バグレポート

バージョン

kubeadmバージョン：1.10.2

環境：

• Kubernetesバージョン：1.9.3
• クラウドプロバイダーまたはハードウェア構成：3 xk8sマスターHA
• OS ：RHEL7
• カーネル：3.10.0-693.11.6.el7.x86_64

何が起こった？

数か月前、「公式」ドキュメントhttps://kubernetes.io/docs/setup/independent/high-availability/に従って、 kubeadm 1.9.3を使用してkubernetes 1.9.3HAクラスターを作成しました。 etcd静的ポッドを使用してマスターノードでホストしているHAクラスター

最新のkubeadmを使用してクラスターをk8s 1.10.2にアップグレードしたかった; kubeadm更新した後、 kubeadm upgrade planを実行すると、次のエラーが発生しました。

[root@shared-cob-01 tmp]# kubeadm upgrade plan
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/plan] computing upgrade possibilities
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.9.3
[upgrade/versions] kubeadm version: v1.10.2
[upgrade/versions] Latest stable version: v1.10.2
[upgrade/versions] FATAL: context deadline exceeded

問題を調査したところ、2つの根本原因が見つかりました。

1） kubeadmは、TLSが有効になっているとしてetcdクラスターを識別しません

ガイドは、 etcd静的ポッドで次のコマンドを使用するように指示します

- etcd --name <name> \
  - --data-dir /var/lib/etcd \
  - --listen-client-urls http://localhost:2379 \
  - --advertise-client-urls http://localhost:2379 \
  - --listen-peer-urls http://localhost:2380 \
  - --initial-advertise-peer-urls http://localhost:2380 \
  - --cert-file=/certs/server.pem \
  - --key-file=/certs/server-key.pem \
  - --client-cert-auth \
  - --trusted-ca-file=/certs/ca.pem \
  - --peer-cert-file=/certs/peer.pem \
  - --peer-key-file=/certs/peer-key.pem \
  - --peer-client-cert-auth \
  - --peer-trusted-ca-file=/certs/ca.pem \
  - --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
  - --initial-cluster-token my-etcd-token \
  - --initial-cluster-state new

kubeadm >= 1.10チェック（ここ：https：//github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56） etcdは、static podコマンドで次のフラグの存在を確認することにより、TLSを有効にします。

"--cert-file=",
"--key-file=",
"--trusted-ca-file=",
"--client-cert-auth=",
"--peer-cert-file=",
"--peer-key-file=",
"--peer-trusted-ca-file=",
"--peer-client-cert-auth=",

しかし、フラグ--client-cert-authと--peer-client-cert-authがパラメーターなしの命令で使用されているため（ブール値）、 kubeadmはetcdクラスターがTLSを持っていることを認識しませんkubeadmた有効。

個人的な修正：
etcd静的ポッドコマンドを更新して、 - --client-cert-auth=trueと- --peer-client-cert-auth=true

一般的な修正：
--client-cert-auth=trueと--peer-client-cert-auth=trueを使用するように手順を更新し、 "--peer-cert-file"と"--peer-key-file"を使用してkubeadmチェックを緩和します（等しいものなし）

2） kubeadmが正しい証明書を使用しなかった

ポイント1を修正した後も、 kubeadmが適切な証明書を使用していなかったため、問題は解決しませんでした。
実際、kubeadm HAガイドに従うと、作成される証明書はca.pem ca-key.pem peer.pem peer-key.pem client.pem client-key.pemしかし、最新のkubeadmは、代わりにca.crt ca.key``peer.crt peer.key``healthcheck-client.crt healthcheck-client.key期待しています。
kubeadm-config MasterConfigurationキーetcd.caFile 、 etcd.certFile 、およびetcd.keyFileは無視されます。

個人的な修正：
.pem証明書の名前を.crtおよび.key相当するものに変更し、それらを使用するようにetcd静的ポッド構成を更新しました。

一般的な修正：
kubeadm-config data.caFile 、 data.certFile 、およびdata.keyFile値を使用して、etcd静的ポッド定義（ポッドパス+ボリュームhostPath）から適切な証明書を推測するか、作成します。アップグレード中に使用する新しい一時クライアント証明書。

あなたは何が起こると思っていましたか？

アップグレード計画は正しく実行されている必要があります

それを（可能な限り最小限かつ正確に）再現する方法は？

https://kubernetes.io/docs/setup/independent/high-availability/に従ってkubeadm 1.9.3を使用してk8s haクラスターを作成し、最新のkubeadmを使用してk8s >= 1.10に更新してみますkubeadm