Kubeadm: menambahkan dukungan untuk OpenRC sebagai sistem init

Harap perbaiki dulu peringatan yang diberikan kubeadm kepada Anda. Misalnya, mulailah dengan menentukan nilai yang tepat untuk variabel lingkungan NO_PROXY, kemudian pastikan bahwa semua binari yang diperlukan ada di sistem (tc, ebtables, ...) dan kemudian periksa apa yang ada di status dan log kubelet.

/menetapkan

Dengan semua peringatan selain tidak memiliki sistem init yang didukung terdeteksi. Masih memiliki masalah yang sama.

kubeadm init
I1204 10: 42: 06.894219 7292 version.go: 236] versi jarak jauh jauh lebih baru: v1.13.0; jatuh kembali ke: stable-1.12
[init] menggunakan versi Kubernetes: v1.12.3
[preflight] menjalankan pemeriksaan pra-penerbangan
[PERINGATAN Firewalld]: tidak ada sistem init yang didukung yang terdeteksi, melewati pemeriksaan layanan
[PERINGATAN Service-Docker]: tidak ada sistem init yang didukung yang terdeteksi, melewatkan pemeriksaan layanan
[PERINGATAN Service-Kubelet]: tidak ada sistem init yang didukung terdeteksi, melewatkan pemeriksaan layanan
[preflight / images] Menarik gambar yang diperlukan untuk menyiapkan cluster Kubernetes
[preflight / images] Ini mungkin memakan waktu satu atau dua menit, tergantung pada kecepatan koneksi internet Anda
[preflight / images] Anda juga dapat melakukan tindakan ini sebelumnya menggunakan 'kubeadm config images pull'
[preflight] tidak ada sistem init yang didukung terdeteksi, tidak akan memastikan kubelet tidak berjalan untuk waktu yang singkat saat mengatur konfigurasi untuk itu.
[kubelet] Menulis file lingkungan kubelet dengan flag ke file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Menulis konfigurasi kubelet ke file "/var/lib/kubelet/config.yaml"
[preflight] tidak ada sistem init yang didukung terdeteksi, tidak akan memastikan kubelet berjalan dengan baik.
[sertifikat] Menggunakan sertifikat dan kunci etcd / server yang ada.
[sertifikat] Menggunakan sertifikat dan kunci apiserver-etcd-client yang ada.
[sertifikat] Menggunakan sertifikat dan kunci etcd / peer yang ada.
[sertifikat] Menggunakan sertifikat dan kunci etcd / healthcheck-client yang ada.
[sertifikat] Menggunakan sertifikat dan kunci apiserver yang ada.
[sertifikat] Menggunakan sertifikat dan kunci apiserver-kubelet-client yang ada.
[sertifikat] Menggunakan sertifikat dan kunci klien-proxy-depan yang ada.
[sertifikat] sertifikat dan kunci yang valid sekarang ada di "/ etc / kubernetes / pki"
[sertifikat] Menggunakan kunci sa yang ada.
[kubeconfig] Menggunakan file KubeConfig terbaru yang sudah ada: "/etc/kubernetes/admin.conf"
[kubeconfig] Menggunakan file KubeConfig terbaru yang sudah ada: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Menggunakan file KubeConfig terbaru yang sudah ada: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Menggunakan file KubeConfig terbaru yang sudah ada: "/etc/kubernetes/scheduler.conf"
[controlplane] menulis manifes Pod Statis untuk komponen kube-apiserver ke "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] menulis manifes Pod Statis untuk komponen kube-controller-manager ke "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] menulis manifes Pod Statis untuk komponen kube-scheduler ke "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Menulis manifes Pod Statis untuk instance etcd lokal menjadi "/etc/kubernetes/manifests/etcd.yaml"
[init] menunggu kubelet untuk melakukan booting pada bidang kontrol sebagai Pod Statis dari direktori "/ etc / kubernetes / manifests"
[init] ini mungkin memakan waktu satu menit atau lebih jika gambar bidang kontrol harus ditarik
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Panggilan HTTP sama dengan 'curl -sSL http: // localhost : 10248 / healthz' gagal dengan kesalahan: Dapatkan http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : koneksi ditolak.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Panggilan HTTP sama dengan 'curl -sSL http: // localhost : 10248 / healthz' gagal dengan kesalahan: Dapatkan http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : koneksi ditolak.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Panggilan HTTP sama dengan 'curl -sSL http: // localhost : 10248 / healthz' gagal dengan kesalahan: Dapatkan http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : koneksi ditolak.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Panggilan HTTP sama dengan 'curl -sSL http: // localhost : 10248 / healthz' gagal dengan kesalahan: Dapatkan http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : koneksi ditolak.
[kubelet-check] Sepertinya kubelet tidak berjalan atau tidak sehat.
[kubelet-check] Panggilan HTTP sama dengan 'curl -sSL http: // localhost : 10248 / healthz' gagal dengan kesalahan: Dapatkan http: // localhost : 10248 / healthz: dial tcp [:: 1]: 10248: connect : koneksi ditolak.

Sayangnya, telah terjadi kesalahan:
waktu tunggu kondisi habis

Kesalahan ini mungkin disebabkan oleh:
- Kubelet tidak bekerja
- Kubelet tidak sehat karena kesalahan konfigurasi node dalam beberapa hal (cgroup yang diperlukan dinonaktifkan)

Jika Anda menggunakan sistem yang didukung systemd, Anda dapat mencoba memecahkan masalah kesalahan dengan perintah berikut:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Selain itu, komponen bidang kontrol mungkin macet atau keluar saat dimulai oleh runtime kontainer.
Untuk memecahkan masalah, daftarkan semua kontainer menggunakan CLI waktu proses kontainer pilihan Anda, misalnya buruh pelabuhan.
Berikut adalah salah satu contoh bagaimana Anda dapat membuat daftar semua kontainer Kubernetes yang berjalan di buruh pelabuhan:
- 'buruh pelabuhan ps -a | grep kube | grep -v pause '
Setelah Anda menemukan penampung yang gagal, Anda dapat memeriksa lognya dengan:
- 'log buruh pelabuhan CONTAINERID'
tidak dapat menginisialisasi cluster Kubernetes

Juga tidak mendukung sistem init (openrc) sepenuhnya dapat dimengerti, mungkin peningkatan di sini hanyalah beberapa dokumentasi dari sistem init yang didukung (atau hanya mengatakan bahwa itu hanya mendukung systemd jika itu masalahnya)

Bisakah Anda membagikan apa yang ada di log untuk kubelet dan di kontainer buruh pelabuhan (jika ada yang berjalan setelah pesan kesalahan kubeadm)

Hai kad, sejauh yang saya tahu tidak ada proses kubelet yang berjalan, dan tidak ada wadah yang pernah dimulai.

Saya tahu sedikit tentang internal kubeadms, tetapi tampaknya ia ingin mengkonfigurasi layanan di awal (misalnya systemd), tidak dapat menemukan sistem init yang didukung, jadi lewati saja, tetapi kemudian menunggu sistem init tersebut untuk memulai kubelet.

ps
PID PERINTAH WAKTU PENGGUNA
1 root 0:00 / sbin / init
2 akar 0:00 [kthreadd]
4 akar 0:00 [kworker / 0: 0H]
5 akar 0:00 [kworker / u64: 0]
6 akar 0:00 [mm_percpu_wq]
7 akar 0:00 [ksoftirqd / 0]
8 akar 0:00 [rcu_sched]
9 akar 0:00 [rcu_bh]
10 root 0:00 [migrasi / 0]
11 akar 0:00 [pengawas / 0]
12 akar 0:00 [cpuhp / 0]
13 akar 0:00 [kdevtmpfs]
14 akar 0:00 [bersih]
16 akar 0:00 [oom_reaper]
174 root 0:00 [writeback]
175 akar 0:00 [kworker / 0: 1]
176 akar 0:00 [kcompactd0]
178 akar 0:00 [ksmd]
179 akar 0:00 [crypto]
180 akar 0:00 [kintegrityd]
182 akar 0:00 [kblockd]
445 akar 0:00 [ata_sff]
454 akar 0:00 [md]
460 akar 0:00 [watchdogd]
585 akar 0:00 [kauditd]
591 akar 0:00 [kswapd0]
679 akar 0:00 [kthrotld]
911 akar 0:00 [hv_vmbus_con]
1182 akar 0:00 [scsi_eh_0]
1255 akar 0:00 [scsi_tmf_0]
1264 akar 0:00 [kworker / u64: 3]
1406 akar 0:00 [jbd2 / sda3-8]
1407 root 0:00 [ext4-rsv-conver]
1821 root 0:00 [hv_balloon]
1874 akar 0:00 [ipv6_addrconf]
1965 akar 0:00 [kworker / 0: 1H]
2235 root 0:00 / sbin / syslogd -Z
2289 root 0:00 / sbin / acpid
2318 kroni 0:00 / usr / sbin / chronyd -f /etc/chrony/chrony.conf
2345 root 0:00 / usr / sbin / crond -c / etc / crontabs
2447 root 0:06 / usr / bin / dockerd -p /run/docker.pid
2480 root 0:00 / usr / sbin / sshd
2485 root 0:00 / sbin / getty 38400 tty1
2486 root 0:00 / sbin / getty 38400 tty2
2489 root 0:00 / sbin / getty 38400 tty3
2491 root 0:00 / sbin / getty 38400 tty4
2495 root 0:00 / sbin / getty 38400 tty5
2498 root 0:00 / sbin / getty 38400 tty6
2507 root 0:00 sshd: root @ pts / 0
2509 root 0:00 -ash
2514 root 0:00 docker-containerd --config /var/run/docker/containerd/containerd.toml
2964 akar 0:00 [kworker / 0: 0]
3064 root 0:00 sshd: root @ pts / 1
3066 root 0:00 -ash
3241 akar 0:00 [kworker / u64: 1]
3311 akar 0:00 [kworker / 0: 2]
3314 root 0:00 / sbin / getty -L 115200 ttyS0 vt100
3315 root 0:00 ps

buruh pelabuhan ps -a
PERINTAH GAMBAR ID KONTAINER NAMA PELABUHAN STATUS YANG DIBUAT

hanya mendukung systemd dan wininit init system. Anda dapat menginstal kubelet secara manual dan menghapus kode yang menginstal file konfigurasi kubelet di kubeadm, mybe berfungsi

apakah alpine linux target bagi kami?
kami mungkin mengandalkan komunitas untuk menambalnya.

apakah alpine linux target bagi kami?
kami mungkin mengandalkan komunitas untuk menambalnya.

Alpine Linux adalah target yang sangat populer untuk kontainer - karena ukurannya yang sangat kecil / instal - juga cukup populer untuk Vagrant / EC2 - Saya terkejut itu tidak didukung. Grep melalui kode kubedm - sepertinya itu hanya mengotak-atik systemd untuk memulai hal-hal docker / kubernetes.

Apakah ada dokumen yang menjelaskan apa yang dilakukan / akan dilakukan / bergantung pada kubeadm dari sistem init?

Apakah ada dokumen yang menjelaskan apa yang dilakukan / ingin dilakukan / bergantung pada kubeadm dari sistem init

di Linux menggunakan systemd untuk memulai / menghentikan kubelet:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/kubelet.go

dokumen ini menguraikan sebagian interaksi kubeadm / systemd:
https://kubernetes.io/docs/setup/independent/kubelet-integration/#configure -kubelet-using-kubeadm

https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System

Alpine Linux menggunakan OpenRC untuk sistem initnya.

sistem init ini tidak didukung oleh kubernetes inti.
dalam hal ini kubeadm menggunakan apa yang tersedia di inti.

[PERINGATAN Service-Docker]: tidak ada sistem init yang didukung yang terdeteksi, melewatkan pemeriksaan layanan
[PERINGATAN Service-Kubelet]: tidak ada sistem init yang didukung terdeteksi, melewatkan pemeriksaan layanan

ini berasal dari sini:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
dan sistem init baru harus ditambahkan di sana.

/ tetapkan @timothysc @detiber
untuk penilaian yang satu ini.

Apakah seseorang sudah mengemas binari yang diperlukan (dan skrip init yang diperlukan) untuk Alpine? Jika demikian, saya tidak melihat masalah dengan menambahkan dukungan yang tepat untuk mengelola layanan dengan benar. Jika tidak, maka saya akan menganggap bahwa prasyarat untuk melanjutkan ini, karena pengelolaan skrip / konfigurasi init bukanlah tanggung jawab kubeadm.

Sepertinya ada satu paket kubernetes di sini .

@rosti Melihat isi dari paket itu pada dasarnya terlihat seperti dump dari beberapa binari k8s dan tidak menyertakan skrip atau konfigurasi init yang diperlukan untuk dijalankan oleh kubeadm.

Aku biasanya pengintai. Tetapi ada minat industri pada Kubernetes on the Edge menggunakan ARM dan berbagai opsi bare metal sedang diselidiki dengan Alpine menjadi campuran pilihan OS.

Saya pikir dukungan OpenRC di kubeadm adalah jenis yang harus dimiliki, saya tidak yakin komunitas Alpine akan mengajukan tambalan yang 'memperbaiki' sesuatu yang sangat mendasar untuk klaim ketenaran OS.

Aku biasanya pengintai. Tetapi ada minat industri pada Kubernetes on the Edge menggunakan ARM dan berbagai opsi bare metal sedang diselidiki dengan Alpine menjadi campuran pilihan OS.

Saya pikir dukungan OpenRC di kubeadm adalah jenis yang harus dimiliki, saya tidak yakin komunitas Alpine akan mengajukan tambalan yang 'memperbaiki' sesuatu yang sangat mendasar untuk klaim ketenaran OS.

Saya sangat curiga Anda benar - dengan ukuran memori / gambar yang mereka targetkan - saya benar-benar tidak dapat melihat mereka pergi ke rute systemd (tidak ada rasa tidak hormat).

Apakah ada dokumen yang menjelaskan apa yang dilakukan / ingin dilakukan / bergantung pada kubeadm dari sistem init

di Linux menggunakan systemd untuk memulai / menghentikan kubelet:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/kubelet.go

dokumen ini menguraikan sebagian interaksi kubeadm / systemd:
https://kubernetes.io/docs/setup/independent/kubelet-integration/#configure -kubelet-using-kubeadm

https://wiki.alpinelinux.org/wiki/Alpine_Linux_Init_System

Alpine Linux menggunakan OpenRC untuk sistem initnya.

sistem init ini tidak didukung oleh kubernetes inti.
dalam hal ini kubeadm menggunakan apa yang tersedia di inti.

[PERINGATAN Service-Docker]: tidak ada sistem init yang didukung yang terdeteksi, melewatkan pemeriksaan layanan
[PERINGATAN Service-Kubelet]: tidak ada sistem init yang didukung terdeteksi, melewatkan pemeriksaan layanan

ini berasal dari sini:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
dan sistem init baru harus ditambahkan di sana.

Sekilas, ini sebenarnya terlihat cukup lurus ke depan. Saya bukan Go-afficionado dengan cara apa pun, tetapi tampaknya hanya melakukan panggilan langsung ke shell. Menambahkan implementor lain ke antarmuka InitSystem yang berfungsi untuk OpenRC ditambah skrip layanan openrc mungkin akan melakukannya.

EDIT:
Mendalami, memasukkan Kubernetes ke Alpine-ARM akan membutuhkan beberapa pekerjaan. Menjalankan kubelet secara manual dimungkinkan, tetapi setelah waktu debugging yang signifikan saya curiga ada masalah jaringan yang sedang terjadi karena apiserver gagal menyinkronkan dengan etcd saat melakukan init dasar dengan kubeadm.

@detiber Anda benar di sana. Tetapi beberapa paket lebih baik daripada tidak ada paket. Ini berarti bahwa kami memiliki pengelola yang dapat kami ping dengan proposal tertentu.

@bcdurden

ini berasal dari sini:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
dan sistem init baru harus ditambahkan di sana.

Sekilas, ini sebenarnya terlihat cukup lurus ke depan. Saya bukan Go-afficionado dengan cara apa pun, tetapi tampaknya hanya melakukan panggilan langsung ke shell. Menambahkan implementor lain ke antarmuka InitSystem yang berfungsi untuk OpenRC ditambah skrip layanan openrc mungkin akan melakukannya.

ya, kontribusi dipersilakan - yaitu upaya ini didorong oleh komunitas. siapa pun yang mengirim PR untuk itu tolong ping saya.

RE: paket.

ping @fcolista
sesuai: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

Adakah rencana untuk terus mempertahankan paket ini?
tampaknya kurang integrasi sistem init dan hanya menyertakan binari.

kami sedang berdiskusi tentang potensi dukungan untuk Alpine Linux di kubeadm.
pemblokir utama di sini sebenarnya bukan di sisi kubeadm melainkan kubernetes inti yang tidak memiliki dukungan OpenRC (lihat komentar di atas).

RE: paket.

ping @fcolista
sesuai: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

Adakah rencana untuk terus mempertahankan paket ini?
tampaknya kurang integrasi sistem init dan hanya menyertakan binari.

kami sedang berdiskusi tentang potensi dukungan untuk Alpine Linux di kubeadm.
pemblokir utama di sini sebenarnya bukan di sisi kubeadm melainkan kubernetes inti yang tidak memiliki dukungan OpenRC (lihat komentar di atas).

FYI, ada paket kubernetes-cni yang juga dikerjakan oleh kontributor yang sama; tetapi memiliki masalah yang sama (tidak ada init atau pengaturan artefak di apk).

RE: paket.

ping @fcolista
sesuai: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

Adakah rencana untuk terus mempertahankan paket ini?
tampaknya kurang integrasi sistem init dan hanya menyertakan binari.

kami sedang berdiskusi tentang potensi dukungan untuk Alpine Linux di kubeadm.
pemblokir utama di sini sebenarnya bukan di sisi kubeadm melainkan kubernetes inti yang tidak memiliki dukungan OpenRC (lihat komentar di atas).

@ neolit123 , @bcdurden hai.
Jangan ragu untuk membuka PR ke https://github.com/alpinelinux/aports/ dengan init openrc-run.
Saya sudah mencoba membangun kubernetes 1.13.2 tetapi build tersebut kehabisan memori saat ini.
Saya tidak menggunakan kubernetes jadi jika Anda memiliki petunjuk tentang cara cepat menguji kemungkinan init yang akan sangat dihargai, saya bisa mengerjakannya. Pada saat yang sama, paket tersebut sedang dalam "pengujian" dengan tepat karena belum siap untuk diproduksi.
Terima kasih!

@fcolista Saya punya satu, tapi itu 'hacky'. Sesuatu tentang Alpine di ARM64 dengan Kubelet baik memblokir etcd dari penyelesaian atau tidak menunggu cukup lama. Saya harus memulai kubelet, menghentikan proses setelah sekitar 20-30 detik, lalu memulainya kembali. Tampaknya tidak menunggu cukup lama untuk memungkinkan apiserver online dan membuat / menyinkronkan sumber daya (memakan waktu total sekitar 2 menit). Peretasan ini membuat penggunaan kubeadm init dan bergabung menjadi sangat tidak pasti. Belum punya kesempatan untuk melacak masalahnya. Ini adalah Alpine 3.8 di ARM64 yang berjalan di RPi 3B +

Saya juga menemukan masalah lain dengan kubeadm join mengalami masalah dengan biner 'find' BusyBox yang tidak memiliki flag -printf.

EDIT: Lupa menambahkan, ini menggunakan binari rilis umum Kubernetes untuk ARM64. Saya pasti tidak mengkompilasinya (Go hanya paket Edge untuk 3,8 di tanah ARM64)

@bcdurden itu sangat menarik. Bisa jadi etcd tidak berputar cukup cepat dan server API mengalami crash loop back-off (mirip dengan kubernetes / kubernetes # 72984).
Bisakah kita melihat hasil dari docker ps -a dan beberapa log kubelet?

@bcdurden itu sangat menarik. Bisa jadi etcd tidak berputar cukup cepat dan server API mengalami crash loop back-off (mirip dengan kubernetes / kubernetes # 72984 ).
Bisakah kita melihat hasil dari docker ps -a dan beberapa log kubelet?

@rosti Ini sangat mungkin, meskipun saya ingat tampaknya etcd sedang berjalan dan secara aktif mendengarkan permintaan. Hanya tidak menerima atau memprosesnya? Ada titik di mana apiserver mengatakan 'Memuat pengontrol' dan mencantumkan berbagai jenis yang didukungnya, dll. Dan kemudian tidak pernah sampai ke titik di mana ia menyinkronkan sumber daya dengan benar. Akhirnya ini menampilkan pesan kegagalan yang menjelaskan bahwa ia tidak dapat menyinkronkan sumber daya. Kubelet kemudian me-restart apiserver dan mencoba lagi (loop tak berujung pada saat ini).

Saat ini saya dalam perjalanan bisnis, tetapi saya akan mencoba memasukkan log di sini secepat mungkin.

Sampai ini teratasi, saya telah membuat https://github.com/oz123/systemctl-shim/ ini untuk menerjemahkan perintah systemctl ke openrc.

kami saat ini sedang dalam pembekuan kode untuk 1,14, tetapi https://github.com/kubernetes/kubernetes/pull/73101 PR tampak seperti penggabungan yang bersih bagi saya. itu diblokir pada pkg/util/initsystem/ PEMILIK dan semoga kami dapat segera menggabungkannya.

^ melakukan ping ke orang-orang tentang PR di atas.

@ oz123 @btrp dkk,
LMK jika menggabungkan https://github.com/kubernetes/kubernetes/pull/73101 akan membebaskan pengguna alpine.

@ neolit123 terima kasih sudah berhati-hati. Saya akan melanjutkan pekerjaan sekarang. Ini luar biasa!

@ oz123 dapatkah Anda menjelaskan apa lagi yang harus dilakukan?

@ neolit123 kita perlu memeriksa bahwa kegagalan pada OpenRC tidak menampilkan pesan:

If you are on a systemd-powered system, you can try ....

lihat misalnya kubeletFailTempl .

Selain itu, tanda kubelet ditulis di / etc / places yang tidak masuk akal untuk OpenRC dan hanya relevan untuk systemd. Jadi ini juga harus modular ...
Saya tidak bisa, saya dapat mengirimkan permintaan penggabungan besar untuk menyelesaikan semua masalah sekaligus. Saya bermaksud untuk membagi pekerjaan menjadi sekitar 2 hingga 3 PR lagi. Jadi masalah harus dibuka kembali, atau kami dapat melacaknya di masalah lain.

ok, terima kasih telah menyegarkan ingatan saya. Saya mulai mengingat apa yang harus dilakukan.

Selain itu, tanda kubelet ditulis di / etc / places yang tidak masuk akal untuk OpenRC dan hanya relevan untuk systemd. Jadi ini juga harus modular ...

sebaiknya perubahan harus diabstraksi dengan baik pada waktu proses dan tidak terlalu mengganggu cara penanganan sistem init yang sudah ada. itu terutama karena systemd menjadi target utama.

saya akan mulai dengan fungsi utilitas yang mendeteksi openrc mungkin di bawah cmd/kubeadm/app/util/initsystem
itu harus memiliki tes unit dan tidak ada op di windows.

cukup ping saya di PR mana saja.

@ neolit123 Deteksi sistem init dilakukan dengan benar sudah di
cmd/kubeadm/app/phases/kubelet/kubelet.go , jadi saya rasa tidak ada kebutuhan untuk file lain.

hm, ini akan mengabstraksi proses start / stop layanan, tetapi kubeadm masih akan membaca / menulis beberapa file seperti file drop-in dinamis di bawah / etc. kode lainnya juga perlu tahu tentang openrc:
misalnya
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/flags.go#L120

File drop-in kubelet untuk systemd
https://kubernetes.io/docs/setup/independent/kubelet-integration/#the -kubelet-drop-in-file-for-systemd

Tepatnya, saya katakan di atas bahwa kubeadm menulis hal-hal pada sistem file di tempat-tempat yang hanya relevan dengan systemd.
Oke, saya akan melakukan pekerjaan yang diperlukan seperti yang Anda sarankan di cmd/kubeadm/app/util/initsystem .

https://github.com/oz123/kubernetes/blob/2a40ef473f906b6a165690480dc000b9e5560258/pkg/util/initsystem/initsystem.go
^ jika ini termasuk metode untuk mengembalikan tipe enum dari sistem init yang terdeteksi, itu akan lebih bersih, tetapi saat Anda melihat penggabungan PR, mungkin diperlukan beberapa saat ...

Haruskah ini ditandai lifecycle/active atau tidak bertanda help wanted ? Tampaknya tidak siap bagi siapa pun untuk mengambilnya, karena sudah dikerjakan.

ditandai sebagai aktif sebagai @ oz123 disebutkan bahwa dia dapat melihat perubahan tindak lanjut.

Karena PR di atas menyebutkan dukungan parsial, apa yang saat ini hilang untuk dukungan penuh @ oz123 ?

@mrueg apa yang hilang hampir semua yang kita bahas di utas ini. Saat ini saya kekurangan waktu untuk menyelesaikan pekerjaan, jika seseorang ingin mensponsori, silakan hubungi saya. Jika orang lain ingin mengambil alih pekerjaan ini, saya juga setuju dengan itu.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirim masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

/ siklus hidup dibekukan

ini adalah masalah openrc yang tertunda: https://github.com/kubernetes/kubeadm/issues/1986

tidak bisa berlari di alpine juga :(

Saya menggunakan k8s di Alpine (satu cluster berjalan di x86_64, armv7 dan aarch64) sebagai solusi saat bergabung dengan node ke cluster Saya secara manual me-restart kubelet ketika gagal, tampaknya hanya perlu dilakukan sekali.

Saya berhasil memulai cluster beberapa hari yang lalu dengan bantuan dari @ neolit123 .

• Https://github.com/kubernetes/kubernetes/pull/90892 PR ini memperbaiki kubeadm yang macet
• Ada masalah lain dengan resolv-conf default ke /run/systemd/resolve/resolv.conf , saya telah menyiapkan komit lain karena saya berada di belakang master tetapi tampaknya ini telah diperbaiki di https://github.com/kubernetes/kubernetes / commit / 28b9a4e0d64e3a00343a93e1fc241a5328c3f926 # diff -1a4e0bdeb8495d00560f3e20354abf41

Selanjutnya, untuk menyelesaikan ini, saya memerlukan kerja sama dari @fcolista untuk memperbaiki sisi alpine. Saya sudah menghubungi Anda tetapi tidak mendapat tanggapan.

Jika tidak, semuanya dari sisi kubeadm berfungsi dengan baik sekarang dan masalah ini dapat ditutup setelah PR saya digabungkan.

@xphoniex Saya
Saya lebih suka patch Anda diterapkan ke hulu ... saat ini versi Alpine terhenti di 1.17.3, karena 1.18 tidak dibangun dengan go 1.13.
Beri tahu saya bantuan / kerja sama seperti apa yang Anda butuhkan dari pihak saya.
Terima kasih!

PR ini di sisi alpine diperlukan, meninggalkan mereka di sini untuk referensi:

• tambahkan pidfile ke docker.initd dan buat foldernya

• perbaiki masalah layanan kubelet saat mulai, tambahkan dukungan untuk kubeadm

• ubah lokasi binari dan lisensi cni-plugins

Dan itu dia.

@xphoniex mereka telah digabungkan
.: Francesco

kita juga bisa menutup ini sekarang karena https://github.com/kubernetes/kubernetes/pull/90892 digabungkan @ neolit123 , ya?

Saya pikir ini adalah item terakhir yang tersisa:
https://github.com/kubernetes/kubeadm/issues/1295#issuecomment -491446853

Alpine sudah menggunakan /etc/ untuk layanan, jadi kami menyimpan file konfigurasi di sana juga.

Kami hanya perlu memperbarui flag di kubelet.confd dan kubelet.initd untuk paket kubernetes agar OpenRC tahu di mana file konfigurasi lainnya berada, Anda dapat melihat perbedaannya di sini .

Perhatikan misalnya bahwa kami menghasilkan --cni-bin-dir=/usr/share/cni-plugins/bin sesuai saran Francesco sedangkan pada distro lain kami mengharapkan binari berada di /opt/cni/bin .

mengerti, ini adalah berita bagus dan saya akan menutup tiket ini (akhirnya).
/Menutup

beberapa file layanan FYI WRT:

• pembaruan ke file 10-kubeadm.conf akan segera terjadi pada saat ini, namun tidak jelas kapan , mungkin di +3, mungkin +5 rilis.
  kubelet menghapus semua benderanya untuk mendukung penggunaan nilai file konfigurasi melalui --config. ketika ini terjadi kita akan berhenti mencari kubeadm-flags.env dan /etc/default/kubelet di 10-kubeadm.conf dan kubeadm akan berhenti menghasilkan kubeadm-flags.env pada waktu proses.

• dockershim yang merupakan implementasi CRI untuk pekerja galangan bergerak di luar kode sumber kubelet ke dalam repositori git terpisah dan layanan terpisah. jadi pengguna buruh pelabuhan harus menjalankannya secara terpisah sebelum memulai layanan kubelet. tidak jelas apa basis pengguna untuk buruh pelabuhan di alpine, tetapi buruh pelabuhan keseluruhan untuk pengguna kubeadm adalah 70% sesuai survei yang kami lakukan beberapa tahun yang lalu.

@ neolit123 : Menutup masalah ini.