|
| 1 | +# Calico v2.5.0 Upgrade Procedure |
| 2 | + |
| 3 | +## Why this is required |
| 4 | + |
| 5 | +Kubernetes v1.7 introduces a new API data type called CustomResourceDefinition (CRD) which will replace the alpha ThirdPartyResource (TPR). |
| 6 | +Calico relies on TPR to store it's config data when it uses kubernetes datastore backend. Moving forward from kubernetes v1.8, |
| 7 | +Kubernetes will remove the support for TPR in favor of CRD. In order to preserve the config data backed by TPR, and continue to |
| 8 | +work with the future Kubernetes versions, it is required to go through this migration process. |
| 9 | +See [this blog post](https://coreos.com/blog/custom-resource-kubernetes-v17) for more information on this new data type. |
| 10 | + |
| 11 | +## Steps required |
| 12 | + |
| 13 | +At a high level we need to do the following steps to make sure we have a successful upgrade. |
| 14 | + |
| 15 | + 1. Check to make sure if you need to do the migration |
| 16 | + 2. Backup your TPR data (Data is in TPR right now) |
| 17 | + 3. Run the migration job (Data is copied from TPR to CRD) |
| 18 | + 4. Verify the migration (Data is still in both TPR and CRD, Calico is still using TPR) |
| 19 | + 5. Upgrade Calico version to `v2.5.0` (Data is still in TPR and CRD, but Calico now uses CRD backed data) |
| 20 | + 6. Verify Calico policy and networking works as expected |
| 21 | + 7. Delete the TPRs |
| 22 | + |
| 23 | +## 1. Before you begin |
| 24 | + |
| 25 | +### 1.1 Do I need to go through this migration process? |
| 26 | + |
| 27 | +This is only required if you meet ALL of the following criteria: |
| 28 | + |
| 29 | +- Running Calico with Kubernetes |
| 30 | +- Current Kubernetes version is `v1.7.x` |
| 31 | +- Current Calico version is `v2.4.x` or lower |
| 32 | +- Upgrading Calico to `v2.5.x` |
| 33 | +- Calico is running with Kubernetes datastore backend (By running `calicoctl version` and making sure `Cluster Type` is `KDD`) |
| 34 | + |
| 35 | +### 1.2 Backup your config data |
| 36 | + |
| 37 | +We highly recommend backing up your config data before proceeding with the migration process. |
| 38 | +We only need to backup the config backed by TPR resources; in the event the migration needs to be halted, you'll be able to restore the original data. |
| 39 | + |
| 40 | +> Note: the migration job does not delete your old data, so your config data backed by TPR will still be there until |
| 41 | + deleted manually (explained in the last step of this doc). |
| 42 | + |
| 43 | +Run the following commands to backup your config data: |
| 44 | + |
| 45 | +> Note: use `calicoctl` version [v1.4.1](https://github.com/projectcalico/calicoctl/releases/tag/v1.4.1) |
| 46 | + and `kubectl` version [v1.7.4](https://kubernetes.io/docs/tasks/tools/install-kubectl/) to backup the data. |
| 47 | + |
| 48 | +Since we will need `calicoctl` versions [v1.4.1](https://github.com/projectcalico/calicoctl/releases/tag/v1.4.1) and [v1.5.0](https://github.com/projectcalico/calicoctl/releases/tag/v1.5.0) for this upgrade, |
| 49 | + we recommend downloading them both and suffixing the binaries with their respective versions (you can check the version by running `calicoctl version`) |
| 50 | + |
| 51 | + 1.2.1. `calicoctl_v1.4 get ippools -o yaml > ippool.yaml` |
| 52 | + |
| 53 | + 1.2.2. `calicoctl_v1.4 get bgppeers -o yaml > bgppeer.yaml` |
| 54 | + |
| 55 | + 1.2.3. `kubectl get globalconfig --all-namespaces -o yaml > tpr-felixconfig.yaml` |
| 56 | + |
| 57 | + 1.2.4. `kubectl get globalbgpconfig --all-namespaces -o yaml > tpr-bgpconfig.yaml` |
| 58 | + |
| 59 | +> Note: you may not have some of these resources if you're using Calico in policy-only mode. |
| 60 | +
|
| 61 | +## 2. Migration process |
| 62 | + |
| 63 | + 2.1. Create the migration kubernetes job for your cluster: `kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/master/upgrade/v2.5/manifests/upgrade-job.yaml` |
| 64 | + |
| 65 | + 2.2. Check the job status `kubectl describe job/calico-upgrade-v2.5` |
| 66 | + |
| 67 | + 2.3. Check the upgrade job logs `kubectl logs <upgrade-pod-name>` to make sure there aren't any errors (You can get the upgrade job's pod name from the previous command output 'Message' field) |
| 68 | + |
| 69 | +## 3. After the migration |
| 70 | + |
| 71 | +### 3.1 Verify that the data has been copied correctly |
| 72 | + |
| 73 | +Make sure you have all the `IPPools`, `BGPPeers`, `GlobalFelixConfig` and `GlobalBGPConfig` resource configs you had before the upgrade: |
| 74 | + |
| 75 | + 3.1.1. `calicoctl_v1.5 get ippools -o wide` |
| 76 | + |
| 77 | + 3.1.2. `calicoctl_v1.5 get bgppeers -o wide` (This is only if you're running Calico BGP networking) |
| 78 | + |
| 79 | + 3.1.3. `kubectl get globalfelixconfigs.crd.projectcalico.org -o wide` |
| 80 | + |
| 81 | + 3.1.4. `kubectl get globalbgpconfigs.crd.projectcalico.org -o wide` |
| 82 | + |
| 83 | +## 4. Upgrade calico |
| 84 | + |
| 85 | + 4.1. (If you have RBAC enabled) Apply the updated RBAC manifest `kubectl apply -f https://docs.projectcalico.org/v2.5/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml` (this will revoke access to TPRs from calico-node) |
| 86 | + |
| 87 | + 4.2. Now you can upgrade Calico version to `v2.5.0` in your kubernetes Calico DaemonSet. (Make sure you reboot your calico-node pods one at a time if calico-node `updateStrategy` is not set to `RollingUpdate`) |
| 88 | + |
| 89 | + 4.3. Verify that everything is working as expected. |
| 90 | + |
| 91 | +## 5. Delete the old TPRs |
| 92 | + |
| 93 | +You can now delete your TPRs by running the following command: |
| 94 | +`kubectl delete -f https://raw.githubusercontent.com/projectcalico/calico/master/upgrade/v2.5/manifests/tprs.yaml` |
0 commit comments