Anwendungen mit Application Delivery verwalten

In dieser Anleitung wird schrittweise gezeigt, wie Sie ein Deployment von NGINX mit Application Delivery konfigurieren. Das Deployment wird in zwei Umgebungen ausgeführt: staging und prod. Die prod-Umgebung verwendet eine reguläre Konfiguration, während für staging eine geringfügig modifizierte Konfiguration genutzt wird.

Anforderungen

Für diese Anleitung ist Folgendes erforderlich:

  • Git 2.19.2 oder höher lokal installiert
  • Ein GitHub- oder GitLab-Konto mit Berechtigungen zum Erstellen eines privaten Repositorys ist vorhanden. Application Delivery unterstützt nur GitHub- und GitLab-Repositories.
  • Ein Cluster mit GKE 1.15 oder höher ist verfügbar.
  • Ein Nutzer mit clusterAdmin-Berechtigungen ist vorhanden.
  • Kustomize ist lokal installiert. Sie können der Installationsanleitung folgen.
  • Wenn Sie Ihre Kubernetes-Konfigurationsdateien im Deployment-Repository validieren möchten, müssen Sie Docker installieren.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Mit den folgenden Methoden können Sie die gcloud-Einstellungen festlegen:

  • Verwenden Sie gcloud init, wenn Sie die Standardeinstellungen ansehen möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

gcloud init verwenden

Wenn Sie die Fehlermeldung One of [--zone, --region] must be supplied: Please specify location erhalten, führen Sie diesen Abschnitt aus.

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass mit dem Befehl ein Browserfenster geöffnet wird:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud zur Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone für zonale Cluster oder eine Region für regionale oder Autopilot-Cluster aus.

gcloud config verwenden

  • Legen Sie Ihre standardmäßige Projekt-ID fest:
    gcloud config set project PROJECT_ID
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Standardzone für Compute Engine fest:
    gcloud config set compute/zone COMPUTE_ZONE
  • Wenn Sie mit Autopilot oder regionalen Clustern arbeiten, legen Sie die Compute-Standardregion fest:
    gcloud config set compute/region COMPUTE_REGION
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update
  • Fügen Sie Ihrem GitHub- oder GitLab-Konto SSH-Schlüssel hinzu.
  • Testen Sie Ihre Schlüssel mit ssh:

    GitHub

    ssh -T git@github.com

    GitLab

    ssh -T git@gitlab.com

    Eventuell werden Sie aufgefordert, die Verbindungsdetails oder Ihre Schlüssel-Passphrase zu bestätigen. Wenn die Verbindung hergestellt ist, wird eine Nachricht zum Terminal gesendet.

Application Delivery einrichten

So verwenden Sie Application Delivery:

  1. Erstellen Sie einen neuen Cluster, in dem der Dienst aktiviert ist, oder aktivieren Sie ihn in einem vorhandenen GKE-Cluster ab Version 1.15.
  2. Installieren Sie das Application Delivery-Befehlszeilentool appctl.

Neuen Cluster mit Application Delivery erstellen

Sie können einen neuen Cluster mit aktiviertem Application Delivery mit gcloud oder mit der Cloud Console erstellen.

gcloud

Geben Sie eine Clusterversion ab 1.15.x an:

gcloud beta container clusters create cluster-name \
    --cluster-version cluster-version --addons ApplicationManager

Console

  1. Rufen Sie in der Cloud Console das Google Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie auf Erstellen.

  3. Geben Sie einen Namen für Ihren Cluster ein.

  4. Wählen Sie eine Masterversion von 1.15.x oder höher aus.

  5. Konfigurieren Sie den Cluster wie gewünscht.

  6. Klicken Sie im Navigationsbereich unter Cluster auf Features.

  7. Klicken Sie auf das Kästchen Anwendungsmanager aktivieren.

  8. Klicken Sie auf Erstellen.

Application Delivery für einen vorhandenen Cluster aktivieren

Sie können Application Delivery für einen vorhandenen Cluster mit gcloud oder mit der Cloud Console aktivieren.

gcloud

gcloud beta container clusters update cluster-name \
    --update-addons ApplicationManager=ENABLED

Console

  1. Rufen Sie in der Cloud Console das Google Kubernetes Engine-Menü auf.

    Zum Google Kubernetes Engine-Menü

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie unter Features neben dem Feld Anwendungsmanager auf Anwendungsmanager bearbeiten.

  4. Klicken Sie auf das Kästchen Anwendungsmanager aktivieren.

  5. Klicken Sie auf Änderungen speichern.

Installation prüfen

Führen Sie folgende Schritte aus, um den Status Ihrer Application Delivery-Installation zu prüfen:

  1. Prüfen Sie den Bereitstellungsstatus:

    kubectl get deployment application-controller-manager -n application-system
    

    Die Ausgabe sieht etwa so aus:

    NAME                             READY   UP-TO-DATE   AVAILABLE   AGE
    application-controller-manager   2/2     2            2           1h
    

    In dieser application-controller-manager-Bereitstellung sollten zwei Pods verfügbar sein.

  2. Prüfen Sie den StatefulSet-Status:

    kubectl get statefulset kalm-controller-manager -n kalm-system
    

    Die Ausgabe sieht etwa so aus:

    NAME                      READY   AGE
    kalm-controller-manager   1/1     1h
    

    In diesem kalm-controller-manager-StatefulSet sollte ein Pod bereit sein.

appctl installieren

Sie installieren pkg, einschließlich des Application Delivery-Befehlszeilentools appctl mit gcloud.

gcloud components install pkg

Nachdem Sie Application Delivery für einen Cluster aktiviert und pkg installiert haben, können Sie Ihre erste Anwendung bereitstellen.

Anwendung bereitstellen

Zum Bereitstellen einer Anwendung führen Sie folgende Schritte aus:

  1. Erstellen Sie neue Git-Repositories oder initialisieren Sie vorhandene Repositories.
  2. Erstellen Sie eine Basiskonfiguration.
  3. Erstellen Sie eine oder mehrere Umgebungen für Ihr Deployment.
  4. (Optional) Wenden Sie Konfigurations-Overlays auf Ihre Umgebungen in Ihrem Anwendungs-Repository an.
  5. Erstellen Sie einen Releasekandidaten in Form einer Pull- oder Zusammenführungsanfrage.
  6. Stellen Sie Ihre Releases bereit.

Neue Repositories erstellen

Erstellen Sie mit appctl Repositories für Application Delivery auf GitHub oder GitLab.

  1. Wechseln Sie in das Verzeichnis, in dem Sie das Anwendungsverzeichnis erstellen möchten.
  2. Erstellen Sie Ihre Application Delivery-Repositories mit appctl.

    GitHub

    appctl init application-name \
      --app-config-repo=github.com/user-name/application-name

    Wenn Ihr GitHub-Nutzername beispielsweise octocat lautet und Sie eine Anwendung namens myapp erstellen möchten, führen Sie Folgendes aus:

    appctl init myapp --app-config-repo=github.com/octocat/myapp

    GitLab

    appctl init application-name \
      --app-config-repo=gitlab.com/user-name/application-name

    Wenn Ihr GitLab-Nutzername beispielsweise alice lautet und Sie eine Anwendung namens myapp erstellen möchten, führen Sie Folgendes aus:

    appctl init myapp --app-config-repo=gitlab.com/alice/myapp

  3. appctl fordert Sie auf, Ihre neuen privaten Repositories zu bestätigen.

appctl erstellt zwei private Remote-Git-Repositories:

  • Das Anwendungs-Repository github.com/user-name/application-name. Dieses Repository wird in das aktuelle Verzeichnis geklont.
  • Das Deployment-Repository github.com/user-name/application-name-deployment. Das lokale Deployment-Repository wird in ./application-name/.deployment gespeichert.

Weitere Informationen zum Inhalt und zur Struktur dieser Repositories finden Sie im Konzeptleitfaden zu Application Delivery.

Vorhandene Repositories initialisieren

Wenn Sie bereits Repositories haben, können Sie sie für Application Delivery auf GitHub oder GitLab mit appctl initialisieren.

  1. Wechseln Sie in das Verzeichnis, in dem Sie das Anwendungsverzeichnis erstellen möchten.

  2. Führen Sie den Befehl appctl init aus, um ein Verzeichnis mit dem Namen application-name zu erstellen und Ihr Repository dort zu klonen.

    Der Befehl appctl init initialisiert eine Kustomize-Basisebene in den Konfigurationsdateien, die im Verzeichnis ./config des Repositorys gespeichert sind. Mit dem Flag --config-path können Sie einen anderen Konfigurationspfad angeben.

    appctl init verwendet standardmäßig github.com/user-name/application-name-deployment als URL des Deployment-Repositorys. Mit dem Flag --deployment-repo können Sie eine andere URL angeben. Wenn das Deployment-Repository nicht vorhanden ist, erstellt der appctl-Befehl eines.

    GitHub

    appctl init application-name \
        --app-config-repo=github.com/user-name/application-name \
        [--config-path=config-path]

    Wenn das vorhandene Anwendungskonfigurations-Repository beispielsweise https://github.com/octocat/myapp ist und Sie davon ausgehen, dass das Deployment-Repository https://github.com/octocat/myapp-deploy ist, führen Sie folgenden Befehl aus:

    appctl init myapp --app-config-repo=github.com/octocat/myapp

    GitLab

    appctl init application-name \
      --app-config-repo=gitlab.com/user-name/application-name \
      [--config-path=config-path]

    Wenn das vorhandene Anwendungskonfigurations-Repository beispielsweise gitlab.com/alice/myapp ist, führen Sie folgenden Befehl aus:

    appctl init myapp --app-config-repo=gitlab.com/alice/myapp

Basiskonfiguration erstellen

  1. Wechseln Sie als Arbeitsverzeichnis in Ihr Anwendungs-Repository. Wenn Sie beispielsweise den Anwendungsnamen myapp verwendet haben, führen Sie folgenden Befehl aus:

    cd myapp
  2. Erstellen Sie die Konfiguration für Ihre Kubernetes-Arbeitslast. Dies kann ein beliebiges gültiges Kubernetes-Deployment sein.

    Mit der nachfolgend aufgeführten Konfiguration wird eine Anwendung namens nginx definiert, die drei Replikate des nginx-Containers bereitstellt. Kopieren Sie die Konfiguration in die Datei config/base/myapp.yaml. Wenn Sie einen Load-Balancer aktivieren möchten, entfernen Sie das Kommentarzeichen in der Zeile type: LoadBalancer.

    #myapp/config/base/myapp.yaml
    
    apiVersion: v1
    kind: Service
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      # if your cluster supports it, uncomment the following to automatically create
      # an external load-balanced IP for the frontend service.
      # type: LoadBalancer
      ports:
        - port: 80
      selector:
        app: nginx
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx:1.7.9
            ports:
            - containerPort: 80
    
  3. Konfigurieren Sie Application Delivery so, dass diese Konfiguration auf die Basis angewendet wird. Fügen Sie zu config/base/kustomization.yaml Folgendes hinzu:

    #config/base/kustomization.yaml
    
    resources:
      - myapp.yaml
    

Konfiguration testen und per Push übertragen

  1. Testen Sie die Konfiguration aus Ihrem Anwendungs-Repository-Verzeichnis mit kustomize build:

    kustomize build config/base/

    Wenn Ihre Konfiguration gültig ist, gibt kustomize die YAML-Datei aus, die nach ihrer Anwendung im Cluster bereitgestellt wird.

  2. Nachdem Sie Ihre YAML-Datei geprüft haben, erstellen Sie einen Commit und übertragen ihn per Push in Ihr Anwendungs-Repository:

    git add .
    git commit -m "Creating application-name"
    git push origin master

Releaseumgebung hinzufügen

Application Delivery stellt Ihre Anwendung in Umgebungen bereit. Umgebungen fügen Sie für Ihre Releases mit appctl hinzu.

  1. Wechseln Sie in das Stammverzeichnis des Anwendungs-Repositorys, z. B. cd myapp.
  2. Erstellen Sie Ihre Umgebung mit appctl:

    appctl env add environment-name --cluster=cluster-name

    appctl erstellt einen Git-Commit, der eine Kustomize-Konfiguration mit Scaffold enthält.

    Sie können den Namen des Namespace für eine Releaseumgebung dieser Anwendung mit --namespace angeben. Wenn Sie das nicht tun, lautet der Standard-Namespace-Name application-name-environment-name. Wenn Sie beispielsweise dem Cluster application-cluster die Umgebungen staging und prod mit dem Standard-Namespace-Namen hinzufügen möchten, führen Sie den folgenden Befehl aus:

    appctl env add staging --cluster=application-cluster
    appctl env add prod --cluster=application-cluster

    Führen Sie den folgenden Befehl aus, um die test-Umgebung im test-Namespace dem Cluster application-cluster hinzuzufügen:

    appctl env add test --cluster=application-cluster --namespace=test

    Wenn Sie eine Umgebung hinzufügen, müssen Sie berücksichtigen, ob im Bereitstellungs-Repository für diese Umgebung Pull-Anfragen und Codeüberprüfungen erforderlich sind. Standardmäßig werden Pull-Anfragen erstellt. Wenn die Umgebung nicht produktionskritisch ist und keine Codeüberprüfung erforderlich ist, können Sie das Erstellen von Pull-Anfragen mit --review-required=false überspringen. Sie können beispielsweise die test-Umgebung hinzufügen, für die keine Pull-Anfragen erstellt werden müssen.

    appctl env add test --cluster=application-cluster --review-required=false

  3. Optional können Sie die Änderungen, die Application Delivery in Ihrem Git-Repository vorgenommen hat, mit git log aufrufen:

    git log -p *
  4. Übertragen Sie die Konfiguration per Push in Ihr Anwendungs-Repository:

    git push origin master

Optional: Deployment-Repository prüfen

Rufen Sie die Seite von GitHub oder GitLab für Ihr Deployment-Repository auf. Wenn beispielsweise Ihr GitHub-Nutzername octocat lautet und Sie eine Anwendung namens myapp erstellt haben, lautet die URL https://github.com/octocat/myapp-deployment. Auf dieser Seite werden die Zweige angezeigt, die für jede Umgebung erstellt wurden.

Umgebung bereitstellen

So stellen Sie eine Umgebung mit Application Delivery bereit:

  1. Erstellen Sie eine Version mit git tag und übertragen Sie das Tag per Push.

    git tag version
    git push origin version

    Um beispielsweise die Version v0.1.0 per Push zu übertragen, führen Sie die folgenden Befehle aus:

    git tag v0.1.0
    git push origin  v0.1.0

  2. Verwenden Sie appctl prepare, um die aktuell mit Tags versehene Version zu benennen und eine Pull-Anfrage im Deployment-Repository zur Prüfung zu generieren.

    appctl prepare environment-name

    Führen Sie beispielsweise den folgenden Befehl aus, um die staging-Umgebung zu verwenden:

    appctl prepare staging --validate=true

    Sie löst die kpt-Validierungsfunktion gcr.io/kustomize-functions/example-validator aus, um zu prüfen, welche Änderung per Push an das Deployment-Repository übertragen wird.

    kpt wird von gcloud components install pkg installiert. Diese Validierungsfunktion führt kubeval im Hintergrund aus, wodurch Kubernetes-Konfigurationsdateien mithilfe von Schemas aus der OpenAPI-Spezifikation von Kubernetes validiert werden.

    Zum Ausführen von kpt prepare staging --validate müssen Sie auf Ihrem Computer [Docker installieren] (https://docs.docker.com/engine/install/){:external}.

    Das Flag "--validate" ist standardmäßig deaktiviert.

    Wenn appctl den Commit im Deployment-Repository durchgeführt hat, gibt es eine URL wie die folgende aus, um eine Pull-Anfrage zu erstellen:

    Created a "Pull Request": "https://github.com/octocat/myapp-deployment/pull/[Pull_Request_ID]"
    
  3. Verwenden Sie GitHub oder GitLab, um die Pull-Anfrage zu prüfen und zu genehmigen.

  4. Nachdem die Pull-Anfrage genehmigt wurde, schließen Sie das Deployment mit appctl apply ab:

    appctl apply environment-name

    Führen Sie beispielsweise folgenden Befehl aus, um Änderungen in der staging-Umgebung bereitzustellen:

    appctl apply staging
  5. Prüfen Sie, ob Ihre Anwendung mit kubectl oder über die Cloud Console ausgeführt wird.

    kubectl

    Verwenden Sie kubectl describe, um den Status Ihrer Anwendung aufzurufen:

     kubectl get releasetracks.app.gke.io application-name -n \
         [application-name-environment-name or customized_namespace`] -w

    Ersetzen Sie Folgendes:

    • application-name: der Name Ihres Anwendungs-Repositorys
    • environment-name: der Name Ihrer Umgebung
    • customized_namespace: der Namespace-Name, der zuvor in env add angegeben wurde

    Beispielsweise können Sie mit dem folgenden Befehl den Status der staging-Umgebung der Anwendung myapp prüfen:

    kubectl get releasetracks.app.gke.io myapp -n myapp-staging

    Führen Sie den folgenden Befehl aus, um den Status der test-Umgebung zu prüfen, die zuvor mit env add --namespace test hinzugefügt wurde:

    kubectl get releasetracks.app.gke.io myapp -n test

    Console

    Informationen zu Status und Version der Anwendungen, die mit Application Delivery bereitgestellt wurden, finden Sie auf der GKE-Seite Anwendungen in der Cloud Console.

Release hochstufen

  1. Mit dem folgenden Befehl können Sie einen Releasekandidaten von einer Umgebung in eine andere hochstufen:

    appctl prepare target-environment-name \
        --from-env source-environment-name

    Ersetzen Sie Folgendes:

    • target-environment-name: der Name der Umgebung, in der Sie den Releasekandidaten bereitstellen möchten
    • source-environment-name: der Name der aktuellen Umgebung

    Zum Hochstufen von staging nach prod führen Sie beispielsweise Folgendes aus:

    appctl prepare prod --from-env staging

  2. Verwenden Sie GitHub oder GitLab, um die Pull-Anfrage zu prüfen und zu genehmigen.

  3. Zum Bereitstellen des Releasekandidaten in der Zielumgebung führen Sie den folgenden Befehl aus:

    appctl apply target-environment-name

    Für ein Deployment in der prod-Umgebung führen Sie beispielsweise den folgenden Befehl aus:

    appctl apply prod

Umgebungen in der Cloud Console aufrufen

Sobald die Anwendung einer Umgebung bereitgestellt wurde, wird sie auf der GKE-Seite Anwendungen aufgeführt. Diese Seite enthält eine Liste von Anwendungen, einschließlich ihrer Umgebungen, die in Klammern angegeben sind. Hier ist ein Screenshot einer Anwendung myapp mit den zwei Umgebungen staging und prod. Auf dieser Seite werden auch der Namespace, der Cluster und die Version jeder Umgebung angezeigt.

Screenshot: Seite "Anwendungen"

Klicken Sie auf den Namen der Anwendung, wenn Sie Anwendungsdetails wie das Git-Tag, die Komponenten und die Umgebungsliste sehen möchten. Der folgende Screenshot zeigt die Details für myapp.

Screenshot: Detailseite einer Anwendung

Konfiguration einer Umgebung ändern

In diesem Abschnitt wird davon ausgegangen, dass eine staging-Umgebung wie in den vorherigen Schritten konfiguriert wurde. Möglicherweise müssen Sie diese Anleitung entsprechend anpassen.

In diesem Abschnitt ändern Sie die Parameter für die staging-Umgebung mithilfe eines Kustomize-Overlays. Nachdem Sie die Änderungen vorgenommen haben, werden sie per Push nach Git übertragen und mit Tags gekennzeichnet. Application Delivery aktualisiert dann Ihren Cluster.

  1. Erstellen Sie eine Datei mit dem Namen config/envs/staging/patch-replicas.yaml und kopieren Sie den folgenden Text in diese Datei. Damit wird die Konfiguration in der staging-Umgebung aktualisiert, sodass nur ein Replikat statt drei Replikaten ausgeführt wird.

    #config/envs/staging/patch-replicas.yaml
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
    spec:
      replicas: 1
    
  2. Bearbeiten Sie die Datei config/envs/staging/kustomization.yaml und fügen Sie patch-replicas.yaml einer neuen Sammlung namens patchesStrategicMerge hinzu.

    #config/envs/staging/kustomization.yaml
    namespace: myapp-staging
    bases:
       - ../../base
    patchesStrategicMerge:
       - patch-replicas.yaml
    

    Sie können diesem Overlay auch umgebungsspezifische Anmerkungen hinzufügen. Im folgenden Beispiel wird eine Anmerkung mit dem Namen oncall-team eingefügt, um alle Ressourcen in dieser Umgebung hinzuzufügen. Weitere Informationen finden Sie unter Kustomization File Fields.

    #config/envs/staging/kustomization.yaml
    
    #Don't change the namespace field
    namespace: myapp-staging
    bases:
       - ../../base
    patchesStrategicMerge:
       - patch-replicas.yaml
    commonAnnotations:
      oncall-team: staging-oncall@foo.bar
    
  3. Testen Sie Ihre Konfiguration mit kustomize build:

    kustomize build config/envs/staging/

  4. Fügen Sie Ihre Änderungen mit einem Commit hinzu:

    git add .
    git commit -m "commit-message"
    git push origin master

    Ersetzen Sie commit-message durch eine Nachricht, die Ihre Änderungen beschreibt.

  5. Erstellen Sie eine Version mit git tag und übertragen Sie diese per Push:

    git tag version
    git push origin  version
  6. Generieren Sie mit appctl prepare eine Pull-Anfrage im Deployment-Repository zur Prüfung:

    appctl prepare environment-name
  7. Folgen Sie dem Link, um eine GitHub- oder GitLab-Pull-Anfrage zu erstellen.

  8. Sehen Sie sich den Inhalt Ihrer Pull-Anfrage an. Application Delivery führt eine Änderung in einer Zeile aus, mit der für replicas der Wert 1 festgelegt wird.

  9. Genehmigen Sie die Pull-Anfrage mit GitHub oder GitLab.

  10. Wenden Sie die Änderungen mit appctl apply an:

    appctl apply staging

Konfigurationsänderungen rückgängig machen

Führen Sie folgenden Befehl aus, um ein Rollback zu einem früheren Release durchzuführen:

appctl apply target-environment-name --from-tag git-tag

Ersetzen Sie Folgendes:

  • target-environment-name: der Name der Umgebung, in der Sie den Release bereitstellen möchten
  • git-tag: der Name des Tags für den Release

appctl in Skripts verwenden

Das Tool appctl ist interaktiv und erfordert standardmäßig eine Nutzereingabe. Wenn Sie appctl in einem Skript, in einem Container oder in Pipelines ausführen möchten, legen Sie die Umgebungsvariable APPCTL_INTERACTIVE auf false fest.

Beispielsweise können Sie in Bash Shell den folgenden Befehl ausführen:

export APPCTL_INTERACTIVE=false

Informationen zu den jeweiligen appctl-Befehlen erhalten Sie mit appctl help command. Hilfe zu appctl prepare können Sie beispielsweise mit appctl help prepare aufrufen.

Anwendungsmanager deinstallieren

Zum Entfernen der Anwendung, die in Ihrem Cluster ausgeführt wird, löschen Sie alle Namespaces, die mit neuen Umgebungen erstellt wurden.

Wiederholen Sie dazu für alle Umgebungen und Cluster die im Folgenden aufgeführten Befehle.

  1. Wechseln Sie für die jeweilige Umgebung zum zugehörigen Cluster:

    kubectl config use-context ${CONTEXT_OF_ENV_CLUSTER}
  2. Löschen Sie den Namespace, in dem Ihre Anwendung für diese Umgebung ausgeführt wird:

     kubectl delete ns [application-name-environment-name or customized_namespace`]

    Ersetzen Sie Folgendes:

    • application-name: der Name Ihres Anwendungs-Repositorys
    • environment-name: der Name Ihrer Umgebung
    • customized_namespace: der Namespace-Name, der zuvor in env add angegeben wurde
  3. Löschen Sie in GitHub oder GitLab die beiden Git-Repositories, die mit appctl erstellt wurden.

  4. Löschen Sie Ihr lokales Anwendungsverzeichnis mit folgendem Befehl:

    rm -rf myapp/
  5. Sie können Application Delivery in Ihrem Cluster mit gcloud oder mit der Cloud Console deaktivieren:

    gcloud

    gcloud beta container clusters update cluster-name \
    --update-addons ApplicationManager=DISABLED

    Console

    1. Rufen Sie in der Cloud Console das Google Kubernetes Engine-Menü auf.

      Zum Google Kubernetes Engine-Menü

    2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

    3. Klicken Sie unter Features neben dem Feld Anwendungsmanager auf Anwendungsmanager bearbeiten.

    4. Entfernen Sie das Häkchen von Anwendungsmanager aktivieren.

    5. Klicken Sie auf Änderungen speichern.

Nächste Schritte

Mehr über Kustomize erfahren