Am 23. September um 20:00 Uhr MSK wird Sergej Bondarew ein kostenloses Webinar „“ abhalten, in dem er erklärt, wie Kubespray vorbereitet wird, um es schnell, effizient und ausfallsicher zu machen.
Sergej Bondarew wird den Unterschied zwischen der Originalversion und unserem Fork erläutern:
Der Unterschied zwischen der Originalversion und unserem Fork.
Diejenigen, die bereits mit Kubespray gearbeitet haben, fragen sich vielleicht jetzt, warum ich kubeadm Kubespray gegenüberstelle, da Kubespray zum Erstellen eines Clusters tatsächlich kubeadm aufruft und auf den ersten Blick wie ein Installationsskript für Pakete und automatisierten Start aussieht.
Aber das war nicht immer so, ursprünglich installierte Kubespray alle Komponenten selbst:
- es erstellte das etcd-Cluster;
- installierte Kubelets, erstellte Zertifikate, Konfigurationen und Zugriffstokens für statische Pods des Controlplanes und andere Dienstkomponenten;
- erstellte Dienstkonten für Arbeitsknoten und verband sie mit dem Cluster.
Aber vor zwei Jahren haben sie diese Funktionalität entfernt und nur kubeadm belassen. Das war damals nicht sehr gut. Es war mir leid, und ich habe meinen eigenen Fork gemacht, in dem ich den klassischen Installationsmodus beibehalten habe, und unterstütze nun diesen Fork, indem ich Commits aus dem originalen Kubespray cherry-picke. Nebenbei habe ich den klassischen Modus an die neuen Änderungen angepasst.
Letztendlich besteht der Unterschied zwischen Clustern, die mit meinem Fork und der Originalversion erstellt wurden, in kube-proxy und der Gültigkeitsdauer der Zertifikate.
In meinem Fork ist alles so geblieben, wie es früher war – kube-proxy läuft als statischer Pod, Zertifikate werden für 100 Jahre ausgestellt.
In Kubeadm läuft kube-proxy als DaemonSet, und die Zertifikate werden für 1 Jahr ausgestellt, und sie müssen regelmäßig verlängert werden. Kubeadm hat endlich gelernt, dies mit einem Befehl zu tun.
Der Unterschied ist gering, und heutzutage nutzen wir beide Varianten.
Besonderheiten (Nachteile) bei der industriellen Nutzung:
Das Szenario ist universell, daher nicht sehr schnell. Die eigene Lösung kann erheblich beschleunigt werden, indem man Prüfungen weglässt und aus einem fertigen Image startet.
Das Szenario ist komplex, es gibt unlogische Stellen und ein schweres Erbe. Die Installation zusätzlicher Controller und Software über Kubespray ist gut für Schulungen und Tests. In der Produktionsumgebung ist es jedoch keine kluge Idee, von Kubespray abhängig zu sein, und das Software-Update erfolgt nach dem "zuerst gelöscht, dann neu gemacht"-Prinzip – was bedeutet, dass es zu Unterbrechungen im Betrieb kommt.
Es können nur Arbeitsknoten hinzugefügt werden; bei den Master-Knoten gibt es einige Besonderheiten bezüglich der Zertifikate, und das Szenario behandelt nicht alle möglichen Probleme, die auftreten können.
Zum Beispiel hatte ich ein Problem mit kubeadm, als es beim Hinzufügen des zweiten und dritten Masters abgestürzt ist, und danach führte Kubespray einen kubeadm reset auf dem Knoten durch und versuchte, den Master erneut hinzuzufügen.
Das Problem war jedoch, dass sich der zweite etcd-Instanz zum Zeitpunkt des Fehlers bereits registriert hatte, und da auch er nach dem Reset entfernt wurde, erhielten wir ein Schreckensszenario – ein etcd-Cluster aus zwei Knoten, von denen einer gelöscht wurde und der andere keine Clients mehr akzeptiert. Das Ergebnis war, dass das Cluster nach der Geburt starb.
Open Source, wie es ist.
All dies und vieles mehr in einem kostenlosen Webinar „“ am 23. September um 20:00 MESZ.
Nehmt teil!
Quelle: habr.com
