<p>kubeadm init atascado en "El primer nodo se ha registrado, pero aún no está listo"</p>

Me está sucediendo exactamente lo mismo en Ubuntu 16.04.02, tanto en GCE como en instalaciones locales de VMWare, Docker versión 1.12.6, kernel 4.8.0-44-generic 47 ~ 16.04.1-Ubuntu SMP.

El registro de kubelet muestra una advertencia sobre la falta de /etc/cni/net.d antes del error que vemos en el informe de jimmycuadra:

Mar 29 04:43:25 instance-1 kubelet[6800]: W0329 04:43:25.763117    6800 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Mar 29 04:43:25 instance-1 kubelet[6800]: E0329 04:43:25.763515    6800 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Mismo problema en Ubuntu AWS VM. Docker 1.12.5

root @ ip-10-43-0-20 : ~ # versión kubeadm
kubeadm version: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.0", GitCommit: "fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState: "clean", BuildDate: "2017: 24-03-28T16: 30Z ", GoVersion:" go1.7.5 "

root @ ip-10-43-0-20 : ~ # uname -a
Linux ip-10-43-0-20 4.4.0-45-generic # 66-Ubuntu SMP Mié 19 de octubre 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

root @ ip-10-43-0-20 : ~ # kubeadm init --config cfg.yaml
[kubeadm] ADVERTENCIA: kubeadm está en versión beta, no lo use para clústeres de producción.
[init] Con la versión de Kubernetes: v1.6.0
[init] Usando el modo de autorización: RBAC
[init] ADVERTENCIA: Para que las integraciones de proveedor de nube funcionen, se debe configurar el proveedor de nube para todos los kubelets del clúster.
(/etc/systemd/system/kubelet.service.d/10-kubeadm.conf debe editarse para este propósito)
[Preflight] Ejecución de comprobaciones previas al vuelo
[Preflight] Iniciando el servicio de kubelet
[certificados] Certificado y clave de CA generados.
[certificados] Certificado y clave de servidor API generados.
[certificados] El certificado de servicio del servidor API está firmado para nombres DNS [ip-10-43-0-20 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] e IP [10.96.0.1 10.43.0.20 ]
[certificados] Certificado y clave del cliente kubelet del servidor API generado.
[certificados] Clave de firma de token de cuenta de servicio generada y clave pública.
[certificados] Certificado y clave de CA de proxy frontal generados.
[certificados] Certificado y clave de cliente de proxy frontal generados.
[certificados] Los certificados y claves válidos ahora existen en "/ etc / kubernetes / pki"
[kubeconfig] Escribió el archivo KubeConfig en el disco: "/etc/kubernetes/admin.conf"
[kubeconfig] Escribió el archivo KubeConfig en el disco: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Escribió el archivo KubeConfig en el disco: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Escribió el archivo KubeConfig en el disco: "/etc/kubernetes/scheduler.conf"
[apiclient] Cliente de API creado, esperando que el plano de control esté listo
[apiclient] Todos los componentes del plano de control están en buen estado después de 16.531681 segundos
[apiclient] Esperando que al menos un nodo se registre y esté listo
[apiclient] El primer nodo se ha registrado, pero aún no está listo
[apiclient] El primer nodo se ha registrado, pero aún no está listo
[apiclient] El primer nodo se ha registrado, pero aún no está listo

++ el mismo problema (Ubuntu 16.04.1)

Lo mismo aquí en Ubuntu 16.04

En CentOS 7, bajé el kubelet a 1.5.4 . Eso me resolvió. Parece que el cheque listo funciona de manera diferente en el kubelet 1.6.0 .

El mismo problema en CentOS 7 en una máquina x64 bare metal, desde la actualización a k8s 1.6.0

Mismo problema en Ubuntu 16.04

El mismo problema en Ubuntu 16.04, la degradación manual del paquete kubelet resolvió el problema.

# apt install kubelet=1.5.6-00

@ctrlaltdel no funcionó para mí.

Sospecho que se trata de un problema de Kubelet. No debería marcar el nodo como no listo cuando CNI no está configurado. Solo las vainas que requieren CNI deben marcarse como no listas.

@jbeda ¿Sabes cuándo se resolverá este problema?

@kristiandrucker - no - todavía

@jbeda Ok, pero después de que se resuelva el problema, ¿entonces qué? ¿Reconstruir kubelet desde la fuente?

@kristiandrucker Esto tendrá que salir en una versión puntual de k8s si se trata de un problema de kubelet.

Sospecho que https://github.com/kubernetes/kubernetes/pull/43474 es la causa principal. Ir a presentar un error y hacer un seguimiento con la gente de la red.

@dcbw ¿ Estás por aquí?

Parece que el problema es que un DaemonSet no está programado para los nodos que tienen la condición Net stNetwork: true debe programarse en un nodo que es Net workReady: false , pero un pod ho

Como solución alternativa, ¿agregar la anotación scheduler.alpha.kubernetes.io/critical-pod en su DaemonSet hace que las cosas funcionen nuevamente?

@janetkuo @lukaszo ¿puedes clasificar el comportamiento de DS?

También hay una discusión en curso en # sig-network sobre la holgura, por cierto.

Mismo problema CentOS 7 x64

@prapdm esto parece indefenso de la distribución que está ejecutando.

Versión 7.3.1611 de CentOS Linux (núcleo)

Lo probé en un nodo con Ubuntu 16.04. Se cuelga con el mensaje "aún no está listo". También creé manualmente Flannel DaemonSet pero en mi caso programé un pod sin ningún problema. El mismo pod daemon entró en CrashLoopBackOff con el error: E0329 22:57:03.065651 1 main.go:127] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-z3xgn': the server does not allow access to the requested resource (get pods kube-flannel-ds-z3xgn)

También probaré Centos, pero no creo que DaemonSet tenga la culpa aquí, kubeadm se cuelga aquí.

eso es un error de permiso rbac.

@jimmycuadra Acabo de notar que lo estás ejecutando en raspberry pi que tiene un procesador de brazo.

Para el conjunto de demonios de franela tienes:

`` `nodeSelector:
beta.kubernetes.io/arch: amd64

but your node is labeled with: 

beta.kubernetes.io/arch=arm
''

Entonces, DaemonSet no puede almorzar en este nodo, simplemente cambie el selector de nodo y funcionará.
Seguirá recibiendo el error con el permiso rbac, pero tal vez @mikedanese le diga cómo solucionarlo porque no lo sé.

¡Ah, gracias @lukaszo! Esta vez no estaba siguiendo la guía específica de RPi (que usé para k8s 1.5) y olvidé ese paso. Lo habría descubierto cuando el daemon set erró, pero resulta que no llegué tan lejos. :}

También veo este problema cuando sigo las instrucciones que se describen aquí:
https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

logró que funcionara después de instalar el módulo de red de franela correcto.

Creo que @jimmycuadra podría hacerlo funcionar con el comentario de @lukaszo .

Cuando el mensaje [apiclient] First node has registered, but is not ready yet comience a inundar, el servidor de la API de kubernetes se ejecutará para que pueda:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | kubectl create -f -

Para la instalación de raspberry pi:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | sed "s/amd64/arm/g" | kubectl create -f -

Entonces terminará:

[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 245.050597 seconds
[apiclient] Test deployment succeeded
[token] Using token: 4dc99e............
[apiconfig] Created RBAC rules
[addons] Created essential addon: kube-proxy
[addons] Created essential addon: kube-dns

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token 4dc99e........... 192.168.1.200:6443

Tuve el mismo problema y lo solucioné de esta manera:
deberías ser root

en 1.6.0 de kubeadm debe eliminar la variable de entorno $ KUBELET_NETWORK_ARGS en el archivo del sistema: /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

luego reinicia los demonios

systemctl daemon-reload

kubeadm init

esto toma un poco de tiempo ... después del éxito

descargue el complemento de red que desea utilizar: http://kubernetes.io/docs/admin/addons/

Calico parece ser el mejor, no estoy seguro, pero todavía está en prueba para mí.

@thelastworm
Intenté hacerlo y no funcionó.
Ubuntu 16.04.2 LTS, kubeadm 1.6.0
Hice los siguientes pasos:

1. edite /etc/systemd/system/kubelet.service.d/10-kubeadm.conf y elimine $ KUBELET_NETWORK_ARGS
2. kubeadm reset para limpiar el intento anterior de iniciarlo
3. kubeadm init --token=<VALUE> --apiserver-advertise-address=<IP>

[EDITADO]
Funcionó después de que @ srinat999 señalara la necesidad de ejecutar systemctl daemon-reload antes de kubeadm init

La solución de @jcorral funcionó para mí con un cambio en la implementación de franela, ya que kubeadm ya no crea el puerto API inseguro.

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | \
kubectl --kubeconfig /etc/kubernetes/admin.conf create -f -

@MaximF Tienes que hacer systemctl daemon-reload después de cambiar el archivo conf. Trabajó para mi.

@jcorral Tu solución me funciona. Gracias.

@MaximF acabo de agregar la línea de comando reiniciar demonio

kubeadm init se completa correctamente, pero cuando verifico la versión, aparece el siguiente error:

Versión del cliente: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.0", GitCommit: "fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState: "clean", BuildDate: "2017-03-28T16: 36: 33Z ", GoVersion:" go1.7.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}
La conexión al servidor localhost: 8080 fue rechazada. ¿Especificó el host o puerto correcto?

@haribole
Debe configurar la var env KUBECONFIG

¿Alguien ha conseguido que Flannel se ejecute después de las soluciones alternativas relacionadas con la CNI? Puedo pasar el problema de no estar listo, pero cuando ejecuto Flannel, aparece un error que se ve así:

Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-g5cbj': the server does not allow access to the requested resource (get pods kube-flannel-ds-g5cbj)

El estado de los pods muestra "CrashLoopBackOff"

Debe agregar roles rbac para autorizar a Flannel a leer desde la API.

Debe agregar roles rbac para autorizar a Flannel a leer desde la API.

En caso de que alguien más se pregunte qué significa esto, parece que necesita crear kube-flannel-rbac.yml antes de crear franela:

kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Creo que debido a que se resuelve un problema de raíz y se cierra el ticket relacionado , deberíamos cerrar este también :)

Solo para información: ahora me está funcionando con los paquetes actualizados en Ubuntu 16.04.

1.6.1 ¡funciona para mí! ¡Gracias a todos los que ayudaron a solucionar este problema!

Configuré con éxito mi clúster de Kubernetes en centos-release-7-3.1611.el7.centos.x86_64 siguiendo los siguientes pasos (supongo que Docker ya está instalado):

1) (de /etc/yum.repo.d/kubernetes.repo) baseurl = http: //yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Para usar el repositorio inestable para la última versión de Kubernetes 1.6.1
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) agregue "--cgroup-driver = systemd" al final de la última línea.
=> Esto se debe a que Docker usa systemd para cgroup-driver mientras que kubelet usa cgroupfs para cgroup-driver.
4) systemctl enable kubelet && systemctl start kubelet
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Si solía agregar --api-publicidad-direcciones, necesita usar --apiserver-publicidad-dirección en su lugar.
6) cp /etc/kubernetes/admin.conf $ INICIO /
sudo chown $ (id -u): $ (id -g) $ HOME / admin.conf
exportar KUBECONFIG = $ HOME / admin.conf
=> Sin este paso, es posible que obtenga un error con kubectl get
=> No lo hice con 1.5.2
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 introduce un control de acceso basado en roles, por lo que debe agregar un ClusterRole y un ClusterRoleBinding antes de crear un daemonset Flannel
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Crear un conjunto de demonios de franela
9) (en cada nodo esclavo) kubeadm join --token (su token) (ip) :( puerto)
=> como se muestra en el resultado de kubeadm init

Todos los pasos anteriores son el resultado de combinar sugerencias de varios problemas relacionados con Kubernetes-1.6.0, especialmente kubeadm.

Espero que esto le ahorre tiempo.

@eastcirclek @Sliim Eres genial

@eastcirclek, estos fueron los pasos exactos que acabo de ejecutar consultando varios foros también. ¿Una diferencia de zona horaria, tal vez? Gracias a todos, este tema fue realmente útil.

Tengo el servidor Ubuntu 16.04 en AWS y seguí los pasos

1. edite /etc/systemd/system/kubelet.service.d/10-kubeadm.conf y elimine $ KUBELET_NETWORK_ARGS
2. kubeadm restablece para limpiar el intento anterior de iniciarlo
3. kubeadm init --token =--apiserver-publicidad-dirección =

que aparentemente funcionó correctamente, pero luego, cuando intento instalar Calico como complemento de red, aparece el siguiente error
La conexión al servidor localhost: 8080 fue rechazada. ¿Especificó el host o puerto correcto?

¿El equipo de k8s está trabajando en un parche?

Gracias

@overip No creo que se requiera ningún parche para eso ... Solo necesita especificar el archivo kubeconfig correcto cuando use kubectl. kubeadm debería haberlo escrito en /etc/kubernetes/admin.conf .

@jimmycuadra, ¿ podrías explicar los pasos para hacerlo?

@overip La salida de kubeadm init tiene las instrucciones:

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Personalmente, prefiero copiar el archivo en $HOME/.kube/config , que es donde kubectl lo buscará de forma predeterminada. Entonces no es necesario configurar la variable de entorno KUBECONFIG.

Si planea usar kubectl desde su máquina local, puede usar scp (o incluso simplemente copiar y pegar el contenido) para escribirlo en ~/.kube/config en su propia computadora.

Busque "admin.conf" en este problema de GitHub para obtener más detalles. Se ha mencionado varias veces.

@eastcirclek : siguió los pasos, pero por alguna razón los nodos no pueden instalar la franela correctamente.
(Nota: en el maestro todo es fluido).

Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666206   22893 kuberuntime_manager.go:458] Container {Name:install-cni Image:quay.io/coreos/flannel:v0.7.0-amd64 Command:[/bin/sh -c set -e -x; cp -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conf; while true; do sleep 3600; done] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:cni ReadOnly:false MountPath:/etc/cni/net.d SubPath:} {Name:flannel-cfg ReadOnly:false MountPath:/etc/kube-flannel/ SubPath:} {Name:flannel-token-g65nf ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:nil ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:nil Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666280   22893 kuberuntime_manager.go:742] checking backoff for container "install-cni" in pod "kube-flannel-ds-3smf7_kube-system(2e6ad0f9-207f-11e7-8f34-0050569120ff)"
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846325   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/configmap/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-cfg" (spec.Name: "flannel-cfg") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846373   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-token-g65nf" (spec.Name: "flannel-token-g65nf") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").

Solo comparte mi método de solución. En primer lugar, se requiere $ KUBELET_NETWORK_ARGS; de lo contrario, CNI no está habilitado / configurado. Eliminar y luego restaurar $ KUBELET_NETWORK_ARGS parece demasiado complicado.
Cuando kubeadm init muestra "[apiclient] El primer nodo se ha registrado, pero aún no está listo", el clúster k8s está realmente listo para atender la solicitud. En ese momento, el usuario simplemente puede pasar al paso 3/4 de https://kubernetes.io/docs/getting-started-guides/kubeadm/ de la siguiente manera.

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:  http://kubernetes.io/docs/admin/addons/

Cuando un usuario instala podnetwork, asegúrese de que la cuenta de servicio de la política de podnetwork tenga el permiso suficiente. Tomando la franela como ejemplo. Solo vinculo el rol de administrador de clúster a la cuenta de servicio de franela de la siguiente manera. Puede que no sea lo ideal, y podría definir un rol específico para la cuenta de servicio de franela. Por cierto, cuando un usuario implementa otro servicio complementario como el tablero, también requiere otorgar suficiente permiso a la cuenta de servicio relacionada.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: flannel:daemonset
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: flannel
  namespace:  kube-system

Una vez que el servidor de podnetwork esté listo, kubeadm init mostrará que el nodo está listo y el usuario podrá continuar con la instrucción.

Tomando la franela como ejemplo. Solo vinculo el rol de administrador de clúster a la cuenta de servicio de franela de la siguiente manera. Puede que no sea lo ideal, y podría definir un rol específico para la cuenta de servicio de franela.

Ya existe https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Gracias a todos por la ayuda.
Finalmente k8s 1.6.1 completamente funcional con franela. Todo está ahora en libros de jugadas ansible.
Probado en Centos / RHEL. También comenzaron los preparativos para Debian (por ejemplo, Ubuntu), pero es posible que sea necesario perfeccionarlo.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PD: trabajo basado en sjenning / kubeadm-playbook - Muchas gracias @sjenning

Obteniendo esto para unirse a un clúster:
[descubrimiento] Se creó el cliente de descubrimiento de información de clúster, solicitando información de " https://10.100.2.158 : 6443"
[descubrimiento] No se pudo solicitar la información del clúster, lo intentaremos de nuevo: [configmaps "cluster-info" está prohibido: el usuario " system: anonymous " no puede obtener configmaps en el espacio de nombres "kube-public"]
[descubrimiento] No se pudo solicitar la información del clúster, lo intentaremos de nuevo: [configmaps "cluster-info" está prohibido: el usuario " system: anonymous " no puede obtener configmaps en el espacio de nombres "kube-public"]

Comencé el nodo como SelfHosting.