CDP Data Services(ECS) 1.5.2 SP2 업그레이드 중 vault-0 파드가 ContainerCreating 에서 멈춘 사례와, 재기동 절차에서 Vault unseal 을 언제 하는지, 재기동 뒤 파드가 Pending 으로 남을 때의 확인 순서를 정리한다.
kubectl describe pod vault-0 -n vault-system # Events 확인
kubectl get pvc -n vault-system
kubectl get events -n vault-system --sort-by=.lastTimestamp
kubectl get pods -n longhorn-system
이 사례의 이벤트는 FailedAttachVolume ... engine image longhorn-engine:v1.4.3 is not deployed on at least one of the replicas' nodes or the node that the volume is going to attach to 였고, longhorn-system 에서 engine-image-ei-* 파드 일부가 0/1, helm-install-longhorn 이 CrashLoopBackOff 였다. Vault 는 피해자이고 원인은 Longhorn 이다. 같은 노드의 다른 볼륨(prometheus, alertmanager) 도 no Pending workload pods for volume ... to be mounted 로 mount 단계에서 실패한다.
kubectl get pods -n longhorn-system -o wide | grep engine-image
kubectl describe pod <engine-image 파드> -n longhorn-system | tail -30
kubectl logs <helm-install-longhorn 파드> -n longhorn-system --tail=80
kubectl get engineimages -n longhorn-system
kubectl get nodes.longhorn.io -n longhorn-system
복구는 canal 과 Longhorn DaemonSet 을 롤링 재시작해 엔진 이미지 파드를 전부 1/1 로 만든 뒤 멈춘 StatefulSet 파드를 지워 재생성하는 순서다.
kubectl rollout restart ds rke2-canal -n kube-system
# canal 이 Running 된 뒤
kubectl rollout restart ds longhorn-manager -n longhorn-system
kubectl rollout restart ds longhorn-csi-plugin -n longhorn-system
kubectl rollout restart ds engine-image-ei-<id> -n longhorn-system
# 약 10분 대기
kubectl get pods -n longhorn-system | grep engine-image # 전부 1/1
kubectl get engineimages -n longhorn-system # deployed
kubectl delete pod vault-0 -n vault-system
kubectl delete pod prometheus-infra-prometheus-operator-prometheus-0 -n infra-prometheus
전부 Running 이 되면 CM 에서 업그레이드를 Resume 한다. 특정 노드에서 엔진 이미지 파드가 계속 0/1 이면 그 노드를 리부트하는 것이 확실하다. replica 가 1개뿐인 볼륨이 detached 로 남으면 Longhorn UI 에서 워크로드를 0 으로 스케일 다운했다가 원래대로 돌린다.
Vault 는 재시작·중지되면 다시 sealed 상태가 되므로 unseal 은 ECS 기동·재시작이 모두 끝난 뒤의 마지막 단계다.
kubectl get pods -n vault-system 으로 vault-0 을 본다.기동 후 자동으로 unseal 되는 경우도 있으므로 CM 헬스 체크에 Vault instance is sealed 경고가 뜨거나 vault 파드가 crash-loop 일 때만 수동으로 한다. Vault 는 Data Services 구성요소라 Base 클러스터만 재기동할 때는 해당하지 않는다. 롤링 재시작 중에도 ECS 서버는 항상 1대 이상 떠 있어야 한다.
cdp 네임스페이스의 dp-cadence-worker(비동기 워크플로 엔진) 가 CrashLoopBackOff 면 Vault 가 sealed 라 시크릿을 못 받는 경우가 흔하다.
CDE 잡·CAI 세션이 열리지 않고 kubectl get pods -A | grep -v Running 에 여러 네임스페이스의 파드가 Pending 이면 컨테이너가 죽은 것이 아니라 스케줄되지 못한 것이다.
kubectl describe pod <pending 파드> -n <ns> | tail -30 # Events
kubectl get nodes -o wide
kubectl describe nodes | grep -A5 -i "taint\|pressure"
kubectl get pvc -A | grep -v Bound
kubectl get pods -n longhorn-system | grep -v Running
kubectl describe resourcequota -A
Events 의 Insufficient cpu/memory 는 리소스 부족, pod has unbound immediate PersistentVolumeClaims 는 Longhorn 볼륨 미연결, untolerated taint {node.kubernetes.io/disk-pressure} 는 노드 디스크 압박이다. 루트 디스크가 80% 를 넘으면 kubelet 이 disk-pressure taint 를 걸어 신규 스케줄을 막는다. 특정 사용자 세션 하나만 CrashLoopBackOff 인 것은 별개 문제로 kubectl logs --previous 로 본다.