/ cc @lukemarsden @luxas @mikedanese

Si revertimos # 43474 por completo, nos encontramos nuevamente en una situación en la que rompemos los complementos CNI 0.2.0 (consulte https://github.com/kubernetes/kubernetes/issues/43014)

¿Deberíamos considerar hacer algo como https://github.com/kubernetes/kubernetes/pull/43284?

También / cc @thockin

/ cc @ kubernetes / sig-network-bugs

Ref: https://github.com/kubernetes/kubernetes/issues/43397#issuecomment -289978351

@jbeda ¿puedo obtener algunos registros de kubelet con --loglevel = 5?

@yujuhong : mencionas que crees que esto funciona según lo previsto. Independientemente, kubeadm dependía de este comportamiento. Introdujimos un cambio importante con # 43474. Podemos hablar sobre la forma correcta de solucionar este problema para 1.7 pero, por ahora, necesitamos que kubeadm vuelva a funcionar.

Discusión de Slack en curso ahora: https://kubernetes.slack.com/archives/C09QYUH5W/p1490803144368246

Parece que DaemonSets aún se programará incluso si el nodo no está listo. Esto es realmente, en este caso, kubeadm siendo un poco demasiado paranoico.

El plan actual que vamos a probar es que kubeadm ya no espere a que el nodo maestro esté listo, sino que simplemente lo registre. Esto debería ser lo suficientemente bueno como para permitir que un CNI DaemonSet se programe para configurar CNI.

@kensimon está probando esto.

@jbeda sí, parece que el controlador DaemonSet todavía los pondrá en cola principalmente porque ignora por completo la conexión en red. Realmente deberíamos arreglar esto de manera más general. ¿Hay algo inmediato que hacer en kube o todo está en kubeadm por ahora?

Estoy intentando instalar kubernetes con kubeadm en Ubuntu 16.04. ¿Existe un arreglo rápido para esto?

@jbeda si tiene una versión parcheada feliz de probarla ..

Tengo a kubeadm superando el estado NotReady del nodo, pero la implementación ficticia que crea no funciona debido a la corrupción node.alpha.kubernetes.io/notReady impide su ejecución. Agregar tolerancias no parece ayudar, no estoy exactamente seguro de cómo proceder en este momento. ¿Alguien puede arrojar algo de luz sobre cómo implementar un pod que tolera la corrupción notReady ?

Estoy explorando algunas otras opciones, como no marcar el nodo como no listo, pero no está claro que eso sea lo que queremos hacer.

lo solucionamos eliminando KUBELET_NETWORK_ARGS de la línea de comandos de kubelet. después de eso, kubeadm init funcionó bien y pudimos instalar el complemento canal cni.

@sbezverk , ¿podría describir cómo se hace?

Puede confirmar los resultados de @sbezverk (buen hallazgo :)), ajustar /etc/systemd/system/10-kubeadm.conf y eliminar KUBELET_NETWORK_ARGS hará que se ejecute en centos. Probado con tejido.

@overip necesita editar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

ExecStart = / usr / bin / kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_SYSTEM_PODS_ARGS $ KUBELET_NETWORK_ARGS $ KUBELET_DNS_ARGS $ KUBELET_AUTHZ_ARGS $ KUBELET_SEXTRA

eliminar $ KUBELET_NETWORK_ARGS

y luego reinicie kubelet después de que bebeadm init debería funcionar.

Esto es lo que hice

reinicio de kubeadm

eliminar entradas ENV de:

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

recargar los servicios de systemd y kube

systemctl daemon-reload
systemctl reiniciar kubelet.service

vuelva a ejecutar init

kubeadm init

Todo correcto, y mientras estamos en eso

Si ve esto:
kubelet: error: no se pudo ejecutar Kubelet: no se pudo crear kubelet: mala configuración: kubelet controlador cgroup: "cgroupfs" es diferente del controlador docker cgroup: "systemd"

tienes que editar tu /etc/systemd/system/kubelet.service.d/10-kubeadm.conf y agregar la bandera --cgroup-driver = "systemd"

y haz lo mismo que arriba

reinicio de kuebadm
systemctl daemon-reload
systemctl reiniciar kubelet.service
kubeadm init.

Tendría cuidado al eliminar --network-plugin=cni de las banderas CLI de kubelet, esto hace que kubelet use el complemento no_op de forma predeterminada ... Me sorprendería si los complementos comunes como calico / weave incluso funcionarían en este caso (pero luego, de nuevo, mi comprensión de cómo funcionan estos complementos es un poco limitada).

@kensimon hm, no he visto ningún problema en mi configuración, implementé el complemento canal cni y funcionó bien.

@sbezverk ¿Las redes entre hosts también funcionan bien?

@resouer no puede confirmar, tengo 1.6.0 solo como todo en uno.

@resouer @sbezverk Me

 [root@deploy-01 x86_64]# kubectl get nodes
 NAME        STATUS    AGE       VERSION
 deploy-01   Ready     51m       v1.6.0
 master-01   Ready     4m        v1.6.0

`` `[ root @ deploy-01 x86_64] # kubectl get pods -n kube-system
NOMBRE ESTADO LISTO REINICIE EDAD
etcd-deploy-01 1/1 En ejecución 0 50m
kube-apiserver-deploy-01 1/1 Corriendo 0 51m
kube-controller-manager-deploy-01 1/1 En ejecución 0 50m
kube-dns-3913472980-6plgh 3/3 Corriendo 0 51m
kube-proxy-mbvdh 1/1 En ejecución 0 4m
kube-proxy-rmp36 1/1 En ejecución 0 51m
kube-Scheduler-deploy-01 1/1 En ejecución 0 50m
kubernetes-dashboard-2396447444-fm8cz 1/1 Corriendo 0 24m
weave-net-3t487 2/2 Corriendo 0 44m
weave-net-hhcqp 2/2 Corriendo 0 4m

''

La solución funciona pero no se puede poner en marcha la franela ...

@stevenbower en el peor de los casos, puede volver a colocar esta configuración y reiniciar kubelet cuando haya terminado con kubeadm business.

Tengo un clúster de tres nodos con weave funcionando. No estoy seguro de cuán estable podría ser esto con este truco, ¡pero gracias de todos modos! : smiley:

En un nodo lateral, puede volver a colocar $ KUBELET_NETWORK_ARGS, después de que pase el init en el maestro. De hecho, no lo eliminé en la máquina a la que me uní, solo el controlador cgroup, de lo contrario, kubelet y docker no funcionarán juntos.

Pero no tienes que reiniciar kubeadm, solo cambia /etc/systemd/system/kubelet.service.d/10-kubeadm.conf y haz el baile systemctl:

systemctl daemon-reload
systemctl reiniciar kubelet.service

Para aquellos de ustedes que están descartando KUBELET_NETWORK_ARGS y reportando que funciona para ustedes:

Para mí, tengo 2 grupos: uno en el que apliqué el parche de https://github.com/kubernetes/kubernetes/pull/43824 y dejé que kubeadm procediera normalmente en la inicialización, y otro con KUBELET_NETWORK_ARGS eliminado. En el clúster con KUBELET_NETWORK_ARGS eliminado, cualquier tráfico entre pods falla.

En un clúster con KUBELET_NETWORK_ARGS eliminado:

$ kubectl run nginx --image=nginx
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
wget: bad address 'nginx.default.svc.cluster.local'

En un clúster con KUBELET_NETWORK_ARGS normal pero con un kubeadm parcheado:

$ kubectl run nginx --image=nginx          
deployment "nginx" created
$ kubectl expose deployment nginx --port 80
service "nginx" exposed
$ kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
If you don't see a command prompt, try pressing enter.
/ # wget nginx.default.svc.cluster.local
Connecting to nginx.default.svc.cluster.local (10.109.159.41:80)
index.html           100% |********************************************************************************************|   612   0:00:00 ETA

Si usted es uno de los que desactivó KUBELET_NETWORK_ARGS, verifique si lo anterior funciona para usted.

Sugiero que eliminemos tanto el nodo listo como la verificación de implementación ficticia
en total para 1.6 y pasarlos a una fase de validación para 1.7.

El 29 de marzo de 2017 a las 10:13 a. M., "Dan Williams" [email protected] escribió:

@jbeda https://github.com/jbeda sí, parece el DaemonSet
el controlador todavía los pondrá en cola principalmente porque es completamente ignorante
de la interconexión. Realmente deberíamos arreglar esto de manera más general. Está ahí
¿Algo inmediato que hacer en kube o está todo en kubeadm por ahora?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290158416 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABtFIUw8GIJVfHrecB3qpTLT8Q4AyLVjks5rqpFKgaJpZM4MtMRe
.

¿Alguien más ejecuta Ubuntu 16.04? Eliminé el KUBELET_NETWORK_ARGS del servicio systemd y recargué el demonio systemd . Puedo activar un nodo maestro pero no puedo unirme a un nodo. Falla con el error The requested resource is unavailable

KUBELET_NETWORK_ARGS eliminado, cualquier tráfico entre pods falla.

No me sorprendería ya que KUBELET_NETWORK_ARGS le dice a kubelet qué complemento usar, dónde buscar la configuración y los binarios. Los necesitas.

Recomiendo # 43835 (y la selección de cereza 1.6 # 43837) como la solución que hacemos para 1.6. Probé ambos y funcionan. He asignado a @jbeda y @luxas para que las revisen cuando se despierten.

Ambos RP parecen razonables. Pero creo que deberíamos considerar ir con https://github.com/kubernetes/kubernetes/pull/43824 en su lugar. Si bien es un poco más complicado, conserva esa ruta de código para que los usuarios que preconfiguran CNI fuera de usar un Daemonset (hago esto en https://github.com/jbeda/kubeadm-gce-tf aunque no lo he hecho actualizado a 1.6) todavía espera a que los nodos estén listos.

Como beneficio adicional, este es el primer RP de @kensimon para Kubernetes y ha hecho todo lo posible para probar estas cosas. Pero, para ser honesto, ambos funcionan y realmente quiero verlo arreglado. :)

Lo siento, me perdí https://github.com/kubernetes/kubernetes/pull/43824. También estoy contento con cualquiera de los dos si ambos funcionan.

También estoy contento con cualquiera de los dos si ambos funcionan también

@kensimon Me funciona cuando solo desactivo KUBELET_NETWORK_ARGS durante kubadm init . Gracias a tus instrucciones pude verificar eso.

Confirmado @webwurst para que funcione cuando solo deshabilita KUBELET_NETWORK_ARGS durante kubadm init . Sin embargo, tuve que reiniciar kube-dns para que lo recogiera. El cheque de @kensimon funciona, resuelve dns.

Aunque estoy de acuerdo en que este es un truco terrible, y demasiado horrible para que la mayoría de la gente lo siga, mirando los canales flojos.

Los parches de @kensimon o @mikedanese presentan una mejor solución.

@coeki, ¿cómo exactamente reiniciaste kube-dns? Probé kubectl delete pod kube-dns-3913472980-l771x --namespace=kube-system y ahora kube-dns permanece pendiente kube-system kube-dns-3913472980-7jrwm 0/3 Pending 0 4m
Hizo exactamente como se describe: eliminar KUBELET_NETWORK_ARGS , sudo systemctl daemon-reload && sudo systemctl restart kubelet.service , kubeadm init , agregar KUBELET_NETWORK_ARGS , nuevamente sudo systemctl daemon-reload && sudo systemctl restart kubelet.service
Pero luego mi maestro se queda en NotReady . En describe obtengo

Conditions:
  Type          Status  LastHeartbeatTime           LastTransitionTime          Reason              Message
  ----          ------  -----------------           ------------------          ------              -------
...
KubeletNotReady         runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Intenté reiniciar kube-dns como se describe anteriormente, pero no tuve éxito. ¿Alguna idea? Me muero por esto, tratando de hacer que nuestro clúster se ejecute nuevamente después de una actualización 1.6.0 fallida esta morging :(

@patte Así que solo delete pods kube-dns-3913472980-3ljfx -n kube-system Y luego vuelve a aparecer kube-dns.

¿Después de kubeadm init, agregó KUBELET_NETWORK_ARGS , nuevamente sudo systemctl daemon-reload && sudo systemctl restart kubelet.service instaló una red de pod, como weave o calico? Agregue eso primero, debería poder hacerlo funcionar.

Probé y probé en centos7 y lo hice en ubuntu / xenial, así que debería funcionar.

Para recapitular lo que hice:

eliminar KUBELET_NETWORK_ARGS
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubeadm init --token=$TOKEN --apiserver-advertise-address=$(your apiserver ip address)

agregar KUBELET_NETWORK_ARGS nuevo
sudo systemctl daemon-reload && sudo systemctl restart kubelet.service

kubectl apply -f https://git.io/weave-kube-1.6

Me uní a una máquina, por lo general, tengo que agregar una ruta estática a 10.96.0.0 (IP del clúster) ya que estoy en vagabundo.
Úselo con $ TOKEN, pero este paso es adicional.

Luego:

delete pods kube-dns-3913472980-3ljfx -n kube-system

Espéralo

kubectl run nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run --rm -i -t ephemeral --image=busybox -- /bin/sh -l
/ # wget nginx.default.svc.cluster.local Connecting to nginx.default.svc.cluster.local (10.101.169.36:80) index.html 100% |***********************************************************************| 612 0:00:00 ETA

Funciona para mí, aunque es un truco horrible;)

Estoy realmente sorprendido de que la comunidad de desarrollo de Kubernetes no haya proporcionado ninguna ETA para una solución oficial. Quiero decir que este es un error horrible que debería detectarse fácilmente durante la prueba del código. Dado que no lo ha hecho, al menos, 1.6.1 debería promoverse lo antes posible con la solución para que las personas dejen de piratear sus clústeres y comiencen a hacer cosas productivas;). ¿Me equivoco aquí?

Oigan todos,

Estuve un poco distraído esta semana, y este es un hilo largo lleno de
cosas de kubeadm que no conozco muy bien. ¿Alguien puede resumirme? I
Creo que entiendo la esencia del error, pero ¿cuáles son las soluciones propuestas y
¿Qué los hace horribles?

El jueves 30 de marzo de 2017 a las 8:13 a. M., Serguei Bezverkhi < [email protected]

escribió:

Estoy realmente sorprendido de que la comunidad de desarrollo de Kubernetes no haya
proporcionó cualquier ETA para una solución oficial. Quiero decir que este es un error horrible que
debería quedar atrapado fácilmente durante la prueba del código. Dado que no lo ha hecho, en
como mínimo, la versión 1.6.1 debería introducirse lo antes posible con la solución para que la gente
deje de piratear sus clústeres y comience a hacer cosas productivas;). Soy yo
mal aquí?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290442315 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFVgVEoKuUf28VazmUApsnyfGhuAhZIqks5rq8aLgaJpZM4MtMRe
.

Un cambio en kubelet (# 43474) hizo que kubelet comenzara a informar correctamente que la red no estaba lista antes de que se inicializara el complemento cni. Esto rompió algunos pedidos de los que dependíamos y provocó un punto muerto en la inicialización del maestro de kubeadm. No lo detectamos porque las pruebas de kubeadm e2e se habían interrumpido durante unos días antes de este cambio.

Las correcciones propuestas actuales son # 43824 y # 43835.

ok, eso fue lo que entendí. El enclavamiento entre el complemento de red
viene y la preparación del nodo es un poco horrible en este momento.

El jueves 30 de marzo de 2017 a las 8:28 a. M., Mike Danese [email protected]
escribió:

Un cambio en kubelet (# 43474
https://github.com/kubernetes/kubernetes/pull/43474 ) provocó que kubelet
comience a informar correctamente que la red no está lista antes de que el complemento cni fuera
inicializado. Esto rompió algunos pedidos del que dependíamos y causó
un interbloqueo en la inicialización maestra de kubeadm. No lo atrapamos porque
Las pruebas de kubeadm e2e se habían interrumpido durante unos días antes de este cambio.

Las correcciones propuestas actuales son # 43824
https://github.com/kubernetes/kubernetes/pull/43824 y # 43835
https://github.com/kubernetes/kubernetes/pull/43835 .

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290447309 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFVgVLzQLxeV6qp1Rw1fNALDDaf-Sktyks5rq8o2gaJpZM4MtMRe
.

Todavía prefiero el # 43835. Es un cambio más simple, no creo que las comprobaciones de e2e deban hacerse donde están, y hay informes de que # 43824 aún no funciona. Voy a presionar para que esto se resuelva hoy.

+1 para resolverlo hoy, ya que se desperdician muchos esfuerzos en lidiar con la garantía de la solución alternativa.

No puedo creer que nadie haya probado kubeadm 1.6.0 antes del lanzamiento de 1.6.0 ...

Y, kubelet 1.5.6 + kubeadm 1.5.6 también están rotos, /etc/systemd/system/kubelet.service.d/10-kubeadm.conf hace referencia a /etc/kubernetes/pki/ca.crt pero kubeadm no genera ca.crt, aunque hay ca.pem.

Actualmente 1.6.0 y 1.5.6 son las únicas versiones que quedan en el repositorio apt de k8s ...

"fuera de la caja", palabras aprendidas hoy.

Todavía prefiero el # 43835. Es un cambio más simple, no creo que las comprobaciones de e2e deban hacerse donde están, y hay informes de que # 43824 aún no funciona. Voy a presionar para que esto se resuelva hoy.

De acuerdo con Mike en este. # 43835 es el cambio más simple y la validación (si es necesario) se puede realizar en una fase separada.

@thockin , realmente necesitamos condiciones y estados más detallados para la creación de redes, especialmente con ho stNetwork: true. Los nodos pueden estar listos para algunos pods, pero no para otros.

No podemos usar nodeNetworkUnavailable, porque eso es específico para los proveedores de la nube. Probablemente necesitemos otro, o una forma para que el planificador permita ho stNetwork: true pods en nodos con Net workReady: false , o hacer que las taints funcionen para nodos no preparados. Y pruebas de trabajo de kubeadm e2e :(

De acuerdo. He estado retrasando el problema porque no tenía grandes respuestas,
pero necesitamos obtener esto en 1.7

El jueves 30 de marzo de 2017 a las 10:02 a. M., Dan Williams [email protected]
escribió:

@thockin https://github.com/thockin realmente necesitamos un grano más fino
condiciones y estado para la creación de redes, especialmente con ho stNetwork: true.
Los nodos pueden estar listos para algunos pods, pero no para otros.

No podemos usar nodeNetworkUnavailable, porque eso es específico de la nube
proveedores. Probablemente necesitemos otro, o una forma para que el programador
permitir ho stNetwork: true pods en nodos con Net workReady: false , o hacer que el
las manchas funcionan para los nodos que no están preparados.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290475480 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFVgVAaO9c76_R8me9PDo96AQ1ZrplMxks5rq-A1gaJpZM4MtMRe
.

@thockin ¿ alguna solución preferida? Podemos bloquear la preparación del nodo y averiguar quién usa IsNodeReady () como ya lo hemos hecho, o podríamos agregar otra condición de nodo y luego arreglar quién sabe cuántos bits de la base de código en otro lugar. O tal vez haya otra opción.

No podemos usar nodeNetworkUnavailable, porque eso es específico para los proveedores de la nube. Probablemente necesitemos otro, o una forma para que el planificador permita ho stNetwork: true pods en nodos con Net workReady: false , o hacer que las taints funcionen para nodos no preparados.

Creo que el programador se puede arreglar para respetar las manchas y las tolerancias, en lugar de descartar por completo todos los nodos que no estén listos.
Alguien tendrá que aplicar la tolerancia en la red ho verdaderas vainas. No sé quién, pero no debería ser el programador, ya que enseñarle al programador a comprender las especificaciones del pod parece demasiado.

/ cc @davidopp @ dchen1107

Además, para cualquiera que haya probado mis parches o los de michael y se esté quedando colgado en el plano de control que se acerca, parece que construir un kubeadm desde master no funciona cuando se tiene que administrar un clúster v1.6.0 , debido a que kubeadm intenta ejecutar kube-apiserver con argumentos no válidos:

unknown flag: --proxy-client-cert-file

Si desea probar los cambios míos o de Michael contra un clúster v1.6.0, selecciónelos con precisión contra v1.6.0 en lugar de construir sobre el maestro por ahora.

@yujuhong, el programador ya aplica automáticamente las tolerancias a los pods (consulte https://github.com/kubernetes/kubernetes/pull/41414), esto parece un caso de uso bastante similar

No tengo una imagen clara de todas las impurezas y la preparación.
red, en este punto. Dan, tienes media hora para escribir el
estado actual, para que podamos empezar a separarlo? Creo que lo sabes
mejor. Siento que tenemos una serie de problemas granulares que acabamos de
cubierto con una manta hasta ahora.

El jueves 30 de marzo de 2017 a las 10:22 a.m., Ken Simon [email protected]
escribió:

@yujuhong https://github.com/yujuhong el programador ya
autoaplica tolerancias a las vainas (ver # 41414
https://github.com/kubernetes/kubernetes/pull/41414 ), esto parece un
caso de uso bastante similar

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290481017 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFVgVMas2IP5X5YA0V5626UlGbaS98jtks5rq-TCgaJpZM4MtMRe
.

@thockin Puedo hacer eso, ¿dónde debería ponerlo?

hay un par de problemas relacionados, ¿podemos cambiar el título de uno de ellos, publicar un
resumen del estado actual y partir de ahí?

El jueves 30 de marzo de 2017 a las 10:50 a.m., Dan Williams [email protected]
escribió:

@thockin https://github.com/thockin Puedo hacer eso, ¿dónde debería poner?
¿eso?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290489157 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFVgVCXJYk9J0QmjTqQA6PPVuhzMHlLZks5rq-t-gaJpZM4MtMRe
.

¿Tenemos alguna línea de tiempo sobre cuándo se transferirá este arreglo al repositorio de CentOS?

En 1.6, de forma predeterminada, el núcleo de Kubernetes no aplica automáticamente ninguna contaminación a los nodos. El programador respeta las taints que se agregan mediante sistemas de implementación como kubeadm, kops, etc. o que los usuarios agregan manualmente (y respeta las tolerancias correspondientes que se agregan a los pods).

En 1.6, de forma predeterminada, el programador de Kubernetes excluye a los nodos de la consideración si informan sobre determinadas condiciones de los nodos, incluida la red no disponible. El código para eso está aquí . No tiene nada que ver con taints, solo está mirando la condición del nodo.

En 1.6 puede habilitar una función alfa que hace que el núcleo de Kubernetes (el NodeController) agregue una contaminación NoExecute siempre que haya NodeReady == "False" o NodeReady == "Desconocido". Esto hará que los pods que se ejecutan en el nodo sean desalojados (si no toleran la contaminación) y evitará que se programen nuevos pods en el nodo (si no toleran la contaminación).

El plan a largo plazo es mover toda la lógica de "cómo reacciona el núcleo Kubernetes a las condiciones del nodo, con respecto a la programación y el desalojo" para usar taints y tolerancias (por ejemplo, # 42001). Pero aún no hemos llegado y no lo estaremos por un tiempo. Por lo tanto, a corto plazo, no hay forma de que un pod "tolere" NetworkUnavailable o cualquier otra condición de nodo que pueda decidir agregar.

Si entiendo bien lo que dijo @davidopp , entonces la función es NodeReady, que ahora devuelve verdadero, falso o desconocido, marca una lista con lo que se necesita. Si pudiera devolver una lista de valores que no se cumplieron, puede probarlo.

En el caso de kubeadm, si entonces NetworkUnavailable, es el único. kubeadm puede devolver verdadero. Eso es en el caso de que no queramos que el complemento networking / cni se pase en el momento de inicio de kubeadm.

Porque si lo entiendo bien, la taint y la tolerancia se establecen en función de esta función, al menos para kubeadm.

Corrígeme si estoy equivocado ;)

Saltando a este hilo porque encontré este problema y es molesto:

¿Por qué la preparación de la red no puede convertirse en una mancha que el kubelet agrega y elimina en función del estado de la red en el nodo?
De esa manera, el nodo puede estar "Listo" para todos los pods que toleran la contaminación de la preparación de la red (aplicaciones de red del pod).

En cuanto a los pods de la red de host, un controlador de admisión podría inyectar tolerancias a la contaminación de la preparación de la red del pod.

Creo que eso se alinea con el plan a largo plazo en el comentario de Davidopp.

Creo que eso se alinea con el plan a largo plazo en el comentario de Davidopp.

Sí exactamente. El plan a largo plazo es tener una mancha para cada condición de nodo y dejar de tener algo interno en Kubernetes que preste atención a las condiciones de nodo. Comenzamos ese trabajo con la característica 1.6 alfa que mencioné.

Ack. ¿Hay alguna razón para no cambiar a taints en la versión del parche v1.6?

El código para agregar taints automáticamente en función de las condiciones del nodo acaba de entrar en alfa en 1.6. No está listo para confiar en él. (Y solo maneja la condición de nodo listo actualmente, no la red).

Entonces, si lo entiendo correctamente, por ahora, dado que https://github.com/kubernetes/features/issues/166 está tardando un poco más en poder contaminar la disponibilidad de la red correctamente, tenemos que solucionarlo. Si podemos presionar una solución lo antes posible para kubeadm, como # 43835, con un comentario para solucionar esto con https://github.com/kubernetes/features/issues/166 , muchas personas estarán felices.

@davidopp Supongo que quisiste decir " no confiado ". Todavía me falta la relación entre la condición automática para manchar la lógica que mencionaste con la de las manchas de publicación de kubelet directamente para problemas de red.

Sí, gracias, fue un error tipográfico, solucionado ahora

Sí, podría hacer que Kubelet agregue la mancha. Puede que no sea ideal que Kubelet agregue las taints para algunas condiciones de nodo y NodeController las agregue para otras condiciones de nodo (esta última es necesaria porque solo el maestro puede detectar el nodo inalcanzable), pero eso es solo un argumento de ingeniería de software, no nada fundamental. Mi plan había sido que NodeController agregara las taints para todas las condiciones del nodo, pero no hay un requisito estricto para hacerlo de esa manera.

Ack. En este caso, una sola condición de nodo tiene varios atributos asociados que el controlador de nodo puede no ser capaz de discernir.
@mikedanese Siento que el comportamiento existente de kubeadm init resulta en un nodo en funcionamiento es atractivo. Espero que el requisito de agregar una fase validation no se base principalmente en este problema.
@dcbw @thockin @yujuhong ¿ Alguna idea sobre el uso de taints para representar problemas de configuración de nodos en el kubelet?

Tenga en cuenta que si desea que su nueva mancha reemplace el filtrado automático actual de nodos con NetworkUnavailable, deberá modificar la función que mencioné anteriormente (es decir, eliminarla del conjunto de condiciones que filtran un nodo). No sé qué otros efectos secundarios tendrá, ya que esa función puede usarse en listas de nodos además del programador.

¿Hay alguna forma de instalar 1.5.6 que debería funcionar en Ubuntu? Si lo hay, ¿podría explicar cómo se hace? ¡Gracias!

Tenga en cuenta que si desea que su nueva mancha reemplace el filtrado automático actual de nodos con NetworkUnavailable, deberá modificar la función que mencioné anteriormente (es decir, eliminarla del conjunto de condiciones que filtran un nodo). No sé qué otros efectos secundarios tendrá, ya que esa función puede usarse en listas de nodos además del programador.

@davidopp debemos tener cuidado con NetworkUnavailable frente a NodeReady. Hay dos condiciones separadas que realmente deberían limpiarse:

nodeNetworkUnavailable: esto es específico de las rutas en la nube, y solo los controladores de ruta en la nube borran esta condición cuando se han configurado las rutas en la nube entre los nodos. Los complementos de red que crean superposiciones o que no realizan enrutamiento L3 entre nodos no quieren ni utilizan esta condición. Ningún complemento de red agrega esta condición; kubelet lo agrega específicamente cuando se seleccionan GCE o AWS como proveedores de nube. No afecta a NodeReady ya que es una condición separada.

NodeReady: afectado directamente por los complementos de red (por ejemplo, CNI o kubenet o tiempos de ejecución remotos como dockershim / CRI-O).

Hay tres cuestiones distintas a considerar:

1. Rutas en la nube: si la infraestructura en la nube y el complemento de red requieren rutas en la nube, entonces la falta de rutas en la nube (por ejemplo, NodeNetworkUnavailable = true) debe bloquear la programación hostNetwork = false pods
2. Complementos de red: si el complemento aún no está listo, debe bloquear la programación de hostNetwork = pods falsos. Esto es independiente de NodeNetworkUnavailable porque es posible que el complemento no tenga interacción directa con un controlador de rutas porque no depende de las rutas de la nube. Por ejemplo, kubenet se puede usar localmente en el nodo si tiene algo más (rutas en la nube, franela, etc.) configurando rutas de nodo.
3. hostNetwork = true Los pods deben ignorar todas estas condiciones y ser programados, pero sujetos a cualquier otra condición aplicable (espacio en disco, etc.)

NodeReady es un martillo demasiado grande. Estoy pensando que probablemente queremos una condición adicional NetworkPluginReady para la preparación del complemento de red (¡separada de la preparación de las rutas en la nube!) Y luego tenemos que conectar eso a los lugares que importan :( O, en realidad, nuevas contaminaciones, no condiciones.

Otro trabajo que encontré.

Mientras kubeadm sigue imprimiendo '[apiclient] El primer nodo se ha registrado, pero aún no está listo', implementé 'kube-flannel.yml' que instala flanneld. Y funcionó sin cambiar los archivos de configuración.

1) kubeadm init --pod-network-cidr = 10.244.0.0 / 16 y
2) cp /etc/kubernetes/admin.conf ~ / .kube / config
3) kubectl apply -f kube-flannel-rbac.yml (necesario en kubeadm 1.6)
4) kubectl aplica -f kube-flannel.yaml
Utilice kube-flannel.yaml en https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml

Podría hacer que el nodo maestro esté 'Listo'. Pero, kube-dns falló con el mensaje,

Error syncing pod, skipping: failed to "CreatePodSandbox" for "kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)" with CreatePodSandboxError: "CreatePodSandbox for pod \"kube-dns-2759646324-nppx6_kube-system(bd585951-15cb-11e7-95c3-1c98ec12245c)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"kube-dns-2759646324-nppx6_kube-system\" network: \"cni0\" already has an IP address different from 10.244.0.1/24"

Después de cambiar el complemento de red a weave-net, funcionó.

@dcbw No sé lo suficiente sobre el problema específico discutido en este número para decirle exactamente qué hacer. Solo quería explicar el estado actual de las corrupciones y cómo podrían aplicarse aquí.

POR FAVOR PRUEBE LAS DEBORACIONES PARCHADAS

El kubernetes-xenial-unstable ahora tiene una compilación parcheada 1.6.1-beta.0.5+d8a384c1c5e35d-00 que @pipejakob y yo hemos estado probando hoy. Los nodos no permanecen listos hasta que se crea una red de vainas (por ejemplo, aplicando configuraciones de tejido / franela). Aprobación de la prueba de conformidad. PTAL.

# cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main
EOF

cc @luxas @jbeda

Es la dirección general en la que las taints pueden expresar casi todo
las condiciones pueden, y son, por tanto, mejores en todos los sentidos?

Estoy de acuerdo en que necesitamos una señal más granular. Todavía tenemos que resolver el
interacción entre kubelet, controlador de red, controlador de nube y proveedor de nube
para desbloquear hostNetwork = false pods, pero hostNetwork = true no debería ser
obstruido.

El jueves 30 de marzo de 2017 a las 7:24 p.m., Dan Williams [email protected]
escribió:

Tenga en cuenta que si desea que su nueva mancha reemplace la actual
filtrado de nodos con NetworkUnavailable, deberá modificar el
función que mencioné anteriormente (es decir, elimínela del conjunto de condiciones
que filtran un nodo). No sé qué otros efectos secundarios
tienen, ya que esa función se puede utilizar en listas de nodos que no sean solo los
planificador.

@davidopp https://github.com/davidopp tenemos que tener cuidado con
NetworkUnavailable frente a NodeReady. Hay dos condiciones distintas que
realmente debería limpiarse:

nodeNetworkUnavailable: esto es específico para las rutas en la nube, y solo en la nube
Los controladores de ruta borran esta condición cuando las rutas en la nube entre nodos tienen
sido configurado. Complementos de red que crean superposiciones o que no hacen L3
el enrutamiento entre nodos no desea ni utiliza esta condición. Esta condición es
no agregado por ningún complemento de red; es agregado por kubelet específicamente cuando
GCE o AWS se seleccionan como proveedores de nube. No afecta a NodeReady desde
es una condición separada.

NodeReady: afectado directamente por los complementos de red (p. Ej., CNI o kubenet
o tiempos de ejecución remotos como dockershim / CRI-O).

Hay tres cuestiones distintas a considerar:

1. Cloud Routes: si la infraestructura de la nube y el complemento de red
   requieren rutas en la nube, luego la falta de rutas en la nube (p. ej.,
   NodeNetworkUnavailable = true) necesita bloquear la programación hostNetwork = false
   vainas
2. Complementos de red: si el complemento aún no está listo, es necesario
   bloquear la programación de hostNetwork = pods falsos
3. hostNetwork = true pods deben ignorar todas estas condiciones y ser
   programado, pero sujeto a cualquier otra condición aplicable (espacio en disco, etc.)

NodeReady es un martillo demasiado grande. Estoy pensando que probablemente queremos un
condición adicional NetworkPluginReady para la preparación del complemento de red
(¡aparte de la preparación de las rutas en la nube!) y luego tenemos que sondear eso
a lugares que se preocupan :(

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290597988 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AFVgVGIn0CpVkcHd2SVaoRsp2RJNEgXFks5rrGPqgaJpZM4MtMRe
.

Para cualquiera que todavía intente la solución temporal eliminando la línea de configuración KUBELET_NETWORK_ARGS de kubelet, @ jc1arke encontró una solución alternativa más simple: tener dos sesiones para el nuevo maestro y, mientras espera que el primer nodo esté listo, aplique una configuración de red de nodo en el segundo sesión:
Primera sesión después de ejecutar kubeadmin init:

...
[apiclient] Created API client, waiting for the control plane to become ready
[apiclient] All control plane components are healthy after 24.820861 seconds
[apiclient] Waiting for at least one node to register and become ready
[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
...

Segunda sesión (usando Calico. Por supuesto, su elección puede variar):

root@kube-test-master-tantk:~# kubectl apply -f http://docs.projectcalico.org/v2.0/getting-started/kubernetes/installation/hosted/kubeadm/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
job "configure-calico" created
root@kube-test-master-tantk:~#

Volver a la primera sesión:

...
[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 118.912515 seconds
[apiclient] Test deployment succeeded
[token] Using token: <to.ken>
[apiconfig] Created RBAC rules
...

Es la dirección general en la que las taints pueden expresar casi todo
las condiciones pueden, y son, por tanto, mejores en todos los sentidos?

Bastante. Probablemente no podamos deshacernos de ninguna de las condiciones del nodo debido a problemas de compatibilidad con versiones anteriores, pero podemos deshacernos de toda la lógica en el maestro que toma medidas basadas en ellos (como bloquear la programación o desalojar pods). Además de hacer que el comportamiento sea más obvio (no es necesario memorizar qué condiciones bloquean la programación, cuáles causan el desalojo, cuánto tiempo esperamos para el desalojo, etc.), la reacción a las condiciones es configurable por grupo.

Acabo de probar las debs de @pipejakob , estas funcionan bien.

Probado en ubuntu / xenial:

root<strong i="9">@kube1</strong>:/home/ubuntu# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Acabo de probar las debs de @pipejakob , todavía se congela en
[apiclient] Created API client, waiting for the control plane to become ready

He esperado unos cinco minutos, pero nada ha cambiado.
Y ayer seguía repitiendo
[apiclient] First node has registered, but is not ready yet

TTI cree que el problema sigue sin solución?

Probado en Ubuntu 16.04:
kubeadm version: version.Info {Major: "1", Minor: "6+", GitVersion: "v1.6.1-beta.0.5 + d8a384c1c5e35d", GitCommit: "d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTree ", GitTree" -03-31T04: 20: 36Z ", GoVersion:" go1.7.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

@ myqq0000 ¿puedes publicar la versión que estás usando?

kubeadm version

@coeki Oh, lo olvidé. Acabo de editar y publico la versión en mi comentario anterior. :)

@mikedanese ¿Tiene algún plan para actualizar centos yum repo? ¿O ya está implementado en yum repo?

Acabo de probar 1.6.1-beta.0.5+d8a384c1c5e35d-00 (el 1.6.1-beta.0.5+48c6a53cf4ff7d-00 mencionado en https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-290616036 no parece existir).

Parece que funciona bien.
No relacionado: tenga en cuenta que si está utilizando weave, debe aplicar https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml en lugar del https: / /git.io/weave-kube

@mausch ¿Podrías decirme cómo conseguir estas debs?

@ srinat999 https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290616036

Las debs parcheadas de

root@kube-test0:~# kubeadm version
kubeadm version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.1-beta.0.5+d8a384c1c5e35d", GitCommit:"d8a384c1c5e35d5118f79808deb7bab41f3f7964", GitTreeState:"clean", BuildDate:"2017-03-31T04:20:36Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

@mausch Gracias. También funcionan para mí con el proveedor de la red de tejido.

¿Alguna posibilidad de construir la misma solución para Centos también? Nuestro sistema de activación utiliza principalmente centos para la base de clústeres de kubernetes. Si tengo la versión centos puedo garantizar aprox. 100 ejecuciones de kubeadm init al día como prueba.

Las debs parcheadas de kubeadm está notificando que el clúster está listo, pero el nodo en sí no lo está.

Los nodos kubectl apply -f https://git.io/weave-kube-1.6

En mi entorno de prueba (in vagrant, basado en máquinas centos / 7), kubeadm simplemente se cuelga. Usando strace puedo verlo tratando de conectarse al servidor de kubelet en el maestro, y haciendo FUTEX_WAIT, epoll_wait reintentar bucles. Pero no hay salida de salida de una sola línea que provenga de él.

kubelet no se inicia, lo que parece ser la razón.
(Pero no veo las razones por las que kublet no pudo comenzar ...)

¿Es este el problema de este tema?

Obtengo binarios del repositorio http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 .
También intento actualizar los binarios de https://storage.googleapis.com/kubernetes-release/release/v1.6.0/bin/linux/amd64/ .

==> ¿Dónde puedo obtener una versión parcheada de kubeadm para probar? <==

Nota: Encontré una versión parcheada (reclamada) de kubeadm a la que se hace referencia en este problema en https://github.com/kensimon/aws-quickstart/commit/9ae07f8d9de29c6cbca4624a61e78ab4fe69ebc4 (la versión parcheada es esta: https: // heptio-aws-quickstart- test.s3.amazonaws.com/heptio/kubernetes/ken-test/kubeadm), pero eso no me funciona. El comportamiento sigue siendo el mismo (sin salida alguna) ...

@ squall0gd ¿Puede mostrarnos el mensaje exacto que está viendo? De acuerdo con lo que describe, me pregunto si realmente eligió el nuevo .debs o si estaba usando versiones antiguas almacenadas en caché.

@thockin @davidopp, por lo que según la sugerencia de Tim, me https: // github. com / kubernetes / kubernetes / issues / 43815 # issuecomment -290597988 en él.

Esto es lo que aparentemente funciona para mí con el repositorio unstable (solo probé el maestro en sí):

"sudo apt-get update && sudo apt-get install -y apt-transport-https",
"echo 'deb http://apt.kubernetes.io/ kubernetes-xenial-unstable main' | sudo tee /etc/apt/sources.list.d/kubernetes.list",
"curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -",
"sudo apt-get update",
"sudo apt-get install -y docker.io",
"sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni",
"sudo service kubelet stop",
"sudo service kubelet start",
"sudo kubeadm init",
"sudo cp /etc/kubernetes/admin.conf $HOME/",
"sudo chown $(id -u):$(id -g) $HOME/admin.conf",
"export KUBECONFIG=$HOME/admin.conf",
"kubectl taint nodes --all dedicated-",
"kubectl apply -f https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml",

Esto arroja error: taint "dedicated:" not found en un punto, pero parece continuar independientemente.

¿No ejecutamos estas pruebas en la rama 1.6?

Las condiciones del nodo

kubeadm no parece que esté probado en la rama de lanzamiento:
https://k8s-testgrid.appspot.com/release-1.6-all

@ bgrant0607 aparentemente, las pruebas de kubeadm e2e estuvieron deshabilitadas / no funcionaron durante aproximadamente una semana antes de la versión 1.6, IIRC

Las condiciones de los nodos están destinadas a proporcionar información adicional para los humanos, para comprender lo que está sucediendo, como el motivo, el mensaje y el tiempo de transición.

@ bgrant0607 ¿ están destinados principalmente a información humana o es solo un efecto secundario feliz? Si son principalmente para humanos, ¿deberían usarse para programar decisiones como lo son actualmente o deberíamos alejarnos de eso?

@dcbw Taints está destinado a convertirse en el GUT de la falta de programación y la interrupción. Eventualmente, el programador debería ignorar las condiciones.

https://github.com/kubernetes/kubernetes/pull/18263#issuecomment -169220144
https://github.com/kubernetes/kubernetes/issues/29178

Tenga en cuenta que si vamos a agregar una mancha a los nodos, debemos considerar

a) Compatibilidad con versiones anteriores, como con la mancha maestra: https://github.com/kubernetes/kubernetes/pull/43537

b) Versión sesgada. Al actualizar los clústeres a 1.6, los kubelets serán de versiones mixtas y algunos pueden ser tan antiguos como 1.4.

así que para recapitular o mientras analizo esto:

basado en @dcbw

nodeNetworkUnavailable es una cosa del proveedor de la nube, no vinculado a kubeadm atm, podríamos encontrarnos con esto.

Pero NodeReady, que es la causa raíz del bucle, necesita ser más granular. Esto es lo que @davidopp quiere ser una mancha, basado en una lista que está marcando casillas, en lo que respecta a la sonda / vivencia, CNI listo, etc.

bien, aunque se podría discutir, ¿por qué no etiquetar?

Pero @dcbw , ¿encontró un hilo más adecuado para esta discusión? Porque este se convierte en un cubo de problemas con la implementación y no es realmente la raíz de las cosas.

Lo sé, fui parte de no llegar realmente al problema y publicar trucos al respecto :)

Pero de todos modos, deberíamos discutir los fundamentos en otro lugar, asegurarnos de que se coloque aquí un ETA fijo y seguir adelante.

No ser ágil, pero bueno :)

PD: sí @ bgrant0607 , deberíamos haber probado esto más
PS2 Si veo esto mal, puedes culparme;)

@coeki También agregaría una solicitud para que las versiones N-1 se mantengan en

@ kfox1111 La puerta también es un problema ... necesitamos una mejor estrategia al respecto :)

¿Por qué incluso eliminar versiones antiguas? Eso podría romper fácilmente la automatización de las personas y evitar instalaciones repetibles.

Las condiciones de los nodos están destinadas a proporcionar información adicional para los humanos, para comprender lo que está sucediendo, como el motivo, el mensaje y el tiempo de transición.

Acordado. La experiencia de usuario es definitivamente una de las principales razones por las que probablemente no podamos deshacernos de las condiciones de los nodos. Sin embargo, creo que podemos deshacernos de todos los usos de las condiciones del nodo como desencadenante de acciones maestras (como el desalojo y la programación de bloqueo) y usar taints para eso.

A largo plazo (como la API v2 a largo plazo) es concebible que podamos agregar razones y mensajes a las taints y luego deshacernos de las condiciones del nodo, pero realmente no lo he pensado y definitivamente no estoy proponiendo formalmente hacerlo. (Ya tenemos el equivalente al tiempo de transición en una dirección, a saber, TimeAdded).

@coeki no, de lo que estaba hablando no tiene nada que ver con la puerta. Gating no puede encontrar todos los problemas a menos que tenga una puerta que pruebe todo lo que podría hacerse. A los operadores les gusta hacer cosas raras en sus entornos. :) Prohibitivamente caro para probar todas las cosas posibles.

Estoy pidiendo que no se elimine la versión anterior antes de que la nueva haya pasado al menos a través de la primera versión de corrección de errores. Para este ejemplo, 1.6.1. Como mínimo. Mantener más versiones antiguas es aún mejor. Esta es una buena práctica para permitir que los operadores continúen progresando mientras se resuelven los errores en la nueva versión.

@ kfox1111 , eso es lo que hace la compuerta, no ir con algo que parece bueno, y descartar la vieja forma de confianza, lo que sucedió ahora.

@davidopp Estoy de acuerdo en que las etiquetas y taints pueden tener una distinción diferente de una forma de api de verlo, UX y maquinaria, pero bueno, es difuso en este momento. También yo, eso es :)

De todos modos, me atraes a una discusión, realmente no debemos tener en este tema, ese era mi punto.

Me gustaría preguntar de nuevo: si veo "kubeadm init" simplemente colgando sin salida (tratando de conectarme al servidor de kubelet, que no ha podido iniciarse), ¿estoy sufriendo este problema? Y si este es un caso, ¿el # 43835 es una solución para mí?

Ahora, ¿dónde puedo conseguir?

• ya sea versiones anteriores (anteriores a 1.6.0) de kubeadm / kubectl / kubelet
• o una versión parcheada de kubeadm (incluyendo # 43835 o cualquier otra solución)?

¡Gracias!

(nota: la versión parcheada de kubeadm a la que se hace referencia en la confirmación mencionada anteriormente no funciona para mí ...)

@obnoxxx prueba la punta de la rama release-1.6.

$ gsutil ls gs://kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9

https://storage.googleapis.com/kubernetes-release-dev/ci/v1.6.1-beta.0.12+018a96913f57f9/bin/linux/amd64/kubeadm

@mikedanese gracias! difícil...

Si ejecuta kubeadm sin instalar el paquete del sistema operativo, debe

$ cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_EXTRA_ARGS
EOF
$ systemctl daemon-reload
$ systemctl restart kubelet

de https://github.com/kubernetes/release/blob/master/debian/xenial/kubeadm/channel/stable/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

@mikedanese gracias. Estoy instalando el paquete del sistema operativo (desde el repositorio de kube) y luego instalando los binarios de la URL web sobre los binarios de los rpms ...

Sin embargo, la versión 1.6.1-beta.0.12 no me funcionó:
kubeadm init todavía se cuelga sin ninguna salida. (intentando conectarse a kubelet)

No olvide el controlador systemd también si centos.

controlador del sistema?

https://github.com/kubernetes/release/issues/306

Dios, gracias, eso es mejor! :-)

@pipejakob No tengo acceso a estos registros en este momento, pero he comprobado la versión de kubeadm y era la misma versión que tiene @webwurst . Además, he comprobado las posibles versiones de kubeadm con apt-cache policy kubeadm . Y solo había una entrada, de kubernetes-xenial-unstable.
@mikedanese probé con franela antes de publicar;)
EDITAR: He reconstruido toda la plataforma y kubadm está funcionando bien: +1:

Chicos, ¿cuál es el status quo para la solución? ¿Se moverá al repositorio estable pronto?

Los debs parcheados de

¿Alguien puede decirme cómo construir una versión parcheada de kubeadm para rhel (rpm)?

@mikedanese con correctamente , pero el mensaje "el complemento de red no está listo: cni config uninitialized" persiste.

El nodo maestro está en NotReady .

El weave-net (weaveworks / weave-kube: 1.9.4 - https://github.com/weaveworks/weave/releases/download/latest_release/weave-daemonset-k8s-1.6.yaml) está en 1/2 CrashLoopBackOff :

FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "weave"

El pod kube-dns está en 0/3 Pending .

@ChipmunkV Probablemente necesite configurar kube-proxy para que se ejecute en el espacio de usuario. Esto también ha sido un problema en 1.5.

command:
  - /usr/local/bin/kube-proxy
  - --kubeconfig=/var/lib/kube-proxy/kubeconfig.conf
  # add this line:
  - --proxy-mode=userspace

Por lo que vale, kubernetes-xenial-unstable está funcionando bien.

@pstadler , gracias a @errordeveloper en el chat que ha señalado que tengo redes superpuestas, he reconfigurado el IPALLOC_RANGE en el tejido.

Gracias @thenayr. Podría abrir el maestro de Kubernetes pero también podría conectar un trabajador a él usando kubeadm join. Publicará más actualizaciones pronto

@mikedanese me tomó una eternidad averiguar qué versión usar, hasta que leí todos los comentarios aquí. Realmente necesitamos facilitar la búsqueda de binarios para una versión determinada. Intenté usar los puntos ci-cross/latest.txt (es decir, v1.7.0-alpha.0.1982+70684584beeb0c ), y eso sucede para introducir la nueva bandera kube-apiserver (es decir, --proxy-client-key-file en d8be13fee85075abfc087632b3dbc586a10897ad), que no funciona con ninguna de las etiquetas recientes en gcr.io/google_containers/kube-apiserver-amd64 ...

¿Cómo podemos hacer que sea más fácil descubrir qué revisiones tienen binarios en el depósito? Ser capaz de enumerar directorios sería bueno, o tener un archivo de mapa simple o simplemente cualquier cosa que no requiera tener que saber o tener que adivinar.

@errordeveloper , estamos tratando de hacer un lanzamiento para que podamos enviar una solución a la rama estable, debería hacerse en O (días), espero. Hay un enlace en la descripción de este problema a las debs parcheadas en inestable.

La versión anterior 1.5.6 me funcionaba en CentOs 7, pero ahora ni siquiera puedo revertir porque la única versión de kubeadm en http://yum.kubernetes.io/repos/kubernetes-el7-x86_64 es la 1.6 rota. 0. ¿Alguna sugerencia sobre cómo obtener kubeadm 1.5.6 RPM?

De hecho, es una lástima. Las versiones antiguas parecen haber sido eliminadas por completo. :-(

Mis resultados son estos en centos 7:

• No he podido hacer que kubadm init me dé ningún resultado, incluso con un kubeadm actualizado y actualizado, sin hacer algo sobre kubectl.
• He podido hacer que kubectl comience con las instrucciones de @coeki , y luego kubeadm incluso pasó. Pero después de eso, nada funciona para mí. kubectl dice

The connection to the server localhost:8080 was refused - did you specify the right host or port?

¿Alguna pista de lo que está pasando?

@obnoxxx por defecto apiserver no escucha en 8080, escucha en el puerto seguro 6443, puede verificar con netstat -tunlp.
Necesita copiar admin.conf de / etc / kubernetes a su $ HOME / .kube / config
asegúrese de cambiar los permisos en el archivo en su $ HOME / .kube /, después de eso, su kubectl debería poder comunicarse con apiserver correctamente. HTH. Serguei

@apsinha ¿

La parte superior de mi cabeza:

• 1.6.0 nunca pasó por pruebas automatizadas: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290809481
• Se eliminaron los binarios / paquetes para versiones anteriores, por lo que la gente no puede revertir de forma segura; rompió cualquier automatización de instalación que suponía que seguían estando disponibles: https://github.com/kubernetes/kubernetes/issues/43815#issuecomment -290861903
• Ningún anuncio público (que yo haya visto) del hecho de que esto está roto
• No se ha proporcionado un cronograma sobre una solución (soy un desarrollador, así que sé lo desagradable que es que me pregunten "¿cuándo se solucionará?", Pero, sin embargo, la gente preguntará esto, por lo que es bueno ofrecer al menos un período de tiempo estimado).
• Los usuarios que continúan uniéndose a la conversación están confundidos sobre el estado de las cosas, las soluciones y el calendario de arreglos.
• Mucha discusión técnica entre los colaboradores, muchos de los cuales tratan sobre la estrategia a largo plazo, combinados en el mismo hilo mientras los usuarios intentan averiguar qué está pasando y cómo lidiar con el problema inmediato.

Sin faltarle el respeto a todas las grandes personas que hacen de Kubernetes lo que es. Solo espero que haya algunos "momentos de enseñanza" aquí en el futuro, ya que esto se ve mal en términos de la percepción pública de que Kubernetes es confiable / estable. (Por supuesto, kubeadm es alfa / beta, pero aún tiene mucha visibilidad).

Construí kubeadm-1.5.6 usando kubernetes / release.rpm solo para encontrar (para mi consternación) que

# rpm -Uvh kubectl-1.5.6-0.x86_64.rpm kubeadm-1.5.6-0.x86_64.rpm 
error: Failed dependencies:
        kubectl >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64
        kubelet >= 1.6.0 is needed by kubeadm-1.5.6-0.x86_64

@bostone necesita ajustar el .spec aquí .

@sbezverk ¡ gracias por la pista! Es mejor ahora...

Esto es curioso:

• No recuerdo que copiar el admin.conf fuera necesario para mí en versiones anteriores.
• Intenté con kubectl -s localhost:6443 antes, pero no fue suficiente.

De todos modos, ahora puedo continuar. Gracias de nuevo

v1.6.1 está en proceso de ser lanzado. Lo hará EOD.

Algunas notas:

1. El problema con la eliminación de paquetes antiguos se rastreó aquí: https://github.com/kubernetes/release/issues/234. Debido a algunas versiones extravagantes de kubeadm y cómo estas cosas se ordenan alfabéticamente, aparentemente no fue posible mantener la versión 1.5.x de kubeadm en el repositorio. ( @bostone, su problema también se menciona allí)
2. Pruebas de kubeadm e2e en RP que se están rastreando aquí: https://github.com/kubernetes/kubeadm/issues/190
3. En cuanto al anuncio público, publiqué en Twitter, pero eso no es oficial. No está claro cuáles son los canales correctos para problemas críticos como este.

Todos estos son buenos temas para abordar en un PM. @pipejakob se ha ofrecido gentilmente como voluntario para realizar esa autopsia.

@obnoxxx El requisito de copiar / chown el admin.conf era necesario antes porque con 1.5 teníamos el servidor API exponiendo un puerto inseguro. Cambiamos eso en 1.6. Ahora debe usar credenciales seguras para acceder al servidor API (consulte https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubeadm-2)

@mikedanese eso suena genial, ¡gracias!
Solo para el tonto que soy: ¿cuál será el efecto de esta versión 1.6.1 con respecto a este problema?
¿Comenzará kubelet sin el cambio a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf (solución alternativa de @coeki ) o contendrá la corrección de # 43835 (que no pareció tener ningún efecto para mí)?

@jbeda gracias por la explicación!

@jbeda Creo que la confusión proviene del documento oficial de instalación de kubadm que configura el repositorio de YUM en http://yum.kubernetes.io/repos/kubernetes-el7-x86_64. Ese repositorio solo tiene kubeadm-1.6.0

Y de nuevo, para mi decepción, la construcción de 1.5.6 rpms y la instalación terminó con el mismo problema exacto. Ejecutar kubeadm init está colgado en la misma línea:

# kubeadm init
Running pre-flight checks
<master/tokens> generated token: "5076be.38581a71134596d0"
<master/pki> generated Certificate Authority key and certificate:
Issuer: CN=kubernetes | Subject: CN=kubernetes | CA: true
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2027-04-01 21:28:18 +0000 UTC
Public: /etc/kubernetes/pki/ca-pub.pem
Private: /etc/kubernetes/pki/ca-key.pem
Cert: /etc/kubernetes/pki/ca.pem
<master/pki> generated API Server key and certificate:
Issuer: CN=kubernetes | Subject: CN=kube-apiserver | CA: false
Not before: 2017-04-03 21:28:18 +0000 UTC Not After: 2018-04-03 21:28:18 +0000 UTC
Alternate Names: [10.25.47.21 10.96.0.1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local]
Public: /etc/kubernetes/pki/apiserver-pub.pem
Private: /etc/kubernetes/pki/apiserver-key.pem
Cert: /etc/kubernetes/pki/apiserver.pem
<master/pki> generated Service Account Signing keys:
Public: /etc/kubernetes/pki/sa-pub.pem
Private: /etc/kubernetes/pki/sa-key.pem
<master/pki> created keys and certificates in "/etc/kubernetes/pki"
<util/kubeconfig> created "/etc/kubernetes/kubelet.conf"
<util/kubeconfig> created "/etc/kubernetes/admin.conf"
<master/apiclient> created API client configuration
<master/apiclient> created API client, waiting for the control plane to become ready

Supongo que solo esperaré el lanzamiento de 1.6.1 y espero ...

1.6.1 está fuera.

@mikedanese , ¿probaste kubeadm antes de cerrar este error? Ahora mismo estoy mirando [apiclient] Created API client, waiting for the control plane to become ready durante 10 minutos. En CentOS 7 con la nueva instalación 1.6.1

@bostone, es posible que tenga este problema: # 43805

Intente editar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf y agregar --cgroup-driver=systemd

Recuerde ejecutar systemctl daemon-reload; systemctl restart kubelet

@gtirloni con nuestra sugerencia llegué al final de kubeadm init sin embargo, cualquier intento de ejecutar kubectl produce este error: The connection to the server localhost:8080 was refused - did you specify the right host or port? No estoy seguro de dónde y cómo cambiar eso o cuál es el puerto correcto en ¿este punto?

No estoy seguro si esto está relacionado, pero esto es lo que veo cuando ejecuto systemctl status kubelet :
`` `estado systemctl kubelet -l
● kubelet.service - kubelet: el agente de nodo de Kubernetes
Cargado: cargado (/etc/systemd/system/kubelet.service; habilitado; preajuste del proveedor: deshabilitado)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Activo: activo (en ejecución) desde Lun 2017-04-03 17:31:07 PDT; Hace 11min
Documentos: http://kubernetes.io/docs/
PID principal: 10382 (kubelet)
CGroup: /system.slice/kubelet.service
├─10382 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --allow-privileged = true - -network-plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorization-mode = Webhook --client-ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = systemd
└─10436 journalctl -k -f

03 de abril 17:41:56 sdl02269 kubelet [10382]: W0403 17: 41: 56.645299 10382 cni.go: 157] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
03 de abril 17:41:56 sdl02269 kubelet [10382]: E0403 17: 41: 56.645407 10382 kubelet.go: 2067] La ​​red de tiempo de ejecución del contenedor no está lista: NetworkReady = razón falsa mensaje: docker : el complemento de red no está listo: cni config no inicializado

Sí, lo probamos. Las pruebas de e2e están pasando en la rama de lanzamiento. Es posible que tenga otros problemas.

@bostone ¿ tal vez te estás perdiendo estos pasos después de kubeadm init ?

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

También debe seguir el paso 3 que se describe aquí . Eso parece estar relacionado con el error de configuración cni que está recibiendo.

También mirando al cliente API creado [apiclient], esperando que el plano de control esté listo durante 10 minutos ya con Ubuntu 16.04 y una nueva instalación de 1.6.1

@pingthings Recomiendo unirse a Slack Kubernetes y al canal kubeadm . Podemos ayudarlo a depurar allí.

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 de 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.

Esto no parece resolverse (Ubuntu LTS, kubeadm 1.6.1).

Primero, también experimenté kubeadm colgando de "Cliente API creado, esperando que el plano de control esté listo" cuando usé la bandera --apiserver-advertise-address .. Los registros del diario dicen:

let.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Apr 04 12:27:04 xxx kubelet[57592]: E0404 12:27:04.352780   57592 eviction_manager.go:214] eviction manager: unexpected err: failed GetNode: node 'xxx' not found
Apr 04 12:27:05 xxx kubelet[57592]: E0404 12:27:05.326799   57592 kubelet_node_status.go:101] Unable to register node "xxx" with API server: Post https://x.x.x.x:6443/api/v1/nodes: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.745674   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.746759   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://x.x.x.x:6443/api/v1/nodes?fieldSelector=metadata.name%3Dxxx&resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeout
Apr 04 12:27:06 xxx kubelet[57592]: E0404 12:27:06.747749   57592 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://x.x.x.x:6443/api/v1/services?resourceVersion=0: dial tcp x.x.x.x:6443: i/o timeou

Si no proporciono esta bandera, kubeadm pasa, pero incluso entonces obtengo el siguiente error para el inicio de kubelet:

Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Kubelet se niega a iniciarse correctamente y no puedo conectarme al clúster con kubectl de ninguna manera

Parece que las versiones 1.5.x de kubeadm se han eliminado no solo del repositorio de centos, sino también de Ubuntu LTS: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages It dificulta la degradación y, de hecho, rompe la compatibilidad con versiones anteriores

@bostone

¿Descubriste el bloqueo de "esperar a que el avión de control esté listo"? Veo lo mismo después de probar todos los cambios con 1.6.1.

@gtirloni @srzjulio agregar estos pasos después de kubeadm init no ayudó. Hizo que el servicio de kubelet cambiara de failed a active (running) pero todavía tengo el mensaje The connection to the server localhost:8080 was refused - did you specify the right host or port? . Y si miro a los servicios que escuchan, no puedo ver el 8080 en ninguna parte. Lo que puedo ver es que kubelet está escuchando en estos puertos:

kubelet    6397  root   12u  IPv6 611842      0t0  TCP *:4194 (LISTEN)
kubelet    6397  root   15u  IPv4 611175      0t0  TCP sdl02269.labs.teradata.com:49597->sdl02269.labs.teradata.com:sun-sr-https (ESTABLISHED)
kubelet    6397  root   16u  IPv4 611890      0t0  TCP localhost:10248 (LISTEN)
kubelet    6397  root   18u  IPv6 611893      0t0  TCP *:10250 (LISTEN)
kubelet    6397  root   19u  IPv6 611895      0t0  TCP *:10255 (LISTEN)

Entonces, ¿hay algún ajuste incorrecto (¿cambiado?) Que apunta erróneamente a 8080.

@bostone no es el puerto kubelet que necesita, es kube-apiserver, debería estar escuchando en el puerto 6443.

@sbezverk No modifiqué ningún valor predeterminado en cuanto a puertos (no está en ninguna instrucción) ¿Qué debo hacer para cambiar de 8080 a 6443?

@bostone si no modificó nada en el manifiesto de apiserver, por defecto escuchará en el puerto 6443. Solo necesita copiar /etc/kubernetes/admin.conf en $ HOME / .kube / config, cambiar los permisos en el archivo de configuración y debería estar listo.

@sbezverk Por cierto: estoy ejecutando todos los pasos de instalación como root, pero estas 3 líneas de instrucciones de la salida kubeadm init sugieren usar el usuario sudo. ¿Cuál es la recomendación al respecto? ¿Debería ejecutar todos los pasos de instalación como sudo también?

Ok, hice todos los pasos desde cero y parece estar mejor. Estos son los pasos que me han funcionado hasta ahora y me estoy ejecutando como root en CentOS 7.

# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/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
# setenforce 0
# yum install -y docker kubelet kubeadm kubectl kubernetes-cni
# vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Agregue -cgroup-driver=systemd a 10-kubeadm.conf y ahorre

# systemctl enable docker && systemctl start docker
# systemctl enable kubelet && systemctl start kubelet
# sysctl -w net.bridge.bridge-nf-call-iptables=1
# systemctl stop firewalld; systemctl disable firewalld
# kubeadm init
# cp /etc/kubernetes/admin.conf $HOME/
# chown $(id -u):$(id -g) $HOME/admin.conf
# export KUBECONFIG=$HOME/admin.conf
# kubectl apply -f https://git.io/weave-kube

En este punto, puedo ejecutar kubectl get nodes y ver mi nodo maestro en la lista.
Repita todos los pasos para minion excepto kubeadm init y en su lugar ejecute kubeadm join --token a21234.c7abc2f82e2219fd 12.34.567.89:6443 como lo genera kubeadm init
Este paso se completa y puedo ver los nodos maestro y minion (s)

Y ahora, el problema:

# kubectl get nodes
NAME       STATUS     AGE       VERSION
abc02918   NotReady   42m       v1.6.1
abc04576   NotReady   29m       v1.6.1

# kubectl describe node abc02918
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  43m       43m     1   kubelet, sdl02918           Normal      Starting        Starting kubelet.
  43m       43m     1   kubelet, sdl02918           Warning     ImageGCFailed       unable to find data for container /
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientDisk   Node sdl02918 status is now: NodeHasSufficientDisk
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasSufficientMemory Node sdl02918 status is now: NodeHasSufficientMemory
  43m       43m     29  kubelet, sdl02918           Normal      NodeHasNoDiskPressure   Node sdl02918 status is now: NodeHasNoDiskPressure
  42m       42m     1   kube-proxy, sdl02918            Normal      Starting        Starting kube-proxy.

Entonces parece que los nodos nunca están listos. ¿Alguna sugerencia?

Me imagino que su tejido no se está desplegando correctamente porque está utilizando el
archivo yaml anterior a 1.6.

Prueba "kubectl apply -f https://git.io/weave-kube-1.6 "

El martes 4 de abril de 2017 a las 12:24 p.m., Bo Stone [email protected] escribió:

Ok, hice todos los pasos desde cero y parece estar mejor. Aquí están
los pasos que me han funcionado hasta ahora y me estoy ejecutando como root.

gato <

[kubernetes]
nombre = Kubernetes
baseurl = http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
habilitado = 1
gpgcheck = 1
repo_gpgcheck = 1
gpgkey = https://packages.cloud.google.com/yum/doc/yum-key.gpg http://yum.kubernetes.io/repos/kubernetes-el7-x86_64enabled=1gpgcheck=1repo_gpgcheck=1gpgkey=https:/ /packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

setenforce 0

yum install -y docker kubelet kubeadm kubectl kubernetes-cni

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

Agregue -cgroup-driver = systemd a 10-kubeadm.conf y guarde

systemctl enable docker && systemctl start docker

systemctl enable kubelet && systemctl start kubelet

sysctl -w net.bridge.bridge-nf-call-iptables = 1

systemctl detener firewalld; systemctl deshabilitar firewalld

kubeadm init

cp /etc/kubernetes/admin.conf $ INICIO /

chown $ (id -u): $ (id -g) $ HOME / admin.conf

exportar KUBECONFIG = $ HOME / admin.conf

kubectl aplicar -f https://git.io/weave-kube

En este punto puedo ejecutar kubectl get nodos y ver mi nodo maestro en el
lista.
Repita todos los pasos para minion excepto, por supuesto, ejecutando kubeadm join
--token a21234.c7abc2f82e2219fd 12.34.567.89:6443 generado por kubeadm
en eso
Este paso se completa y puedo ver los nodos maestro y minion (s)

Y ahora, el problema:

kubectl obtener nodos

NOMBRE ESTADO EDAD VERSIÓN
abc02918 NotReady 42m v1.6.1
abc04576 NotReady 29m v1.6.1

kubectl describe el nodo abc02918

Eventos:
Mensaje de motivo de tipo de ruta de subobjetos del recuento de lo último visto
--------- -------- ----- ---- ------------- -------- --- --- -------
43m 43m 1 kubelet, sdl02918 Arranque normal Arranque kubelet.
43m 43m 1 kubelet, sdl02918 Imagen de advertencia GCFailed no se pueden encontrar datos para el contenedor /
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientDisk El estado del nodo sdl02918 es ahora: NodeHasSufficientDisk
43m 43m 29 kubelet, sdl02918 Normal NodeHasSufficientMemory El estado del nodo sdl02918 es ahora: NodeHasSufficientMemory
43m 43m 29 kubelet, sdl02918 Normal NodeHasNoDiskPressure El estado sdl02918 es ahora: NodeHasNoDiskPressure
42m 42m 1 kube-proxy, sdl02918 Inicio normal Iniciando kube-proxy.

Entonces parece que los nodos nunca están listos. ¿Alguna sugerencia?

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291571437 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAeJQ6OFBV3s6OHmfOkUdwqQsJ1sjg23ks5rsnzMgaJpZM4MtMRe
.

Usando CentOS y la versión 1.6.1-1 de kubeadm, y siguiendo los pasos anteriores, obtengo un comportamiento ligeramente diferente: se informa que el clúster está listo, pero luego me quedo atascado en este mensaje:

[apiclient] Temporarily unable to list nodes (will retry)

En los registros, sin embargo, todavía tenemos el mismo error:

Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.491150  108575 pod_workers.go:182] Error syncing pod 2193220cb6f65d66c0d8762189232e64 ("kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"), skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 20s restarting failed container=kube-apiserver pod=kube-apiserver-csc-q-docker-1.colinx.com_kube-system(2193220cb6f65d66c0d8762189232e64)"
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: W0404 13:30:30.524051  108575 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Apr 04 13:30:30 csc-q-docker-1.colinx.com kubelet[108575]: E0404 13:30:30.524243  108575 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@sjenning ¡ Eso es! ¡Todavía necesito implementar algunas imágenes para ver si todo funciona, pero puedo ver todos los nodos con el estado Ready ! Gracias a todos, chicos (por ahora :)

@bostone Seguí la misma receta que

@dcowden Es lo que elija yum en mi sistema Docker version 1.12.6, build 96d83a5/1.12.6 . Además, lo que me ayudó fue reaprovisionar todas las máquinas virtuales que estaba usando en lugar de intentar solucionar mis instalaciones anteriores

@bostone gracias. Cambiaré a esa versión para ver si puedo obtener una configuración que funcione. en mi sistema, la última es una extraña versión 17.03.1.ce (evidentemente la última mejor)

No estoy seguro de si es útil en general, pero tengo un libro de jugadas ansible que
hace todos los pasos para CentOS 7

https://github.com/sjenning/kubeadm-playbook

YMMV, pero al menos documenta el proceso. También hago algunas cosas como
cambie la ventana acoplable para usar el registro de archivos json y el almacenamiento de superposición.

Podría ser útil como referencia incluso si en realidad no ejecuta el libro de jugadas.

El martes 4 de abril de 2017 a las 12:55 p.m., Dave Cowden [email protected]
escribió:

@bostone https://github.com/bostone gracias. bajaré a eso
versión para ver si puedo obtener una configuración que funcione. en mi sistema, el último es un
extraña versión 17.03.1.ce (evidentemente la última mejor)

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/43815#issuecomment-291580822 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAeJQ7CUA4vxhF3T7nMc9wRu47rbWe-Kks5rsoQmgaJpZM4MtMRe
.

@sjenning ¡Gracias! eso es muy útil!

Ok, aquí hay una complicación. después de ejecutar kubeadm reset en master y minion y reiniciar los servicios de docker y kubelet kubeadm init cuelga en Created API client, waiting for the control plane to become ready una vez más. ¿Alguien puede proporcionar los pasos completos para restablecer kubeadm?
@sjenning, ¿ ha intentado volver a ejecutar su libro de jugadas después de ejecutarlo inicialmente?

@bostone en mi caso mover /var/lib/etcd/ hizo el truco.

@autostatic el directorio estaba vacío y cambiarle el nombre no ayudó. @sjenning, tu libro de jugadas se cuelga, creé un boleto para ti

¿Alguien ha intentado ejecutar el panel en v1.6.1? Recibo un error que indica lo siguiente:

Prohibido (403)

El usuario " system: serviceaccount : kube- system: default " no puede enumerar los espacios de nombres en el ámbito del clúster. (obtener espacios de nombres)
'

Supongo que necesito configurar más RBAC, como tienes que hacerlo para ejecutar Flannel.

@srzjulio ¿Puede presentar una nueva emisión por eso? Supongo que es algo en lo que SIG Auth y el equipo de Dashboard deberían trabajar juntos. Probablemente sea un cambio YAML simple.

@srzjulio , necesita actualizar las reglas de RBAC, las usamos para ponernos en marcha:

apiVersion: rbac.authorization.k8s.io/v1alpha1
tipo: ClusterRoleBinding
metadatos:
nombre: cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
tipo: ClusterRole
nombre: cluster-admin
asignaturas:

• tipo: Grupo
  nombre: sistema: maestros
• tipo: Grupo
  nombre: sistema: autenticado
• tipo: Grupo
  nombre: sistema: no autenticado

Tenga cuidado: el enlace que tiene @sbezverk es esencialmente desactivar RBAC. Tendrás un clúster súper inseguro si haces eso.

kind: Group
name: system:unauthenticated

Esto es particularmente malo. Significa que cualquier persona que pueda ponerse en contacto con su servidor API, incluso sin ninguna credencial, puede ejecutar comandos arbitrarios.

@jbeda coincide con el comportamiento que teníamos con 1.5.6

En realidad, hacer un sistema: un administrador de clúster

Si no desea autorización, use el autorizador AlwaysAllow

Si desea permitir todo mientras audita, use una combinación de RBAC, AlwaysAllow

Eso deshabilitará las solicitudes anónimas, registrará las denegaciones de RBAC en el registro del servidor API, pero continuará permitiendo que todas las solicitudes autenticadas hagan lo que quieran

Lo siento, y lo repito de nuevo, esto no tiene nada que ver con el problema original. Y aunque los problemas y cuestiones son válidos, deberíamos trasladar la conversación a otra parte.

Nuevamente, lo siento, presione enter demasiado pronto, pero tal como están las cosas:

1 - la versión 1.6.0 causa problemas
2 - no están todos arreglados
3 - mudarse a RBAC (bueno en mi opinión) pero es un problema, ¿por qué? ver punto 4
4 - Esto no se comunicó muy bien y no hay muchos documentos / blogs o lo que sea para explicarlo.
5 - Me inclino ante todas las personas que intentan salvar, pero necesitamos una mejor manera de hacer esto

https://kubernetes.io/docs/admin/authorization/rbac/#service -account-permissions es una buena guía para conocer las opciones más detalladas que tiene para abrir permisos.

agregar " --cgroup-driver = systemd " en kublet causa un nuevo problema en Centos / RHEL 7.3 (completamente actualizado, también conocido como docker 1.10.3):

Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542322    3026 docker_service.go:196] No cgroup driver is set in Docker
Apr 12 14:23:25 machine01 kubelet[3026]: W0412 14:23:25.542343    3026 docker_service.go:197] Falling back to use the default driver: "cgroupfs"
Apr 12 14:23:25 machine01 kubelet[3026]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"

mientras que podemos ver claramente que native.cgroupdriver = systemd está configurado en el demonio de la

 ps -ef|grep -i docker
root      4365     1  3 14:30 ?        00:00:33 /usr/bin/docker-current daemon --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --selinux-enabled --log-driver=journald --insecure-registry 172.30.0.0/16 --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/vg.docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true

@ReSearchITEng ¿por qué no actualiza la ventana acoplable a 1.12.6? Funciona a las mil maravillas con esta versión.

@sbezverk : ¡Acabo de actualizar a 1.12.5 y ahora está funcionando! ¡Muchas gracias!

Gracias a todos por la ayuda.
Finalmente trabajando completamente k8s 1.6.1 con franela. Todo está ahora en libros de jugadas ansible.
Probado en Centos / RHEL. También se iniciaron 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 !

@sjenning @ReSearchITEng
Hola, tengo un libro de jugadas vagabundo + ansible [0] muy similar al que ha creado, pero todavía no puedo hacerlo funcionar, aunque para mí está fallando en la configuración de la red. Lo he probado con percal, tejido y franela, y los tres fallan (aunque con diferentes síntomas).

Estoy ejecutando estas versiones:
[ vagrant @ master ~] $ docker --version
Docker versión 1.12.6, compilación 3a094bd / 1.12.6
[ vagrant @ master ~] $ kubelet --versión
Kubernetes v1.6.1
[ vagrant @ master ~] $ kubeadm versión
kubeadm version: version.Info {Major: "1", Minor: "6", GitVersion: "v1.6.1", GitCommit: "b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState: "clean", BuildDate: "2017-04-03T20 27Z ", GoVersion:" go1.7.5 ", Compilador:" gc ", Plataforma:" linux / amd64 "}

errores:

[vagrant<strong i="19">@master</strong> ~]$ kubectl get all --all-namespaces
NAMESPACE     NAME                                           READY     STATUS             RESTARTS   AGE
kube-system   po/calico-etcd-gvrhd                           1/1       Running            0          47m
kube-system   po/calico-node-7jvs8                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-7ljpn                           2/2       Running            0          47m
kube-system   po/calico-node-w15z3                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-node-zq3zx                           1/2       CrashLoopBackOff   12         45m
kube-system   po/calico-policy-controller-1777954159-13x01   1/1       Running            0          47m
kube-system   po/etcd-master                                 1/1       Running            0          46m
kube-system   po/kube-apiserver-master                       1/1       Running            0          46m
kube-system   po/kube-controller-manager-master              1/1       Running            0          46m
kube-system   po/kube-dns-3913472980-16m01                   3/3       Running            0          47m
kube-system   po/kube-proxy-70bmf                            1/1       Running            0          45m
kube-system   po/kube-proxy-9642h                            1/1       Running            0          45m
kube-system   po/kube-proxy-jhtvm                            1/1       Running            0          45m
kube-system   po/kube-proxy-nb7q5                            1/1       Running            0          47m
kube-system   po/kube-scheduler-master                       1/1       Running            0          46m

NAMESPACE     NAME              CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
default       svc/kubernetes    10.96.0.1       <none>        443/TCP         47m
kube-system   svc/calico-etcd   10.96.232.136   <none>        6666/TCP        47m
kube-system   svc/kube-dns      10.96.0.10      <none>        53/UDP,53/TCP   47m

NAMESPACE     NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   deploy/calico-policy-controller   1         1         1            1           47m
kube-system   deploy/kube-dns                   1         1         1            1           47m

NAMESPACE     NAME                                     DESIRED   CURRENT   READY     AGE
kube-system   rs/calico-policy-controller-1777954159   1         1         1         47m
kube-system   rs/kube-dns-3913472980                   1         1         1         47m

[vagrant<strong i="5">@master</strong> ~]$ kubectl -n kube-system describe po/calico-node-zq3zx
Name:       calico-node-zq3zx
Namespace:  kube-system
Node:       node1/192.168.10.101
Start Time: Wed, 26 Apr 2017 19:37:35 +0000
Labels:     k8s-app=calico-node
        pod-template-generation=1
Annotations:    kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"DaemonSet","namespace":"kube-system","name":"calico-node","uid":"844cd287-2ab7-11e7-b184-5254008815b6","ap...
        scheduler.alpha.kubernetes.io/critical-pod=
Status:     Running
IP:     192.168.10.101
Controllers:    DaemonSet/calico-node
Containers:
  calico-node:
    Container ID:   docker://ca00b0a73a073a2d2e39cb0cc315b8366eaa20e2e479002dd16134b0d1e94f0b
    Image:      quay.io/calico/node:v1.1.3
    Image ID:       docker-pullable://quay.io/calico/node<strong i="6">@sha256</strong>:8e62eee18612a6ac7bcae90afaba0ed95265baba7bf3c0ab632b7b40ddfaf603
    Port:       
    State:      Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Wed, 26 Apr 2017 20:21:09 +0000
    Ready:      False
    Restart Count:  12
    Requests:
      cpu:  250m
    Environment:
      ETCD_ENDPOINTS:               <set to the key 'etcd_endpoints' of config map 'calico-config'> Optional: false
      CALICO_NETWORKING_BACKEND:        <set to the key 'calico_backend' of config map 'calico-config'> Optional: false
      CALICO_DISABLE_FILE_LOGGING:      true
      FELIX_DEFAULTENDPOINTTOHOSTACTION:    ACCEPT
      CALICO_IPV4POOL_CIDR:         192.168.0.0/16
      CALICO_IPV4POOL_IPIP:         always
      FELIX_IPV6SUPPORT:            false
      FELIX_LOGSEVERITYSCREEN:          info
      IP:                   
    Mounts:
      /lib/modules from lib-modules (ro)
      /var/run/calico from var-run-calico (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
  install-cni:
    Container ID:   docker://442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
    Image:      quay.io/calico/cni:v1.7.0
    Image ID:       docker-pullable://quay.io/calico/cni<strong i="7">@sha256</strong>:3612ffb0bff609d65311b45f4bae57fa80a05d25e1580ceb83ba4162e2ceef9f
    Port:       
    Command:
      /install-cni.sh
    State:      Running
      Started:      Wed, 26 Apr 2017 19:38:29 +0000
    Ready:      True
    Restart Count:  0
    Environment:
      ETCD_ENDPOINTS:       <set to the key 'etcd_endpoints' of config map 'calico-config'>     Optional: false
      CNI_NETWORK_CONFIG:   <set to the key 'cni_network_config' of config map 'calico-config'> Optional: false
    Mounts:
      /host/etc/cni/net.d from cni-net-dir (rw)
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from calico-cni-plugin-token-5wnmg (ro)
Conditions:
  Type      Status
  Initialized   True 
  Ready     False 
  PodScheduled  True 
Volumes:
  lib-modules:
    Type:   HostPath (bare host directory volume)
    Path:   /lib/modules
  var-run-calico:
    Type:   HostPath (bare host directory volume)
    Path:   /var/run/calico
  cni-bin-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /opt/cni/bin
  cni-net-dir:
    Type:   HostPath (bare host directory volume)
    Path:   /etc/cni/net.d
  calico-cni-plugin-token-5wnmg:
    Type:   Secret (a volume populated by a Secret)
    SecretName: calico-cni-plugin-token-5wnmg
    Optional:   false
QoS Class:  Burstable
Node-Selectors: <none>
Tolerations:    CriticalAddonsOnly=:Exists
        node-role.kubernetes.io/master=:NoSchedule
        node.alpha.kubernetes.io/notReady=:Exists:NoExecute for 300s
        node.alpha.kubernetes.io/unreachable=:Exists:NoExecute for 300s
Events:
  FirstSeen LastSeen    Count   From        SubObjectPath           Type        Reason      Message
  --------- --------    -----   ----        -------------           --------    ------      -------
  46m       46m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulling     pulling image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Pulled      Successfully pulled image "quay.io/calico/node:v1.1.3"
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id e035a82202b2c8490e879cb9647773158ff05def6c60b31a001e23e6d288a977
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulling     pulling image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Pulled      Successfully pulled image "quay.io/calico/cni:v1.7.0"
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Created     Created container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  45m       45m     1   kubelet, node1  spec.containers{install-cni}    Normal      Started     Started container with id 442c3adfa908f76654bb54070ef5ff638e4b68e0331ea0555ae877ce583ce858
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Created     Created container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1  spec.containers{calico-node}    Normal      Started     Started container with id 163a9073070aa52ce7ee98c798ffe130a581e4fdbbc503540ed5d3b79651c549
  44m       44m     1   kubelet, node1                  Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 10s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  44m   44m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 07453d944dfb9a4ebae57c83158e4b51f8870bcab94b4f706239f6c0b93bb62d
  43m   43m 2   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  43m   43m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 00f363848c16ff66743d54b87948133a87a97bfd32fbde2338622904d0990601
  42m   42m 3   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   41m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id a5aad1f1a57a361fafcaa2ee6aba244bf19925f56c5b46771cfd45e5e7fd884e
  41m   40m 6   kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  40m   40m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 520ee97fe986fd726a0347cab6de5b2a8fba91f73df2d601e8b7625531ed2117
  39m   36m 12  kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  36m   36m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id 90be4da6fd2e8c111c3e2a91256d60656db80316c1497c29c4155b8f009f241f
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Created     Created container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  31m   31m 1   kubelet, node1  spec.containers{calico-node}    Normal  Started     Started container with id bf0d93f45d5ffa2d2c42487851f80048757da5c767491f673bfecfa37fe76e48
  44m   3m  12  kubelet, node1  spec.containers{calico-node}    Normal  Pulled      Container image "quay.io/calico/node:v1.1.3" already present on machine
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Started     (events with common reason combined)
  25m   3m  5   kubelet, node1  spec.containers{calico-node}    Normal  Created     (events with common reason combined)
  36m   15s 149 kubelet, node1                  Warning FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "calico-node" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=calico-node pod=calico-node-zq3zx_kube-system(c983e5d0-2ab7-11e7-b184-5254008815b6)"

  44m   15s 173 kubelet, node1  spec.containers{calico-node}    Warning BackOff Back-off restarting failed container

Esto parece información clave, pero no estoy seguro de cómo solucionarlo:

[vagrant<strong i="6">@master</strong> ~]$ kubectl -n kube-system logs calico-node-zq3zx calico-node
Skipping datastore connection test
time="2017-04-26T20:20:39Z" level=info msg="NODENAME environment not specified - check HOSTNAME" 
time="2017-04-26T20:20:39Z" level=info msg="Loading config from environment" 
ERROR: Unable to access datastore to query node configuration
Terminating
time="2017-04-26T20:21:09Z" level=info msg="Unhandled error: client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
time="2017-04-26T20:21:09Z" level=info msg="Unable to query node configuration" Name=node1 error="client: etcd cluster is unavailable or misconfigured; error #0: client: endpoint http://10.96.232.136:6666 exceeded header timeout
" 
Calico node failed to start

Cualquier ayuda será muy apreciada ...

[0] - https://github.com/thiagodasilva/kubernetes-swift/tree/master/roles

No pude identificar qué está mal en tu extremo.
Le sugiero que intente crear una instalación separada usando los libros de jugadas aquí: https://github.com/ReSearchITEng/kubeadm-playbook e intente ver cuál es la diferencia.
PD: mis últimas pruebas son con 1.6.2, tanto kube * como imágenes y parece estar bien.

@kelseyhightower

@ReSearchITEng lo siento, olvidé informar, pero finalmente lo hice funcionar, mis archivos vagrant + ansible están aquí: https://github.com/thiagodasilva/kubernetes-swift

También tuve el mismo problema, pero simplemente copié la configuración cni en el nodo maestro a la ubicación correspondiente del nodo trabajador, luego se volvió correcto.

systemctl status kubelet.service -l

● kubelet.service - kubelet: el agente de nodo de Kubernetes
Cargado: cargado (/etc/systemd/system/kubelet.service; habilitado; preajuste del proveedor: deshabilitado)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Activo: activo (en ejecución) desde Tue 2017-06-06 10:42:00 CST; Hace 18min
Documentos: http://kubernetes.io/docs/
PID principal: 4414 (kubelet)
Memoria: 43,0 M
CGroup: /system.slice/kubelet.service
├─4414 / usr / bin / kubelet --kubeconfig = / etc / kubernetes / kubelet.conf --require-kubeconfig = true --pod-manifest-path = / etc / kubernetes / manifests --network-plugin = cni - -cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin --cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorizatio -ca-file = / etc / kubernetes / pki / ca.crt --cgroup-driver = cgroupfs
└─4493 journalctl -k -f

06 de junio 10:59:46 contiv1.com kubelet [4414]: W0606 10: 59: 46.215827 4414 cni.go: 157] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
06 de junio 10:59:46 contiv1.com kubelet [4414]: E0606 10: 59: 46.215972 4414 kubelet.go: 2067] La ​​red en tiempo de ejecución del contenedor no está lista: NetworkReady = mensaje falso listo
06 de junio 10:59:51 contiv1.com kubelet [4414]: W0606 10: 59: 51.216843 4414 cni.go: 157] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
06 de junio 10:59:51 contiv1.com kubelet [4414]: E0606 10: 59: 51.216942 4414 kubelet.go: 2067] La ​​red en tiempo de ejecución del contenedor no está lista: NetworkReady = mensaje falso listo
06 de junio 10:59:56 contiv1.com kubelet [4414]: W0606 10: 59: 56.217923 4414 cni.go: 157] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
06 de junio 10:59:56 contiv1.com kubelet [4414]: E0606 10: 59: 56.218113 4414 kubelet.go: 2067] La ​​red en tiempo de ejecución del contenedor no está lista: NetworkReady = mensaje falso listo
06 de junio 11:00:01 contiv1.com kubelet [4414]: W0606 11: 00: 01.219251 4414 cni.go: 157] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
06 de junio 11:00:01 contiv1.com kubelet [4414]: E0606 11: 00: 01.219382 4414 kubelet.go: 2067] La ​​red de tiempo de ejecución del contenedor no está lista: NetworkReady = mensaje falso listo
06 de junio 11:00:06 contiv1.com kubelet [4414]: W0606 11: 00: 06.220396 4414 cni.go: 157] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
06 de junio 11:00:06 contiv1.com kubelet [4414]: E0606 11: 00: 06.220575 4414 kubelet.go: 2067] La ​​red en tiempo de ejecución del contenedor no está lista: NetworkReady = mensaje falso listo

El estado de todos los nodos:
[ root @ swarm net.d] # kubectl obtener nodo
NOMBRE ESTADO EDAD VERSIÓN
contiv1.com Listo 1h v1.6.4
contiv2.com Listo 1h v1.6.4
swarm.com Listo 1h v1.6.4

¿Alguna resolución sobre esto? No pude hacer esto incluso después de probar todas las resoluciones mencionadas.

Como soy nuevo en la configuración de Kubernetes, me siento superconfundido. Intenté seguir https://medium.com/@SystemMining/setup -kubenetes-cluster-on-ubuntu-16-04-with-kubeadm-336f4061d929 que usa weave-kube para la red, pero también estoy atascado con el mismo problema . ¿Alguna forma de resolver esto?
Ready False Mon, 12 Jun 2017 16:55:16 +0200 Mon, 12 Jun 2017 12:22:45 +0200 KubeletNotReady runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

¿Por qué sigue siendo un problema? Ubuntu 16.04 / CentOS 7.3 con las últimas actualizaciones utilizando los repositorios oficiales de k8s con 1.6.4 y siguiendo los pasos que se describen aquí: https://kubernetes.io/docs/setup/independent/install-kubeadm/
Jun 13 09:57:21 tme-lnx1-centos kubelet: W0613 09:57:21.871413 10321 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 13 09:57:21 tme-lnx1-centos kubelet: E0613 09:57:21.871788 10321 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

@drajen No, esto afectó solo a la v1.6.0_ . Se espera que kubelet no encuentre una red ya que no ha instalado ninguna. Por ejemplo, solo ejecuta

kubectl apply -f https://git.io/weave-kube-1.6

para instalar Weave Net y esos problemas desaparecerán. Puede optar por instalar Flannel, Calico, Canal o cualquier red CNI si lo desea

@luxas Sigo viendo referencias a esto, pero ¿cómo se supone que debo aplicar algo a un clúster que no se está ejecutando? No tengo nada con lo que conectarme.

@drajen Creo que el punto de @luxas es que este es el lugar equivocado para preguntar sobre la configuración.
Las diversas guías de configuración lo llevarán más allá de este punto: el paso típico que falta en las guías anteriores, que luxas menciona amablemente, en el sentido de que debe aplicar una configuración de red antes de que todo comience a funcionar correctamente.

Sí, puede que no sea obvio y lo sentimos, pero tampoco podemos tener un solo nombre de proveedor allí.

Charlé con @drajen en Slack y el problema estaba relacionado con cgroup, el kubelet no era saludable y no podía crear ningún Pod, de ahí el problema.

Gracias a @luxas por luchar contra mi problema particular hasta el suelo: https://github.com/kubernetes/kubeadm/issues/302

Aún presionando esto en Arch en 1.7, ¿hay una solución rápida en alguna parte?

Editar:

kubectl apply -f https://git.io/weave-kube-1.6

hizo el truco, parece que solo necesitábamos CNI funcionando

Al menos para CentOS / RHEL, asegúrese de actualizar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf y agregue la bandera --cgroup-driver = "systemd"

Si vuelve a instalar en la misma máquina, este es un restablecimiento completo y adecuado:
https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/reset.yml
(esto es necesario especialmente si usa flanneld)
Si desea hacer todo en uno, es posible que desee utilizar todo el proyecto: https://github.com/ReSearchITEng/kubeadm-playbook/

Encontré este problema, y ​​absolutamente nada de lo que leí arriba funcionó. Así que lo intenté de nuevo con una configuración mucho más controlada, cambiando de Ubuntu al último CoreOS, yendo a una versión anterior de k8s para empezar y, en general, siendo muy anal con todo lo que se instaló en cada VM. NO estoy usando kubeadm, sino una combinación de vagabundo y ansible.

(¿Por qué? Porque no tenía idea de lo que estaba pasando en kubeadm y pensé de esta manera que al menos tendría el control y sería capaz de eludir cualquier verificación previa al vuelo demasiado entusiasta, sin mencionar la sensación de que tenía más control de automatización en general, y también no tener que preocuparse por la advertencia de no aplicar software alfa en producción).

Cuando probé esta configuración con una edición anterior (1.4.3) de k8s, este enfoque fue excelente. Luego intenté actualizar a 1.71. Una vez más, TODAVÍA tengo el mismo problema a pesar de no usar kubeadm en absoluto.

He confirmado que estoy ejecutando calicó en cada uno de mis nodos, incluido el Maestro y los tres Trabajadores potenciales. TODOS mis nodos se informan como NotReady, por lo que no estoy realmente seguro de cómo podría aplicar el tejido (o cualquier otra cosa) para que funcione.

Todo esto parece una gallina / huevo ... no se puede asignar un pod porque la red está fallando, pero es necesario que se esté ejecutando una red para crear una red en /etc/cni/net.d para poder asignar los pods. Y nuevamente, todo esto funcionaba hace unas horas con k8s 1.4.3. ¡Estoy muy frustrado!

Agradecería cualquier información que alguien pudiera dar.

Notas a pie de página:

En el maestro: journalctl -r -u kubelet me da

24 de julio 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: E0724 00: 48: 16.592274 7647 kubelet.go: 2136] La red de tiempo de ejecución del contenedor no está lista: NetworkReady = razón falsa mensaje: docker : el complemento de red no es
24 de julio 00:48:16 rogue-kube-master-01 kubelet-wrapper [7647]: W0724 00: 48: 16.590588 7647 cni.go: 189] No se puede actualizar la configuración de cni: no se encontraron redes en / etc / cni / net .D

docker ps | grep calicó

(truncado para facilitar la lectura)
cde ... quay.io/calico/ leader-elector @ sha256 : ... "/run.sh --election = c" Hace 8 horas Hasta 8 horas
f72 ... calico / kube-policy-controller @ sha256 : ... "/ dist / controller" hace 8 horas Hasta 8 horas
c47 ... gcr.io/google_containers/pause-amd64:3.0 "/ pause" Hace 8 horas Hasta 8 horas

No hay /etc/cni/net.d

Desde mi caja de kubectl:
kubectl obtener nodos
10.0.0.111 NotReady, SchedulingDisabled 8h v1.7.1 + coreos.0
10.0.0.121 NotReady 8h v1.7.1 + coreos.0
10.0.0.122 NotReady 8h v1.7.1 + coreos.0
10.0.0.123 NotReady 8h v1.7.1 + coreos.0

kubectl aplicar -f https://git.io/weave-kube-1.6

NO arregló nada y, de hecho, solo parece crear más problemas.

bill @ rogue : ~ / vagrant_rogue / rogue-cluster $ kubectl apply -f https://git.io/weave-kube-1.6
cuenta de servicio "weave-net" creada
clusterrolebinding "weave-net" creado
Se creó el daemonset "weave-net"
Error del servidor (Prohibido): clusterroles.rbac.authorization.k8s.io "weave-net" está prohibido: intento de otorgar privilegios adicionales: [PolicyRule {Resources: ["pods"], APIGroups: [""], Verbos: ["get"]} PolicyRule {Recursos: ["pods"], APIGroups: [""], Verbos: ["list"]} PolicyRule {Recursos: ["pods"], APIGroups: [""], Verbos: ["watch"]} PolicyRule {Recursos: ["espacios de nombres"], APIGroups: [""], Verbos: ["get"]} PolicyRule {Recursos: ["espacios de nombres"], APIGroups: [""], Verbos: ["list"]} PolicyRule {Recursos: ["espacios de nombres"], APIGroups: [""], Verbos: ["watch"]} PolicyRule {Recursos: ["nodos"], APIGroups: [""], Verbos: ["get"]} PolicyRule {Recursos: ["nodos"], APIGroups: [""], Verbos: ["lista"]} PolicyRule {Recursos: ["nodos"], APIGroups: [""], Verbos: ["watch"]} PolicyRule {Recursos: ["networkpolicies"], APIGroups: ["extensions"], Verbos: ["get"]} PolicyRule {Recursos: ["networkpolicies"], APIGroups: ["extensions"], Verbos: ["list"]} PolicyRule {Recursos: ["networkpolicies"], APIGroups: ["extensions"], Verbos: ["watch"]}] user = & {kube-admin [system: a uthenticated] map []} ownerrules = [] ruleResolutionErrors = []

bill @ rogue : ~ / vagrant_rogue / rogue-cluster $ kubectl obtener pods --namespace = kube-system
NOMBRE ESTADO LISTO REINICIE EDAD
kube-apiserver-10.0.0.111 1/1 En ejecución 1 8h
kube-controller-manager-10.0.0.111 1/1 En ejecución 1 8h
kube-dns-v20-fcl01 0/3 Pendiente 0 8h
kube-proxy-10.0.0.111 1/1 En ejecución 1 8 h
kube-proxy-10.0.0.121 1/1 En ejecución 1 8 h
kube-proxy-10.0.0.122 1/1 En ejecución 1 8 h
kube-proxy-10.0.0.123 1/1 En ejecución 1 8 h
kube-planificador-10.0.0.111 1/1 En ejecución 1 8h
kubernetes-dashboard-v1.4.1-29zzk 0/1 Pendiente 0 8h
weave-net-2lplj 1/2 CrashLoopBackOff 3 3m
weave-net-2nbgd 1/2 CrashLoopBackOff 3 3m
weave-net-fdr1v 2/2 Corriendo 0 3m
weave-net-jzv50 1/2 CrashLoopBackOff 3 3m

Una investigación más profunda de los errores de tejido indica que o (a) no se pueden conectar al apiserver, o bien (b) en el caso del que está marcado como "En ejecución" se queja de que no se puede conectar a sí mismo.

@billmilligan Al tener problemas similares, el dns deja de funcionar pocos minutos después de que se inicia el contenedor

@Paxa @billmilligan Si desea obtener ayuda, no comente sobre este tema. En su lugar, abra nuevos en el repositorio de kubeadm con suficientes detalles solicitados.

@luxas Respetuosamente, tengo que preguntarme si este es un tema nuevo. Como obtengo exactamente el mismo resultado configurando k8s sin kubeadm que todos los demás obtienen con kubeadm, esto parece eliminar a kubeadm como la fuente del problema. ¿Quizás este tema debería cambiarse de nombre en consecuencia?

@billmilligan respetuosamente, dado que el problema es sobre kubeadm, y puedes reproducirlo sin kubeadm, ¿entonces es el lugar equivocado para archivarlo? Creo que este hilo resolvió el problema de kubeadm. Este es un tema nuevo. Creo que recibirá más atención como un tema nuevo. Como las personas en este hilo piensan que ya está resuelto y lo están ignorando.

Utilizo kubeadm y este problema lo afectó, y se ha resuelto desde 1.6.1. He implementado pérdidas de k8 desde entonces, así que realmente creo que tienes un problema aparte.

@ kfox1111 Gracias por los comentarios. Presentaré un nuevo problema, pero la cantidad de personas que todavía parecen enfrentarlo en otro lugar en 1.7.x todavía me hace preguntarme.

TL; DR;

El mensaje de error

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

NO es necesariamente malo.

Ese mensaje de error le dice que debe instalar un proveedor de implementación de especificaciones CNI de terceros .

¿Qué es CNI y cómo se integra con Kubernetes?

CNI significa Container Network Interface y define una especificación que usa kubelet para crear una red para el clúster. Consulte esta página para obtener más información sobre cómo Kubernetes usa la especificación CNI para crear una red para el clúster.

A Kubernetes no le importa cómo se crea la red siempre que cumpla con la especificación CNI.

kubelet está a cargo de conectar nuevos Pods a la red (puede ser una red superpuesta, por ejemplo).
kubelet lee un directorio de configuración (a menudo /etc/cni/net.d ) para que lo utilicen las redes CNI.
Cuando se crea un nuevo Pod, el kubelet lee los archivos en el directorio de configuración, exec sale al binario CNI especificado en el archivo de configuración (el binario suele estar en /opt/cni/bin ). El binario que se ejecutará pertenece y es instalado por un tercero (como Weave, Flannel, Calico, etc.).

kubeadm es una herramienta genérica para activar los clústeres de Kubernetes y no sabe qué solución de red desea y no favorece a nadie en específico. Después de que se ejecuta kubeadm init , no existe tal binario ni configuración CNI . Esto significa que kubeadm init NO ES SUFICIENTE para poner en funcionamiento un clúster en pleno funcionamiento.

Esto significa que después de kubeadm init , los registros de kubelet dirán

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

esto es muy esperado. Si este no fuera el caso, hubiéramos favorecido a un proveedor de red específico.

Entonces, ¿cómo "soluciono" este error?
El siguiente paso de la guía de introducción de kubeadm es "Instalar una red de Pod".
Esto significa, kubectl apply un manifiesto de su proveedor de red CNI preferido.

El DaemonSet copiará los binarios CNI necesarios en /opt/cni/bin y la configuración necesaria en /etc/cni/net.d/ . También ejecutará el demonio real que configura la red entre los nodos (escribiendo reglas de iptables, por ejemplo).

Una vez instalado el proveedor de CNI, el kubelet notará que "oh, tengo información sobre cómo configurar la red", y utilizará la configuración de terceros y los binarios.

Y cuando la red es configurada por un proveedor externo (invocándolo por kubelet), el nodo se marcará a sí mismo Ready .

¿Cómo se relaciona este problema con kubeadm?

Al final del ciclo v1.6, se fusionó un PR que cambió la forma en que kubelet informó el estado Ready/NotReady . En versiones anteriores, kubelet siempre había informado el estado de Ready , independientemente de si la red CNI estaba configurada o no. En realidad, esto estaba un poco mal y se cambió para respetar el estado de la red CNI. Es decir, NotReady cuando CNI no se inicializó y Ready cuando se inicializó.

kubeadm en v1.6.0 esperó incorrectamente a que el nodo maestro estuviera en el estado Ready antes de continuar con el resto de las tareas kubeadm init . Cuando el comportamiento de kubelet cambió para informar NotReady cuando CNI no se inicializó, kubeadm esperaría una eternidad a que el nodo obtuviera Ready .

ESE ESPERA MAL CONCEPCIÓN EN EL LADO KUBEADM ES DE LO QUE SE TRATA ESTE PROBLEMA

Sin embargo, arreglamos rápidamente la regresión en v1.6.1 y la lanzamos algunos días después de v1.6.0.

Lea la retrospectiva para obtener más información sobre esto y por qué la v1.6.0 podría lanzarse con este defecto.

Entonces, ¿qué debe hacer si cree que ve este problema en kubeadm v1.6.1 +?

Bueno, realmente creo que no. Este problema se trata de cuándo kubeadm init se interbloquea.
Ningún usuario o mantenedor ha visto eso en v1.6.1 +.

Sin embargo, lo que VERÁS es

runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

después de cada kubeadm init en todas las versiones anteriores a la v1.6, pero eso NO ES MALO

De todos modos, abra un nuevo problema si ve algo inesperado con kubeadm

Por favor, no comente más sobre este tema. En su lugar, abra uno nuevo.

@billmilligan Así que solo tienes que kubectl apply el manifiesto de un proveedor de CNI para que tu clúster esté en funcionamiento, creo

Estoy resumiendo prácticamente lo que se ha dicho anteriormente, pero espero que de una manera más clara y detallada.
Si tiene preguntas sobre cómo funciona CNI, consulte los canales de soporte normales como StackOverflow, un problema o Slack.

(Por último, lo siento por ese texto en negrita, pero sentí que era necesario para llamar la atención de la gente).