Gemeinsamen Cluster zum Ausführen von Containerarbeitslasten erstellen

Freigegeben

In diesem Dokument wird beschrieben, wie Sie einen freigegebenen Kubernetes-Cluster in einer GDC-Zone (Google Distributed Cloud) mit Air Gap erstellen. Ein freigegebener Cluster umfasst mehrere Projekte und enthält umfassende von GDC verwaltete Dienste, die eine stark vordefinierte Kubernetes-Clusterkonfiguration bieten, die weniger konfigurierbar ist als der Standardcluster. Weitere Informationen zu Standard clustern finden Sie unter Kubernetes-Clusterkonfigurationen.

Freigegebene Cluster sind eine zonale Ressource und können nicht mehrere Zonen umfassen. Wenn Sie Cluster in einer Multi-Zonen-Umgebung betreiben möchten, müssen Sie in jeder Zone manuell Cluster erstellen.

Dieses Dokument richtet sich an Zielgruppen wie Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung von Containerarbeitslasten in ihrer Organisation verantwortlich sind. Weitere Informationen finden Sie unter Zielgruppen für die GDC-Dokumentation mit Air Gap.

Hinweis

In den meisten Anwendungsfällen sollten Sie Standardcluster verwenden, um Ihre Containerarbeitslasten zu hosten. Standardcluster sind am besten auf die Berechtigungen und Funktionen typischer Kubernetes-Angebote abgestimmt. Weitere Informationen zu den Unterschieden zwischen freigegebenen und Standardclustern finden Sie unter Konfigurationsoptionen.
Bitten Sie den IAM-Administrator Ihrer Organisation, Ihnen die Rolle „Nutzercluster-Administrator“ (user-cluster-admin) zuzuweisen, um die Berechtigungen zum Erstellen eines freigegebenen Clusters zu erhalten. Diese Rolle ist nicht an einen Namespace gebunden.
Wenn Sie die API oder Terraform verwenden möchten, um einen freigegebenen Cluster zu erstellen, generieren Sie die kubeconfig-Datei des zonalen API-Servers, um Ihren Cluster zu hosten. Weitere Informationen finden Sie unter Anmelden. Legen Sie die Umgebungsvariable MANAGEMENT_API_SERVER auf den kubeconfig-Pfad fest.
Prüfen Sie die Cluster limits für Ressourcenüberlegungen, bevor Sie einen Cluster erstellen.
- Wir empfehlen, mindestens drei Worker-Knoten zu erstellen, um Upgrades und Updates für Ihren Cluster zu ermöglichen.
- Aus Gründen der Verwaltbarkeit empfehlen wir, weniger als 20 Worker-Knoten zu verwenden.
- Wir empfehlen, die neueste Version von Kubernetes bereitzustellen, die auf der Plattform verfügbar ist, um die Wartbarkeit und Langlebigkeit Ihres Clusters zu gewährleisten.

Pod-CIDR-Block planen

Um den passenden Pod-CIDR-Block für Ihre Arbeitslasten zuzuweisen, müssen Sie die Anzahl der IP-Adressen berechnen, die für Ihren Kubernetes-Cluster erforderlich sind, bevor Sie ihn erstellen. Die meisten Netzwerkparameter können nach dem Erstellen des Clusters nicht mehr geändert werden.

Ein Kubernetes-Cluster folgt bei der Zuweisung von IP-Adressen der folgenden Logik:

Kubernetes weist jedem Knoten einen /24-CIDR-Block mit 256 Adressen zu. Diese Anzahl entspricht dem Standardmaximum von 110 Pods pro Knoten für Kubernetes-Cluster.
Die Größe des CIDR-Blocks, der einem Knoten zugewiesen wird, hängt von der maximalen Anzahl von Pods pro Knoten ab.
Der Block enthält immer mindestens doppelt so viele Adressen wie die maximale Anzahl von Pods pro Knoten.

Im folgenden Beispiel wird veranschaulicht, wie der Standardwert von Maskengröße pro Knoten= /24 berechnet wurde, um 110 Pods zu berücksichtigen:

Maximum pods per node = 110
Total number of IP addresses required = 2 * 110 = 220

Per node mask size = /24
Number of IP addresses in a /24 = 2^{(32 - 24)} = 256

Bestimmen Sie die erforderliche Pod-CIDR-Maske, die für den Kubernetes Cluster konfiguriert werden muss, basierend auf der erforderlichen Anzahl von Knoten. Planen Sie beim Konfigurieren des CIDR-Bereichs zukünftige Knotenerweiterungen für den Cluster ein:

  Total number of nodes supported = 2^{(Per node mask size - pod CIDR mask)}

Da es eine Standardmaskengröße pro Knoten von /24 gibt , finden Sie in der folgenden Tabelle die Zuordnung der Pod-CIDR-Maske zur Anzahl der unterstützten Knoten.

Pod-CIDR-Maske	Berechnung: 2^{(Maskengröße pro Knoten – CIDR Maske)}	Maximale Anzahl der unterstützten Knoten einschließlich Steuerungsebene Knoten
/21	2^{(24 – 21)}	8
/20	2^{(24 – 20)}	16
/19	2^{(24 – 19)}	32
/18	2^{(24 – 18)}	64

Nachdem Sie den Pod-CIDR-Block für Ihren Kubernetes-Cluster berechnet haben, konfigurieren Sie ihn im nächsten Abschnitt im Rahmen des Clustererstellungsprozesses.

Freigegebenen Cluster erstellen

Führen Sie die folgenden Schritte aus, um einen freigegebenen Kubernetes-Cluster zu erstellen:

Console

Wählen Sie im Navigationsmenü Kubernetes Engine > Cluster aus.

**Wichtig**: Sie können bei der Erstellung eines freigegebenen Clusters kein Projekt in der Projektauswahl auswählen. Das liegt daran, dass der Cluster auf Organisationsebene gilt. Weitere Informationen finden Sie unter der Ressourcenhierarchie.
Klicken Sie auf Cluster erstellen.
Geben Sie im Feld Name einen Namen für den Cluster an.
Wählen Sie die Kubernetes-Version für den Cluster aus.
Wählen Sie die Zone aus, in der der Cluster erstellt werden soll.
Klicken Sie auf Projekt anhängen und wählen Sie ein vorhandenes Projekt aus, das an Ihren Cluster angehängt werden soll. Klicken Sie dann auf Speichern. Sie können Projekte nach der Erstellung des Clusters auf der Seite mit den Projektdetails anhängen oder trennen. Sie müssen ein Projekt an Ihren Cluster anhängen, bevor Sie Containerarbeitslasten bereitstellen.
Klicken Sie auf Weiter.
Konfigurieren Sie die Netzwerkeinstellungen für Ihren Cluster. Diese Netzwerkeinstellungen können nach der Erstellung des Clusters nicht mehr geändert werden. Das Standard- und einzige unterstützte Internetprotokoll für Kubernetes-Cluster ist Internetprotokoll Version 4 (IPv4).
1. Wenn Sie dedizierte Load-Balancer-Knoten erstellen möchten, geben Sie die Anzahl der zu erstellenden Knoten ein. Standardmäßig erhalten Sie keine Knoten und der Load-Balancer-Traffic wird über die Steuerungsknoten geleitet.
2. Wählen Sie den zu verwendenden Dienst-CIDR-Bereich (Classless Inter-Domain Routing) aus. Ihren bereitgestellten Diensten wie Load-Balancern werden IP-Adressen aus diesem Bereich zugewiesen.
  
  Wichtig: Der Bereich kann ein beliebiger RFC 1918-Bereich sein, der nicht mit anderen IP-Adressbereichen in den Cluster- und Knotenpoolressourcen in Konflikt steht. Weitere Informationen finden Sie unter RFC 1918.
3. Wählen Sie den zu verwendenden Pod-CIDR-Bereich aus. Der Cluster weist Ihren Pods und VMs IP-Adressen aus diesem Bereich zu.
4. Klicken Sie auf Weiter.
Prüfen Sie die Details des automatisch generierten Standardknotenpools für den Cluster. Klicken Sie auf Bearbeiten , um den Standardknotenpool zu ändern.

Wichtig: Wenn der Cluster Arbeitslasten mit Grafikprozessoren (GPUs) ausführen soll, müssen Sie einen GPU-Maschinentyp in Ihrem Cluster bereitstellen. Weitere Informationen finden Sie unter GPU-Arbeitslasten in einem Kubernetes-Cluster.
Wenn Sie zusätzliche Knotenpools erstellen möchten, wählen Sie Knotenpool hinzufügen aus. Beim Bearbeiten des Standardknotenpools oder Hinzufügen eines neuen Knotenpools können Sie ihn mit den folgenden Optionen anpassen:
1. Weisen Sie dem Knotenpool einen Namen zu. Sie können den Namen nach der Erstellung des Knotenpools nicht mehr ändern.
2. Geben Sie die Anzahl der Worker-Knoten an, die im Knotenpool erstellt werden sollen.
3. Wählen Sie die Maschinenklasse aus, die Ihren Arbeitslastanforderungen am besten entspricht. Hier finden Sie eine Liste der folgenden Einstellungen:
  - Maschinentyp
  - CPU
  - Arbeitsspeicher
4. Klicken Sie auf Speichern.
Klicken Sie auf Erstellen , um den Cluster zu erstellen.

Die Erstellung eines freigegebenen Clusters kann bis zu 90 Minuten dauern.

API

Erstellen Sie die benutzerdefinierte Ressource Cluster:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: cluster.gdc.goog/v1
kind: Cluster
metadata:
  name: CLUSTER_NAME
  namespace: platform
spec:
  clusterNetwork:
    podCIDRSize: POD_CIDR
    serviceCIDRSize: SERVICE_CIDR
  initialVersion:
    kubernetesVersion: KUBERNETES_VERSION
  nodePools:
  - machineTypeName: MACHINE_TYPE
    name: NODE_POOL_NAME
    nodeCount: NUMBER_OF_WORKER_NODES
    taints: TAINTS
    labels: LABELS
    acceleratorOptions:
      gpuPartitionScheme: GPU_PARTITION_SCHEME
  releaseChannel:
    channel: UNSPECIFIED
EOF
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER: Der kubeconfig-Pfad des zonalen API-Servers.
- CLUSTER_NAME: Der Name des Clusters. Der Clustername darf nicht mit -system enden. Das Suffix -system ist für Cluster reserviert, die von GDC erstellt wurden.
- POD_CIDR: Die Größe der Netzwerkbereiche, aus denen virtuelle Pod-IP-Adressen zugewiesen werden. Wenn kein Wert angegeben ist, wird der Standardwert 21 verwendet.
- SERVICE_CIDR: Die Größe der Netzwerkbereiche, aus denen virtuelle Dienst-IP-Adressen zugewiesen werden. Wenn kein Wert angegeben ist, wird der Standardwert 23 verwendet.
- KUBERNETES_VERSION: Die Kubernetes-Version des Clusters, z. B. 1.26.5-gke.2100. Eine Liste der verfügbaren Kubernetes-Versionen, die konfiguriert werden können, finden Sie unter Verfügbare Kubernetes-Versionen für einen Cluster auflisten.
- MACHINE_TYPE: Der Maschinentyp für die Worker-Knoten des Knotenpools. Hier finden Sie die verfügbaren Maschinentypen für die Konfiguration.
- NODE_POOL_NAME: Der Name des Knotenpools.
- NUMBER_OF_WORKER_NODES: Die Anzahl der Worker-Knoten, die im Knotenpool bereitgestellt werden sollen.
- TAINTS: Die Markierungen, die auf die Knoten dieses Knotenpools angewendet werden sollen. Dieses Feld ist optional.
- LABELS: Die Labels, die auf die Knoten dieses Knotenpools angewendet werden sollen. Es enthält eine Liste von Schlüssel/Wert-Paaren. Dieses Feld ist optional.
- GPU_PARTITION_SCHEME: Das GPU-Partitionierungsschema, wenn Sie GPU-Arbeitslasten ausführen. Dieses Feld ist optional. Beispiel: mixed-2. Die GPU wird nicht partitioniert, wenn dieses Feld nicht festgelegt ist. Weitere Informationen zu den verfügbaren MIG-Profilen (Multi-Instanz-GPU) finden Sie unter Unterstützte MIG-Profile.
Wichtig: Sie können Knotenkonfigurationen wie die GPU-Partitionierung nicht mehr bearbeiten, nachdem ein Clusterknotenpool erstellt wurde.

Die Erstellung eines freigegebenen Clusters kann bis zu 90 Minuten dauern.
Erstellen Sie die benutzerdefinierte Ressource ProjectBinding:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectBinding
metadata:
  name: CLUSTER_NAME-PROJECT_NAME
  namespace: platform
  labels:
    resourcemanager.gdc.goog/projectbinding-for-user-project: "true"
spec:
  clusterRef:
    name: CLUSTER_NAME
  selector:
    nameSelector:
      matchNames:
      - PROJECT_NAME
EOF
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER: Der kubeconfig-Pfad des zonalen API-Servers.
- CLUSTER_NAME: Der Name des Clusters.
- PROJECT_NAME: Der Name des Projekts, an das gebunden werden soll. Jede ProjectBinding-Ressource kann nur einem Cluster zugeordnet werden. Wenn ein Projekt Zugriff auf mehrere Cluster benötigt, muss für jeden Cluster eine eindeutige ProjectBinding erstellt werden.
Sie müssen ein Projekt an Ihren Cluster anhängen, bevor ein Entwickler Containerarbeitslasten im Cluster bereitstellen kann.

Terraform

Fügen Sie in einer Terraform-Konfigurationsdatei das folgende Code-Snippet ein, um die benutzerdefinierte Ressource Cluster zu erstellen:
```
provider "kubernetes" {
  config_path = "MANAGEMENT_API_SERVER"
}

resource "kubernetes_manifest" "CLUSTER_RESOURCE_NAME" {
  manifest = {
    "apiVersion" = "cluster.gdc.goog/v1"
    "kind" = "Cluster"
    "metadata" = {
      "name" = "CLUSTER_NAME"
      "namespace" = "platform"
    }
    "spec" = {
      "clusterNetwork" = {
        "podCIDRSize" = "POD_CIDR"
        "serviceCIDRSize" = "SERVICE_CIDR"
      }
      "initialVersion" = {
        "kubernetesVersion" = "KUBERNETES_VERSION"
      }
      "nodePools" = [{
        "machineTypeName" = "MACHINE_TYPE"
        "name" = "NODE_POOL_NAME"
        "nodeCount" = "NUMBER_OF_WORKER_NODES"
        "taints" = "TAINTS"
        "labels" = "LABELS"
        "acceleratorOptions" = {
          "gpuPartitionScheme" = "GPU_PARTITION_SCHEME"
        }
      }]
      "releaseChannel" = {
        "channel" = "UNSPECIFIED"
      }
    }
  }
}
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER: Der kubeconfig-Pfad des zonalen API-Servers.
- CLUSTER_RESOURCE_NAME: Der eindeutige Terraform-Ressourcenname des Clusters, z. B. cluster-1. Dieser Name wird von Terraform verwendet, um Ihren Cluster zu identifizieren, und wird nicht von GDC verwendet.
- CLUSTER_NAME: Der Name des Clusters. Der Clustername darf nicht mit -system enden. Das Suffix -system ist für Cluster reserviert, die von GDC erstellt wurden.
- POD_CIDR: Die Größe der Netzwerkbereiche, aus denen virtuelle Pod-IP-Adressen zugewiesen werden. Wenn kein Wert angegeben ist, wird der Standardwert 21 verwendet.
- SERVICE_CIDR: Die Größe der Netzwerkbereiche, aus denen virtuelle Dienst-IP-Adressen zugewiesen werden. Wenn kein Wert angegeben ist, wird der Standardwert 23 verwendet.
- KUBERNETES_VERSION: Die Kubernetes-Version des Clusters, z. B. 1.26.5-gke.2100. Eine Liste der verfügbaren Kubernetes-Versionen, die konfiguriert werden können, finden Sie unter Verfügbare Kubernetes-Versionen für einen Cluster auflisten.
- MACHINE_TYPE: Der Maschinentyp für die Worker-Knoten des Knotenpools. Hier finden Sie die verfügbaren Maschinentypen für die Konfiguration.
- NODE_POOL_NAME: Der Name des Knotenpools.
- NUMBER_OF_WORKER_NODES: Die Anzahl der Worker-Knoten, die im Knotenpool bereitgestellt werden sollen.
- TAINTS: Die Markierungen, die auf die Knoten dieses Knotenpools angewendet werden sollen. Dieses Feld ist optional.
- LABELS: Die Labels, die auf die Knoten dieses Knotenpools angewendet werden sollen. Es enthält eine Liste von Schlüssel/Wert-Paaren. Dieses Feld ist optional.
- GPU_PARTITION_SCHEME: Das GPU-Partitionierungsschema, wenn Sie GPU-Arbeitslasten ausführen. Dieses Feld ist optional. Beispiel: mixed-2. Die GPU wird nicht partitioniert, wenn dieses Feld nicht festgelegt ist. Weitere Informationen zu den verfügbaren MIG-Profilen (Multi-Instanz-GPU) finden Sie unter Unterstützte MIG-Profile.
Fügen Sie in einer Terraform-Konfigurationsdatei das folgende Code-Snippet ein, um die benutzerdefinierte Ressource ProjectBinding zu erstellen:
```
provider "kubernetes" {
  config_path = "MANAGEMENT_API_SERVER"
}

resource "kubernetes_manifest" "PROJECT_BINDING_RESOURCE_NAME" {
  manifest = {
    "apiVersion" = "resourcemanager.gdc.goog/v1"
    "kind" = "ProjectBinding"
    "metadata" = {
      "name" = "CLUSTER_NAME-PROJECT_NAME"
      "namespace" = "platform"
      "labels" = {
        "resourcemanager.gdc.goog/projectbinding-for-user-project" = "true"
      }
    }
    "spec" = {
      "clusterRef" = {
        "name" = "CLUSTER_NAME"
      }
      "selector" = {
        "nameSelector" = {
          "matchNames" = [
            "PROJECT_NAME",
          ]
        }
      }
    }
  }
}
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER: Der kubeconfig-Pfad des zonalen API-Servers.
- PROJECT_BINDING_RESOURCE_NAME: Der Terraform-Ressourcenname der Projektbindung, z. B. project-binding-1. Dieser Name wird von Terraform verwendet, um Ihre Projektbindung zu identifizieren, und wird nicht von GDC verwendet.
- CLUSTER_NAME: Der Name des Clusters.
- PROJECT_NAME: Der Name des Projekts, an das gebunden werden soll. Jede ProjectBinding-Ressource kann nur einem Cluster zugeordnet werden. Wenn ein Projekt Zugriff auf mehrere Cluster benötigt, muss für jeden Cluster eine eindeutige ProjectBinding erstellt werden.
Sie müssen ein Projekt an Ihren Cluster anhängen, bevor ein Entwickler Containerarbeitslasten im Cluster bereitstellen kann.
Wenden Sie die neuen benutzerdefinierten Ressourcen mit Terraform an:
```
terraform apply
```