Vorbereitung der Clusterknotenmaschinen

Google Distributed Cloud unterstützt eine Vielzahl von Systemen auf der Hardware, die von den Zielbetriebssystem-Distributionen unterstützt wird. Eine Google Distributed Cloud-Konfiguration kann auf minimaler Hardware oder auf mehreren Maschinen ausgeführt werden, um Flexibilität, Verfügbarkeit und Leistung zu ermöglichen.

Unabhängig von Ihrer Google Distributed Cloud-Konfiguration müssen Ihre Knoten und Cluster über genügend CPU-, RAM- und Speicherressourcen verfügen, um den Anforderungen von Clustern und ausgeführten Arbeitslasten gerecht zu werden.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die IT-Lösungen und die Systemarchitektur gemäß der Unternehmensstrategie definieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud-Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

Wenn Sie Google Distributed Cloud installieren, können Sie verschiedene Arten von Clustern erstellen:

  • Ein Nutzercluster, der Arbeitslasten ausführt.
  • Ein Administratorcluster der Nutzercluster zur Ausführung von Arbeitslasten erstellt und steuert.
  • Ein eigenständiger Cluster ist ein einzelner Cluster, der Arbeitslasten verwalten und ausführen kann. Ein eigenständiger Cluster kann jedoch keine Nutzercluster erstellen oder verwalten.
  • Ein Hybridcluster kann Arbeitslasten verwalten und ausführen. Ein Hybridcluster kann außerdem zusätzliche Nutzercluster erstellen und verwalten.

Zusätzlich zum Clustertyp können Sie in Bezug auf die Ressourcenanforderungen aus den folgenden Installationsprofilen auswählen:

  • Standard: Das Standardprofil hat Standardanforderungen an Systemressourcen, die für alle Clustertypen verwendet werden können.

  • Edge: Das Edge-Profil hat die Systemressourcenanforderungen erheblich reduziert. Die Verwendung dieses Profils wird für Edge-Geräte mit begrenzten Ressourcen empfohlen. Sie können das Edge-Profil nur für eigenständige Cluster verwenden.

Ressourcenanforderungen für alle Clustertypen mit dem Standardprofil

In der folgenden Tabelle werden die mindestens erforderlichen und empfohlenen Hardwarevoraussetzungen für Google Distributed Cloud beschrieben, um Administrator-, Hybrid-, Nutzer- und eigenständige Cluster über das Standardprofil zu betreiben und zu verwalten.

Ressource Minimum Empfohlen
CPUs / vCPUs* 4 Core 8 Core
RAM 16 GiB 32 GiB
Speicherplatz 128 GiB 256 GiB

* Google Distributed Cloud unterstützt nur x86-64-CPUs und vCPUs auf CPU-Mikroarchitekturebene (x86-64-v3) und höher.

Ressourcenanforderungen für eigenständige Cluster mit dem Edge-Profil

In der folgenden Tabelle werden die mindestens erforderlichen und empfohlenen Hardwarevoraussetzungen für Google Distributed Cloud beschrieben, um eigenständige Cluster mit dem Edge-Profil zu betreiben und zu verwalten:

Ressource Minimum Empfohlen
CPUs / vCPUs* 2 Core 4 Core
RAM Ubuntu: 4 GiB

RHEL: 6 GiB

 Ubuntu: 8 GiB

RHEL: 12 GiB
Speicherplatz 128 GiB 256 GiB

* Google Distributed Cloud unterstützt nur x86-64-CPUs und vCPUs auf CPU-Mikroarchitekturebene (x86-64-v3) und höher.

So konfigurieren Sie eigenständige Cluster mit dem Edge-Profil:

  • Führen Sie bmctl auf einer separaten Workstation aus. Wenn Sie bmctl auf dem Zielclusterknoten ausführen müssen, benötigen Sie 2 GiB Arbeitsspeicher, um die Mindestanforderungen zu erfüllen. Beispiel: Sie benötigen 6 GiB für Ubuntu und 8 GiB für RHEL.

  • Legen Sie MaxPodsPerNode auf 110 fest. Der Cluster führt im Durchschnitt nicht mehr als 30 Nutzer-Pods pro Knoten aus. Für eine höhere MaxPodsPerNode-Konfiguration benötigen Sie möglicherweise zusätzliche Ressourcen oder führen mehr als 30 Nutzer-Pods pro Knoten aus.

  • Die Komponenten von VM Runtime on GDC werden in dieser Konfiguration von Mindestressourcen nicht berücksichtigt. Je nach Anzahl der im Cluster bereitgestellten VMs benötigt VM Runtime on GDC zusätzliche Ressourcen.

Zusätzliche Speicheranforderungen

Google Distributed Cloud stellt keine Speicherressourcen zur Verfügung. Sie müssen den erforderlichen Speicher auf Ihrem System bereitstellen und konfigurieren.

Ausführliche Informationen zu den Speicheranforderungen finden Sie unter Voraussetzungen für die Installation: Übersicht.

Weitere Informationen zur Konfiguration des erforderlichen Speichers finden Sie unter Speicher für Google Distributed Cloud konfigurieren.

Voraussetzungen für Knotenrechner

Für Knotenrechner gelten folgende Voraussetzungen:

  • Die Mindestanforderungen an die Hardware werden erfüllen
  • Das Betriebssystem ist eine der unterstützten Linux-Distributionen. Weitere Informationen, einschließlich der Kernel-Anforderungen, finden Sie unter Betriebssystem auswählen.
  • Internetzugriff.
  • Ebene-3-Verbindung zu allen anderen Knotenmaschinen
  • Zugriff auf die VIP der Steuerungsebene.
  • Zugriff auf erforderliche Ports Spezifische Portanforderungen für Knoten der Steuerungsebene, Worker-Knoten und Load Balancer-Knoten finden Sie auf der Seite „Netzwerkanforderungen“ unter Portnutzung.
  • Korrekt konfigurierte DNS-Nameserver.
  • Keine doppelten Hostnamen.
  • Einer der folgenden NTP-Dienste muss aktiviert sein und funktionieren:
    • chrony
    • ntp
    • ntpdate
    • systemd-timesyncd
  • Ein funktionsfähiger Paketmanager, z. B. apt oder dnf.

  • Unter Ubuntu müssen Sie Uncomplicated Firewall (UFW) deaktivieren. Führen Sie systemctl stop ufw aus, um UFW zu deaktivieren.

  • Eines der folgenden Netzwerk-Kernelmodule muss geladen sein:

    • ip_tables (dies unterscheidet sich vom Frontend-Debian-Paket iptables, das nicht erforderlich ist)
    • nf_tables

    Führen Sie den folgenden Befehl aus, um ein Modul zu laden:

    modprobe MODULE_NAME

  • Bei der Clustererstellung wird nur auf den erforderlichen freien Speicherplatz für die Google Distributed Cloud-Systemkomponenten geprüft. Mit dieser Änderung haben Sie mehr Kontrolle über den Speicherplatz, den Sie Anwendungsarbeitslasten zuweisen. Achten Sie beim Installieren von Google Distributed Cloud darauf, dass die Dateisysteme, die die folgenden Verzeichnisse sichern, die erforderliche Kapazität haben und die folgenden Anforderungen erfüllen:

    • /: 17 GiB (18.253.611.008 Byte).
    • /var/lib/containerd:
      • 30 GiB (32.212.254.720 Byte) für Knoten der Steuerungsebene.
      • 10 GiB (10.485.760 Byte) für Worker-Knoten.
    • /var/lib/kubelet: 500 MiB (524.288.000 Byte).
    • /var/lib/etcd: 20 GiB (21.474.836.480 Byte nur für Knoten der Steuerungsebene).

    • /var/lib/etcd-events: 5 GiB (5,368,709,120 Byte nur für Knoten der Steuerungsebene)

    Unabhängig von der Clusterversion können sich die vorherigen Verzeichnislisten in denselben oder in unterschiedlichen Partitionen befinden. Wenn sie sich in derselben zugrunde liegenden Partition befinden, entspricht der Speicherplatzbedarf der Summe des Speicherplatzes, der für jedes einzelne Verzeichnis in dieser Partition erforderlich ist. Bei allen Releaseversionen erstellt der Cluster die Verzeichnisse, sofern erforderlich.

  • Die Verzeichnisse /var/lib/etcd und /etc/kubernetes sind entweder nicht vorhanden oder leer.

  • Bei Maschinen mit RHEL 9.2 oder Ubuntu 22.04 müssen die inotify-Limits des Linux-Kernels für die maximale Anzahl von Nutzerinstanzen und Nutzerüberwachungen größer oder gleich Folgendem sein:

    • fs.inotify.max_user_instances: 8192
    • fs.inotify.max_user_watches: 524288

    Weitere Informationen finden Sie in der Konfigurationsdokumentation für RHEL oder Ubuntu.

Zusätzlich zu den Voraussetzungen für die Installation und Ausführung von Google Distributed Cloud müssen Kunden die relevanten Standards ihrer Branche oder ihres Geschäftssegments erfüllen, z. B. die PCI-DSS-Anforderungen für Unternehmen, die Kreditkarten verarbeiten, oder SISGs (Security Technical Implementation Guides) für Unternehmen in der Verteidigungsindustrie.

Voraussetzungen für Load-Balancer-Rechner

Wenn Ihre Bereitstellung über keinen speziellen Load-Balancer-Knotenpool verfügt, können Sie Worker-Knoten oder Steuerungsebenenknoten erstellen, um einen Load-Balancer-Knotenpool zu erstellen. Für diesen Fall gelten zusätzliche Voraussetzungen:

  • Maschinen befinden sich im selben Ebene-2-Subnetz.
  • Alle VIPs befinden sich im Subnetz des Load-Balancer-Knotens und können vom Gateway des Subnetzes aus verbunden werden.
  • Das Gateway des Load-Balancer-Subnetzes sollte nicht relevante ARPs erfassen, um Pakete an den Master-Load-Balancer weiterzuleiten.

Nächste Schritte