134
edits
Equipment/Blanton/Kubernetes: Difference between revisions
From London Hackspace Wiki
→Upgrading Kubernetes
Mich181189 (talk | contribs) |
Mich181189 (talk | contribs) |
||
| Line 157: | Line 157: | ||
It’s perhaps worth ignoring the 1.x.0 releases, since experience suggests things like metallb and callico might not yet support it in a stable version, which is a recipe for pain. | It’s perhaps worth ignoring the 1.x.0 releases, since experience suggests things like metallb and callico might not yet support it in a stable version, which is a recipe for pain. | ||
You probably also want to upgrade cluster services to make sure they're compatible with the newer version: | |||
* Calico is a little tricky: because we have IPv4 and IPv6 you need to merge some of the changes into the manifest (see https://projectcalico.docs.tigera.io/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-with-kubernetes-api-datastore-50-nodes-or-less) Specifically, FELIX_IPV6SUPPORT needs to be true! | |||
* MetalLB is easier because it (sensibly) doesn't mix config in with the deployment manifest so you can deploy straight from https://metallb.universe.tf/installation/ | |||
* cert-manager is also fairly easy, from https://cert-manager.io/docs/installation/upgrading/ (use the static manifest instructions) | |||
* ingress-nginx is an easy one as well: https://kubernetes.github.io/ingress-nginx/deploy/upgrade/ (though they sometimes seem to change permissions so you might need to reference the cloud install manifest - cloud install not bare-metal because we're running metallb) | |||
You might want to scale the acnode-dash-status deployment to zero so it doesn't throw up false errors if the network gets flaky while you're doing this | |||
# On the master node, run <code>apt-cache madison kubeadm</code> to find a version to update to | # On the master node, run <code>apt-cache madison kubeadm</code> to find a version to update to | ||
| Line 164: | Line 172: | ||
#: <pre>sudo kubeadm upgrade apply --patches=/etc/kubernetes/patches v<your-chosen-version></pre> | #: <pre>sudo kubeadm upgrade apply --patches=/etc/kubernetes/patches v<your-chosen-version></pre> | ||
#: <pre>sudo apt-get install -y --allow-change-held-packages kubelet=<your-chosen-version> kubectl=<your-chosen-version></pre> | #: <pre>sudo apt-get install -y --allow-change-held-packages kubelet=<your-chosen-version> kubectl=<your-chosen-version></pre> | ||
#: <pre>sudo apt-mark hold kubelet kubeadm kubectl</pre> to make sure the packages are again pinned | |||
On each node: | On each node: | ||
| Line 173: | Line 181: | ||
#: <pre>sudo kubeadm upgrade node</pre> | #: <pre>sudo kubeadm upgrade node</pre> | ||
#: <pre>sudo apt-get install -y --allow-change-held-packages kubelet=<your-chosen-version> kubectl=<your-chosen-version></pre> | #: <pre>sudo apt-get install -y --allow-change-held-packages kubelet=<your-chosen-version> kubectl=<your-chosen-version></pre> | ||
#: <pre>sudo apt-mark hold kubelet kubeadm kubectl</pre> to make sure the packages are again pinned | |||
# run <code>kubectl get nodes</code> wherever you normally run kubectl to make sure the node is running the expected version | # run <code>kubectl get nodes</code> wherever you normally run kubectl to make sure the node is running the expected version | ||
# Uncordon node | # Uncordon node | ||
