<p>kubeadm mengeluh tentang bridge-nf-call dan ip_forward jika tidak menggunakan runtime docker</p>

Dibuat pada 16 Agu 2018 · 10Komentar · Sumber: kubernetes/kubeadm

Apakah ini LAPORAN BUG atau PERMINTAAN FITUR? :

/ jenis bug

Apa yang terjadi :

Setelah mem-boot sistem yang bersih, menjalankan kubeadm init dengan runtime CRI selain dari docker yang dikonfigurasi menghasilkan pasangan pesan kesalahan berikut:

[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

Apa yang Anda harapkan terjadi :

Kedua pemeriksaan pra-penerbangan itu lulus karena mereka bisa dipenuhi secara otomatis.

Jelas, ini ditangani secara otomatis oleh permulaan daemon docker normal, tetapi untuk openSUSE Kubic kami menyelidiki menggunakan CRI-O secara default, di mana kami tidak memiliki kemewahan daemon yang sombong untuk ikut campur dengan hal-hal seperti itu .

Oleh karena itu, laporan bug ini merupakan kesempatan bagi kubeadm untuk menangani hal-hal itu sendiri. Saya pikir ada kasusnya karena kubeadm tahu apa yang dibutuhkannya, kubeadm harus modprobe br_netfilter dan echo '1' > /proc/sys/net/ipv4/ip_forward secara otomatis daripada mengeluh tentang masalah.

Sebagai alternatif, jika saran ini tidak dapat diterima, saya akan menghargai saran tentang bagaimana openSUSE Kubic secara otomatis menangani masalah ini dengan cara yang akan tetap selaras dengan harapan umum kubeadm.

Cara memperbanyaknya (seminimal dan setepat mungkin) :

Instal kubeadm dan cri-o
systemctl mengaktifkan --sekarang crio
Konfigurasikan kubeadm untuk menjalankan kublet dengan argumen tambahan --container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock --runtime-request-timeout=15m
Jalankan kubeadm init --cri-socket /var/run/crio/crio.sock

Ada hal lain yang perlu kami ketahui? :

Lingkungan :

Versi Kubernetes (gunakan kubectl version ): v1.11.2
Penyedia cloud atau konfigurasi hardware: qemu-kvm x86_64 16GB RAM 2 core
OS (misalnya dari / etc / os-release): opensuse-tumbleweed-kubic
Kernel (misalnya uname -a ): 4.17.13
Instal alat: kubeadm

help wanted kinbug

Sumber

sysrich

👍6

Komentar yang paling membantu

Memulai ulang Docker berhasil ... Terima kasih

itpings pada 25 Apr 2019

👍10 ❤7 😕1

Semua 10 komentar

Tidak terasa seperti bug produk, tetapi bug dokumentasi (hanya manual yang hilang). Saat ini kami hanya memiliki halaman tentang bagaimana menginstal kubernetes dengan kubeadm dengan buruh pelabuhan sebagai runtime kontainer, kita harus memiliki halaman lain untuk cri-o.

outcoldman pada 3 Sep 2018

IMO kubeadm setidaknya harus melakukan modprobe itu sendiri. Apakah itu kasus untuk ip_forward juga masih bisa diperdebatkan karena itu adalah konfigurasi sistem dan terserah admin.

Vogtinator pada 12 Sep 2018

@vrothberg - bagaimana menurut Anda? Haruskah 2 kondisi di atas (modprobe dan sysctl) diperbaiki secara otomatis oleh kubeadm, atau apakah menurut Anda ini sesuatu yang lebih baik ditangani di CRI-O?

Docker melakukan keduanya secara otomatis

Dan jika menurut Anda CRI-O seharusnya tidak berhati-hati, menurut Anda di mana peretasan kotor harus dilakukan di openSUSE? di paket cri-o atau di paket kubeadm? ;)

sysrich pada 12 Sep 2018

Saya pikir itu adalah sesuatu yang harus dilakukan oleh paket kubeadm. Setelah itu kita bisa
periksa apakah itu benar-benar kesalahan atau jika itu dapat diturunkan ke log info.
Banyak hal di K8 masih dibangun di sekitar bagaimana Docker melakukan sesuatu tetapi
mereka tidak selalu diperlukan.

Saya sedang berlibur saat ini tetapi akan memeriksa email di sini dan kemudian. Terima kasih
untuk ping.

Pada Rabu 12 Sep 2018 pukul 10:30, Richard Brown [email protected]
menulis:

@vrothberg https://github.com/vrothberg - bagaimana menurut Anda? Haruskah
di atas 2 kondisi (modprobe dan sysctl) akan diperbaiki secara otomatis oleh
kubeadm, atau menurut Anda ini sesuatu yang lebih baik ditangani di CRI-O?
Docker melakukan keduanya secara otomatis
Dan jika menurut Anda CRI-O seharusnya tidak berhati-hati, menurut Anda di mana
hack kotor harus dilakukan di openSUSE? dalam paket cri-o atau di
paket kubeadm? ;)
-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubeadm/issues/1062#issuecomment-420559942 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ALI4g1dRKf5vWXz_7H27VktuD8nP5tAsks5uaMYogaJpZM4V_W70
.

vrothberg pada 12 Sep 2018

Masalah ini akan ditangani di openSUSE dengan perubahan berikut: https://build.opensuse.org/package/rdiff/devel : kubic / kubernetes? Linkrev = base & rev = 9

Saya berencana mengirimkan sesuatu yang serupa di paket rpm hulu segera

sysrich pada 13 Sep 2018

Memulai ulang Docker berhasil ... Terima kasih

itpings pada 25 Apr 2019

👍10 ❤7 😕1

Kedua, saya menambahkan informasi ini ke halaman penyiapan. Saya melihat kesalahan ini dan itu menyebabkan saya sakit setidaknya 20 menit sampai saya menemukan utas ini. Terima kasih telah membagikan solusinya.

adobo76 pada 13 Jun 2019

pastikan bahwa Anda mengikuti prosedur maka kesalahan tidak terjadi
https://kubernetes.io/docs/setup/production-environment/container-runtimes/#cri -o

danielsand pada 26 Mar 2020

hanya memodifikasi hal-hal tidak memastikan semuanya berjalan. Jika Anda reboot maka semuanya rusak. Ini harus memberi tahu Anda untuk memastikan hal-hal ini diaktifkan secara terus-menerus. Yang berfungsi untuk aturan sysctl, tetapi tidak untuk modulnya.

Ketika mengikuti petunjuk tentang hal-hal seperti ini, saya tidak suka membaca dan mencoba mengambil langkah tambahan berdasarkan firasat. Jika ia menyuruh saya melakukan sesuatu, saya melakukannya. Jika tidak, saya tidak. Saya menunggu hal-hal rusak dan kembali dan memperbaikinya. Dengan cara ini saya memiliki ide yang lebih baik jika dokumentasi buruk yang menjadi masalah daripada beberapa hal acak yang saya lakukan ketika ada yang rusak.