Prologue
언제나처럼 kubectl
을 사용하려는데 다음과 같은 에러가 발생했습니다. '어이쿠 인증서 문제네...' 하면서 생각해보니, 이 클러스터를 구축해둔지 벌써 1년이라는 시간이 지났더군요. 갱신을 한 번은 해줬어야 했는데 깜빡하고 있던게 화근이었습니다.
Unable to authenticate the request due to an error: x509: certificate has expired or is not yet valid
인증서 만료일 확인
$ cd /etc/kubernetes/pki
$ openssl x509 -in apiserver.crt -noout -dates
$ openssl x509 -in apiserver-kubelet-client.crt -noout -dates
$ openssl x509 -in apiserver-etcd-client.crt -noout -dates
notAfter
를 보면 이 인증서가 언제 만료되는지 알 수 있습니다. 문제는 전부 만료가 돼서, 전부 갱신해줘야 하는 상황이었는데, 어떻게 해줘야할지 좀처럼 감이 안 잡혀 구글링을 해봤습니다.
다행히도 이미 이런 일을 겪으셨던 선배님께서 블로그에 절차를 작성해두셔서 이를 잘 따라갈 수 있었습니다. 유감스럽게도 마지막 부분에선 에러가 발생해서 추가적인 절차가 필요했습니다만, 어쩌면 제가 완전히 똑같이 따라한게 아니라서 생긴 오류일 수도 있을 것 같습니다. 잘 정리해주셨던 원본 블로그의 포스트를 다음처럼 소개합니다.
https://kangwoo.github.io/devops/kubernetes/apiserver-kubelet-client-certs-expired/
저는 선배님께서 잘 정리해두신 내용에 몇가지 설명을 더 곁들여 작성해보았습니다.
본 포스트는 kubeadm
을 활용해 클러스터를 구축했을 때 해결 방법을 담고 있습니다.
(구)인증서 백업
혹시 모를 상황에 대비하기 위해 일단 예전 인증서를 백업해두겠습니다.
$ cd /etc/kubernetes/pki
$ sudo mkdir -p backup
$ sudo mv apiserver.key backup/apiserver.key.old
$ sudo mv apiserver.crt backup/apiserver.crt.old
$ sudo mv apiserver-kubelet-client.key backup/apiserver-kubelet-client.key.old
$ sudo mv apiserver-kubelet-client.crt backup/apiserver-kubelet-client.crt.old
$ sudo mv apiserver-etcd-client.key backup/apiserver-etcd-client.key.old
$ sudo mv apiserver-etcd-client.crt backup/apiserver-etcd-client.crt.old
(새)인증서 발급
kubeadm
을 이용해 클러스터를 구축했다면 인증서 발급이 굉장히 쉽습니다.
# 192.168.x.x는 본인의 master 노드 ip로 넣어주시면 됩니다.
$ sudo kubeadm init phase certs apiserver --apiserver-cert-extra-sans '192.168.x.x'
$ sudo kubeadm init phase certs apiserver-kubelet-client
$ sudo kubeadm init phase certs apiserver-etcd-client
(구) config 파일 백업
config 파일은 /etc/kubernetes
에 위치한 admin.conf
, kubelet.conf
, controller-manager.conf
, scheduler.conf
을 의미합니다. 각 config 파일을 살펴보면 certificate-authority-data
와 client-certificate-data
필드가 있습니다. 우리가 새 인증서를 사용하게 되었기 때문에 이 필드도 변해야 합니다.
방금 (구)인증서를 백업하듯 예전 config 파일도 백업하겠습니다.
$ cd /etc/kubernetes
$ sudo mkdir -p backup
$ sudo mv admin.conf backup/admin.conf.old
$ sudo mv kubelet.conf backup/kubelet.conf.old
$ sudo mv controller-manager.conf backup/controller-manager.conf.old
$ sudo mv scheduler.conf backup/scheduler.conf.old
(새) config 파일 생성
이 역시 kubeadm
을 이용했다면 굉장히 쉽게 진행할 수 있는 과정입니다.
$ sudo kubeadm init phase kubeconfig admin
$ sudo kubeadm init phase kubeconfig kubelet
$ sudo kubeadm init phase kubeconfig controller-manager
$ sudo kubeadm init phase kubeconfig scheduler
Kubernetes 컴포넌트 재시작
업데이트한 인증서와 config 파일을 적용하기 위해 apiserver
, controller-manager
, scheduler
, kubelet
을 재시작합니다. 제가 참고한 블로그 덕분에 더 편리한 방법을 배우게 되었습니다.
$ sudo kill -s SIGHUP $(pidof kube-apiserver)
$ sudo kill -s SIGHUP $(pidof kube-controller-manager)
$ sudo kill -s SIGHUP $(pidof kube-scheduler)
$ sudo systemctl restart kubelet
주의 사항
우선 루트 계정에서 작업하는 것을 지양하는 것이 좋습니다. 번번히 sudo
를 붙여가며 작업을 한 까닭은 sudo su
를 해서 루트 계정으로 이동하는 경우, /root/.kube/config
에 데이터가 없으면 정상적으로 명령이 수행되지 않았기 때문입니다. 따라서 뭔가 제대로 수행되지 않는 것 같다! 싶으면 계정을 확인해보시길 바랍니다.
cp
명령 대신 mv
명령을 사용한 이유는 cp
명령을 사용했을 때는 원본 데이터가 남기 때문입니다. 기존 데이터가 남아 있으면 위 명령들을 수행했을 때 데이터가 새로 생성되지 않습니다. 주의하셔야 합니다.
만약 이 절차대로 수행하지 않았다면 어쩌면 에러를 맞이하게 되실 수도 있습니다. 제 경우 node $XXX not found
를 보게 됐는데요. 이 부분은 위 절차를 순서대로 잘 따라가게 되니 잘 해결 되었습니다.
마무리
여기까지 따라오시느라 고생 많으셨습니다. 만약 이 글이 도움이 되셨다면 글 좌측 하단의 하트❤를 눌러주시면 감사하겠습니다.
혹시라도 글에 이상이 있거나, 이해가 가지 않으시는 부분, 또는 추가적으로 궁금하신 내용이 있다면 주저 마시고 댓글💬을 남겨주세요! 빠른 시간 안에 답변을 드리겠습니다 😊
참고
'IT > Kubernetes' 카테고리의 다른 글
[Kubernetes] Helm Chart 만들기 (2) | 2021.06.18 |
---|---|
[Kubernetes] kubectx를 활용해서 멀티 클러스터를 관리하자 (2) | 2021.06.13 |
[Kubernetes] Helm으로 Statefulset의 spec upgrade가 안 되는 경우 (0) | 2021.05.12 |
[Kubernetes] CKA (Certified Kubernetes Administrator) (v1.19 기준) 시험 후기 (12) | 2021.01.16 |
[Kubernetes] Kubernetes와 Docker (Kubernetes v1.20) (0) | 2020.12.22 |