virtuellen Servern<\/a>deployten, verwendeten wir Ansible, in dem die Konfigurationen im selben Repository lagen. Dennoch war es f\u00fcr die meisten Entwickler etwas komplizierter, damit zu arbeiten. Hier wurde das Volumen an Konfigurationen und Code, den Sie hinzuf\u00fcgen m\u00fcssen, um einen Service zu deployen, deutlich kleiner. Au\u00dferdem ist es f\u00fcr DevOps sehr einfach, es zu \u00e4ndern oder zu aktualisieren. Im Fall von \u00dcberg\u00e4ngen, zum Beispiel bei einer neuen Version von Nomad, k\u00f6nnen sie einfach alle operativen Dateien, die an derselben Stelle liegen, massenhaft aktualisieren.<\/li>\n<\/ol>\n\nAber wir sind auch auf einige Nachteile gesto\u00dfen: <\/p>\n
Es stellte sich heraus, dass wir nicht nahtlose Deployments <\/b>im Fall von Nomad erreichen konnten. Beim Rollout von Containern aus unterschiedlichen Bedingungen konnte es passieren, dass dieser gestartet wurde und Nomad ihn als bereit f\u00fcr den Datenverkehr ansah. Dies geschah noch bevor die Anwendung darin gestartet wurde. Aus diesem Grund begann das System f\u00fcr kurze Zeit, 500-Fehler auszugeben, weil der Datenverkehr auf einen Container gelenkt wurde, der noch nicht bereit war, ihn zu akzeptieren. <\/p>\n
Wir stie\u00dfen auf einige Bugs<\/b>. Der gravierendste Fehler besteht darin, dass Nomad gro\u00dfe Cluster nicht optimal verwaltet, wenn Sie viele Systeme und Container haben. Wenn Sie einen der Server, der zum Nomad-Cluster geh\u00f6rt, au\u00dfer Betrieb nehmen m\u00f6chten, besteht eine erhebliche Wahrscheinlichkeit, dass sich das Cluster schlecht verh\u00e4lt und auseinanderf\u00e4llt. Ein Teil der Container kann beispielsweise ausfallen und nicht wieder hochgefahren werden \u2014 das k\u00f6nnte Ihnen sp\u00e4ter erheblich kosten, insbesondere wenn sich all Ihre Systeme in der Produktion im Nomad-verwalteten Cluster befinden. <\/p>\n
Deshalb haben wir beschlossen, dar\u00fcber nachzudenken, wo wir als N\u00e4chstes hingehen wollen. Zu diesem Zeitpunkt hatten wir viel klarer erkannt, was wir erreichen m\u00f6chten. Und zwar: Wir w\u00fcnschen uns Zuverl\u00e4ssigkeit, ein paar mehr Funktionen als Nomad bietet, sowie ein reiferes und stabileres System. <\/p>\n
In dieser Hinsicht fiel unsere Wahl auf Kubernetes als die popul\u00e4rste Plattform zum Starten von Clustern. Besonders unter der Voraussetzung, dass die Gr\u00f6\u00dfe und Anzahl unserer Container recht gro\u00df war. F\u00fcr solche Zwecke erschien Kubernetes als das geeignetste System von denen, die wir uns angesehen hatten. <\/p>\n
Der \u00dcbergang zu Kubernetes<\/h1>\n \nIch werde ein wenig \u00fcber die grundlegenden Konzepte von Kubernetes erz\u00e4hlen und wie sie sich von Nomad unterscheiden. <\/p>\n
Pod<\/b> \u2014 es ist eine Gruppe von einem oder mehreren Containern, die immer zusammen gestartet werden. Sie arbeiten, als ob sie immer auf derselben virtuellen Maschine ausgef\u00fchrt werden. Sie sind \u00fcber die IP-Adresse 127.0.0.1 auf verschiedenen Ports miteinander erreichbar. <\/p>\n
Angenommen, Sie haben eine PHP-Anwendung, die aus Nginx und PHP-FPM besteht \u2014 ein klassisches Setup. Wahrscheinlich m\u00f6chten Sie, dass sowohl die Nginx- als auch die PHP-FPM-Container immer gemeinsam laufen. Kubernetes erm\u00f6glicht es, dies zu erreichen, indem man sie als einen gemeinsamen Pod beschreibt. Genau das konnten wir mit Nomad nicht erreichen.<\/p>\n
Das zweite Konzept ist deployment<\/b>. Der Punkt ist, dass ein Pod f\u00fcr sich genommen eine fl\u00fcchtige Sache ist, die startet und verschwindet. Ob Sie zuerst alle Ihre vorherigen Container l\u00f6schen und dann sofort neue Versionen starten m\u00f6chten oder ob Sie sie schrittweise ausrollen wollen \u2014 genau 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 praktisch Ihr System, das einen bestimmten Datenverkehr aufnimmt und ihn dann an einen oder mehrere Pods weiterleitet, die Ihrem Service entsprechen. Das bedeutet, dass Sie sagen k\u00f6nnen, dass der gesamte eingehende Datenverkehr zu einem bestimmten Service mit einem bestimmten Namen an genau diese Pods gesendet werden soll. Gleichzeitig sorgt es f\u00fcr eine Lastverteilung des Datenverkehrs. Sie k\u00f6nnen also zwei Pods Ihrer Anwendung starten, und der gesamte eingehende Datenverkehr wird gleichm\u00e4\u00dfig auf die entsprechenden Pods dieses Services verteilt.<\/p>\n
Und das vierte grundlegende Konzept \u2014 Ingress<\/b>. Dies ist ein Service, der in einem Kubernetes-Cluster gestartet wird. Er fungiert als externer Lastenausgleich, der alle Anfragen entgegennimmt. \u00dcber die API von Kubernetes kann Ingress bestimmen, wohin diese Anfragen gesendet werden m\u00fcssen. Dabei geschieht dies sehr flexibel. Sie k\u00f6nnen sagen, dass alle Anfragen an diesen Host und eine bestimmte URL an diesen Service gesendet werden. Und diese Anfragen, die an diesen Host und eine andere URL kommen, werden an einen anderen Service gesendet. <\/p>\n
Das Tolle aus Sicht des Entwicklers ist, dass Sie all dies selbst verwalten k\u00f6nnen. Indem Sie die Ingress-Konfiguration festlegen, k\u00f6nnen Sie den gesamten Datenverkehr, der an eine bestimmte API kommt, an separate Container weiterleiten, die beispielsweise in Go geschrieben sind. Der Datenverkehr, der an dieselbe Domain, aber an eine andere URL kommt, kann an Container weitergeleitet werden, die in PHP geschrieben sind, wo viel Logik enthalten ist, die jedoch nicht sehr schnell ist.<\/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 ist in Nomad nicht vorhanden. Wir haben an seiner Stelle einen externen Lastenausgleich verwendet: das kann haproxy, nginx, nginx+ usw. sein. Im Fall von Kubernetes brauchen Sie dieses zus\u00e4tzliche Konzept nicht separat einzuf\u00fchren. Wenn man jedoch Ingress n\u00e4her betrachtet, ist es entweder nginx, haproxy oder traefik, aber sozusagen in Kubernetes integriert. <\/p>\n
Alle von mir beschriebenen Konzepte sind im Wesentlichen Ressourcen, die innerhalb eines Kubernetes-Clusters existieren. Zur Beschreibung dieser Ressourcen wird im Cluster das yaml-Format verwendet, das lesbarer und vertrauter ist als HCL-Dateien im Fall von Nomad. Strukturell beschreiben sie jedoch beispielsweise bei Pods dasselbe. Sie sagen \u2013 ich m\u00f6chte solche Pods dorthin deployen, mit solchen Images, in einer bestimmten Anzahl. <\/p>\n
Grundlegende Konzepte in Helm<\/h1>\n \nHelm ist ein Paketmanager<\/b> f\u00fcr Kubernetes. Er funktioniert sehr \u00e4hnlich wie Paketmanager in Programmiersprachen. Sie erm\u00f6glichen es Ihnen, einen Service zu speichern, der beispielsweise aus dem Deployment von nginx, dem Deployment von php-fpm, einer Konfiguration f\u00fcr Ingress, ConfigMaps (dies ist ein Objekt, das es Ihnen erm\u00f6glicht, env und andere Parameter f\u00fcr Ihr System festzulegen) in Form von sogenannten Charts besteht. Dabei arbeitet Helm \u00fcber Kubernetes<\/b>. Das bedeutet, dass es kein separates System ist, sondern einfach ein weiterer Service, der innerhalb des Clusters l\u00e4uft. Sie interagieren mit ihm \u00fcber seine API mittels eines Konsolenbefehls. Sein Komfort und seine Vorz\u00fcge liegen darin, dass selbst wenn Helm abst\u00fcrzt oder Sie ihn aus dem Cluster entfernen, Ihre Services nicht verschwinden, da Helm im Grunde nur dazu dient, das System zu starten. F\u00fcr die Funktionsf\u00e4higkeit und den Zustand der Services ist dann Kubernetes selbst verantwortlich. <\/p>\n
Au\u00dferdem haben wir erkannt, dass die Vorlagenbildung<\/b>, die wir zuvor manuell durch die Integration von Jinja in unsere Konfigurationen durchf\u00fchren mussten, eine der Hauptfunktionen von Helm ist. Alle Konfigurationen, die Sie f\u00fcr Ihre Systeme erstellen, werden in Helm als Vorlagen gespeichert, die ein wenig wie Jinja, aber tats\u00e4chlich mit der Template-Sprache von Go, in der Helm geschrieben ist, verwendet werden, genau wie Kubernetes. <\/p>\n
Helm f\u00fcgt uns noch einige zus\u00e4tzliche Konzepte hinzu. <\/p>\n
Diagramm<\/b> \u2014 das ist die Beschreibung Ihres Services. In anderen Paketmanagern w\u00fcrde man es Paket, Bundle oder etwas \u00c4hnliches nennen. Hier hei\u00dft es Chart. <\/p>\n
Values <\/b>\u2013 das sind die Variablen, die Sie zur Erstellung Ihrer Konfigurationen aus den Vorlagen verwenden m\u00f6chten. <\/p>\n
Release<\/b>Jedes Mal erh\u00e4lt der Service, der mit Helm bereitgestellt wird, eine inkrementelle Version des Releases. Helm erinnert sich, wie die Konfiguration des Services bei der vorherigen, vorvorherigen Version usw. war. Daher reicht es aus, den Befehl 'helm callback' auszuf\u00fchren und die vorherige Version des Releases anzugeben, wenn ein Rollback erforderlich ist. Selbst wenn die entsprechende Konfiguration im Moment des Rollbacks nicht in Ihrem Repository verf\u00fcgbar ist, erinnert sich Helm trotzdem, wie sie war, und stellt Ihr System auf den Zustand zur\u00fcck, in dem es sich beim vorherigen Release befand. <\/p>\n
Im Fall von Helm werden auch die \u00fcblichen Konfigurationen f\u00fcr Kubernetes in Templates umgewandelt, die die M\u00f6glichkeit bieten, Variablen, Funktionen und bedingte Operatoren zu verwenden. Auf diese Weise k\u00f6nnen Sie die Konfiguration Ihres Services je nach Umgebung zusammenstellen.<\/p>\n
Obwohl wir in den Konfigurationsdateien keine wirklich sensiblen Daten speichern. Zum Beispiel Passw\u00f6rter f\u00fcr Datenbanken werden als Secrets in Kubernetes gespeichert, dennoch gibt es dort immer noch bestimmte Dinge, auf die wir nicht allen Zugriff gew\u00e4hren m\u00f6chten. Daher ist der Zugang zum Repository 'deploy' strenger geregelt, w\u00e4hrend das Repository 'helm' einfach die Beschreibung des Services enth\u00e4lt. Aus diesem Grund kann dort sicher eine breitere Personengruppe Zugang erhalten. <\/p>\n
Da wir nicht nur eine Produktionsumgebung, sondern auch andere Umgebungen haben, k\u00f6nnen wir dank dieser Trennung unsere Helm-Charts wiederverwenden, um Services nicht nur in der Produktionsumgebung, sondern beispielsweise auch in der QA-Umgebung bereitzustellen. Sogar um sie lokal zu implementieren, unter Verwendung von Minikube<\/i> \u2014 das ist ein Tool f\u00fcr den lokalen Betrieb von Kubernetes. <\/p>\n
In jedem Repository haben wir eine Trennung in separate Verzeichnisse f\u00fcr jeden Dienst gelassen. Das bedeutet, dass sich in jedem Verzeichnis Templates befinden, die zu dem entsprechenden Chart geh\u00f6ren und die Ressourcen beschreiben, die f\u00fcr den Start unseres Systems bereitgestellt werden m\u00fcssen. Im Repository \u201edeploy\u201c haben wir nur die Environments hinterlassen. In diesem Fall haben wir auf die Verwendung von Jinja-Templating verzichtet, da Helm selbst Templating out of the box bietet \u2013 das ist eine seiner Hauptfunktionen. <\/p>\n
Wir haben ein Skript f\u00fcr das Deployment \u2013 deploy.sh \u2013 hinterlassen, das den Start f\u00fcr das Deployment mit Helm vereinfacht und standardisiert. So sieht das Deployment-Interface f\u00fcr jeden, der ein Deployment durchf\u00fchren m\u00f6chte, genau so aus wie bei einem Deployment \u00fcber Nomad. Das gleiche deploy.sh, der Name Ihres Dienstes und wohin Sie ihn deployen m\u00f6chten. Dadurch wird Helm im Hintergrund gestartet. Es sammelt die Konfigurationen aus den Templates, setzt die erforderlichen Values-Dateien ein und deployt dann, indem es sie in Kubernetes \u00fcbergibt. <\/p>\n
Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h1>\n \nDer Kubernetes-Dienst erscheint komplexer als Nomad. <\/p>\n
Bei unserem Wechsel haben wir festgestellt, dass Kubernetes alle Funktionen von Nomad, das wir zuvor verwendet haben, bietet und zudem viele neue M\u00f6glichkeiten hinzuf\u00fcgt. Es l\u00e4sst sich durch Plugins erweitern und durch benutzerdefinierte Ressourcentypen anpassen. Das bedeutet, dass Sie nicht nur etwas verwenden k\u00f6nnen, was out-of-the-box in Kubernetes bereitgestellt wird, sondern auch Ihre eigenen Ressourcen und Dienste schaffen, die auf ihre Ressourcen zugreifen k\u00f6nnen. Dies bietet zus\u00e4tzliche M\u00f6glichkeiten, Ihr System zu erweitern, ohne Kubernetes neu installieren oder \u00c4nderungen vornehmen zu m\u00fcssen. <\/p>\n
Ein Beispiel f\u00fcr eine solche Verwendung ist Prometheus, der bei uns innerhalb des Kubernetes-Clusters l\u00e4uft. Um zu beginnen, Metriken von einem bestimmten Dienst zu sammeln, m\u00fcssen wir dem Dienstbeschreibung einen zus\u00e4tzlichen Ressourcentyp hinzuf\u00fcgen, den sogenannten Service-Monitor. Prometheus kann, weil er in Kubernetes l\u00e4uft, benutzerdefinierte Ressourcentypen lesen und beginnt automatisch, Metriken aus dem neuen System zu sammeln. Das ist sehr praktisch. <\/p>\n
Der erste Deployment, den wir in Kubernetes gemacht haben, war im M\u00e4rz 2018. Seit dieser Zeit haben wir nie Probleme damit gehabt. Es arbeitet stabil, ohne wesentliche Bugs. Au\u00dferdem k\u00f6nnen wir es weiter ausbauen. Heute reicht uns die Funktionalit\u00e4t, die es bietet, und wir m\u00f6gen das Entwicklungstempo von Kubernetes sehr. Zurzeit sind mehr als 3000 Container in Kubernetes. Der Cluster umfasst mehrere Nodes. Dabei ist er wartbar, stabil und sehr gut 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