Mehrere Umgebungen (Staging, QS, Produktion usw.) mit Kubernetes

Was wird mit K8S als bewährte Methode für die Verwaltung mehrerer Umgebungen (QS, Staging, Produktion, Entwicklung usw.) angesehen?

Angenommen, ein Team arbeitet an einem Produkt, für das einige APIs zusammen mit einer Front-End-Anwendung bereitgestellt werden müssen. Normalerweise erfordert dies mindestens 2 Umgebungen:

• Staging: Für Iterationen / Tests und Validierungen vor der Freigabe an den Client
• Produktion: Dies ist die Umgebung, auf die der Kunde Zugriff hat. Sollte stabile und gut getestete Funktionen enthalten.

Angenommen, das Team verwendet Kubernetes. Was wäre eine gute Vorgehensweise, um diese Umgebungen zu hosten? Bisher haben wir zwei Optionen in Betracht gezogen:

1. Verwenden Sie für jede Umgebung einen K8s-Cluster
2. Verwenden Sie nur einen K8s-Cluster und bewahren Sie diese in verschiedenen Namespaces auf.

(1) Scheint die sicherste Option zu sein, da sie das Risiko potenzieller menschlicher Fehler und Maschinenausfälle minimiert, die die Produktionsumgebung gefährden könnten. Dies ist jedoch mit den Kosten für mehr Master-Maschinen und auch mit den Kosten für mehr Infrastrukturmanagement verbunden.

(2) Sieht so aus, als würde dies das Infrastruktur- und Bereitstellungsmanagement vereinfachen, da es einen einzigen Cluster gibt, wirft jedoch einige Fragen auf:

• Wie stellt man sicher, dass ein menschlicher Fehler die Produktionsumgebung beeinflusst?
• Wie kann sichergestellt werden, dass eine hohe Last in der Staging-Umgebung keinen Leistungsverlust in der Produktionsumgebung verursacht?

Es könnte noch andere Bedenken geben, daher wende ich mich an die K8-Community auf StackOverflow, um besser zu verstehen, wie Menschen mit solchen Herausforderungen umgehen.

Überlegungen zu mehreren Clustern

Schauen Sie sich diesen Blog-Beitrag von Vadim Eisenberg ( IBM / Istio ) an: Checkliste: Vor- und Nachteile der Verwendung mehrerer Kubernetes-Cluster und Verteilung der Workloads zwischen diesen .

Ich möchte einige der Vor- und Nachteile hervorheben:

Gründe für mehrere Cluster

• Trennung von Produktion / Entwicklung / Test: insbesondere zum Testen einer neuen Version von Kubernetes, eines Service-Meshs oder einer anderen Cluster-Software
• Konformität: Gemäß einigen Vorschriften müssen einige Anwendungen in separaten Clustern / separaten VPNs ausgeführt werden
• Bessere Isolation für die Sicherheit
• Cloud / On-Prem: Zum Aufteilen der Last auf On-Premise-Services

Gründe für einen einzelnen Cluster

• Reduzieren Sie den Aufwand für Einrichtung, Wartung und Verwaltung
• Verbesserung der Auslastung
• Kostenreduzierung

In Anbetracht einer nicht zu teuren Umgebung mit durchschnittlicher Wartung und dennoch Sicherheitsisolierung für Produktionsanwendungen würde ich empfehlen:

• 1 Cluster für DEV und STAGING (getrennt durch Namespaces, möglicherweise sogar isoliert, mithilfe von Netzwerkrichtlinien, wie in Calico )
• 1 Cluster für PROD

Umweltparität

Es ist eine gute Übung , Entwicklung, Inszenierung und Produktion so ähnlich wie möglich zu halten:

Unterschiede zwischen den Sicherungsdiensten führen dazu, dass winzige Inkompatibilitäten auftreten und Code, der funktioniert hat und Tests in der Entwicklung oder im Staging bestanden hat, in der Produktion fehlschlägt. Diese Art von Fehlern führt zu Reibungsverlusten, die die kontinuierliche Bereitstellung beeinträchtigen.

Kombinieren Sie ein leistungsstarkes CI / CD-Tool mit Helm . Sie können die Flexibilität der Steuerstandwerte verwenden , um Standardkonfigurationen festzulegen, indem Sie nur die Konfigurationen überschreiben, die sich von einer Umgebung zur anderen unterscheiden.

GitLab CI / CD mit AutoDevops verfügt über eine leistungsstarke Integration in Kubernetes, mit der Sie mehrere Kubernetes-Cluster verwalten können, die bereits Helmunterstützung bieten.

Verwalten mehrerer Cluster ( kubectlInteraktionen)

Wenn Sie mit mehreren Kubernetes-Clustern arbeiten, ist es einfach, Kontexte durcheinander zu bringen und kubectlim falschen Cluster auszuführen . Darüber hinaus unterliegt Kubernetes Einschränkungen hinsichtlich der Versionsinkongruenz zwischen Client ( kubectl) und Server (Kubernetes-Master). Das Ausführen von Befehlen im richtigen Kontext bedeutet also nicht, dass die richtige Client-Version ausgeführt wird.

Um dies zu überwinden:

• Verwenden Sie asdfdiese Option , um mehrere kubectlVersionen zu verwalten
• Stellen Sie dieKUBECONFIG Umgebung so ein, dass zwischen mehreren kubeconfigDateien gewechselt wird
• Verwenden Sie kube-ps1diese Option , um Ihren aktuellen Kontext / Namespace zu verfolgen
• Verwenden Sie kubectxundkubens , um schnell zwischen Clustern / Namespaces zu wechseln
• Verwenden Sie Aliase, um sie alle miteinander zu kombinieren

Ich habe einen Artikel, der beispielhaft zeigt, wie dies erreicht werden kann: Verwenden verschiedener Kubectl-Versionen mit mehreren Kubernetes-Clustern

Ich empfehle auch die folgenden Lesungen:

• Beherrschung der KUBECONFIG-Datei von Ahmet Alp Balkan ( Google Engineer )
• Wie Zalando über 140 Kubernetes-Cluster verwaltet von Henning Jacobs ( Zalando Tech )

Verwenden Sie auf jeden Fall einen separaten Cluster für die Entwicklung und Erstellung von Docker-Images, damit Ihre Staging- / Produktionscluster sicherheitshalber gesperrt werden können. Ob Sie separate Cluster für verwenden, staging + productionliegt bei Ihnen, basierend auf Risiko / Kosten. Wenn Sie diese getrennt halten, können Sie stagingAuswirkungen vermeiden production.

Ich würde auch empfehlen, GitOps zu verwenden, um Versionen Ihrer Apps zwischen Ihren Umgebungen zu bewerben.

Um menschliches Versagen zu minimieren, empfehle ich Ihnen außerdem, sich so weit wie möglich mit der Automatisierung Ihrer CI / CD und Ihrer Werbung zu befassen.

Hier ist eine Demo zur Automatisierung von CI / CD mit mehreren Umgebungen auf Kubernetes mithilfe von GitOps für die Werbung zwischen Umgebungen und Vorschau von Umgebungen auf Pull-Anforderungen, die live auf GKE durchgeführt wurde, obwohl Jenkins X die meisten Kubernetes-Cluster unterstützt

Dies hängt davon ab, was Sie in den einzelnen Szenarien testen möchten. Im Allgemeinen würde ich versuchen, das Ausführen von Testszenarien im Produktionscluster zu vermeiden, um unnötige Nebenwirkungen (Auswirkungen auf die Leistung usw.) zu vermeiden.

Wenn Sie mit einem Staging-System testen möchten , das das Produktionssystem genau nachahmt, würde ich empfehlen, ein genaues Replikat des gesamten Clusters zu starten und es nach Abschluss des Tests herunterzufahren und die Bereitstellungen in die Produktion zu verschieben.

Wenn Sie ein Staging-System testen möchten , mit dem die Bereitstellung der Anwendung getestet werden kann , würde ich einen kleineren Staging-Cluster dauerhaft ausführen und die Bereitstellungen (mit einer verkleinerten Version der Bereitstellungen) nach Bedarf für kontinuierliche Tests aktualisieren.

Um die verschiedenen Cluster zu steuern, bevorzuge ich einen separaten ci / cd-Computer, der nicht Teil des Clusters ist, aber zum Starten und Herunterfahren von Clustern sowie zum Durchführen von Bereitstellungsarbeiten, Initiieren von Tests usw. verwendet wird. Dies ermöglicht das Einrichten und Herunterfahren Cluster als Teil automatisierter Testszenarien.

Es ist klar, dass das Risiko potenzieller Fehler, die sich auf die Produktionsservices auswirken, verringert wird, wenn das Produktionscluster von der Bereitstellungsphase getrennt wird. Dies kostet jedoch mehr Infrastruktur- / Konfigurationsmanagement, da mindestens Folgendes erforderlich ist:

• Mindestens 3 Master für den Produktionscluster und mindestens ein Master für den Staging-Cluster
• 2 Kubectl-Konfigurationsdateien, die dem CI / CD-System hinzugefügt werden sollen

Vergessen wir auch nicht, dass es mehr als eine Umgebung geben kann. Ich habe zum Beispiel in Unternehmen gearbeitet, in denen es mindestens drei Umgebungen gibt:

• QA: Hier haben wir tägliche Bereitstellungen durchgeführt und unsere interne QS durchgeführt, bevor wir sie an den Kunden freigegeben haben.
• Client-Qualitätssicherung: Hier haben wir vor der Bereitstellung in der Produktion bereitgestellt, damit der Client die Umgebung vor der Freigabe für die Produktion validieren kann.
• Produktion: Hier werden Produktionsservices bereitgestellt.

Ich denke, kurzlebige / On-Demand-Cluster sind sinnvoll, aber nur für bestimmte Anwendungsfälle (Last- / Leistungstests oder sehr große Integrations- / End-to-End-Tests), aber für beständigere / klebrigere Umgebungen sehe ich einen Overhead, der möglicherweise reduziert wird indem Sie sie in einem einzelnen Cluster ausführen.

Ich wollte mich wohl an die k8s-Community wenden, um herauszufinden, welche Muster für solche Szenarien wie die von mir beschriebenen verwendet werden.

Sofern Compliance oder andere Anforderungen nichts anderes vorschreiben, bevorzuge ich einen einzelnen Cluster für alle Umgebungen. Bei diesem Ansatz sind die Aufmerksamkeitspunkte:

• Stellen Sie sicher, dass Sie auch Knoten pro Umgebung mithilfe von Beschriftungen gruppieren. Sie können dann die nodeSelectorRessourcen on verwenden, um sicherzustellen, dass sie auf bestimmten Knoten ausgeführt werden. Dies verringert die Wahrscheinlichkeit eines (übermäßigen) Ressourcenverbrauchs zwischen den Umgebungen.

• Behandeln Sie Ihre Namespaces als Subnetze und verbieten Sie standardmäßig den gesamten Ausgangs- / Eingangsverkehr. Siehe https://kubernetes.io/docs/concepts/services-networking/network-policies/ .

• Haben Sie eine Strategie für die Verwaltung von Dienstkonten. ClusterRoleBindingsimplizieren etwas anderes, wenn ein Cluster mehr als eine Umgebung hostet.

• Verwenden Sie die Kontrolle, wenn Sie Werkzeuge wie Helm verwenden. In einigen Diagrammen werden offensichtlich Dienstkonten mit clusterweiten Berechtigungen installiert. Die Berechtigungen für Dienstkonten sollten jedoch auf die Umgebung beschränkt sein, in der sie sich befinden.

Die Verwendung mehrerer Cluster ist die Norm, um eine starke Trennung zwischen Produktion und "Nichtproduktion" zu erzwingen.

Beachten Sie in diesem Sinne, dass GitLab 13.2 (Juli 2020) jetzt Folgendes enthält:

Bereitstellung mehrerer Kubernetes-Cluster in Core

Für die Verwendung von GitLab zum Bereitstellen mehrerer Kubernetes-Cluster mit GitLab war zuvor eine Premium-Lizenz erforderlich.
Unsere Community sprach und wir hörten zu: Die Bereitstellung in mehreren Clustern ist selbst für einzelne Mitwirkende nützlich.
Basierend auf Ihrem Feedback können Sie ab GitLab 13.2 in Core mehrere Gruppen- und Projektcluster bereitstellen.

Siehe Dokumentation und Ausgabe /

Ich halte das Ausführen eines einzelnen Clusters für sinnvoll, da dadurch der Overhead und die Überwachung reduziert werden. Sie müssen jedoch sicherstellen, dass Netzwerkrichtlinien und Zugriffssteuerungen vorhanden sind.

Netzwerkrichtlinie - Verbietet die Arbeitsbelastung der Dev / QA-Umgebung für die Interaktion mit Produkt- / Staging-Speichern.

Zugriffskontrolle - die mithilfe von ClusterRoles, Roles usw. Zugriff auf verschiedene Umgebungsressourcen haben.