Upgrade Cassandra or DSE clusters in Kubernetes

To upgrade Cassandra or DSE clusters in Kubernetes, modify and apply the revised configuration.

Replace prior cluster configuration

If you previously created a `

` configuration and want to define a different one in your Kubernetes (K8s) cluster where Kubernetes Operator for Apache Cassandra is running and the Storage class is defined, then complete the following steps.

Remove the existing CassandraDatacenter configuration.

For example:

kubectl -n cass-operator delete -f https://raw.githubusercontent.com/datastax/cass-operator/v1.6.0/operator/example-cassdc-yaml/dse-6.8.x/example-cassdc-minimal.yaml

Sample Output:

cassandradatacenter.cassandra.datastax.com "dc1" deleted

Next, create the new CassandraDatacenter configuration. The command contains two noticeable differences. The release number changes from v1.6.0 to v1.7.1 and the GitHub repo reflects a change that started with Kubernetes Operator for Apache Cassandra v1.7.0.

For example:
```
kubectl -n cass-operator create -f https://raw.githubusercontent.com/k8ssandra/cass-operator/v1.7.1/operator/example-cassdc-yaml/dse-6.8.x/example-cassdc-three-rack-three-node.yaml
```
Sample Output:
```
cassandradatacenter.cassandra.datastax.com/dc1 created
```

Option to use `forceUpgradeRacks`

For scenarios where a pod ultimately does not start, use forceUpgradeRacks in an edited CassandraDatacenter YAML configuration file to restart the rack that is hosting the pod.

In this example, a three-rack, three-node CassandraDatacenter was created with the following command and its referenced sample YAML configuration file:

kubectl -n cass-operator create -f https://raw.githubusercontent.com/k8ssandra/cass-operator/v1.7.1/operator/example-cassdc-yaml/dse-6.8.x/example-cassdc-three-rack-three-node.yaml

Assume a scenario where the configured cluster2-dc1-rack1-sts-0 pod does not start, as reported in the Google Cloud Console, in the Kubernetes Engine section and the Workloads tab for your cluster.

On a local machine with an established a connection to a Kubernetes project and cluster, use a kubectl command to invoke an editor for the target configuration.

For example, run the following command for namespace cass-operator, datacenter cassdc, and cluster dc1:
```
kubectl -n cass-operator edit cassdc dc1
```
In the editing session, add entries to identify the rack hosting the pod that would not start. In this case, the three racks were defined previously when the datacenter was created using example-cassdc-three-rack-three-node.yaml. The following editing example adds the two-line forceUpgradeRacks: entry:
```
spec:
   forceUpgradeRacks:
   - rack1
   racks:
   - name: rack1
   - name: rack2
   - name: rack3
```
When you save the edited cassdc configuration, Kubernetes Operator for Apache Cassandra directly applies the requested forceUpgradeRacks action to the target rack in the cluster. Upon completion, Kubernetes Operator for Apache Cassandra removes the forceUpgradeRacks entry from the cassdc YAML configuration file.

After allowing time for the pods to restart, check the pods status again to see if the upgraded rack solved the issue.

For example:

kubectl -n cass-operator get pod

Sample Output:

NAME                             READY   STATUS    RESTARTS   AGE
cass-operator-78c9999797-gdnwd   1/1     Running   0          18h
cluster2-dc1-rack1-sts-0         2/2     Running   0          4m23s
cluster2-dc1-rack2-sts-0         2/2     Running   0          4m23s
cluster2-dc1-rack3-sts-0         2/2     Running   0          4m23s

What’s next?

To uninstall Kubernetes Operator for Apache Cassandra and related resources from Kubernetes, see this topic.

Upgrade Cassandra or DSE clusters in Kubernetes

Replace prior cluster configuration

Option to use `forceUpgradeRacks`

What’s next?

Was this helpful?

Give Feedback

Upgrade Cassandra or DSE clusters in Kubernetes

Replace prior cluster configuration

Option to use forceUpgradeRacks

What’s next?

Was this helpful?

Option to use `forceUpgradeRacks`