<p>kubeadm se plaint de bridge-nf-call et ip_forward s'il n'utilise pas le runtime docker</p>

Créé le 16 août 2018 · 10Commentaires · Source: kubernetes/kubeadm

S'agit-il d'un rapport de bogue ou d'une demande de fonctionnalité? :

/ genre bug

Qu'est-il arrivé :

Après le démarrage d'un système propre, l'exécution de kubeadm init avec un runtime CRI autre que docker configuré produit la paire de messages d'erreur suivante:

[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

Ce à quoi vous vous attendiez :

Ces deux vérifications avant vol doivent réussir car elles pourraient être satisfaites automatiquement.

Évidemment, ceux-ci sont gérés automatiquement par le démarrage du démon docker normalement, mais pour openSUSE Kubic, nous étudions l'utilisation de CRI-O par défaut, où nous n'avons pas le luxe d'un démon autoritaire pour se mêler de telles choses .

Par conséquent, ce rapport de bogue est soit une opportunité pour kubeadm de gérer les choses lui-même. Je pense qu'il y a un cas à être que parce que kubeadm sait ce dont il a besoin, kubeadm devrait modprobe br_netfilter et echo '1' > /proc/sys/net/ipv4/ip_forward automatiquement plutôt que de se plaindre des problèmes.

Sinon, si cette suggestion n'est pas acceptable, j'apprécierais une suggestion sur la façon dont openSUSE Kubic devrait automatiquement résoudre ces problèmes d'une manière qui restera alignée avec les attentes générales de kubeadm.

Comment le reproduire (de la manière la plus minimale et la plus précise possible) :

Installez kubeadm et cri-o
systemctl enable - maintenant crio
Configurez kubeadm pour exécuter kublet avec des arguments supplémentaires --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15m
Exécutez kubeadm init --cri-socket /var/run/crio/crio.sock

Y a-t-il autre chose que nous devons savoir? :

Environnement :

Version Kubernetes (utilisez kubectl version ): v1.11.2
Fournisseur de cloud ou configuration matérielle: qemu-kvm x86_64 16 Go de RAM 2 cœurs
OS (par exemple à partir de / etc / os-release): opensuse-tumbleweed-kubic
Noyau (par exemple uname -a ): 4.17.13
Installer les outils: kubeadm

help wanted kinbug

Source

sysrich

👍6

Commentaire le plus utile

Le redémarrage de Docker a fait l'affaire ... Merci

itpings le 25 avr. 2019

👍10 ❤7 😕1

Tous les 10 commentaires

Cela ne ressemble pas à un bug de produit, mais à un bug de documentation (juste un manuel manquant) Actuellement, nous n'avons que des pages sur la façon d'installer kubernetes avec kubeadm avec docker comme runtime de conteneur, nous devrions en avoir une autre pour cri-o.

outcoldman le 3 sept. 2018

IMO kubeadm devrait au moins faire le modprobe lui-même. Que ce soit le cas pour ip_forward aussi est discutable car c'est la configuration du système et dépend de l'administrateur.

Vogtinator le 12 sept. 2018

@vrothberg - qu'en pensez-vous? Les 2 conditions ci-dessus (modprobe et sysctl) devraient-elles être rectifiées automatiquement par kubeadm, ou pensez-vous que c'est quelque chose de mieux géré dans CRI-O?

Docker fait les deux automatiquement

Et si vous pensez que CRI-O proprement dit ne devrait pas faire attention, où pensez-vous que le sale hack devrait être effectué dans openSUSE? dans le paquet cri-o ou dans le paquet kubeadm? ;)

sysrich le 12 sept. 2018

Je pense que c'est quelque chose que le package kubeadm devrait faire. Après cela, nous pouvons
vérifiez si c'est vraiment une erreur ou si elle peut être rétrogradée dans un journal d'informations.
Beaucoup de choses dans K8 sont toujours construites autour de la façon dont Docker fait les choses, mais
ils ne sont pas toujours nécessaires.

Je suis en vacances en ce moment mais je vérifierai mes mails ici et là. Merci
pour le ping.

Le mer.12 septembre 2018 à 10h30, Richard Brown [email protected]
a écrit:

@vrothberg https://github.com/vrothberg - qu'en pensez-vous? Devrait le
au-dessus de 2 conditions (modprobe et sysctl) être rectifiées automatiquement par
kubeadm, ou pensez-vous que c'est quelque chose de mieux géré dans CRI-O?
Docker fait les deux automatiquement
Et si vous pensez que le CRI-O proprement dit ne devrait pas faire attention, où pensez-vous que le
sale hack doit être effectué dans openSUSE? dans le package cri-o ou dans le
paquet kubeadm? ;)
-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

vrothberg le 12 sept. 2018

Ce problème sera traité dans openSUSE avec les modifications suivantes: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes? Linkrev = base & rev = 9

Je prévois de soumettre rapidement quelque chose de similaire dans l'emballage du rpm en amont

sysrich le 13 sept. 2018

Le redémarrage de Docker a fait l'affaire ... Merci

itpings le 25 avr. 2019

👍10 ❤7 😕1

J'ajoute ensuite ces informations à la page de configuration. Je voyais cette erreur et cela m'a causé au moins 20 minutes de douleur jusqu'à ce que je tombe sur ce fil. Merci d'avoir partagé la solution.

adobo76 le 13 juin 2019

assurez-vous que vous suivez la procédure, l'erreur ne se produit pas
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

danielsand le 26 mars 2020

simplement modifier les choses ne garantit pas qu'elles fonctionnent. Si vous redémarrez, tout se brise. Il devrait vous dire de vous assurer que ces choses sont activées de manière persistante. Ce qui est valable pour les règles sysctl, mais pas pour les modules.

En suivant les instructions sur des choses comme celle-ci, je n'aime pas lire dans les choses et essayer de prendre des mesures supplémentaires en fonction des intuitions. Si ça me dit de faire quelque chose, je le fais. Si ce n'est pas le cas, je ne le fais pas. J'attends que les choses se cassent et je reviens les réparer. De cette façon, j'ai une meilleure idée si c'est une mauvaise documentation qui est le problème au lieu d'une chose aléatoire que j'ai faite quand les choses cassent.