{"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, Autoskalierung 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 bew\u00e4ltigen 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, bei dem auch externe HTTP-Anfragen bearbeitet und SSL-Entladungen durchgef\u00fchrt werden m\u00fcssen. Dies erfordert die Integration mit einem Lastenausgleich, wie zum Beispiel ha-proxy. Eine weitere Herausforderung ist das halbautomatische Skalieren des Kubernetes-Clusters in einer Cloud-Umgebung, beispielsweise das teilweises Reduzieren des Clusters zu Nachtzeiten.<\/p>\n

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

In diesem Artikel, einer Video-Transkription, wird erkl\u00e4rt, wie man Kubernetes zusammen mit anderen Open-Source-Komponenten f\u00fcr eine produktionsbereite Umgebung einrichtet, die ohne Ausfallzeiten in der Produktion den Code aus einem git commit aufnimmt.<\/p>\n

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

DEVOXX UK. Kubernetes in der Produktion: Blue\/Green Deployment, Auto-Scaling und Automatisierung der Bereitstellung. Teil 1<\/a><\/noindex><\/p>\n

Nachdem Sie also Zugriff auf Ihre Anwendungen aus der Au\u00dfenwelt haben, k\u00f6nnen Sie mit der vollst\u00e4ndigen Automatisierung beginnen, d.h. sie auf den Stand zu bringen, bei dem ein git commit durchgef\u00fchrt werden kann, und sicherzustellen, dass dieser git commit in der Produktion endet. Nat\u00fcrlich m\u00f6chten wir bei der Durchf\u00fchrung dieser Schritte, insbesondere beim Deployment, keine Ausfallzeiten erleben. Daher beginnt jede Automatisierung in Kubernetes mit der API. <\/p>\n

\"DEVOXX
\n
\nKubernetes ist nicht das Werkzeug, das man \u201edirectly out of the box\u201c produktiv nutzen kann. Nat\u00fcrlich k\u00f6nnen Sie das tun, kubectl verwenden usw., aber die API ist dennoch das interessanteste und n\u00fctzlichste an dieser Plattform. Wenn Sie die API als Funktionsb\u00fcndel nutzen, k\u00f6nnen Sie praktisch auf alles zugreifen, was Sie in Kubernetes tun m\u00f6chten. Auch kubectl selbst nutzt die REST API. <\/p>\n

Dies ist ein REST-API, sodass Sie f\u00fcr die Arbeit mit diesem API beliebige Programmiersprachen und Werkzeuge verwenden k\u00f6nnen. Benutzerdefinierte Bibliotheken erleichtern Ihnen jedoch das Leben erheblich. Mein Team hat zwei solche Bibliotheken geschrieben: eine f\u00fcr Java \/ OSGi und eine f\u00fcr Go. Letztere wird nicht h\u00e4ufig verwendet, aber in jedem Fall stehen Ihnen diese n\u00fctzlichen Tools zur Verf\u00fcgung. Sie sind Teil eines teilweise lizenzierten Open-Source-Projekts. Es gibt viele 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, m\u00fcssen Sie sicherstellen, dass dieser Prozess nicht unterbrochen wird. Zum Beispiel f\u00fchrt unser Team die Produktionsbereitstellung mitten am Tag durch, wenn die Nutzer die Anwendungen am meisten nutzen, daher ist es sehr wichtig, Verz\u00f6gerungen in diesem Prozess zu vermeiden. Um Ausfallzeiten zu vermeiden, gibt es zwei Methoden: Blue\/Green-Deployment oder Rolling Update. Im letzteren Fall, wenn Sie 5 Replikate der Anwendung haben, werden sie nacheinander aktualisiert. Diese Methode funktioniert gut, ist jedoch nicht geeignet, wenn w\u00e4hrend der Bereitstellung verschiedene Versionen der Anwendung gleichzeitig ausgef\u00fchrt werden. In diesem Fall k\u00f6nnen Sie die Benutzeroberfl\u00e4che aktualisieren, w\u00e4hrend das Backend mit der alten Version arbeitet, was zu einem Ausfall der Anwendung f\u00fchrt. Daher ist das Arbeiten unter solchen Bedingungen aus programmiertechnischer Sicht ziemlich schwierig. <\/p>\n

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

Der Blue\/Green-Deployment-Mechanismus funktioniert folgenderma\u00dfen. Wir erhalten den Datenverkehr f\u00fcr unsere Anwendungen \u00fcber ha-proxy, der ihn an die laufenden Replikate der Anwendung derselben Version weiterleitet. <\/p>\n

Wenn ein neues Deployment erfolgt, verwenden wir Deployer, dem neue Komponenten bereitgestellt werden, und er f\u00fchrt das Deployment der neuen Version durch. Das Deployment der neuen Version der Anwendung bedeutet, dass ein neuer Satz an Replikaten \u201ehochgefahren\u201c wird, nachdem diese Replikate der neuen Version in einem separaten, neuen Pod gestartet werden. Ha-proxy wei\u00df jedoch nichts dar\u00fcber und leitet bisher keinen Arbeitsaufwand an sie weiter.<\/p>\n

Deshalb ist es zun\u00e4chst notwendig, die Funktionsf\u00e4higkeit der neuen Versionen durch Health Checking zu \u00fcberpr\u00fcfen, um sicherzustellen, dass die Replikate bereit sind, die Last zu bedienen.<\/p>\n

\"DEVOXX
\n
\nAlle Deployment-Komponenten m\u00fcssen irgendeine Form von Health Check unterst\u00fctzen. Dies kann eine sehr einfache HTTP-Pr\u00fcfung sein, bei der Sie einen Statuscode 200 erhalten, oder eine tiefere Pr\u00fcfung, bei der Sie die Verbindung der Replikate zur Datenbank und anderen Diensten \u00fcberpr\u00fcfen, die Stabilit\u00e4t der Verbindungen der dynamischen Umgebung, und ob alles richtig gestartet und funktioniert. Dieser Prozess kann ziemlich komplex sein. <\/p>\n

\"DEVOXX
\n
\nNachdem das System die Funktionsf\u00e4higkeit aller aktualisierten Replikate sichergestellt hat, wird Deployer die Konfiguration aktualisieren und das richtige confd \u00fcbergeben, das ha-proxy neu konfiguriert. <\/p>\n

\"DEVOXX
\n
\nErst danach wird der Verkehr zu dem 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 existiert schon eine geraume Zeit und hat immer einen Lastenausgleich verwendet. Zuerst leiten Sie den gesamten Verkehr zur alten Version der Anwendung, und nach dem Update wechseln Sie vollst\u00e4ndig zur neuen Version. Dieses Prinzip wird nicht nur in Kubernetes verwendet.<\/p>\n

Jetzt m\u00f6chte ich Ihnen das neue Deployment-Komponente \u2013 Deployer \u2013 vorstellen, das die Funktionsf\u00e4higkeit \u00fcberpr\u00fcft, das Proxy neu konfiguriert und so weiter. Dies ist ein Konzept, das sich nicht auf die Au\u00dfenwelt bezieht 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 der Deployer macht, ist die Erstellung eines Replication Controller (RC) mit der Kubernetes-API. Diese API erstellt Pods und Dienste f\u00fcr die weitere Bereitstellung, d.h. sie erstellt einen v\u00f6llig neuen Cluster f\u00fcr unsere Anwendungen. Sobald der RC sicherstellt, dass die Replikate gestartet wurden, f\u00fchrt er einen Health-Check durch. F\u00fcr dies wird im Deployer der Befehl GET \/health verwendet. Dadurch werden die entsprechenden Pr\u00fcfkomponenten gestartet und alle Elemente \u00fcberpr\u00fcft, die den Betrieb des Clusters gew\u00e4hrleisten. <\/p>\n

\"DEVOXX
\n
\nSobald alle Pods \u00fcber ihren \u00abGesundheitszustand\u00bb berichtet haben, erstellt der Deployer ein neues Konfigurationselement \u2013 das verteilte Speicher etcd, das innerhalb von Kubernetes verwendet wird, einschlie\u00dflich zur Speicherung der Konfiguration des Load Balancers. Wir schreiben Daten in etcd, und ein kleines Tool namens confd \u00fcberwacht etcd auf neue Daten. <\/p>\n

Wenn es \u00c4nderungen an der urspr\u00fcnglichen Konfiguration entdeckt, generiert es eine neue Einstellungsdatei und \u00fcbergibt diese an ha-proxy. In diesem Fall wird ha-proxy ohne Verlust von Verbindungen neu gestartet und leitet die Last an neue Dienste weiter, die den Betrieb der neuen Version unserer Anwendungen gew\u00e4hrleisten. <\/p>\n

\"DEVOXX
\n
\nWie Sie sehen, gibt es trotz der Vielzahl von Komponenten nichts Kompliziertes. Sie m\u00fcssen nur mehr Aufmerksamkeit der API und etcd schenken. Ich m\u00f6chte Ihnen von dem Open-Source-Deployer erz\u00e4hlen, den wir selbst verwenden \u2013 dem Amdatu Kubernetes Deployer.<\/p>\n

\"DEVOXX
\n
\nDies ist ein Tool zur Orchestrierung von Kubernetes-Bereitstellungen, das folgende Funktionen bietet: <\/p>\n