Am 23. September um 20:00 MESZ wird Sergej Bondarev ein kostenloses Webinar „„ halten, in dem er erklärt, wie Kubespray vorbereitet wird, um schnell, effektiv und ausfallsicher zu sein.
Sergej Bondarev 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, werden sich wahrscheinlich fragen, warum ich Kubeadm Kubespray gegenüberstelle, denn Kubespray wird genau zum Erstellen eines Clusters eingesetzt und ruft Kubeadm auf, es sieht auf den ersten Blick aus wie ein Paketinstallationsskript und ein automatisierter Start.
Aber das war nicht immer so, ursprünglich installierte Kubespray alle Komponenten selbst:
- erstellte einen etcd-Cluster;
- installierte Kubelets, generierte Zertifikate, Konfigurationen und Zugangstoken für die statischen Pods des Control Plane und andere Dienstkomponenten;
- erstellte Dienstkonten für die Arbeitsknoten und verband sie mit dem Cluster.
Vor zwei Jahren wurde diese Funktion entfernt, es blieb nur kubeadm, das damals nicht besonders war. Ich war enttäuscht und habe meinen eigenen Fork erstellt, in dem ich den klassischen Installationsmodus beibehalten habe, und jetzt pflege ich diesen Fork, indem ich Commits aus dem Original-Kubespread cherry-picke. Gleichzeitig passe ich den klassischen Modus an die neuen Änderungen an.
Am Ende besteht der Unterschied zwischen den Clustern, die mit meinem Fork und dem Original erstellt wurden, aus kube-proxy und der Gültigkeitsdauer der Zertifikate.
In meinem Fork ist alles geblieben, wie es früher war – kube-proxy wird als statischer Pod gestartet, die Zertifikate werden für 100 Jahre ausgestellt.
In Kubeadm wird kube-proxy als Daemonset gestartet, und die Zertifikate werden für ein 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 heute verwenden wir beide Varianten.
Besonderheiten (Nachteile) bei der industriellen Nutzung:
Das Szenario ist universell, daher nicht sehr schnell. Der eigene Modus kann erheblich beschleunigt werden, indem Überprüfungen entfernt werden und aus einem bereitgestellten Image gestartet wird.
Das Szenario ist komplex, es gibt logische Probleme und ein schweres Erbe von Legacy-Systemen. Die Installation zusätzlicher Controller und Software über KubeSpray ist gut für Schulungen und Tests. In der produktiven Nutzung ist es jedoch keine kluge Idee, von KubeSpray abhängig zu sein, plus die Software-Updates werden nach dem Prinzip "kaputt gemacht - neu gemacht" durchgeführt, was bedeutet, dass es eine Serviceunterbrechung gibt.
Es können nur Arbeitsknoten hinzugefügt werden, es gibt einige Nuancen mit den Masterknoten hinsichtlich 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 abstürzte, und danach führte KubeSpray einen kubeadm reset auf dem Knoten durch und versuchte, den Master erneut hinzuzufügen.
Das Problem war jedoch, dass zur Zeit des Fehlers die zweite Instanz von etcd bereits registriert war, und da sie auch nach dem Reset entfernt wurde, hatten wir ein großes Chaos – ein etcd-Cluster mit zwei Knoten, von denen einer entfernt wurde und der andere keine Clients mehr akzeptiert. Letztendlich starb das Cluster, ohne je zu leben.
Open Source, wie es ist.
Das alles und vieles mehr bei dem kostenlosen Webinar „“ am 23. September um 20:00 Uhr MSK.
Treten Sie bei!
Quelle: habr.com
