Describe the bug
When a service uses kompose.controller.type: statefulset together with kompose.volume.type: persistentVolumeClaim, kompose convert generates three artifacts for the same volume — two of which are redundant and cause a broken deployment:
volumeClaimTemplates inside the StatefulSet ✅ (correct — this is what the pod uses)- A standalone
<volume>-persistentvolumeclaim.yaml ❌ (orphaned — no consumer, stays Pending forever)
- A
spec.template.spec.volumes[] entry referencing the same volume ❌ (redundant — conflicts with volumeClaimTemplates)
The pod binds to the PVC auto-created by volumeClaimTemplates (e.g. pgdata-postgresql-0), while the standalone pgdata PVC sits Pending indefinitely with no consumer.
To Reproduce
Docker Compose service with these labels:
services:
postgresql:
image: postgres:13-alpine
volumes:
- pgdata:/var/lib/postgresql/data
labels:
kompose.controller.type: statefulset
kompose.volume.size: 1Gi
kompose.volume.type: persistentVolumeClaim
volumes:
pgdata:Run:
kompose convert -c -f docker-compose.yaml -o my-chart
Expected behavior
For a StatefulSet, the volume should be managed exclusively by volumeClaimTemplates. kompose should:
- Emit
volumeClaimTemplates in the StatefulSet ✅
- Not emit a standalone
pgdata-persistentvolumeclaim.yaml
- Not add a
spec.template.spec.volumes[] entry for the same volume (it is owned by volumeClaimTemplates)
Actual behavior
Three files/entries are generated for the same volume. Deploying to Kubernetes results in an orphaned PVC stuck in Pending and the StatefulSet failing due to the conflicting spec.volumes entry.
Workaround
# Remove redundant spec.volumes entry
yq -i 'del(.spec.template.spec.volumes[] | select(.name == "pgdata"))' \
my-chart/templates/postgresql-statefulset.yaml
# Delete orphaned standalone PVC manifest
rm -f my-chart/templates/pgdata-persistentvolumeclaim.yamlEnvironment
- kompose version:
1.38.0 (a8f5d1cbd)
- Kubernetes: kind cluster
- OS: Linux
Root cause (suspected)
ConfigVolumes in pkg/transformer/kubernetes/kubernetes.go unconditionally emits standalone PersistentVolumeClaim objects regardless of the target controller type. The StatefulSet path correctly generates volumeClaimTemplates, but ConfigVolumes is not suppressed for the StatefulSet case, leading to both artifacts being emitted simultaneously.
This was introduced with StatefulSet support in PR #1452.
Describe the bug
When a service uses
kompose.controller.type: statefulsettogether withkompose.volume.type: persistentVolumeClaim,kompose convertgenerates three artifacts for the same volume — two of which are redundant and cause a broken deployment:volumeClaimTemplatesinside the StatefulSet ✅ (correct — this is what the pod uses)<volume>-persistentvolumeclaim.yaml❌ (orphaned — no consumer, staysPendingforever)spec.template.spec.volumes[]entry referencing the same volume ❌ (redundant — conflicts withvolumeClaimTemplates)The pod binds to the PVC auto-created by
volumeClaimTemplates(e.g.pgdata-postgresql-0), while the standalonepgdataPVC sitsPendingindefinitely with no consumer.To Reproduce
Docker Compose service with these labels:
Run:
Expected behavior
For a StatefulSet, the volume should be managed exclusively by
volumeClaimTemplates. kompose should:volumeClaimTemplatesin the StatefulSet ✅pgdata-persistentvolumeclaim.yamlspec.template.spec.volumes[]entry for the same volume (it is owned byvolumeClaimTemplates)Actual behavior
Three files/entries are generated for the same volume. Deploying to Kubernetes results in an orphaned PVC stuck in
Pendingand the StatefulSet failing due to the conflictingspec.volumesentry.Workaround
Environment
1.38.0 (a8f5d1cbd)Root cause (suspected)
ConfigVolumesinpkg/transformer/kubernetes/kubernetes.gounconditionally emits standalonePersistentVolumeClaimobjects regardless of the target controller type. The StatefulSet path correctly generatesvolumeClaimTemplates, butConfigVolumesis not suppressed for the StatefulSet case, leading to both artifacts being emitted simultaneously.This was introduced with StatefulSet support in PR #1452.