CrashLoopBackoff when PersistentVolume=true
- Dominant language
- Mustache
- Stars
- 55
- Forks
- 68
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
I am getting CrashLoopBackoff of a CouchDB pod, when I am deploying it with persistenVolume.
values for Helm Chart
```
clusterSize: '1'
persistentVolume:
enabled: 'true'
storageClass: 'efs-sc-couchdb'
couchdbConfig:
couchdb:
uuid:
```
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: efs-sc-couchdb
namespace:
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-
directoryPerms: "760"
```
**Version of Helm and Kubernetes**:
Chart version: couchdb-4.4.1
App version: 3.3.2
EKS K8s Cluster version: 1.25
**What happened**:
✗ kubectl get pod couchdb-beta-couchdb-0
NAME READY STATUS RESTARTS AGE
couchdb-beta-couchdb-0 0/1 CrashLoopBackOff 8 (3m48s ago) 19m
**What you expected to happen**:
✗ kubectl get pod couchdb-beta-couchdb-0
NAME READY STATUS RESTARTS AGE
couchdb-beta-couchdb-0 1/1 Running
**How to reproduce it** (as minimally and precisely as possible):
helm upgrade --install couchdb-beta couchdb/couchdb --set clusterSize=1 --set persistentVolume.enabled=true --set persistentVolume.storageClass=efs-sc-couchdb --set persistenVolume.accessModes=ReadWriteOnce --set couchdbConfig.couchdb.uuid=$(curl https://www.uuidgenerator.net/api/version4 2>/dev/null | tr -d -)
✗ kubectl logs couchdb-beta-couchdb-0 -c couchdb
✗ kubectl logs couchdb-beta-couchdb-0 -c init-copy
total 8
-rw-r--r-- 1 root root 101 Jun 15 09:36 seedlist.ini
-rw-r--r-- 1 root root 106 Jun 15 09:36 chart.ini
✗ kubectl get pvc database-storage-couchdb-beta-couchdb-0
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
database-storage-couchdb-beta-couchdb-0 Bound pvc-5fb45da0-1df7-4a5b-ae9z-6f797b210aex 10Gi RWO efs-sc-couchdb 19h
**Anything else we need to know**:
All infrastructure is based on AWS service like EKS EFS...
When I deploy it with persistentVolume.enabled=false, everything seems to be ok.
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce the deployment with the supplied Helm command, then inspect the couchdb and init-copy container logs and the persistent-volume settings used by chart version 4.4.1. Compare the pod behavior with persistentVolume.enabled set to false; done means the CouchDB pod reaches 1/1 Running with the EFS-backed volume enabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, helm, kubernetes
- Domain
- databases, devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100