<p>kubeadm restableció correctamente, pero esta ip de nodo todavía está en el mapa de configuración de kubeadm-config</p>

cc @fabriziopandini

Idealmente, habría una forma de "actualizar" ClusterStatus. Ejecutamos clústeres con pruebas de caos, es totalmente posible que un nodo del plano de control termine sin previo aviso y sin oportunidad de ejecutar kubeadm reset . Lo ideal sería que hubiera una forma limpia de actualizar ClusterStatus explícitamente para eliminar los nodos del plano de control que sabemos que ya no están en el clúster. Esto es algo que se haría antes de ejecutar kubeadm join --control-plane ... o posiblemente esté integrado.

Algunos comentarios aquí:

kubeadm-config ConfigMap elimina esta ip de nodo.

@pytimer Sé que dejar una dirección de API de nodo en el estado del clúster no es ideal, pero me interesa comprender si esta "falta de limpieza" genera problemas o no. ¿Ha intentado volver a unirse al mismo plano de control? ¿Ha intentado unirse a otro plano de control? No espero problemas, pero se agradece mucho recibir una confirmación sobre este punto.

Todavía tengo una pregunta, ¿por qué kubeadm reset no elimina este nodo directamente del clúster? En su lugar, ejecute kubectl delete nodea mano.

@luxas podría ser un poco de contexto histórico que puede ayudar aquí.
Supongo que el nodo no tenía el privilegio de eliminarse a sí mismo (pero esto se aplica a los nodos trabajadores, no a los nodos del plano de control ...)

Idealmente, habría una forma de "actualizar" ClusterStatus / habría una forma limpia de actualizar ClusterStatus explícitamente

@danbeaulieu ese es un buen punto. tener un comando explícito para sincronizar el estado del clúster o hacer cumplir la sincronización automática cuando se ejecuta kubeadm es una buena idea.
Sin embargo, al ser kubeadm sin ningún tipo de bucle de control en ejecución continua, creo que siempre habrá la posibilidad de que ClusterStatus no esté sincronizado.
Esto no debería ser un problema, o más específicamente tener IP de nodo para nodos que ya no existen (falta de limpieza) no debería ser un problema.
En cambio, si existe un nodo y falta la IP del nodo correspondiente en ClusterStatus (inicialización incorrecta), esto podría crear problemas, por ejemplo, para las actualizaciones.

¿Podría informar amablemente si la suposición anterior es confirmada por su prueba de caos? cualquier comentario será realmente apreciado.

@fabriziopandini Me uno al mismo nodo del plano de control, ha fallado.

Mis pasos de unión:

La IP del segundo nodo del plano de control es 192.168.46.212 .

• elimine el miembro etcd del nodo 192.168.46.212 del clúster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f en este nodo del plano de control.
• ejecute kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 nuevo.

Registros de unión de kubeadm:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Veo el código kubeadm y creo que este problema puede ser causado por 192.168.46.212 que queda en el kubeadm-config ConfigMap.

Kubeadm obtiene puntos finales api desde kubeadm-config ConfigMap cuando se une al nodo del plano de control y los puntos finales etcd son los mismos que los puntos finales api. Pero el nodo 912.168.46.212 control-plane se ha eliminado y aún no se ha unido, así que compruebe el estado del clúster etcd incorrectamente.

Cuando elimino el punto final 192.168.46.212 api del kubeadm-config ConfigMap y me uno a este nodo del plano de control de nuevo, se une correctamente.

@pytimer gracias!
Esto debería investigarse. Ya existe una lógica que intenta sincronizar la supuesta lista de puntos finales etcd con el punto final de la lista etcd real, pero algo parece no funcionar correctamente

Sí, esto parece un error. Tenemos un plano de control de 3 nodos ASG. Si terminamos una instancia, se creará una nueva según las reglas de ASG. Durante este tiempo, el nodo terminado aparece como insalubre en la lista de miembros de etcd. Cuando aparece la nueva instancia, antes de ejecutar kubeadm join... , elimina el miembro en mal estado de etcd. Para cuando ejecutamos kubeadm join... el clúster etcd está en buen estado con 2 nodos según etcd. Sin embargo, kubeadm usa ClusterStatus como su fuente de verdad, que todavía tiene listada la instancia anterior.

La solución para nosotros es, justo después de hacer la administración de membresía de etcd, actualizar el ConfigMap de kubeadm-config con la verdad del clúster y luego ejecutar kubeadm join... .

Idealmente, kubeadm join... usaría etcd como la fuente de la verdad y actualizaría el ConfigMap de kubeadm-config en consecuencia.

@fabianofranz Quizás encontré la causa de este problema.

Cuando sincroniza los puntos finales etcd con la lista de puntos finales etcd real, la sincronización es correcta. Pero asigne los puntos finales reales de etcd al cliente etcd Endpoints , esta variable de cliente no es un puntero, por lo que cuando otro código usa el cliente, los puntos finales de este cliente siguen siendo puntos finales antiguos, no los puntos finales reales después de la sincronización.

Solucioné este problema en mi repositorio de fork, puede consultar este PR https://github.com/pytimer/kubernetes/commit/0cdf6cad87a317be5326f868bafe4faecc80f033. Y estoy probando el caso de usuario join the same control-plane node , se une al éxito.

@pytimer ¡Se ve genial! ¡Bien descrito!
¿Podría enviarme un PR? En mi opinión, esto será elegible para la selección de cerezas.

@ neolit123 @timothysc ^^^

@fabianofranz El primer PR es incorrecto, olvido confirmar CLA.

Este PR https://github.com/kubernetes/kubernetes/pull/71945 se puede comprobar. Si algo anda mal, espero que lo señale.

@fabriziopandini Me uno al mismo nodo del plano de control, ha fallado.

Mis pasos de unión:

La IP del segundo nodo del plano de control es 192.168.46.212 .

• elimine el miembro etcd del nodo 192.168.46.212 del clúster etcd.
• kubectl delete node k8s-212
• kubeadm reset -f en este nodo del plano de control.
• ejecute kubeadm join --experimental-control-plane --config kubeadm.yaml -v 5 nuevo.

Registros de unión de kubeadm:

...
[etcd] Checking Etcd cluster health
I1207 17:57:18.109993    8541 local.go:66] creating etcd client that connects to etcd pods
I1207 17:57:18.110000    8541 etcd.go:134] checking etcd manifest
I1207 17:57:18.119797    8541 etcd.go:181] etcd endpoints read from pods: https://192.168.46.211:2379,https://192.168.46.212:2379
I1207 17:57:18.131111    8541 etcd.go:221] etcd endpoints read from etcd: https://192.168.46.211:2379
etcd cluster is not healthy: context deadline exceeded

Veo el código kubeadm y creo que este problema puede ser causado por 192.168.46.212 que queda en el kubeadm-config ConfigMap.

Kubeadm obtiene puntos finales api desde kubeadm-config ConfigMap cuando se une al nodo del plano de control y los puntos finales etcd son los mismos que los puntos finales api. Pero el nodo 912.168.46.212 control-plane se ha eliminado y aún no se ha unido, así que compruebe el estado del clúster etcd incorrectamente.

Cuando elimino el punto final 192.168.46.212 api del kubeadm-config ConfigMap y me uno a este nodo del plano de control de nuevo, se une correctamente.

Obtuve el mismo error en la versión 1.13.2 de kubeadm, intenté eliminar el nodo manualmente y actualizar kubeadm-config, no funciona, el resto de los nodos etcd aún intentan conectar el nodo eliminado

Cuando elimino el punto final 192.168.46.212 api del kubeadm-config ConfigMap y me uno a este nodo del plano de control de nuevo, se une correctamente.

@pytimer ¿Puede explicar cómo eliminó manualmente el antiguo api-server?

Estoy ejecutando 1.13.3; eliminar el servidor antiguo manualmente a través de:

1. kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
2. manually edit /tmp/conf.yml to remove the old server
3. kubectl -n kube-system apply -f /tmp/conf.yml 

Todavía no puedo unirme al clúster debido al error:

[etcd] Checking etcd cluster health
etcd cluster is not healthy: context deadline exceeded

Luego maté las cápsulas api y las cápsulas etcd (2 de cada una).

Se vuelven a crear, pero todavía tengo el mismo error al intentar conectar el nodo adicional.

Tuvo el mismo problema en 1.13.3 (configuración de clúster HA: 3 nodos maestros + 3 trabajadores). Nodo maestro reemplazado con éxito solo después de los siguientes pasos:

Eliminar nodo del clúster

kubectl delete node master03

Descarga etcdctl (por ejemplo, en master01)

mkdir /opt/tools && cd /opt/tools
wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-arm64.tar.gz
tar xfz etcd-v3.3.12-linux-arm64.tar.gz

Eliminar el nodo maestro de etcd

cd /opt/tools/etcd-v3.3.12-linux-arm64
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member list
./etcdctl --endpoints https://192.168.0.11:2379 --ca-file /etc/kubernetes/pki/etcd/ca.crt --cert-file /etc/kubernetes/pki/etcd/server.crt --key-file /etc/kubernetes/pki/etcd/server.key member remove 28a9dabfcfbca673

Eliminar de kubeadm-config

kubectl -n kube-system get cm kubeadm-config -o yaml > /tmp/conf.yml
manually edit /tmp/conf.yml to remove the old server
kubectl -n kube-system apply -f /tmp/conf.yml

@zhangyelong Ahora kubeadm reset no puede eliminar el miembro etcd, por lo que encontró que el clúster etcd todavía conecta el nodo etcd eliminado. Debería eliminar manualmente el miembro etcd usando etcdctl ahora.

Envío un PR para implementar eliminar el nodo etcd cuando se reinicia, puede ver. https://github.com/kubernetes/kubernetes/pull/74112

@lvangool Puedes seguir los pasos de @Halytskyi . El PR: https://github.com/kubernetes/kubernetes/pull/71945 corrige los puntos finales de sincronización etcd cuando se une al nodo del plano de control, no se puede eliminar el miembro etcd.

Elimine el miembro etcd del clúster etcd cuando se reinicie, puede ver kubernetes / kubernetes # 74112.

Esto parece ser un error en 1.13.4.

Todavía necesitamos actualizar manualmente el mapa de configuración de kubeadm ala https://github.com/kubernetes/kubeadm/issues/1300#issuecomment -463374200

¿No es el caso de que la solución en
kubernetes / kubernetes # 71945 usaría la membresía del clúster etcd como fuente de verdad para los miembros del clúster? Si no es así, ¿qué solucionó exactamente ese PR?

Curiosamente, funciona esporádicamente porque en golang el rango sobre mapas, como ClusterStatus , no es determinista . Entonces, si el primer punto final que encuentra es de un punto final antiguo que ya no existe, las cosas fallan. Si encuentra un punto final en buen estado, actualizará ClusterStatus desde etcd Sync ...

Creo que la causa raíz de esto es un error en el etcd clientv3 donde el error hace que el cliente no vuelva a intentar los otros puntos finales si el primero falla https://github.com/etcd-io/etcd/issues/9949.

Utilice el siguiente problema para realizar un seguimiento de las mejoras de restablecimiento

• https://github.com/kubernetes/kubeadm/issues/1312 Elimine los nodos del plano de control de ClusterStatus ( @Klaven https://github.com/kubernetes/kubernetes/pull/72886)
• https://github.com/kubernetes/kubeadm/issues/1211 Elimina miembros de etcd del clúster de etcd (

@fabriziopandini Hay al menos otro problema aquí que no está relacionado con kubeadm reset .

Si un nodo falla sin la posibilidad de realizar un reinicio de kubeadm (terminación de la instancia, falla de hardware, etc.)
El clúster se deja en un estado en el que ClusterStatus.apiEndpoints todavía enumera un nodo que ya no está en el clúster. Esto requiere la solución alternativa de leer, editar y actualizar el mapa de configuración antes de realizar kubeadm join . Kubeadm probablemente tiene 2 opciones:

1) Implementar el cliente etcd reintentarlo si el dial falla
2) Espere a que se solucione el error go-grpc y luego a que la solución llegue al cliente etcd

Este problema puede ser un buen problema para realizar un seguimiento de cualquiera de esas opciones.

Si un nodo falla sin la posibilidad de realizar un reinicio de kubeadm (terminación de la instancia, falla de hardware, etc.)
El clúster se deja en un estado en el que ClusterStatus.apiEndpoints todavía enumera un nodo que ya no está en el clúster. Esto requiere la solución alternativa de leer, editar y actualizar el mapa de configuración antes de realizar kubeadm join .

eso es cierto, sin llamar a reset tendrá que actualizar manualmente ClusterStatus.
no tenemos un comando que haga eso. Si cree que esta es una función que kubeadm debería admitir, presente un ticket por separado.

Acabo de experimentar esto hoy en 1.14.1

La instancia que ejecuta uno de mis nodos maestros falló, lo que evitó que se eliminara con gracia. Cuando un nuevo nodo intentó entrar, no pudo unirse debido al error descrito en este ticket.

Tuve que eliminar manualmente el miembro etcd a través de etcdctl, luego pude unirme en un nuevo nodo. También eliminé manualmente el nodo del ConfigMap de kubeadm-config, pero no estoy seguro de si era necesario.

@Halytskyi Gracias, la sección etcdctl me ayudó .....

Experimenté esto hoy en 1.15.5

En mi caso, me uní al clúster pero con la versión 1.16. luego eliminó este nodo kubectl delete node , baje a 15.5.5 e intente volver a unirse (misma IP, mismo nombre de host, versión diferente) y obtuve el error insalubre etcd.

Resuelto por (basado en la respuesta de @Halytskyi pero con etcdctl actualizado):

• Eliminar el nodo del mapa de configuración kubeadm-config

>: kubectl edit configmap  kubeadm-config -n kube-system
configmap/kubeadm-config edited

• kubeadm reset -f en el nodo problemático && iptables -t -f -X y así sucesivamente.

• eliminar miembro etcd (esta es la clave):

root@k8s-nebula-m-115-2:wget https://github.com/etcd-io/etcd/releases/download/v3.4.3/etcd-v3.4.3-linux-amd64.tar.gz
root@k8s-nebula-m-115-2:tar xfz etcd-v3.4.3-linux-amd64.tar.gz

`` caparazón
root @ k8s-nebula-m-115-2 : ~ / etcdctl / etcd-v3.4.3-linux-amd64 # ./etcdctl --endpoints https://127.0.0.1 : 2379 --cacert / etc / kubernetes / pki /etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key lista de miembros
289ed62da3c6e9e5, iniciado, k8s-nebula-m-115-1, https://10.205.30.2 : 2380, https://10.205.30.2 : 2379, falso
917e16b9e790c427, iniciado, k8s-nebula-m-115-0, https://10.205.30.1 : 2380, https://10.205.30.1 : 2379, falso
ad6b76d968b18085, iniciado, k8s-nebula-m-115-2, https://10.205.30.0 : 2380, https://10.205.30.0 : 2379, falso

```shell
root@k8s-nebula-m-115-2:~/etcdctl/etcd-v3.4.3-linux-amd64# ./etcdctl --endpoints https://127.0.0.1:2379 --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/server.crt --key /etc/kubernetes/pki/etcd/server.key member remove 289ed62da3c6e9e5
Member 289ed62da3c6e9e5 removed from cluster d4913a539ea2384e

Y luego reincorporarse a las obras.

esto puede suceder si kubeadm reset se interrumpe y no se pudo eliminar el nodo del kubeadm CM.
en tal caso, debe eliminarlo manualmente de kubeadm CM.

Entonces, si elimino el nodo con kubectl delete node foobar , no
eliminarlo del miembro etcd? Pero si hago kubeadm reset en el nodo que quiero
para eliminar, entonces lo hace? 🙄

El miércoles 30 de octubre de 2019 a las 13:27 Lubomir I. Ivanov, [email protected]
escribió:

esto puede suceder si el restablecimiento de kubeadm se interrumpe y no se pudo eliminar el
nodo del kubeadm CM.
en tal caso, debe eliminarlo manualmente de kubeadm CM.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZL3Q4E2FMPZYKYNOV53QRF4SXA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVREBWG43 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AF7BZL4EOZV7GQYNQOM3773QRF4SXANCNFSM4GIIZTPA
.

"kubeadm reset" debería eliminarlo del kubeadm CM, pero también es necesario llamar a "kubectl delete node", lo que elimina el objeto API de nodo.

En mi caso, eliminar el nodo del mapa de configuración no lo eliminó del
etcd cluster que necesitaba manualmente etcdctl delete member .

El jueves 31 de octubre de 2019 a las 16:28, Lubomir I. Ivanov [email protected]
escribió:

"kubeadm reset" debería eliminarlo del kubeadm CM, pero llamando a "kubectl
También se necesita eliminar nodo ", lo que elimina el objeto API de nodo.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubeadm/issues/1300?email_source=notifications&email_token=AF7BZLZVF7FFVA3LWINJZW3QRL2TLA5CNFSM4GIIZTPKYY3PNVWWK3TUL52HS4DFVDVREXWJWK3TUL52HS4DFVDVREXG43VM2
o darse de baja
https://github.com/notifications/unsubscribe-auth/AF7BZL2KB3GVLTFKQTJTYXLQRL2TLANCNFSM4GIIZTPA
.

kubeadm reset también debería eliminar el miembro etcd del clúster etcd.
intente ejecutarlo con, por ejemplo, --v = 5 y vea lo que hace.

sin embargo, tenga en cuenta que kubeadm reset es un comando de mejor esfuerzo, por lo que si falla por alguna razón, solo puede imprimir una advertencia.

por lo que kubectl delete node no lo elimina de etcd. En cambio, ejecutar en el nodo kubeadm reset hace.
suena roto para mí, creo que kubectl delete node debería eliminarlo de etcd también. ¿O me estoy perdiendo un caso de uso obvio?
tal vez preguntando si también debería eliminarse de allí?
De todos modos gracias por la aclaración @ neolit123 , primero lo

por lo que hay diferentes responsabilidades.
kubectl delete node, elimina el objeto API de Node; debe hacer esto cuando esté realmente seguro de que ya no quiere el nodo alrededor,
antes de eso, debe llamar a kubeadm reset en ese nodo. lo que hago es limpiar el estado en el disco y también elimina el miembro etcd (si se trata de un nodo del plano de control y si está utilizando la opción predeterminada donde las instancias etcd se ejecutan por nodo del plano de control)

kubeadm reset restablece el nodo, pero no elimina el objeto Node por un par de razones:

• reset simplemente restablece el nodo y puede volver a unirse a él. el nombre del nodo permanece reservado.
• el nodo en sí no tiene suficientes privilegios para eliminar su objeto Nodo. esto es responsabilidad del propietario del "admin.conf" (por ejemplo, administrador).

kubeadm reset es un comando de mejor esfuerzo

Con respecto a esto: cuando el kubeadm reset no se completa por cualquier motivo (incluido un error del servidor subyacente para que el restablecimiento de kubeadm nunca se ejecute en primer lugar), ¿hay alguna opción para reconciliar manualmente el estado además de la edición manual? el objeto de mapa de configuración kubeadm-config y eliminar el nodo?

Si el nodo tiene fallas graves y no puede llamar a kubeadm reset en él, se requieren pasos manuales. tendrías que:
1) elimine la IP del plano de control de kubeadm-config CM ClusterStatus
2) elimine el miembro etcd usando etcdctl
3) elimine el objeto Node usando kubectl (si ya no quiere el Node cerca)

1 y 2 se aplican solo a los nodos del plano de control.

¿Hay alguna forma de automatizar esta conmutación por error si no se puede ejecutar kubeadm reset?

Mismos problemas en 1.9. Gracias por las soluciones.