Kubeadm: apiserver証明書の有効期限が切れたときに証明書を更新する方法は？

https://github.com/kubernetes/kubeadm/issues/206の複製

@zalmanzhaoこの問題を解決できましたか？

1年ほど前にkubeadm v1.9.3クラスターを作成しましたが、それはずっと正常に機能していました。 今日、1つのデプロイメントを更新しましたが、証明書の有効期限が切れたため、APIからロックアウトされていることに気付きました。 failure loading apiserver certificate: the certificate has expiredを取得するため、 kubeadm alpha phase certs apiserverすらできません（アップグレードしたいので、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で自分の状況の解決策を見つけることができず、どうやって抜け出すのか疑問に思っています。 私が掘り下げることができた唯一の関連資料は、 _ 'kubernetesクラスターでブログ投稿でした。これは一見有望に見えました。 ただし、マスターマシンに/etc/kubernetes/ssl/フォルダーがなかったため（ /etc/kubernetes/pki/ ）、最終的には収まりません/etc/kubernetes/ssl/た。別のk8sバージョンを使用しているか、気付かずにそのフォルダーを削除しただけです。

@errordeveloper何かお勧めしてkubeadm resetとペイロードの再作成なしで問題を修正したいと思います。

@kachkaev kubeadmをリセットせずに証明書を更新することに運がありましたか？
もしそうなら、共有してください、私はここでk8s1.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に正常なポッドをインストールできたので、少なくともダウンタイムはありませんでした。

返信してくれてありがとう
何か見つけたら、必ずここに投稿します...

1.8より前のバージョンのkubeadmを使用していて、証明書ローテーション＃206が導入されている（ベータ機能として）か、証明書の有効期限が切れていると理解している場合は、証明書を手動で更新する（またはクラスターを再作成する）必要があります。一部（@kachkaevだけでなく）が（@ 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 ：ありがとうございました。動作しています。

サーバーを再起動する必要はありません。
次の2つのコマンドで、kubeシステムポッド（apiserver、schdulerなど）を再作成するだけで十分です。

systemctl restart kubelet
for i in $（docker ps | egrep'admin | controller | scheduler | api | fron | proxy '| rev | awk' {print $ 1} '| rev）;
docker stop $ iを実行します。 終わり

1.13クラスターでもこれに対処する必要がありました。私の場合、証明書の有効期限が近づいていたため、わずかに異なります。
また、オンプレミスで単一のマスター/コントロールインスタンスを処理するため、HAのセットアップやAWSの詳細について心配する必要はありませんでした
他の人が上に含めたように、バックステップを含めていません

証明書の有効期限が切れていないため、クラスターにはすでに作業を継続したいワークロードがありました
現時点でもetcd証明書を処理する必要がなかったため、省略しました

だから高レベルで私はしなければならなかった

• マスターに
  
  
  
  • マスターで新しい証明書を生成する
  
  
  • 埋め込み証明書を使用して新しいkubeconfigsを生成する
  
  
  • 新しい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

今、各労働者のために-一度に1つ

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だけでなく）が（@ 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パラメーターを明示的に渡す必要があります。 そうしないと、ログsudo journalctl -u kubelet --all | tail 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ようなエラーが発生し、マスターノードは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クラスターでもこれに対処する必要がありました。私の場合、証明書の有効期限が近づいていたため、わずかに異なります。
また、オンプレミスで単一のマスター/コントロールインスタンスを処理するため、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

今、各労働者のために-一度に1つ

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日に期限切れになりました）。

証明書を更新し、構成ファイルを再生成し、単純な3ノードクラスターを元に戻すには、4つの異なるソースを参照する必要がありました。

@danroliverは、IBMからの以下のガイドに非常に近い、非常に優れた構造化された指示を出しました。
[Kubernetesクラスター証明書の更新] IBM WoW！ （https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html）

注：Watsonprivateを使用したIBMFinancial Crimes Insightは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がすべて含まれていません。つまり、代わりにkubeadminitフェーズです。

# 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ワーキンググループによって、kubernetesのバージョンを長期間サポートすることについて議論が行われていますが、プロセスの確立には時間がかかる場合があります。

ありがとう@pmorie 。
kubeバージョン1.13.6で動作します

コメントと機能のリクエスト：この証明書の有効期限は、今朝、Kubernetes1.11.xクラスターで本番環境に影響を与えました。 上記のすべて（およびリンク）を試しましたが、多数のエラーが発生し、数時間後に大きなホース付きクラスターで完全にスタックすることを諦めました。 幸い、Kubernetes 1.15へのアップグレード（および新しいクラスターの構築）から約2週間離れていたため、新しい1.15クラスターを最初から作成し、すべてのユーザーデータをコピーすることになりました。

これが起こる前にいくつかの警告があったことを強く願っています。 警告なしに「信じられないほど安定したクラスター」から「完全に壊れた地獄の悪夢」に移行したばかりで、おそらくこれまでで最悪のダウンタイムが発生しました。 幸いなことに、それは金曜日の午後の西海岸だったので、影響は比較的最小限でした。

上で説明したすべての、およびリンクされたすべてのチケットの中で、大規模になったであろう1つのこと
私たちにとっての違いは言及されていません：証明書がまもなく期限切れになるときに警告の表示を開始します。 （たとえば、kubectlを使用していて、証明書が数週間以内に期限切れになる場合は、教えてください！）。

ご迷惑をおかけして申し訳ありません。 通常、それはオペレーターの責任です
ディスク上の証明書の有効期限を監視します。 しかし、私はその欠如に同意します
監視が容易な場合、問題が発生する可能性があります。 それが私たちが追加した理由の1つです
kubeadmで証明書の有効期限を確認するコマンド。 見る
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

また、1.15以降、kubeadmはで証明書を自動更新することに注意してください。
アップグレード。 これにより、ユーザーはより頻繁にアップグレードすることもできます。
2019年7月20日03:49、「ウィリアムスタイン」 [email protected]は次のように書いています。

ただのコメントと機能のリクエスト：この証明書の有効期限は私たちを襲った
今朝のKubernetes1.11.xクラスターでの本番。 やってみた
上記のすべて（およびリンクへ）が、多数のエラーが発生し、
大きなホース付きクラスターで完全にスタックする数時間。 幸運にも、
Kubernetes 1.15へのアップグレード（およびビルド）から約2週間でした
新しいクラスター）なので、新しい1.15クラスターを最初から作成することになりました。
すべてのユーザーデータをコピーします。

これが起こる前にいくつかの警告があったことを強く願っています。 私たちはただ
「信じられないほど安定したクラスター」から「完全に壊れた地獄のような」になりました
悪夢」と警告なしに、おそらくこれまでで最悪のダウンタイムが発生しました。
幸いなことに、それは金曜日の午後の西海岸だったので、比較的最小限でした
インパクトがあります。

上記およびリンクされたすべてのチケットで説明されているすべての中で、1つのこと
それは大規模になったでしょう
私たちにとっての違いは言及されていません：証明書が発行されたときに警告を表示し始めます間もなく期限切れになります。 （たとえば、kubectlを使用していて、証明書が
数週間以内に期限切れになりますので、教えてください！）。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
。

@ neolit123ありがとう; コメントで説明されているように、今後の証明書の問題を定期的にチェックするために、独自の監視インフラストラクチャに何かを追加します。

@danroliverThxあなたの返事にたくさん。 それは私にとって多くの時間を節約しました。
言及する価値のある1つのポイントは、「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れていました。これにより、クラスタークリティカルなサービスがK8sAPIで認証できなくなりました。
トークンを再生成するには、古いトークンを削除すると、トークンが再作成されます。
PVプロビジョナー、イングレスコントローラー、 cert-managerなど、K8sAPIと通信するすべてのサービスについても同じことが言えます。

この素晴らしいステップバイステップ、@ danroliverをありがとう！ このプロセスをマルチマスタークラスター（ベアメタル、現在1.11.1を実行中）に、できればダウンタイムなしでどのように適用できるのか疑問に思っています。 私の証明書はまだ有効期限が切れていませんが、それが発生する前にそれらを再生成/更新する方法を学ぼうとしています。

こんにちは@kcronin 、マルチマスター設定でどのように解決しましたか？ --apiserver-advertise-addressの進め方がわかりません私は3つのIPを持っていて、1つだけではありません。

ありがとう

@pmcgrathマスターが3人いる場合、各マスターで手順を繰り返す必要がありますか？ または何ですか。 場合

@ SuleimanWA 、CAが再生成された場合は、CAファイルと同様にadmin.confをコピーできます。
それ以外の場合は、すべてのマスターで証明書（etcd、kubelet、schedulerなど）を再生成する手順を繰り返す必要があります。

@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が起動していなかったため、シークレットは自動生成されませんでした。

ハイバージョン使用：

kubeadmalpha証明書はすべて更新します

最初のマスターノードのkubeletがダウンすると（systemctl stop kubelet）、他のマスターノードは最初のマスターノードのCAに接続できません。 これにより、元のマスターノードのkubeletがオンラインに戻るまで、次のメッセージが表示されます。

kubectlgetノード
サーバーからのエラー（InternalError）：サーバーのエラー（ ""）により、要求が成功しませんでした（ノードの取得）

元のCAノードのキューブレットがダウンしているときに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はすべてを更新します（これにより、マスターのコントロールプレーン証明書uber pki /フォルダーが更新されます）。
kubeadm初期化フェーズkubeconfigを使用して、kube構成ファイルを更新します。 （マスターとワーカーについて）。
すべてのノードでkubeletを再起動します。

それでもトークンを作成してワーカーノードでjoinを実行する必要がありますか？ 可能であれば、実行した手順を共有できますか？