Erstellen einer hochverfügbaren Cluster-Strategie

Entscheiden Sie, wie viele Cluster Sie erstellen möchten

Die Wahrscheinlichkeit, dass Ihre Benutzer Ausfallzeiten verzeichnen, ist geringer, wenn Sie Ihre Apps auf mehrere Workerknoten, Zonen und Cluster verteilen. Integrierte Funktionen wie Lastausgleich (Load Balancing) und Isolation erhöhen die Ausfallsicherheit gegenüber möglichen Fehlerbedingungen mit Hosts, Netzen oder Apps.

Die Anzahl der Cluster, die Sie erstellen, hängt von Ihrer Arbeitslast, den Unternehmensrichtlinien und -vorschriften, den geschäftlichen Anforderungen, den Service Level Agreements, die Sie mit Ihren Kunden abgeschlossen haben, den Ressourcen, die Sie aufwenden wollen, und der Art und Weise, wie Sie die Computerressourcen nutzen wollen, ab.

• Mehrere Cluster: Mehrere Cluster sind in der Regel komplexer zu verwalten, können Ihnen jedoch dabei helfen, wichtige Ziele wie die folgenden zu erreichen.

  • Einhalten von Sicherheitsrichtlinien, die eine Isolierung von Workloads erfordern.
  • Testen Sie, wie Ihre App unter einer anderen Version von Red Hat OpenShift oder mit anderer Cluster-Software (z. B. Calico) ausgeführt wird.
  • Erzielen Sie eine höhere Leistung für Nutzer in verschiedenen geografischen Gebieten.
  • Vereinfachen Sie den Benutzerzugriff, um den Zugriff innerhalb eines Clusters zu kontrollieren, indem Sie den Zugriff auf der Ebene der Cluster-Instanz konfigurieren, anstatt mehrere RBAC-Richtlinien auf Namespace-Ebene anzupassen und zu verwalten.
  • Halten Sie die Anzahl der Arbeitsknoten niedriger. Die Netzwerkbandbreite bei der Skalierung virtueller Maschinen beträgt etwa 1000 Mbit/s. Wenn Sie Hunderte von Worker-Knoten in einem Cluster benötigen, können Sie die Konfiguration auf mehrere Cluster mit weniger Knoten aufteilen oder Bare-Metal-Knoten bestellen.
  • Ermöglichen Sie eine größere Anzahl von Diensteintegrationen, z. B. mehr als 5.000 Dienste.
  • Bieten Sie einer Anwendung eine höhere Verfügbarkeit. Ähnlich wie bei der Verwendung von drei Zonen in Multizonen-Clustern können Sie die Verfügbarkeit Ihrer App erhöhen, indem Sie drei Cluster über mehrere Zonen hinweg einrichten.
  • Reduzieren Sie Kosten, indem Sie kleinere Maschinen kaufen, um Ihre Arbeitslast zu bewältigen.

• Ein Cluster mit mehreren Worker-Knoten: Mit weniger Clustern können Sie den Betriebsaufwand und die Kosten pro Cluster für feste Ressourcen reduzieren. Anstatt mehrere Cluster zu erstellen, können Sie einem Cluster Worker-Pools hinzufügen, um verschiedene Arten von Computing-Ressourcen für Ihre Anwendungs- und Servicekomponenten bereitzustellen. Wenn Sie die App entwickeln, befinden sich die Ressourcen, die sie verwendet, in derselben Zone oder sind auf andere Weise in einer Mehrfachzone eng verbunden, sodass Sie Annahmen zu Latenzzeiten, Bandbreite oder korrelierten Fehlern machen können. Wenn Sie jedoch nur über einen einzigen Cluster verfügen, ist es umso wichtiger, dass Sie Ihren Cluster mithilfe von Namespaces, Ressourcenquoten und Labels organisieren.

Bestimmen Sie, wie viele Standorte benötigt werden

Ein Cluster kann die Replikate entweder auf Arbeitsknoten an einem einzigen Standort oder auf mehrere Standorte verteilen. Diese Wahl kann sich auf die Clustertypen auswirken, die Ihnen im nächsten Abschnitt zur Verfügung stehen.

Durch die Verteilung der Workload auf drei Zonen wird Hochverfügbarkeit für Ihre App für den Fall sichergestellt, dass eine Zone nicht mehr verfügbar ist. Ihre Workerknoten müssen gleichmäßig auf alle drei Verfügbarkeitszonen verteilt sein, um das IBM Cloud-Service-Level-Agreement (SLA) für HA-Konfigurationen zu erfüllen.

Ein Zonenfehler wirkt sich auf alle physischen Datenverarbeitungshosts und den NFS-Speicher aus. Fehler umfassen Ausfälle bei Stromversorgung, Kühlung, Netzbetrieb oder Speicherausfälle sowie Naturkatastrophen wie Überschwemmungen, Erdbeben und Stürme. Um sich gegen einen Zonenausfall zu schützen, müssen Sie Cluster in zwei verschiedenen Zonen haben, die durch einen externen Load Balancer ausgeglichen werden, einen Cluster an einem Standort mit mehreren Zonen erstellen, der den Master über die Zonen verteilt, oder die Einrichtung eines zweiten Clusters in einer anderen Zone in Betracht ziehen.

Wählen Sie einen Clustertyp

Die Workerknotentypen und Isolationsstufen, die Ihnen zur Verfügung stehen, hängen von der Containerplattform, vom Clustertyp, vom geplanten Infrastrukturprovider und vom Red Hat OpenShift on IBM Cloud-Standort ab, an dem Sie Ihren Cluster erstellen wollen. Sie können zwischen Classic-, VPC- oder Satellite-Clustern wählen. Die Art des Clusters, die Sie benötigen, wird durch die Entscheidungen bestimmt, die Sie für die Anzahl der Cluster und die Standorte getroffen haben.

VPC-Cluster

Arbeitsknoten können mithilfe virtueller Arbeitsknoten auf einer Standardinfrastruktur oder dedizierten Hosts bereitgestellt werden. Wenn Geschwindigkeit für Sie eine große Rolle spielt, sind VPC-Cluster möglicherweise die beste Wahl.

Satellite-Cluster

Worker Nodes können auf virtuellen Maschinen bei Cloud-Anbietern wie AWS, Azure, GCP und anderen bereitgestellt werden. Worker Nodes können auch über Ihre eigene Infrastruktur vor Ort bereitgestellt werden.

Klassische Cluster

Worker-Knoten können auf virtuellen und Bare-Metal-Worker-Knoten erstellt werden. Wenn Sie zusätzliche lokale Platten benötigen, können Sie außerdem einen der Bare-Metal-Typen auswählen, die für Software-Defined Storage-Lösungen wie Portworx vorgesehen sind.

Auswahl eines Betriebssystems für den Cluster

Welche Betriebssysteme Ihnen zur Verfügung stehen, hängt von dem von Ihnen gewählten Clustertyp ab.

Red Hat Enterprise Linux (RHEL) Version 8

Klassische VPC Satellite

Red Hat Enterprise Linux auf IBM Cloud bietet Unternehmen eine robuste und skalierbare Umgebung, die mit Blick auf die Sicherheit entwickelt wurde und auf kritische Arbeitslasten zugeschnitten ist. Durch die Verbindung der Red Hat Enterprise Linux-Plattform mit der IBM Cloud-Infrastruktur erhalten Unternehmen Zugang zu Hochverfügbarkeit, Disaster Recovery und optimierten Verwaltungsfunktionen. Einen Überblick über RHEL 8 finden Sie unter Warum sollte Linux auf IBM Cloud laufen?.

CoreOSRed Hat Enterprise Linux (RHCOS)

VPC Satellite

Verfügbar für Cluster, die mit Version 4.15 oder später erstellt wurden. Red Hat Enterprise Linux CoreOS (RHCOS) ist speziell für die Red Hat OpenShift Container Platform (OCP) konzipiert. RHCOS nutzt die Stabilität und Sicherheit von Red Hat Enterprise Linux (RHEL), ist jedoch schlank und minimalistisch und konzentriert sich auf die effiziente und skalierbare Ausführung von containerisierten Arbeitslasten. Da es aus RHEL-Komponenten besteht, erhalten Sie das gleiche Sicherheitsniveau wie RHEL und zusätzlich einen minimalen Container-zentrierten Fußabdruck, ein schreibgeschütztes Dateisystem, Image-basierte Bereitstellungen und mehr. Für einen Überblick über RHCOS siehe Red Hat Enterprise Linux CoreOS(RHCOS). RHCOS-Arbeitsknoten für VPC-Cluster sind nur bei Clustern verfügbar, die mit einer Version erstellt wurden, die RHCOS unterstützt. Cluster, die von einer Version, die RHCOS nicht unterstützt, auf eine Version mit RHCOS-Unterstützung aktualisiert werden, können keine RHCOS-Arbeiter verwenden.

Definieren Sie eine Strategie zur Benennung von Clustern

Verwenden Sie bei der Angabe von Clustern eindeutige Namen für Ressourcengruppen und Regionen in Ihrem Konto, um Namenskonflikte zu vermeiden. Sie können einen Cluster nicht umbenennen, nachdem er erstellt wurde.

Entscheiden Sie, wie viele Arbeitsknoten für jeden Cluster

Der Verfügbarkeitsgrad, den Sie für Ihren Cluster einrichten, hat Auswirkungen auf Ihre Abdeckung in Bezug auf die Bedingungen des IBM Cloud-HA-Service-Level-Agreements. Um beispielsweise eine vollständige HA-Abdeckung gemäß den SLA-Bedingungen zu erhalten, müssen Sie einen Cluster mit mehreren Zonen mit insgesamt mindestens 6 Workerknoten einrichten, zwei Workerknoten pro Zone, die gleichmäßig auf drei Zonen verteilt sind.

Die Gesamtzahl der Workerknoten in einem Cluster bestimmt die Datenverarbeitungsfunktionalität, die für Ihre Apps im Cluster zur Verfügung steht. Sie können Ihre Konfiguration bei einem Ausfall eines Worker-Knotens schützen, indem Sie mehrere Worker-Knoten in Ihrem Cluster einrichten. Ausfälle von Worker-Knoten können Hardwareausfälle wie Strom-, Kühlungs- oder Netzwerkausfälle sowie Probleme auf der VM selbst umfassen.

• Multizonen-Cluster Classic VPC: Planen Sie mindestens zwei Worker-Knoten pro Zone ein, also insgesamt sechs Knoten in drei Zonen. Planen Sie außerdem für die Gesamtkapazität Ihres Clusters mindestens 150 Prozent der erforderlichen Gesamtkapazität für die Workload, sodass Sie, wenn eine Zone ausfällt, Ressourcen für die Aufrechterhaltung der Workload zur Verfügung haben.

• Einzelzone-Cluster Planen Sie mindestens drei Worker-Knoten in Ihrem Cluster ein. Weiterhin benötigen Sie genügend im Cluster verfügbare CPU- und Speicherkapazität für einen zusätzlichen Knoten. Wenn Ihre Apps weniger Ressourcen benötigen als auf dem Worker-Knoten verfügbar sind, können Sie möglicherweise die Anzahl der Pods, die Sie auf einem Worker-Knoten bereitstellen, begrenzen.

Denken Sie daran:

• Sie können den Cluster-Autoscaler ausprobieren, um sicher zu sein, dass Sie immer genügend Worker Nodes haben, um Ihre Arbeitslast abzudecken.
• Kubernetes beschränkt die maximale Anzahl von Workerknoten, die in einem Cluster vorhanden sein können. Weitere Informationen finden Sie unter „ Worker-Knoten und Pod-Kontingente überprüfen“.

Worker-Node-Varianten auswählen

Ein Worker-Knoten ist eine VM, die auf physischer Hardware ausgeführt wird. Ein Workerknotentyp ('Flavor') beschreibt die Datenverarbeitungsressourcen, wie CPU-, Speicher- und Plattenkapazität, die Sie erhalten, wenn Sie Ihren Workerknoten bereitstellen. Workerknoten desselben Typs werden in Workerknotenpools zusammen gruppiert.

Bei der Auswahl eines Clustertyps haben Sie bereits darüber nachgedacht, wie sich der Standort des Worker Node Flavor und der Maschinentyp auf Ihre Entscheidung auswirken. Bei der Auswahl der Worker-Node-Varianten sollten Sie Folgendes beachten.

• Tenancy: Je nach dem von Ihnen benötigten Grad der Hardware-Isolierung können virtuelle Arbeitsknoten so eingerichtet werden, dass sie von mehreren IBM Kunden gemeinsam genutzt werden (Multi-Tenancy) oder nur für Sie bestimmt sind (Single-Tenancy). Bare-Metal-Maschinen werden immer als dediziert eingerichtet. Wenn Sie sich zwischen gemeinsam genutzten und dedizierten Knoten entscheiden, sollten Sie sich möglicherweise mit Ihrer Rechtsabteilung in Verbindung setzen, um den Grad der Infrastrukturisolierung und Compliance zu besprechen, den Ihre Anwendungsumgebung erfordert.

  • Gemeinsam genutzt: Physische Ressourcen wie CPU und Arbeitsspeicher werden von allen virtuellen Maschinen gemeinsam genutzt, die auf derselben physischen Hardware bereitgestellt werden. Um sicherzustellen, dass jede virtuelle Maschine unabhängig von anderen Maschinen ausgeführt werden kann, segmentiert ein VM-Monitor, d. h. eine Überwachungsfunktion für virtuelle Maschinen, die auch als Hypervisor bezeichnet wird, die physischen Ressourcen in isolierte Entitäten und ordnet diese einer virtuellen Maschine als dedizierte Ressourcen zu. Dies wird als Hypervisor-Isolation bezeichnet. Gemeinsam genutzte Knoten sind in der Regel kostengünstiger als dedizierte Knoten, weil die Kosten für die ihnen zugrunde liegende Hardware von mehreren Kunden getragen werden.
  • Gewidmet: Alle physischen Ressourcen sind nur für Sie bestimmt. Sie können mehrere Workerknoten als virtuelle Maschinen auf demselben physischen Host bereitstellen. Ähnlich wie bei der Multi-Tenant-Konfiguration stellt der Hypervisor auch hier sicher, dass jeder Workerknoten seinen Anteil an den verfügbaren physischen Ressourcen erhält.

• Maschinentyp: Sie haben eine Reihe von Maschinentypen zur Auswahl.

  • Virtuelle Maschinen: Größere Flexibilität, kürzere Bereitstellungszeiten, mehr automatische Skalierbarkeitsfunktionen und ein günstigerer Preis: Verwenden Sie VMs. Sie können virtuelle Maschinen für die meisten allgemeinen Anwendungsfälle, wie Test- und Entwicklungsumgebungen, Staging- und Produktionsumgebungen, Microservices und Business-Apps, verwenden. Allerdings gibt es einen Kompromiss bei der Leistung.

  • Bare-Metal-Maschinen (physisch): Wenn Sie Hochleistungsrechner für daten- oder RAM-intensive Workloads benötigen, sollten Sie die Einrichtung klassischer Cluster mit Bare-Metal-Worker-Knoten in Betracht ziehen. Da Sie die uneingeschränkte Kontrolle über die Isolation und die Ressourcenauslastung für Ihre Workloads besitzen, können Sie Bare-Metal-Maschinen einsetzen, um HIPAA- und PCI-Konformität für Ihre Umgebung zu erzielen. Mit Bare-Metal haben Sie direkten Zugriff auf die physischen Ressourcen auf der Maschine, wie z. B. Speicher oder CPU. Durch diese Konfiguration wird der Hypervisor der virtuellen Maschine entfernt, der physische Ressourcen zu virtuellen Maschinen zuordnet, die auf dem Host ausgeführt werden. Stattdessen sind alle Ressourcen einer Bare-Metal-Maschine ausschließlich dem Worker zugeordnet, sodass Sie sich keine Sorgen machen müssen, dass "verrauschte Nachbarn" Ressourcen gemeinsam nutzen oder die Leistung verlangsamen. Physische Typen verfügen über einen größeren lokalen Speicher als virtuelle und einige verfügen zur Steigerung der Datenverfügbarkeit zudem über RAID. Der lokale Speicher auf dem Worker-Knoten dient nur zur kurzfristigen Verarbeitung, und die primären und sekundären Festplatten werden gelöscht, wenn Sie den Worker-Knoten aktualisieren oder neu laden. Physische Maschinen sind nur für klassische Cluster verfügbar und werden in VPC-Clustern nicht unterstützt.

    Die Abrechnung für Bare-Metal-Server erfolgt monatlich. Wenn Sie einen Bare-Metal-Server vor Monatsende stornieren, werden Ihnen die Kosten bis zum Ende dieses Monats in Rechnung gestellt. Nachdem Sie einen Bare-Metal-Server bestellt oder storniert haben, wird der Prozess manuell in Ihrem Konto für die IBM Cloud-Infrastruktur ausgeführt. Die Ausführung kann daher länger als einen Geschäftstag dauern.

  • SDS-Maschinen: Software-defined Storage (SDS) Flavors verfügen über zusätzliche Raw Disks für physischen lokalen Speicher. Im Gegensatz zur primären und sekundären lokalen Festplatte werden diese Raw-Festplatten bei einer Aktualisierung oder einem Neuladen des Worker-Knotens nicht gelöscht. Da sich die Daten auf derselben Maschine wie der Datenverarbeitungsknoten befinden, eignen sich SDS-Maschinen für Workloads mit hoher Leistungsanforderung. Softwaredefinierte Speichertypen sind nur für klassische Cluster verfügbar und werden in VPC-Clustern nicht unterstützt.

    Da Sie die uneingeschränkte Kontrolle über die Isolation und die Ressourcenauslastung für Ihre Workloads besitzen, können Sie SDS-Maschinen einsetzen, um HIPAA- und PCI-Konformität für Ihre Umgebung zu erzielen.

    Normalerweise verwenden Sie SDS-Maschinen in den folgenden Fällen:

    • Wenn Sie ein SDS-Add-on wie verwenden Portworx, verwenden Sie eine SDS-Maschine.
    • Wenn Ihre App lokalen StatefulSet Speicher benötigt, können Sie SDS-Maschinen verwenden und lokale persistente Kubernetes Volumes bereitstellen.
    • Wenn Sie über angepasste Apps verfügen, die zusätzlichen unaufbereiteten lokalen Speicher erfordern.

• Kosten: Im Allgemeinen eignen sich Ihre intensiven Workloads eher für die Ausführung auf physischen Bare-Metal-Maschinen, während Sie für kostengünstige Test- und Entwicklungsarbeiten möglicherweise virtuelle Maschinen auf gemeinsam genutzter oder dedizierter Hardware wählen.

• Standort: Entscheiden Sie, an welchen Standorten Sie einen Cluster haben möchten. Der Ort, an dem Sie sie benötigen, kann auch Aufschluss darüber geben, wie viele Cluster oder welche Art von Clustern Sie benötigen. Wenn Sie z. B. wissen, dass der Ort in Montreal liegen muss, können Sie Ihre Auswahl einschränken. Sehen Sie sich die verfügbaren Standorte an.

• Größe: Größere Knoten können kosteneffizienter sein als kleinere Knoten, insbesondere bei Workloads, die für eine effizientere Verarbeitung auf einem Hochleistungsrechner ausgelegt sind. Wenn jedoch ein großer Worker-Knoten ausfällt, müssen Sie sicherstellen, dass Ihr Cluster über genügend Kapazität verfügt, um alle Workload-Pods sicher auf andere Worker-Knoten im Cluster umzuplanen. Kleinere Arbeitsknoten können Ihnen helfen, sicher zu skalieren. Erfahren Sie mehr über Kapazität.

• GPUs: Sie können eine GPU-Maschine verwenden, um die Verarbeitungszeit zu beschleunigen, die für rechenintensive Workloads wie KI, maschinelles Lernen, Inferenzierung und mehr erforderlich ist.

• Speicher: Jede VM verfügt über eine zugeordnete Festplatte zur Speicherung von Informationen, die die VM zum Ausführen benötigt, z. B. das Betriebssystem-Dateisystem, die Container-Laufzeitumgebung und die kubelet. Der lokale Speicher auf dem Workerknoten ist nur für die kurzfristige Verarbeitung vorgesehen und die Speicherplatten werden gelöscht, wenn Sie den Workerknoten löschen, erneut laden, ersetzen oder aktualisieren. Darüber hinaus unterscheiden sich die klassische und die VPC-Infrastruktur in der Plattenkonfiguration.

  • Klassische VMs: Klassische VMs verfügen über zwei zugeordnete Platten. Die primäre Speicherfestplatte verfügt über 25 GB für das Betriebssystem-Dateisystem, und die zusätzliche Speicherfestplatte verfügt über 100 GB für Daten wie die Container-Laufzeitumgebung und die kubelet. Aus Gründen der Zuverlässigkeit sind die primären und sekundären Speichervolumes lokale Festplatten statt Storage Area Networking (SAN). Zu den Vorteilen zählen ein höherer Durchsatz beim Serialisieren von Bytes für die lokale Festplatte und weniger Beeinträchtigungen des Dateisystems aufgrund von Netzausfällen. Die Zusatzfestplatte ist standardmäßig verschlüsselt.
  • VPC-Rechen-VMs: VPC-VMs verfügen über eine primäre Festplatte, bei der es sich um ein Blockspeichervolumen handelt, das über das Netzwerk angeschlossen ist. Die Speicherschicht wird nicht von den anderen Netzebenen getrennt und sowohl der Netz- als auch der Speicherdatenverkehr werden über dasselbe Netz weitergeleitet. Die primäre Speicherplatte wird zum Speichern von Daten wie dem Dateisystem des Betriebssystems, der Containerlaufzeit und dem kubelet verwendet und ist standardmäßig verschlüsselt. Bei VPC-Clustern können Sie auch eine sekundäre Festplatte auf Ihren Worker-Knoten bereitstellen. Diese optionale Festplatte wird in Ihrem Konto bereitgestellt und Sie können sie in der VPC-Konsole sehen. Die Kosten für diese Disketten werden getrennt von den Kosten für die einzelnen Mitarbeiter berechnet und auf Ihrer Rechnung unter einem anderen Posten ausgewiesen. Diese sekundären Volumes werden ebenfalls auf die Kontingentnutzung für Ihr Konto angerechnet. Um eine standardmäßige Pod-Entfernung zu verhindern, sind 10 % der Kubernetes Datendisk (Hilfsdisk in Classic, primäre Bootdisk in VPC) für Systemkomponenten reserviert.

  In einer statusabhängigen App spielen Daten eine wichtige Rolle, um Ihre App betriebsbereit zu halten. Stellen Sie sicher, dass Ihre Daten hoch verfügbar sind, sodass Sie nach einem möglichen Ausfall eine Wiederherstellung vornehmen können. In Red Hat OpenShift on IBM Cloud können Sie aus mehreren Optionen auswählen, um Ihre Daten als persistent zu definieren. Sie können zum Beispiel NFS-Speicher bereitstellen, indem Sie native, persistente Kubernetes-Datenträger verwenden oder Ihre Daten mithilfe eines IBM Cloud-Datenbankservice speichern. Weitere Informationen finden Sie unter Planung hochverfügbarer Daten.

  Wählen Sie eine Geschmacksrichtung oder einen Maschinentyp mit der richtigen Speicherkonfiguration, um Ihre Arbeitslast zu unterstützen. Einige Typen verfügen über eine Kombination aus den folgenden Platten und Speicherkonfigurationen. Beispielsweise können bestimmte Typen über eine SATA-Primärplatte mit einer unformatierten SSD-Sekundärplatte verfügen.

Eine Liste der verfügbaren Flavors finden Sie unter VPC Gen 2 Flavors oder Classic Flavors.

Bestimmen der Arbeitsknotenkapazität für die Ressourcen

Um die Leistung Ihres Worker Nodes optimal zu nutzen, sollten Sie beim Einrichten Ihrer Ressourcen Folgendes beachten:

• Überlegen Sie, was Ihre Anwendung macht: Beginnen Sie damit, die Größe der Anwendung mit der Kapazität einer der verfügbaren Worker-Node-Varianten abzustimmen. Berücksichtigen Sie auch, ob Ihre App große oder viele Bilder lädt, da diese lokalen Speicherplatz auf dem Worker-Knoten belegen können.

• Behalten Sie die Stärke Ihrer Kerne bei: Jede Maschine besitzt eine bestimmte Anzahl von Kernen. Legen Sie abhängig von der Workload Ihrer App eine Begrenzung für die Anzahl der Pods pro Kern fest, z. B. 10.

• Vermeiden Sie eine Überlastung der Knoten: Halten Sie die Auslastung Ihres Worker-Knotens bei etwa 75 %, um Platz für andere Pods zu lassen, die möglicherweise geplant werden müssen. Wenn Ihre Apps mehr Ressourcen benötigen, als Sie auf Ihrem Workerknoten zur Verfügung haben, verwenden Sie einen anderen Workerknotentyp, der diese Anforderungen erfüllen kann. Legen Sie abhängig von der Workload Ihrer App eine Begrenzung für die Anzahl der Pods pro Knoten fest, z. B. 40.

• Auswahl der Dienste: Für wie viele Dienstintegrationen haben Sie sich entschieden, als Sie darüber nachdachten, wie viele Cluster Sie erstellen wollten? Diese integrierten Dienste und Add-ons können Pods starten, die Cluster-Ressourcen verbrauchen und beeinflussen.

• Replikate Ihrer App: Um die Anzahl der gewünschten Workerknoten zu ermitteln, können Sie auch die Anzahl der Replikate Ihrer App berücksichtigen, die Sie ausführen möchten. Wenn Sie beispielsweise wissen, dass Ihre Workload 32 CPU-Kerne benötigt, und Sie planen, 16 Replikate Ihrer App auszuführen, benötigt jeder Replikat-Pod 2 CPU-Kerne. Wenn Sie pro Workerknoten nur eine App-Pod ausführen möchten, können Sie eine entsprechende Anzahl von Workerknoten für Ihren Clustertyp bestellen, um diese Konfiguration zu unterstützen.

• Raum für Laufzeitanforderungen lassen: Worker-Knoten müssen bestimmte Mengen an CPU- und Speicherressourcen reservieren, um erforderliche Komponenten wie das Betriebssystem oder die Container-Laufzeit auszuführen.

  Reservierte Kapazität und reservierte Instanzen werden nicht unterstützt.

Wählen Sie, wie viele Namensräume innerhalb des Clusters erstellt werden sollen

Richten Sie mehrere Namensbereiche ein, wenn Sie mehrere Teams und Projekte haben, die den Cluster gemeinsam nutzen. Namespaces sind eine Möglichkeit, Cluster-Ressourcen mit Hilfe von Ressourcenquoten und Standardgrenzen aufzuteilen. Wenn Sie neue Namensbereiche erstellen, achten Sie darauf, dass Sie die richtigen RBAC-Richtlinien für die Zugriffssteuerung einrichten. Weitere Informationen finden Sie unter „ Cluster mit Namespaces freigeben “ in der Kubernetes Dokumentation.

Wenn Sie einen kleinen Cluster haben, nur ein paar Dutzend Benutzer und einander ähnliche Ressourcen (wie z. B. verschiedene Versionen derselben Software), benötigen Sie wahrscheinlich keine Vielzahl an Namensbereichen. Stattdessen können Sie Bezeichnungen verwenden.

Lesen Sie die Sicherheitsinformationen zu dieser Entscheidung in Container Isolation und Sicherheit.

Festlegung von Ressourcenanforderungen und -grenzen für die Namensräume

Um sicherzustellen, dass jedes Team über die erforderlichen Ressourcen verfügt, um Dienste bereitzustellen und Anwendungen im Cluster auszuführen, müssen Sie für jeden Namespace Ressourcenquoten festlegen. Ressourcenquoten legen die Bereitstellungsbeschränkungen fest, z. B. die Anzahl der Kubernetes Ressourcen, die Sie bereitstellen können, und die Menge an CPU und Arbeitsspeicher, die von diesen Ressourcen verbraucht werden kann. Nachdem Sie eine Beschränkung festgelegt haben, müssen Benutzer Ressourcenanforderungen und -begrenzungen in ihre Bereitstellungen aufnehmen.

Wenn Sie eine Bereitstellung erstellen, beschränken Sie diese auch so, dass der Pod Ihrer App nur auf Maschinen mit der besten Ressourcenkonstellation bereitgestellt wird. Sie können beispielsweise eine Datenbankanwendung auf eine Bare-Metal-Maschine begrenzen, die einen großen lokalen Plattenspeicher hat, wie md1c.28x512.4x4tb.

Machen Sie auch Ihre Anwendungen hochverfügbar

Container und Pods sind per Definition Komponenten mit kurzer Lebensdauer, die kurzfristig und unerwartet ausfallen können. Ein Container oder Pod kann ausfallen, wenn ein Fehler in Ihrer App auftritt. Um die Hochverfügbarkeit Ihrer App zu gewährleisten, müssen Sie sicherstellen, dass Sie über genügend Instanzen verfügen, um die Arbeitslast zu bewältigen, sowie über zusätzliche Instanzen für den Fall eines Ausfalls. Sie können sicherstellen, dass genügend Instanzen vorhanden sind, indem Sie automatische Skalierung einrichten.

Nächste Schritte

Um mit der Planung fortzufahren, wählen Sie zwischen VPC-Cluster-Vernetzung und Classic-Cluster-Vernetzung. Wenn Sie bereit sind, einen Cluster zu erstellen, beginnen Sie zunächst mit Vorbereitung Ihres Kontos für die Erstellung von Clustern.