Anthos-Cluster auf Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

Administratorcluster erstellen

In Google Distributed Cloud richten Sie Administratorcluster ein, um andere Cluster sicher zu verwalten. Sie können Nutzercluster aus Administratorclustern erstellen, aktualisieren und löschen. Die Nutzercluster führen Arbeitslasten getrennt von der Verwaltung aus, sodass vertrauliche Informationen geschützt sind.

Administratorcluster, die Multi-Cluster-Arbeitslasten verwalten, können Hochverfügbarkeit (HA) bieten. Wenn in einem HA-Cluster ein Knoten der Steuerungsebene ausfällt, funktionieren andere Knoten weiterhin.

Ein Administratorcluster in einer Multi-Cluster-Umgebung bietet die beste grundlegende Sicherheit. Da der Zugriff auf Verwaltungsdaten von den Arbeitslasten getrennt ist, haben Personen, die auf Nutzerarbeitslasten zugreifen, keinen Zugriff auf sensible administrative Daten wie SSH-Schlüssel und Dienstkontodaten. Deshalb ist ein Kompromiss zwischen Sicherheit und Ressourcen erforderlich, da für einen separaten Administratorcluster spezielle Ressourcen für Verwaltung und Arbeitslasten benötigt werden.

Sie erstellen einen Administratorcluster mit dem Befehl bmctl. Nachdem Sie den Administratorcluster erstellt haben, erstellen Sie Nutzercluster, um Arbeitslasten auszuführen.

Voraussetzungen:

Die neueste bmctl wird aus Cloud Storage heruntergeladen (gs://anthos-baremetal-release/bmctl/1.30.100-gke.96/linux-amd64/bmctl).
Die Workstation, auf der bmctl ausgeführt wird, hat eine Netzwerkverbindung zu allen Knoten in den Ziel-Nutzerclustern.
Die Workstation, auf der bmctl ausgeführt wird, hat eine Netzwerkverbindung zum Cluster API-Server (VIP der Steuerungsebene).
Der SSH-Schlüssel, der zum Erstellen des Administratorclusters verwendet wird, ist entweder für root- oder einen Nicht-Root-Nutzer mit passwortlosen sudo-Berechtigungen auf allen Knoten im Zieladministratorcluster verfügbar.
Das Connect-Register-Dienstkonto ist für die Verwendung mit Connect konfiguriert.

Eine ausführliche Schritt-für-Schritt-Anleitung zum Erstellen eines Hybridclusters finden Sie in der Kurzanleitung zu Google Distributed Cloud. Das Erstellen eines Administratorclusters ist mit dem Erstellen eines Hybridclusters vergleichbar, mit dem Unterschied, dass Sie keine Arbeitslasten auf dem Administratorcluster ausführen.

SELinux aktivieren

Wenn Sie SELinux zum Schutz Ihrer Container aktivieren möchten, müssen Sie darauf achten, dass SELinux auf allen Hostcomputern im Enforced-Modus aktiviert ist. Beginnend mit Google Distributed Cloud Release 1.9.0 oder höher können Sie SELinux vor oder nach Clustererstellung oder Clusterupgrades aktivieren oder deaktivieren. SELinux ist unter Red Hat Enterprise Linux (RHEL) standardmäßig aktiviert. Wenn SELinux auf Ihren Hostcomputern deaktiviert ist oder Sie sich nicht sicher sind, finden Sie unter Container mit SELinux sichern Informationen zur Aktivierung.

Google Distributed Cloud unterstützt SELinux nur in RHEL-Systemen.

Bei gcloud CLI anmelden und eine Administratorcluster-Konfigurationsdatei erstellen

Legen Sie die Standardanmeldedaten fest, mit denen Google Distributed Cloud den Cluster erstellen kann. Verwenden Sie dazu den folgenden Befehl:
```
gcloud auth application-default login
```
Wenn Sie die automatischen Features für die API-Aktivierung und Dienstkontoerstellungs auf dieser Seite verwenden möchten, weisen Sie diesem Hauptkonto die Rolle "Projektinhaber" zu. Wenn das Hauptkonto die Rolle "Projektinhaber" nicht haben kann, führen Sie den nächsten Schritt aus.
Damit der Cluster erfolgreich erstellt werden kann, ohne die Rolle "Projektinhaber" zuzuweisen, fügen Sie dem Hauptkonto die folgenden IAM-Rollen hinzu:
- Dienstkontoadministrator
- Zentraler Dienstkontoadministrator
- Projekt-IAM-Administrator
- Compute-Betrachter
- Service Usage-Administrator
Wenn das Hauptkonto ein Dienstkonto mit diesen Rollen ist, können Sie Folgendes ausführen:
```
export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
```
Ersetzen Sie JSON_KEY_FILE durch den Pfad zur JSON-Schlüsseldatei Ihres Dienstkontos.
Rufen Sie die ID Ihres Google Cloud-Projekts ab und speichern Sie sie in einer Umgebungsvariablen, um sie für die Clustererstellung zu verwenden:
```
export CLOUD_PROJECT_ID=$(gcloud config get-value project)
```

Administratorclusterkonfiguration mit `bmctl` erstellen

Nachdem Sie sich bei der gcloud CLI angemeldet und Ihr Projekt eingerichtet haben, können Sie die Cluster-Konfigurationsdatei mit dem Befehl bmctl erstellen.

Im folgenden Beispiel werden alle Dienstkonten automatisch mit dem Befehl bmctl create config erstellt:

bmctl create config -c ADMIN_CLUSTER_NAME --enable-apis \
    --create-service-accounts --project-id=CLOUD_PROJECT_ID

Dabei gilt:

ADMIN_CLUSTER_NAME: durch den Namen des neuen Clusters.
CLOUD_PROJECT_ID: Ihre Google Cloud-Projekt-ID oder die Umgebungsvariable $CLOUD_PROJECT_ID.

Das folgende Beispiel zeigt, wie Sie eine Konfigurationsdatei für einen Administratorcluster namens admin1 erstellen, der mit der Projekt-ID my-gcp-project verknüpft ist:

bmctl create config -c admin1 --create-service-accounts --enable-apis --project-id=my-gcp-project

Die Datei wird in bmctl-workspace/admin1/admin1.yaml geschrieben.

Als Alternative zur automatischen Aktivierung von APIs und zum Erstellen von Dienstkonten können Sie Ihren vorhandenen Dienstkonten die entsprechenden IAM-Berechtigungen zuweisen. Sie können die automatische Erstellung des Dienstkontos im vorherigen Beispiel im Befehl bmctl überspringen:

bmctl create config -c admin1 --project-id=my-gcp-project

Cluster-Konfigurationsdatei bearbeiten

Sie haben nun eine Clusterkonfigurationsdatei und können diese bearbeiten, um folgende Änderungen vorzunehmen:

Geben Sie den privaten SSH-Schlüssel an, um auf die Administrator-Clusterknoten zugreifen zu können:

# bmctl configuration variables. Because this section is valid YAML but not a valid Kubernetes
# resource, this section can only be included when using bmctl to
# create the initial admin/admin cluster. Afterwards, when creating user clusters by directly
# applying the cluster and node pool resources to the existing cluster, you must remove this
# section.
gcrKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /path/to/your/ssh_private_key
gkeConnectAgentServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
gkeConnectRegisterServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json

Registrieren Sie Ihre Cluster bei einer Flotte: Die Projekt-ID, die Sie im Befehl bmctl create config angegeben haben, wird automatisch dem Feld gkeConnect.projectID in der Clusterkonfigurationsdatei hinzugefügt. Dieses Projekt wird als Flotten-Hostprojekt bezeichnet.
- Wenn Sie Ihre Konfigurationsdatei mithilfe der Features der automatischen API-Aktivierung und der Erstellung von Dienstkonten erstellt haben, können Sie diesen Schritt überspringen.
- Wenn Sie die Konfigurationsdatei erstellt haben, ohne die Features der automatischen API-Aktivierung und Erstellung von Dienstkonten zu verwenden, verweisen Sie auf die heruntergeladenen Dienstkonto-JSON-Schlüssel in den entsprechenden Feldern gkeConnectAgentServiceAccountKeyPath und gkeConnectRegisterServiceAccountKeyPath der Cluster-Konfigurationsdatei.
- Optional können Sie gkeConnect.location zur Clusterspezifikation hinzufügen, um die Google Cloud-Region anzugeben, in der die Flotte und die Connect-Dienste ausgeführt werden. Diese regionale Mitgliedschaft beschränkt den Flottendienst-Traffic auf Ihre Region. Wenn Sie gkeConnect.location in die Cluster-Spezifikation aufnehmen, muss die Region, die Sie angeben, mit der in clusterOperations.location konfigurierten Region übereinstimmen. Wenn die Regionen nicht identisch sind, schlägt die Cluster-Erstellung fehl.

Prüfen Sie, ob in der Konfiguration der Clustertyp admin (Standardwert) angegeben ist:

spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin

Wenn die GKE On-Prem API in Ihrem Google Cloud-Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der GKE On-Prem API in der Region angemeldet, die in clusterOperations.location konfiguriert wurde.
- Wenn Sie alle Cluster im Projekt für die GKE On-Prem API registrieren möchten, müssen Sie die Schritte unter Vorbereitung zur Aktivierung und Verwendung der GKE On-Prem API im Projekt ausführen.
- Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie diesen Abschnitt hinzu und setzen Sie gkeOnPremAPI.enabled auf false. Wenn Sie keine Cluster in dem Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (der Dienstname für die GKE On-Prem API) in dem Projekt. Eine Anleitung finden Sie unter Dienste deaktivieren.
Ändern Sie die Konfigurationsdatei, um eine Steuerungsebene mit mehreren Knoten und Hochverfügbarkeit anzugeben. Geben Sie eine ungerade Anzahl von Knoten ein, die für ein Großteil des Quorums über HA geeignet sein sollen:
```
  # Control plane configuration
  controlPlane:
    nodePoolSpec:
      nodes:
      # Control plane node pools. Typically, this is either a single machine
      # or 3 machines if using a high availability deployment.
      - address: 10.200.0.4
      - address: 10.200.0.5
      - address: 10.200.0.6
```
Hinweis: Wenn Sie vorübergehend eine gerade Anzahl von Knoten haben, während Sie Knoten zur Wartung oder zum Ersetzen hinzufügen oder entfernen, hält Ihre Bereitstellung die Hochverfügbarkeit aufrecht, solange Sie genügend Quorum haben.
Gibt die Pod-Dichte von Clusterknoten an:
```
....
# NodeConfig specifies the configuration that applies to all nodes in the cluster.
nodeConfig:
  # podDensity specifies the pod density configuration.
  podDensity:
    # maxPodsPerNode specifies at most how many pods can be run on a single node.
    maxPodsPerNode: 250
....
```
Zulässige Werte für AdministratorclustermaxPodsPerNode sind32-250 für HA-Cluster und64-250 für Nicht-HA-Cluster. Der Standardwert, wenn nichts angegeben ist, lautet 110. Sobald der Cluster erstellt ist, kann dieser Wert nicht mehr aktualisiert werden.

Die Pod-Dichte wird auch durch die verfügbaren IP-Ressourcen des Clusters begrenzt. Weitere Informationen finden Sie unter Pod-Netzwerk.

Administratorcluster mit Clusterkonfiguration erstellen

Stellen Sie den Cluster mit dem Befehl bmctl bereit:

bmctl create cluster -c ADMIN_CLUSTER_NAME

ADMIN_CLUSTER_NAME gibt den im vorherigen Abschnitt erstellten Clusternamen an.

Im Folgenden sehen Sie ein Beispiel für den Befehl zum Erstellen eines Clusters mit dem Namen admin1:

bmctl create cluster -c admin1

Beispiele für Konfigurationen von Administratorclustern

Beispiele für die Konfigurationen von Administratorclustern finden Sie unter Administratorcluster in den Beispielen für Clusterkonfigurationen.