Skip to content

Commit 533a83b

Browse files
frozenprocessfrozenprocess
committed
This PR adds the necessary steps for someone who is running OpenShift OVN to migrate to Calico.
- Adds a tutorial on how to migrate from OVN to Calico. - Adds a local workaround to use Red Hat CRC to run a test. - Adds reasons why people should consider Calico, such as its eBPF dataplane and Whisker. - Explains the VMware migration path and possibilities.
1 parent 1c38ca4 commit 533a83b

File tree

4 files changed

+389
-1
lines changed

4 files changed

+389
-1
lines changed

‎calico/getting-started/kubernetes/openshift/ovn-to-calico.mdx

+194
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,194 @@
1+
---
2+
description: Migrate from OVN Kubernetes CNI to Calico
3+
---
4+
5+
# Migrate from OVN-Kubernetes CNI to Calico
6+
7+
In scenarios where creating an OpenShift cluster from scratch isn't feasible, this tutorial guides you through the live migration of your Container Network Interface (CNI) from OVN-Kubernetes to $[prodname]. This migration unlocks advanced networking and security capabilities crucial for modern cloud-native environments.
8+
9+
## Why should I use $[prodname]
10+
$[prodname] offers significant advantages over OVN-Kubernetes, particularly when it comes to advanced networking and security features:
11+
12+
- **eBPF Networking:** $[prodname]'s support for eBPF (Extended Berkeley Packet Filter) allows for highly efficient and programmable in-kernel network data path manipulation. This translates to significant performance improvements in areas like network policy enforcement, load balancing, and service mesh integration, as the processing happens directly within the kernel, reducing context switching and overhead.
13+
- **Support for Virtual Machines:** $[prodname] integrates seamlessly with virtual machine workloads managed by technologies like KubeVirt. It can provide consistent networking and security policies across both containers and VMs within the OpenShift cluster. This unified approach simplifies network management and policy enforcement in hybrid environments.
14+
- **Advanced Network Policy:** $[prodname]'s network policy engine is highly flexible and scalable, allowing for fine-grained control over pod-to-pod, pod-to-external, and host-to-pod communication.
15+
- **Scalability and Performance:** For large and high-throughput environments, $[prodname]'s architecture, particularly when leveraging eBPF or its data plane offers better scalability and performance.
16+
- **VMware Migration Ready:** $[prodname] allows you to have capabilities such as tier-0 routing, VM tenant isolation, and microsegemntation to help your VMware migration journey to Kubernetes.
17+
- **Network Observability:** Understanding your cluster's network traffic is crucial for security. $[prodname] Whisker offers a simple GUI to observe and interact with your network logs, making it easier than ever to identify anomalies and create targeted security policies that truly protect your environment.
18+
19+
## Prerequisites
20+
21+
:::note
22+
Before diving into this tutorial with your own setup, consider leveraging [crc](https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/).
23+
It offers a convenient way to spin up a development OpenShift environment for experimentation.
24+
25+
Red Hat CodeReady Containers (CRC) provides a minimal, preconfigured OpenShift 4 cluster on a laptop or desktop machine for development and testing purposes. CRC is delivered as a platform inside of the VM.
26+
:::
27+
28+
- Verify that your OpenShift cluster is in a healthy state with all nodes and control plane components functioning correctly.
29+
- Implement a robust backup strategy for your etcd data and critical cluster configurations.
30+
- Ensure your nodes have sufficient resources (CPU, memory) to accommodate the $[prodname] agents and any potential increase in resource usage due to the new CNI.
31+
32+
While this tutorial aims for a smooth transition, unforeseen issues can occur. It is recommended that for any environment more than 50 nodes you consult with us via our [slack group](http://slack.projectcalico.org/).
33+
34+
:::note
35+
Be aware that the migration process will cause network disruption as the underlying networking fabric is replaced. Plan for downtime and communicate this to stakeholders.
36+
:::
37+
38+
## Disable Machine Config Pool Updates
39+
40+
OpenShift's Machine Config Operator (MCO) manages the operating system configuration of your nodes.
41+
During a CNI migration, changes to the network configuration are significant.
42+
To prevent the MCO from applying potentially conflicting configuration updates during this critical phase, we pause the Machine Config Pools (MCPs).
43+
```bash
44+
oc patch MachineConfigPool master --type='merge' --patch '{ "spec": { "paused": true } }'
45+
oc patch MachineConfigPool worker --type='merge' --patch '{ "spec":{ "paused": true } }'
46+
```
47+
48+
This ensures that no unintended configuration changes are rolled out to your master and worker nodes while the CNI migration is in progress.
49+
This prevents potential instability or conflicts arising from simultaneous network and OS configuration updates.
50+
51+
## Preparing your cluster for Migration
52+
53+
Start by checking if any other migrations are currently in progress:
54+
```bash
55+
oc get Network.operator.openshift.io cluster -o jsonpath='{.spec.migration}'
56+
```
57+
58+
If no migration is currently in progress then, clear the migration status:
59+
```bash
60+
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "migration": null } }'
61+
```
62+
63+
Next, enable migration to $[prodname].
64+
```bash
65+
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "migration": { "networkType": "Calico" } } }'
66+
```
67+
68+
This crucial command signals the OpenShift network operator to initiate CNI migration to $[prodname].
69+
Setting `spec.migration.networkType` to `$[prodname]` enables and configures cluster network migration, for network changes that cannot be made instantly.
70+
71+
## Install $[prodname]
72+
73+
Download the $[prodname] manifests for OpenShift.
74+
```bash
75+
mkdir calico
76+
wget -qO- $[calicoReleasesURL]/$[releaseTitle]/ocp.tgz | tar xvz --strip-components=1 -C calico
77+
cd calico
78+
```
79+
80+
use `oc create -f` to install all manifests other than the ones that have `-cr-` in their name.
81+
If you are using Linux try the following command:
82+
```bash
83+
for file in $(ls *.yaml | grep -Ev 'cr-(.*?)\.yaml'); do
84+
echo "Applying $file"
85+
oc create -f "$file"
86+
done
87+
```
88+
89+
Wait for Tigera-operator to successfully rollout.
90+
```bash
91+
oc rollout status -w --timeout=2m -n tigera-operator deployment/tigera-operator
92+
```
93+
94+
Currently there is a problem with the way OpenShift and Operator try to gain access to admin network policy CRD.
95+
As a workaround disable adminnetworkpolicy CRD creation. Click [here](https://github.com/tigera/operator/issues/3893) if you like to know more about the issue.
96+
```bash
97+
oc patch crd adminnetworkpolicies.policy.networking.k8s.io --type=merge -p='{"metadata":{"annotations":{"unsupported.operator.tigera.io/ignore": "true"}}}'
98+
```
99+
100+
:::note
101+
Enhancement for eBPF: If you intend to leverage $[prodname]'s eBPF data plane for enhanced performance and features,
102+
you do not need to set `deployKubeProxy` to `true`. Since $[prodname] eBPF data plane completely replaces the kube-proxy functionality.
103+
:::
104+
105+
Enable kube-proxy or use [eBPF](https://docs.tigera.io/calico/latest/operations/ebpf/enabling-ebpf)
106+
```bash
107+
oc patch networks.operator.openshift.io cluster --type merge -p '{"spec":{"deployKubeProxy": true}}'
108+
```
109+
110+
Create installation manifest to instruct Tigera operator to install $[prodname].
111+
```bash
112+
oc create -f *cr*.yaml
113+
```
114+
115+
Wait until $[prodname] components are ready.
116+
```bash
117+
oc wait --for=condition=Available tigerastatus --all
118+
```
119+
120+
By setting `spec.networkType` to `$[prodname]`, you inform the OpenShift network management system that $[prodname] is now the active CNI.
121+
This triggers the final steps in the migration process, such as configuring node networking to use $[prodname].
122+
```bash
123+
oc patch Network.config.openshift.io cluster --type='merge' --patch '{ "spec": { "networkType": "Calico" } }'
124+
```
125+
126+
## Restart Multus
127+
OpenShift Container Platform uses the Multus CNI plugin to allow chaining of CNI plugins.
128+
During cluster installation, you configure your default pod network. Multus acts as a meta-CNI, allowing pods to have multiple network interfaces.
129+
130+
Restart Multus using the following command:
131+
```bash
132+
oc -n openshift-multus rollout restart daemonset/multus
133+
```
134+
135+
Wait for Multus to report back:
136+
```bash
137+
oc -n openshift-multus -w --timeout=2m rollout status daemonset/multus
138+
```
139+
140+
At this point, you can finalize the migration, allowing the network operator to apply all the changes:
141+
```bash
142+
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "migration": null } }'
143+
```
144+
145+
## Clean up
146+
147+
After migration, you can completely remove OVN-Kubernetes CNI. These commands remove any remaining OVN-Kubernetes parts from your cluster.
148+
This ensures a clean transition and prevents potential conflicts with the new $[prodname] CNI.
149+
150+
Remove OVN-Kubernetes specific configurations:
151+
```bash
152+
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig":null } } }'
153+
```
154+
155+
Remove SDN-Kubernetes specific configurations:
156+
```bash
157+
oc patch Network.operator.openshift.io cluster --type='merge' --patch '{ "spec": { "defaultNetwork": { "ovnKubernetesConfig":null } } }'
158+
```
159+
160+
Remove openshift OVN by deleting its namespace.
161+
```bash
162+
oc delete namespace openshift-ovn-kubernetes
163+
```
164+
165+
At this stage, anticipate a period of service disruption.
166+
The duration and impact will vary depending on the size and complexity of your OpenShift environment.
167+
You might observe some nodes temporarily becoming unresponsive as the underlying OVN network interfaces are removed and workloads transition to utilizing the newly established $[prodname] interfaces.
168+
This transition involves re-establishing network connectivity for all pods and services, which can take some time.
169+
170+
## Return your nodes to their original state
171+
172+
MachineConfigPools are paused, preventing the Machine Config Operator to push out updates in OpenShift 4.
173+
174+
Re-enable Machine Config Pool updates:
175+
```bash
176+
oc patch MachineConfigPool master --type='merge' --patch '{ "spec": { "paused": false } }'
177+
oc patch MachineConfigPool worker --type='merge' --patch '{ "spec":{ "paused": false } }'
178+
```
179+
180+
181+
## Next steps
182+
183+
**Recommended - Networking**
184+
185+
- If you are using the default BGP networking with full-mesh node-to-node peering with no encapsulation, go to [Configure BGP peering](../../../networking/configuring/bgp.mdx) to get traffic flowing between pods.
186+
- If you are unsure about networking options, or want to implement encapsulation (overlay networking), see [Determine best networking option](../../../networking/determine-best-networking.mdx).
187+
188+
**Recommended - Security**
189+
190+
- [Enable network observability](../../../observability/index.mdx)
191+
- [Secure Calico component communications](../../../network-policy/comms/crypto-auth.mdx)
192+
- [Secure hosts by installing Calico on hosts](../../bare-metal/about.mdx)
193+
- [Secure pods with Calico network policy](../../../network-policy/get-started/calico-policy/calico-network-policy.mdx)
194+
- If you are using $[prodname] with Istio service mesh, get started here: [Enable application layer policy](../../../network-policy/istio/app-layer-policy.mdx)

0 commit comments

Comments
 (0)