GKE-Cluster mit Config Controller und KRM-Blueprints verwalten

In dieser Anleitung wird gezeigt, wie die KRM-Blueprints mit Config Controller zusammengestellt werden, um einen GKE-Cluster (Google Kubernetes Engine) und die erforderliche Netzwerkinfrastruktur wie eine Virtual Private Cloud (VPC) und ein Subnetz zum Hosten des GKE-Clusters sowie benannte IP-Bereiche für Pods und Dienste bereitzustellen. Wenn Sie GKE-Clusteroperator sind und Ihre Clusterkonfiguration und Netzwerkinfrastruktur deklarativ verwalten möchten, folgen Sie dieser Anleitung.

Config Controller ist ein gehosteter Dienst zur Bereitstellung und Orchestrierung von Anthos- und Google Cloud-Ressourcen. Diese Komponente bietet einen API-Endpunkt, der Google Cloud-Ressourcen als Teil von Anthos Config Management bereitstellen, aktivieren und orchestrieren kann.

KRM-Blueprints sind eine Möglichkeit, Ressourcen zu verpacken, die häufig zusammen verwendet werden, während Best Practices codiert werden, die Sie in Ihrer Organisation einführen können.

Der GKE-Cluster-Blueprint ist ein KRM-Blueprint, der alle Ressourcen enthält, die Sie benötigen, um einen GKE-Cluster auf einer bestehenden Google Cloud VPC, einem Subnetz und IP-Bereichen zu verwalten. Sie können den Blueprint mehrmals instanziieren, um mehrere Cluster einzurichten.

Die Netzwerk-Blueprints sind eine Reihe von KRM-Blueprints, die Ihnen dabei helfen, die erforderlichen Netzwerkkomponenten wie eine VPC, Subnetze und Alias-IP-Bereiche zu erstellen, die für die Erstellung eines GKE-Clusters erforderlich sind. Sie können diese Blueprints mehrmals instanziieren, um mehrere Subnetze und Alias-IP-Bereiche einzurichten, je nach Bedarf für mehrere Cluster.

Ziele

  • Deklarative Netzwerkinfrastruktur erstellen, die zum Hosten eines GKE-Clusters erforderlich ist.
  • GKE-Cluster deklarativ in dieser Netzwerkinfrastruktur konfigurieren.
  • Konfiguration mithilfe von Config Controller anwenden

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Eine vollständige Liste der im GKE-Cluster-Blueprint enthaltenen Ressourcen finden Sie im Abschnitt "Ressourcen" des GKE-Pakets und den zugehörigen Unterpaketen.

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.

Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.

Voraussetzungen

Hinweis

  1. Aktivieren Sie Cloud Shell in der Cloud Console.

    Cloud Shell aktivieren

    Unten in der Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Führen Sie alle Befehle in dieser Anleitung in Cloud Shell aus.

Umgebung einrichten

Führen Sie in Cloud Shell die folgenden Befehle aus:

  1. Installieren Sie kubectl, das Befehlszeilentool für Kubernetes:

    gcloud components install kubectl
    
  2. Installieren Sie kpt, die primäre Befehlszeile für KRM-Blueprints:

    gcloud components install kpt
    
  3. Konfigurieren Sie kubectl und kpt für die Verbindung mit Config Controller:

    gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
        --location COMPUTE_REGION \
        --project CONFIG_CONTROLLER_PROJECT_ID
    

    Dabei gilt:

    • CONFIG_CONTROLLER_NAME: der Name Ihres Config Controller-Clusters

    • COMPUTE_REGION: die Region Ihres Config Controller-Clusters (z. B. us-central1)

    • CONFIG_CONTROLLER_PROJECT_ID: die Projekt-ID Ihres Config Controller-Clusters

  4. Aktivieren Sie die Resource Manager API:

    gcloud services enable cloudresourcemanager.googleapis.com \
        --project PROJECT_ID
    

    Ersetzen Sie PROJECT_ID durch die ID Ihres Projekts.

  5. Prüfen Sie, ob Config Connector im Projekt-Namespace konfiguriert und fehlerfrei ist:

    kubectl get ConfigConnectorContext -n PROJECT_NAMESPACE \
        -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HEALTHY:.status.healthy"
    

    Ersetzen Sie PROJECT_NAMESPACE durch den Namespace, den Sie zum Verwalten von Projektressourcen verwenden möchten (z. B. config-control).

    Beispielausgabe:

    NAMESPACE        NAME                                                HEALTHY
    config-control   configconnectorcontext.core.cnrm.cloud.google.com   true
    

VPC-, Subnetz- und Alias-IP-Bereiche für den Cluster konfigurieren

VPC konfigurieren

Führen Sie die folgenden Befehle aus, um die VPC mit den Netzwerk-Blueprints einzurichten und zu konfigurieren.

  1. Rufen Sie die Netzwerk-Blueprints mit kpt aus dem gewünschten Arbeitsverzeichnis ab:

    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network/vpc@networking-blueprint-v0.4.0 \
      VPC_NAME
    

    Ersetzen Sie VPC_NAME durch den gewünschten Namen, der für die VPC verwendet werden soll (z. B. my-vpc).

  2. Wechseln Sie zum neu erstellten Verzeichnis:

    cd VPC_NAME
    
  3. Konfigurieren Sie das Paket. Ändern Sie dazu die Datei setters.yaml:

    Aktualisieren Sie die folgenden Felder in der Datei. Geben Sie Ihre eigene Projekt-ID an:

      namespace: PROJECT_NAMESPACE
      network-name: VPC_NAME
      project-id: PROJECT_ID
    

    Dabei gilt:

    • PROJECT_ID: die Projekt-ID.

      In dieser Anleitung werden der Cluster und das Netzwerk im selben Projekt bereitgestellt.

    • PROJECT_NAMESPACE: Der Namespace zur Verwaltung von Projektressourcen, z. B. config-control.

      In dieser Anleitung werden die Cluster-, Netzwerk- und Dienstaktivierung im selben Namespace verwaltet.

  4. Fügen Sie am Ende der Datei ein neues Feld mit dem Namen Präfix hinzu. Achten Sie darauf, dass die Einrückung korrekt ist:

      prefix: NAT-PREFIX
    

    Ersetzen Sie NAT-PREFIX durch ein Präfix (z. B. nat).

    Dies wird beim Einrichten der VPC als Präfix für den NAT-Namen verwendet.

    Ihre Datei würde in etwa so aussehen:

    apiVersion: v1
    kind: ConfigMap
    metadata: # kpt-merge: /setters
      name: setters
    data:
      namespace: PROJECT_NAMESPACE
      network-name: VPC_NAME
      project-id: PROJECT_ID
      prefix: NAT-PREFIX
    
  5. Mit der Funktion kpt set-namespace können Sie den Namespace im Blueprint so ändern:

      kpt fn eval --image set-namespace:v0.1 -- namespace=PROJECT_NAMESPACE
    

    Ersetzen Sie PROJECT_NAMESPACE durch den Namespace, der zum Verwalten der Projektressourcen verwendet wird, z. B. config-control.

Subnetz konfigurieren

  1. Rufen Sie den Blueprint des Subnetzwerks mit kpt aus dem Verzeichnis VPC_NAME ab:

    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network/subnet@networking-blueprint-v0.4.0 \
      SUBNET_NAME
    

    Ersetzen Sie SUBNET_NAME durch den Namespace, der zum Verwalten der Projektressourcen verwendet wird, z. B. gke-subnet.

  2. Wechseln Sie in das Subnetzverzeichnis:

    cd SUBNET_NAME
    
  3. Bearbeiten Sie die Datei subnet.yaml und fügen Sie das folgende Snippet am Ende der Datei im Abschnitt spec hinzu. Dies definiert die beiden benannten Bereiche, die zum Zuweisen der IP-Adressen für die GKE-Cluster-Pods und -Dienste verwendet werden:

      secondaryIpRange:
      - ipCidrRange: 172.17.0.0/16
        rangeName: pods
      - ipCidrRange: 172.18.0.0/16
        rangeName: services
    

    Die Datei subnet.yaml würde in etwa so aussehen:

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
    kind: ComputeSubnetwork
    metadata: # kpt-merge: networking/network-name-subnetwork
      name: network-name-subnetwork # kpt-set: ${prefix}${network-name}-subnetwork
      namespace: networking # kpt-set: ${namespace}
      annotations:
        cnrm.cloud.google.com/project-id: project-id # kpt-set: ${project-id}
        cnrm.cloud.google.com/blueprint: cnrm/landing-zone:networking/v0.4.0
    spec:
      description: Subnetwork
      ipCidrRange: 10.2.0.0/16 # kpt-set: ${ip-cidr-range}
      logConfig:
        metadata: INCLUDE_ALL_METADATA
        aggregationInterval: INTERVAL_10_MIN
        flowSampling: 0.5
      networkRef:
        name: network-name # kpt-set: ${network-name}
      privateIpGoogleAccess: false
      region: us-central1 # kpt-set: ${region}
      secondaryIpRange:
      - ipCidrRange: 172.17.0.0/16
        rangeName: pods
      - ipCidrRange: 172.18.0.0/16
        rangeName: services
    

Blueprint rendern

Bevor der Blueprint angewendet werden kann, muss er zuerst gerendert werden. Mit diesem Schritt wird die Pipeline, die in Kptfile definiert ist, auf den Ressourcen im Entwurf ausgeführt. Ein typisches Beispiel für eine ausführbare Funktion ist apply-setters, die die zuvor bearbeiteten Setter anwendet.

  1. Wechseln Sie zurück zum Verzeichnis VPC_NAME und verwenden Sie dann kpt, um die Setter-Werte in den vorlagenbasierten Ressourcen anzuzeigen:

    cd ..
    kpt fn render
    

    Die Ausgabe sollte in etwa so aussehen:

    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 5.4s
      Results:
        [INFO] set field value to "ALL_SUBNETWORKS_ALL_IP_RANGES" in file "nat.yaml" in field "spec.sourceSubnetworkIpRangesToNat"
        [INFO] set field value to "10.2.0.0/16" in file "subnet.yaml" in field "spec.ipCidrRange"
    
    Package "my-vpc":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.3s
      Results:
        [INFO] set field value to "00-my-vpc-router-nat" in file "nat.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "nat.yaml" in field "metadata.namespace"
        [INFO] set field value to "krm-playground-00" in file "nat.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        [INFO] set field value to "00-my-vpc-router" in file "nat.yaml" in field "spec.routerRef.name"
        ...(13 line(s) truncated, use '--truncate-output=false' to disable)
    
    Successfully executed 2 function(s) in 2 package(s).
    

Konfigurationsänderungen anwenden

Lokale Änderungen in den vorherigen Schritten wirken sich erst auf die Cloud aus, wenn sie angewendet werden.

Führen Sie die folgenden Befehle aus, um Ihre Konfigurationsänderungen anzuwenden.

  1. Initialisieren Sie das Arbeitsverzeichnis mit kpt, das eine Ressource erstellt, um Änderungen verfolgen zu können:

    kpt live init --namespace PROJECT_NAMESPACE
    

    Ersetzen Sie PROJECT_NAMESPACE durch den Namespace, der zum Verwalten der Projektressourcen verwendet wird, z. B. config-control.

    initializing Kptfile inventory info (namespace: config-control)...success
    
  2. Sehen Sie sich die erstellen Ressourcen in der Vorschau an:

    kpt live apply --dry-run
    

    Alle Ressourcen sollten mit "Erstellt (Probelauf)" versehen sein.

    Beispielausgabe:

    computerouter.compute.cnrm.cloud.google.com/my-vpc-router created (dry-run)
    computerouternat.compute.cnrm.cloud.google.com/my-vpc-router-nat created (dry-run)
    computesubnetwork.compute.cnrm.cloud.google.com/my-vpc-subnetwork created (dry-run)
    service.serviceusage.cnrm.cloud.google.com/proj-id-00-compute created (dry-run)
    computenetwork.compute.cnrm.cloud.google.com/my-vpc created (dry-run)
    5 resource(s) applied. 5 created, 0 unchanged, 0 configured, 0 failed (dry-run)
    
  3. Wenden Sie die Ressourcen mit kpt an:

    kpt live apply
    

    Alle Ressourcen sollten mit „abgeglichen“ versehen sein.

    Beispielausgabe:

    computenetwork.compute.cnrm.cloud.google.com/my-vpc created
    computerouter.compute.cnrm.cloud.google.com/my-vpc-router created
    computerouternat.compute.cnrm.cloud.google.com/my-vpc-router-nat created
    computesubnetwork.compute.cnrm.cloud.google.com/my-vpc-subnetwork created
    service.serviceusage.cnrm.cloud.google.com/proj-id-00-compute created
    5 resource(s) applied. 5 created, 0 unchanged, 0 configured, 0 failed
    

Prüfen, ob die Netzwerkressourcen erfolgreich erstellt wurden

Mit den folgenden Befehlen prüfen Sie, ob die Änderungen angewendet wurden und ob die von ihnen angegebenen Ressourcen bereitgestellt werden:

  1. Warten Sie, bis die Ressourcen bereit sind:

    kpt live status --output table --poll-until current
    

    Dieser Befehl fragt die Ressourcen ab, bis alle Ressourcen den Status Current und die Bedingung Ready haben.

    Verwenden Sie ctrl-c, um ihn bei Bedarf zu unterbrechen.

    Beispielausgabe:

    NAMESPACE   RESOURCE                                STATUS      CONDITIONS      AGE     MESSAGE
    config-con  ComputeNetwork/my-vpc                   Current     Ready           2m      Resource is Ready
    config-con  ComputeRouter/my-vpc-router             Current     Ready           2m      Resource is Ready
    config-con  ComputeRouterNAT/my-vpc-router-nat      Current     Ready           2m      Resource is Ready
    config-con  ComputeSubnetwork/my-vpc-subnetwork     Current     Ready           2m      Resource is Ready
    config-con  Service/proj-id-00-compute              Current     Ready           2m      Resource is Ready
    
  2. Wenn ein Fehler auftritt, verwenden Sie die Standardereignisausgabe, um die vollständigen Fehlermeldungen zu sehen:

    kpt live status
    

    Es dauert einige Minuten, bis alle Ressourcen erstellt und bereit sind.

    Nachdem die Netzwerkressourcen erfolgreich erstellt wurden, verschieben Sie ein Verzeichnis nach oben, um mit der Konfiguration des GKE-Clusters zu beginnen.

    cd ..
    

GKE-Cluster konfigurieren

Führen Sie die folgenden Befehle aus, um einen GKE-Cluster mit dem GKE-Cluster-Blueprint zu konfigurieren.

  1. Rufen Sie den Entwurf des GKE-Clusters mit kpt aus dem gewünschten Arbeitsverzeichnis ab:

    kpt pkg get \
        https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gke@gke-blueprint-v0.4.0 \
        CLUSTER_NAME
    

    Ersetzen Sie CLUSTER_NAME durch den gewünschten Namen, der für den GKE-Cluster verwendet werden soll (z. B. hello-cluster).

  2. Wechseln Sie in das Clusterverzeichnis:

    cd ./CLUSTER_NAME/
    
  3. Konfigurieren Sie das Paket. Ändern Sie dazu die Datei setters.yaml:

    cat > setters.yaml << EOF
    apiVersion: v1
    kind: ConfigMap
    metadata: # kpt-merge: /setters
      name: setters
    data:
      # The name of this cluster
      cluster-name: CLUSTER_NAME
      # The compute location (region for a regional cluster or zone for a zonal cluster)
      location: us-central1
      # The private IP range for masters to use when peering to the VPC
      master-ip-range: 10.254.0.0/28
      # The reference to the network
      network-ref: projects/PROJECT_ID/global/networks/VPC_NAME
      # The reference to the subnet
      subnet-ref: projects/PROJECT_ID/regions/us-central1/subnetworks/subnetwork
      # The namespace in which to manage cluster resources
      platform-namespace: PROJECT_NAMESPACE
      # The project in which to manage cluster resources
      project-id: PROJECT_ID
      # The namespace in which to manage service enablement resources
      projects-namespace: PROJECT_NAMESPACE
      # The private IP range name for Pods to use, this range must already exist
      pods-range-name: pods
      # The private IP range name for services to use, this range must already exist
      services-range-name: services
      # The group in which to manage the list of groups that can be used for RBAC.
      # Must be named exactly 'gke-security-groups'.
      security-group: gke-security-groups@YOUR_DOMAIN
    EOF
    

    Dabei gilt:

    • PROJECT_ID: die Projekt-ID.

      In dieser Anleitung werden der Cluster und das Netzwerk im selben Projekt bereitgestellt.

    • PROJECT_NAMESPACE: Der Namespace zur Verwaltung von Projektressourcen, z. B. config-control.

      In dieser Anleitung werden die Cluster-, Netzwerk- und Dienstaktivierung im selben Namespace verwaltet.

    • YOUR_DOMAIN: Die Domain, die von Ihren Gruppen verwendet wird (z. B. example.com).

    • network-ref: der SelfLink-Verweis auf das Netzwerk, in dem der Cluster erstellt werden soll.

      Er hat folgendes Format: projects/{network-project-id}/global/networks/{vpc-name}

    • subnet-ref: der SelfLink-Verweis auf das Subnetz, in dem der Cluster erstellt werden soll.

      Er hat folgendes Format: projects/{network-project-id}/regions/{region}/subnetworks/{subnet-name}

    Alle anderen Datenfelder können nach Bedarf neu konfiguriert werden.

    Die angegebenen Standardeinstellungen sollten in einem ansonsten leeren Projekt mit dem Standardnetzwerk funktionieren.

Google Groups for RBAC deaktivieren

Wenn Sie RBAC nicht so konfigurieren möchten, dass Google Groups nicht nur für die Autorisierung verwendet werden kann, können Sie die Clusterkonfiguration ändern, um das Feature für Google Groups for RBAC zu deaktivieren. Dies kann z. B. erforderlich sein, wenn Sie die Gruppe gke-security-groups nicht erstellt haben und nicht über die erforderlichen Berechtigungen zum Erstellen dieser Gruppe verfügen. Weitere Informationen finden Sie unter Gruppeneinrichtung.

  1. Bearbeiten Sie einfach direkt die Datei cluster/cluster.yaml, um Google Groups for RBAC zu deaktivieren.

  2. Suchen Sie den Abschnitt mit dem Feld authenticatorGroupsConfig und entfernen Sie die folgenden drei Zeilen:

      # Enable Groups for GKE, to allow role binding to Google Groups.
      authenticatorGroupsConfig:
        securityGroup: gke-security-group@example.com # kpt-set: ${security-group}
    
  3. Speichern Sie die Datei.

    Dadurch wird die Funktion „RBAC for Google Groups“ deaktiviert.

Blueprint rendern

Mit diesem Schritt wird die Pipeline, die in Kptfile definiert ist, auf den Ressourcen im Entwurf ausgeführt. In der Regel wird dadurch apply-setters ausgeführt, wobei die zuvor bearbeiteten Setter angewendet werden.

  1. Rendern Sie die Setter-Werte in den vorlagenbasierten Ressourcen:

    kpt fn render
    

    Beispielausgabe:

    Package "example/cluster":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 3.3s
      Results:
        [INFO] set field value to "example-us-west4" in file "cluster.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "cluster.yaml" in field "metadata.namespace"
        [INFO] set field value to "project-id" in file "cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        ...(9 line(s) truncated, use '--truncate-output=false' to disable)
    
    Package "test-00/nodepools/primary":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.2s
      Results:
        [INFO] set field value to "gke-example-us-east4-primary" in file "node-iam.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "node-iam.yaml" in field "metadata.namespace"
        [INFO] set field value to "project-id" in file "node-iam.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        [INFO] set field value to "gke-example-us-east4-primary" in file "node-iam.yaml" in field "spec.displayName"
        ...(23 line(s) truncated, use '--truncate-output=false' to disable)
    
    Package "test-00":
    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
    [PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.3s
      Results:
        [INFO] set field value to "test-00" in file "cluster.yaml" in field "metadata.name"
        [INFO] set field value to "config-control" in file "cluster.yaml" in field "metadata.namespace"
        [INFO] set field value to "krm-playground-00" in file "cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
        ...(36 line(s) truncated, use '--truncate-output=false' to disable)
    
    Successfully executed 3 function(s) in 3 package(s).
    

Konfigurationsänderungen anwenden

Lokale Änderungen in den vorherigen Schritten wirken sich erst auf die Cloud aus, wenn sie angewendet werden.

Führen Sie die folgenden Befehle aus, um Ihre Konfigurationsänderungen anzuwenden.

  1. Initialisieren Sie das Arbeitsverzeichnis mit kpt, das eine Ressource erstellt, um Änderungen verfolgen zu können:

    kpt live init --namespace PROJECT_NAMESPACE
    

    Ersetzen Sie PROJECT_NAMESPACE durch den Namespace, der zum Verwalten der Projektressourcen verwendet wird, z. B. config-control.

  2. Sehen Sie sich die erstellen Ressourcen in der Vorschau an:

    kpt live apply --dry-run
    

    Alle Ressourcen sollten mit "Erstellt (Probelauf)" versehen sein.

    Beispielausgabe:

    service.serviceusage.cnrm.cloud.google.com/proj-id-00-test-00-container created (dry-run)
    containercluster.container.cnrm.cloud.google.com/test-00 created (dry-run)
    containernodepool.container.cnrm.cloud.google.com/test-00-primary created (dry-run)
    iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-test-00-primary created (dry-run)
    iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-test-00-primary created (dry-run)
    iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-test-00-primary created (dry-run)
    iamserviceaccount.iam.cnrm.cloud.google.com/gke-test-00-primary created (dry-run)
    7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed (dry-run)
    
  3. Wenden Sie die Ressourcen mit kpt an:

    kpt live apply
    

    Alle Ressourcen sollten "Erstellt" versehen sein.

    Beispielausgabe:

    iamserviceaccount.iam.cnrm.cloud.google.com/gke-test-00-primary created
    service.serviceusage.cnrm.cloud.google.com/proj-id-00-test-00-container created
    containercluster.container.cnrm.cloud.google.com/test-00 created
    containernodepool.container.cnrm.cloud.google.com/test-00-primary created
    iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-test-00-primary created
    iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-test-00-primary created
    iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-test-00-primary created
    7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed
    

Prüfen, ob GKE-Clusterressourcen erfolgreich erstellt wurden

Mit den folgenden Befehlen prüfen Sie, ob die Änderungen angewendet wurden und ob die von ihnen angegebenen Ressourcen bereitgestellt werden:

  1. Warten Sie, bis die Ressourcen bereit sind:

    kpt live status --output table --poll-until current
    

    Dieser Befehl fragt die Ressourcen ab, bis alle Ressourcen den Status Current und die Bedingung Ready haben.

    Verwenden Sie ctrl-c, um ihn bei Bedarf zu unterbrechen.

    Beispielausgabe:

    NAMESPACE   RESOURCE                                  STATUS      CONDITIONS      AGE     MESSAGE
    config-con  ContainerCluster/test-00                  Current     Ready           12m     Resource is Ready
    config-con  ContainerNodePool/test-00-primary         Current     Ready           12m     Resource is Ready
    config-con  IAMPolicyMember/artifactreader-gke-test-  Current     Ready           12m     Resource is Ready
    config-con  IAMPolicyMember/logwriter-gke-test-00-pr  Current     Ready           12m     Resource is Ready
    config-con  IAMPolicyMember/metricwriter-gke-test-00  Current     Ready           12m     Resource is Ready
    config-con  IAMServiceAccount/gke-test-00-primary     Current     Ready           12m     Resource is Ready
    config-con  Service/proj-id-00-test-00-contai         Current     Ready           12m     Resource is Ready
    
  2. Wenn ein Fehler auftritt, verwenden Sie die Standardereignisausgabe, um die vollständigen Fehlermeldungen zu sehen:

    kpt live status
    

FAQ

Bereinigen

Wenn Sie Config Controller nicht mehr verwenden möchten, sollten Sie zuerst alle mit Config Controller erstellten Ressourcen bereinigen und dann Config Controller selbst löschen.

  1. Löschen Sie die Clusterressourcen zuerst mit kpt aus dem Arbeitsverzeichnis des GKE-Cluster-Blueprints:

    kpt live destroy
    
  2. Warten Sie, bis alle Ressourcen gelöscht wurden:

    until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
    do sleep 1; done
    

    Dieser Befehl fragt die Ressourcen ab, bis alle Ressourcen den Status Deleted haben.

    Verwenden Sie ctrl-c, um ihn bei Bedarf zu unterbrechen.

  3. Löschen Sie die Netzwerkressourcen, wenn Sie sie im Rahmen dieser Anleitung erstellt haben. Verwenden Sie kpt aus dem VPC-Verzeichnis, das Sie für den Entwurf erstellt haben:

    kpt live destroy
    
  4. Warten Sie, bis alle Ressourcen gelöscht wurden:

    until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
    do sleep 1; done
    

    Dieser Befehl fragt die Ressourcen ab, bis alle Ressourcen den Status Deleted haben.

    Verwenden Sie ctrl-c, um ihn bei Bedarf zu unterbrechen.

Nächste Schritte