Kubeadm: apiserver 인증서가 만료되었을 때 인증서를 갱신하는 방법은 무엇입니까?

https://github.com/kubernetes/kubeadm/issues/206 의

@zalmanzhao 이 문제를 해결하셨습니까?

저는 1년 전에 kubeadm v1.9.3 클러스터를 생성했으며 지금까지 잘 작동하고 있었습니다. 오늘 하나의 배포를 업데이트하려고 갔고 인증서가 만료되어 API가 잠겨 있다는 것을 깨달았습니다. 나는조차 할 수 kubeadm alpha phase certs apiserver 내가 얻을 수 있기 때문에, failure loading apiserver certificate: the certificate has expired (kubeadm 버전은 현재 1.10.6 I 업그레이드 할부터).

추가 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 upgrade plan)가 되지 않는 것 같습니다.

[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 . 그래도 다시 시도해 보겠습니다.
뭔가 찾으면 이곳에 꼭 올리겠습니다...

1.8 이전 버전의 kubeadm을 사용 중이고 인증서 교체 #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. kubeadm config.yml 준비합니다.

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

1. 백업 인증서 및 conf 파일

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 컨테이너 ID를 찾고 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 : 정말 감사합니다. 잘 작동하고 있습니다.

서버를 재부팅할 필요가 없습니다.
다음 두 명령으로 kube 시스템 포드(apiserver, schduler, ...)를 다시 만드는 것으로 충분합니다.

systemctl 다시 시작 kubelet
for i in $(docker ps | egrep 'admin|controller|scheduler|api|fron|proxy' | rev | awk '{print $1}' | rev);
docker stop $i; 완료

1.13 클러스터에서도 이 문제를 처리해야 했습니다. 제 경우에는 인증서가 만료될 예정이었습니다.
또한 온프레미스에서 단일 master\control 인스턴스를 처리하므로 HA 설정 또는 AWS 세부 사항에 대해 걱정할 필요가 없습니다.
다른 사람들이 위에 포함했듯이 백 단계는 포함하지 않았습니다.

인증서가 만료되지 않았기 때문에 클러스터에는 계속 작업하고 싶은 워크로드가 이미 있었습니다.
현재로서는 etcd 인증서를 처리할 필요가 없었으므로 생략했습니다.

그래서 높은 수준에서

• 마스터에
  
  
  
  • 마스터에서 새 인증서 생성
  
  
  • 포함된 인증서로 새 kubeconfig 생성
  
  
  • 새 kubelet 인증서 생성 - 클라이언트 및 서버
  
  
  • 작업자 노드 kubelets에 대한 새 토큰 생성
  
  
• 작업자마다
  
  
  
  • 작업자를 먼저 마스터에서 배출
  
  
  • 작업자에 대한 ssh, kubelet 중지, 파일 제거 및 kubelet 다시 시작
  
  
  • 마스터에서 작업자의 코드를 해제합니다.
  
  
• 마지막에 마스터에서
  
  
  
  • 토큰 삭제
  
  

# 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 해당 단계를 게시

1.8 이전 버전의 kubeadm을 사용 중이고 인증서 교체 #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 와 같은 오류가 발생하고 kubectl get nodes 를 실행할 때 마스터 노드는 Not Ready 라고 보고합니다.

--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 인스턴스를 처리하므로 HA 설정 또는 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에서 동일한 문제가 있고 가이드에는 오류가 없지만 클러스터에 연결할 수 없고 토큰을 재발급할 수 없습니다(인증 실패).

kubeadm v1.9.x를 사용하여 생성된 k8s 클러스터는 v1.14.1 의 나이에 동일한 문제를 경험했습니다( apiserver-kubelet-client.crt 7월 2일에 만료됨) lol

인증서를 갱신하고 구성 파일을 재생성하고 간단한 3노드 클러스터를 다시 가져오려면 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 with Watson private은 k8에 의해 구동되며, 그 사실을 전혀 몰랐습니다.

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가 모두 포함되어 있지 않으며 대신 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 자동으로 인증서를 갱신합니다!

kubeadm v1.9.x를 사용하여 생성된 k8s 클러스터는 v1.14.1의 나이에 동일한 문제(apiserver-kubelet-client.crt가 7월 2일에 만료됨)를 경험했습니다.

1.13 이전 버전은 이미 지원되지 않습니다.
우리는 사용자들이 이 빠르게 움직이는 프로젝트를 따라갈 것을 강력히 권장합니다.

현재 LongTermSupport Working Group 에서 더 오랜 기간 동안 Kubernetes 버전을 지원하기 위한 논의가 진행 중이지만 프로세스를 설정하는 데 시간이 걸릴 수 있습니다.

@pmori 감사
kube 버전 1.13.6에서 작동

의견 및 기능 요청: 이 인증서 만료는 오늘 아침 Kubernetes 1.11.x 클러스터의 프로덕션 환경에서 발생했습니다. 우리는 위(및 링크)를 모두 시도했지만 수많은 오류가 발생했고 몇 시간 후에 큰 호스 클러스터에 완전히 갇힌 후 포기했습니다. 다행히도 Kubernetes 1.15로 업그레이드하고 새 클러스터를 구축하기까지 약 2주가 남았으므로 처음부터 새 1.15 클러스터를 만들고 모든 사용자 데이터를 복사하는 것으로 끝냈습니다.

이런 일이 일어나기 전에 경고가 있었으면 하는 바램입니다. 우리는 경고 없이 "믿을 수 없을 정도로 안정적인 클러스터"에서 "완전히 부서진 지옥 같은 악몽"으로 바뀌었고 아마도 최악의 가동 중지 시간을 가졌을 것입니다. 다행히 금요일 오후 서해안이어서 상대적으로 영향이 적었습니다.

위에서 논의한 모든 것과 연결된 모든 티켓에서
차이점은 언급되지 않았습니다. 인증서가 곧 만료될 때 경고 표시를 시작하십시오 . (예를 들어, kubectl을 사용하고 인증서가 몇 주 안에 만료될 예정이라면 알려주세요!).

불편을 끼쳐드려 죄송합니다. 일반적으로 운영자의 책임입니다.
만료에 대해 디스크의 인증서를 모니터링합니다. 그러나 나는 부족하다는 데 동의합니다.
모니터링이 용이하지 않아 문제가 발생할 수 있습니다. 추가한 이유 중 하나입니다.
kubeadm에서 인증서 만료를 확인하는 명령입니다. 보다
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

또한 1.15 kubeadm 이후에는 인증서가 자동으로 갱신됩니다.
업그레이드. 사용자가 더 자주 업그레이드하도록 권장합니다.
2019년 7월 20일 03:49에 "William Stein" [email protected]이 작성했습니다.

의견 및 기능 요청: 이 인증서 만료 날짜는 다음과 같습니다.
오늘 아침 Kubernetes 1.11.x 클러스터에서 프로덕션을 시작합니다. 우리는 시도했다
위의 모든 것(및 링크), 그러나 수많은 오류가 발생하여
몇 시간 동안 대형 호스 클러스터에 완전히 갇히게 됩니다. 다행스럽게도,
Kubernetes 1.15로 업그레이드하고 빌드하기까지 약 2주가 남았습니다.
새 클러스터) 그래서 우리는 처음부터 새로운 1.15 클러스터를 만들었습니다.
모든 사용자 데이터를 복사합니다.

이런 일이 일어나기 전에 경고가 있었으면 하는 바램입니다. 우리는 그냥
"믿을 수 없을 정도로 안정적인 클러스터"에서 "완전히 부서진 지옥 같은"
악몽"이라는 경고도 표시되지 않았고 아마도 사상 최악의 가동 중지 시간을 가졌을 것입니다.
다행히 금요일 오후 서해안이라 상대적으로
임팩트 있는.

위에서 논의한 모든 것과 연결된 모든 티켓에서 한 가지
그것은 대규모를 만들었을 것입니다
우리를 위한 차이점은 언급되지 않았습니다: 인증서가 있을 때 경고 표시 시작곧 만료됩니다 . (예: kubectl을 사용하고 인증서가
몇 주 안에 만료될 예정이니 알려주세요!).

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVEXG43VMVBW63LNMVX
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@neolit123 감사합니다. 귀하의 의견에 설명된 대로 향후 인증서 문제를 주기적으로 확인하기 위해 자체 모니터링 인프라에 무언가를 추가할 것입니다.

@danroliver Thx 답장을 보내
언급할 가치가 있는 한 가지 사항은 동일한 방식으로 갱신해야 하는 "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 버전일 수 있음)
CA 인증서( /etc/kubernetes/pki/ca.crt )를 다시 생성한 경우 토큰( kubectl -n kube-system get secret | grep token )에 이전 CA가 있을 수 있으므로 다시 생성해야 합니다. 문제가 있는 토큰에는 kube-proxy-token , coredns-token 되어 있어 클러스터 크리티컬 서비스가 K8s API로 인증할 수 없었습니다.
토큰을 재생성하려면 이전 토큰을 삭제하면 다시 생성됩니다.
PV Provisioner, Ingress Controllers, cert-manager 등과 같은 K8s API와 통신하는 모든 서비스도 마찬가지입니다.

이 훌륭한 단계별 과정에 감사드립니다. @danroliver! 이 프로세스가 다중 마스터 클러스터(베어메탈, 현재 1.11.1을 실행 중)에 어떻게 적용되고 다운타임 없이 적용되는지 궁금합니다. 내 인증서가 아직 만료되지 않았지만 그 일이 발생하기 전에 인증서를 재생성/갱신하는 방법을 배우려고 합니다.

안녕하세요 @kcronin님 , 멀티 마스터 구성으로 어떻게 해결하셨나요? --apiserver-advertise-address로 진행하는 방법을 모르겠습니다.하나가 아니라 3개의 IP를 가지고 있기 때문입니다.

감사 해요

@pmcgrath 마스터가 3개인 경우 각 마스터에 대해 단계를 반복해야 합니까? 또는 무엇입니까 . 사례

@SuleimanWA , CA가 재생성된 경우 admin.conf 및 CA 파일을 복사할 수 있습니다.
다른 모든 경우에는 모든 마스터에서 인증서(etcd, kubelet, 스케줄러 등)를 재생성하는 단계를 반복해야 합니다.

@anapsix
1.13.x 클러스터를 실행 중이고 kubeadm alpha certs renew all 를 실행하여 인증서를 갱신한 후 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이 생성한 것입니까 아니면 토큰을 어떻게 삭제할 수 있습니까?

-----업데이트-----
나는 그것이 비밀 그 자체라는 것을 알았다. 제 경우에는 kube-controller가 작동하지 않아 비밀이 자동 생성되지 않았습니다.

높은 버전 사용:

kubeadm 알파 인증서 모두 갱신

첫 번째 마스터 노드의 kubelet이 다운되면(systemctl stop kubelet) 다른 마스터 노드는 첫 번째 마스터 노드의 CA에 연결할 수 없습니다. 이로 인해 원래 마스터 노드의 kubelet이 다시 온라인 상태가 될 때까지 다음 메시지가 표시됩니다.

kubectl 가져오기 노드
서버 오류(InternalError): 서버 오류("")로 인해 요청이 성공하지 못했습니다(노드 가져오기).

원래 CA 노드의 kublet이 다운되는 동안 CA 역할을 다른 마스터 노드로 이전하는 방법이 있습니까?

@anapsix
1.13.x 클러스터를 실행 중이고 kubeadm alpha certs renew all 를 실행하여 인증서를 갱신한 후 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이 생성한 것입니까 아니면 토큰을 어떻게 삭제할 수 있습니까?

-----업데이트-----
나는 그것이 비밀 그 자체라는 것을 알았다. 제 경우에는 kube-controller가 작동하지 않아 비밀이 자동 생성되지 않았습니다.

안녕하세요, 저는 이 작업을 수행했지만 1.13 버전에서는 수행하지 않았습니다. 이미 해보셨다면 몇가지 여쭤봐도 될까요?
그래서 기본적으로 나는 할 것입니다 :
kubeadm alpha certs는 모두를 갱신합니다(마스터의 컨트롤 플레인 cert uber pki/ 폴더를 업데이트함).
kubeadm init phase kubeconfig를 실행하여 kube 구성 파일을 업데이트합니다. (마스터 및 작업자).
모든 노드에서 kubelet을 다시 시작하십시오.

여전히 토큰을 만들고 작업자 노드에서 조인을 실행해야 합니까? 가능하다면 수행한 단계를 공유할 수 있습니까?