INFORME DE ERROR

Versiones

versión de kubeadm : 1.10.2

Medio ambiente :

• Versión de Kubernetes : 1.9.3
• Proveedor de nube o configuración de hardware : 3 x k8s master HA
• SO : RHEL7
• Kernel : 3.10.0-693.11.6.el7.x86_64

¿Qué sucedió?

Hace un par de meses creé un clúster HA de kubernetes 1.9.3 usando kubeadm 1.9.3 , siguiendo la documentación 'oficial' https://kubernetes.io/docs/setup/independent/high-availability/ , configurando el etcd HA clúster que lo aloja en los nodos maestros usando pods estáticos

Quería actualizar mi clúster a k8s 1.10.2 usando el último kubeadm ; después de actualizar kubeadm , al ejecutar kubeadm upgrade plan , recibí el siguiente error:

[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

Investigué el problema y encontré las 2 causas raíz:

1) kubeadm no identifica el clúster etcd como TLS habilitado

La guía instruye para usar el siguiente comando en el pod estático 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 cheques (aquí: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56) si etcd tiene TLS habilitado al verificar la presencia de los siguientes indicadores en el comando de pod estático.

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

pero como las banderas --client-cert-auth y --peer-client-cert-auth se usan en las instrucciones sin ningún parámetro (siendo booleanos) kubeadm no reconoció que el clúster etcd tuviera TLS activado.

ARREGLO PERSONAL:
Actualicé mi comando de pod estático etcd para usar - --client-cert-auth=true y - --peer-client-cert-auth=true

ARREGLO GENERAL:
Actualice las instrucciones para usar --client-cert-auth=true y --peer-client-cert-auth=true y relaje los cheques kubeadm usando "--peer-cert-file" y "--peer-key-file" (sin los iguales)

2) kubeadm no usó los certificados correctos

después de arreglar el punto 1, el problema persistía ya que kubeadm no estaba usando los certificados correctos.
Siguiendo la guía de kubeadm HA, de hecho, los certificados creados son ca.pem ca-key.pem peer.pem peer-key.pem client.pem client-key.pem pero el último kubeadm espera ca.crt ca.key``peer.crt peer.key``healthcheck-client.crt healthcheck-client.key lugar.
Las claves de configuración maestra kubeadm-config etcd.caFile , etcd.certFile y etcd.keyFile se ignoran.

ARREGLO PERSONAL:
Se cambió el nombre del certificado .pem a su .crt y .key y se actualizó la configuración de pod estática etcd para usarlos.

ARREGLO GENERAL:
Utilice los valores kubeadm-config data.caFile , data.certFile y data.keyFile , infiera los certificados correctos de la definición de pod estática de etcd (ruta de pod + volúmenes hostPath) y / o cree un nuevo certificado de cliente temporal para usar durante la actualización.

¿Qué esperabas que sucediera?

El plan de actualización debería haberse ejecutado correctamente

¿Cómo reproducirlo (de la forma más mínima y precisa posible)?

cree un clúster de k8s ha usando kubeadm 1.9.3 siguiendo https://kubernetes.io/docs/setup/independent/high-availability/ e intente actualizarlo a k8s >= 1.10 usando el último kubeadm