Version: release-0.9

Manage Milvus with KubeBlocks

The popularity of generative AI (Generative AI) has aroused widespread attention and completely ignited the vector database (Vector Database) market.

Milvus is a highly flexible, reliable, and blazing-fast cloud-native, open-source vector database. It powers embedding similarity search and AI applications and strives to make vector databases accessible to every organization. Milvus can store, index, and manage a billion+ embedding vectors generated by deep neural networks and other machine learning (ML) models.

This tutorial illustrates how to create and manage a Milvus cluster by kbcli, kubectl or a YAML file. You can find the YAML examples and guides in the GitHub repository.

Before you start

Install kbcli if you want to manage the Milvus cluster with kbcli.
Install KubeBlocks by kbcli or by Helm.
Install and enable the milvus Addon by kbcli or by Helm.
To keep things isolated, create a separate namespace called demo throughout this tutorial.
```
kubectl create namespace demo
```

Create a cluster

kbcli
kubectl

Steps

Execute the following command to create a Milvus cluster.

kbcli cluster create mycluster --cluster-definition=milvus-2.3.2 -n demo

note

If you want to customize your cluster specifications, kbcli provides various options, such as setting cluster version, termination policy, CPU, and memory. You can view these options by adding --help or -h flag.

kbcli cluster create milvus --help

kbcli cluster create milvus -h

Check whether the cluster is created successfully.

kbcli cluster list -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION        VERSION               TERMINATION-POLICY   STATUS           CREATED-TIME
mycluster   demo        milvus-2.3.2                                    Delete               Running          Jul 05,2024 17:35 UTC+0800   

Check the cluster information.

kbcli cluster describe mycluster -n demo
>
Name: milvus     Created Time: Jul 05,2024 17:35 UTC+0800
NAMESPACE   CLUSTER-DEFINITION   VERSION   STATUS    TERMINATION-POLICY   
demo        milvus-2.3.2                   Running   Delete               

Endpoints:
COMPONENT   MODE        INTERNAL                                        EXTERNAL   
milvus      ReadWrite   milvus-milvus.default.svc.cluster.local:19530   <none>     
minio       ReadWrite   milvus-minio.default.svc.cluster.local:9000     <none>     
proxy       ReadWrite   milvus-proxy.default.svc.cluster.local:19530    <none>     
                        milvus-proxy.default.svc.cluster.local:9091                

Topology:
COMPONENT   INSTANCE             ROLE     STATUS    AZ       NODE     CREATED-TIME                 
etcd        milvus-etcd-0        <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
minio       milvus-minio-0       <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
milvus      milvus-milvus-0      <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
indexnode   milvus-indexnode-0   <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
mixcoord    milvus-mixcoord-0    <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
querynode   milvus-querynode-0   <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
datanode    milvus-datanode-0    <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   
proxy       milvus-proxy-0       <none>   Running   <none>   <none>   Jul 05,2024 17:35 UTC+0800   

Resources Allocation:
COMPONENT   DEDICATED   CPU(REQUEST/LIMIT)   MEMORY(REQUEST/LIMIT)   STORAGE-SIZE   STORAGE-CLASS     
milvus      false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
etcd        false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
minio       false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
proxy       false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
mixcoord    false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
datanode    false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
indexnode   false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   
querynode   false       1 / 1                1Gi / 1Gi               data:20Gi      csi-hostpath-sc   

Images:
COMPONENT   TYPE        IMAGE                                                
milvus      milvus      milvusdb/milvus:v2.3.2                               
etcd        etcd        docker.io/milvusdb/etcd:3.5.5-r2                     
minio       minio       docker.io/minio/minio:RELEASE.2022-03-17T06-34-49Z   
proxy       proxy       milvusdb/milvus:v2.3.2                               
mixcoord    mixcoord    milvusdb/milvus:v2.3.2                               
datanode    datanode    milvusdb/milvus:v2.3.2                               
indexnode   indexnode   milvusdb/milvus:v2.3.2                               
querynode   querynode   milvusdb/milvus:v2.3.2                               

Show cluster events: kbcli cluster list-events -n demo milvus

KubeBlocks implements a Cluster CRD to define a cluster. Here is an example of creating a Milvus cluster.

cat <<EOF | kubectl apply -f -
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  affinity:
    podAntiAffinity: Preferred
    topologyKeys: 
    - kubernetes.io/hostname
  clusterDefinitionRef: milvus-2.3.2
  componentSpecs:
  - componentDefRef: milvus
    disableExporter: true
    name: milvus
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: etcd
    disableExporter: true
    name: etcd
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: minio
    disableExporter: true
    name: minio
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: proxy
    disableExporter: true
    name: proxy
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: mixcoord
    disableExporter: true
    name: mixcoord
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: datanode
    disableExporter: true
    name: datanode
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: indexnode
    disableExporter: true
    name: indexnode
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  - componentDefRef: querynode
    disableExporter: true
    name: querynode
    replicas: 1
    resources:
      limits:
        cpu: "1"
        memory: 1Gi
      requests:
        cpu: "1"
        memory: 1Gi
    serviceAccountName: kb-mycluster
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
  resources:
    cpu: "0"
    memory: "0"
  storage:
    size: "0"
  terminationPolicy: Delete
status: {}
EOF

Field	Definition
`spec.clusterDefinitionRef`	It specifies the name of the ClusterDefinition for creating a specific type of cluster.
`spec.clusterVersionRef`	It is the name of the cluster version CRD that defines the cluster version.
`spec.terminationPolicy`	It is the policy of cluster termination. The default value is `Delete`. Valid values are `DoNotTerminate`, `Delete`, `WipeOut`. For the detailed definition, you can refer to Termination Policy.
`spec.affinity`	It defines a set of node affinity scheduling rules for the cluster's Pods. This field helps control the placement of Pods on nodes within the cluster.
`spec.affinity.podAntiAffinity`	It specifies the anti-affinity level of Pods within a component. It determines how pods should spread across nodes to improve availability and performance.
`spec.affinity.topologyKeys`	It represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.
`spec.tolerations`	It is an array that specifies tolerations attached to the cluster's Pods, allowing them to be scheduled onto nodes with matching taints.
`spec.componentSpecs`	It is the list of components that define the cluster components. This field allows customized configuration of each component within a cluster.
`spec.componentSpecs.componentDefRef`	It is the name of the component definition that is defined in the cluster definition and you can get the component definition names with `kubectl get clusterdefinition milvus -o json \\| jq '.spec.componentDefs[].name'`.
`spec.componentSpecs.name`	It specifies the name of the component.
`spec.componentSpecs.disableExporter`	It defines whether the monitoring function is enabled.
`spec.componentSpecs.replicas`	It specifies the number of replicas of the component.
`spec.componentSpecs.resources`	It specifies the resource requirements of the component.

KubeBlocks operator watches for the Cluster CRD and creates the cluster and all dependent resources. You can get all the resources created by the cluster with kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo.

kubectl get all,secret,rolebinding,serviceaccount -l app.kubernetes.io/instance=mycluster -n demo

Run the following command to see the created Milvus cluster object:

kubectl get cluster mycluster -n demo -o yaml

Scale

Currently, KubeBlocks supports vertically scaling a Milvus cluster.

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kbcli
kubectl

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION           TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        milvus-2.3.2                           Delete               Running   Jul 05,2024 17:35 UTC+0800

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION                  TERMINATION-POLICY   STATUS    AGE
mycluster   milvus-2.3.2                                  Delete               Running   4m29s

Steps

kbcli
OpsRequest
Edit cluster YAML file

Set the --cpu and --memory values according to your needs and run the following command to perform vertical scaling.
```
kbcli cluster vscale mycluster -n demo --cpu=1 --memory=1Gi --components=milvus 
```
Please wait a few seconds until the scaling process is over.
Validate the vertical scaling operation.
- View the OpsRequest progress.
  KubeBlocks outputs a command automatically for you to view the OpsRequest progress. The output includes the status of this OpsRequest and Pods. When the status is Succeed, this OpsRequest is completed.
```
kbcli cluster describe-ops mycluster-verticalscaling-rpw2l -n demo
```
- Check the cluster status.
```
kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION           TERMINATION-POLICY   STATUS     CREATED-TIME
mycluster   demo                                               Delete               Updating   Jul 05,2024 17:35 UTC+0800
```
  - STATUS=Updating: it means the vertical scaling is in progress.
  - STATUS=Running: it means the vertical scaling operation has been applied.
  - STATUS=Abnormal: it means the vertical scaling is abnormal. The reason may be that the number of the normal instances is less than that of the total instance or the leader instance is running properly while others are abnormal.
    To solve the problem, you can manually check whether this error is caused by insufficient resources. Then if AutoScaling is supported by the Kubernetes cluster, the system recovers when there are enough resources. Otherwise, you can create enough resources and troubleshoot with kubectl describe command.
After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.
```
kbcli cluster describe mycluster -n demo
```

Apply an OpsRequest to the specified cluster. Configure the parameters according to your needs.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-vertical-scaling
  namespace: demo
spec:
  clusterName: mycluster
  type: VerticalScaling
  verticalScaling:
  - componentName: milvus
    requests:
      memory: "2Gi"
      cpu: "1"
    limits:
      memory: "4Gi"
      cpu: "2"
EOF

Check the operation status to validate the vertical scaling.

kubectl get ops -n demo
>
NAMESPACE   NAME                   TYPE              CLUSTER     STATUS    PROGRESS   AGE
demo        ops-vertical-scaling   VerticalScaling   mycluster   Succeed   3/3        6m

If an error occurs, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Change the configuration of spec.componentSpecs.resources in the YAML file. spec.componentSpecs.resources controls the requirement and limit of resources and changing them triggers a vertical scaling.

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: milvus
  clusterVersionRef: milvus-2.3.2
  componentSpecs:
  - name: milvus
    componentDefRef: milvus
    replicas: 1
    resources: # Change the values of resources.
      requests:
        memory: "2Gi"
        cpu: "1"
      limits:
        memory: "4Gi"
        cpu: "2"
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
  terminationPolicy: Delete

Check whether the corresponding resources change.
```
kubectl describe cluster mycluster -n demo
```

Volume Expansion

Before you start

Check whether the cluster status is Running. Otherwise, the following operations may fail.

kbcli
kubectl

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION           TERMINATION-POLICY   STATUS    CREATED-TIME
mycluster   demo        milvus-2.3.2                           Delete               Running   Jul 05,2024 17:35 UTC+0800

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION                  TERMINATION-POLICY   STATUS    AGE
mycluster   milvus-2.3.2                                  Delete               Running   4m29s

Steps

kbcli
OpsRequest
Edit cluster YAML fil

Set the --storage value according to your need and run the command to expand the volume.
```
kbcli cluster volume-expand mycluster -n demo --storage=40Gi --components=milvus -t data
```
The volume expansion may take a few minutes.
Validate the volume expansion operation.
- View the OpsRequest progress.
  KubeBlocks outputs a command automatically for you to view the details of the OpsRequest progress. The output includes the status of this OpsRequest and PVC. When the status is Succeed, this OpsRequest is completed.
```
kbcli cluster describe-ops mycluster-volumeexpansion-5pbd2 -n demo
```
- View the cluster status.
```
kbcli cluster list mycluster
>
NAME        NAMESPACE   CLUSTER-DEFINITION   VERSION           TERMINATION-POLICY   STATUS     CREATED-TIME
mycluster   demo        milvus-2.3.2                           Delete               Running    Jul 05,2024 17:35 UTC+0800
```
  - STATUS=Updating: it means the volume expansion is in progress.
  - STATUS=Running: it means the volume expansion operation has been applied.
After the OpsRequest status is Succeed or the cluster status is Running again, check whether the corresponding resources change.
```
kbcli cluster describe mycluster -n demo
```

Change the value of storage according to your need and run the command below to expand the volume of a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-volume-expansion
  namespace: demo
spec:
  clusterName: mycluster
  type: VolumeExpansion
  volumeExpansion:
  - componentName: milvus
    volumeClaimTemplates:
    - name: data
      storage: "40Gi" # Set the volume storage size.
EOF

Validate the volume expansion operation.

kubectl get ops -n demo
>
NAMESPACE   NAME                   TYPE              CLUSTER     STATUS    PROGRESS   AGE
demo        ops-volume-expansion   VolumeExpansion   mycluster   Succeed   3/3        6m

If an error occurs to the vertical scaling operation, you can troubleshoot with kubectl describe ops -n demo command to view the events of this operation.

Check whether the corresponding cluster resources change.
```
kubectl describe cluster mycluster -n demo
```

Change the value of spec.componentSpecs.volumeClaimTemplates.spec.resources in the cluster YAML file.

spec.componentSpecs.volumeClaimTemplates.spec.resources is the storage resource information of the pod and changing this value triggers the volume expansion of a cluster.

kubectl edit cluster mycluster -n demo
apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: milvus
  clusterVersionRef: milvus-2.3.2
  componentSpecs:
  - name: milvus
    componentDefRef: milvus
    replicas: 2
    volumeClaimTemplates:
    - name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 40Gi # Change the volume storage size.
  terminationPolicy: Delete

Check whether the corresponding cluster resources change.
```
kubectl describe cluster mycluster -n demo
```

Restart

kbcli
OpsRequest

Configure the values of components and ttlSecondsAfterSucceed and run the command below to restart a specified cluster.
```
kbcli cluster restart mycluster -n demo --components="milvus" --ttlSecondsAfterSucceed=30
```
- components describes the component name that needs to be restarted.
- ttlSecondsAfterSucceed describes the time to live of an OpsRequest job after the restarting succeeds.

Validate the restarting.

Run the command below to check the cluster status to check the restarting status.

kbcli cluster list mycluster -n demo
>
NAME     NAMESPACE   CLUSTER-DEFINITION     VERSION         TERMINATION-POLICY   STATUS    CREATED-TIME
milvus   demo     milvus-2.3.2                              Delete               Running   Jul 05,2024 18:35 UTC+0800

STATUS=Updating: it means the cluster restart is in progress.
STATUS=Running: it means the cluster has been restarted.

Restart a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-restart
  namespace: demo
spec:
  clusterName: mycluster
  type: Restart 
  restart:
  - componentName: milvus
EOF

Check the pod and operation status to validate the restarting.
```
kubectl get pod -n demo

kubectl get ops ops-restart -n demo
```
During the restarting process, there are two status types for pods.
- STATUS=Terminating: it means the cluster restart is in progress.
- STATUS=Running: it means the cluster has been restarted.

Stop/Start a cluster

You can stop/start a cluster to save computing resources. When a cluster is stopped, the computing resources of this cluster are released, which means the pods of Kubernetes are released, but the storage resources are reserved. You can start this cluster again to restore it to the state it was in before it was stopped.

Stop a cluster

Configure the name of your cluster and run the command below to stop this cluster.

kbcli
OpsRequest
Edit Cluster YAML File

kbcli cluster stop mycluster -n demo

Apply an OpsRequest to stop a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-stop
  namespace: demo
spec:
  clusterName: mycluster
  type: Stop
EOF

Configure replicas as 0 to delete pods.

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: milvus
  clusterVersionRef: milvus-2.3.2
  terminationPolicy: Delete
  componentSpecs:
  - name: milvus
    componentDefRef: milvus
    disableExporter: true  
    replicas: 0 # Change this value
......

Check the status of the cluster to see whether it is stopped.

kbcli
kubectl

kbcli cluster list mycluster -n demo

kubectl get cluster mycluster -n demo

Start a cluster

Configure the name of your cluster and run the command below to start this cluster.

kbcli
OpsRequest
Edit Cluster YAML File

kbcli cluster start mycluster -n demo

Apply an OpsRequest to start a cluster.

kubectl apply -f - <<EOF
apiVersion: apps.kubeblocks.io/v1alpha1
kind: OpsRequest
metadata:
  name: ops-start
  namespace: demo
spec:
  clusterName: mycluster
  type: Start
EOF 

Change replicas back to the original amount to start this cluster again.

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Cluster
metadata:
  name: mycluster
  namespace: demo
spec:
  clusterDefinitionRef: milvus
  clusterVersionRef: milvus-2.3.2
  terminationPolicy: Delete
  componentSpecs:
  - name: milvus
    componentDefRef: milvus
    disableExporter: true  
    replicas: 1 # Change this value
......

Check the status of the cluster to see whether it is running again.
- kbcli
- kubectl
kbcli cluster list mycluster -n demo
kubectl get cluster mycluster -n demo

Delete a cluster

Termination policy

note

The termination policy determines how a cluster is deleted.

terminationPolicy	Deleting Operation
`DoNotTerminate`	`DoNotTerminate` blocks delete operation.
`Halt`	`Halt` deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations. Halt policy is deprecated in v0.9.1 and will have same meaning as DoNotTerminate.
`Delete`	`Delete` extends the Halt policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
`WipeOut`	`WipeOut` deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, especially in non-production environments, to avoid irreversible data loss.

To check the termination policy, execute the following command.

kbcli
kubectl

kbcli cluster list mycluster -n demo
>
NAME        NAMESPACE   CLUSTER-DEFINITION        VERSION               TERMINATION-POLICY   STATUS           CREATED-TIME
mycluster   demo        milvus-2.3.2                                    Delete               Running          Jul 05,2024 17:35 UTC+0800  

kubectl get cluster mycluster -n demo
>
NAME        CLUSTER-DEFINITION   VERSION                  TERMINATION-POLICY   STATUS    AGE
mycluster   milvus-2.3.2                                  Delete               Running   14m

Steps

Run the command below to delete a specified cluster.

kbcli
kubectl

kbcli cluster delete mycluster -n demo

If you want to delete a cluster and its all related resources, you can modify the termination policy to WipeOut, then delete the cluster.

kubectl patch -n demo cluster mycluster -p '{"spec":{"terminationPolicy":"WipeOut"}}' --type="merge"

kubectl delete -n demo cluster mycluster

Manage Milvus with KubeBlocks

Before you start​

Create a cluster​

Scale​

Before you start​

Steps​

Volume Expansion​

Before you start​

Steps​

Restart​

Stop/Start a cluster​

Stop a cluster​

Start a cluster​

Delete a cluster​

Termination policy​

Steps​

Before you start

Create a cluster

Scale

Before you start

Steps

Volume Expansion

Before you start

Steps

Restart

Stop/Start a cluster

Stop a cluster

Start a cluster

Delete a cluster

Termination policy

Steps