skills/kubeblocks-volume-expansion/SKILL.md
Expand persistent volume storage for KubeBlocks database clusters via OpsRequest. Requires the StorageClass to support volume expansion (allowVolumeExpansion=true). Use when the user needs more disk space, wants to increase storage, expand volumes, or resize PVCs. NOT for changing CPU/memory (see vertical-scaling) or adding more replicas (see horizontal-scaling). Note that volume shrinking is not supported by Kubernetes.
npx skillsauth add apecloud/kubeblocks-skills kubeblocks-volume-expansionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Volume expansion increases the persistent storage allocated to a KubeBlocks database cluster. This is an online operation — pods continue running while the underlying PVCs are resized.
Official docs: https://kubeblocks.io/docs/preview/user_docs/kubeblocks-for-mysql/cluster-management/expand-the-storage-of-a-mysql-cluster Full doc index: https://kubeblocks.io/llms-full.txt
Important: Volumes can only be expanded, never shrunk. Plan storage capacity carefully.
The StorageClass must support volume expansion. Check:
kubectl get sc
Look for ALLOWVOLUMEEXPANSION = true in the output. If it shows false, the StorageClass does not support expansion and must be reconfigured by a cluster administrator:
kubectl get sc <storage-class-name> -o jsonpath='{.allowVolumeExpansion}'
Before proceeding, verify the cluster is healthy and no other operation is running:
# Cluster must be Running
kubectl get cluster <cluster-name> -n <namespace> -o jsonpath='{.status.phase}'
# No pending OpsRequests
kubectl get opsrequest -n <namespace> -l app.kubernetes.io/instance=<cluster-name> --field-selector=status.phase!=Succeed
If the cluster is not Running or has a pending OpsRequest, wait for it to complete before proceeding.
Check current PVC sizes and StorageClass expansion support:
# Current PVC sizes
kubectl get pvc -n <namespace> -l app.kubernetes.io/instance=<cluster-name>
# StorageClass supports expansion
kubectl get sc -o custom-columns='NAME:.metadata.name,EXPANSION:.allowVolumeExpansion'
- [ ] Step 1: Check current storage and StorageClass
- [ ] Step 2: Apply volume expansion OpsRequest
- [ ] Step 3: Monitor the operation
- [ ] Step 4: Verify new storage size
Check current PVC sizes:
kubectl get pvc -n <namespace> -l app.kubernetes.io/instance=<cluster-name>
Check the cluster spec for storage configuration:
kubectl get cluster <cluster-name> -n <namespace> -o yaml | grep -A 6 volumeClaimTemplates
Verify StorageClass supports expansion:
kubectl get sc -o custom-columns='NAME:.metadata.name,PROVISIONER:.provisioner,EXPANSION:.allowVolumeExpansion'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-<cluster-name>
namespace: <namespace>
spec:
clusterName: <cluster-name>
type: VolumeExpansion
volumeExpansion:
- componentName: <component-name>
volumeClaimTemplates:
- name: <volume-name>
storage: "<new-size>"
| Addon | Volume Name | Description |
|-------|-----------|-------------|
| MySQL | data | Data directory |
| PostgreSQL | data | Data directory |
| Redis | data | Data directory |
| MongoDB | data | Data directory |
| Kafka | data | Data logs |
| Kafka | metadata | Metadata directory |
Before applying, validate with dry-run:
kubectl apply -f - --dry-run=server <<'EOF'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-mysql-cluster
namespace: default
spec:
clusterName: mysql-cluster
type: VolumeExpansion
volumeExpansion:
- componentName: mysql
volumeClaimTemplates:
- name: data
storage: "50Gi"
EOF
If dry-run reports errors, fix the YAML before proceeding.
kubectl apply -f - <<'EOF'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-mysql-cluster
namespace: default
spec:
clusterName: mysql-cluster
type: VolumeExpansion
volumeExpansion:
- componentName: mysql
volumeClaimTemplates:
- name: data
storage: "50Gi"
EOF
Before applying, validate with dry-run:
kubectl apply -f - --dry-run=server <<'EOF'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-pg-cluster
namespace: default
spec:
clusterName: pg-cluster
type: VolumeExpansion
volumeExpansion:
- componentName: postgresql
volumeClaimTemplates:
- name: data
storage: "100Gi"
EOF
If dry-run reports errors, fix the YAML before proceeding.
kubectl apply -f - <<'EOF'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-pg-cluster
namespace: default
spec:
clusterName: pg-cluster
type: VolumeExpansion
volumeExpansion:
- componentName: postgresql
volumeClaimTemplates:
- name: data
storage: "100Gi"
EOF
Before applying, validate with dry-run:
kubectl apply -f - --dry-run=server <<'EOF'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-kafka-cluster
namespace: default
spec:
clusterName: kafka-cluster
type: VolumeExpansion
volumeExpansion:
- componentName: kafka-combine
volumeClaimTemplates:
- name: data
storage: "100Gi"
- name: metadata
storage: "20Gi"
EOF
If dry-run reports errors, fix the YAML before proceeding.
kubectl apply -f - <<'EOF'
apiVersion: apps.kubeblocks.io/v1beta1
kind: OpsRequest
metadata:
name: volumeexpand-kafka-cluster
namespace: default
spec:
clusterName: kafka-cluster
type: VolumeExpansion
volumeExpansion:
- componentName: kafka-combine
volumeClaimTemplates:
- name: data
storage: "100Gi"
- name: metadata
storage: "20Gi"
EOF
spec:
volumeExpansion:
- componentName: kafka-broker
volumeClaimTemplates:
- name: data
storage: "200Gi"
- componentName: kafka-controller
volumeClaimTemplates:
- name: data
storage: "50Gi"
Watch the OpsRequest:
kubectl get ops volumeexpand-<cluster-name> -n <namespace> -w
Success condition:
.status.phase=Succeed| Typical: 1-5min | If stuck >10min:kubectl describe ops volumeexpand-<cluster-name> -n <namespace>
Expected progression: Pending → Running → Succeed.
Watch PVC resize:
kubectl get pvc -n <namespace> -l app.kubernetes.io/instance=<cluster-name> -w
After the OpsRequest succeeds, confirm PVC sizes:
kubectl get pvc -n <namespace> -l app.kubernetes.io/instance=<cluster-name>
Check the CAPACITY column reflects the new size.
Also verify from inside a pod:
kubectl exec -it <cluster-name>-<component>-0 -n <namespace> -- df -h /data
OpsRequest fails with "volume expansion not supported":
kubectl get sc <name> -o jsonpath='{.allowVolumeExpansion}'kubectl patch sc <name> -p '{"allowVolumeExpansion": true}'PVC resize stuck in FileSystemResizePending:
kubectl describe pvc <pvc-name> -n <namespace>Cannot shrink volumes:
Expansion for log or metadata volumes:
metadata volume). Use the correct volume name from the reference table above.For complete volume name reference across all addons, additional OpsRequest examples (Redis, MongoDB, Elasticsearch, Milvus), and StorageClass expansion support by cloud provider, see reference.md.
For general agent safety conventions (dry-run, status confirmation, production protection), see safety-patterns.md.
data-ai
Scale CPU and memory resources for KubeBlocks database clusters via OpsRequest (vertical scaling). Supports in-place updates when the feature gate is enabled. Use when the user wants to change, increase, decrease, resize, or adjust CPU or memory resources of a database cluster. NOT for adding/removing replicas or shards (see horizontal-scaling) or expanding disk storage (see volume-expansion).
data-ai
Upgrade the KubeBlocks operator itself via Helm. Covers update operator, upgrade to v1.0, update kubeblocks version, and CRD updates. Use when the user wants to upgrade KubeBlocks, update the operator, or upgrade to a new KubeBlocks release. NOT for upgrading database engine versions (see minor-version-upgrade).
development
Diagnostic guide for KubeBlocks-managed database clusters. Use when the user reports troubleshoot, debug, diagnose, not working, error, failed, stuck, CrashLoopBackOff, cluster exception, or similar problems with their database cluster. This skill guides the agent through diagnostic steps — it does NOT perform actions.
data-ai
Perform planned primary-secondary switchover for KubeBlocks database clusters via OpsRequest. Promotes a replica to primary with minimal downtime. Use when the user wants to promote a replica, switch primary, change leader, perform a planned failover, or do maintenance on the current primary node. NOT for unplanned failover recovery (handled automatically by HA middleware like Patroni, Orchestrator, or Sentinel) or restarting all pods (see kubeblocks-cluster-lifecycle).