<p>kubeadm reclama sobre bridge-nf-call e ip_forward se não estiver usando o docker runtime</p>

Criado em 16 ago. 2018 · 10Comentários · Fonte: kubernetes/kubeadm

Este é um RELATÓRIO DE BUGS ou PEDIDO DE RECURSO? :

/ tipo bug

O que aconteceu :

Depois de inicializar um sistema limpo, executar kubeadm init com um tempo de execução CRI diferente do docker configurado produz o seguinte par de mensagens de erro:

[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

O que você esperava que acontecesse :

Essas duas verificações pré-voo devem ser aprovadas porque podem ser satisfeitas automaticamente.

Obviamente, eles são tratados automaticamente ao iniciar o daemon docker normalmente, mas para o openSUSE Kubic estamos investigando o uso de CRI-O por padrão, onde não temos o luxo de um daemon autoritário para interferir em tais coisas .

Portanto, este relatório de bug é uma oportunidade para o kubeadm lidar com as coisas sozinho. Eu acho que há um caso em que, porque kubeadm sabe o que precisa, kubeadm deve modprobe br_netfilter e echo '1' > /proc/sys/net/ipv4/ip_forward automaticamente em vez de reclamar sobre os problemas.

Alternativamente, se esta sugestão não for aceitável, eu apreciaria uma sugestão de como o openSUSE Kubic deve resolver automaticamente esses problemas de uma forma que permanecerá alinhada com as expectativas gerais do kubeadm.

Como reproduzi-lo (o mais mínimo e precisamente possível) :

Instale o kubeadm e o cri-o
systemctl enable --now crio
Configure o kubeadm para executar o kublet com argumentos adicionais --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15m
Execute kubeadm init --cri-socket /var/run/crio/crio.sock

Mais alguma coisa que precisamos saber? :

Meio Ambiente :

Versão do Kubernetes (use kubectl version ): v1.11.2
Provedor de nuvem ou configuração de hardware: qemu-kvm x86_64 16 GB RAM 2 núcleos
SO (por exemplo, de / etc / os-release): opensuse-tumbleweed-kubic
Kernel (por exemplo, uname -a ): 4.17.13
Ferramentas de instalação: kubeadm

help wanted kinbug

Fonte

sysrich

👍6

Comentários muito úteis

Reiniciar o Docker resolveu ... Obrigado

itpings em 25 abr. 2019

👍10 ❤7 😕1

Todos 10 comentários

Não parece um bug do produto, mas sim da documentação (apenas um manual faltando). Atualmente, temos apenas páginas sobre como instalar kubernetes com kubeadm com docker como o tempo de execução do contêiner, devemos ter outro para cri-o.

outcoldman em 3 set. 2018

IMO kubeadm deve pelo menos fazer o modprobe em si. Se é o caso de ip_forward também é discutível, pois é a configuração do sistema e cabe ao administrador.

Vogtinator em 12 set. 2018

@vrothberg - o que você acha? As 2 condições acima (modprobe e sysctl) devem ser retificadas automaticamente pelo kubeadm ou você acha que isso é algo melhor tratado no CRI-O?

O Docker faz as duas coisas automagicamente

E se você acha que o CRI-O apropriado não deve ser levado em consideração, para onde você acha que o hack sujo deve ser levado no openSUSE? no pacote cri-o ou no pacote kubeadm? ;)

sysrich em 12 set. 2018

Acho que é algo que o pacote kubeadm deve fazer. Depois disso, podemos
verifique se isso é realmente um erro ou se pode ser rebaixado a um log de informações.
Muitas coisas no K8s ainda são construídas em torno de como o Docker faz as coisas, mas
eles nem sempre são necessários.

Estou de férias no momento, mas verificarei e-mails aqui e então. Obrigado
para o ping.

Na quarta-feira, 12 de setembro de 2018 às 10:30, Richard Brown [email protected]
escrevi:

@vrothberg https://github.com/vrothberg - o que você acha? Deve o
acima de 2 condições (modprobe e sysctl) sejam retificadas automaticamente por
kubeadm, ou você acha que isso é algo melhor tratado no CRI-O?
O Docker faz as duas coisas automagicamente
E se você acha que o CRI-O adequado não deve tomar cuidado, onde você acha que o
hack sujo deve ser realizado no openSUSE? no pacote cri-o ou no
pacote kubeadm? ;)
-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

vrothberg em 12 set. 2018

Este problema será tratado no openSUSE com as seguintes alterações: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes? Linkrev = base & rev = 9

Estou planejando enviar algo semelhante no pacote rpm upstream imediatamente

sysrich em 13 set. 2018

Reiniciar o Docker resolveu ... Obrigado

itpings em 25 abr. 2019

👍10 ❤7 😕1

Em segundo lugar, adicionando essas informações à página de configuração. Eu estava vendo esse erro e isso me causou pelo menos 20 minutos de dor até que encontrei este tópico. Obrigado por compartilhar a solução.

adobo76 em 13 jun. 2019

certifique-se de seguir o procedimento, então o erro não ocorrerá
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

danielsand em 26 mar. 2020

simplesmente modificar as coisas não garante que elas estejam funcionando. Se você reiniciar, tudo será interrompido. Ele deve dizer a você para ter certeza de que essas coisas estão ativadas de forma persistente. O que serve para as regras do sysctl, mas não para os módulos.

Ao seguir as instruções sobre coisas como essas, não gosto de ler as coisas e tento dar passos extras com base em palpites. Se me diz para fazer algo, eu faço. Se não, eu não quero. Eu espero que as coisas quebrem e volto para consertá-las. Dessa forma, tenho uma ideia melhor se o problema é uma documentação ruim, em vez de alguma coisa aleatória que fiz quando as coisas quebraram.