Kubeadm: La ejecución de comprobaciones previas al vuelo se bloquea

Con parámetro v10.

[ root@vm03 etcd]# kubeadm unirse a vm10.andrefagundes. org: 6443 --token 07nh7g.v8p5fcs61fn3o2h4 --discovery-token-ca-cert-hash SHA256: 039a5f9229dafe39d4a51af6899c20adff1de5dda23f780ac9b896e95f95623a --experimental-plano de control clave --certificate-cf3c8ca4f74751bfe7fc9d3e00e03a37619d36a6d6fb79fb5ba3645d74dd7bf4 -v10
I0401 00:34:08.531961 16893 join.go:367] [preflight] encontró NodeName vacío; usando el nombre de host del sistema operativo como nombre de nodo
I0401 00:34:08.532014 16893 join.go:371] [preflight] encontró la dirección de publicidad vacía; utilizando la dirección IP de la interfaz predeterminada como publicidadDirección
I0401 00:34:08.532048 16893 initconfiguration.go:105] detectado y usando el zócalo CRI: /var/run/dockershim.sock
I0401 00:34:08.532179 16893 interface.go:384] Buscando rutas predeterminadas con direcciones IPv4
I0401 00:34:08.532187 16893 interface.go:389] La ruta predeterminada transita la interfaz "eth0"
I0401 00:34:08.532324 16893 interface.go:196] La interfaz eth0 está activa
I0401 00:34:08.532380 16893 interface.go:244] La interfaz "eth0" tiene 4 direcciones: [192.168.122.103/24 fe80::a3c0:2a34:91f2:e0eb/64 fe80::8439:c3eb:5848:c1f2/ 64 fe80::4381:b4a5:5836:a0e1/64].
I0401 00:34:08.532399 16893 interface.go:211] Comprobando la dirección 192.168.122.103/24.
I0401 00:34:08.532407 16893 interface.go:218] IP encontrada 192.168.122.103
I0401 00:34:08.532415 16893 interface.go:250] Se encontró una dirección IPv4 válida 192.168.122.103 para la interfaz "eth0".
I0401 00:34:08.532421 16893 interface.go:395] IP activa encontrada 192.168.122.103
[preflight] Ejecución de comprobaciones previas al vuelo
I0401 00:34:08.532495 16893 preflight.go:90] [preflight] Ejecución de comprobaciones generales
I0401 00:34:08.532539 16893 checks.go:254] validando la existencia y el vacío del directorio /etc/kubernetes/manifests
I0401 00:34:08.532570 16893 checks.go:292] validando la existencia del archivo /etc/kubernetes/kubelet.conf
I0401 00:34:08.532579 16893 checks.go:292] validando la existencia del archivo /etc/kubernetes/bootstrap-kubelet.conf
I0401 00:34:08.532586 16893 checks.go:105] validando el tiempo de ejecución del contenedor
I0401 00:34:08.580885 16893 checks.go:131] validando si el servicio está habilitado y activo
I0401 00:34:08.638659 16893 checks.go:341] validando el contenido del archivo /proc/sys/net/bridge/bridge-nf-call-iptables
I0401 00:34:08.638724 16893 checks.go:341] validando el contenido del archivo /proc/sys/net/ipv4/ip_forward
I0401 00:34:08.638755 16893 checks.go:653] validando si el intercambio está habilitado o no
I0401 00:34:08.638788 16893 checks.go:382] validando la presencia de IP ejecutable
I0401 00:34:08.638809 16893 checks.go:382] validando la presencia de iptables ejecutables
I0401 00:34:08.638824 16893 checks.go:382] validando la presencia del montaje ejecutable
I0401 00:34:08.638837 16893 checks.go:382] validando la presencia del ejecutable nsenter
I0401 00:34:08.638849 16893 checks.go:382] validando la presencia de ebtables ejecutables
I0401 00:34:08.638860 16893 checks.go:382] validando la presencia del ejecutable ethtool
I0401 00:34:08.638871 16893 checks.go:382] validando la presencia del ejecutable socat
I0401 00:34:08.638883 16893 checks.go:382] validando la presencia del ejecutable tc
I0401 00:34:08.638894 16893 checks.go:382] validando la presencia del toque ejecutable
I0401 00:34:08.638914 16893 checks.go:524] ejecutando todas las comprobaciones
I0401 00:34:08.664826 16893 checks.go:412] comprobando si el nombre de nodo dado es accesible mediante net.LookupHost
I0401 00:34:08.665583 16893 checks.go:622] validando la versión de kubelet
I0401 00:34:08.709573 16893 checks.go:131] validando si el servicio está habilitado y activo
I0401 00:34:08.716270 16893 checks.go:209] validando la disponibilidad del puerto 10250
I0401 00:34:08.716418 16893 checks.go:439] validando si el tipo de conectividad es vía proxy o directa
I0401 00:34:08.716444 16893 join.go:427] [verificación previa] Descubrimiento de información del clúster
I0401 00:34:08.716498 16893 token.go:200] [descubrimiento] Intentando conectarse al servidor API "vm10.andrefagundes. org:6443 "
I0401 00:34:08.716961 16893 token.go:75] [descubrimiento] Creado cliente de descubrimiento de información de clúster, solicitando información de " https://vm10.andrefagundes.org :6443"
I0401 00:34:08.717031 16893 round_trippers.go:419] curl -k -v -XGET -H "Aceptar: aplicación/json, / " -H "User-Agent: kubeadm/v1.14.0 (linux/amd64) kubernetes/ 641856d" ' https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info'
I0401 00:34:08.722405 16893 round_trippers.go:438] OBTENER https://vm10.andrefagundes.org :6443/api/v1/namespaces/kube-public/configmaps/cluster-info 403 Prohibido en 5 milisegundos
I0401 00:34:08.722423 16893 round_trippers.go:444] Encabezados de respuesta:
I0401 00:34:08.722432 16893 round_trippers.go:447] Tipo de contenido: aplicación/json
I0401 00:34:08.722441 16893 round_trippers.go:447] Opciones de tipo de contenido X: nosniff
I0401 00:34:08.722450 16893 round_trippers.go:447] Longitud del contenido: 321
I0401 00:34:08.722458 16893 round_trippers.go:447] Fecha: lunes, 01 de abril de 2019 03:34:08 GMT
I0401 00:34:08.722497 16893 request.go:942] Cuerpo de respuesta: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message ":"configmaps \"cluster-info\" está prohibido: el usuario \" system:anonymous\ " no puede obtener el recurso \"configmaps\" en el grupo API \"\" en el espacio de nombres \"kube-public\""," razón":"Prohibido","detalles":{"nombre":"información del clúster","tipo":"configmaps"},"código":403}
I0401 00:34:08.722937 16893 token.go:83] [descubrimiento] No se pudo solicitar la información del clúster, se intentará de nuevo: [los mapas de configuración "información del clúster" están prohibidos: el usuario " sistema: anónimo " no puede obtener los "mapas de configuración" de recursos en la API grupo "" en el espacio de nombres "kube-public"]

Otra info... vm10.andrefagundes.org es un Haproxy frente a mi plano de control.

Me parece un problema de red.
¿Está seguro de que este nodo de unión tiene conectividad al puerto 6443 en el LB y puede resolver vm10.andrefagundes.org?

Sí, también cambié vm10 para que apunte al plano de control. Vi tráfico en el avión de control que venía monitoreando con TCDUMP.

¿Ve algún error pendiente en los registros de kubelet?

Hay varios errores en los registros. También intenté reinstalar el clúster varias veces y cada vez obtengo diferentes errores. Me estoy dando por vencido. Podemos cerrar el caso. ¡¡Gracias!!

¿La creación de un solo nodo de plano de control + algunos nodos de trabajo funciona para usted o el problema solo ocurre cuando se unen nodos de plano de control adicionales?

El usuario " system:anonymous " no puede obtener el recurso "configmaps" en el grupo API "" en el espacio de nombres "kube-public"","motivo":"Prohibido","detalles":{"nombre":"información del clúster", "tipo":"configmaps"},"código":403

Parece que kubeadm init no crea/configura la información del clúster correctamente
¿Podría compartir los registros de inicio de kubeadm?

Tengo el mismo error después de ejecutar el comando 'kubeadm join ...': Ejecución de comprobaciones previas atascadas. No tengo idea de manejarlo.

Tuve el mismo problema. Necesitaba reiniciar el maestro y luego ejecutar el comando 'kubeadm join ...' nuevamente en los nodos funcionó para mí.

tuve los mismos problemas con kubeadm v1.15 , reiniciar maestro no funciona para mí

tuve los mismos problemas con kubeadm v1.15 , reiniciar maestro no funciona para mí

volver a kubelet y kubeadm v1.13.1 solucionaron estos problemas

asegúrese de llamar a kubeadm init/join con, por ejemplo --v=2 para tener más detalles sobre lo que está pasando.

Me topé con el mismo problema, pero el problema se remonta a la conectividad de red de mi lado con mis demonios keepalived y haproxy que se configuraron incorrectamente para evitar que el nodo maestro de bloqueo se una al clúster a través del servicio API VIP

Vale la pena señalar que ejecutar kubeadm init/join con --v=2 fue la forma en que pude resolverlo.

asegúrese de llamar a kubeadm init/join con, por ejemplo --v=2 para tener más detalles sobre lo que está pasando.

Kubeadm v1.15

unirse a kubeadm .. --v=2

I0802 11:47:31.027812 359 token.go:202] [descubrimiento] No se pudo conectar con el servidor API "": el identificador de token "r5uyqk" no es válido para este clúster o ha caducado. Use "kubeadm token create" en el nodo del plano de control para crear un nuevo token válido

kubeadm init fase upload-certs --upload-certs
token de kubeadm crear

entonces kubeadm se une al éxito

En mi caso, pude unirme con éxito al nodo al detener el firewall en el nodo maestro.

systemctl stop firewall

En mi caso, pude unirme con éxito al nodo al detener el firewall en el nodo maestro.

systemctl stop firewall

Este funcionó a las mil maravillas.
[ root@localhost ~]# kubeadm unirse a 192.168.8.128:6443 --token 38lhr8.kxi5uy8aoy71dj17 --discovery-token-ca-cert-hash sha256:a12c805b8d98f42a256486d27e87463e22aaba190ab8f5bd4ce89b8bb3
[preflight] Ejecución de comprobaciones previas al vuelo
[ADVERTENCIA IsDockerSystemdCheck]: detectó "cgroupfs" como el controlador Docker cgroup. El controlador recomendado es "systemd". Siga la guía en https://kubernetes.io/docs/setup/cri/
[ADVERTENCIA SystemVerification]: esta versión de Docker no está en la lista de versiones validadas: 19.03.1. Última versión validada: 18.09
[preflight] Leyendo la configuración del clúster...
[preflight] FYI: puede mirar este archivo de configuración con 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Descargando la configuración para el kubelet desde el ConfigMap "kubelet-config-1.14" en el espacio de nombres del sistema kube
[kubelet-start] Escribiendo la configuración de kubelet en el archivo "/var/lib/kubelet/config.yaml"
[kubelet-start] Escritura del archivo de entorno de kubelet con banderas en el archivo "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activación del servicio kubelet
[kubelet-start] Esperando a que el kubelet realice el TLS Bootstrap...

Este nodo se ha unido al clúster:

• Se envió una solicitud de firma de certificado a apserver y se recibió una respuesta.
• El Kubelet fue informado de los nuevos detalles de conexión segura.

Ejecute 'kubectl get nodes' en el plano de control para ver este nodo unirse al clúster.

mirando el registro en el OP nuevamente, esto no es un "bloqueo" en la verificación previa, sino que no se puede acceder al mapa de configuración de información del clúster, la única forma en que esto podría suceder si la fase "boostrap-token" de "init" se salta

Mirando informes posteriores, veo problemas de redes y tokens caducados que se incluyen en los elementos de "soporte" y no en los errores.

/soporte de triaje
si tiene preguntas, pruebe stackoverflow, reddit o #kubeadm en k8s slack.

si encuentra un error real, abra un nuevo problema.

En mi caso, pude unirme con éxito al nodo al detener el firewall en el nodo maestro.

systemctl stop firewall

systemctl detener firewalld

Encuentro que no se permitió el tráfico para conectar el nodo maestro.

agregar reglas en sg resolvió mi problema

Tengo el mismo error después de ejecutar el comando 'kubeadm join ...': Ejecución de comprobaciones previas atascadas. No tengo idea de manejarlo.

¿Encontraste alguna solución?

Encuentro que no se permitió el tráfico para conectar el nodo maestro.

agregar reglas en sg resolvió mi problema

¿Qué puerto de entrada permitiste?