El primer mensaje de error: no se puede cargar el archivo CA del cliente /etc/kubernetes/pki/ca.crt: abrir /etc/kubernetes/pki/ca.crt: no existe tal archivo o directorio

El primer mensaje de error: no se puede cargar el archivo CA del cliente /etc/kubernetes/pki/ca.crt: abrir /etc/kubernetes/pki/ca.crt: no existe tal archivo o directorio

hola, aquí hay algunas preguntas:
1) ¿kubeadm init finaliza e imprime un token boostrap?
2) ¿versión en tiempo de ejecución del contenedor?
3) ¿kubelet y kubeadm son la versión 1.12?

/ necesidades-prioritarias-más-evidencia

necesita ejecutar systemctl start kubelet antes de kubeadm init

Estoy experimentando el mismo problema, porque el núcleo de la taza es inferior a 2

mismo problema

@javacppc ¿cómo error code

mismo problema con kubernetes 1.12.2.
@Javacppc ¿cómo

mismo problema

mismo problema

Hola chicos,

Estoy enfrentando el mismo problema aquí, cuando inicio el clúster recibí el mensaje del token, pero no puedo instalar un tejido en la nube:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" The connection to the server 192.168.56.104:6443 was refused - did you specify the right host or port?

Cuando voy a los registros, recibí el mensaje sobre el nombre del nodo:

Dec 02 22:27:55 kubemaster5 kubelet[2838]: E1202 22:27:55.128645 2838 kubelet.go:2236] node "kubemaster5" not found

¿Alguien puede enviarme algo de luz?

¡Gracias!

mi problema está resuelto y en realidad no es un error, es porque un servidor no pudo iniciarse por alguna razón.

"apiserver no pudo iniciarse por alguna razón"? ¿Puedes darnos algunos detalles?

Resolví mi problema hace varios días. Actualización desde 1.11.4 -> 1.12.3. Tengo:

1. api-server : se ejecuta en una interfaz virtual específica con su propia red. ( metal desnudo ).
   Después de kubeadm init/join con la bandera apiserver-advertise-address , comenzó en una interfaz específica, pero los paquetes con configuraciones / controles de estado recorren la ruta estándar de la tabla de enrutamiento (interfaz predeterminada). Se ayudó al parámetro bind-address en /etc/kubernetes/manifests/kube-apiserver.yaml con enlace a la IP de la interfaz virtual.
2. flannel - la misma situación con la red después de crear controller , scheduler pods. La implementación de DNS falló debido a connection refused a la IP del clúster del servidor api 10.96.0.1:443 . (tabla de enrutamiento predeterminada) Especifiqué node-ip del nodo del clúster por bandera --node-ip en /etc/systemd/system/kubelet.service.d/10-kubeadm.conf con la IP de la interfaz virtual.

Después de esto, tengo el nodo listo con la versión 1.12.3. La información más útil estaba en docker logs + kubectl logs

mismo problema aquí con v1.13.0

El mismo problema aquí con Kubernetes v1.13.0
CentOS 7
docker-ce 18.06 (última versión validada)
dockerd: activo, en ejecución
kubelet: activo, en ejecución
selinux: discapacitado
firewalld: discapacitado

ERROR es:
kubelet[98023]: E1212 21:10:01.708004 98023 kubelet.go:2266] node "node1" not found
/ etc / hosts contiene el nodo, se puede hacer ping, se puede acceder a él; en realidad, se trata de un único trabajador de un solo maestro (es decir, un nodo contaminado).

¿Dónde busca K8S este valor? en / etc / hosts?
Puedo solucionar problemas y proporcionar más pruebas si es necesario.

-> ¿kubeadm init finaliza e imprime un token boostrap?
Termina con un largo error:

[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
        - 'docker ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

NOTA: Ninguno de los comandos sugeridos después del tiempo de espera informó algo que valga la pena mencionar aquí.

versión kubelet y kubeadm?
---> 1.13.0
kubeadm version: & version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.0", GitCommit: "ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState: "clean", BuildDate: "2018-12-03T21: 02 01Z ", GoVersion:" go1.11.2 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

Además, ¿no debería establecer un mensaje de error mejor que "nodo no encontrado" con un poco más de claridad / verbosidad en los registros de kube?

Gracias

Mismo problema ...

$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Fri 2018-12-14 19:05:47 UTC; 2min 2s ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 9114 (kubelet)
    Tasks: 23 (limit: 4915)
   CGroup: /system.slice/kubelet.service
           └─9114 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-d

Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862262    9114 kuberuntime_manager.go:657] createPodSandbox for pod "kube-scheduler-pineview_kube-system(7f99b6875de942b000954351c4a
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862381    9114 pod_workers.go:186] Error syncing pod 7f99b6875de942b000954351c4ac09b5 ("kube-scheduler-pineview_kube-system(7f99b687
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906855    9114 remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to start san
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906944    9114 kuberuntime_sandbox.go:65] CreatePodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fai
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906981    9114 kuberuntime_manager.go:657] createPodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fa
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.907100    9114 pod_workers.go:186] Error syncing pod b7841e48f3e7b81c3cda6872104ba3de ("etcd-pineview_kube-system(b7841e48f3e7b81c3c
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.933627    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.033880    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.134064    9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.184943    9114 event.go:212] Unable to write event: 'Post https://192.168.1.235:6443/api/v1/namespaces/default/events: dial tcp 192.

Mismo problema:

Ubuntu 18.04.1 LTS
Kubernetes v1.13.1 (usando cri-o 1.11)

Seguí las instrucciones de instalación en kubernetes.io:
https://kubernetes.io/docs/setup/independent/install-kubeadm/
https://kubernetes.io/docs/setup/cri/#cri -o

systemctl enable kubelet.service
kubeadm init --pod-network-cidr=192.168.0.0/16 --cri-socket=/var/run/crio/crio.sock

/etc/hosts

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       master01.mydomain.tld master01
::1             master01.mydomain.tld master01

/etc/hostname

systemctl status kubelet

● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Tue 2018-12-18 16:19:54 CET; 20min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 10148 (kubelet)
    Tasks: 21 (limit: 2173)
   CGroup: /system.slice/kubelet.service
           └─10148 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock --resolv-conf=/run/systemd/resolve/resolv.conf

Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.795313   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.896277   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.997864   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.098927   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.200355   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.281586   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://192.168.178.27:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.282143   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:444: Failed to list *v1.Service: Get https://192.168.178.27:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.283945   10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:453: Failed to list *v1.Node: Get https://192.168.178.27:6443/api/v1/nodes?fieldSelector=metadata.name%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.301468   10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.402256   10148 kubelet.go:2266] node "master01" not found

@fhemberger Descubrí mi problema. Estaba usando snap para instalar Docker. Si lo desinstalé y lo reinstalé usando apt , entonces kubeadm funcionó bien.

@cjbottaro No uso Docker en absoluto, pero cri-o.

mismo problema aquí con v1.13.1

Si está utilizando systemd y cri-o, asegúrese de configurarlo como controlador cgroup en /var/lib/kubelet/config.yaml (o pase el fragmento a continuación como parte de kubeadm init --config=config.yaml ).

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

Si nota esto en sus registros de kubelet:

remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = cri-o configured with systemd cgroup manager, but did not receive slice as parent: /kubepods/besteffort/…

Hoy me encontré con el mismo problema.

Lo arreglé eliminando rm -rf / var / lib / kubelet / y volví a instalar

@JishanXing ¡ gracias! Esto también resolvió mi problema para ejecutar en Raspbian Sketch lite

Lo arreglé eliminando /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf

Sería mejor usar el comando kubeadm reset .

@fhemberger cómo resolverlo ， la misma pregunta, gracias

Encontré el mismo problema cuando actualicé k8s de 1.13.3 a 1.13.4 ...
Lo resuelvo después de editar /etc/kubernetes/manifests/kube-scheduler.yaml . Modificar la versión de la imagen
image: k8s.gcr.io/kube-scheduler:v1.13.3 ==> image: k8s.gcr.io/kube-scheduler:v1.13.4
lo mismo para kube-controller-manager.yaml y kube-apiserver.yaml.

La última forma es agregar la opción --image-repository registry.aliyuncs.com/google_containers , mi versión de k8s es 1.14.0, Docker Version: 18.09.2,
`kubeadm init --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.14.0 --pod-network-cidr = 192.168.0.0 / 16
[init] Con la versión de Kubernetes: v1.14.0
[Preflight] Ejecución de comprobaciones previas al vuelo
[ADVERTENCIA IsDockerSystemdCheck]: se detectó "cgroupfs" como el controlador cgroup de Docker. El controlador recomendado es "systemd". Siga la guía en https://kubernetes.io/docs/setup/cri/
[Preflight] Obtención de imágenes necesarias para configurar un clúster de Kubernetes
[Preflight] Esto puede tardar uno o dos minutos, según la velocidad de tu conexión a Internet.
[Preflight] También puede realizar esta acción de antemano usando 'kubeadm config images pull'
[kubelet-start] Escribiendo un archivo de entorno kubelet con banderas en el archivo "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Escribiendo la configuración de kubelet en el archivo "/var/lib/kubelet/config.yaml"
[kubelet-start] Activando el servicio kubelet
[certs] Usando la carpeta certificateDir "/ etc / kubernetes / pki"
[certs] Generando certificado y clave "front-proxy-ca"
[certs] Generando certificado y clave "front-proxy-client"
[certs] Generando certificado y clave "ca"
[certs] Generando certificado y clave "apiserver"
[certs] El certificado de servicio de apiserver está firmado para los nombres DNS [jin-virtual-machine kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] e IP [10.96.0.1 192.168.232.130]
[certs] Generando el certificado y la clave "apiserver-kubelet-client"
[certs] Generando certificado y clave "etcd / ca"
[certs] Generando certificado y clave "etcd / server"
[certs] etcd / server que sirve cert está firmado para nombres DNS [jin-virtual-machine localhost] e IPs [192.168.232.130 127.0.0.1 :: 1]
[certs] Generando certificado y clave "etcd / peer"
[certs] etcd / peer serve cert está firmado para nombres DNS [jin-virtual-machine localhost] e IPs [192.168.232.130 127.0.0.1 :: 1]
[certs] Generando el certificado y la clave "apiserver-etcd-client"
[certs] Generando el certificado y la clave "etcd / healthcheck-client"
[certs] Generando clave "sa" y clave pública
[kubeconfig] Usando la carpeta kubeconfig "/ etc / kubernetes"
[kubeconfig] Escribiendo el archivo kubeconfig "admin.conf"
[kubeconfig] Escribiendo archivo "kubelet.conf" kubeconfig
[kubeconfig] Escribiendo el archivo kubeconfig "controller-manager.conf"
[kubeconfig] Escribiendo el archivo kubeconfig "planificador.conf"
[plano de control] Usando la carpeta de manifiesto "/ etc / kubernetes / manifiestos"
[control-plane] Creación de un manifiesto de pod estático para "kube-apiserver"
[control-plane] Creación de un manifiesto de pod estático para "kube-controller-manager"
[control-plane] Creación de un manifiesto de pod estático para "kube-Scheduler"
[etcd] Creación de un manifiesto de pod estático para etcd local en "/ etc / kubernetes / manifiestos"
[wait-control-plane] Esperando que kubelet inicie el plano de control como Pods estáticos desde el directorio "/ etc / kubernetes / manifests". Esto puede tardar hasta 4 min.
[apiclient] Todos los componentes del plano de control están en buen estado después de 17.004356 segundos
[upload-config] almacenando la configuración usada en ConfigMap "kubeadm-config" en el espacio de nombres "kube-system"
[kubelet] Creación de un ConfigMap "kubelet-config-1.14" en el espacio de nombres kube-system con la configuración de los kubelets en el clúster
[upload-certs] Fase de omisión. Consulte --experimental-upload-certs
[mark-control-plane] Marcando el nodo jin-virtual-machine como control-plane agregando la etiqueta "node-role.kubernetes.io/master= ''"
[mark-control-plane] Marcando el nodo jin-virtual-machine como control-plane agregando taints [node-role.kubernetes.io/ master: NoSchedule ]
[bootstrap-token] Usando token: xucir0.o4kzo3qqjyjnzphl
[bootstrap-token] Configuración de tokens de arranque, ConfigMap de información de clúster, Roles RBAC
[bootstrap-token] configuró las reglas de RBAC para permitir que los tokens de Node Bootstrap publiquen CSR para que los nodos obtengan credenciales de certificado a largo plazo
[bootstrap-token] configuró reglas de RBAC para permitir que el controlador csrapprover apruebe automáticamente las CSR desde un token de Bootstrap de nodo
[bootstrap-token] configuró reglas de RBAC para permitir la rotación de certificados para todos los certificados de cliente de nodo en el clúster
[bootstrap-token] creando el ConfigMap "cluster-info" en el espacio de nombres "kube-public"
[complementos] Complemento esencial aplicado: CoreDNS
[complementos] Complemento esencial aplicado: kube-proxy

¡Su plano de control de Kubernetes se ha inicializado correctamente!

Para comenzar a usar su clúster, debe ejecutar lo siguiente como usuario habitual:

mkdir -p $ INICIO / .kube
sudo cp -i /etc/kubernetes/admin.conf $ INICIO / .kube / config
sudo chown $ (id -u): $ (id -g) $ HOME / .kube / config

Ahora debe implementar una red de pod en el clúster.
Ejecute "kubectl apply -f [podnetwork] .yaml" con una de las opciones enumeradas en:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

Luego, puede unirse a cualquier número de nodos trabajadores ejecutando lo siguiente en cada uno como raíz:

kubeadm unirse 192.168.232.130:6443 --token xucir0.o4kzo3qqjyjnzphl
--discovery-token-ca-cert-hash sha256: 022048b22926a2cb2f8295ce2e3f1f6fa7ffe1098bc116f7d304a26bcfb78656
'

Me encontré con el mismo problema con kubernetes v1.14.1 y cri-o v1.14.0 en una máquina virtual GCP Ubuntu 18.04. Sin embargo, las cosas funcionaron bien al usar la ventana acoplable. referenciando: https://github.com/cri-o/cri-o/issues/2357

Mi problema fue con los diferentes controladores de cgroup. CRIO usa systemd por defecto, kubelet usa cgroupfs por defecto.

cat /etc/crio/crio.conf | grep cgroup
# cgroup_manager is the cgroup management implementation to be used
cgroup_manager = "systemd"

Si ese es su caso, consulte https://kubernetes.io/docs/setup/independent/install-kubeadm/#configure -cgroup-driver-used-by-kubelet-on-master-node

Solo escribe el archivo

echo "KUBELET_EXTRA_ARGS=--cgroup-driver=systemd" > /etc/default/kubelet

y ejecute kubeadm init después de eso. O cambie cgroup_manager a cgroupfs

a diferencia de docker, cri-o y containerd son un poco más difíciles de administrar en términos de detección de controladores de cgroup, pero hay algunos planes para admitirlo desde kubeadm.

Docker ya se maneja.

Así que aparentemente no hay otra solución que resetear el cluster $ (yes | kubeadm reset), ¡que no es una solución en mi opinión!

Cambiar el repositorio de imágenes funcionó para mí, pero esta no es una gran solución.
--image-repository registry.aliyuncs.com/google_containers

mi caso ha funcionado con esto

sed -i 's / cgroup-driver = systemd / cgroup-driver = cgroupfs / g' /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Tengo el mismo problema. Utilizo kubeadm init --config=init-config.yaml y fallé, este archivo generado por kubeadm. hay un campo publicidadAddress por defecto es 1.2.3.4 en el archivo, lo que hace que el inicio de etcd contianer falle. cuando cambio a 127.0.0.1, etcd contianer se inicia correctamente y kubeadm init éxito

para resolver este problema, use docker ps -a listar todos los contenedores, verifique si alguno de ellos salió, si es así, use docker logs CONTIANER_ID ver qué sucedió. Espero eso ayude

Hola a todos, ¿alguien tiene una solución? El mismo problema aquí, pero usando el k3s .

@MateusMac , probablemente también debería abrir un informe de error contra k3s.

Trabajé durante una semana para conseguir que kubeadm trabajaran en
Ubuntu 18.04
acoplador 18.06-2-ce
k8s 1.15.1
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

Fails with:

[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
        - 'docker ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster

Los registros de kubelet muestran que simplemente no puede encontrar los nodos para pasar la primera base:

warproot<strong i="15">@warp02</strong>:~$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/kubelet.service.d
           └─10-kubeadm.conf
   Active: active (running) since Sun 2019-08-04 18:22:26 AEST; 5min ago
     Docs: https://kubernetes.io/docs/home/
 Main PID: 12569 (kubelet)
    Tasks: 27 (limit: 9830)
   CGroup: /system.slice/kubelet.service
           └─12569 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-dri

Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322762   12569 kuberuntime_sandbox.go:68] CreatePodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)"
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322806   12569 kuberuntime_manager.go:692] createPodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322872   12569 pod_workers.go:190] Error syncing pod ecae9d12d3610192347be3d1aa5aa552 ("kube-scheduler-warp02_kube-system(ecae9d12d36101
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.373094   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.375587   12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSIDriver: Get https://10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.473295   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.573567   12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.575495   12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.RuntimeClass: Get https://10.1.1.4:6
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.590886   12569 event.go:249] Unable to write event: 'Post https://10.1.1.4:6443/api/v1/namespaces/default/events: dial tcp 10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.673767   12569 kubelet.go:2248] node "warp02" not found

Debo tener en cuenta que tengo varias NIC en estas máquinas sin sistema operativo:

warproot<strong i="6">@warp02</strong>:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:feff:fe65:37f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:fe:65:03:7f  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 516 (516.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.2  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::32b5:c2ff:fe02:410b  prefixlen 64  scopeid 0x20<link>
        ether 30:b5:c2:02:41:0b  txqueuelen 1000  (Ethernet)
        RX packets 46  bytes 5821 (5.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 70  bytes 7946 (7.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.4  netmask 255.255.255.0  broadcast 10.1.1.255
        inet6 fd42:59ff:1166:0:25a7:3617:fee6:424e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1a03:73ff:fe44:5694  prefixlen 64  scopeid 0x20<link>
        inet6 fd9e:fdd6:9e01:0:1a03:73ff:fe44:5694  prefixlen 64  scopeid 0x0<global>
        ether 18:03:73:44:56:94  txqueuelen 1000  (Ethernet)
        RX packets 911294  bytes 1361047672 (1.3 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 428759  bytes 29198065 (29.1 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  

ib0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 4092
        unspec A0-00-02-10-FE-80-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ib1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 4092
        unspec A0-00-02-20-FE-80-00-00-00-00-00-00-00-00-00-00  txqueuelen 256  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 25473  bytes 1334779 (1.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25473  bytes 1334779 (1.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

No sé si eso es un problema, pero configuré mi archivo /etc/hosts como

warproot<strong i="7">@warp02</strong>:~$ cat /etc/hosts
127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
# add our host name
10.1.1.4 warp02 warp02.ad.xxx.com
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
# add our ipv6 host name
fd42:59ff:1166:0:25a7:3617:fee6:424e warp02 warp02.ad.xxx.com

warproot<strong i="8">@warp02</strong>:~$ 

Entonces, está configurado (creo) para ver la NIC 10.1.1.4 como la "red" para k8s

nslookup contra el nombre del nodo parece estar funcionando bien:

warproot<strong i="13">@warp02</strong>:~$ nslookup warp02
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   warp02.ad.xxx.com
Address: 10.1.1.4
Name:   warp02.ad.xxx.com
Address: fd42:59ff:1166:0:25a7:3617:fee6:424e

warproot<strong i="14">@warp02</strong>:~$ 

He revisado la documentación de instalación de kubeadm varias veces.

Extraño. Simplemente no puede encontrar la red.

Perplejo.

Para la versión 1.15.3 pude arreglar esto en Ubuntu 18.04 agregando

kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    cgroup-driver: "systemd"

a mi configuración de kubeadm y luego ejecutando kubeadm init

Tengo el mismo problema aquí, con la versión 1.15.3, en Ubuntu 18.04
@ kris-nova Realmente agradecería si pudiera especificar dónde se encuentra este archivo de configuración :-)

ACTUALIZACIÓN: Realmente no puedo decir por qué, pero funciona ahora, ¡sin cambiar ninguna configuración!
(nota: no sé si está relacionado, pero actualicé la ventana acoplable de la v.19.03.1 a la v.19.03.2, antes de volver a intentarlo kubeadm init )

Recibí el siguiente error al ejecutar kubeadm init, es decir, nodexx no encontrado.

[ root @ node01 ~] # journalctl -xeu kubelet
07 de noviembre 10:34:02 nodo01 kubelet [2968]: E1107 10: 34: 02.682095 2968 kubelet.go: 2267] nodo "nodo01" no encontrado
07 de noviembre 10:34:02 nodo01 kubelet [2968]: E1107 10: 34: 02.782554 2968 kubelet.go: 2267] nodo "nodo01" no encontrado
07 de noviembre 10:34:02 node01 kubelet [2968]: E1107 10: 34: 02.829142 2968 reflector.go: 123] k8s.io/client-go/informers/factory.go:134: No se pudo enumerar * v1beta1.CSID
07 de noviembre 10:34:02 nodo01 kubelet [2968]: E1107 10: 34: 02.884058 2968 kubelet.go: 2267] nodo "nodo01" no encontrado
07 de noviembre 10:34:02 nodo01 kubelet [2968]: E1107 10: 34: 02.984510 2968 kubelet.go: 2267] nodo "nodo01" no encontrado
07 de noviembre 10:34:03 node01 kubelet [2968]: E1107 10: 34: 03.030884 2968 reflector.go: 123]

Resuelto a través de:

setenforce 0

sed -i --follow-symlinks 's / SELINUX = enforcing / SELINUX = disabled / g' / etc / sysconfig / selinux

mismo problema

En mi caso, eso fue causado por una desviación de tiempo en el nodo maestro, que sucedió después de un corte de energía.
Lo tenía arreglado corriendo

# Correcting the time as mentioned here https://askubuntu.com/a/254846/861548
sudo service ntp stop
sudo ntpdate -s time.nist.gov
sudo service ntp start
# Then restarting the kubelet
sudo systemctl restart kubelet.service
# I also had to run daemon-reload as I got the following warning
# Warning: The unit file, source configuration file or drop-ins of kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.
sudo systemctl daemon-reload
# I also made another restart, which I don't know whether needed or not
sudo systemctl restart kubelet.service

arreglé mi mismo problema node "xxxx" not found ， trato de ver el registro del contenedor usar los registros de la ventana /etc/kubernetes/manifests/etcd.yaml , reiniciar, problema solucionado。