Vorbereitung der Clusterknotenmaschinen

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

Unabhängig von Ihrer Google Distributed Cloud-Konfiguration müssen Ihre Knoten und Cluster genügend CPU-, RAM- und Speicherressourcen haben, um die Anforderungen der Cluster und der von Ihnen ausgeführten Arbeitslasten zu erfüllen.

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 Mindest- und empfohlenen Hardwareanforderungen beschrieben, die Google Distributed Cloud benötigt, um Administrator-, Hybrid-, Nutzer- und eigenständige Cluster mit dem Standardprofil auszuführen und zu verwalten:

Ressource Minimum Chrome Enterprise Recommended
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 v3 (x86-64-v3) und höher.

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

In der folgenden Tabelle werden die Mindestanforderungen und empfohlenen Hardwareanforderungen beschrieben, die Google Distributed Cloud zum Betrieb und Verwalten von eigenständigen Clustern mit dem Edge-Profil benötigt:

Ressource Minimum Chrome Enterprise Recommended
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 v3 (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.

  • Komponenten der VM-Laufzeit auf GDC werden in dieser Mindestressourcenkonfiguration nicht berücksichtigt. Die VM-Laufzeit auf GDC erfordert je nach Anzahl der im Cluster bereitgestellten VMs 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 Kernelanforderungen, finden Sie unter Betriebssystem auswählen.
  • Internetzugriff.
  • Ebene-3-Verbindung zu allen anderen Knotenmaschinen
  • Zugriff auf die VIP der Steuerungsebene.
  • Zugriff auf erforderliche Ports. Informationen zu bestimmten Portanforderungen für Knoten der Steuerungsebene, Worker-Knoten und Load-Balancer-Knoten finden Sie auf der Seite "Netzwerkanforderungen" unter Portnutzung.
  • Richtig konfigurierte DNS-Nameserver.
  • Keine doppelten Hostnamen.
  • Einer der folgenden NTP-Dienste muss aktiviert sein und funktionieren:
    • chrony
    • ntp
    • ntpdate
    • systemd-timesyncd
  • Einen funktionierenden 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 werden:

    • ip_tables (unterscheidet sich vom Debian-Frontend-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 der erforderliche freie Speicherplatz für die Systemkomponenten von Google Distributed Cloud geprüft. Mit dieser Änderung haben Sie mehr Kontrolle über den Speicherplatz, den Sie Anwendungsarbeitslasten zuweisen. Achten Sie bei der Installation 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-Uhren größer oder gleich dem folgenden Wert sein:

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

    Weitere Informationen finden Sie in der Konfigurationsdokumentation zu RHEL oder Ubuntu.

Zusätzlich zu den Voraussetzungen für die Installation und Ausführung von Google Distributed Cloud wird erwartet, dass Kunden die relevanten Standards für ihre Branche oder ihr Geschäftssegment einhalten. Dazu gehören z. B. die PCI-DSS-Anforderungen für Unternehmen, die Kreditkarten verarbeiten, oder Security Technical Implementation Guides (STIGs) für Unternehmen in der Verteidigungsbranche.

Voraussetzungen für Load-Balancer-Rechner

Wenn Ihre Bereitstellung keinen speziellen Load-Balancer-Knotenpool hat, können Worker-Knoten oder Knoten der Steuerungsebene einen Load-Balancer-Knotenpool erstellen lassen. In diesem Fall müssen sie zusätzliche Voraussetzungen erfüllen:

  • Maschinen befinden sich im selben Ebene-2-Subnetz.
  • Alle virtuellen IP-Adressen befinden sich im Subnetz der Load-Balancer-Knoten und können vom Gateway des Subnetzes aus weitergeleitet werden.
  • Das Gateway des Load-Balancer-Subnetzes sollte Gratuitous ARPs überwachen, um Pakete an den Haupt-Load-Balancer weiterzuleiten.

Nächste Schritte