Skip to content

Latest commit

 

History

History
92 lines (71 loc) · 4.9 KB

upgrade.adoc

File metadata and controls

92 lines (71 loc) · 4.9 KB

Upgrade Kadalu

Here the steps to upgrade a Kadalu service to the latest version for Kubernetes.

Upgrade kubectl-kadalu binary

$ curl -fsSL https://github.com/kadalu/kadalu/releases/latest/download/install.sh | sudo bash -x
$ kubectl-kadalu version
[...]

Apply kadalu operator file

  1. Download the relevant Kadalu Operator file definition according to your Kubernetes Cluster:

  2. Apply the file definition to the Kubernetes Cluster.

kubectl apply -f kadalu-operator.yaml

Exemple for a generic Kubernetes Cluster in single command ligne:

  curl -Ls https://github.com/kadalu/kadalu/releases/latest/download/kadalu-operator.yaml | sed -e 's/"no"/"yes"/g' | kubectl apply -f -

  namespace/kadalu unchanged
  serviceaccount/kadalu-operator unchanged
  serviceaccount/kadalu-csi-nodeplugin unchanged
  serviceaccount/kadalu-csi-provisioner unchanged
  serviceaccount/kadalu-server-sa unchanged
  customresourcedefinition.apiextensions.k8s.io/kadalustorages.kadalu-operator.storage configured
  clusterrole.rbac.authorization.k8s.io/pod-exec unchanged
  clusterrole.rbac.authorization.k8s.io/kadalu-operator unchanged
  clusterrolebinding.rbac.authorization.k8s.io/kadalu-operator unchanged
  deployment.apps/operator configured

(wait for operator and csi-provisionner pods in kadalu namespace get in Running state)

Apply kadalu CSI-Nodeplugin

  1. Download the relevant Kadalu CSI-Nodeplugin file definition according to your Kubernetes Cluster:

  2. Apply the file definition to the Kubernetes Cluster.

kubectl apply -f csi-nodeplugin.yaml

Example for a generic Kubernetes Cluster in single command line:

curl -Ls https://github.com/kadalu/kadalu/releases/latest/download/csi-nodeplugin.yaml | sed -e 's/"no"/"yes"/g' | kubectl apply -f -

clusterrole.rbac.authorization.k8s.io/kadalu-csi-nodeplugin unchanged
clusterrolebinding.rbac.authorization.k8s.io/kadalu-csi-nodeplugin unchanged
daemonset.apps/kadalu-csi-nodeplugin configured
  • As the .spec.updateStrategy.type of the Nodeplugin Daemonset is onDelete the onus is on the admin to drain the nodes where kadalu-nodeplugin is running and delete the nodeplugin one at a time

  • After the nodeplugin is deleted, the new nodeplugin will be run on that specific node and new workloads can be scheduled to run on that node

  • One of the below three options can be followed for a successful update

  • Assume we have three worker nodes running kadalu nodeplugin, i.e, node-a, node-b, node-c

Option 1 (preferred): Use a liveness probe on your workload

  1. Include a liveness probe for your container to list the mounted volume/device as nodeplugin now remounts corrupted mounts and pods having a liveness probe can recovery mount at their end by a container restart due to liveness failure on the mounted volume

Option 2: Cordon and drain one node at a time

  1. Drain node-a and delete the nodeplugin running on node-a

  2. Uncordon node-a and await new version of nodeplugin come up on node-a

  3. Repeat step-2 for remaining nodes and by the end new version of nodeplugins on all nodes should be in running state

Option 3: Evict specific deployments using kubectl-evict plugin

  1. Option 1 evicts all the pods running on a node and however the kubectl-evict plugin can be used to evict a specific deployment

  2. Cordon one of the nodes, let’s say node-a, evict a deployment running on node-a which is using kadalu pvc

  3. Delete the nodeplugin pod running on node-a and uncordon node-a

  4. Repeat step-2 for remaining nodes and by the end new version of nodeplugins on all nodes should be in running state

  5. This’ll be helpful if the nodes are running workloads with less headroom wherein for various reasons the workload which was evicted may never be re-scheduled on other nodes