[recovery mode] Мне повезло: нужно обновить сертификаты k8s v1.12.3
Неделю назад мне подкинули задачу — обновить сертификаты k8s кластере. С одной стороны задача казалась достаточно тривиальной, НО нетривиальности добавляло моя неуверенность с k8s: до этого момента я пользовался кубером как сервисом и больше чем посмотреть на поды, удалить их написать deployment по шаблону делать ничего не доводилось. Уверенности добавляло наличие инструкции, но как выяснилось — она для версии v1.13, а у кластера для, которого требовалось реализовать эту задачу версия была 1.12.3. И тут началось…
3-го числа задачу с обновлением решил и захотелось написать инструкцию. Слышал, что в новых версиях сейчас эта задача решается чуть ли не одной командой, но для тех у кого оказался такой же винтаж как и у меня делюсь своим опытом.
Дано k8s кластер:
3 master ноды
3 etcd ноды
5 worker нод
kubectl get nodes
NAME STATUS ROLES AGE VERSION
product1-mvp-k8s-0001 Ready master 464d v1.12.3
product1-mvp-k8s-0002 Ready master 464d v1.12.3
product1-mvp-k8s-0003 Ready master 464d v1.12.3
product1-mvp-k8s-0007 Ready node 464d v1.12.3
product1-mvp-k8s-0008 Ready node 464d v1.12.3
product1-mvp-k8s-0009 Ready node 464d v1.12.3
product1-mvp-k8s-0010 Ready node 464d v1.12.3
product1-mvp-k8s-0011 Ready node 464d v1.12.3
Срок действия сертификата
echo | openssl s_client -showcerts -connect product1-mvp-k8s-0001:6443 -servername api 2>/dev/null | openssl x509 -noout -enddate
notAfter=Mar 4 00:39:56 2021 GMT
Поехали:
на всех MASTER нодах бэкапируем /etc/kubernetes
sudo mkdir backup; sudo cp -R /etc/kubernetes backup/ ; sudo tar -cvzf backup/pki_backup_`hostname`-`date +%Y%m%d`.tar.gz backup/kubernetes/Смотрим в структуру /etc/Kubernetes она будет примерно такой
ls -l
total 80
-rw------- 1 root root 5440 Mar 3 13:21 admin.conf
drwxr-xr-x 2 root root 4096 Aug 17 2020 audit-policy
-rw-r--r-- 1 root root 368 Mar 4 2020 calico-config.yml
-rw-r--r-- 1 root root 270 Mar 4 2020 calico-crb.yml
-rw-r--r-- 1 root root 341 Mar 4 2020 calico-cr.yml
-rw-r--r-- 1 root root 147 Mar 4 2020 calico-node-sa.yml
-rw-r--r-- 1 root root 6363 Mar 4 2020 calico-node.yml
-rw------- 1 root root 5472 Mar 3 13:21 controller-manager.conf
-rw-r--r-- 1 root root 3041 Aug 14 2020 kubeadm-config.v1alpha3.yaml
-rw------- 1 root root 5548 Mar 3 13:21 kubelet.conf
-rw-r--r-- 1 root root 1751 Mar 4 2020 kubelet.env
drwxr-xr-x 2 kube root 4096 Aug 14 2020 manifests
lrwxrwxrwx 1 root root 28 Mar 4 2020 node-kubeconfig.yaml -> /etc/kubernetes/kubelet.conf
-rw------- 1 root root 5420 Mar 3 13:21 scheduler.conf
drwxr-xr-x 3 kube root 4096 Mar 3 10:20 ssl
у меня все ключи в ssl, а не в pki, который будет нужен kubeadm, то он должен появиться, в своем случае я сделаю на него symlink
ln -s /etc/kubernetes/ssl /etc/kubernetes/pkiотыскиваем файл с конфигурацией кластера, в моем случае это был
kubeadm-config.v1alpha3.yaml
если такового вдруг нет то его возможно сгенерировать
kubectl get cm kubeadm-config -n kube-system -o yaml > /etc/kubernetes/kubeadm-config.yamlНачинаем перегенерацию сертификатов
kubeadm alpha phase certs apiserver --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml
[certificates] Using the existing apiserver certificate and key.
kubeadm alpha phase certs apiserver-kubelet-client
I0303 13:12:24.543254 40613 version.go:236] remote version is much newer: v1.20.4; falling back to: stable-1.12
[certificates] Using the existing apiserver-kubelet-client certificate and key.
kubeadm alpha phase certs front-proxy-client
I0303 13:12:35.660672 40989 version.go:236] remote version is much newer: v1.20.4; falling back to: stable-1.12
[certificates] Using the existing front-proxy-client certificate and key.
kubeadm alpha phase certs etcd-server --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [prod-uct1-mvp-k8s-0001 localhost] and IPs [127.0.0.1 ::1]
kubeadm alpha phase certs etcd-server --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml
[certificates] Using the existing etcd/server certificate and key.
kubeadm alpha phase certs etcd-healthcheck-client --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml
[certificates] Generated etcd/healthcheck-client certificate and key.
kubeadm alpha phase certs etcd-peer --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [product1-mvp-k8s-0001 localhost] and IPs [192.168.4.201 127.0.0.1 ::1]
проверяем выпущенные сертификаты на актуальность
find /etc/kubernetes/pki/ -name '*.crt' -exec openssl x509 -text -noout -in {} \; | grep -A2 Validity
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 2 10:29:44 2030 GMT
--
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 3 10:07:29 2022 GMT
--
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 3 10:07:52 2022 GMT
--
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 3 10:06:48 2022 GMT
--
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 2 10:29:44 2030 GMT
--
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 2 19:39:56 2022 GMT
--
Validity
Not Before: Mar 4 10:29:43 2020 GMT
Not After : Mar 2 10:29:43 2030 GMT
--
Validity
Not Before: Mar 4 10:29:43 2020 GMT
Not After : Mar 2 19:40:13 2022 GMT
--
Validity
Not Before: Mar 4 10:29:44 2020 GMT
Not After : Mar 2 19:36:38 2022 GMT
В процессе обновления сертификатов буду выпущены заново файлы admin.conf, controller-manager.conf, kubelet.conf, scheduler.conf а существующие переносим в подпапку tmp и генерим новые файлы
kubeadm alpha phase kubeconfig all --config /etc/kubernetes/kubeadm-config.v1alpha3.yaml
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"
перезапускаем все контейнеры и kubelet мастер ноды и проверяем что сервис kubelet завершил перезапуск
sudo systemctl stop kubelet; sudo docker stop $(docker ps -aq); sudo docker rm $(docker ps -aq); sudo systemctl start kubelet
systemctl status kubelet -l
● kubelet.service - Kubernetes Kubelet Server
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-03-03 14:00:22 MSK; 10s ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Process: 52998 ExecStartPre=/bin/mkdir -p /var/lib/kubelet/volume-plugins (code=exited, status=0/SUCCESS)
Main PID: 53001 (kubelet)
Memory: 51.2M
CGroup: /system.slice/kubelet.service
проверяем что master нода вернулась нормально в кластер и что доступна конфигурация namespace
kubectl get nodes
kubectl get ns
NAME STATUS AGE
default Active 464d
product1-mvp Active 318d
infra-logging Active 315d
infra-nginx-ingress Active 386d
kube-public Active 464d
kube-system Active 464d
pg Active 318dпроверяем что сертификат обновился
notAfter=Mar 3 07:40:43 2022 GMTОбновление сертификатов на master ноде 1 успешно завершено и повторяем туже процедуру на оставшихся 2-х.
Далее обновляем worker ноды:
удаляем или переименовываем kubelet.conf, необходимо для того чтобы при перезапуске подхватился файл bootstrap-kubelet.conf
cd /etc/kubernetes/
mv kubelet.conf kubelet.conf_oldвносим изменения в файл bootstrap-kubelet.conf если его нет, то создаем по шаблону внизу
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: | LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01ETX
server: https://192.168.4.201:6443
name: product1
contexts:
- context:
cluster: product1
user: tls-bootstrap-token-user
name: tls-bootstrap-token-user@product1
current-context: tls-bootstrap-token-user@product1
kind: Config
preferences: {}
users:
- name: tls-bootstrap-token-user
user:
token: fgz9qz.lujw0bwsdfhdsfjhgdsгде мы должны заменить
— certificate-authority-data — корневой сертификат центра сертификации PKI CA мастера, берем например из файла /etc/kubernetes/kubelet.conf на master ноде
— server: https://192.168.4.201:6443 — ip api сервера master ноды, или же виртуальный balance ip
token: fgz9qz.lujw0bwsdfhdsfjhgds — токен, который генерим на master ноде
kubeadm token create
перезапускаем kubelet и проверяем результат с master ноды, work нода должна , быть доступна ready в ресурсе кластера
systemctl restart kubelet
systemctl status kubelet -l
● kubelet.service - Kubernetes Kubelet Server
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-03-03 14:06:33 MSK; 11s ago
Docs: https://github.com/GoogleCloudPlatform/kubernetes
Process: 54615 ExecStartPre=/bin/mkdir -p /var/lib/kubelet/volume-plugins (code=exited, status=0/SUCCESS)
Main PID: 54621 (kubelet)
Memory: 52.1M
CGroup: /system.slice/kubelet.serviceпроверить, что сертификат обновлен — посмотреть на обновление сертификатов в папке
ls -las /var/lib/kubelet/pki/
total 24
4 -rw-------. 1 root root 1135 Mar 3 14:06 kubelet-client-2021-03-03-14-06-34.pem
0 lrwxrwxrwx. 1 root root 59 Mar 3 14:06 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2021-03-03-14-06-34.pem
4 -rw-r--r--. 1 root root 2267 Mar 2 10:40 kubelet.crt
4 -rw-------. 1 root root 1679 Mar 2 10:40 kubelet.keyПовторяем подобную процедуру на всех оставшихся work нодах.
Все мы обновили сертификаты на k8s кластере v1.12.3
