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: Die Verwaltung mehrerer Cluster ist in der Regel komplexer, kann 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 Anwendung erhöhen, indem Sie drei Cluster über verschiedene Zonen hinweg einrichten.
  • Senken Sie Ihre Kosten, indem Sie kleinere Maschinen erwerben, die Ihre Arbeitslast bewältigen können.

• 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, Ressourcenkontingenten 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, hängt von den Entscheidungen ab, die Sie hinsichtlich der Anzahl der Cluster und der Standorte getroffen haben.

VPC-Cluster (empfohlen)

Worker-Knoten werden als virtuelle Serverinstanzen auf der VPC-Infrastruktur bereitgestellt. VPC ist der empfohlene Infrastrukturtyp für neue Cluster. Es bietet standardmäßig Netzwerkisolierung und unterstützt die neuesten Funktionen von „ Red Hat OpenShift on IBM Cloud “, darunter dedizierte Hosts und „Secure by Default“.

Satellite-Cluster

Worker-Knoten werden in Ihrer eigenen Infrastruktur bereitgestellt, einschließlich lokaler Hardware oder virtueller Maschinen bei anderen Cloud-Anbietern wie AWS, Azure und GCP. Verwenden Sie „ Satellite “, wenn Sie von „ IBM Cloud “ verwaltete Cluster außerhalb der Rechenzentren von „ IBM Cloud “ betreiben möchten.

Klassische Cluster

Worker-Knoten werden auf virtuellen Maschinen oder Bare-Metal-Servern in der klassischen Infrastruktur v IBM Cloud bereitgestellt. Verwenden Sie „Classic“, wenn Sie Bare-Metal-Worker-Knoten, Software-Defined-Storage-Varianten (SDS) oder Verbindungen zu bestehenden Ressourcen der klassischen Infrastruktur benötigen.

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 CoreOS (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 das Red Hat OpenShift Container Platform (OCP) konzipiert. RHCOS nutzt die Stabilität und Sicherheit von Red Hat Enterprise Linux (RHEL), ist jedoch leichtgewichtig 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.

Ab der Version 4.18 sind RHEL Worker Nodes für VPC-Cluster veraltet. Die Version 4.22 ist die letzte Version, die RHEL-Worker-Knoten in VPC unterstützt. Zukünftige Versionen erfordern RHCOS-Worker-Knoten. Weitere Informationen finden Sie unter RHEL-Abkündigung für VPC-Cluster.

Red Hat Enterprise Linux (RHEL) Version 9

Klassische VPC

Verfügbar für Cluster, die mit der Version 4.16 und später erstellt wurden. Red Hat Enterprise Linux auf IBM Cloud bietet Unternehmen eine robuste und skalierbare Umgebung, die auf Sicherheit ausgelegt und auf kritische Workloads zugeschnitten ist. Unternehmen erhalten Zugang zu Hochverfügbarkeit, Disaster Recovery und optimierten Verwaltungsfunktionen, indem sie die Plattform Red Hat Enterprise Linux mit der Infrastruktur von IBM Cloud verbinden. Einen Überblick über RHEL 9 finden Sie unter Warum Linux auf IBM Cloud? ausführen?

Red Hat Enterprise Linux (RHEL) Version 8

Klassische VPC

Verfügbar für Cluster, die mit Version 4.15 und früher erstellt wurden. RHEL 8 hat das Ende seiner Lebensdauer am 31. Mai 2024 erreicht. Weitere Informationen finden Sie unter Red Hat Enterprise Linux 8 Life Cycle.

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. Zu den Ausfällen von Worker-Knoten können Hardwareausfälle wie Strom-, Kühlungs- oder Netzwerkausfälle sowie Probleme auf dem VM selbst gehören.

• Multizonen-Cluster Classic VPC: Planen Sie mindestens zwei Worker-Knoten pro Zone ein, also insgesamt sechs Knoten über drei Zonen verteilt. 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.

• Cluster mit einer Zone 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 Anwendungen weniger Ressourcen benötigen, als auf dem Worker-Knoten verfügbar sind, können Sie möglicherweise die Anzahl der Pods begrenzen, die Sie auf einem Worker-Knoten bereitstellen.

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 Quoten für Worker-Knoten und Pods.

Worker-Node-Varianten auswählen

Ein Worker-Knoten ist ein VM, der 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 die Compliance-Anforderungen zu besprechen, die Ihre Anwendungsumgebung erfordert.

  • Gemeinsam genutzt: Physische Ressourcen wie CPU und Arbeitsspeicher werden von allen virtuellen Maschinen gemeinsam genutzt, die auf derselben physischen Hardware bereitgestellt sind. 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 dabei Abstriche bei der Leistung.

  • Bare-Metal-Maschinen (physische Maschinen): Wenn Sie Hochleistungsrechner für daten- oder RAM-intensive Workloads benötigen, sollten Sie die Einrichtung von Clustern 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 ausschließlich der kurzfristigen Verarbeitung, und die Haupt- und Zusatzfestplatten werden gelöscht, wenn Sie den Worker-Knoten aktualisieren oder neu laden. Für klassische Cluster und für VPC-Bare-Metal-Konfigurationen stehen Bare-Metal-Mitarbeiter zur Verfügung.

    Die Abrechnung für Bare-Metal-Worker-Knoten variiert je nach Infrastrukturtyp. Klassische Bare-Metal-Server werden monatlich abgerechnet. Wenn Sie einen klassischen Bare-Metal-Server vor Monatsende kündigen, fallen die Kosten bis zum Ende dieses Monats an. Nachdem Sie einen klassischen Bare-Metal-Server bestellt oder storniert haben, wird der Vorgang manuell in Ihrem „ IBM Cloud “-Infrastrukturkonto abgeschlossen, sodass es mehr als einen Werktag dauern kann, bis der Vorgang abgeschlossen ist. VPC-Bare-Metal-Server werden stundenweise abgerechnet, ohne Mindestvertragslaufzeit.

  • 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 zur sekundären lokalen Festplatte werden diese Raw-Festplatten bei einer Aktualisierung oder einem Neustart 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 Portworx verwenden, nutzen Sie eine SDS-Maschine. * Wenn es sich bei Ihrer App um eine StatefulSet handelt, die lokalen Speicher benötigt, können Sie SDS-Maschinen verwenden und über Kubernetes lokale persistente Volumes bereitstellen. * Wenn Sie über angepasste Apps verfügen, die zusätzlichen unaufbereiteten lokalen Speicher erfordern.

• Kosten: Im Allgemeinen eignen sich Ihre rechenintensiven Workloads besser für den Betrieb auf physischen Bare-Metal-Servern, während Sie für kostengünstige Test- und Entwicklungsaufgaben möglicherweise virtuelle Maschinen auf gemeinsam genutzter oder dedizierter Hardware wählen sollten.

• 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.

• Umfang: Größere Knoten können kosteneffizienter sein als kleinere Knoten, insbesondere bei Workloads, die darauf ausgelegt sind, bei der Verarbeitung auf einem Hochleistungsrechner an Effizienz zu gewinnen. Sollte jedoch ein großer Worker-Knoten ausfallen, 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 umzuverteilen. Kleinere Arbeitsknoten können Ihnen helfen, sicher zu skalieren. Erfahren Sie mehr über die 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: Jeder VM verfügt über eine angeschlossene Festplatte zur Speicherung von Informationen, die der VM zum Ausführen benötigt, wie z. B. das Dateisystem des Betriebssystems, 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 Festplatte verfügt über 25 GB für das Dateisystem des Betriebssystems, und die zusätzliche Festplatte bietet 100 GB für Daten wie die Container-Laufzeitumgebung und die kubelet. Aus Gründen der Zuverlässigkeit handelt es sich bei den Primär- und Zusatzspeichervolumes um lokale Festplatten anstelle eines Storage Area Network (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-Compute-VMs: VPC-VMs verfügen über eine primäre Festplatte, bei der es sich um ein Blockspeichervolume handelt, das über das Netzwerk angebunden 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 wurde in Ihrem Konto bereitgestellt und ist in der VPC-Konsole einsehbar. 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. Auch diese sekundären Volumina werden auf die Kontingentnutzung Ihres Kontos angerechnet. Um eine standardmäßige Pod-Entfernung zu verhindern, werden 10 % der Datenfestplatte des Kubernetes (Zusatzfestplatte in Classic, primäre Boot-Festplatte 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 Instanzvariante 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-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 außerdem, ob Ihre App große oder viele Bilder abruft, da diese Speicherplatz auf dem lokalen Speicher des Worker-Knotens beanspruchen 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 eingeplant 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 beanspruchen 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äten 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 Einen Cluster mit Namespaces freigeben in der Dokumentation zu Kubernetes.

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 Ressourcenkontingente einrichten. Ressourcenkontingente legen die Bereitstellungsbeschränkungen fest, beispielsweise die Anzahl der Kubernetes-Ressourcen, die Sie bereitstellen können, sowie die Menge an CPU-Leistung und Arbeitsspeicher, die von diesen Ressourcen beansprucht werden darf. Nachdem Sie eine Beschränkung festgelegt haben, müssen Benutzer Ressourcenanforderungen und -begrenzungen in ihre Bereitstellungen aufnehmen.

Wenn Sie eine Bereitstellung erstellen, schränken Sie diese außerdem so ein, dass der Pod Ihrer App nur auf Maschinen mit der optimalen Kombination von Ressourcen 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 eine hohe Verfü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.

Laufende Best Practices

Befolgen Sie diese bewährten Vorgehensweisen, nachdem Ihr Cluster in Betrieb genommen wurde, um dessen Sicherheit und einwandfreien Betrieb zu gewährleisten.

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.