<p>kubeadmアルファフェーズ証明書はすべて更新し、KubeConfigファイルの証明書も更新する必要があります</p>

@MalloZup
もちろんですが、結合フェーズは優先度が高いことに注意してください。

いいですね！ どうもありがとう。

こんにちは、

このトピックに関してもう1つあります。

kubeadm alpha phase kubeconfig allは、コマンドの発行時にconfファイルが配置されている場合、次のメッセージを表示します。

[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"

証明書の有効期限が切れているかどうかはチェックされないため、私の意見ではup-to-dateは誤解を招く恐れがあります。

更新された証明書をファイルに取り込むには、ログが次のようになるよりも、ファイルを事前に削除する必要があります。

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"   

私の場合は大丈夫ですが、数日後、証明書が古くなったため、静的ポッドと通信できませんでした。

宜しくお願いします
アンドレアス

@MalloZupに割り当てられてい

@MalloZup ：GitHubでは、次のユーザーを割り当てることができませんでした：MalloZup。

割り当てできるのはkubernetesメンバーとレポコラボレーターのみであり、課題/ PRには同時に10人の割り当て者しか割り当てられないことに注意してください。
詳細については、寄稿者ガイドを参照

こんにちは@adoerlerthxの問題です。 誤解を招く情報に関して、私はPRhttps ：//github.com/kubernetes/kubernetes/pull/73798を送信しました

時間があれば、残りの問題について見ていきます。 問題の時間と精度のためのThx

@adoerler私はあなたの提案のためにDOC広報を送りました。 お気軽にtia：rocket：をご覧ください。
（https://github.com/kubernetes/website/pull/12579）

こんにちは@MalloZup 、

PRありがとう！

certs renewはゲームの一部にすぎないため、kubeconfigファイルに関する文がありません。
何かのようなもの：

証明書が更新されたら、 kubeadm alpha phase kubeconfig ...を使用してKubeConfigファイルを再作成することを忘れないでください

THX。 実際にkubeconfigファイルも更新できると思っていたので、ドキュメントを追加しませんでした。 残りの再起動ポッドは、ユーザーに委任して最小限のドキュメントを作成できます。 @fabriziopandini @lubomir @ereslibreこの実装で何かが足りませんか？ ティア

@MalloZup証明書の更新がどのように機能するかについての深い知識がありません。

個人的には、行動を起こす前に、全体的な歴史を少し明らかにしたいと思います-上記で提案されたものを含みます-：

• kubeadm alpha phase certs renewで管理する必要があるもの
• kubeadm upgrade間に自動的に管理されるべきもの
• 何を文書化する必要があるか（そしてユーザーが管理する必要があるか）
• これがHAクラスターにどのように適用されるか
• これがクラスターバリアント（外部etcd、外部CAなど）によってどのように影響を受けるか
• 等

しかし、私はこの分野で私よりも熟練した人々に最後の言葉を残します

推奨される証明書の更新ポリシーについて話し合うために、会議に時間を割く必要があると思います。 証明書管理に関するページでは、さらに詳細が必要になる場合があります。
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

少なくとも開始点として、単一のコントロールプレーンクラスター用の小さなガイドを作成する必要があります。

ユーザーが行っていることは、自分で物事を理解することです。
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^このコメントと上記のコメントには、ユーザーが作成したガイドが含まれています。

これは、公式ガイドを追加する必要があることを示しています。
cc @timothysc @liztio

/ assign @ereslibre

現在、数百人のユーザーがいるクラスターはスタックしています。 期限切れの証明書をどうするかについての非常に簡単なガイドを教えてもらえますか？

@ dimm0

ユーザーが行っていることは、自分で物事を理解することです。
＃581（コメント）
^このコメントと上記のコメントには、ユーザーが作成したガイドが含まれています。

これらは私たちがATMを持っている唯一のガイドです。

[root<strong i="5">@controller0</strong> ~]# kubeadm alpha phase certs apiserver --apiserver-advertise-address 1.2.3.4
Error: unknown flag: --apiserver-advertise-address
Usage:

Flags:
  -h, --help   help for phase

Global Flags:
      --log-file string   If non-empty, use this log file
      --rootfs string     [EXPERIMENTAL] The path to the 'real' host root filesystem.
      --skip-headers      If true, avoid header prefixes in the log messages
  -v, --v Level           log level for V logs

error: unknown flag: --apiserver-advertise-address
[root<strong i="6">@controller0</strong> ~]# kubeadm alpha phase certs apiserver
This command is not meant to be run on its own. See list of available subcommands.

1.13では、initフェーズは親のinitコマンドに移行しました。
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

1.12では、フラグはそこにあるはずです。
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11はまもなくサポートが終了します。

ライフサイクル/アクティブラベルを削除します。
1.15に移動します。

可能なドキュメントはここでアイデアを更新します：
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

@ neolit123
質問：1.14でマスターHAを使用する場合、単一のマスターでhttps://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139をフォローするだけで十分ですか、それともセカンダリマスターに再度参加する必要があります。証明書を再フェッチしますか？

セカンダリコントロールプレーンノードに再結合することは、1,14の迅速で実行可能なオプションのようです。
HA証明書のローテーションに関するドキュメントはまだありません。
（言うまでもなく、https：//github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139のような適切な手順はまだ追加されていません）。

--experimental-upload-certsは、HAでの証明書ローテーションのより簡単なソリューションの基礎を提供しませんか？

HA証明書ローテーションを行う1つの方法は次のとおりです。

• 単一のコントロールプレーンノードで、上記の手順に従って証明書を更新します
• 同じCPノード呼び出しで：

kubeadm init phase upload-certs --experimental-upload-certs

証明書キーを保存します。

kubeadm token create --print-join-command

トークンとともにjoinコマンドを保存します。

トークンと証明書キーを使用して、残りのコントロールプレーンノードに--certs-key .... --experimental-control-plane-joinを使用して1つずつ再結合します。

労働者のために：排水し、新しいトークンを使用して再参加し、コードンを1つずつ使用します。

オプションで、結果のトークンを削除します。

@ neolit123
3つのマスタークラスターでは、「プライマリ」マスターの証明書を変更すると、証明書が変更されるため、etcdは機能しなくなります（クォーラムは最小51％である必要があります）。 もしそうなら、多分私たちはどういうわけか2つのセカンダリマスターをコードンしてから証明書を変更する必要がありますか？ 「コードンマスター」は可能ですか？

私はここの専門家ではありませんが、自動証明書コピーがこの写真に含まれるべきではないと思います

自動コピー証明書は、CA、front-proxy-CAなどを処理します-CA（10年TTLあり）およびSAキー（TTLなし）

Cert renewコマンドは、マスター間で異なる他のすべての証明書（1年TTL）にタッチします。
AFAIK、現在、kubeconfigファイルの証明書の更新を処理するものはありません

わかりました、私は「証明書のコピー」が実際にここで何をするかを考慮しませんでした。
どちらの方法でも、適切な証明書ローテーションドキュメントを作成する必要があります。

/割当
/ライフサイクルアクティブ

私はこの問題に取り組み始めています。
対処すべきさまざまなポイントがあります（_ 2019年5月14日更新_）

• 証明書ローテーションが有効になっている場合でも、kubelet.confは古い証明書を指します（https://github.com/kubernetes/kubeadm/issues/1317によってすでに追跡されています）
• 証明書ローテーションはapiserver / etcd / front-proxy-client証明書を更新しません（https://github.com/kubernetes/kubernetes/pull/76862で修正）
• コマンドkubeadmalpha phase certs renew allはKubeConfigファイルを更新しません（https://github.com/kubernetes/kubernetes/pull/77180で修正）
• 証明書の更新に関するドキュメント（コマンドを実行する場所、when、kubeconfig、HAの詳細）

そして、私はそれらすべてに別々のPRで取り組みます

@ neolit123 @fabriziopandini
CA証明書をローテーションするためにも言及した手順はありますか？ これも文書化できますか？ CA用のものを含む秘密鍵をローテーションするのはどうですか？

@ tushar00jainのCA証明書のローテーションは別の問題で追跡されていますhttps://github.com/kubernetes/kubeadm/issues/1350
この問題は、署名された証明書のみに焦点を当てています

@fabriziopandini更新パーツのPRを送信できたので、今日このチケットを閉じることを検討していました。 チケットを閉じる必要がありますか？

証明書ローテーションが有効になっている場合でも、kubelet.confは古い証明書を指します（すでに＃1317で追跡されています）

はい、これは別の問題で追跡されます。提供する必要のある回避策に関して、ディスカッション/ドキュメントが必要になる可能性があります。

証明書ローテーションはapiserver / etcd / front-proxy-client証明書を更新しません（kubernetes / kubernetes＃76862で修正）

コマンドkubeadmalpha phase certs renew allは、KubeConfigファイルを更新しません（kubernetes / kubernetes＃77180で修正）

証明書の更新に関するドキュメント（コマンドを実行する場所、when、kubeconfig、HAの詳細）

上記の3を実行する必要があります。

/閉じる
上記のコメントによると、ほとんどの作業はすでに完了しています。 欠落しているビットは、別の/専用の問題で追跡されます

@fabriziopandini ：この問題を解決します。

「証明書ローテーションが有効になっている場合でも、kubelet.confが古い証明書を指している」部分がどのように対処されたかを誰かに説明してもらえますか？ これに言及している唯一のリンクされた問題は、「これが問題であるかどうかわからないので、新しいチケットを開く」で閉じられる別の問題を支持して、明示的に閉じられました。
私は1.16を使用していますが、 kubelet.confでsudo kubeadm alpha certs renew all更新が行われていません。 何が欠けていますか？ @ neolit123

非常に長い議論の簡単な要約。

1. kubelet.confを除くすべての証明書の証明書ローテーションは、kubeadm alpha certrenewによって管理されるようになりました。
2. kubelet.confの証明書ローテーションは、kubelet自体によって管理されます（ユーザーが自動証明書ローテーションをオプトアウトしない限り）

今日の時点ですでにこの2番目のポイントは、kubeadminitを実行するノードを除くすべてのノードで機能します。 https://github.com/kubernetes/kubernetes/pull/84118はそれを修正する予定です

@fabriziopandiniこれをありがとう、それは理にかなっています。

kubelte.confの証明書が現在から上記の修正までの間に古くなっているという問題に直面している他の人にとって、この記事は役に立ちました。

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#check -certificate-expiration

kubeadm initで作成されたノードでは、kubeadmバージョン1.17より前では、kubelet.confの内容を手動で変更する必要があるというバグがあります。 kubeadm initが終了したら、client-certificate-dataとclient-key-dataを次のように置き換えて、ローテーションされたkubeletクライアント証明書を指すようにkubelet.confを更新する必要があります。

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

@AndrewSavありがとうございます。 私はpromethes演算子を使用してクラスターを監視しました。 最近、「Kubernetes API証明書の有効期限が7日以内です」というアラートを受け取りましたが、これはこの問題に関連していると思います。 マスターノードのkubelet.confのコンテンツを更新しました。 しかし、私はまだアラートを受け取ります。 何か提案はありますか？ Tks。

@tannh kubeadmを使用してクラスターをインストールした場合は、kubeadmを使用して証明書の有効期限を確認してください。 そうでなければ、あなたの問題はおそらく関連していません。

kubeadm initで作成されたノードでは、kubeadmバージョン1.17より前では、kubelet.confの内容を手動で変更する必要があるというバグがあります。 kubeadm initが終了したら、client-certificate-dataとclient-key-dataを次のように置き換えて、ローテーションされたkubeletクライアント証明書を指すようにkubelet.confを更新する必要があります。

これは、1.17のリリースノートにも記載されています。

@adoerler古いバージョンのkubeadmをまだ実行していますが、証明書の更新後にkubelet.conf、admin.conなどを更新するにはどうすればよいですか？

新しい証明書を生成する「kubeadmalphacerts renew all」を実行した後、/ etc / kubernetesの下にあるすべての.confを編集する必要があります。どうすればよいですか？ 正確にどこを指す必要がありますか？
マルチマスターノードの場合、すべてのマスターでコマンドを実行する必要がありますか？

こんにちは@SuleimanWA 、

マルチマスター環境で何をすべきかわかりません。セットアップには単一のマスターしかありませんでした。

これは私がしたことです：

まず、既存のファイルは上書きされないため、既存のconfファイルを邪魔にならない場所に移動してください。

mv /etc/kubernetes/admin.conf /backup
mv /etc/kubernetes/kubelet.conf /backup
mv /etc/kubernetes/controller-manager.conf /backup
mv /etc/kubernetes/scheduler.conf /backup

次に、これらのファイルを更新します。

user<strong i="13">@master</strong>:~$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address=<INSERT-YOUR-APISERVER-IP-HERE>
I0124 21:56:14.253641   15040 version.go:236] remote version is much newer: v1.13.2; falling back to: stable-1.12
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"    

静的システムポッドに新しい証明書を適用する最も簡単な方法は、マスターサーバーを再起動することでした。

client-certificate-dataとclient-key-dataを/etc/kubernetes/admin.confからローカルの.kube/configコピーすることを忘れないでください。

お役に立てれば

アンドレアス

1.14.10でこのコマンドを実行する方法はありますか？ 私が得るのは：

kubeadm alpha phase kubeconfig all --apiserver-advertise-address=192.168.102.170 Error: unknown flag: --apiserver-advertise-address

次に、ドキュメントは次のように述べています。
kubeadm alpha phase kubeconfig all
そして私は得る：
This command is not meant to be run on its own. See list of available subcommands.

ありがとう

こんにちは@provgregoryabdo 、

kubeadm version出力は何ですか？

BRアンドレアス

@provgregoryabdo phaseコマンドはアルファ版から移動し、新しいバージョンで初期化するため、次のようなものを使用できます。

kubeadm init phase kubeconfig all --apiserver-advertise-address=<your_address>

@adoerler助けてくれてありがとう！