Kubeadm: Unterstützung für OpenRC als Init-System hinzufügen

Bitte korrigieren Sie zuerst die Warnungen, die kubeadm Ihnen zur Verfügung stellt. Beginnen Sie beispielsweise mit der Definition des richtigen Werts für die Umgebungsvariable NO_PROXY, stellen Sie dann sicher, dass alle erforderlichen Binärdateien auf dem System vorhanden sind (tc, ebtables, ...), und überprüfen Sie dann, was im Status und in den Protokollen von kubelet enthalten ist.

/zuordnen

Mit allen Warnungen, außer dass kein unterstütztes Init-System erkannt wurde. Hat immer noch das gleiche Problem.

kubeadm init
I1204 10: 42: 06.894219 7292 version.go: 236] Remote-Version ist viel neuer: v1.13.0; Zurückfallen auf: Stable-1.12
[init] mit Kubernetes Version: v1.12.3
[Preflight] Ausführen von Pre-Flight-Checks
[WARNUNG Firewalld]: Es wurde kein unterstütztes Init-System erkannt. Die Überprüfung auf Dienste wird übersprungen
[WARNUNG Service-Docker]: Kein unterstütztes Init-System erkannt, Überprüfung auf Dienste übersprungen
[WARNUNG Service-Kubelet]: Kein unterstütztes Init-System erkannt, Überprüfung auf Services übersprungen
[Preflight / Bilder] Abrufen von Bildern, die zum Einrichten eines Kubernetes-Clusters erforderlich sind
[Preflight / Bilder] Dies kann je nach Geschwindigkeit Ihrer Internetverbindung ein oder zwei Minuten dauern
[Preflight / Bilder] Sie können diese Aktion auch vorher mit 'kubeadm config images pull' ausführen.
[Preflight] Kein unterstütztes Init-System erkannt, stellt nicht sicher, dass das Kubelet für kurze Zeit nicht ausgeführt wird, während die Konfiguration dafür eingerichtet wird.
[kubelet] Schreiben einer Kubelet-Umgebungsdatei mit Flags in die Datei "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Schreiben der Kubelet-Konfiguration in die Datei "/var/lib/kubelet/config.yaml"
[Preflight] Kein unterstütztes Init-System erkannt, stellt nicht sicher, dass das Kubelet ordnungsgemäß ausgeführt wird.
[Zertifikate] Verwenden des vorhandenen etcd / Server-Zertifikats und -Schlüssels.
[Zertifikate] Verwenden des vorhandenen apiserver-etcd-client-Zertifikats und -Schlüssels.
[Zertifikate] Verwenden des vorhandenen etcd / Peer-Zertifikats und -Schlüssels.
[Zertifikate] Verwenden des vorhandenen Zertifikats und Schlüssels etcd / healthcheck-client.
[Zertifikate] Verwenden des vorhandenen Apiserver-Zertifikats und -Schlüssels.
[Zertifikate] Verwenden des vorhandenen Apiserver-Kubelet-Client-Zertifikats und -Schlüssels.
[Zertifikate] Verwenden des vorhandenen Front-Proxy-Client-Zertifikats und -Schlüssels.
[Zertifikate] Gültige Zertifikate und Schlüssel sind jetzt in "/ etc / kubernetes / pki" vorhanden.
[Zertifikate] Verwenden des vorhandenen sa-Schlüssels.
[kubeconfig] Verwenden der vorhandenen aktuellen KubeConfig-Datei: "/etc/kubernetes/admin.conf"
[kubeconfig] Verwenden der vorhandenen aktuellen KubeConfig-Datei: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Verwenden der vorhandenen aktuellen KubeConfig-Datei: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Verwenden der vorhandenen aktuellen KubeConfig-Datei: "/etc/kubernetes/scheduler.conf"
[controlplane] hat das Static Pod-Manifest für die Komponente kube-apiserver an "/etc/kubernetes/manifests/kube-apiserver.yaml" geschrieben.
[controlplane] hat das Static Pod-Manifest für die Komponente kube-controller-manager an "/etc/kubernetes/manifests/kube-controller-manager.yaml" geschrieben.
[controlplane] hat das Static Pod-Manifest für die Komponente kube-scheduler an "/etc/kubernetes/manifests/kube-scheduler.yaml" geschrieben.
[etcd] Schrieb ein statisches Pod-Manifest für eine lokale etcd-Instanz an "/etc/kubernetes/manifests/etcd.yaml".
[init] Warten, bis das Kubelet die Steuerebene als statische Pods aus dem Verzeichnis "/ etc / kubernetes / manifestes" hochfährt.
[init] Dies kann eine Minute oder länger dauern, wenn die Bilder der Steuerebene gezogen werden müssen
[Kubelet-Check] Es scheint, als ob das Kubelet nicht läuft oder gesund ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http: // localhost : 10248 / healthz' ist mit folgendem Fehler fehlgeschlagen: Get http: // localhost : 10248 / healthz: Wählen Sie tcp [:: 1]: 10248: connect : Verbindung abgelehnt.
[Kubelet-Check] Es scheint, als ob das Kubelet nicht läuft oder gesund ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http: // localhost : 10248 / healthz' ist mit folgendem Fehler fehlgeschlagen: Get http: // localhost : 10248 / healthz: Wählen Sie tcp [:: 1]: 10248: connect : Verbindung abgelehnt.
[Kubelet-Check] Es scheint, als ob das Kubelet nicht läuft oder gesund ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http: // localhost : 10248 / healthz' ist mit folgendem Fehler fehlgeschlagen: Get http: // localhost : 10248 / healthz: Wählen Sie tcp [:: 1]: 10248: connect : Verbindung abgelehnt.
[Kubelet-Check] Es scheint, als ob das Kubelet nicht läuft oder gesund ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http: // localhost : 10248 / healthz' ist mit folgendem Fehler fehlgeschlagen: Get http: // localhost : 10248 / healthz: Wählen Sie tcp [:: 1]: 10248: connect : Verbindung abgelehnt.
[Kubelet-Check] Es scheint, als ob das Kubelet nicht läuft oder gesund ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http: // localhost : 10248 / healthz' ist mit folgendem Fehler fehlgeschlagen: Get http: // localhost : 10248 / healthz: Wählen Sie tcp [:: 1]: 10248: connect : Verbindung abgelehnt.

Leider ist ein Fehler aufgetreten:
Zeitüberschreitung beim Warten auf den Zustand

Dieser Fehler wird wahrscheinlich verursacht durch:
- Das Kubelet läuft nicht
- Das Kubelet ist aufgrund einer Fehlkonfiguration des Knotens in irgendeiner Weise ungesund (erforderliche cgroups deaktiviert)

Wenn Sie sich auf einem systemd-basierten System befinden, können Sie versuchen, den Fehler mit den folgenden Befehlen zu beheben:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Darüber hinaus kann eine Steuerebenenkomponente beim Starten durch die Container-Laufzeit abgestürzt oder beendet sein.
Listen Sie zur Fehlerbehebung alle Container mit Ihrer bevorzugten Container-Laufzeit-CLI auf, z. B. Docker.
Hier ist ein Beispiel, wie Sie alle im Docker ausgeführten Kubernetes-Container auflisten können:
- 'Docker ps -a | grep kube | grep -v pause '
Sobald Sie den fehlerhaften Container gefunden haben, können Sie seine Protokolle überprüfen mit:
- 'Docker protokolliert CONTAINERID'
Ein Kubernetes-Cluster konnte nicht initialisiert werden

Auch das Nicht-Unterstützen des Init-Systems (openrc) ist völlig verständlich. Vielleicht ist eine Verbesserung hier nur eine Dokumentation der unterstützten Init-Systeme (oder nur zu sagen, dass es nur Systemd unterstützt, wenn dies der Fall ist).

Können Sie freigeben, was in den Protokollen für Kubelet und in Docker-Containern enthalten ist (falls welche nach Kubeadm-Fehlermeldungen ausgeführt werden)?

Hallo Kad, soweit ich das beurteilen kann, läuft kein Kubelet-Prozess und es werden nie Container gestartet.

Ich weiß wenig über kubeadms-Interna, aber es scheint, dass es zu Beginn einen Dienst konfigurieren möchte (z. B. systemd), kein unterstütztes Init-System finden kann, es also überspringt, aber später darauf wartet, dass dieses Init-System das gestartet hat Kubelet.

ps
PID USER TIME COMMAND
1 root 0:00 / sbin / init
2 root 0:00 [kthreadd]
4 root 0:00 [kworker / 0: 0H]
5 root 0:00 [kworker / u64: 0]
6 root 0:00 [mm_percpu_wq]
7 root 0:00 [ksoftirqd / 0]
8 root 0:00 [rcu_sched]
9 root 0:00 [rcu_bh]
10 root 0:00 [Migration / 0]
11 root 0:00 [Wachhund / 0]
12 root 0:00 [cpuhp / 0]
13 root 0:00 [kdevtmpfs]
14 root 0:00 [netns]
16 root 0:00 [oom_reaper]
174 root 0:00 [Rückschreiben]
175 root 0:00 [kworker / 0: 1]
176 root 0:00 [kcompactd0]
178 root 0:00 [ksmd]
179 root 0:00 [Krypto]
180 root 0:00 [kintegrityd]
182 root 0:00 [kblockd]
445 root 0:00 [ata_sff]
454 root 0:00 [md]
460 root 0:00 [watchdogd]
585 root 0:00 [kauditd]
591 root 0:00 [kswapd0]
679 root 0:00 [kthrotld]
911 root 0:00 [hv_vmbus_con]
1182 root 0:00 [scsi_eh_0]
1255 root 0:00 [scsi_tmf_0]
1264 root 0:00 [kworker / u64: 3]
1406 root 0:00 [jbd2 / sda3-8]
1407 root 0:00 [ext4-rsv-conver]
1821 root 0:00 [hv_balloon]
1874 root 0:00 [ipv6_addrconf]
1965 root 0:00 [kworker / 0: 1H]
2235 root 0:00 / sbin / syslogd -Z
2289 root 0:00 / sbin / acpid
2318 chrony 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
2509 root 0:00 -ash
2514 root 0:00 Docker-Containerd --config /var/run/docker/containerd/containerd.toml
2964 root 0:00 [kworker / 0: 0]
3064 root 0:00 sshd: root @ pts
3066 root 0:00 -ash
3241 root 0:00 [kworker / u64: 1]
3311 root 0:00 [kworker / 0: 2]
3314 root 0:00 / sbin / getty -L 115200 ttyS0 vt100
3315 root 0:00 ps

Docker ps -a
BEHÄLTER-ID BILDBEFEHL ERSTELLTE STATUS-PORTS-NAMEN

unterstützt nur systemd und wininit init system. Sie können kubelet manuell installieren und den Code löschen, der die kubelet-Konfigurationsdatei in kubeadm installiert. Vielleicht funktioniert es

ist alpine linux ein ziel für uns?
Wir könnten uns darauf verlassen, dass die Community es patcht.

ist alpine linux ein ziel für uns?
Wir könnten uns darauf verlassen, dass die Community es patcht.

Alpine Linux ist ein sehr beliebtes Ziel für Container - aufgrund seiner extrem geringen Größe / Installation - auch sehr beliebt für Vagrant / EC2 - ich bin überrascht, dass es nicht unterstützt wird. Durch den kubedm-Code gepackt - es scheint, als würde er nur mit systemd herumspielen, um Docker / Kubernetes-Sachen zu starten.

Gibt es ein Dokument, das beschreibt, was kubeadm vom Init-System tut / beabsichtigt / davon abhängt?

Gibt es ein Dokument, das beschreibt, was kubeadm vom Init-System tut / beabsichtigt / davon abhängt?

Unter Linux wird systemd verwendet, um das Kubelet zu starten / zu stoppen:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/kubelet.go

Dieses Dokument beschreibt teilweise die Interaktion zwischen kubeadm und systemd:
https://kubernetes.io/docs/setup/independent/kubelet-integration/#configure -kubelets-using-kubeadm

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

Alpine Linux verwendet OpenRC für sein Init-System.

Dieses Init-System wird von Core-Kubernetes nicht unterstützt.
In diesem Fall verwendet Kubeadm das, was im Kern verfügbar ist.

[WARNUNG Service-Docker]: Kein unterstütztes Init-System erkannt, Überprüfung auf Dienste übersprungen
[WARNUNG Service-Kubelet]: Kein unterstütztes Init-System erkannt, Überprüfung auf Services übersprungen

das kommt von hier:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
Dort müssen neue Init-Systeme hinzugefügt werden.

/ weise @timothysc @detiber zu
für das Urteil über diesen.

Hat jemand bereits die erforderlichen Binärdateien (und die erforderlichen Init-Skripte) für Alpine gepackt? Wenn ja, sehe ich kein Problem beim Hinzufügen einer angemessenen Unterstützung für die korrekte Verwaltung von Diensten. Wenn nicht, würde ich dies als Voraussetzung für das weitere Vorgehen betrachten, da die Verwaltung der Init-Skripte / -Konfigurationen nicht in der Verantwortung von kubeadm liegt.

Es scheint ein einziges Kubernetes Paket zu sein hier .

@rosti Wenn man sich den Inhalt dieses Pakets ansieht, sieht es im Grunde wie ein Speicherauszug mehrerer k8s-Binärdateien aus und enthält kein Init-Skript oder keine Konfiguration, die von kubeadm gesteuert werden muss.

Ich bin normalerweise ein Lurker. Das Interesse der Industrie an Kubernetes on the Edge mit ARM ist jedoch groß, und verschiedene Bare-Metal-Optionen werden untersucht, wobei Alpine in der Mischung der Betriebssystemoptionen enthalten ist.

Ich denke, die OpenRC-Unterstützung in kubeadm ist ein Muss. Ich bin nicht sicher, ob die Community von Alpine einen Patch veröffentlichen wird, der etwas „Grundlegendes“ für den Bekanntheitsgrad des Betriebssystems „behebt“.

Ich bin normalerweise ein Lurker. Das Interesse der Industrie an Kubernetes on the Edge mit ARM ist jedoch groß, und verschiedene Bare-Metal-Optionen werden untersucht, wobei Alpine in der Mischung der Betriebssystemoptionen enthalten ist.

Ich denke, die OpenRC-Unterstützung in kubeadm ist ein Muss. Ich bin nicht sicher, ob die Community von Alpine einen Patch veröffentlichen wird, der etwas „Grundlegendes“ für den Bekanntheitsgrad des Betriebssystems „behebt“.

Ich vermute sehr, dass Sie richtig liegen - mit der Speicher- / Bildgröße, auf die sie abzielen - kann ich wirklich nicht sehen, dass sie den (nicht respektlosen) Systemweg gehen.

Gibt es ein Dokument, das beschreibt, was kubeadm vom Init-System tut / beabsichtigt / davon abhängt?

Unter Linux wird systemd verwendet, um das Kubelet zu starten / zu stoppen:
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/kubelet.go

Dieses Dokument beschreibt teilweise die Interaktion zwischen kubeadm und systemd:
https://kubernetes.io/docs/setup/independent/kubelet-integration/#configure -kubelets-using-kubeadm

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

Alpine Linux verwendet OpenRC für sein Init-System.

Dieses Init-System wird von Core-Kubernetes nicht unterstützt.
In diesem Fall verwendet Kubeadm das, was im Kern verfügbar ist.

[WARNUNG Service-Docker]: Kein unterstütztes Init-System erkannt, Überprüfung auf Dienste übersprungen
[WARNUNG Service-Kubelet]: Kein unterstütztes Init-System erkannt, Überprüfung auf Services übersprungen

das kommt von hier:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
Dort müssen neue Init-Systeme hinzugefügt werden.

Auf den ersten Blick sieht das eigentlich ganz einfach aus. Ich bin keineswegs ein Go-Afficionado, aber es scheint nur direkte Anrufe an eine Shell zu tätigen. Das Hinzufügen eines weiteren Implementierers zu dieser InitSystem-Schnittstelle, die für OpenRC und das openrc-Dienstskript funktioniert, würde dies wahrscheinlich tun.

BEARBEITEN:
Das Eintauchen in Kubernetes auf Alpine-ARM erfordert einige Arbeit. Das manuelle Ausführen von kubelet ist möglich, aber nach längerem Debuggen vermute ich, dass ein Netzwerkproblem im Gange ist, da der Apiserver nicht mit etcd synchronisiert werden kann, wenn eine grundlegende Initialisierung mit kubeadm durchgeführt wird.

@detiber du bist da richtig. Aber einige Pakete sind besser als keine Pakete. Dies bedeutet, dass wir einen Betreuer haben, den wir mit einem bestimmten Vorschlag anpingen können.

@bcdurden

das kommt von hier:
https://github.com/kubernetes/kubernetes/blob/master/pkg/util/initsystem/initsystem.go#L178
Dort müssen neue Init-Systeme hinzugefügt werden.

Auf den ersten Blick sieht das eigentlich ganz einfach aus. Ich bin keineswegs ein Go-Afficionado, aber es scheint nur direkte Anrufe an eine Shell zu tätigen. Das Hinzufügen eines weiteren Implementierers zu dieser InitSystem-Schnittstelle, die für OpenRC und das openrc-Dienstskript funktioniert, würde dies wahrscheinlich tun.

Ja, Beiträge sind willkommen - dh diese Bemühungen sind gemeinschaftsorientiert. Wer auch immer eine PR dafür schickt, bitte ping mich an.

RE: Pakete.

ping @fcolista
gemäß: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

Gibt es Pläne, dieses Paket weiter beizubehalten?
Es scheint an der Integration des Init-Systems zu mangeln und nur Binärdateien zu enthalten.

Wir haben eine Diskussion über die mögliche Unterstützung von Alpine Linux in kubeadm.
Der Hauptblocker hier ist nicht wirklich auf der Kubeadm-Seite, sondern Kern-Kubernetes, die keine OpenRC-Unterstützung haben (siehe Kommentar oben).

RE: Pakete.

ping @fcolista
gemäß: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

Gibt es Pläne, dieses Paket weiter beizubehalten?
Es scheint an der Integration des Init-Systems zu mangeln und nur Binärdateien zu enthalten.

Wir haben eine Diskussion über die mögliche Unterstützung von Alpine Linux in kubeadm.
Der Hauptblocker hier ist nicht wirklich auf der Kubeadm-Seite, sondern Kern-Kubernetes, die keine OpenRC-Unterstützung haben (siehe Kommentar oben).

Zu Ihrer Information, es gibt ein entsprechendes kubernetes-cni-Paket, das ebenfalls von demselben Mitwirkenden erstellt wurde. aber es hat die gleichen probleme (kein init oder setup der artefakte in der apk).

RE: Pakete.

ping @fcolista
gemäß: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/kubernetes

Gibt es Pläne, dieses Paket weiter beizubehalten?
Es scheint an der Integration des Init-Systems zu mangeln und nur Binärdateien zu enthalten.

Wir haben eine Diskussion über die mögliche Unterstützung von Alpine Linux in kubeadm.
Der Hauptblocker hier ist nicht wirklich auf der Kubeadm-Seite, sondern Kern-Kubernetes, die keine OpenRC-Unterstützung haben (siehe Kommentar oben).

@ neolit123 , @bcdurden hi.
Fühlen Sie sich frei, eine PR unter https://github.com/alpinelinux/aports/ mit einem OpenRC-Run-Init zu öffnen.
Ich habe versucht, kubernetes 1.13.2 zu erstellen, aber der Build verfügt derzeit nicht über genügend Arbeitsspeicher.
Ich benutze keine Kubernetes. Wenn Sie also einen Hinweis darauf haben, wie Sie schnell einen möglichen Init testen können, der sehr geschätzt wird, kann ich daran arbeiten. Gleichzeitig wird das Paket aus dem Grund, der nicht für die Produktion bereit ist, genau "getestet".
Vielen Dank!

@fcolista Ich habe eine, aber es ist 'hacky'. Etwas über Alpine auf ARM64 mit Kubelet blockiert entweder die Fertigstellung von etcd oder wartet nicht lange genug. Ich muss kubelet starten, den Prozess nach ca. 20-30s abbrechen und dann wieder starten. Es scheint nicht lange genug zu warten, damit Apiserver online gehen und Ressourcen erstellen / synchronisieren kann (dauert insgesamt etwa 2 Minuten). Diese Hackiness macht die Verwendung von Kubeadm Init und Join ziemlich heikel. Ich hatte keine Chance, das Problem aufzuspüren. Dies ist Alpine 3.8 auf ARM64 unter RPi 3B +

Ich habe auch ein anderes Problem mit kubeadm join gefunden, bei dem Probleme mit der 'find'-Binärdatei von BusyBox ohne das Flag -printf aufgetreten sind.

BEARBEITEN: Das Hinzufügen wurde vergessen. Hierbei werden die allgemeinen Binärdateien von Kubernetes für ARM64 verwendet. Ich kompiliere es definitiv nicht (Go ist nur ein Edge-Paket für 3.8 in ARM64-Land)

@bcdurden das ist sehr interessant. Könnte sein, dass etcd nicht schnell genug hochfährt und der API-Server in ein Crash-Loop-Back-Off gerät (ähnlich wie bei kubernetes / kubernetes # 72984).
Können wir das Ergebnis von docker ps -a und einigen der Kubelet-Protokolle sehen?

@bcdurden das ist sehr interessant. Könnte sein, dass etcd nicht schnell genug hochfährt und der API-Server in ein Crash-Loop-Back-Off gerät (ähnlich wie bei
Können wir das Ergebnis von docker ps -a und einigen der Kubelet-Protokolle sehen?

@rosti Es ist durchaus möglich, obwohl ich mich erinnere, dass etcd ausgeführt wird und aktiv auf Anfragen wartet. Es geht nur nicht darum, sie zu empfangen oder zu verarbeiten? Es gibt einen Punkt, an dem Apiserver "Laden von Controllern" sagt und die verschiedenen unterstützten Typen usw. auflistet. Und dann kommt es nie zu dem Punkt, an dem Ressourcen ordnungsgemäß synchronisiert werden. Schließlich wird eine Fehlermeldung angezeigt, die beschreibt, dass Ressourcen nicht synchronisiert werden können. Kubelet startet dann Apiserver neu und versucht es erneut (eine Endlosschleife an dieser Stelle).

Ich bin derzeit auf Geschäftsreise, aber ich werde versuchen, die Logs hier so schnell wie möglich einzureichen.

Bis dies behoben ist, habe ich diese https://github.com/oz123/systemctl-shim/ erstellt , um systemctl-Befehle in openrc zu übersetzen.

Wir befinden uns derzeit in Code Freeze für 1.14, aber die PR von https://github.com/kubernetes/kubernetes/pull/73101 scheint mir eine saubere Verschmelzung zu sein. Es ist auf pkg/util/initsystem/ OWNERS blockiert und hoffentlich können wir es ziemlich bald zusammenführen.

^ pingte Leute über die oben genannte PR.

@ oz123 @btrepp et al.,
LMK beim Zusammenführen von https://github.com/kubernetes/kubernetes/pull/73101 entsperrt alpine Benutzer.

@ neolit123 danke fürs aufpassen. Ich werde jetzt die Arbeit fortsetzen. Das ist fantastisch!

@ oz123 Könnten Sie bitte skizzieren, was noch zu tun ist?

@ neolit123 man muss überprüfen, ob Fehler auf OpenRC die Nachricht nicht ausgeben:

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

siehe zum Beispiel kubeletFailTempl .

Außerdem werden Kubelet-Flags in / etc / Orte geschrieben, die für OpenRC keinen Sinn ergeben und nur für systemd relevant sind. Das muss also auch modular sein ...
Ich konnte keine große Zusammenführungsanforderung stellen, um alle Probleme auf einmal zu lösen. Ich beabsichtige, die Arbeit in etwa 2 bis 3 weitere PRs aufzuteilen. Das Problem sollte also erneut geöffnet werden, oder wir können dies in einem anderen Problem nachverfolgen.

ok, danke, dass du mein Gedächtnis aufgefrischt hast. Ich fange an mich zu erinnern, was getan werden musste.

Außerdem werden Kubelet-Flags in / etc / Orte geschrieben, die für OpenRC keinen Sinn ergeben und nur für systemd relevant sind. Das muss also auch modular sein ...

Vorzugsweise sollten die Änderungen zur Laufzeit gut abstrahiert sein und die bereits vorhandenen Methoden zur Handhabung des Init-Systems nicht sehr beeinträchtigen. Das liegt hauptsächlich daran, dass systemd das Hauptziel ist.

Ich würde mit einer Utility-Funktion beginnen, die openrc möglicherweise unter cmd/kubeadm/app/util/initsystem erkennt
Es sollte einen Unit-Test haben und unter Windows nicht aktiv sein.

Pingen Sie mich einfach auf PRs.

@ neolit123 Erkennung des Init-Systems erfolgt bereits in ordnungsgemäß
cmd/kubeadm/app/phases/kubelet/kubelet.go , daher glaube ich nicht, dass eine weitere Datei erforderlich ist.

hm, es wird den Start / Stopp-Prozess des Dienstes abstrahieren, aber kubeadm würde immer noch einige Dateien lesen / schreiben, wie z. B. die dynamische Drop-In-Datei unter / etc. Der Rest des Codes müsste auch über openrc Bescheid wissen:
z.B
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/kubelet/flags.go#L120

Die Kubelet-Drop-In-Datei für systemd
https://kubernetes.io/docs/setup/independent/kubelet-integration/#the -kubelet-drop-in-file-for-systemd

Genau, ich habe oben gesagt, dass kubeadm Sachen an Stellen in das Dateisystem schreibt, die nur systemrelevant sind.
Ok, dann werde ich die Arbeit erledigen, die Sie in cmd/kubeadm/app/util/initsystem .

https://github.com/oz123/kubernetes/blob/2a40ef473f906b6a165690480dc000b9e5560258/pkg/util/initsystem/initsystem.go
^ Wenn dies eine Methode zur Rückgabe des Aufzählungstyps des erkannten Init-Systems enthalten hätte, wäre dies noch sauberer gewesen, aber wie Sie beim Zusammenführen von PRs gesehen haben, kann es eine Weile dauern ...

Sollte dies als lifecycle/active oder nicht als help wanted markiert sein? Es scheint für niemanden bereit zu sein, da es bereits bearbeitet wird.

markiert als aktiv wie @ oz123 erwähnt, dass er

Da in der obigen PR teilweise Unterstützung erwähnt wird, was fehlt derzeit für die vollständige Unterstützung @ oz123 ?

@mrueg Was fehlt, ist fast alles, was wir in diesem Thread besprochen haben. Derzeit fehlt mir die Zeit, um die Arbeit abzuschließen. Wenn jemand sie sponsern möchte, kann er sich gerne an mich wenden. Wenn eine andere Person diese Arbeit übernehmen will, bin ich auch damit einverstanden.

Probleme sind nach 90 Tagen Inaktivität veraltet.
Markieren Sie das Problem mit /remove-lifecycle stale als frisch.
Veraltete Probleme verrotten nach weiteren 30 Tagen Inaktivität und schließen schließlich.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes / test-infra und / oder fejta .
/ Lebenszyklus abgestanden

/ Lebenszyklus eingefroren

Dies ist ein ausstehendes OpenRC-Problem: https://github.com/kubernetes/kubeadm/issues/1986

kann auch nicht auf alpinen laufen :(

Ich verwende k8s auf Alpine (ein einzelner Cluster, der auf x86_64, armv7 und aarch64 ausgeführt wird) als Problemumgehung, wenn ich einen Knoten mit einem Cluster verbinde. Ich starte kubelet manuell neu, wenn es fehlschlägt. Dies scheint nur einmal erforderlich zu sein.

Ich habe es neulich geschafft, mit Hilfe von

• Diese PR https://github.com/kubernetes/kubernetes/pull/90892 behebt, dass kubeadm stecken bleibt
• Es gab ein weiteres Problem mit resolv-conf standardmäßig /run/systemd/resolve/resolv.conf war. Ich hatte ein weiteres Commit vorbereitet, als ich hinter dem Master stand, aber anscheinend wurde dies in https://github.com/kubernetes/kubernetes behoben

Um dies zu vervollständigen, brauche ich außerdem eine Kooperation von

Ansonsten funktioniert jetzt alles von kubeadm Seite einwandfrei und dieses Problem kann geschlossen werden, sobald meine PR zusammengeführt ist.

@xphoniex Ich
Ich bevorzuge, dass Ihr Patch stromaufwärts angewendet wird ... im Moment steckt die alpine Version bei 1.17.3 fest, da 1.18 nicht mit go 1.13 erstellt wird.
Lassen Sie mich wissen, welche Art von Hilfe / Zusammenarbeit Sie von meiner Seite benötigen.
Vielen Dank!

Diese PRs auf der alpinen Seite werden benötigt, so dass sie hier als Referenz verbleiben:

• Fügen Sie pidfile zu docker.initd hinzu und erstellen Sie den Ordner

• Beheben Sie das Problem mit dem Kubelet-Service beim Start und fügen Sie Unterstützung für kubeadm hinzu

• Ändern Sie den Speicherort der Binärdateien und die Lizenz der CNI-Plugins

Und das ist es.

@xphoniex sie wurden zusammengeführt
.: Francesco

Wir können dies jetzt auch schließen, da https://github.com/kubernetes/kubernetes/pull/90892 @ neolit123 zusammengeführt wird , ja?

Ich denke, dies ist der letzte verbleibende Punkt:
https://github.com/kubernetes/kubeadm/issues/1295#issuecomment -491446853

Alpine verwendet bereits /etc/ für Dienste, daher haben wir die Konfigurationsdateien auch dort aufbewahrt.

Wir mussten nur die Flags in kubelet.confd und kubelet.initd für das kubernetes-Paket aktualisieren, um OpenRC wissen zu lassen, wo sich die restlichen Konfigurationsdateien befanden. Sie können den Unterschied hier sehen .

Beachten Sie zum Beispiel, dass wir gemäß Francescos Vorschlag --cni-bin-dir=/usr/share/cni-plugins/bin , während wir in anderen Distributionen erwarten, dass die Binärdateien in /opt/cni/bin .

verstanden, das sind großartige Neuigkeiten und ich werde dieses Ticket (endlich) schließen.
/schließen

ein paar FYI WRT-Servicedateien:

• Die Aktualisierung der Datei 10-kubeadm.conf steht zu diesem Zeitpunkt unmittelbar bevor, ist jedoch nicht klar, wann , möglicherweise in +3, möglicherweise +5 Versionen.
  Das Kubelet entfernt alle seine Flags, um die Werte der Konfigurationsdatei über --config zu verwenden. In diesem Fall werden wir aufhören, kubeadm-flags.env und /etc/default/kubelet in 10-kubeadm.conf beschaffen, und kubeadm wird zur Laufzeit keine kubeadm-flags.env mehr generieren.

• Dockershim, die CRI-Implementierung für Docker, wird außerhalb des Kubelet-Quellcodes in ein separates Git-Repository und einen separaten Service verschoben. Docker-Benutzer müssen es daher separat ausführen, bevor sie den Kubelet-Dienst starten. unklar, was die Nutzerbasis für Docker auf Alpen ist, aber insgesamt Docker für Kubeadm-Benutzer beträgt 70% nach einer Umfrage, die wir vor ein paar Jahren durchgeführt haben.

@ neolit123 : Dieses Problem wird geschlossen.