{"id":83787,"date":"2020-06-03T07:42:26","date_gmt":"2020-06-03T05:42:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2"},"modified":"2020-06-03T07:42:26","modified_gmt":"2020-06-03T05:42:26","slug":"devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devoxx-uk-kubernetes-v-prodakshene-blue-green-deployment-avtomasshtabirovanie-i-avtomatizacziya-razvertyvaniya-chast-2","title":{"rendered":"DEVOXX UK. Kubernetes in der Produktion: Blue\/Green Deployment, Auto-Scaling und Automatisierung von Deployments. Teil 2.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kubernetes ist ein hervorragendes Werkzeug zum Starten von Docker-Containern in einer clusterbasierten Produktionsumgebung. Es gibt jedoch Aufgaben, die Kubernetes nicht l\u00f6sen kann. Bei h\u00e4ufigen Bereitstellungen in der Produktionsumgebung ben\u00f6tigen wir ein vollst\u00e4ndig automatisiertes Blue\/Green Deployment, um Ausfallzeiten in diesem Prozess zu vermeiden, wobei auch externe HTTP-Anfragen verarbeitet und SSL-Uploads durchgef\u00fchrt werden m\u00fcssen. Dies erfordert eine Integration mit einem Lastenausgleichssystem, wie zum Beispiel ha-proxy. Ein weiteres Anliegen ist das halbautomatische Scaling des Kubernetes-Clusters in einer Cloud-Umgebung, wie zum Beispiel das teilweise Reduzieren der Clustergr\u00f6\u00dfe w\u00e4hrend der Nacht.<\/p>\n

Obwohl Kubernetes diese Funktionen nicht direkt \u201eout of the box\u201c bietet, stellt es eine API zur Verf\u00fcgung, die zur L\u00f6sung solcher Aufgaben genutzt werden kann. Werkzeuge f\u00fcr automatisiertes Blue\/Green Deployment und das Skalieren von Kubernetes-Clustern wurden im Rahmen des Cloud RTI-Projekts entwickelt, das auf Open-Source basiert.<\/p>\n

In diesem Artikel zur Videoentzifferung erfahren Sie, wie Sie Kubernetes zusammen mit anderen Open-Source-Komponenten einrichten, um eine produktionsbereite Umgebung zu schaffen, die ohne Ausfallzeiten im Produktionsbetrieb Code von einem git commit verarbeitet.<\/p>\n

\"DEVOXX<\/a><\/noindex><\/p>\n

DEVOXX UK. Kubernetes in der Produktion: Blue\/Green Deployment, automatisches Skalieren und Bereitstellungsautomatisierung. Teil 1<\/a><\/noindex><\/p>\n

Sobald Sie Zugang zu Ihren Anwendungen aus der Au\u00dfenwelt erhalten haben, k\u00f6nnen Sie mit der vollst\u00e4ndigen Automatisierung beginnen. Das bedeutet, dass Sie die Automatisierung so weit vorantreiben, dass Sie einen git commit ausf\u00fchren k\u00f6nnen und sicher sein k\u00f6nnen, dass dieser git commit in der Produktion endet. Nat\u00fcrlich m\u00f6chten wir bei der Umsetzung dieser Schritte und beim Deployment keine Ausfallzeiten erleben. Somit beginnt jede Automatisierung in Kubernetes mit der API. <\/p>\n

\"DEVOXX
\n
\nKubernetes ist nicht das Tool, das man produktiv \"out of the box\" verwenden kann. Nat\u00fcrlich k\u00f6nnen Sie es so tun, kubectl verwenden und dergleichen, aber die API ist das Interessanteste und N\u00fctzlichste an dieser Plattform. Indem Sie die API als Funktionsset nutzen, k\u00f6nnen Sie nahezu alles, was Sie in Kubernetes tun m\u00f6chten, ansteuern. Kubectl selbst verwendet ebenfalls die REST-API. <\/p>\n

Es handelt sich um eine REST-API, sodass Sie jede beliebige Sprache und jedes Tool zur Arbeit mit dieser API verwenden k\u00f6nnen, aber benutzerdefinierte Bibliotheken werden Ihnen das Leben erheblich erleichtern. Mein Team hat zwei solche Bibliotheken geschrieben: eine f\u00fcr Java \/ OSGi und eine f\u00fcr Go. Letztere wird nicht h\u00e4ufig verwendet, aber diese n\u00fctzlichen Dinge stehen Ihnen auf jeden Fall zur Verf\u00fcgung. Sie sind Teil eines teilweise lizenzierten Open-Source-Projekts. Es gibt zahlreiche solcher Bibliotheken f\u00fcr verschiedene Sprachen, sodass Sie die am besten geeigneten ausw\u00e4hlen k\u00f6nnen. <\/p>\n

\"DEVOXX
\n
\nBevor Sie mit der Automatisierung der Bereitstellung beginnen, ist es entscheidend, sicherzustellen, dass dieser Prozess keine Ausfallzeiten verursacht. Unsere Team f\u00fchrt beispielsweise Produktionsbereitstellungen tags\u00fcber durch, wenn die Nutzung der Anwendungen am h\u00f6chsten ist. Daher ist es von gro\u00dfer Bedeutung, Verz\u00f6gerungen in diesem Prozess zu vermeiden. Um Ausfallzeiten zu verhindern, stehen zwei Methoden zur Verf\u00fcgung: Blue\/Green-Bereitstellung oder Rolling Update. Letzteres bedeutet, dass, wenn Sie 5 Replikate Ihrer Anwendung haben, diese nacheinander aktualisiert werden. Diese Methode funktioniert ausgezeichnet, eignet sich jedoch nicht, wenn w\u00e4hrend der Bereitstellung verschiedene Versionen der Anwendung gleichzeitig laufen. In diesem Fall k\u00f6nnte das Benutzerinterface aktualisiert werden, w\u00e4hrend das Backend noch mit der alten Version arbeitet, was zu einer Unterbrechung des Anwendungsbetriebs f\u00fchren w\u00fcrde. Daher gestaltet sich die Programmierung unter diesen Bedingungen als herausfordernd. <\/p>\n

Das ist einer der Gr\u00fcnde, warum wir Blue\/Green-Deployment bevorzugen, um die Bereitstellung unserer Anwendungen zu automatisieren. Bei dieser Methode m\u00fcssen Sie sicherstellen, dass zu einem bestimmten Zeitpunkt nur eine Version der Anwendung aktiv ist. <\/p>\n

Der Mechanismus des Blue\/Green-Deployments funktioniert folgenderma\u00dfen: Wir erhalten den Datenverkehr f\u00fcr unsere Anwendungen \u00fcber HA-Proxy, der ihn an die laufenden Replikate der Anwendung mit derselben Version weiterleitet. <\/p>\n

Wenn ein neues Deployment stattfindet, verwenden wir Deployer, dem die neuen Komponenten zur Verf\u00fcgung gestellt werden, und dieser f\u00fchrt das Deployment der neuen Version durch. Das Deployment einer neuen Version der Anwendung bedeutet, dass ein neuer Satz von Replikaten ''hochgefahren'' wird, nachdem diese Replikate der neuen Version in einem separaten, neuen Pod gestartet werden. Allerdings wei\u00df HA-Proxy noch nichts \u00fcber diese und leitet vorerst keine Arbeitslast an sie weiter.<\/p>\n

Daher ist es zun\u00e4chst erforderlich, die neuen Versionen mit einem Health-Check zu \u00fcberpr\u00fcfen, um sicherzustellen, dass die Replikate bereit sind, die Last zu \u00fcbernehmen.<\/p>\n

\"DEVOXX
\n
\nAlle Bereitstellungskomponenten sollten eine Form von Health Check unterst\u00fctzen. Dies kann ein ganz einfacher HTTP-Check sein, bei dem Sie einen Statuscode von 200 erhalten, oder ein tiefgehenderer Check, bei dem Sie die Verbindung der Replikate zur Datenbank und zu anderen Diensten sowie die Stabilit\u00e4t der Verbindungen in der dynamischen Umgebung \u00fcberpr\u00fcfen. Dabei wird sichergestellt, dass alles gestartet wird und korrekt funktioniert. Dieser Prozess kann recht komplex sein. <\/p>\n

\"DEVOXX
\n
\nSobald das System die Funktionsf\u00e4higkeit aller aktualisierten Replikate best\u00e4tigt hat, wird der Deployer die Konfiguration aktualisieren und das passende confd \u00fcbergeben, welches ha-proxy neu konfiguriert. <\/p>\n

\"DEVOXX
\n
\nErst danach wird der Verkehr auf den Pod mit den Replikaten der neuen Version geleitet, w\u00e4hrend der alte Pod verschwindet. <\/p>\n

\"DEVOXX
\n
\nDieser Mechanismus ist kein spezifisches Merkmal von Kubernetes. Das Konzept des Blue\/Green Deployments gibt es schon lange, und es hat immer einen Lastenausgleich verwendet. Zun\u00e4chst leiten Sie den gesamten Verkehr zur alten Version der Anwendung, und nach dem Update leiten Sie ihn vollst\u00e4ndig zur neuen Version um. Dieses Prinzip wird nicht nur in Kubernetes angewandt.<\/p>\n

Jetzt pr\u00e4sentiere ich Ihnen eine neue Bereitstellungskomponente \u2013 Deployer, die die Funktionsf\u00e4higkeit \u00fcberpr\u00fcft, den Proxy neu konfiguriert und so weiter. Dies ist ein Konzept, das nicht mit der Au\u00dfenwelt verbunden ist und innerhalb von Kubernetes existiert. Ich werde Ihnen zeigen, wie Sie Ihr eigenes Deployer-Konzept mit Open-Source-Tools erstellen k\u00f6nnen. <\/p>\n

Das erste, was Deployer tut, ist die Erstellung eines Replication Controllers (RC) unter Verwendung der Kubernetes-API. Diese API erstellt Pods und Services f\u00fcr die weitere Bereitstellung, also einen komplett neuen Cluster f\u00fcr unsere Anwendungen. Sobald der RC sichergestellt hat, dass die Replikate gestartet wurden, f\u00fchrt er einen Health-Check durch. Daf\u00fcr wird im Deployer der Befehl GET \/health verwendet. Dieser Befehl startet die entsprechenden \u00dcberpr\u00fcfungskomponenten und \u00fcberpr\u00fcft alle Elemente, die den Betrieb des Clusters gew\u00e4hrleisten. <\/p>\n

\"DEVOXX
\n
\nNachdem alle Pods ihren \"Status\" gemeldet haben, erstellt Deployer ein neues Konfigurationselement: einen verteilten etcd-Speicher, der innerhalb von Kubernetes verwendet wird, unter anderem zur Speicherung der Konfiguration des Lastenausgleichs. Wir speichern Daten in etcd, und ein kleines Tool namens confd \u00fcberwacht etcd auf neue Daten. <\/p>\n

Wenn es \u00c4nderungen in der urspr\u00fcnglichen Konfiguration entdeckt, wird eine neue Konfigurationsdatei generiert und an den ha-proxy \u00fcbergeben. In diesem Fall wird der ha-proxy neu gestartet, ohne dass Verbindungen verloren gehen, und leitet die Last an die neuen Services weiter, die die neue Version unserer Anwendungen unterst\u00fctzen. <\/p>\n

\"DEVOXX
\n
\nWie Sie sehen, ist trotz der Vielzahl an Komponenten nichts kompliziert. Sie m\u00fcssen lediglich mehr Aufmerksamkeit auf die API und etcd richten. Ich m\u00f6chte Ihnen \u00fcber den Open-Source-Deploy-Manager berichten, den wir selbst verwenden \u2013 den Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nEs ist ein Tool zur Orchestrierung von Kubernetes-Bereitstellungen mit Funktionen wie: <\/p>\n