Estoy teniendo el mismo problema. También intenté eliminar Network ARGS como se sugirió en otro problema. Todavía se cuelga en waiting for control plane to be ready .

¿Recargaste Daemon y reiniciaste el servicio kubelet después de hacer los cambios? Funcionó después de cambiar el controlador y comentar la red. El avión de control tarda de 10 a 11 minutos en estar listo por primera vez para mí, sugeriría dejarlo durante 15 minutos por primera vez.

Recargué el daemon y reinicié el servicio kubelet cada vez. Incluso dejé la configuración sin tocar durante toda la noche, pero todavía estaba esperando el avión de control.

Recargué Daemon ( systemctl daemon-reload ) y también reinicié kubelet. Ejecuto kubeadm reset , edito la configuración del servicio, vuelvo a cargar el daemon y luego ejecuto kubeadm init .

Los contenedores acoplables Apserver y etcd no se ejecutan después de comentar las opciones de red. También intenté instalar weave-net manualmente para que se llenara el directorio de configuración de cni, pero tampoco funcionó. Para hacer esto, instalé tejido, ejecuté weave setup y weave launch . Realmente no sé cómo Kubeadm configura Docker para usar la configuración de CNI, pero tal vez me falte un paso aquí.

Parece que kubelet no puede acceder al servidor api de kube.

Noté que etcd no pudo escuchar en el puerto 2380, seguí estos pasos nuevamente y mi clúster se inició:

• Ejecute kubeadm reset para eliminar los cambios realizados en el servidor.
• Vuelve la máquina al estado inicial. Reinstalando kubeadm (para recuperar los archivos de configuración originales).
• Elimine los contenedores docker relacionados con kubernetes, si los hay.
• Obtener e instalar tejido. No lo ejecutes.
• Reinicie el servidor.
• Asegúrese de que kubelet no se ejecute.
• Ejecute weave setup y weave launch .
• Ejecute kubeadm init .

Si quieres deshacerte de manejar el tejido a mano...

• Ejecutar weave reset
• Aplique el complemento weave para kubernetes 1.6.
• Reinicie el servidor.

Kubeadm join debería funcionar en otros servidores.

@Yengas ¿Puede proporcionar más detalles sobre los pasos de tejido? ¿Los ejecutó en todos los nodos, o solo en el maestro?

@jruels solo el nodo maestro. Weave es solo un binario. El comando de configuración sin ningún argumento, descarga imágenes de la ventana acoplable de tejido y crea la configuración de CNI. El comando de lanzamiento sin ningún argumento inicia los contenedores de tejido solo en el host.

@Yengas Todavía no estoy seguro, a qué te refieres con - "obtener e instalar tejido. No ejecutarlo" Obviamente no puedo hacer kubectl apply -f https://git.io/weave-kube-1.6 entonces, ¿cómo instalo tejido? ?

¿Qué dicen los registros de apserver?

@rushabh268
Para instalar Weave, ejecute lo siguiente en el maestro
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
Entonces corre
weave setup
Cuando eso se complete, ejecute
weave launch

no necesitas hacer eso. kubectl apply -f https://git.io/weave-kube-1.6 debería ser suficiente.

Los registros del servidor API dicen exactamente lo mismo que mencioné en el error. Además, no puedo hacer kubectl porque Kubernetes no está instalado

@jruels ¡Lo probaré y actualizaré este hilo!

En la descripción del error hay registros de kubeadm y registros de kubelet. No hay registros de apserver.

@mikedanese ¿Cómo obtengo los registros del servidor ap?
@jruels Puedo mencionar el tejido
@Yengas Incluso después de seguir sus pasos, veo el siguiente error en los registros de kubelet:
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

Además, detuve el cortafuegos, así que no estoy seguro de por qué me rechazan la conexión.

Tengo el mismo problema informado aquí.

Recorte de los mensajes de mi sistema (Master Node) mientras estaba atascado, por si acaso, señala algo. Por cierto, estoy realizando esto en Linode.

12 de abril 02:10:00 auditoría localhost: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? dir=? terminal=? res=éxito'
12 de abril 02:10:00 auditoría localhost: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? dir=? terminal=? res=éxito'
12 de abril 02:10:00 auditoría localhost: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? dir=? terminal=? res=éxito'
12 de abril 02:10:00 localhost systemd: kubelet.service: se acabó el tiempo de espera del servicio, se reinicia la programación.
12 de abril 02:10:00 localhost systemd: Kubelet detenido: el agente de nodo de Kubernetes.
12 de abril 02:10:00 localhost systemd: Kubelet iniciado: el agente de nodo de Kubernetes.
12 de abril 02:10:00 localhost systemd: Iniciando la herramienta de contabilidad de actividad del sistema...
12 de abril 02:10:00 auditoría localhost: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? dir=? terminal=? res=éxito'
12 de abril 02:10:00 auditoría localhost: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? dir=? terminal=? res=éxito'
12 de abril 02:10:00 localhost systemd: herramienta de contabilidad de actividad del sistema iniciada.
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.924529 3445 feature_gate.go:144] puertas de características: mapa[]
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.928973 3445 docker.go:364] Conexión a docker en unix:///var/run/docker.sock
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.929201 3445 docker.go:384] Inicie el cliente docker con tiempo de espera de solicitud = 2m0s
12 de abril 02:10:00 localhost kubelet: W0412 02:10:00.941088 3445 cni.go:157] No se puede actualizar la configuración de cni: No se encontraron redes en /etc/cni/net.d
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.948892 3445 manager.go:143] cAdvisor ejecutándose en contenedor: "/system.slice"
12 de abril 02:10:00 localhost kubelet: W0412 02:10:00.974540 3445 manager.go:151] no se puede conectar al servicio Rkt api: rkt: no se puede tcp Marque el servicio rkt api: marque tcp [::1]:15441: getsockopt: conexión rechazada
12 de abril 02:10:00 localhost kubelet: I0412 02:10:00.997599 3445 fs.go:117] Particiones del sistema de archivos: map[/dev/root:{mountpoint:/var/lib/docker/devicemapper major:8 minor:0 fsType:ext4 blockSize:0 }]
Abr 12 02:10:01 localhost kubelet: I0412 02: 10: 01,001662 3,445 manager.go: 198] Máquina: { NumCores: 1 Cpu Frecuencia: 2799998 Memor yCapacity: 1037021184 MachineID: 5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID: 5e9a9a0b58984bfb8766dba9afa8a191 IdInicio: 7ed1a6ff-9848- 437b-9460-981eeefdfe5a Sistemas de archivos:[{Dispositivo:/dev/root Capacidad:15447539712 Tipo:vfs Inodes:962880 HasInodes:true }] DiskMap:map [43:0:{ Nombre:nbd0 Mayor:43 Menor:0 Tamaño:0 Programador: ninguno } 43:11: { Nombre: nbd11 Mayor: 43 Menor: 11 Tamaño: 0 Programador: ninguno } 43:12: { Nombre: nbd12 Mayor: 43 Menor: 12 Tamaño: 0 Programador: ninguno } 43:15: { Nombre: nbd15 Mayor: 43 Menor: 15 Tamaño: 0 Programador: ninguno } 43: 7: { Nombre: nbd7 Mayor: 43 Menor: 7 Tamaño: 0 Programador: ninguno } 8: 0: { Nombre: sda Mayor: 8 Menor :0 Tamaño:15728640000 Programador:cfq } 252:0:{ Nombre:dm-0 Mayor:252 Menor:0 Tamaño:107374182400 Programador:ninguno } 43:1:{ Nombre:nbd1 Mayor:43 Menor:1 Tamaño:0 Programador :ninguno } 43:13:{ Nombre:nbd13 Mayor:43 Menor:13 Tamaño:0 Programador:ninguno } 43:8:{ Nombre:nbd8 Mayor:43 Menor:8 Tamaño:0 Programador:ninguno } 8: 16:{ Nombre:sdb Mayor:8 Menor:16 Tamaño:536870912 Programador:cfq } 9:0:{ Nombre:md0 Mayor:9 Menor:0 Tamaño:0 Programador:ninguno } 43:3:{ Nombre:nbd3 Mayor: 43 Menor:3 Tamaño:0 Programador:ninguno } 43:9:{ Nombre:nbd9 Mayor:43 Menor:9 Tamaño:0 Programador:ninguno } 43:10:{ Nombre:nbd10 Mayor:43 Menor:10 Tamaño:0 Programador :ninguno } 43:14:{ Nombre:nbd14 Mayor:43 Menor:14 Tamaño:0 Programador:ninguno } 43:2:{ Nombre:nbd2 Mayor:43 Menor:2 Tamaño:0 Programador:ninguno } 43:4:{ Nombre: nbd4 Mayor: 43 Menor: 4 Tamaño: 0 Programador: ninguno } 43: 5: { Nombre: nbd5 Mayor: 43 Menor: 5 Tamaño: 0 Programador: ninguno } 43: 6: { Nombre: nbd6 Mayor: 43 Menor: 6 Tamaño:0 Programador:ninguno }] NetworkDevices:[{ Nombre:dummy0 M acAddress:5a :34:bf:e4:23:cc Velocidad:0 Mtu:1500 } { Nombre:eth0 M acAddress:f2 :3c:91: 1f:cd:c3 Velocidad:-1 Mtu:1500 } { Nombre:gre0 M acAddress:00 :00:00:00 Velocidad:0 Mtu:1476 } { Nombre:gretap0 M acAddress:00 :00:00:00:00 :00 Velocidad:0 Mtu:1462 } { Nombre:ip6_vti0 MAC Dirección:00 :00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Velocidad:0 Mtu:1500 } { Nombre:ip6gre0 MACAddress:00 :00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00 Velocidad:0 Mtu:1448 } { Nombre:ip6tnl0 MACAddress:00 :00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00 Velocidad:0 Mtu:1452 } { Nombre:ip_vti0 Ma
12 de abril 02:10:01 localhost kubelet: cAddress:00 :00:00:00 Speed:0 Mtu:1428 } { Name:sit0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 } { Name: teql0 MacAddress: Velocidad:0 Mtu:1500 } { Nombre:tunl0 M acAddress:00 :00:00:00 Velocidad:0 Mtu:1480 }] Topología:[{Id:0 Memoria:1037021184 Núcleos:[{Id:0 Subprocesos :[0] Cachés:[{ Tamaño:32768 Tipo: Nivel de datos:1 } { Tamaño:32768 Tipo:Nivel de instrucción :1 } { Tamaño:4194304 Tipo: Nivel unificado:2 }]}] Cachés:[]}] Clou dProvider:Unknown InstanceType:Unknown I nstanceID:Ninguno }
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.013353 3445 manager.go:204] Versión: {Kern elVersion:4.9.15-x86_64-linode81 Container OsVersion:Fedora 25 (Server Edition) Dock erVersion:1.12. 6 Versión de Cadvisor: Revisión de Cadvisor:}
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.014086 3445 server.go:509] --cgroups-per-qos habilitado, pero --cgroup-root no se especificó. por defecto a /
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.016562 3445 container_manager_linux.go:218] No se admite la ejecución con intercambio activado, deshabilite el intercambio. ¡Este será un error fatal por defecto a partir de K8s v1.6! Mientras tanto, puede optar por hacer que esto sea un error fatal habilitando --experimental-fail-swap-on.
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016688 3445 container_manager_linux.go:245] administrador de contenedores verificado por el usuario especificado cgroup-root existe: /
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016717 3445 container_manager_linux.go:250] Creación del objeto Container Manager basado en Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contain erRuntime:docker Cgroup upsPerQOS:true CgroupRoot:/ Cgr oupDriver:cgroupfs ProtectKerne lDefaults:false EnableCRI:true NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl localizable:map [pods:{}] Kub eReserved:map [] Syste mReserved:map [] HardEvictionThresholds:[{ Signal:memory.disponible Operador :LessThan Valor:{ Cantidad:100Mi P orcentaje:0 } Gr acePeriod:0s MinReclaim:}]} ExperimentalQO SReservado:mapa []}
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016943 3445 kubelet.go:255] Agregar archivo de manifiesto: /etc/kubernetes/manifests
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.016966 3445 kubelet.go:265] Viendo apiserver
12 de abril 02:10:01 localhost kubelet: E0412 02:10:01.025058 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: No se pudo enumerar *v1.Node: Obtener https: //50.116.13.214 :6443/api/v1/nodes?fieldSelector=metadata.name%3Dli471-214.members.linode.com&resourceVersion=0: marcar tcp 50.116.13.214:6443: getsockopt: conexión rechazada
12 de abril 02:10:01 localhost kubelet: E0412 02:10:01.025342 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Error al incluir *v1.Servicio: Obtener https: //50.116.13.214 :6443/api/v1/services?resourceVersion=0: marcar tcp 50.116.13.214:6443: getsockopt: conexión rechazada
12 de abril 02:10:01 localhost kubelet: E0412 02:10:01.025397 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Error al incluir *v1.Pod: Obtener https://50.116.13.214 :6443/api/v1/pods?fieldSelector=spec.nodeName%3Dli471-214.members.linode.com&resourceVersion=0: marcar tcp 50.116.13.214:6443: getsockopt: conexión rechazada
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.026574 3445 kubelet_network.go:70] Modo de horquilla establecido en "promiscuous-bridge" pero kubenet no está habilitado, recurriendo a "hairpin-veth"
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.026599 3445 kubelet.go:494] Modo de horquilla establecido en "horquilla-veth"
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.026661 3445 cni.go:157] No se puede actualizar la configuración de cni: No se encontraron redes en /etc/cni/net.d
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.034194 3445 cni.go:157] No se puede actualizar la configuración de cni: No se encontraron redes en /etc/cni/net.d
12 de abril 02:10:01 localhost kubelet: W0412 02:10:01.043157 3445 cni.go:157] No se puede actualizar la configuración de cni: No se encontraron redes en /etc/cni/net.d
12 de abril 02:10:01 localhost kubelet: I0412 02:10:01.043183 3445 docker_service.go:187] Docker cri networking administrado por cni
12 de abril 02:10:01 localhost kubelet: error: error al ejecutar Kubelet: error al crear kubelet: configuración incorrecta: controlador kubelet cgroup: "cgroupfs" es diferente del controlador docker cgroup: "systemd"
12 de abril 02:10:01 auditoría localhost: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? dir=? terminal=? res=fallido'
12 de abril 02:10:01 localhost systemd: kubelet.service: Proceso principal cerrado, código=salido, estado=1/FALLA
12 de abril 02:10:01 localhost systemd: kubelet.service: la unidad entró en estado fallido.
12 de abril 02:10:01 localhost systemd: kubelet.service: error con el resultado 'código de salida'.

@acloudiator Creo que necesita configurar cgroup-driver en la configuración de kubeadm.

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

Y luego reinicie el servicio kubelet

Sería genial si kubeadm pudiera solucionar de alguna manera el problema de configuración de cgroup.
Ideas:

• Abortar la inicialización en caso de mala configuración
• Verifique la configuración de Docker de antemano y use lo que está usando Docker (no estoy seguro de las implicaciones aquí)

Solo una actualización, cualquier solución que probé no funcionó. ¡Así que me mudé a CentOS 7.3 para el maestro y funciona de maravilla! Sin embargo, mantuve a los minions en CentOS 7.2.

@rushabh268 hola, tengo el mismo problema en Redhat Linux 7.2. Después de actualizar systemd, este problema está resuelto. Puede intentar actualizar systemd antes de la instalación.
yum update -y systemd
y el registro de errores de kubelet:
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

Encontré este problema en CentOS 7.3. El problema desaparece después de desinstalar docker-ce y luego instalar docker-io.
No estoy seguro si es la causa raíz. De todos modos, puede intentarlo si los métodos anteriores no funcionan.

@ZongqiangZhang Tengo docker 1.12.6 instalado en mis nodos. @juntaoXie También intenté actualizar systemd y todavía está atascado

Así que he estado ejecutando Centos 7.3 con 1.6.4 sin problemas en varias máquinas.

¿Te aseguraste de desactivar selinux?

@timothysc tengo CentOS 7.2 y no CentOS 7.3 y selinux está deshabilitado

Tengo una versión de CentOS Linux 7.3.1611 (Core) y KubeAdm 1.6.4 no funciona.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

Producción:

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[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"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

@paulobezerr , ¿puede compartir un poco más de registros de kube-apiserver ? (los que están al final de tu comentario)

¿Las filas sobre lo que ya ha incluido mencionan la misma dirección IP? Intenté ejecutar k8s en dos KVM nuevos recientemente, uno con Ubuntu 16.04 y otro con CentOS 7.3. Ambos dieron esto:

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

Tenga en cuenta que primero la dirección IP mencionada es x.x.x.x , pero luego localhost se resuelve en y.y.y.y (que en mi caso era una IP pública de otro KVM ubicado en el mismo servidor físico). Pude iniciar kubeadm en Ubuntu al final, pero solo después de instalar dnsmasq de manera similar a https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861. La misma solución en CentOS no ayudó.

¿Puede ser esto un error en kubedns o algo así? Curiosamente, los mismos pasos en las máquinas virtuales de AWS generaron kubeadm. Pero las instancias EC2 son demasiado caras para mis proyectos personales.

Tengo el mismo problema que @paulobezerr.

## Versiones :
kubelet-1.6.4-0.x86_64
kubernetes-cni-0.5.1-0.x86_64
kubectl-1.6.4-0.x86_64
kubeadm-1.6.4-0.x86_64
docker-cliente-1.12.6-28.git1398f24.el7.centos.x86_64
docker-common-1.12.6-28.git1398f24.el7.centos.x86_64
docker-1.12.6-28.git1398f24.el7.centos.x86_64

ENTONCES
uname -r > 3.10.0-229.1.2.el7.x86_64
cat /etc/redhat-release > Versión de CentOS Linux 7.3.1611 (Núcleo)

## Pasos seguidos:

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## registros del servidor API:
--> 37.247.XX.XXX es la IP pública

[tranquilo] 2017/06/08 10:45:19 log.go:30: [tranquilo/arrogante] la lista está disponible en https://37.247.XX.XXX :6443/swaggerapi/
[tranquilo] 2017/06/08 10:45:19 log.go:30: [tranquilo/arrogante] https://37.247.XX.XXX :6443/swaggerui/ está asignado a la carpeta /swagger-ui/
E0608 10:45:19.429839 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *api.Secret: Obtener https://localhost : 6443/api/v1/secrets?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.430419 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *api.ResourceQuota: Obtener https://localhost : 6443/api/v1/resourcequotas?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.430743 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *api.ServiceAccount: Obtener https://localhost : 6443/api/v1/serviceaccounts?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.431076 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *storage.StorageClass: Obtener https://localhost : 6443/apis/storage.k8s.io/v1beta1/storageclasses?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.431377 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *api.LimitRange: Obtener https://localhost : 6443/api/v1/limitranges?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.431678 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *rbac.RoleBinding: Obtener https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.431967 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *rbac.ClusterRoleBinding: Obtener https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.432165 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *api.Namespace: Obtener https://localhost : 6443/api/v1/namespaces?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.432386 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *rbac.ClusterRole: Obtener https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterroles?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.432619 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Error al incluir *rbac.Role: Obtener https://localhost : 6443/apis/rbac.authorization.k8s.io/v1beta1/roles?resourceVersion=0: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
I0608 10:45:19.481612 1 serve.go:79] Servicio seguro en 0.0.0.0:6443
W0608 10:45:19.596770 1 storage_extensions.go:127] error de sincronización de recursos de terceros: Obtenga https://localhost :6443/apis/extensions/v1beta1/thirdpartyresources: marque tcp 108.59.253.109:6443: getsockopt: conexión rechazada
E0608 10:45:19.596945 1 client_ca_hook.go:58] Publicar https://localhost :6443/api/v1/namespaces: marcar tcp 108.59.253.109:6443: getsockopt: conexión rechazada
F0608 10:45:19.597174 1 controller.go:128] No se puede realizar la verificación de asignación de IP inicial: no se puede actualizar el bloque de IP del servicio: obtenga https://localhost : 6443/api/v1/services: marque tcp 108.59.253.109: 6443: getsockopt: conexión rechazada

@albpal Tuve exactamente el mismo problema hace una semana: dial tcp X.X.X.X mostraba una dirección IP extraña y no pude resolver esto en CentOS incluso después de instalar dnsmasq y cambiar a los servidores DNS de Google en lugar del DNS de mi proveedor de alojamiento. Solo por curiosidad: ¿puede verificar si esa dirección IP incorrecta que está viendo está en el mismo centro de datos que su VM? Puede usar http://ipinfo.io para estimar eso con cierto grado de certeza o simplemente rastrear la ruta.

En mi caso, la dirección IP incorrecta se refería a otro KVM en el mismo servidor físico. Puede tener algo que ver con DNS en una máquina física, lo que puede requerir una solución dentro de kube api o kube dns; de lo contrario, iniciar un clúster se convierte en un gran dolor para muchos recién llegados. Desperdicié algunas tardes antes de darme cuenta de que dial tcp tenía una IP incorrecta en los registros, lo cual fue una primera experiencia bastante triste con k8s. Todavía no tengo una buena solución lista para usar para CentOS KVM en mi proveedor de alojamiento ( firstvds.ru ).

¿Qué puede causar este extraño desajuste en las direcciones IP?

@albpal Abra un nuevo problema, lo que describió y de qué se trata este problema son problemas separados (creo, según esa información)

@kachkaev Acabo de verificar lo que sugirió.

Descubrí que la IP incorrecta termina en un CPANEL: vps-1054290-4055.manage.myhosting.com.

Por otro lado, la IP pública de mi VPS es de Italia y esta IP incorrecta es de EE. UU.... así que, a pesar de que la IP incorrecta tiene algo relacionado con el alojamiento (CPANEL), no parece referirse a otro KVM en el mismo servidor físico.

¿Pudiste instalar k8s?

@luxas tengo el mismo comportamiento pero copié los registros de la ventana acoplableSalida también.

Los resultados de /var/log/messages y kubeadm init son los mismos que los del problema original.

@albpal , ¿entonces su VM y esa segunda máquina están en CPANEL? Buena señal, porque entonces mi caso es el mismo! El hecho de que fuera la misma máquina física podría ser solo una coincidencia.

Usé dos KVM en mis experimentos, uno con Ubuntu 16.04 y otro con CentOS 7.3. Ambos tenían el mismo problema con la dirección IP dial tcp . Al final pude iniciar kubeadm en Ubuntu al deshacerme de los servidores DNS de mi proveedor. La solución se basó en los consejos de ​crilozs :

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

¡Esto trajo la dirección IP correcta después dial tcp en los registros en Ubuntu y kubeadm se inicializó después de un par de minutos! Intenté configurar dnsmasq en CentOS de la misma manera, pero esto no resolvió el problema. Pero soy un novato total en este sistema operativo, por lo que puede ser que me haya olvidado de reiniciar algún servicio o limpiar algún caché. ¡Prueba esta idea!

En cualquier caso, se siente mal hacer un paso adicional de reconfiguración de DNS porque es muy confuso (no soy un tipo de servidor/devops y toda la investigación que realicé casi me hizo llorar: temeroso:). Espero que kubeadm alguna vez pueda detectar si los servidores DNS del proveedor funcionan de manera extraña y corregir automáticamente lo que sea necesario en el clúster.

Si alguien del equipo de k8s está dispuesto a ver lo que está sucediendo, estaré encantado de compartir el acceso raíz en un par de KVM FirstVDS nuevos. ¡Solo envíame un correo electrónico o DM en twitter!

Gracias @kachkaev ! Intentaré mañana

cc @kubernetes/sig-network-bugs ¿Tiene alguna idea de por qué falla la resolución de DNS anterior?

Gracias @kachkaev , intentaremos investigarlo. No creo que sea realmente culpa de kubeadm per se, pero si muchos usuarios están atascados en la misma configuración incorrecta, podríamos agregarlo a los documentos de resolución de problemas más o menos...

Es muy probable que mis registros sean registros de @albpal .
Pero probaré el dnsmasq. ¡Gracias a todos!

@kachkaev , no funciona. Mismo problema 😢
Se adjunta bitácora completa.

registro.txt

ya lo he podido arreglar!! ¡Muchas gracias @kachkaev por tus consejos!

Creo que el problema era:

### Escenario:
Un VPS con el siguiente esquema de configuración:

resolv.conf
[ root@apalau ~]# gato resolv.conf
servidor de nombres 8.8.8.8
servidor de nombres 8.8.4.4
servidor de nombres 2001:4860:4860::8888
servidor de nombres 2001:4860:4860::8844

¡No hay ningún dominio de búsqueda!

Hospedadores
[ raíz@apalau ~]# gato /etc/hosts
127.0.0.1 localhost.localdomain localhost
37.XXX.XX.XXX nombre.vpshosting.com

Según los registros, el contenedor de kubernetes intenta conectarse a:

Obtenga https://localhost :6443/api/v1/secrets?resourceVersion=0

Y cuando pido:
$ nslookup "localhost.$(nombre de host -d)"
La IP que obtengo es la incorrecta, es decir, 108.59.253.109.

Entonces, creo que estos contenedores están tratando de resolver localhost (sin dominio) y obtienen una IP incorrecta. Probablemente porque "localhost.$(hostname -d)" se está resolviendo en esa IP, lo que creo que sucederá en casi todos los servicios de VPS.

## Lo que hice para solucionar el problema en un VPS CentOS 7.3 (aparte de los pasos que se muestran en https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm):

Como raíz:

1. reinicio de kubeadm
2. yum instalar dnsmasq
3. cp /etc/resolv.conf ~/resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. echo -e "servidor de nombres 127.0.0.1\nservidor de nombres $(nombre de host -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr +i /etc/resolv.conf
8. echo -e "servidor=8.8.8.8\nservidor=8.8.4.4" > /etc/dnsmasq.conf
9. echo -e "$(nombre de host -i)\tlocalhost.$(nombre de host -d)" >> /etc/hosts
10. reinicio del servicio dnsmasq
11. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld
12. inicio de kubeadm

Agregué el nombre de host -i en el paso 5 porque, si no lo hago, Docker agregará 8.8.8.8 a resolv.conf en los contenedores.

Espero que ayude a otros también.

¡¡Gracias!!

¡Me alegra escuchar eso @albpal! Seguí sus pasos antes kubeadm init y el clúster finalmente se inicializó dentro de mi FirstVDS KVM de prueba con CentOS 7.3. Lo único adicional que tuve que hacer fue detener y deshabilitar firewalld ya que estaba bloqueando las conexiones externas al puerto 6443:

systemctl disable firewalld
systemctl stop firewalld

_No recomiendo hacer esto porque no estoy al tanto de las consecuencias; esto solo me ayudó a completar una prueba en un sistema operativo que normalmente no uso._

Ahora me pregunto qué se podría hacer para facilitar el proceso de instalación para los novatos como yo. El camino entre quedarse atascado en Created API client, waiting for the control plane to become ready y resolver las cosas sigue siendo enorme, especialmente si tenemos en cuenta el tiempo necesario para desenterrar este problema y leer todos los comentarios. __¿Qué me pueden sugerir?__

@paulobezerr por lo que veo en su archivo adjunto, creo que su problema es ligeramente diferente. Mis registros de apserver contienen algo como:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

mientras los tuyos dicen:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

(en el primer caso es localhost / RANDOM_IP , mientras que en el segundo caso siempre es 10.X.X.X )

Desafortunadamente, no sé qué aconsejar excepto probar varios --apiserver-advertise-address=??? cuando kubeadm init (ver documentos ). Mi experiencia práctica con k8s acaba de llegar a 10 días, la mayoría de los cuales fueron intentos vanos de iniciar un clúster de un solo nodo en FirstVDS :-)

¡Espero que lo solucionen y compartan la solución con otros!

@kachkaev Olvidé mencionar que apliqué la siguiente regla de firewall:

$ firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld

Funciona bien en mi entorno cuando se aplica esta regla sin desactivar el firewall. Lo agregaré a mi comentario anterior para recopilar todos los pasos necesarios.

@juntaoXie Gracias. Actualizar la versión de systemd según su comentario funcionó para mí.

Sigo teniendo este problema durante dos días, estoy ejecutando todo esto detrás de un proxy y no parece haber ningún problema.
kubeadm init espera a que el plano de control esté listo. Cuando hago docker ps, los contenedores se extraen y se ejecutan, pero no hay puertos asignados (no sé si se supone que debe hacerlo, pero está bien). etcd también está funcionando bien. Sin embargo, cuando miro mi servicio kubelet, dice No se puede actualizar la configuración de cni: No se encontraron redes en /etc/cni/net.d que https://github.com/kubernetes/kubernetes/issues/43815 dice que está bien, usted necesita aplicar una red cni.
Lo cual hago según https://www.weave.works/docs/net/latest/kubernetes/kube-addon/. Ahora, kubectl dice que 8080 fue rechazado. ¿Especificó el host o puerto correcto? Parece un problema del huevo y la gallina, ¿cómo aplico una red cni cuando mi kubeadm init se bloquea? esto es tan confuso

Esto tampoco es un problema de cgroup, tanto docker como mi servicio kubelet usan systemd.

FWIW, tuve este mismo problema en GCP. Intenté usar Ubuntu 16.04 y CentOS usando los siguientes comandos en un proyecto limpio:

$ instancias informáticas de gcloud create test-api-01 --zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nodo 1 para pruebas de API'

$ instancias informáticas de gcloud create test-api-02 --zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nodo 2 para pruebas de API'

$ instancias informáticas de gcloud create test-api-03 --zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' nodo 3 para pruebas de API'

$ apt-obtener actualización

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key agregar -

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

$ systemctl reiniciar kubelet

$ inicio de kubeadm

Entonces, después de golpearme la cabeza contra él durante varias horas, terminé diciendo:

$ gcloud beta container --project "weather-177507" clusters create "weather-api-cluster-1" --zone "us-west1-a" --username="admin" --cluster-version "1.6.7" --tipo de máquina "f1-micro" --tipo de imagen "COS" --tamaño de disco "100" --ámbitos " https://www.googleapis.com/auth/compute "," https:// www.googleapis.com/auth/devstorage.read_only "," https://www.googleapis.com/auth/logging.write "," https://www.googleapis.com/auth/monitoring.write "," https://www.googleapis.com/auth/servicecontrol "," https://www.googleapis.com/auth/service.management.readonly "," https://www.googleapis.com/auth/trace. agregar " --num-nodes "3" --network "predeterminado" --enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

Pude poner en marcha un clúster donde no podía a partir de una imagen en blanco.

Incluso me enfrento al mismo problema con la versión de Kubeadm:

se está atascando
[apiclient] Created API client, waiting for the control plane to become ready

Mismo problema que @paulobezerr : mi entorno: CentOS 7.4.1708 versión de kubeadm: &version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean ", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compilador:"gc", Plataforma:"linux/amd64"}

Para mí, este problema no se estaba ejecutando con SELinux deshabilitado. La pista eran sus pasos, el comentario:

edite /etc/selinux/config y establezca SELINUX=disabled

Los pasos de instalación aquí (https://kubernetes.io/docs/setup/independent/install-kubeadm/) para CentOS dicen:
"Se requiere deshabilitar SELinux ejecutando setenforce 0 para permitir que los contenedores accedan al sistema de archivos del host"
pero no menciona (al menos en la pestaña CentOS/RHEL/Fedora) que debe editar /etc/selinux/config y establecer SELINUX=disabled

Para mí, aunque había ejecutado setenforce 0, seguía recibiendo los mismos errores. Editando /etc/selinux/config y configurando SELINUX=disabled, luego reiniciando lo arreglé para mí.

Parece que hay muchos problemas (potencialmente ortogonales) en juego aquí, por lo que estoy dispuesto a que no dejemos que las cosas se desvíen. Hasta ahora parece que hemos identificado 3 problemas:

1. El DNS no puede resolver localhost correctamente en algunas máquinas. @kachkaev @paulobezerr ¿Lograste arreglar esto? Me pregunto cómo hacer esto más explícito en nuestros requisitos, ¿alguna idea?

2. Coincidencia incorrecta cgroup-driver entre kubelet y Docker. Deberíamos agregar esto a nuestra lista de requisitos.

3. SELinux no está deshabilitado. Deberíamos agregar esto a nuestra lista de requisitos.

Una vez que los tres se aborden con relaciones públicas, tal vez deberíamos cerrar esto y dejar que las personas que tengan problemas en el futuro creen sus propios problemas. Eso nos permitirá recibir información más estructurada y brindar un soporte más granular, en lugar de hacer malabarismos con muchas cosas en un solo hilo. ¿Qué opinas @luxas?

Para mí, fui con docker 17.06 (se recomienda 17.03, pero no está disponible en docker.io) y me encontré con el mismo problema. Actualizar a 17.09 solucionó mágicamente el problema.

Como este hilo se ha vuelto tan largo, y probablemente hay muchos problemas totalmente diferentes, lo más productivo que puedo agregar además del excelente comentario de @jamiehannaford es que abra nuevos problemas específicos con todos los registros / información relevante en caso de que algo falla _con el último kubeadm v1.8_, que detecta automáticamente un estado defectuoso mucho mejor que las versiones anteriores. También hemos mejorado nuestra documentación sobre los requisitos y los casos extremos que, con suerte, ahorrarán tiempo a las personas.

¡Gracias a todos!

tuve el mismo problema con 1.8 en CENTOS 7 con 1.8? alguien tuvo el mismo problema o sabe como solucionarlo.

@rushins Si desea obtener ayuda con el posible problema que está viendo, abra un nuevo problema aquí con suficientes detalles.

Tengo el mismo problema que @rushabh268, que es connection refused y no localhost:6443/api .
Finalmente lo resolví comentando el dominio buscando search xxx.xx.xxxx.org .

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

Env:
-> CentOS-7-x86_64-Minimal-1708
-> K8 v1.9.2
-> Ventana acoplable v17.12.0.ce
-> en Red privada xxx.xx.xxxx.org

Por el amor de Dios, agregue esto a los documentos. He estado tratando de configurar mi clúster durante muchas noches después del trabajo con el pretexto de "divertirme y jugar con la tecnología". El nodo maestro me desanimó y no obtuve la IP correcta cuando ejecuté nslookup localhost.

Gracias a @kachkaev por la solución.