<p>Los certificados de fase alfa de kubeadm se renuevan todos también deben actualizar los certificados en los archivos de KubeConfig</p>

@MalloZup
por supuesto, pero tenga en cuenta que las fases de unión son de alta prioridad.

¡suena bien! muchas gracias.

Hola,

hay una cosa más con respecto a este tema.

kubeadm alpha phase kubeconfig all muestra este mensaje si los archivos conf están en su lugar al emitir el comando:

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

No verifica si los certificados están vencidos, por lo que, en mi opinión, up-to-date es engañoso.

Para obtener los certificados actualizados en los archivos, uno DEBE eliminar los archivos por adelantado, de lo que parece el registro:

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

En mi caso, pensé que estaba bien, pero unos días después, los pods estáticos no pudieron comunicarse debido a certificados obsoletos.

Atentamente
Andreas

Asignado a @MalloZup

@MalloZup : GitHub no me permitió asignar los siguientes usuarios: MalloZup.

Tenga en cuenta que solo se pueden asignar miembros de kubernetes y colaboradores de repositorios y que los problemas / RP solo pueden tener 10 asignados al mismo tiempo.
Para obtener más información, consulte la guía para colaboradores.

hola @adoerler gracias por el problema. Con respecto a la información engañosa, he enviado un PR https://github.com/kubernetes/kubernetes/pull/73798.

Revisaré el resto del problema una vez que tenga tiempo. Gracias por el tiempo y la precisión del problema.

@adoerler he enviado un PR DOC para su sugerencia. No dudes en echar un vistazo tia: rocket:
(https://github.com/kubernetes/website/pull/12579)

Hola @MalloZup ,

gracias por PR!

Me falta una oración sobre los archivos kubeconfig, porque certs renew es solo una parte del juego.
Algo como:

Una vez renovados los certificados, no olvide volver a crear los archivos de KubeConfig usando kubeadm alpha phase kubeconfig ...

Gracias. No agregué el documento porque estaba pensando que en realidad podríamos renovar también los archivos kubeconfig. El resto, reiniciando pods, podemos delegarlo al usuario y escribir un documento mínimo. @fabriziopandini @lubomir @ereslibre ¿ Me falta algo en esta implementación? Tia

@MalloZup No tengo un conocimiento profundo de cómo funciona la renovación de certificados.

Personalmente, me gustaría aclarar un poco la historia general antes de tomar medidas, incluido lo propuesto anteriormente:

• qué debería ser administrado por kubeadm alpha phase certs renew
• lo que debe administrarse automáticamente durante kubeadm upgrade
• lo que debe documentarse (y gestionarse por los usuarios)
• cómo se aplica esto a los clústeres de alta disponibilidad
• cómo esto se ve afectado por las variantes del clúster (como, por ejemplo, externo, etcd, CA externa)
• etc.

pero dejo la última palabra a personas más hábiles que yo en esta área

Creo que deberíamos reservar tiempo en una reunión para discutir cuál debería ser nuestra política de renovación de certificados recomendada. la página sobre la gestión de certificados puede necesitar algunos detalles adicionales:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

y necesitamos escribir una pequeña guía, para los clústeres de un solo plano de control como un comienzo al menos.

lo que los usuarios han estado haciendo es resolver las cosas por su cuenta:
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^ este comentario y el anterior contienen guías creadas por el usuario.

esta es una señal de que necesitamos agregar una guía oficial.
cc @timothysc @liztio

/ asignar @ereslibre

Nuestro clúster con un par de cientos de usuarios está bloqueado en este momento. ¿Podría tener una guía muy rápida sobre qué hacer con un certificado caducado?

@ dimm0

lo que los usuarios han estado haciendo es resolver las cosas por su cuenta:
# 581 (comentario)
^ este comentario y el anterior contienen guías creadas por el usuario.

estas son las únicas guías que tenemos cajeros automáticos.

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

en 1.13 las fases de inicio se han graduado al comando de inicio principal:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

en 1.12 la bandera debería estar ahí:
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11 pronto dejará de ser compatible.

eliminar el ciclo de vida / etiqueta activa.
pasando a 1,15.

posibles ideas de actualización de documentos aquí:
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

@ neolit123
Pregunta: en 1.14 con master HA, ¿es suficiente seguir el https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139 en un solo maestro, o tenemos que volver a unirnos a los maestros secundarios para poder volver a obtener los certificados?

reincorporarse a los nodos del plano de control secundario, parece una opción rápida y viable en 1,14.
todavía no tenemos ningún documento en términos de rotaciones de certificados HA.
(sin mencionar que todavía tenemos que agregar los pasos adecuados como lo hizo https://github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139).

¿No proporciona --experimental-upload-certs la base para una solución más sencilla para la rotación de certificados en HA?

una forma de hacer la rotación de certificados HA es:

• en un solo nodo del plano de control, siga los pasos mencionados anteriormente para actualizar sus certificados
• en la misma llamada de nodo CP:

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

almacenar la clave de certs.

kubeadm token create --print-join-command

almacenar el comando de unión con el token.

reúnase con el resto de los nodos del plano de control usando el token y la clave de certs, uno por uno usando --certs-key .... --experimental-control-plane-join

para los trabajadores: escurrir, reincorporarse con la nueva ficha, descordonar, uno por uno.

opcionalmente, elimine los tokens resultantes.

@ neolit123
En un clúster de 3 maestros, en el momento en que cambiemos los certificados en el maestro "primario", etcd dejará de funcionar, ya que los certificados se cambian (y el quórum debe ser un mínimo del 51%). Si es así, ¿tal vez tengamos que acordonar de alguna manera a los 2 maestros secundarios y solo entonces cambiar los certificados? ¿Es posible "cordon master"?

No soy un experto aquí, pero no creo que la copia automática del certificado deba entrar en esta imagen

Los certificados de copia automática manejan CA, front-proxy-CA, etcd-CA (con 10 años TTL) y clave SA (sin TTL)

El comando de renovación de certificado toca todos los demás certificados (con TTL de 1 año), que son diferentes entre maestros.
AFAIK, actualmente no hay nada que maneje la renovación de certificados para archivos kubeconfig

ok, no consideré lo que realmente hace la "copia de certificados" aquí.
tenemos que escribir los documentos de rotación de certificados adecuados, de cualquier manera.

/asignar
/ ciclo de vida activo

Estoy empezando a trabajar en este tema.
Hay diferentes puntos a abordar (_actualizado el 14 de mayo de 2019_)

• Incluso con la Rotación de certificados habilitada, kubelet.conf apunta a certificados obsoletos (ya registrados por https://github.com/kubernetes/kubeadm/issues/1317)
• La rotación de certificados no actualiza los certificados de apiserver / etcd / front-proxy-client (corregido por https://github.com/kubernetes/kubernetes/pull/76862)
• Los certificados de fase alfa de Command kubeadm renovar todo no actualizan los archivos de KubeConfig (corregido por https://github.com/kubernetes/kubernetes/pull/77180)
• Documentación sobre la renovación de certificados (con más detalles sobre dónde se debe ejecutar el comando, cuándo, kubeconfig, HA)

Y los abordaré todos en RP separados

@ neolit123 @fabriziopandini
¿Los pasos que mencionaste también para rotar el certificado de CA? ¿Se puede documentar esto también? ¿Qué pasa con la rotación de las claves privadas, incluida la de la CA?

@ tushar00jain la rotación del https://github.com/kubernetes/kubeadm/issues/1350
Este problema se centra solo en certificados firmados

@fabriziopandini Estaba buscando cerrar este boleto hoy, ya que pudieron enviar PR para las piezas de renovación. ¿Debería cerrarse el ticket?

Incluso con la Rotación de certificados habilitada, kubelet.conf apunta a certificados desactualizados (ya registrados por # 1317)

sí, esto se rastrea en un número separado, posiblemente necesite discusión / documentación en términos de qué soluciones deberíamos proporcionar.

La rotación de certificados no actualiza los certificados de apiserver / etcd / front-proxy-client (corregido por kubernetes / kubernetes # 76862)

Los certificados de fase alfa de Command kubeadm renovar todo no actualizan los archivos de KubeConfig (corregido por kubernetes / kubernetes # 77180)

Documentación sobre la renovación de certificados (con más detalles sobre dónde se debe ejecutar el comando, cuándo, kubeconfig, HA)

se deben hacer los 3 anteriores.

/cerca
Según el comentario anterior, la mayor parte del trabajo ya está terminado; el bit faltante se rastrea en un problema separado / dedicado

@fabriziopandini : Cerrando este tema.

¿Puede alguien explicarme cómo se abordó la parte "Incluso con la rotación de certificados habilitada, kubelet.conf apunta a certificados obsoletos"? El único problema vinculado que menciona esto se cerró explícitamente a favor de otro problema que se cierra con "No estoy seguro si este es un problema, así que abra un nuevo ticket si lo es".
Estoy en 1.16, no veo ninguna renovación en kubelet.conf con sudo kubeadm alpha certs renew all . ¿Qué me falta? @ neolit123

un resumen rápido de una discusión muy, muy larga.

1. la rotación de certificados para todos los certificados, pero kubelet.conf ahora es administrado por kubeadm alpha cert renew.
2. la rotación de certificados para kubelet.conf será administrada por kubelet mismo (a menos que el usuario opte por no participar en la rotación automática de certificados)

Este segundo punto ya funciona a partir de hoy para todos los nodos excepto el que ejecuta kubeadm init; https://github.com/kubernetes/kubernetes/pull/84118 va a arreglar eso

@fabriziopandini Gracias por esto, tiene sentido.

Para cualquier otra persona que se enfrente al problema de que los certificados en kubelte.conf estén desactualizados entre ahora y cuando se solucione lo anterior, encontré este artículo útil:

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

En los nodos creados con kubeadm init, antes de la versión 1.17 de kubeadm, hay un error en el que debe modificar manualmente el contenido de kubelet.conf. Después de que finalice kubeadm init, debe actualizar kubelet.conf para que apunte a los certificados de cliente de kubelet rotados, reemplazando client-certificate-data y client-key-data con:

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

@AndrewSav Gracias por esto. He usado el operador promethes para monitorear el clúster. Recientemente recibí una alerta "El certificado de API de Kubernetes vence en menos de 7 días", creo que está relacionado con este problema. He actualizado el contenido de kubelet.conf en los nodos maestros. Pero sigo recibiendo la alerta. ¿Tienes alguna sugerencia? Tks.

@tannh si instaló el clúster con kubeadm, use kubeadm para verificar la experiencia de los certificados. De lo contrario, es probable que su problema no esté relacionado.

En los nodos creados con kubeadm init, antes de la versión 1.17 de kubeadm, hay un error en el que debe modificar manualmente el contenido de kubelet.conf. Después de que finalice kubeadm init, debe actualizar kubelet.conf para que apunte a los certificados de cliente de kubelet rotados, reemplazando client-certificate-data y client-key-data con:

esto también estará en las notas de la versión 1.17.

@adoerler Todavía estoy ejecutando la versión anterior de kubeadm, ¿cómo puedo actualizar kubelet.conf, admin.con, ... etc, después de la renovación del certificado?

Ejecuté "kubeadm alpha certs renew all", lo que generó nuevos certificados, luego necesito editar todos los archivos .conf en / etc / kubernetes, ¿cómo? ¿Dónde exactamente deberían apuntar?
y en el caso de nodos multimaestro, ¿debo ejecutar el comando en todos los masters?

Hola @SuleimanWA ,

No puedo decirle qué hacer en un entorno multimaestro, solo he tenido un maestro único en mi configuración.

Esto es lo que hice:

En primer lugar, asegúrese de quitar los archivos conf existentes, ¡porque los archivos existentes no se sobrescribirán!

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

luego actualice estos archivos:

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"    

Para aplicar los nuevos certificados en los pods del sistema estático, la forma más fácil para mí fue simplemente reiniciar el servidor maestro.

No olvide copiar client-certificate-data y client-key-data de /etc/kubernetes/admin.conf a su .kube/config local.

Espero que esto ayude

Andreas

¿Alguna idea de cómo ejecutar este comando en 1.14.10? Todo lo que obtengo es:

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

Entonces los doctores dicen:
kubeadm alpha phase kubeconfig all
y obtengo:
This command is not meant to be run on its own. See list of available subcommands.

Gracias

Hola @provgregoryabdo ,

¿Cuál es tu salida de kubeadm version ?

BR Andreas

@provgregoryabdo los phase movieron fuera de alpha y a init en versiones posteriores para que pueda usar algo como

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

@adoerler gracias por la ayuda!