virtuellen Servern<\/a>, wir haben Ansible verwendet, bei dem die Konfigurationen im selben Repository gespeichert waren. F\u00fcr die meisten Entwickler war es jedoch etwas komplizierter, damit zu arbeiten. Hier ist das Volumen an Konfigurationen und Code, den Sie hinzuf\u00fcgen m\u00fcssen, um einen Service bereitzustellen, deutlich geringer geworden. Zudem ist es f\u00fcr DevOps sehr einfach, Anpassungen vorzunehmen oder \u00c4nderungen vorzunehmen. Im Falle von Updates, beispielsweise auf eine neue Version von Nomad, k\u00f6nnen sie alle Betriebsdateien, die sich am gleichen Speicherort befinden, massenhaft aktualisieren.<\/li>\n<\/ol>\n\nAber wir sind auch auf einige Nachteile gesto\u00dfen: <\/p>\n
Es stellte sich heraus, dass wir nicht die nahtlosen Deployments erreichen konnten <\/b>bei Nomad. Beim Rollout von Containern aus unterschiedlichen Umgebungen konnte es passieren, dass der Container bereits gestartet war, und Nomad ihn als bereit empfand, Verkehr zu akzeptieren. Dies geschah, bevor die Anwendung in ihm wirklich gestartet war. Aus diesem Grund begann das System kurzfristig, 500er-Fehler auszugeben, da der Verkehr auf einen Container geleitet wurde, der noch nicht bereit war, ihn zu akzeptieren. <\/p>\n
Wir stie\u00dfen auf einige Bugs<\/b>. Der wesentliche Fehler besteht darin, dass Nomad gro\u00dfe Cluster nicht gut verwalten kann, insbesondere wenn Sie viele Systeme und Container haben. Wenn Sie einen der Server, der Teil des Nomad-Clusters ist, au\u00dfer Betrieb nehmen m\u00f6chten, gibt es eine betr\u00e4chtliche Wahrscheinlichkeit, dass der Cluster nicht stabil bleibt und auseinanderf\u00e4llt. Einige Container k\u00f6nnen beispielsweise abst\u00fcrzen und sich nicht wiederherstellen lassen \u2013 das wird Ihnen teuer zu stehen kommen, wenn all Ihre Systeme im Produktionsumfeld tats\u00e4chlich im Nomad-Cluster verwaltet werden. <\/p>\n
Deshalb haben wir beschlossen, \u00fcber die n\u00e4chsten Schritte nachzudenken. Zu diesem Zeitpunkt wurde uns viel klarer, was wir erreichen m\u00f6chten. Insbesondere streben wir nach Verl\u00e4sslichkeit, zus\u00e4tzliche Funktionen im Vergleich zu Nomad und ein ausgereifteres, stabileres System. <\/p>\n
In diesem Zusammenhang fiel unsere Wahl auf Kubernetes, die beliebteste Plattform zur Bereitstellung von Clustern. Besonders angesichts der Tatsache, dass die Gr\u00f6\u00dfe und Anzahl unserer Container recht gro\u00df war. F\u00fcr diese Zwecke erschien uns Kubernetes als das passendste System von den M\u00f6glichkeiten, die wir in Betracht ziehen konnten. <\/p>\n
Umstieg auf Kubernetes<\/h1>\n \nIch m\u00f6chte Ihnen kurz die grundlegenden Konzepte von Kubernetes erkl\u00e4ren und wie sie sich von Nomad unterscheiden. <\/p>\n
Pod<\/b> ist eine Gruppe von einem oder mehreren Containern, die immer zusammen gestartet werden. Sie arbeiten, als ob sie immer auf einer einzigen virtuellen Maschine laufen. Sie sind \u00fcber die IP-Adresse 127.0.0.1 auf verschiedenen Ports miteinander verbunden. <\/p>\n
Nehmen wir an, Sie haben eine PHP-Anwendung, die aus nginx und php-fpm besteht \u2013 eine klassische Architektur. Wahrscheinlich m\u00f6chten Sie, dass die nginx- und php-fpm-Container immer zusammen vorhanden sind. Kubernetes erm\u00f6glicht dies, indem Sie sie als ein gemeinsames Pod beschreiben. Genau das konnten wir mit Nomad nicht erreichen.<\/p>\n
Das zweite Konzept ist deployment<\/b>. Ein Pod ist an sich eine fl\u00fcchtige Entit\u00e4t, sie wird gestartet und verschwindet. M\u00f6chten Sie zuerst alle Ihre vorherigen Container vernichten und dann sofort neue Versionen starten, oder m\u00f6chten Sie diese schrittweise ausrollen? F\u00fcr diesen Prozess ist das Konzept des Deployments verantwortlich. Es beschreibt, wie Sie Ihre Pods bereitstellen, in welcher Anzahl und wie Sie sie aktualisieren. <\/p>\n
Das dritte Konzept ist service<\/b>. Ihr Service ist im Grunde Ihr System, das bestimmten Datenverkehr annimmt und diesen dann an einen oder mehrere Pods weiterleitet, die zu Ihrem Service geh\u00f6ren. Das hei\u00dft, er erm\u00f6glicht es, zu definieren, dass der gesamte eingehende Datenverkehr f\u00fcr einen bestimmten Service mit einem bestimmten Namen auf genau diese Pods geleitet werden soll. Dabei sorgt er f\u00fcr eine effiziente Lastenverteilung. Das bedeutet, Sie k\u00f6nnen zwei Pods Ihrer Anwendung betreiben, und der gesamte eingehende Datenverkehr wird gleichm\u00e4\u00dfig auf die entsprechenden Pods verteilt.<\/p>\n
Und das vierte grundlegende Konzept \u2014 Ingress<\/b>. Dies ist ein Service, der in einem Kubernetes-Cluster ausgef\u00fchrt wird. Er fungiert als externer Lastenausgleich, der alle Anfragen entgegennimmt. \u00dcber die API von Kubernetes kann Ingress flexibel bestimmen, wohin diese Anfragen geleitet werden sollen. Sie k\u00f6nnen beispielsweise festlegen, dass alle Anfragen an diesen Host und eine bestimmte URL an diesen Service gesendet werden. Und Anfragen, die an diesen Host und eine andere URL kommen, leiten wir an einen anderen Service weiter. <\/p>\n
Das Beste aus Sicht eines App-Entwicklers ist, dass Sie alles selbst verwalten k\u00f6nnen. Mit der Konfiguration von Ingress k\u00f6nnen Sie den gesamten Verkehr, der auf eine bestimmte API trifft, an separate Container weiterleiten, die zum Beispiel in Go geschrieben sind. Der Verkehr, der auf dieselbe Domain, aber auf eine andere URL trifft, kann an Container, die in PHP geschrieben sind und viel Logik enthalten, weitergeleitet werden, diese sind jedoch nicht sehr leistungsf\u00e4hig.<\/p>\n
Wenn man all diese Konzepte mit Nomad vergleicht, kann man sagen, dass die ersten drei Konzepte zusammen als Service betrachtet werden. Das letzte Konzept fehlt jedoch in Nomad. Stattdessen haben wir einen externen Lastenausgleich verwendet: Das kann haproxy, nginx, nginx+ usw. sein. Im Fall von Kubernetes ben\u00f6tigen Sie dieses zus\u00e4tzliche Konzept nicht. Wenn Sie sich jedoch Ingress von innen ansehen, handelt es sich entweder um nginx, haproxy oder traefik, aber integriert in Kubernetes. <\/p>\n
Alle von mir beschriebenen Konzepte sind im Grunde genommen Ressourcen, die innerhalb eines Kubernetes-Clusters existieren. Zur Beschreibung dieser Ressourcen wird im Kubernetes-Umfeld das YAML-Format verwendet, das leserlicher und vertrauter ist als die HCL-Dateien bei Nomad. Strukturtechnisch beschreiben sie im Fall eines Pods dasselbe. Sie geben an: Ich m\u00f6chte diese Pods dorthin bereitstellen, mit diesen Images, in dieser Anzahl. <\/p>\n
Wichtige Konzepte in Helm<\/h1>\n \nHelm ist von KISS ist in Shell geschrieben und umfasst etwa 500 Zeilen Code. Alle Pakete werden aus Quelltexten erstellt. Die Abh\u00e4ngigkeiten werden ber\u00fccksichtigt und zus\u00e4tzliche Patches k\u00f6nnen angewendet werden.<\/b> f\u00fcr Kubernetes. Es \u00e4hnelt der Funktionsweise von Paketmanagern in Programmiersprachen. Damit k\u00f6nnen Sie einen Service speichern, der beispielsweise aus einem nginx-Deployment, einem php-fpm-Deployment, einer Konfiguration f\u00fcr Ingress und ConfigMaps (dies ist ein Element, das es Ihnen erm\u00f6glicht, Umgebungsvariablen und andere Parameter f\u00fcr Ihr System festzulegen) besteht, in Form von sogenannten Charts. l\u00e4uft auf Kubernetes<\/b>. Das hei\u00dft, es handelt sich nicht um ein separates System, sondern einfach um einen weiteren Service, der innerhalb des Clusters ausgef\u00fchrt wird. Sie interagieren \u00fcber die API mit ihm durch einen Konsolenbefehl. Der Vorteil und die Sch\u00f6nheit dabei ist, dass selbst wenn Helm abst\u00fcrzt oder Sie es aus dem Cluster entfernen, Ihre Services nicht verschwinden, da Helm im Grunde nur f\u00fcr den Start des Systems zust\u00e4ndig ist. F\u00fcr die Funktionsf\u00e4higkeit und den Zustand der Dienste ist dann Kubernetes selbst verantwortlich. <\/p>\n
Au\u00dferdem haben wir verstanden, dass Templating<\/b>, das wir zuvor selbst durch die Integration von Jinja in unsere Konfigurationen durchf\u00fchren mussten, eine der Hauptfunktionen von Helm darstellt. Alle Konfigurationen, die Sie f\u00fcr Ihre Systeme erstellen, werden in Helm in Form von Vorlagen gespeichert, die ein wenig wie Jinja aussehen, tats\u00e4chlich jedoch die Templating-Sprache Go verwenden, auf der Helm, ebenso wie Kubernetes, geschrieben ist. <\/p>\n
Helm f\u00fcgt uns noch einige zus\u00e4tzliche Konzepte hinzu. <\/p>\n
Chart<\/b> \u2014 das ist die Beschreibung Ihres Services. In anderen Paketmanagern w\u00fcrde man es als Paket, Bundle oder etwas \u00c4hnliches bezeichnen. Hier wird es Chart genannt. <\/p>\n
Values <\/b>\u2013 das sind die Variablen, die Sie f\u00fcr den Zusammenbau Ihrer Konfigurationen aus den Vorlagen verwenden m\u00f6chten. <\/p>\n
Release<\/b>. Bei jedem Deployment \u00fcber Helm erh\u00e4lt der Service eine inkrementelle Versionsnummer. Helm merkt sich die Konfiguration des Services aus der vorherigen und der \u00fcbern\u00e4chsten Version und so weiter. Wenn ein Rollback erforderlich ist, gen\u00fcgt es, den Befehl helm rollback mit der Angabe der vorherigen Version auszuf\u00fchren. Selbst wenn die entsprechende Konfiguration in Ihrem Repository zum Zeitpunkt des Rollbacks nicht verf\u00fcgbar ist, beh\u00e4lt Helm trotzdem die Informationen und stellt Ihre Systemkonfiguration auf den Zustand des vorherigen Releases zur\u00fcck. <\/p>\n
Wenn wir Helm verwenden, verwandeln sich die \u00fcblichen Konfigurationen f\u00fcr Kubernetes ebenfalls in Templates, in denen Variablen, Funktionen und bedingte Operatoren verwendet werden k\u00f6nnen. So k\u00f6nnen Sie die Konfiguration Ihres Services je nach Umgebung erstellen.<\/p>\n
Obwohl wir in den Konfigurationsdateien keine wirklich sensiblen Daten speichern, wie zum Beispiel Datenbankpassw\u00f6rter, die als Secrets in Kubernetes gespeichert werden, gibt es dennoch einzelne Dinge, auf die wir nicht allen Zugriff gew\u00e4hren m\u00f6chten. Daher ist der Zugriff auf das Repository \u201edeploy\u201c st\u00e4rker eingeschr\u00e4nkt, w\u00e4hrend das Repository \u201ehelm\u201c lediglich die Beschreibung des Services enth\u00e4lt. Aus diesem Grund kann der Zugang zu diesem Repository sicher einem weiteren Personenkreis gew\u00e4hrt werden. <\/p>\n
Da wir nicht nur Produktionsumgebungen, sondern auch andere Umgebungen haben, k\u00f6nnen wir durch diese Trennung unsere Helm-Charts wiederverwenden, um Dienste nicht nur in der Produktion, sondern beispielsweise auch in der QA-Umgebung bereitzustellen. Sogar um sie lokal zu starten, verwenden wir Minikube<\/i> \u2014 das ist ein Werkzeug f\u00fcr das lokale Erstellen von Kubernetes. <\/p>\n
Innerhalb jedes Repositories haben wir eine Trennung in separate Verzeichnisse f\u00fcr jeden Dienst belassen. Das hei\u00dft, in jedem Verzeichnis befinden sich die Vorlagen, die zu dem entsprechenden Chart geh\u00f6ren und die Ressourcen beschreiben, die ben\u00f6tigt werden, um unser System zu starten. Im Repository \u201edeploy\u201c haben wir nur die Umgebungsvariablen gelassen. In diesem Fall haben wir keine Jinja-Templates verwendet, weil Helm selbst von Haus aus eine Template-Engine bietet \u2013 das ist eine seiner Hauptfunktionen. <\/p>\n
Wir haben ein Skript f\u00fcr den Deployment-Prozess \u2013 deploy.sh \u2013 bereitgestellt, das das Starten von Deployments mit Helm vereinfacht und standardisiert. F\u00fcr jeden, der bereitstellen m\u00f6chte, sieht die Deploy-Oberfl\u00e4che genau gleich aus wie bei einem Deployment \u00fcber Nomad. Das gleiche deploy.sh, der Name Ihres Dienstes und das Ziel, wohin Sie es bereitstellen m\u00f6chten. Dadurch wird Helm im Hintergrund ausgef\u00fchrt. Dieses sammelt die Konfigurationsdateien aus den Vorlagen, setzt die erforderlichen Werte aus den values-Dateien ein und f\u00fchrt dann das Deployment in Kubernetes durch. <\/p>\n
Fazit<\/h1>\n \nDer Kubernetes-Dienst wirkt komplexer als Nomad. <\/p>\n
Bei der Migration haben wir festgestellt, dass Kubernetes alle Funktionen von Nomad bietet, das wir zuvor verwendet haben, und dar\u00fcber hinaus viele neue M\u00f6glichkeiten hinzuf\u00fcgt. Es ist erweiterbar durch Plugins und durch benutzerdefinierte Ressourcenarten. Das bedeutet, dass Sie nicht nur etwas verwenden k\u00f6nnen, das standardm\u00e4\u00dfig mit Kubernetes geliefert wird, sondern auch Ihre eigenen Ressourcen und Dienste erstellen k\u00f6nnen, die diese Ressourcen abfragen. Dies er\u00f6ffnet zus\u00e4tzliche Erweiterungsm\u00f6glichkeiten f\u00fcr Ihr System, ohne dass eine Neuinstallation von Kubernetes erforderlich ist und ohne \u00c4nderungen notwendig sind. <\/p>\n
Ein Beispiel f\u00fcr eine solche Nutzung ist Prometheus, das innerhalb unseres Kubernetes-Clusters l\u00e4uft. Um mit dem Sammeln von Metriken eines bestimmten Dienstes zu beginnen, m\u00fcssen wir dem Dienst eine zus\u00e4tzliche Ressource hinzuf\u00fcgen, die als Service-Monitor bezeichnet wird. Da Prometheus in der Lage ist, benutzerdefinierte Ressourcentypen zu lesen, w\u00e4hrend es in Kubernetes l\u00e4uft, beginnt es automatisch, Metriken von neuen Systemen zu sammeln. Das ist sehr praktisch. <\/p>\n
Die erste Bereitstellung, die wir in Kubernetes durchgef\u00fchrt haben, fand im M\u00e4rz 2018 statt. Seitdem hatten wir nie Probleme damit. Es l\u00e4uft stabil ohne nennenswerte Fehler. Zudem k\u00f6nnen wir es weiter ausbauen. Aktuell reichen uns die M\u00f6glichkeiten, die es bietet, und wir sind sehr zufrieden mit den Entwicklungsgeschwindigkeiten von Kubernetes. Momentan befinden sich \u00fcber 3000 Container in Kubernetes. Der Cluster l\u00e4uft auf mehreren Nodes. Dabei ist er verwaltbar, stabil und sehr kontrollierbar.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Video](\"https:\/\/img.youtube.com\/vi\/oqrb7dWECSo\/hqdefault.jpg\")
\r\n