App-Bereitstellungen planen

Welche Art von Apps kann ich in IBM Cloud Kubernetes Service ausführen?

Statusunabhängige Apps

Statusunabhängige Apps werden für cloudnative Umgebungen wie Kubernetes bevorzugt. Sie sind einfach zu migrieren und skalieren, weil sie Abhängigkeiten deklarieren, Konfigurationen getrennt vom Code speichern und Sicherungsservices wie Datenbanken als angeschlossene Ressourcen und nicht als an die App gekoppelt behandeln. Die App-Pods erfordern keinen persistenten Datenspeicher oder eine stabile Netz-IP-Adresse. Daher können Pods als Reaktion auf Workloadanforderungen beendet, neu geplant und skaliert werden. Die App verwendet einen Database as a Service für persistente Daten sowie NodePort-, Load-Balancer- oder Ingress-Services, um die Workload für eine stabile IP-Adresse zugänglich zu machen.

Statusabhängige Apps

Statusabhängige Apps sind komplizierter einzurichten, zu verwalten und zu skalieren als statusunabhängige Apps, da die Pods persistente Daten und eine stabile Netzidentität benötigen. Statusabhängige Anwendungen sind häufig Datenbanken oder andere verteilte, datenintensive Workloads, bei denen die Verarbeitung effizienter und näher an den Daten selbst ist. Wenn Sie eine statusabhängige App bereitstellen möchten, müssen Sie persistenten Speicher einrichten und einen persistenten Datenträger an den Pod anhängen, der von einem StatefulSet-Objekt kontrolliert wird. Sie können wahlweise einen Datei-, Block- oder Objekt-Speicher als persistenten Speicher für Ihre statusabhängige Gruppe hinzufügen. Sie können auch Portworx auf Ihren Bare-Metal-Worker-Nodes installieren und Portworx als hochverfügbare softwaredefinierte Speicherlösung verwenden, um persistenten Speicher für Ihre zustandsabhängigen Anwendungen zu verwalten. Weitere Informationen über die Funktionsweise von Stateful Sets finden Sie in der Dokumentation Kubernetes.

Welche Richtlinien gibt es für die Entwicklung von statusunabhängigen, cloudnativen Apps?

Schauen Sie sich die Zwölf-Faktoren-App an, eine sprachneutrale Methode, um zu überlegen, wie Sie Ihre App anhand von 12 Faktoren entwickeln können, die wie folgt zusammengefasst sind

1. Codebasis: Verwenden Sie eine einzelne Codebasis in einem Versionssteuerungssystem für Ihre Implementierungen. Wenn Sie ein Image für Ihre Containerbereitstellung extrahieren, geben Sie einen getesteten Image-Tag anstelle von latest an.
2. Abhängigkeiten: Deklarieren und isolieren Sie explizit externe Abhängigkeiten.
3. Konfiguration: Speichern Sie die bereitstellungsspezifische Konfiguration in Umgebungsvariablen, nicht im Code.
4. Sicherungsservices: Behandeln Sie Sicherungsservices, wie beispielsweise Datenspeicher oder Nachrichtenwarteschlangen, als angehängte oder ersetzbare Ressourcen.
5. App-Phasen: Führen Sie die Erstellung in streng voneinander abgegrenzten Phasen aus, wie build, release, run.
6. Prozesse: Führen Sie einzelne oder mehrere statusunabhängige Prozesse aus, die nichts gemeinsam nutzen, und verwenden Sie persistenten Speicher zum Speichern von Daten.
7. Portbindung: Portbindungen sind eigenständig und stellen einen Serviceendpunkt für einen klar definierten Host und Port bereit.
8. Gleichzeitigkeit: Verwalten und skalieren Sie Ihre App über Prozessinstanzen wie Replikate und horizontale Skalierung. Legen Sie Ressourcenanforderungen und Grenzwerte für Ihre Bereitstellungen fest. Beachten Sie, dass Calico-Netzrichtlinien die Bandbreite nicht begrenzen können. Ziehen Sie stattdessen Istio in Betracht.
9. Löschbarkeit: Konstruieren Sie Ihre App so, dass sie gelöscht werden kann, minimale Startkapazitäten benötigt, sich ordnungsgemäß beenden lässt und abrupte Prozessbeendigungen toleriert. Denken Sie daran, dass Container, Pods und sogar Workerknoten löschbar sein sollten, und planen Sie Ihre App entsprechend.
10. Parität zwischen Entwicklung und Produktion: Richten Sie eine kontinuierliche Integrations- und Bereitstellungspipeline für Ihre Anwendung ein, mit minimalen Unterschieden zwischen der Anwendung in der Entwicklungsphase und der Anwendung in der Produktionsphase.
11. Protokolle: Behandeln Sie Protokolle als Ereignisströme: Die äußere oder Hosting-Umgebung verarbeitet Protokolldateien und leitet sie weiter. Wichtig: In IBM Cloud Kubernetes Service sind die Protokolle standardmäßig nicht aktiviert. Informationen zum Aktivieren finden Sie im Abschnitt Protokollweiterleitung konfigurieren.
12. Verwaltungsprozesse: Bewahren Sie alle einmaligen Verwaltungsskripte mit Ihrer Anwendung auf und führen Sie sie als Kubernetes Job-Objekt aus, um sicherzustellen, dass die Verwaltungsskripte in derselben Umgebung wie die Anwendung selbst ausgeführt werden. Für die Orchestrierung größerer Pakete, die Sie in Ihren Kubernetes Clustern ausführen möchten, sollten Sie einen Paketmanager wie Helm.

Was ist mit serverunabhängigen Apps?

Sie können serverunabhängige Apps und Jobs über den IBM Cloud Code Engine-Service ausführen. Code Engine kann Ihre Images auch für Sie erstellen. Code Engine ist so konzipiert, dass Sie nicht mit der zugrunde liegenden Technologie interagieren müssen, auf der es basiert. Wenn Sie jedoch bereits vorhandene Tools auf der Basis von Kubernetes oder Knative verwenden, können Sie es immer noch mit Code Engine verwenden. Weitere Informationen finden Sie unter Kubernetes für die Interaktion mit Ihrer Anwendung verwenden.

Ich habe bereits eine App. Wie kann ich sie nach IBM Cloud Kubernetes Service migrieren?

Die folgenden allgemeinen Schritte können Sie ausführen, um Ihre App zu containerisieren.

1. Verwenden Sie die Zwölf-Faktoren-App als Leitfaden für die Isolierung von Abhängigkeiten, die Aufteilung von Prozessen in separate Dienste und die weitestgehende Reduzierung der Zustandsabhängigkeit Ihrer App.
2. Suchen Sie ein geeignetes Basisimage, das verwendet werden soll. Sie können öffentlich verfügbare Bilder von Docker Hub, öffentliche IBM Bilder verwenden oder Ihre eigenen Bilder in Ihrem privaten IBM Cloud Container Registry erstellen und verwalten.
3. Fügen Sie dem Docker-Image nur die für die Ausführung der App erforderlichen Informationen hinzu.
4. Anstatt auf dem lokalen Speicher aufzubauen, planen Sie die Verwendung von persistentem Speicher oder von Cloud-Database as a Service-Lösungen, um die Daten Ihrer App zu sichern.
5. Im Laufe der Zeit refaktorieren Sie Ihre App-Prozesse in Microservices.

Ich dachte, ich müsste meine App in einem Container anordnen. Warum ist jetzt von Pods die Rede?

Ein Pod ist die einfachste einsatzfähige Einheit, die Kubernetes verwalten kann. Sie legen Ihren Container (oder eine Gruppe von Containern) in einen Pod und verwenden die Pod-Konfigurationsdatei, um dem Pod mitzuteilen, wie der Container ausgeführt werden und wie er Ressourcen mit anderen Pods gemeinsam nutzen soll. Alle Container, die Sie in einen Pod einfügen, werden in einem gemeinsamen Kontext ausgeführt, d. h. sie teilen sich den virtuellen oder physischen Rechner.

Was in einen Container gehört

Wenn Sie über die Komponenten Ihrer Anwendung nachdenken, sollten Sie berücksichtigen, ob sie über signifikant unterschiedliche Ressourcenanforderungen verfügen, z. B. für CPU und Speicher. Könnten einige Komponenten nach bestem Wissen und Gewissen betrieben werden, so dass ein kurzzeitiger Ausfall zur Umleitung von Ressourcen auf andere Bereiche akzeptabel ist? Bildet eine Komponente eine Schnittstelle zum Kunden, weshalb sie unbedingt laufen muss? Teilen Sie sie in separate Container auf. Sie können sie immer im selben Pod bereitstellen, sodass sie synchron laufen.

Was in einen Pod gestellt werden soll

Die Container für Ihre App müssen sich nicht immer im gleichen Pod befinden. Wenn Sie eine Komponente haben, die statusabhängig und schwer skalierbar ist, wie z. B. ein Datenbankservice, stellen Sie sie in einen anderen Pod, den Sie auf einem Workerknoten mit mehr Ressourcen zur Verarbeitung der Workload planen können. Wenn Ihre Container ordnungsgemäß funktionieren, wenn sie auf verschiedenen Workerknoten ausgeführt werden, verwenden Sie mehrere Pods. Wenn sie auf derselben Maschine ausgeführt und zusammen skaliert werden müssen, gruppieren Sie die Container im selben Pod.

Wenn ich also einen Pod verwenden kann, warum brauche ich dann all diese verschiedenen Arten von Objekten?

Die Erstellung einer YAML-Datei für einen Pod ist einfach. Sie können eine wie folgt mit nur wenigen Zeilen schreiben.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Aber das ist noch nicht alles. Wenn der Knoten, auf dem der Pod ausgeführt wird, ausfällt, fällt Ihr Pod zusammen mit dem Knoten aus und wird nicht neu geplant. Verwenden Sie stattdessen ein Deployment, um Pod-Neuplanung, Replikatsätze und rollierende Updates zu unterstützen. Eine Basisbereitstellung ist fast so einfach wie ein Pod. Statt den Container in der spec selbst zu definieren, geben Sie jedoch replicas und eine template in spec der Bereitstellung an. Die Vorlage verfügt über eine eigene spec für die Container darin, die z. B. wie folgt aussehen kann.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Sie können Features wie Anti-Affinität für den Pod oder Ressourcengrenzwerte alle in derselben YAML-Datei hinzufügen.

Eine detailliertere Erläuterung der verschiedenen Funktionen, die Sie Ihrem Deployment hinzufügen können, finden Sie unter Erstellen der YAML-Datei für Ihr App-Deployment.

Welche Art von Kubernetes-Objekten kann ich für meine App erstellen?

Wenn Sie die YAML-Datei für die App vorbereiten, haben Sie viele Möglichkeiten, um die Verfügbarkeit, Leistung und Sicherheit der App zu erhöhen. So können Sie zum Beispiel anstelle eines einzelnen Pods ein Kubernetes-Controller-Objekt, wie z. B. eine Replikatgruppe, einen Job oder eine Dämongruppe, zur Verwaltung der Workload verwenden. Weitere Informationen zu Pods und Controllern finden Sie in der Dokumentation Kubernetes. Eine Bereitstellung, von der eine Replikatgruppe von Pods verwaltet wird, ist ein gängiger Anwendungsfall für eine App.

Beispiel: Das Objekt kind: Deployment ist eine gute Möglichkeit zum Bereitstellen eines App-Pods, weil Sie damit eine Replikatgruppe für mehr Verfügbarkeit für die Pods angeben können.

In der folgenden Tabelle wird beschrieben, warum es sinnvoll sein kann, abweichende Objekttypen für Kubernetes-Workloads zu erstellen.

Was ist, wenn in meiner App-Konfiguration Variablen verwendet werden sollen? Wie kann ich diese Variablen in die YAML einfügen?

Um variable Informationen zu Ihren Deployments hinzuzufügen, anstatt die Daten fest in die YAML-Datei zu kodieren, können Sie eine Kubernetes ConfigMap oder Secret objekt verwenden.

Wenn Sie eine Konfigurationszuordnung (ConfigMap) oder einen geheimen Schlüssel (Secret) verarbeiten möchten, müssen Sie diese bzw. diesen an den Pod anhängen. Die Konfigurationszuordnung bzw. der geheime Schlüssel wird mit dem Pod kurz vor der Ausführung des Pods kombiniert. Sie können Bereitstellungsspezifikationen und Images für viele Apps wiederverwenden, aber anschließend die angepassten Konfigurationszuordnungen und geheimen Schlüssel auslagern. Da besonders für geheime Schlüssel große Speichermengen auf dem lokalen Knoten erforderlich sein können, sollten Sie entsprechend planen.

Von beiden Ressourcen werden Schlüssel/Wert-Paare definiert, Sie verwenden diese jedoch für unterschiedliche Situationen.

ConfigMap

Stellen Sie nicht sensible Konfigurationsinformationen für Workloads bereit, die in einer Bereitstellung angegeben sind. Zum Verwenden von Konfigurationszuordnungen stehen drei Hauptmöglichkeiten zur Verfügung.

• Dateisystem: Sie können eine vollständige Datei oder einen Satz von Variablen auf dem Pod bereitstellen. Eine Datei wird für jeden Eintrag auf der Basis des Schlüsselnamensinhalts der Datei erstellt, der für den Wert festgelegt ist.
• Umgebungsvariable: Die Umgebungsvariable dynamisch für eine Container-Spezifikation festlegen.
• Kommandozeilen-Option: Legen Sie die Befehlszeilenoption fest, die in einer Container-Spezifikation verwendet wird.

Secret

Geben Sie sensible Informationen wie die folgenden zu Ihren Workloads an. Andere Benutzer des Clusters verfügen möglicherweise über Zugriff auf den geheimen Schlüssel; stellen Sie daher sicher, dass die Informationen des geheimen Schlüssels gemeinsam mit diesen Benutzern genutzt werden können.

• Persönliche Daten (PII: Speichern Sie vertrauliche Daten wie E-Mail-Adressen oder sonstige Daten, die das Unternehmen für die Einhaltung von Vorschriften oder behördliche Bestimmungen benötigt in geheimen Schlüsseln.
• Berechtigungsnachweise: Stellen Sie Berechtigungsnachweise wie Kennworte, Schlüssel und Token in einen geheimen Schlüssel, um das Risiko einer unbeabsichtigten Offenlegung zu mindern. Beispiel: Beim Binden eines Service an einen Cluster werden die Berechtigungsnachweise in einem geheimen Schlüssel gespeichert.

Sollen die geheimen Schlüssel noch sicherer werden? Wenden Sie sich zur Aktivierung eines Key Management Service-Providers im Cluster an Ihren Clusteradministrator, um neue und vorhandene geheime Schlüssel zu verschlüsseln.

Wie kann ich sicherstellen, dass meine Anwendung über die richtigen Ressourcen verfügt?

Wenn Sie Ihre App-YAML-Datei spezifizieren, können Sie Kubernetes Funktionalitäten zu Ihrer App-Konfiguration hinzufügen, die Ihrer App helfen, die richtigen Ressourcen zu erhalten. Insbesondere ressourcengrenzen und -anforderungen festlegen für jeden Container, der in Ihrer YAML-Datei definiert ist.

Zusätzlich kann der Clusteradministrator Ressourcensteuerungen wie die folgenden einrichten, die sich auf die Bereitstellung auswirken.

• Ressourcenkontingente
• Podpriorität

Wie können Funktionen zur App-Konfiguration hinzugefügt werden?

Beschreibungen zu allen Elementen, die in einer Bereitstellung enthalten sein können, finden Sie in App-Anforderungen in YAML-Datei angeben. Das Beispiel enthält die folgenden Optionen:

• Replikatgruppen
• Labels
• Affinität
• Imagerichtlinien
• Ports
• Ressourcenanforderungen und -begrenzungen
• Aktivitäts- und Bereitschaftsprüfungen
• Dienste, um den App-Dienst auf einem Port freizugeben.
• Configmaps zum Festlegen von Containerumgebungsvariablen.
• Geheime Schlüssel zum Festlegen von Containerumgebungsvariablen.
• Persistente Volumes, die zur Speicherung in den Container eingebunden werden.

Wie kann ich IBM Services zu meiner App hinzufügen, zum Beispiel Watson?

Informationen hierzu finden Sie unter Services zu Apps hinzufügen.

Wie kann ich die Verfügbarkeit meiner App erhöhen?

Ziehen Sie die folgenden Optionen zum Verbessern der Verfügbarkeit Ihrer App in Betracht.

Bereitstellungen und Replikatgruppen zum Bereitstellen Ihrer App und deren Abhängigkeiten verwenden

Eine Bereitstellung ist eine Kubernetes-Ressource, die Sie zum Deklarieren aller Komponenten Ihrer App und ihrer Abhängigkeiten verwenden können. Bei Bereitstellungen müssen Sie nicht alle Schritte aufschreiben und können sich stattdessen auf Ihre App konzentrieren. Wenn Sie mehrere Pods bereitstellen, wird automatisch eine Replikatgruppe für Ihre Bereitstellungen erstellt, die die Pods überwacht und sicherstellt, dass die angegebene Anzahl von Pods betriebsbereit ist. Wird ein Pod inaktiv, so ersetzt die Replikatgruppe den inaktiven Pod durch einen neuen Pod. Mit einer Bereitstellung können Sie Aktualisierungsstrategien für Ihre App definieren. Dabei können Sie unter anderem die Anzahl von Pods angeben, die Sie bei einer rollierenden Aktualisierung hinzufügen wollen, und festlegen, wie viele Pods zur gleichen Zeit nicht verfügbar sein dürfen. Wenn Sie eine rollierende Aktualisierung durchführen, überprüft die Bereitstellung, ob die Revision funktioniert und stoppt die Implementierung, wenn Fehler erkannt werden. Mit Verteilungen können Sie gleichzeitig mehrere Revisionen mit unterschiedlichen Optionen verteilen. Sie können beispielsweise eine Bereitstellung zuerst testen, bevor Sie sich entschließen, sie per Push-Operation an die Produktion zu übertragen. Mithilfe von Bereitstellungen können Sie alle bereitgestellten Revisionen nachverfolgen. Sie können dieses Verlaufsprotokoll verwenden, um ein Rollback auf eine vorherige Version durchzuführen, falls Sie feststellen, dass Ihre Aktualisierungen nicht wie erwartet funktionieren.

Ausreichende Anzahl von Replikaten für die Arbeitslast Ihrer App plus 2 einbeziehen

Um Ihre Anwendung noch hochverfügbarer und ausfallsicherer zu machen, sollten Sie zusätzliche Replikate über das Minimum hinaus einrichten, um die erwartete Arbeitslast zu bewältigen. Zusätzliche Replikate können die Arbeitslast bewältigen, falls ein Pod abstürzt und der Replikatsatz den abgestürzten Pod noch nicht wiederhergestellt hat. Um sich gegen zwei gleichzeitige Ausfälle zu schützen, sollten Sie zwei zusätzliche Replikate erstellen. Bei dieser Konfiguration handelt es sich um ein N+2-Muster, wobei N die Anzahl der Replikate zur Bewältigung der eingehenden Arbeitslast und +2 zwei zusätzliche Replikate ist. Vorausgesetzt, in Ihrem Cluster ist ausreichend Platz, ist die Anzahl der mögliche Pods unbegrenzt.

Pods auf mehrere Knoten (Anti-Affinität) verteilen

Wenn Sie Ihre Bereitstellung erstellen, können alle Pods auf demselben Workerknoten bereitgestellt werden. Dies wird als Affinität oder Kolokation bezeichnet. Zum Schutz Ihrer App vor dem Ausfall eines Workerknotens können Sie Ihre Bereitstellung so konfigurieren, dass Ihre Pods mithilfe der Option podAntiAffinity in Ihren Standardclustern über mehrere Workerknoten verteilt werden. Sie können zwei Typen von Pod-Anti-Affinität definieren: bevorzugt oder erforderlich. Weitere Informationen finden Sie in der Dokumentation Kubernetes über die Zuordnung von Pods zu Knoten.

Ein Beispiel für die Affinität in einer App-Bereitstellung finden Sie unter YAML-Datei für App-Bereitstellung erstellen.

Pods auf mehrere Zonen oder Regionen verteilen

Um Ihre App vor einem Zonenfehler zu schützen, können Sie mehrere Cluster in separaten Zonen erstellen oder Zonen zu einem Worker-Pool in einem Mehrzonencluster hinzufügen. Mehrzonencluster sind nur in bestimmten klassischen Mehrzonenumgebungen oder VPC-Mehrzonenumgebungen (z. B. Dallas) verfügbar. Wenn Sie mehrere Cluster in unterschiedlichen Zonen erstellen, müssen Sie eine globale Lastausgleichsfunktion einrichten. Wenn Sie eine Replikatgruppe verwenden und Anti-Affinität für Pods angeben, verteilt Kubernetes Ihre App-Pods auf die Knoten. Wenn sich die Knoten in mehreren Zonen befinden, werden die Pods auf diese Zonen verteilt, was die Verfügbarkeit für Ihre App erhöht. Wenn Sie Ihre Apps nur in einer einzigen Zone ausführen möchten, können Sie die Pod-Affinität konfigurieren oder einen Worker-Pool in einer Zone erstellen und kennzeichnen.

Sind meine App-Pods in einem Multizonen-Cluster gleichmäßig auf die Knoten verteilt?

Die Pods sind gleichmäßig über die Zonen verteilt, aber nicht immer über Knoten hinweg. Wenn Sie beispielsweise über einen Cluster mit einem Knoten in jeder der drei Zonen verfügen und eine Replikatgruppe von sechs Pods bereitstellen, erhält jeder Knoten zwei Pods. Wenn Sie jedoch über einen Cluster mit zwei Knoten in jeder der drei Zonen verfügen und eine Replikatgruppe von sechs Pods bereitstellen, sind für jede Zone zwei Pods geplant und es kann ein Pod pro Knoten geplant werden (oder auch nicht). Für eine bessere Kontrolle der Planung können Sie die Pod-Affinität festlegen.

Wenn eine Zone ausfällt, wie werden dann die Pods auf die verbleibenden Knoten in den anderen Zonen umgeplant?

Dies ist abhängig von Ihrer Planungsrichtlinie, die Sie in der Bereitstellung verwenden. Wenn Sie die knotenspezifische Pod-Affinität einbezogen haben, werden Ihre Pods nicht neu geplant. Wenn Sie dies nicht getan haben, werden die Pods auf verfügbaren Workerknoten in anderen Zonen erstellt, aber sie sind möglicherweise nicht ausgeglichen. Die beiden Pods können beispielsweise über die beiden verfügbaren Knoten verteilt sein oder sie können beide für einen Knoten mit verfügbarer Kapazität geplant werden. In ähnlicher Weise werden Pods nicht automatisch neu gelöscht und über Knoten hinweg verteilt, wenn die nicht verfügbare Zone wieder verfügbar wird. Wenn Sie möchten, dass die Pods nach der Wiederherstellung der Zone auf die Zonen verteilt werden, konfigurieren Sie den Kubernetes descheduler. Bei Clustern mit mehreren Zonen sollten Sie versuchen, die Worker-Node-Kapazität bei 50 % pro Zone zu halten, damit genügend Kapazität verbleibt, um Ihren Cluster gegen einen zonalen Ausfall zu schützen.

Was ist, wenn ich meine Anwendung auf mehrere Regionen verteilen möchte?

Um Ihre Anwendung vor dem Ausfall einer Region zu schützen, erstellen Sie einen zweiten Cluster in einer anderen Region, richten Sie einen globalen Load Balancer ein, um Ihre Cluster zu verbinden, und verwenden Sie eine Bereitstellungs-YAML, um ein doppeltes Replikat-Set mit Pod-Anti-Affinität für Ihre Anwendung bereitzustellen.

Was ist, wenn meine Anwendungen dauerhaften Speicher benötigen?

Verwenden Sie einen Cloud-Service wie IBM Cloudant oder IBM Cloud Object Storage.

Wie kann ich meine App skalieren?

Wenn Sie Apps als Reaktion auf die Workloadnutzung dynamisch hinzufügen und entfernen möchten, finden Sie weitere Informationen zu den Schritten zum Aktivieren der automatischen horizontalen Skalierung von Pods unter Apps skalieren.

Wie kann ich meine Bereitstellungen so organisieren, dass sie sich einfacher aktualisieren und verwalten lassen?

Nachdem Sie nun eine gute Vorstellung davon haben, was Sie in Ihre Bereitstellung einbeziehen können, fragen Sie sich vielleicht, wie Sie alle diese unterschiedlichen YAML-Dateien verwalten sollen. Ganz zu schweigen von den Objekten, die diese in Ihrer Kubernetes-Umgebung erzeugen.

Die folgenden Tipps können bei der Organisation Ihrer Bereitstellungs-YAML-Dateien behilflich sein.

• Verwenden Sie ein System zur Versionssteuerung wie z. B. Git.
• Gruppieren Sie eng zusammengehörige Kubernetes-Objekte in einer einzigen YAML-Datei. Wenn Sie beispielsweise eine deployment erstellen, können Sie auch die service-Datei zur YAML hinzufügen. Trennen Sie Objekte mit ---, wie im folgenden Beispiel.

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  ...
  ---
  apiVersion: v1
  kind: Service
  metadata:
  ...
  

• Für die Anwendung auf ein gesamtes Verzeichnis und nicht nur auf eine einzelne Datei können Sie den Befehl kubectl apply -f verwenden.

Innerhalb der YAML-Datei können Sie Bezeichnungen oder Annotationen als Metadaten verwenden, um Ihre Bereitstellungen zu verwalten.

Bezeichnungen

Labels sind key:value Paare, die an Kubernetes Objekte wie Pods und Bereitstellungen angehängt werden können. Dabei kann es sich um Elemente aller Art handeln. Sie sind hilfreich bei der Auswahl von Objekten auf Grundlage der Bezeichnungsinformationen. Bezeichnungen bilden die Grundlage für die Gruppierung von Objekten. Die folgenden Beispiele bieten Ideen für Bezeichnungen.

• app: nginx
• version: v1
• env: dev

Anmerkungen

Anmerkungen sind ähnlich wie Beschriftungen, da sie ebenfalls key:value Paare sind. Sie eignen sich besser für nicht identifizierende Informationen, die von Tools oder Bibliotheken genutzt werden können, wie z. B. das Halten zusätzlicher Informationen darüber, woher ein Objekt stammt, wie das Objekt verwendet wird, Zeiger auf zugehörige Aufzeichnungsrepositorys oder eine Richtlinie über das Objekt. Es werden keine Objekte auf der Basis von Annotationen ausgewählt.

Welche App-Aktualisierungsstrategien kann ich anwenden?

Um Ihre App zu aktualisieren, können Sie aus verschiedenen Strategien auswählen, wie z. B. den folgenden. Sie können mit einer rollierenden Bereitstellung oder sofortigen Umschaltung beginnen, bevor Sie sich mit einer komplexeren Canary-Bereitstellung beschäftigen.

Rollierende Bereitstellung

Sie können Kubernetes-native Funktionen verwenden, um eine v2-Bereitstellung zu erstellen und die vorherige v1-Bereitstellung nach und nach zu ersetzen. Dieser Ansatz setzt voraus, dass die Anwendungen mit früheren Versionen kompatibel sind, so dass Nutzer, denen die Version v2 zur Verfügung gestellt wird, keine störenden Änderungen erfahren. Weitere Informationen finden Sie unter Laufende Bereitstellungen zum Aktualisieren der Apps verwalten.

Sofortige Umschaltung

Eine sofortige Umschaltung, auch als Blue-Green Deployment bezeichnet, erfordert die doppelten Datenverarbeitungsressourcen, um zwei Versionen einer App gleichzeitig auszuführen. Mit diesem Ansatz können Sie Ihre Benutzer nahezu in Echtzeit auf die neuere Version umschalten. Stellen Sie sicher, dass Sie Selektoren für Dienstbezeichnungen (wie version: green und version: blue) verwenden, um sicherzustellen, dass Anfragen an die richtige App-Version gesendet werden. Sie können die neue Bereitstellung mit version: green erstellen, warten, bis sie bereit ist, und anschließend die Bereitstellung mit version: blue löschen. Sie können auch eine rollierende Aktualisierung ausführen, aber legen Sie den Parameter maxUnavailable auf 0% und den Parameter maxSurge auf 100% fest.

Canary- oder A/B-Bereitstellung

Eine Canary-Bereitstellung ist eine komplexere Aktualisierungsstrategie und besteht darin, dass Sie einen Prozentsatz von Benutzern wie z. B. 5% wählen und diese an die neue App-Version senden. Sie erfassen Metriken in Ihren Protokollierungs- und Überwachungstools zur Leistung der neuen App-Version, führen A/B-Tests durch und implementieren dann die Aktualisierung für weitere Benutzer. Wie bei allen Bereitstellungen ist die Bezeichnung der App (z. B. mit version: stable und version: canary) von entscheidender Bedeutung. Um Canary-Bereitstellungen zu verwalten, können Sie das verwaltete Istio Add-on Service Mesh installieren, Monitoring für Ihren Cluster einrichten und dann das Istio Service Mesh für A/B-Tests verwenden, wie in diesem Blogbeitrag beschrieben.

Wie kann ich meine App-Bereitstellung automatisieren?

Wenn Sie Ihre App in mehreren Clustern, öffentlichen und privaten Umgebungen oder sogar mit mehreren Cloud-Providern ausführen möchten, fragen Sie sich vielleicht, wie Sie in solchen Umgebungen Ihre Bereitstellungsstrategie gestalten können. Mit IBM Cloud und anderen Open-Source-Tools können Sie Ihre Anwendung paketieren und damit die Automatisierung von Bereitstellungen unterstützen.

Pipeline für kontinuierliche Integration und Continuous Delivery (CI/CD) einrichten

Mit Ihren App-Konfigurationsdateien, die in einem Quellcodeverwaltungssystem wie Git organisiert sind, können Sie Ihre Pipeline erstellen und damit Code in verschiedenen Umgebungen, z. B. test und prod, testen und bereitstellen. Arbeiten Sie mit Ihrem Cluster-Administrator zusammen, um die kontinuierliche Integration und Bereitstellung einzurichten.

App-Konfigurationsdateien paketieren

Mit dem Helm Kubernetes paketmanager können Sie alle Kubernetes Ressourcen, die Ihre Anwendung benötigt, in einem Helm Diagramm angeben. Anschließend können Sie mit Helm die YAML-Konfigurationsdateien erstellen und diese Dateien in Ihrem Cluster bereitstellen. Sie können auch IBM Cloud-bereitgestellte Diagramme integrieren Helm verwenden, um die Fähigkeiten Ihres Clusters zu erweitern, z. B. mit einem Blockspeicher-Plug-in.

Möchten Sie YAML-Dateivorlagen erstellen? Einige Leute verwenden Helm, um genau das zu tun, oder Sie könnten andere Community-Tools ausprobieren, wie ytt.

Wie kann ich sicherstellen, dass meine Dienste mit den richtigen Bereitstellungen verbunden und einsatzbereit sind?

Bei den meisten Services fügen Sie Ihrer .yaml-Servicedatei einen Selektor hinzu, sodass sie auf Pods angewendet wird, die Ihre Apps mit dieser Bezeichnung ausführen. Wenn Ihre Anwendung zum ersten Mal gestartet wird, möchten Sie oft nicht, dass sie sofort Anfragen verarbeitet. Fügen Sie Ihrer Bereitstellung eine Bereitschaftsprüfung hinzu, sodass Datenverkehr nur an einen Pod gesendet wird, der als bereit eingestuft wurde. Ein Beispiel für ein Deployment mit einem Dienst, der Labels verwendet und eine Readiness-Probe setzt, finden Sie in dieser NGINX YAML.

In einigen Fällen soll der Service keine Bezeichnung verwenden. Zum Beispiel haben Sie eine externe Datenbank haben oder möchten, dass der Service auf einen anderen Service in einem anderen Namensbereich innerhalb des Clusters verweist. In diesem Fall müssen Sie manuell ein Endpunktobjekt hinzufügen und es mit dem Service verknüpfen.

Wie mache ich meine Services im Internet zugänglich?

Sie können drei Typen von Services für den externen Netzbetrieb erstellen: NodePort, LoadBalancer und Ingress.

Sie haben verschiedene Optionen, die sich nach dem Clustertyp richten. Weitere Informationen hierzu finden Sie unter Netzbetriebsservices planen.

• Standardcluster: Sie können Ihre App mithilfe des NodePort-Service, Lastausgleichsservice oder Ingress-Service verfügbar machen.
• Cluster, der mit Calico privat verwendet wird: Sie können Ihre App mithilfe des NodePort-Service, Lastausgleichsservice oder Ingress-Service verfügbar machen. Sie müssen auch eine Calico-PreDNAT-Netzrichtlinie verwenden, um die öffentlichen Knotenports zu blockieren.
• Standardcluster für ausschließlich privates VLAN: Sie können Ihre App mithilfe des NodePort-Service, Lastausgleichsservice oder Ingress-Service verfügbar machen. Sie müssen außerdem den Port für die private IP-Adresse des Service in der Firewall öffnen.

Bei der Planung, wie viele Service-Objekte Sie in Ihrem Cluster benötigen, berücksichtigen Sie, dass Kubernetes für die Bearbeitung von Netzbetriebs- und Portweiterleitungsregeln iptables verwendet. Wenn Sie viele Services in Ihrem Cluster ausführen, z. B. 5000, kann dies die Leistung beeinträchtigen.

Wie kann ich steuern, wer Zugriff auf meine App-Bereitstellungen hat?

Konto- und Clusteradministratoren können den Zugriff auf unterschiedlichen Ebenen steuern: Cluster, Kubernetes-Namensbereich, Pod und Container.

Mit IBM Cloud IAM können Sie Berechtigungen zu einzelnen Benutzern, Gruppen oder Servicekonten auf der Clusterinstanzebene zuordnen. Sie können einen Bereich für den Clusterzugriff noch weiter definieren, indem Sie Benutzer auf bestimmte Namensbereiche im Cluster beschränken. Weitere Informationen finden Sie in Clusterzugriff zuweisen.

Um den Zugang auf Pod-Ebene zu kontrollieren, können Sie Pod-Sicherheitsrichtlinien (PSPs) konfigurieren.

In der YAML-Datei für die Bereitstellung der App können Sie den Sicherheitskontext für einen Pod oder Container festlegen. Weitere Informationen finden Sie in der Dokumentation Kubernetes.

Wie kann ich den Status meiner App nach ihrer Bereitstellung überwachen?

Sie können die IBM Cloud-Protokollierung und -Überwachung für den Cluster konfigurieren. Sie können auch einen Protokollierungs- oder Überwachungsservice eines Drittanbieters integrieren.