Clusterkonfigurationsbeispiele

Version 1.14 

• Neueste
• Version 1.16
• Frühere Versionen (nicht unterstützt)

Dieses Dokument enthält YAML-Beispiele der gängigsten Google Distributed Cloud Virtual for Bare Metal-Clusterkonfigurationen. Die Beispiel-Clusterkonfigurationsdateien bieten Permutationen der folgenden Funktionen und Merkmale:

• Edge-Profil
• Hochverfügbarkeit
• Open ID Connect (OIDC)
• Lightweight Directory Access Protocol (LDAP)
• Load-Balancer-Optionen:
  • Externes, manuell konfiguriertes Load-Balancing
  • Gebündeltes Layer-2-Load-Balancing
  • Gebündeltes Layer-2-Load-Balancing außerhalb der Steuerungsebene
  • Gebündeltes Load-Balancing mit Border Gateway Protocol (BGP)
• Mehrere Knotenpools
• SSH-Schlüsselüberschreibungen
• Registry-Spiegelung
• Hinter einem Proxy
• Privates Paket-Repository

Hinweis: Mit dem GKE Identity Service können Sie die Identität außerhalb von Clusterkonfigurationsdateien verwalten. Weitere Informationen zur Verwendung von GKE Identity Service zum Einrichten von OIDC oder LDAP finden Sie unter Einführung in Anthos Identity Service.

Verwendung der Beispiele

Diese Sammlung von YAML-Beispielen dient hauptsächlich als Bildungsreferenz, die zeigt, wie verschiedene Features bei ordnungsgemäßer Konfiguration aussehen. Wenn Sie diese Beispiele zum Erstellen eigener Cluster verwenden möchten, müssen Sie Änderungen vornehmen. Viele der verwendeten Werte, wie z. B. die Werte für den Abschnitt storage, sind Standardwerte und funktionieren für die meisten Cluster. Andere Werte wie spec.authentication.oidc.clientID und spec.gkeConnect.projectID sind jedoch projekt- und umgebungsspezifisch.

Machen Sie sich mit der zugehörigen Feature-Dokumentation vertraut, bevor Sie versuchen, den in diesem Dokument bereitgestellten YAML-Inhalt zu verwenden.

Features in jedem Beispiel

In der folgenden Tabelle sind die grundlegenden Konfigurationsinformationen für jedes Beispiel aufgeführt:

Beispiele
Eigenständige Cluster
Einfaches Edge-Profil	Einzelner Knoten Edge-Profil Keine Knotenpools
Edge-Hochverfügbarkeitsprofil	Hochverfügbarkeit mit drei Knoten Edge-Profil Gebündeltes Layer-2-Load-Balancing Keine Knotenpools
Hybridcluster
Einfacher Hybridcluster	Nicht hohe Verfügbarkeit Gebündeltes Layer-2-Load-Balancing
Hybridcluster mit Hochverfügbarkeit	Hochverfügbarkeit OIDC Hinter einem Proxy Registry-Spiegelung Privates Paket-Repository Gebündeltes Layer-2-Load-Balancing
Hochverfügbarkeits-Hybridcluster mit Load-Balancing außerhalb der Steuerungsebene	Hochverfügbarkeit OIDC Hinter einem Proxy Registry-Spiegelung Privates Paket-Repository Gebündeltes Layer-2-Load-Balancing außerhalb der Steuerungsebene
Administratorcluster
Einfacher Administratorcluster	Nicht hohe Verfügbarkeit Gebündeltes Layer-2-Load-Balancing
Administratorcluster mit manuellem Load-Balancing	Nicht hohe Verfügbarkeit Externes, manuell konfiguriertes Load-Balancing
Administratorcluster mit Hochverfügbarkeit	Hochverfügbarkeit OIDC Hinter einem Proxy Registry-Spiegelung Privates Paket-Repository Gebündeltes Layer-2-Load-Balancing
Nutzercluster
Einfacher Nutzercluster	Nicht hohe Verfügbarkeit Gebündeltes Layer-2-Load-Balancing
Nutzercluster mit Hochverfügbarkeit und mehreren Knotenpools	SSH-Schlüsselüberschreibungen Hochverfügbarkeit Hinter einem Proxy Registry-Spiegelung Privates Paket-Repository Gebündeltes Layer-2-Load-Balancing Mehrere Knotenpools
Nutzercluster mit Hochverfügbarkeit mit OIDC	Hochverfügbarkeit OIDC Hinter einem Proxy Registry-Spiegelung Privates Paket-Repository Gebündeltes Layer-2-Load-Balancing
Nutzercluster mit Hochverfügbarkeit mit LDAP- und BGP-Load-Balancing	Hochverfügbarkeit LDAP Gebündeltes Load-Balancing mit BGP

Eigenständige Cluster

Beachten Sie die folgenden Funktionen eines eigenständigen Clusters:

• Kann sich selbst verwalten
• Es kann Arbeitslasten ausführen
• Es können keine anderen Nutzer-/Nutzercluster erstellt oder verwaltet werden

Eigenständige Cluster eignen sich für Clusterinstallationen, die einen geringen Platzbedarf erfordern oder in denen Sie Cluster in isolierten Partitionen ausführen möchten.

Weitere Informationen zu eigenständigen Clustern finden Sie unter Eigenständige Clusterbereitstellung und Eigenständige Cluster erstellen.

Einfaches Edge-Profil

Beachten Sie die folgenden Features und Optionen in dieser eigenständigen Clusterkonfiguration:

• Einzelner Knoten
• Edge-Profil
• Keine Knotenpools

gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-edge-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: edge-basic
  namespace: cluster-edge-basic
spec:
  type: standalone
  profile: edge
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 110

Edge-Hochverfügbarkeitsprofil

Beachten Sie die folgenden Features und Optionen in dieser eigenständigen Clusterkonfiguration:

• Hochverfügbarkeit mit drei Knoten
• Edge-Profil
• Gebündeltes Layer-2-Load-Balancing
• Keine Knotenpools

gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-edge-ha
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: edge-ha
  namespace: cluster-edge-ha
spec:
  type: standalone
  profile: edge
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 110

Hybridcluster

Beachten Sie die folgenden Funktionen eines Hybridclusters:

• Kann sich selbst verwalten
• Es kann Arbeitslasten ausführen
• Kann andere Nutzercluster verwalten

Hybridcluster funktionieren wie Administratorcluster, mit denen Nutzerarbeitslasten ausgeführt werden können. Wie Administratorcluster können auch Hybridcluster andere Nutzercluster verwalten. Weitere Informationen zu eigenständigen Clustern finden Sie unter Hybridclusterbereitstellung bereitstellen und Hybridcluster erstellen.

Einfacher Hybridcluster

Beachten Sie die folgenden Features und Optionen in dieser Hybrid-Clusterkonfiguration:

• Nicht hohe Verfügbarkeit
• Gebündeltes Layer-2-Load-Balancing

gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-hybrid-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-basic
  namespace: cluster-hybrid-basic
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-hybrid-basic
spec:
  clusterName: hybrid-basic
  nodes:
  - address:  10.200.0.10
  - address:  10.200.0.11
  - address:  10.200.0.12

Hybridcluster mit Hochverfügbarkeit

Beachten Sie die folgenden Features und Optionen in dieser Hybrid-Clusterkonfiguration:

• Hochverfügbarkeit
• OIDC
• Hinter einem Proxy
• Registry-Spiegelung
• Privates Paket-Repository
• Gebündeltes Layer-2-Load-Balancing

registryMirrors:
  - endpoint: https://10.194.2.13:5007/v2/test-namespace
    caCertPath: /root/cert.pem
    pullCredentialConfigPath: /root/dockerconfig.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-hybrid-ha
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha
  namespace: cluster-hybrid-ha
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  proxy:
    url: http://10.194.2.140:3128
    noProxy:
    - 127.0.0.1
    - localhost
  osEnvironmentConfig:
    addPackageRepo: false
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  authentication:
    oidc:
      issuerURL: "https://infra.example.dev/adfs"
      clientID: "be654652-2c45-49ff-9d7c-3663cee9ba51"
      clientSecret: "clientSecret"
      kubectlRedirectURL: "http://localhost:44320/callback"
      username: "unique_name"
      usernamePrefix: "oidc:"
      group: "groups"
      groupPrefix: "oidc:"
      scopes: "allatclaims"
      extraParams: "resource=token-groups-claim"
      deployCloudConsoleProxy: true
      certificateAuthorityData: base64EncodedCACertificate
      proxy: http://10.194.2.140:3128
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-hybrid-ha
spec:
  clusterName: hybrid-ha
  nodes:
  - address:  10.200.0.10
  - address:  10.200.0.11
  - address:  10.200.0.12

Hochverfügbarkeits-Hybridcluster mit Load-Balancing außerhalb der Steuerungsebene

Beachten Sie die folgenden Features und Optionen in dieser Hybrid-Clusterkonfiguration:

• Hochverfügbarkeit
• OIDC
• Hinter einem Proxy
• Registry-Spiegelung
• Privates Paket-Repository
• Gebündeltes Layer-2-Load-Balancing außerhalb der Steuerungsebene

registryMirrors:
  - endpoint: https://10.194.2.13:5007/v2/test-namespace
    caCertPath: /root/cert.pem
    pullCredentialConfigPath: /root/dockerconfig.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-hybrid-ha-lb
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha-lb
  namespace: cluster-hybrid-ha-lb
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  proxy:
    url: http://10.194.2.140:3128
    noProxy:
    - 127.0.0.1
    - localhost
  osEnvironmentConfig:
    addPackageRepo: false
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
      ingressVIP: 10.200.0.72
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.72-10.200.0.90
    nodePoolSpec:
      nodes:
      - address: 10.200.0.5
      - address: 10.200.0.6
      - address: 10.200.0.7
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  authentication:
    oidc:
      issuerURL: "https://infra.example.dev/adfs"
      clientID: "be654652-2c45-49ff-9d7c-3663cee9ba51"
      clientSecret: "clientSecret"
      kubectlRedirectURL: "http://localhost:44320/callback"
      username: "unique_name"
      usernamePrefix: "oidc:"
      group: "groups"
      groupPrefix: "oidc:"
      scopes: "allatclaims"
      extraParams: "resource=token-groups-claim"
      deployCloudConsoleProxy: true
      certificateAuthorityData: base64EncodedCACertificate
      proxy: http://10.194.2.140:3128
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-hybrid-ha-lb
spec:
  clusterName: hybrid-ha-lb
  nodes:
  - address:  10.200.0.10
  - address:  10.200.0.11
  - address:  10.200.0.12

Administratorcluster

Ein Administratorcluster wird zum Verwalten anderer Nutzercluster verwendet. Verwenden Sie Administratorcluster, wenn Sie eine Reihe von Clustern im selben Rechenzentrum haben, das Sie von einem zentralen Ort aus verwalten möchten, und für größere Bereitstellungen, die zwischen verschiedenen Teams oder zwischen Entwicklungs- und Produktionsarbeitslasten isoliert werden müssen.

Weitere Informationen zu Administratorclustern finden Sie unter Multi-Cluster-Bereitstellung und Administratorcluster erstellen.

Einfacher Administratorcluster

Beachten Sie die folgenden Features und Optionen in dieser Administratorclusterkonfiguration:

• Nicht hohe Verfügbarkeit
• Gebündeltes Layer-2-Load-Balancing

gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Administratorcluster mit manuellem Load-Balancing

Beachten Sie die folgenden Features und Optionen in dieser Administratorclusterkonfiguration:

• Nicht hohe Verfügbarkeit
• Externes, manuell konfiguriertes Load-Balancing

gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-manlb
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-manlb
  namespace: cluster-admin-manlb
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: manual
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Administratorcluster mit Hochverfügbarkeit

Beachten Sie die folgenden Features und Optionen in dieser Administratorclusterkonfiguration:

• Hochverfügbarkeit
• OIDC
• Hinter einem Proxy
• Registry-Spiegelung
• Privates Paket-Repository
• Gebündeltes Layer-2-Load-Balancing

registryMirrors:
  - endpoint: https://10.194.2.13:5007/v2/test-namespace
    caCertPath: /root/cert.pem
    pullCredentialConfigPath: /root/dockerconfig.json
sshPrivateKeyPath: .ssh/id_rsa
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-ha
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-ha
  namespace: cluster-admin-ha
spec:
  type: admin
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  proxy:
    url: http://10.194.2.140:3128
    noProxy:
    - 127.0.0.1
    - localhost
  osEnvironmentConfig:
    addPackageRepo: false
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.71
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  authentication:
    oidc:
      issuerURL: "https://infra.example.dev/adfs"
      clientID: "be654652-2c45-49ff-9d7c-3663cee9ba51"
      clientSecret: "clientSecret"
      kubectlRedirectURL: "http://localhost:44320/callback"
      username: "unique_name"
      usernamePrefix: "oidc:"
      group: "groups"
      groupPrefix: "oidc:"
      scopes: "allatclaims"
      extraParams: "resource=token-groups-claim"
      deployCloudConsoleProxy: true
      certificateAuthorityData: base64EncodedCACertificate
      proxy: http://10.194.2.140:3128
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Nutzercluster

Ein Nutzercluster führt Ihre containerisierten Arbeitslasten aus. Nutzercluster müssen einen oder mehrere Worker-Knoten enthalten, mit denen Nutzerarbeitslasten ausgeführt werden. Verwenden Sie Nutzercluster, wenn Sie eine Reihe von Clustern im selben Rechenzentrum haben, die Sie von einem zentralen Ort aus verwalten möchten. Nutzercluster werden auch für größere Bereitstellungen empfohlen, die eine Isolierung zwischen verschiedenen Teams oder zwischen Entwicklungs- und Produktionsarbeitslasten erfordern.

Weitere Informationen zu Administratorclustern finden Sie unter Multi-Cluster-Bereitstellung und Nutzercluster erstellen.

Einfacher Nutzercluster

Beachten Sie die folgenden Features und Optionen in dieser Nutzerclusterkonfiguration:

• Nicht hohe Verfügbarkeit
• Gebündeltes Layer-2-Load-Balancing

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.20
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.91
      ingressVIP: 10.200.0.92
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.92-10.200.0.100
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-user-basic
spec:
  clusterName: user-basic
  nodes:
  - address:  10.200.0.30
  - address:  10.200.0.31
  - address:  10.200.0.32

Nutzercluster mit Hochverfügbarkeit und mehreren Knotenpools

Beachten Sie die folgenden Features und Optionen in dieser Nutzerclusterkonfiguration:

• SSH-Schlüsselüberschreibungen
• Hochverfügbarkeit
• Hinter einem Proxy
• Registry-Spiegelung
• Privates Paket-Repository
• Gebündeltes Layer-2-Load-Balancing
• Mehrere Knotenpools

registryMirrors:
  - endpoint: https://10.194.2.13:5007/v2/test-namespace
    caCertPath: /root/cert.pem
    pullCredentialConfigPath: /root/dockerconfig.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-ha-np
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-ha-np
  namespace: cluster-user-ha-np
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.20
      - address: 10.200.0.21
      - address: 10.200.0.22
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  proxy:
    url: http://10.194.2.140:3128
    noProxy:
    - 127.0.0.1
    - localhost
  osEnvironmentConfig:
    addPackageRepo: false
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.91
      ingressVIP: 10.200.0.92
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.92-10.200.0.100
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
  credential:
    sshKeySecret:
      name: ssh-key
      namespace: cluster-user-ha-np
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-user-ha-np
spec:
  clusterName: user-ha-np
  nodes:
  - address:  10.200.0.30
  - address:  10.200.0.31
  - address:  10.200.0.32
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np2
  namespace: cluster-user-ha-np
spec:
  clusterName: user-ha-np
  nodes:
  - address:  10.200.0.33
  - address:  10.200.0.34
  - address:  10.200.0.35

Nutzercluster mit Hochverfügbarkeit mit OIDC

Beachten Sie die folgenden Features und Optionen in dieser Nutzerclusterkonfiguration:

• Hochverfügbarkeit
• OIDC
• Hinter einem Proxy
• Registry-Spiegelung
• Privates Paket-Repository
• Gebündeltes Layer-2-Load-Balancing von der Steuerungsebene

registryMirrors:
  - endpoint: https://10.194.2.13:5007/v2/test-namespace
    caCertPath: /root/cert.pem
    pullCredentialConfigPath: /root/dockerconfig.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-ha-oidc
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-ha-oidc
  namespace: cluster-user-ha-oidc
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.20
      - address: 10.200.0.21
      - address: 10.200.0.22
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  proxy:
    url: http://10.194.2.140:3128
    noProxy:
    - 127.0.0.1
    - localhost
  osEnvironmentConfig:
    addPackageRepo: false
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.91
      ingressVIP: 10.200.0.92
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.92-10.200.0.100
    nodePoolSpec:
      nodes:
      - address: 10.200.0.25
      - address: 10.200.0.26
      - address: 10.200.0.27
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  authentication:
    oidc:
      issuerURL: "https://infra.example.dev/adfs"
      clientID: "be654652-2c45-49ff-9d7c-3663cee9ba51"
      clientSecret: "clientSecret"
      kubectlRedirectURL: "http://localhost:44320/callback"
      username: "unique_name"
      usernamePrefix: "oidc:"
      group: "groups"
      groupPrefix: "oidc:"
      scopes: "allatclaims"
      extraParams: "resource=token-groups-claim"
      deployCloudConsoleProxy: true
      certificateAuthorityData: base64EncodedCACertificate
      proxy: http://10.194.2.140:3128
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-user-ha-oidc
spec:
  clusterName: user-ha-oidc
  nodes:
  - address:  10.200.0.30
  - address:  10.200.0.31
  - address:  10.200.0.32

Nutzercluster mit Hochverfügbarkeit mit LDAP- und BGP-Load-Balancing

Beachten Sie die folgenden Features und Optionen in dieser Nutzerclusterkonfiguration:

• Hochverfügbarkeit
• LDAP
• Gebündeltes Load-Balancing mit BGP

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-ha-ldap
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-ha-ldap
  namespace: cluster-user-ha-ldap
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.14.11
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 10.200.0.20
      - address: 10.200.0.21
      - address: 10.200.0.22
  clusterNetwork:
    advancedNetworking: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    type: bgp
    localASN: 65001
    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: 10.200.0.91
      ingressVIP: 10.200.0.92
    addressPools:
    - name: pool1
      addresses:
      - 10.200.0.92-10.200.0.100
  clusterOperations:
    projectID: project-fleet
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      storageClassName: local-shared
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
  authentication:
  - name: ldap
    ldap:
      connectionType: ldaps
      group:
        baseDN: ou=Groups,dc=onpremidp,dc=example,dc=net
        filter: (objectClass=*)
        identifierAttribute: dn
      host: ldap.google.com:636
      user:
        baseDN: ou=Users,dc=onpremidp,dc=example,dc=net
        filter: (objectClass=*)
        identifierAttribute: uid
        loginAttribute: uid
      serviceAccountSecret:
        name: google-ldap-client-secret
        namespace: anthos-identity-service
        type: tls
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-user-ha-ldap
spec:
  clusterName: user-ha-ldap
  nodes:
  - address:  10.200.0.30
  - address:  10.200.0.31
  - address:  10.200.0.32
---
apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
metadata:
  name: default
  namespace: cluster-user-ha-ldap
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100