To upgrade the csi-driver version, you just need to apply the new manifests to your cluster.
In case of a new major version, there might be manual steps that you need to follow to upgrade the csi-driver. See the following section for a list of major updates and their required steps.
### From v1 to v2
There are two breaking changes between v1.6 and v2.0 that require user intervention. Please take care to follow these steps, as otherwise the update might fail.
**Before the rollout**:
1. The secret containing the API token was renamed from `hcloud-csi` to `hcloud`. This change was made so both the cloud-controller-manager and the csi-driver can use the same secret. Check that you have a secret `hcloud` in the namespace `kube-system`, and that the secret contains the API token, as described in the section [Getting Started](#getting-started):
```shell
$ kubectl get secret -n kube-system hcloud
```
2. We added a new field to our `CSIDriver` resource to support [CSI volume fsGroup policy management](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods). This change requires a replacement of the `CSIDriver` object. You need to manually delete the old object:
```shell
$ kubectl delete csidriver csi.hetzner.cloud
```
The new `CSIDriver` will be installed when you apply the new manifests.
3. Stop the old pods to make sure that only everything is replaced in order and no incompatible pods are running side-by-side:
There was a bug in the interaction between `hcloud-csi-driver` and the `cluster-autoscaler` where the autoscaler would fail to scale up when the pending pod had pre-existing `PersistentVolumes`. This was fixed in v2.0.0 for new `PersistentVolumes`. Unfortunately this fix does not work for `PersistentVolumes` created by `v1.x` of the driver. For details on this bug, see [PR #302](https://github.com/hetznercloud/csi-driver/pull/302).
To check if your volume is affected by this, you can execute the following command for the `PersistentVolume` and verify the output:
```bash
$ kubectl get persistentvolume NAME_OF_THE_PV -ojsonpath="{.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].key}}"
```
If the return value is `topology.kubernetes.io/region` then the volume was created with `v2.x+`.
If it is `csi.hetzner.cloud/location` then the volume was created with `v1.x` and will not work properly with `cluster-autoscaler`. We are currently working on a fix in `cluster-autoscaler` for old volumes, see PR [kubernetes/autoscaler#5322](https://github.com/kubernetes/autoscaler/pull/5322) for details and current status.
## Integration with Root Servers
## Integration with Root Servers
Root servers can be part of the cluster, but the CSI plugin doesn't work there. Taint the root server as follows to skip that node for the daemonset.
Root servers can be part of the cluster, but the CSI plugin doesn't work there. Taint the root server as follows to skip that node for the daemonset.
...
@@ -131,13 +188,13 @@ we do not test that version anymore. Additionally, we will not fix bugs
...
@@ -131,13 +188,13 @@ we do not test that version anymore. Additionally, we will not fix bugs