클러스터 인증서 관리

결론부터

클러스터 인증서는 만료 전에 확인·갱신하고, 사용하는 컴포넌트가 새 인증서를 읽도록 해야 한다.

클러스터 내부 통신도 인증서에 의존한다. 만료일 조회부터 kubeadm 갱신, 컴포넌트 재시작과 kubeconfig 반영까지 확인한다. 인증서와 개인 키의 차이는 사용자 인증에서, 어느 연결에 어느 인증서가 쓰이는지와 갱신 뒤 재시작이 필요한 이유는 컴포넌트 인증서에서 설명한다.

인증서 관리

클러스터 안의 모든 대화는 양쪽이 서로 인증서를 내미는 mTLS로 이뤄진다 (mutual TLS·상호 TLS) — kubelet이 apiserver를 부를 때도, apiserver가 etcd를 읽을 때도 그렇다. 그 인증서에 만료일이 있으니, 인증서가 만료되면 루프 전체가 한꺼번에 멈춘다. 증상은 “갑자기 kubectl이 전부 안 된다”로 나타나 원인을 짐작하기 어렵다.

sudo kubeadm certs check-expiration
# CERTIFICATE              EXPIRES                RESIDUAL TIME
# admin.conf               Aug 04, 2027           364d
# apiserver                Aug 04, 2027           364d
# apiserver-etcd-client    Aug 04, 2027           364d
# ...
# CERTIFICATE AUTHORITY    EXPIRES                RESIDUAL TIME
# ca                       Aug 02, 2035           9y

sudo kubeadm certs renew all                    # 전부 갱신
sudo kubeadm certs renew apiserver              # 하나만

apiserver·admin.conf 같은 갱신 대상 이름이 기억나지 않으면 문서를 찾기 전에 kubeadm certs renew -h를 친다. 하위 명령 목록이 곧 대상 이름이고, check-expiration 출력의 첫 컬럼과도 같다.

클라이언트 인증서는 1년, CA(Certificate Authority·인증 기관 — 다른 인증서에 서명하는 루트)는 10년 유효하다
kubeadm upgrade를 하면 인증서가 자동 갱신된다 — 매년 업그레이드하면 신경 쓸 일이 없다
갱신 후 컨트롤 플레인 스태틱 Pod을 재시작해야 반영된다

kubeadm certs renew 이후 스태틱 Pod 재시작과 kubeconfig 재복사가 모두 필요한 이유

요약

클러스터 인증서는 만료 전에 확인·갱신하고, 사용하는 컴포넌트가 새 인증서를 읽도록 해야 한다.
kubeadm certs check-expiration으로 만료일을 확인한다.
갱신한 파일과 컴포넌트가 실제로 사용하는 인증서가 일치하는지 확인한다.