<p>kubeadm se queja de bridge-nf-call e ip_forward si no usa el tiempo de ejecución de Docker</p>

Creado en 16 ago. 2018 · 10Comentarios · Fuente: kubernetes/kubeadm

¿Es este un INFORME DE ERROR o una SOLICITUD DE FUNCIÓN? :

/ tipo error

Que paso :

Después de iniciar un sistema limpio, ejecutar kubeadm init con un tiempo de ejecución de CRI que no sea la ventana acoplable configurada produce el siguiente par de mensajes de error:

[ERROR FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables does not exist [ERROR FileContent--proc-sys-net-ipv4-ip_forward]: /proc/sys/net/ipv4/ip_forward contents are not set to 1

Qué esperabas que sucediera :

Esos dos controles previos al vuelo deben aprobarse porque podrían cumplirse automáticamente.

Obviamente, estos se manejan automáticamente al iniciar el demonio docker normalmente, pero para openSUSE Kubic estamos investigando el uso de CRI-O por defecto, donde no tenemos el lujo de un demonio dominante que se entrometa en tales cosas. .

Por lo tanto, este informe de error es una oportunidad para que kubeadm maneje las cosas por sí mismo. Creo que es posible que, debido a que kubeadm sabe lo que necesita, kubeadm debería modprobe br_netfilter y echo '1' > /proc/sys/net/ipv4/ip_forward automáticamente en lugar de quejarse de los problemas.

Alternativamente, si esta sugerencia no es aceptable, agradecería una sugerencia sobre cómo openSUSE Kubic debería abordar automáticamente estos problemas de una manera que se mantenga alineada con las expectativas generales de kubeadm.

Cómo reproducirlo (de la forma más mínima y precisa posible) :

Instalar kubeadm y cri-o
systemctl enable --now crio
Configure kubeadm para ejecutar kublet con argumentos adicionales --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15m
Ejecutar kubeadm init --cri-socket /var/run/crio/crio.sock

¿Algo más que necesitemos saber? :

Medio ambiente :

Versión de Kubernetes (use kubectl version ): v1.11.2
Proveedor de nube o configuración de hardware: qemu-kvm x86_64 16GB RAM 2 núcleos
SO (por ejemplo, de / etc / os-release): opensuse-tumbleweed-kubic
Kernel (por ejemplo, uname -a ): 4.17.13
Instalar herramientas: kubeadm

help wanted kinbug

Fuente

sysrich

👍6

Comentario más útil

Reiniciar Docker hizo el truco ... Gracias

itpings en 25 abr. 2019

👍10 ❤7 😕1

Todos 10 comentarios

No se siente como un error de producto, sino un error de documentación (solo falta un manual). Actualmente solo tenemos páginas sobre cómo instalar kubernetes con kubeadm con docker como tiempo de ejecución del contenedor, deberíamos tener otra para cri-o.

outcoldman en 3 sept. 2018

En mi opinión, kubeadm debería al menos hacer el modprobe en sí. Si es el caso de ip_forward también es discutible, ya que esa es la configuración del sistema y depende del administrador.

Vogtinator en 12 sept. 2018

@vrothberg , ¿qué piensas? ¿Deberían las 2 condiciones anteriores (modprobe y sysctl) ser rectificadas automáticamente por kubeadm, o cree que esto es algo mejor manejado en CRI-O?

Docker hace ambas cosas automáticamente

Y si crees que CRI-O no debería tener cuidado, ¿dónde crees que debería llevarse el truco sucio en openSUSE? en el paquete cri-o o en el paquete kubeadm? ;)

sysrich en 12 sept. 2018

Creo que eso es algo que debería hacer el paquete kubeadm. Después de eso, podemos
compruebe si eso es realmente un error o si se puede degradar a un registro de información.
Muchas cosas en K8 todavía se basan en cómo Docker hace las cosas, pero
no siempre son necesarios.

Estoy de vacaciones en este momento, pero revisaré los correos aquí y luego. Gracias
para el ping.

El miércoles 12 de septiembre de 2018 a las 10:30, Richard Brown [email protected]
escribió:

@vrothberg https://github.com/vrothberg - ¿qué opinas? Si el
las 2 condiciones anteriores (modprobe y sysctl) se rectificarán automáticamente mediante
kubeadm, ¿o cree que esto es algo que se maneja mejor en CRI-O?
Docker hace ambas cosas automáticamente
Y si cree que el CRI-O adecuado no debería tener cuidado, ¿dónde cree que
¿El truco sucio debería llevarse a cabo en openSUSE? en el paquete cri-o o en el
paquete kubeadm? ;)
-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

vrothberg en 12 sept. 2018

Este problema se manejará en openSUSE con los siguientes cambios: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes? Linkrev = base & rev = 9

Estoy planeando enviar algo similar en el paquete de rpm ascendente de inmediato

sysrich en 13 sept. 2018

Reiniciar Docker hizo el truco ... Gracias

itpings en 25 abr. 2019

👍10 ❤7 😕1

En segundo lugar, agrego esta información a la página de configuración. Estaba viendo este error y me causó al menos 20 minutos de dolor hasta que encontré este hilo. Gracias por compartir la solución.

adobo76 en 13 jun. 2019

asegúrese de seguir el procedimiento, entonces el error no ocurrirá
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

danielsand en 26 mar. 2020

simplemente modificar las cosas no garantiza que estén funcionando. Si reinicia, todo se rompe. Debería indicarle que se asegure de que estas cosas estén habilitadas de forma persistente. Lo que ocurre con las reglas sysctl, pero no con los módulos.

Cuando sigo las instrucciones en cosas como esta, no me gusta leer las cosas y trato de dar pasos adicionales basados en corazonadas. Si me dice que haga algo, lo hago. Si no es así, no lo hago. Espero a que las cosas se rompan y vuelvo a arreglarlas. De esta manera, tengo una mejor idea si el problema es una mala documentación en lugar de algo al azar que hice cuando las cosas se rompen.