Kubespray 노드 확장(Scale) 후 kubectl TLS 에러 해결기 -

안녕하세요. 오늘은 Kubespray로 배포된 Kubernetes 클러스터에서 워커 노드를 추가(Scale-out)한 후 발생할 수 있는 인증서 관련 트러블슈팅사례를 공유합니다.

기존 마스터 1식, 워커 2식 구성에서 신규 노드 1식을 추가하는 과정에서 겪은 `kubectl exec` TLS 에러와 그 해결 방안을 정리했습니다.

1. kubectl exec 접속 불가

`ansible-playbook`의 `scale.yml`을 사용하여 `worker01` 노드를 성공적으로 추가했습니다. Pod 스케줄링 및 배포는 정상이었으나, 해당 노드에 위치한 Pod에 접속하려 할 때 아래와 같은 에러가 발생했습니다.

$ kubectl exec -it <pod_name> -- /bin/bash
Error from server: error dialing backend: remote error: tls: internal error

이 에러는 보통 API 서버와 노드의 Kubelet 간 통신 시 인증서(TLS) 문제가 있을 때 발생합니다.

2. Kubelet Server 인증서 누락 확인

신규 노드의 `/var/lib/kubelet/pki/` 디렉토리를 확인한 결과, 클라이언트 인증서는 존재했으나 서버 인증서인 `kubelet-server-current.pem` 파일이 생성되지 않은 것을 발견했습니다.

– 확인 결과 : `kubelet-client-current.pem` (존재)
`kubelet-server-current.pem` (누락)

인테스트 환경에서 해당 키를 강제로 삭제했을 때 동일한 에러가 재현되는 것을 확인했으며, 이는 Kubelet이 자신을 증명할 서버용 인증서를 발급받지 못했음을 의미합니다.

3. CSR(Certificate Signing Request) 수동 승인

쿠버네티스는 보안을 위해 신규 노드의 인증서 발급 요청을 관리자가 검토하도록 대기시킵니다. `Pending` 상태인 요청을 찾아 승인해 주면 해결됩니다.

① CSR 상태 확인

마스터 노드에서 아래 명령어로 대기 중인 인증서 요청이 있는지 확인합니다.

$ Kubectl get csr
NAME        AGE     SIGNERNAME                                    REQUESTOR                 REQUESTEDDURATION   CONDITION
csr-kdz94   7m55s   kubernetes.io/kubelet-serving                 system:node:worker01      <none>              Pending   
csr-n8767   40m     kubernetes.io/kubelet-serving                 system:node:worker01      <none>              Pending   
csr-pq2ww   25m     kubernetes.io/kubelet-serving                 system:node:worker01      <none>              Pending

`CONDITION`이 Pending으로 되어 있는 항목들이 보인다면, API 서버가 해당 노드의 인증서 발급을 기다리고 있는 상태입니다.

② CSR 승인 처리

아래 명령어를 사용하여 대기 중인 모든 요청을 일괄 승인합니다.

$ kubectl get csr -o name | xargs kubectl certificate approve

③ 결과 확인

승인 후 신규 노드의 `/var/lib/kubelet/pki/` 경로를 다시 확인하면 `kubelet-server-current.pem`이 생성된 것을 볼 수 있습니다. 이후 `kubectl exec`나 `kubectl logs` 명령어가 정상 작동합니다.

4. 왜 이런 절차가 필요했을까? (TLS Bootstrapping)

이 문제의 근본 원인은 쿠버네티스의 TLS Bootstrapping 메커니즘에 있습니다.

Kubelet은 API 서버에 요청을 보낼 때 쓰는 ‘클라이언트 인증서’와, API 서버가 Kubelet에 접근(exec, logs 등)할 때 쓰는 ‘서버 인증서’를 모두 가집니다. Kubespray 환경에서는 보안 강화를 위해 서버 인증서 발급 요청을 자동으로 승인하지 않는 설정이 많습니다. 공격자가 가짜 노드를 클러스터에 합류시켜 데이터를 가로채는 것을 방지하기 위함입니다.

해결의 핵심 따라서 노드 추가 작업 후에는 `kubectl get csr`을 통해 관리자가 명시적으로 Approve 해주는 과정이 필요할 수 있습니다.

5. 마치며

Kubespray로 노드를 확장할 때 단순히 플레이북 실행만 끝내지 말고, 신규 노드의 인증서가 정상 발급되었는지 확인하는 습관이 필요합니다. 만약 `exec`나 `logs`에서 TLS 에러가 발생한다면 가장 먼저 CSR 상태를 점검해 보시기 바랍니다.

공부가 부족해 삽질이라 생각했던 과정이 알고 보니 쿠버네티스의 보안 메커니즘을 경험하는 과정이었네요. 같은 문제를 겪는 분들께 도움이 되었으면 합니다. 평안한 저녁 보내세요.

참고 블로그 : https://cloudev.tistory.com/entry/Kubernetes-CSR-CertificateSigningRequest-%EB%A6%AC%EC%86%8C%EC%8A%A4

Kubespray 노드 확장(Scale) 후 kubectl TLS 에러 해결기