RAPPORT D'ERREUR

Versions

version de kubeadm: 1.10.2

Environnement :

• Version de Kubernetes: 1.9.3
• Fournisseur de cloud ou configuration matérielle : 3 x k8s master HA
• Système d' exploitation : RHEL7
• Noyau : 3.10.0-693.11.6.el7.x86_64

Qu'est-il arrivé?

Il y a quelques mois, j'ai créé un cluster kubernetes 1.9.3 HA en utilisant kubeadm 1.9.3 , en suivant la documentation `` officielle '' https://kubernetes.io/docs/setup/independent/high-availability/ , en configurant le etcd Cluster HA qui l'héberge sur les nœuds maîtres à l'aide de pods statiques

Je voulais mettre à niveau mon cluster vers k8s 1.10.2 utilisant la dernière kubeadm ; après la mise kubeadm jour de kubeadm upgrade plan , j'ai eu l'erreur suivante:

[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

J'ai enquêté sur le problème et trouvé les 2 causes profondes:

1) kubeadm n'identifie pas le cluster etcd comme TLS activé

Le guide demande d'utiliser la commande suivante dans le pod statique 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 chèques (ici: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56) si etcd a activé TLS en vérifiant la présence des indicateurs suivants dans la commande de pod statique.

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

mais comme les indicateurs --client-cert-auth et --peer-client-cert-auth sont utilisés dans les instructions sans aucun paramètre (étant des booléens) kubeadm n'a pas reconnu le cluster etcd pour avoir TLS activée.

CORRECTIF PERSONNEL:
J'ai mis à jour ma commande de pod statique etcd pour utiliser - --client-cert-auth=true et - --peer-client-cert-auth=true

CORRECTIF GÉNÉRAL:
Mettez à jour les instructions pour utiliser --client-cert-auth=true et --peer-client-cert-auth=true et relâchez les chèques kubeadm en utilisant "--peer-cert-file" et "--peer-key-file" (sans les égaux)

2) kubeadm n'a pas utilisé les bons certificats

après avoir corrigé le point 1, le problème persistait car kubeadm n'utilisait pas les bons certificats.
En suivant le guide HA de kubeadm, en fait, les certificats créés sont ca.pem ca-key.pem peer.pem peer-key.pem client.pem client-key.pem mais le dernier kubeadm attend ca.crt ca.key``peer.crt peer.key``healthcheck-client.crt healthcheck-client.key place.
Les clés kubeadm-config MasterConfiguration etcd.caFile , etcd.certFile et etcd.keyFile sont ignorées.

CORRECTIF PERSONNEL:
Le certificat .pem renommé en son équivalent .crt et .key et a mis à jour la configuration du pod statique etcd pour les utiliser.

CORRECTIF GÉNÉRAL:
Utilisez les valeurs kubeadm-config data.caFile , data.certFile et data.keyFile , inférez les bons certificats à partir de la définition de pod statique etcd (chemin du pod + volumes hostPath) et / ou créez un nouveau certificat client temporaire à utiliser lors de la mise à niveau.

À quoi vous attendiez-vous?

Le plan de mise à niveau doit avoir été exécuté correctement

Comment le reproduire (de la manière la plus minimale et la plus précise possible)?

créez un cluster ha k8s en utilisant kubeadm 1.9.3 suivant https://kubernetes.io/docs/setup/independent/high-availability/ et essayez de le mettre à jour à k8s >= 1.10 utilisant le dernier kubeadm