<env>-monitoring-platform 네임스페이스의 monitoring-cm-health-exporter 파드가 configtemplate-init 초기화 컨테이너에서 Back-off restarting 을 반복한다. 로그에는 Java 가 CDP 콘솔(console-cdp.apps.<domain>)에 접속하며 PKIX path building failed 를 낸다. 호스트 /etc/pki/ca-trust 에는 CA 가 등록되어 있지만 파드는 호스트 트러스트를 쓰지 않는다.
파드는 ConfigMap monitoring-sdx-ca-certs 의 cacerts 키(JKS)를 /etc/pki/java/cacerts 로 마운트한다. 이 JKS 에 콘솔 인증서를 서명한 CA 가 없으면 실패한다. 같은 이름의 ConfigMap 이 네임스페이스마다 따로 있으므로 kubectl get configmap --all-namespaces | grep sdx-ca-certs 로 대상 네임스페이스를 확인한다.
NS=<env>-monitoring-platform
openssl s_client -connect console-cdp.apps.<domain>:443 -showcerts 2>/dev/null \
| awk '/BEGIN CERTIFICATE/,/END CERTIFICATE/' > /tmp/cdp-ca.pem
openssl x509 -in /tmp/cdp-ca.pem -noout -subject -issuer -dates
kubectl get configmap monitoring-sdx-ca-certs -n ${NS} -o yaml > /tmp/monitoring-sdx-ca-certs.bak.yaml
kubectl get configmap monitoring-sdx-ca-certs -n ${NS} -o jsonpath='{.binaryData.cacerts}' | base64 -d > /tmp/pod-cacerts.jks
keytool -import -alias cdp-console-ca -file /tmp/cdp-ca.pem -keystore /tmp/pod-cacerts.jks -storepass ${JKS_PASSWORD} -noprompt
keytool -list -keystore /tmp/pod-cacerts.jks -storepass ${JKS_PASSWORD} | grep -i cdp
kubectl create configmap monitoring-sdx-ca-certs -n ${NS} --from-file=cacerts=/tmp/pod-cacerts.jks \
--dry-run=client -o yaml | kubectl apply -f -
kubectl rollout restart deployment monitoring-cm-health-exporter -n ${NS}
kubectl logs -f -n ${NS} $(kubectl get pod -n ${NS} -o name | grep monitoring-cm-health-exporter | head -1) -c configtemplate-init
Java 기본 cacerts 의 비밀번호는 changeit 이다. 체인 파일에 인증서가 여럿이면 -showcerts 결과에서 발급자(CA) 블록을 골라 넣는다. Issuer 표기가 조금 달라도 PEM 본문이 같으면 같은 인증서다.
근본 조치는 CM 의 Data Services 인증서(/opt/cloudera/ds/cert/dsfullchain.pem 등)에 CA 체인을 포함해 다시 등록하는 것이며, ConfigMap 직접 수정은 재배포 시 되돌아갈 수 있다.
AttachVolume.Attach failed for volume "pvc-..." : volume is already attached to another node 는 Longhorn 볼륨이 이전 노드에 붙어 있는 것으로, 이전 파드를 지우거나 Longhorn UI 에서 볼륨을 detach 하면 풀린다.