Kubeadm: как обновить сертификат по истечении срока действия сертификата apiserver?

Дубликат https://github.com/kubernetes/kubeadm/issues/206.

@zalmanzhao Вам удалось решить эту проблему?

Я создал кластер kubeadm v1.9.3 чуть больше года назад, и все это время он работал нормально. Сегодня я пошел обновить одно развертывание и понял, что у меня заблокирован доступ к API, потому что срок действия сертификата истек. Я не могу даже kubeadm alpha phase certs apiserver , потому что получаю failure loading apiserver certificate: the certificate has expired (версия kubeadm сейчас 1.10.6 так как я хочу обновить).

Добавление insecure-skip-tls-verify: true к ~/.kube/config → clusters[0].cluser тоже не помогает - я вижу You must be logged in to the server (Unauthorized) при попытке kubectl get pods (https: // github. com / kubernetes / kubernetes / issues / 39767).

Кластер работает, но живет своей жизнью, пока не самоуничтожится или пока что-то не починится 😅 К сожалению, я не смог найти решение для моей ситуации в # 206, и мне интересно, как выйти из этого. Единственным релевантным материалом, который я смог найти, была запись в блоге «Как изменить просроченные сертификаты в кластере кубернетов» , которая на первый взгляд выглядела многообещающей. Однако в итоге он не подошел, потому что на моей главной машине не было папки /etc/kubernetes/ssl/ (только /etc/kubernetes/pki/ ) - либо у меня другая версия k8s, либо я просто удалил эту папку, не заметив этого.

@errordeveloper, не могли бы вы что-нибудь порекомендовать? Я бы хотел исправить ситуацию без kubeadm reset и восстановления полезной нагрузки.

@kachkaev Удалось ли вам обновить сертификаты без перезагрузки kubeadm?
Если да, поделитесь, у меня такая же проблема с k8s 1.7.4. И я не могу выполнить обновление (план обновления $ kubeadm), потому что снова появляется ошибка, сообщающая мне, что срок действия сертификата истек, и он не может перечислить мастера в моем кластере:

[ERROR APIServerHealth]: the API Server is unhealthy; /healthz didn't return "ok"
[ERROR MasterNodesReady]: couldn't list masters in cluster: Get https://172.31.18.88:6443/api/v1/nodes?labelSelector=node-role.kubernetes.io%2Fmaster%3D: x509: certificate has expired or is not yet valid

К сожалению, в конце концов я сдался. Решение состояло в том, чтобы создать новый кластер, восстановить всю полезную нагрузку на нем, переключить записи DNS и, наконец, удалить исходный кластер 😭 По крайней мере, не было простоев, потому что мне посчастливилось иметь исправные модули на старых k8 во время перехода.

Спасибо @kachkaev за ответ. Тем не менее, я попробую еще раз.
Если найду что-нибудь, обязательно опубликую здесь ...

Если вы используете версию kubeadm до 1.8, где, как я понимаю, была введена ротация сертификатов № 206 (как бета-функция ) или срок действия ваших сертификатов уже истек, вам необходимо вручную обновить свои сертификаты (или воссоздать кластер, который похоже, что некоторые (не только @kachkaev) в конечном итоге прибегают к помощи).

Вам нужно будет подключиться к главному узлу по SSH. Если вы используете kubeadm> = 1.8, перейдите к 2.

1. При необходимости обновите Kubeadm. Раньше был на 1.7.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Резервное копирование старых сертификатов и ключей apiserver, apiserver-kubelet-client и front-proxy-client.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Создайте новые сертификаты и ключи apiserver, apiserver-kubelet-client и front-proxy-client.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Резервное копирование старых файлов конфигурации

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Создайте новые файлы конфигурации.

Здесь есть важное замечание. Если вы используете AWS, вам нужно будет явно передать параметр --node-name в этом запросе. В противном случае вы получите сообщение об ошибке вида: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal в ваших журналах sudo journalctl -u kubelet --all | tail и главный узел сообщит, что это Not Ready когда вы запустите kubectl get nodes .

Обязательно замените значения, переданные в --apiserver-advertise-address и --node-name на правильные значения для вашей среды.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Убедитесь, что ваш kubectl ищет в нужном месте ваши файлы конфигурации.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Перезагрузите ваш главный узел

$ sudo /sbin/shutdown -r now

1. Повторно подключитесь к своему главному узлу, возьмите свой токен и убедитесь, что ваш главный узел «Готов». Скопируйте токен в буфер обмена. Он понадобится вам на следующем шаге.

$ kubectl get nodes
$ kubeadm token list

Если у вас нет действующего токена. Вы можете создать его с помощью:

$ kubeadm token create

Токен должен выглядеть примерно так: 6dihyb.d09sbgae8ph2atjw.

1. SSH в каждый из подчиненных узлов и переподключите их к главному

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Повторите шаг 9 для каждого соединительного узла. На главном узле вы можете убедиться, что все подчиненные узлы подключены и готовы:

$ kubectl get nodes

Надеюсь, это поможет вам стать @davidcomeyne.

Большое спасибо @danroliver !
Я обязательно попробую это и опубликую здесь свои выводы.

@danroliver Спасибо! Просто попробовал это на старом одноузловом кластере, сделал шаги до 7. Это сработало.

@danroliver У меня работал. Спасибо.

У меня не получилось, пришлось настраивать новый кластер. Но рад, что помог другим!

спасибо @danroliver . меня устраивает
и моя версия kubeadm - 1.8.5

Спасибо @danroliver за то, что собрал шаги. Пришлось сделать небольшие дополнения к вашим шагам. Мой кластер работает под управлением v1.9.3 и находится в частном центре обработки данных вне Интернета.

О Мастере

1. Приготовьте кубеадм config.yml .

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
  advertiseAddress: <master-ip>
kubernetesVersion: 1.9.3

1. Резервные копии сертификатов и файлов конфигурации

mkdir ~/conf-archive/
for f in `ls *.conf`;do mv $f ~/conf-archive/$f.old;done

mkdir ~/pki-archive
for f in `ls apiserver* front-*client*`;do mv $f ~/pki-archive/$f.old;done

1. Команды kubeadm на главном сервере имели --config config.yml например:

kubeadm alpha phase certs apiserver --config ./config.yml 
kubeadm alpha phase certs apiserver-kubelet-client --config ./config.yml 
kubeadm alpha phase certs front-proxy-client --config ./config.yml
kubeadm alpha phase kubeconfig all --config ./config.yml --node-name <master-node>
reboot

1. Создать токен

На миньонов

Мне пришлось переехать

mv /etc/kubernetes/pki/ca.crt ~/archive/
mv /etc/kubernetes/kubelet.conf ~/archive/
systemctl stop kubelet
kubeadm join --token=eeefff.55550009999b3333 --discovery-token-unsafe-skip-ca-verification <master-ip>:6443

Спасибо @danroliver! Только для моего одноузлового кластера было достаточно выполнить шаги 1-6 (без перезагрузки), а затем отправить SIGHUP на kube-apiserver . Просто нашел идентификатор контейнера с помощью docker ps и установил сигнал с помощью docker kill -s HUP <container id> .

Большое спасибо @danroliver! В нашем кластере с одним главным / несколькими рабочими было достаточно выполнения шагов с 1 по 7, нам не нужно было повторно подключать каждый рабочий узел к мастеру (что было самой болезненной частью).

Спасибо за эту замечательную пошаговую инструкцию, @danroliver! Мне интересно, как этот процесс может быть применен к кластеру с несколькими мастерами (голое железо, в настоящее время работает 1.11.1) и, желательно, без простоев. Срок действия моих сертификатов еще не истек, но я пытаюсь научиться восстанавливать / обновлять их до того, как это произойдет.

@kcronin
пожалуйста, взгляните на этот новый документ:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
надеюсь, это поможет.

@danroliver : Большое спасибо, все работает.

Перезагрузка серверов не требуется.
Достаточно воссоздать pod'ы kube-system (apiserver, schduler, ...) этими двумя командами:

systemctl перезапустить kubelet
для i в $ (docker ps | egrep 'admin | controller | scheduler | api | fron | proxy' | rev | awk '{print $ 1}' | rev);
docker stop $ i; сделано

Мне приходилось иметь дело с этим также в кластере 1.13, в моем случае срок действия сертификатов истекал так немного по-другому
Также работает с одним экземпляром master \ control в локальной среде, поэтому не нужно беспокоиться о настройке высокой доступности или особенностях AWS.
Не включили задние ступеньки, как другие ребята включили выше

Поскольку срок действия сертификатов не истек, в кластере уже были рабочие нагрузки, которые я хотел продолжить.
Мне также не приходилось иметь дело с сертификатами etcd в настоящее время, поэтому мы пропустили

Так что на высоком уровне мне пришлось

• О мастере
  
  
  
  • Сгенерировать новые сертификаты на мастере
  
  
  • Создавайте новые kubeconfigs со встроенными сертификатами
  
  
  • Создание новых сертификатов kubelet - клиент и сервер
  
  
  • Сгенерируйте новый токен для кубелетов рабочего узла
  
  
• За каждого работника
  
  
  
  • Слейте рабочий сначала на мастера
  
  
  • ssh рабочему, остановите кубелет, удалите файлы и перезапустите кубелет
  
  
  • Развязать рабочего на хозяине
  
  
• На хозяине в конце
  
  
  
  • Удалить токен
  
  

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

Давайте создадим новый токен для узлов, повторно присоединяющихся к кластеру (после перезапуска kubelet)

# On master
sudo kubeadm token create

Теперь для каждого рабочего - по одному

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh на рабочий узел

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

Вернуться к хозяину и расстегнуть рабочий

kubectl uncordon WORKER-NODE-NAME

После обновления всех воркеров - Удалить токен - истечет через 24 часа, но давайте избавимся от него.

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

@pmcgrath Спасибо, что опубликовали эти шаги. Мне удалось по ним проследить и обновить свои сертификаты, и получить рабочий кластер.

Если вы используете версию kubeadm до 1.8, где, как я понимаю, была введена ротация сертификатов № 206 (как бета-функция ) или срок действия ваших сертификатов уже истек, вам необходимо вручную обновить свои сертификаты (или воссоздать кластер, который похоже, что некоторые (не только @kachkaev) в конечном итоге прибегают к помощи).

Вам нужно будет подключиться к главному узлу по SSH. Если вы используете kubeadm> = 1.8, перейдите к 2.

1. Update Kubeadm, if needed. I was on 1.7 previously.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Backup old apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Generate new apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Backup old configuration files

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Generate new configuration files.

Здесь есть важное замечание. Если вы используете AWS, вам нужно будет явно передать параметр --node-name в этом запросе. В противном случае вы получите сообщение об ошибке вида: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal в ваших журналах sudo journalctl -u kubelet --all | tail и главный узел сообщит, что это Not Ready когда вы запустите kubectl get nodes .

Обязательно замените значения, переданные в --apiserver-advertise-address и --node-name на правильные значения для вашей среды.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Ensure that your `kubectl` is looking in the right place for your config files.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Reboot your master node

$ sudo /sbin/shutdown -r now

1. Reconnect to your master node and grab your token, and verify that your Master Node is "Ready". Copy the token to your clipboard. You will need it in the next step.

$ kubectl get nodes
$ kubeadm token list

Если у вас нет действующего токена. Вы можете создать его с помощью:

$ kubeadm token create

Токен должен выглядеть примерно так: 6dihyb.d09sbgae8ph2atjw.

1. SSH into each of the slave nodes and reconnect them to the master

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Repeat Step 9 for each connecting node. From the master node, you can verify that all slave nodes have connected and are ready with:

$ kubectl get nodes

Надеюсь, это поможет вам стать @davidcomeyne.

Это то, что мне нужно только для 1.14.2 .. любые подсказки как

Мне приходилось иметь дело с этим также в кластере 1.13, в моем случае срок действия сертификатов истекал так немного по-другому
Также работает с одним экземпляром master \ control в локальной среде, поэтому не нужно беспокоиться о настройке высокой доступности или особенностях AWS.
Не включили задние ступеньки, как другие ребята включили выше

Поскольку срок действия сертификатов не истек, в кластере уже были рабочие нагрузки, которые я хотел продолжить.
Мне также не приходилось иметь дело с сертификатами etcd в настоящее время, поэтому мы пропустили

Так что на высоком уровне мне пришлось

* On the master

  * Generate new certificates on the master
  * Generate new kubeconfigs with embedded certificates
  * Generate new kubelet certicates - client and server
  * Generate a new token for the worker node kubelets

* For each worker

  * Drain the worker first on the master
  * ssh to the worker, stop the kubelet, remove files and restart the kubelet
  * Uncordon the worker on the master

* On master at the end

  * Delete token

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

Давайте создадим новый токен для узлов, повторно присоединяющихся к кластеру (после перезапуска kubelet)

# On master
sudo kubeadm token create

Теперь для каждого рабочего - по одному

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh на рабочий узел

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

Вернуться к хозяину и расстегнуть рабочий

kubectl uncordon WORKER-NODE-NAME

После обновления всех воркеров - Удалить токен - истечет через 24 часа, но давайте избавимся от него.

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

Я знаю, что эта проблема закрыта, но у меня такая же проблема с 1.14.2, и в руководстве нет ошибок, но я не могу подключиться к кластеру и повторно выпустить токен (я получаю ошибку аутентификации)

Кластер k8s, созданный с использованием kubeadm v1.9.x, столкнулся с той же проблемой (срок действия apiserver-kubelet-client.crt истек 2 июля) в возрасте v1.14.1 lol.

Мне пришлось обратиться к 4 различным источникам, чтобы обновить сертификаты, восстановить файлы конфигурации и вернуть простой трехузловой кластер.

@danroliver дал очень хорошие и структурированные инструкции, очень близкие к приведенному ниже руководству от IBM.
[Обновление сертификатов кластера Kubernetes] от IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

ПРИМЕЧАНИЕ. IBM Financial Crimes Insight с Watson private работает на базе k8s, даже не подозревал об этом.

Проблема с шагами 3 и 5

Шаг 3 НЕ должен иметь фазы в команде

$ sudo kubeadm alpha certs renew apiserver
$ sudo kubeadm alpha certs renew apiserver-kubelet-client
$ sudo kubeadm alpha certs renew front-proxy-client

Шаг 5 следует использовать ниже, kubeadm alpha не имеет kubeconfig all, вместо этого используется этап инициализации kubeadm

# kubeadm init phase kubeconfig all
I0705 12:42:24.056152   32618 version.go:240] remote version is much newer: v1.15.0; falling back to: stable-1.14
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file

в 1.15 мы добавили лучшую документацию для продления сертификата:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Кроме того, после 1.15 kubeadm upgrade автоматически обновит сертификаты за вас!

Кластер k8s, созданный с использованием kubeadm v1.9.x, столкнулся с той же проблемой (apiserver-kubelet-client.crt истек 2 июля) в возрасте v1.14.1 lol

версии старше 1.13 уже не поддерживаются.
мы настоятельно рекомендуем пользователям не отставать от этого быстро развивающегося проекта.

в настоящее время в рабочей группе LongTermSupport ведутся дискуссии о том, чтобы версии кубернетов поддерживались в течение более длительных периодов времени, но создание процесса может занять некоторое время.

Спасибо @pmorie .
Работает для kube версии 1.13.6

Просто комментарий и запрос функции: этот срок действия сертификата поразил нас сегодня утром в производственной среде в нашем кластере Kubernetes 1.11.x. Мы пробовали все, что описано выше (и ссылки), но столкнулись с многочисленными ошибками и сдались через несколько часов, полностью застряв в большом кластере с шлангом. К счастью, до обновления до Kubernetes 1.15 (и создания нового кластера) оставалось около двух недель, поэтому мы просто создали новый кластер 1.15 с нуля и скопировали все наши пользовательские данные.

Я очень хотел бы, чтобы до этого было какое-то предупреждение. Мы просто без всякого предупреждения перешли от «невероятно стабильного кластера» к «полностью сломанному адскому кошмару», и, вероятно, у нас было самое худшее время простоя за всю историю. К счастью, это был полдень в пятницу на западном побережье, поэтому воздействие было относительно минимальным.

Из всего, что обсуждалось выше и во всех связанных билетах, единственное, что могло бы
разница для нас не упоминается: начните выводить предупреждение, когда срок действия сертификатов скоро истечет . (Например, если вы используете kubectl, и срок действия сертификата истекает через несколько недель, сообщите мне, пожалуйста!).

Извините за проблемы. Обычно это ответственность оператора.
для отслеживания срока действия сертификатов на диске. Но я согласен с тем, что недостаток
простого мониторинга может вызвать проблемы. Это одна из причин, по которой мы добавили
команда для проверки истечения срока действия сертификата в kubeadm. Видеть
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Также обратите внимание, что после 1.15 kubeadm будет автоматически обновлять сертификаты на
Обновить. Что также побуждает пользователей обновляться чаще.
20 июля 2019 г., 03:49, «Уильям Штайн» [email protected] написал:

Просто комментарий и запрос функции: этот срок действия сертификата поразил нас через
production на нашем кластере Kubernetes 1.11.x сегодня утром. Мы устали
все, что указано выше (и ссылки), но столкнулся с многочисленными ошибками, сдался после
несколько часов полностью застрял с большим скоплением из шланга. К счастью,
до обновления до Kubernetes 1.15 (и сборки
новый кластер), поэтому мы просто создали новый кластер 1.15 с нуля
и копирование всех наших пользовательских данных.

Я очень хотел бы, чтобы до этого было какое-то предупреждение. Мы только
из «невероятно стабильного кластера» превратился в «адский адский сломанный»
кошмар "без всякого предупреждения, и, вероятно, у нас были худшие простои за всю историю.
К счастью, это был полдень в пятницу на западном побережье, поэтому относительно минимально
впечатляющий.

Из всего, что обсуждалось выше и во всех связанных билетах, есть одно
это привело бы к массовому
разница для нас не упоминается: начните выводить предупреждение, когда сертификатыскоро истечет . (Например, если вы используете kubectl, а сертификат
истекает через несколько недель, скажите, пожалуйста!).

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKKYY3PNVWWK3TULXWORLV2BFHKKYY3PNVWWK3TULXW2XG4DFWWK3TREFXW2HWG4DFWWGV2XW2HW03DVMW3DHWB08B08B08B08
или отключить поток
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@ neolit123 Спасибо; мы добавим что-то в нашу собственную инфраструктуру мониторинга, чтобы периодически проверять предстоящие проблемы с сертификатами, как описано в вашем комментарии.

@danroliver Спасибо большое за ответ. Это сэкономило мне много времени.
Стоит упомянуть и сертификаты, относящиеся к "etcd", которые следует продлевать таким же образом. Нет необходимости в перезагрузке конфигурации, поскольку она используется в файлах метаданных YAML в качестве ссылок.

Для Kubernetes v1.14 я считаю эту процедуру, предложенную @desdic, наиболее полезной:

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • резервное копирование и повторное создание всех сертификатов:
  
  

$ cd /etc/kubernetes/pki/
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} ~/
$ kubeadm init phase certs all --apiserver-advertise-address <IP>

• сделайте резервную копию и заново сгенерируйте все файлы kubeconfig:

$ cd /etc/kubernetes/
$ mv {admin.conf,controller-manager.conf,mv kubelet.conf,scheduler.conf} ~/
$ kubeadm init phase kubeconfig all
$ reboot

• скопировать новый admin.conf :

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

Для Kubernetes v1.14 я считаю эту процедуру наиболее полезной:

* https://stackoverflow.com/a/56334732/1147487

Я создал исправление после того, как исправил свой собственный кластер ... надеялся, что кто-то другой сможет его использовать

@danroliver дал очень хорошие и структурированные инструкции, очень близкие к приведенному ниже руководству от IBM.
[Обновление сертификатов кластера Kubernetes] от IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

Отлично! Интересно, когда это было опубликовано? Я определенно нашел бы это полезным, когда проходил через это.

Примечание о токенах в K8s 1.13.x (возможно, в других версиях K8s)
Если вы закончили повторное создание сертификата ЦС ( /etc/kubernetes/pki/ca.crt ), ваши токены (см. kubectl -n kube-system get secret | grep token ) могут иметь старый ЦС, и их придется сгенерировать заново. Среди проблемных токенов были kube-proxy-token , coredns-token в моем случае (и другие), из-за чего критически важные для кластера службы не могли пройти аутентификацию с помощью K8s API.
Чтобы регенерировать токены, удалите старые, и они будут созданы заново.
То же самое касается любых сервисов, использующих K8s API, таких как PV Provisioner, Ingress Controllers, cert-manager и т. Д.

Спасибо за эту замечательную пошаговую инструкцию, @danroliver! Мне интересно, как этот процесс может быть применен к кластеру с несколькими мастерами (голое железо, в настоящее время работает 1.11.1) и, желательно, без простоев. Срок действия моих сертификатов еще не истек, но я пытаюсь научиться восстанавливать / обновлять их до того, как это произойдет.

Привет @kcronin , как вы решили с конфигурацией с несколькими мастерами? Я не знаю, что делать с --apiserver-Advertise-addressтак как у меня 3 IP а не один.

Спасибо

@pmcgrath Если у меня 3 мастера, нужно ли повторять шаги для каждого мастера? или что такое. кейс

@SuleimanWA , вы можете скопировать admin.conf поверх, а также файл CA, если CA был регенерирован.
Для всего остального вы должны повторить шаги по регенерации сертификатов (для etcd, kubelet, scheduler и т. Д.) На каждом главном сервере.

@anapsix
Я использую кластер 1.13.x, и apiserver сообщает Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] после того, как я обновил сертификаты, запустив kubeadm alpha certs renew all .

Чтобы регенерировать токены, удалите старые, и они будут созданы заново.

Какой токен вы имеете в виду в данном случае? Этот токен сгенерирован kubeadm или как я могу удалить токен?

-----ОБНОВИТЬ-----
Я понял, что это секрет. В моем случае kube-controller не работал, поэтому секрет не был автоматически сгенерирован.

использование высокой версии ：

kubeadm alpha сертификаты продлить все

Когда кубелет первого главного узла не работает (systemctl stop kubelet), другие главные узлы не могут связаться с CA на первом главном узле. Это приводит к следующему сообщению, пока kubelet на исходном главном узле не вернется в режим онлайн:

kubectl получить узлы
Ошибка сервера (InternalError): ошибка на сервере ("") помешала выполнению запроса (получить узлы)

Есть ли способ передать роль ЦС другим главным узлам, пока кублет на исходном узле ЦС не работает?

@anapsix
Я использую кластер 1.13.x, и apiserver сообщает Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] после того, как я обновил сертификаты, запустив kubeadm alpha certs renew all .

Чтобы регенерировать токены, удалите старые, и они будут созданы заново.

Какой токен вы имеете в виду в данном случае? Этот токен сгенерирован kubeadm или как я могу удалить токен?

-----ОБНОВИТЬ-----
Я понял, что это секрет. В моем случае kube-controller не работал, поэтому секрет не был автоматически сгенерирован.

Привет, я выполнил эту задачу, но не в версии 1.13. Могу я кое-что спросить, если вы это уже сделали?
Итак, в основном я буду делать:
Сертификаты kubeadm alpha обновляют все (обновляют папку Cert uber pki / плоскости управления на Мастерах).
kubeadm init phase kubeconfig для обновления файлов конфигурации kube. (О Мастере и Рабочем).
Перезапустите кубелет на всех узлах.

Мне все еще нужно создавать токен и выполнять соединение на рабочих узлах? Если возможно, поделитесь выполненными шагами?