<p>kubeadm жалуется на bridge-nf-call и ip_forward, если не использует среду выполнения докеров</p>

Созданный на 16 авг. 2018 · 10Комментарии · Источник: kubernetes/kubeadm

Это ОТЧЕТ ОБ ОШИБКЕ или ЗАПРОС О ФУНКЦИОНИРОВАНИИ? :

/ добрый баг

Что случилось :

После загрузки чистой системы запуск kubeadm init со средой выполнения CRI, отличной от настроенной docker, выдает следующую пару сообщений об ошибках:

[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

Что вы ожидали :

Эти две предполетные проверки нужно пройти, потому что они могут быть выполнены автоматически.

Очевидно, что они обычно обрабатываются автоматически при запуске демона docker , но для openSUSE Kubic мы исследуем использование CRI-O по умолчанию, где у нас нет роскоши властного демона, чтобы вмешиваться в такие вещи. .

Таким образом, этот отчет об ошибке - это либо возможность для kubeadm решить все самостоятельно. Я думаю, что есть случай, когда kubeadm знает, что ему нужно, kubeadm должен автоматически modprobe br_netfilter и echo '1' > /proc/sys/net/ipv4/ip_forward а не жаловаться на проблемы.

В качестве альтернативы, если это предложение неприемлемо, я был бы признателен за предложение о том, как openSUSE Kubic должен автоматически решать эти проблемы таким образом, чтобы оставаться в соответствии с общими ожиданиями kubeadm.

Как это воспроизвести (максимально минимально и точно) :

Установите kubeadm и cri-o
systemctl enable --now crio
Настройте kubeadm для запуска kublet с дополнительными аргументами --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15m
Выполнить kubeadm init --cri-socket /var/run/crio/crio.sock

Что еще нам нужно знать? :

Окружающая среда :

Версия Kubernetes (используйте kubectl version ): v1.11.2
Облачный провайдер или конфигурация оборудования: qemu-kvm x86_64 16GB RAM 2 ядра
ОС (например, из / etc / os-release): opensuse-tumbleweed-kubic
Ядро (например, uname -a ): 4.17.13
Инструменты установки: kubeadm

help wanted kinbug

Источник

sysrich

👍6

Самый полезный комментарий

Перезапуск Docker помог ... Спасибо

itpings 25 апр. 2019

👍10 ❤7 😕1

Все 10 Комментарий

Не похоже на ошибку продукта, но на ошибку в документации (просто отсутствует руководство). В настоящее время у нас есть только страницы о том, как установить kubernetes с помощью kubeadm с docker в качестве среды выполнения контейнера, у нас должна быть еще одна для cri-o.

outcoldman 3 сент. 2018

IMO kubeadm должен, по крайней мере, сделать сам modprobe. Вопрос о том, относится ли это к ip_forward также является спорным, поскольку это конфигурация системы и зависит от администратора.

Vogtinator 12 сент. 2018

@vrothberg - как ты думаешь? Должны ли kubeadm автоматически исправлять два вышеуказанных условия (modprobe и sysctl), или вы думаете, что это лучше обработать в CRI-O?

Docker делает и то, и другое автоматически

И если вы думаете, что CRI-O не должен заботиться о себе, то где, по вашему мнению, следует переносить грязный хак в openSUSE? в пакете cri-o или в пакете kubeadm? ;)

sysrich 12 сент. 2018

Я думаю, что это то, что должен делать пакет kubeadm. После этого мы можем
проверьте, действительно ли это ошибка, или ее можно перевести в информационный журнал.
Многие вещи в K8s по-прежнему построены вокруг того, как Docker делает что-то, но
они не всегда нужны.

Я сейчас в отпуске, но проверю почту то и дело. Спасибо
для пинга.

В среду, 12 сентября 2018 г., в 10:30, Ричард Браун [email protected]
написал:

@vrothberg https://github.com/vrothberg - как вы думаете? Если
выше 2 условий (modprobe и sysctl) исправляются автоматически с помощью
kubeadm, или как вы думаете, с этим лучше справиться в CRI-O?
Docker делает и то, и другое автоматически
И если вы думаете, что CRI-O не должен заботиться о себе, как вы думаете, где
грязный хакер должен быть в openSUSE? в упаковке Cri-o или в
пакет kubeadm? ;)
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

vrothberg 12 сент. 2018

Эта проблема будет решена в openSUSE со следующими изменениями: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes? Linkrev = base & rev = 9

Я планирую в кратчайшие сроки представить что-то подобное в пакете upstream rpm.

sysrich 13 сент. 2018

Перезапуск Docker помог ... Спасибо

itpings 25 апр. 2019

👍10 ❤7 😕1

Во-вторых, я добавляю эту информацию на страницу настройки. Я видел эту ошибку, и это вызывало у меня как минимум 20 минут боли, пока я не наткнулся на эту ветку. Спасибо, что поделились решением.

adobo76 13 июн. 2019

убедитесь, что вы следуете процедуре, тогда ошибки не возникает
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

danielsand 26 мар. 2020

простая модификация вещей не гарантирует, что они работают. При перезагрузке все ломается. Он должен сказать вам, что эти вещи включены постоянно. Это относится к правилам sysctl, но не к модулям.

Следуя указаниям в подобных вещах, я не люблю вдаваться в подробности и пытаться предпринять дополнительные шаги, основываясь на догадках. Если он говорит мне что-то сделать, я это делаю. Если этого не произойдет, я этого не сделаю. Я жду, когда что-то сломается, вернусь и починю их. Таким образом, у меня есть лучшее представление о том, является ли проблема плохой документацией, а не какой-то случайной вещью, которую я сделал, когда что-то сломалось.