In GKE bereitstellen

Auf dieser Seite wird erläutert, wie Sie mit Cloud Build eine Anwendung in Kubernetes bereitstellen.

Cloud Build bietet einen gke-deploy-Builder, mit dem Sie eine Containeranwendung in einem GKE-Cluster bereitstellen können.

gke-deploy ist ein Wrapper um kubectl, die Befehlszeile für Kubernetes. Es wendet die von Google empfohlenen Vorgehensweisen für das Bereitstellen von Anwendungen in Kubernetes an, indem folgende Aktionen vorgenommen werden:

• Aktualisieren der Kubernetes-Ressourcendatei der Anwendung, um den Digest des Container-Images anstelle eines Tags zu verwenden.

• Hinzufügen von empfohlenen Labels zur Kubernetes-Ressourcendatei.

• Abrufen der Anmeldedaten für die GKE-Cluster, in denen Sie das Image bereitstellen möchten.

• Es wird auf die bereitgestellte Kubernetes-Ressourcendatei gewartet.

Wenn Sie Ihre Anwendungen direkt mit kubectl bereitstellen möchten und keine zusätzlichen Funktionen benötigen, bietet Cloud Build auch einen kubectl-Builder, mit dem Sie die Anwendungen in einem GKE-Cluster bereitstellen können.

Hinweis

• Erstellen Sie einen GKE-Cluster, falls Sie noch keinen haben.

• Halten Sie die containerisierte Anwendung in Form von Quellcode und einem Dockerfile bereit. Der Quellcode muss in einem Repository gespeichert sein, z. B. in Cloud Source Repositories, GitHub oder Bitbucket.

• Sie benötigen mindestens eine Kubernetes-Ressourcendatei, in der die Kubernetes-Ressourcen beschrieben sind, die zum Ausführen der Anwendung verwendet werden. Wenn Sie keine Kubernetes-Ressourcendateien haben, gehen Sie folgendermaßen vor, um eine Datei für die Anwendung zu erstellen:

  1. Öffnen Sie in der Google Cloud Console die Kubernetes Engine-Seite "Cluster".
  2. Klicken Sie auf der Seite mit den Kubernetes Engine-Clustern auf Bereitstellen.
  3. Wählen Sie Ihren Container aus und klicken Sie auf Weiter. Der Bereich "Konfiguration" wird angezeigt.
  4. Klicken Sie unter „YAML-Konfigurationsdatei“ auf YAML öffnen, um eine Beispielkonfigurationsdatei für Kubernetes zu erhalten.
  Hinweis: Wenn Sie bereits eine andere Form einer Vorlagendatei für Kubernetes-Ressourcen haben etwa ein Helm-Diagramm oder eine Ressource im Kustomize-Format, finden Sie im Helm-Builder oder kustomize Builder. Dort finden Sie Beispiele für Build-Konfigurationen, die Sie für die Bereitstellung verwenden.

Achtung:Ab dem 17. Juni 2024 ist Cloud Source Repositories nicht mehr verfügbar. für Neukund*innen. Wenn Ihre Organisation noch nicht zuvor verwendeten Cloud Source Repositories verwendet haben, können Sie die API nicht aktivieren oder Cloud Source Repositories erstellen. Für neue Projekte, die nicht mit einer Organisation verknüpft sind, kann das Cloud Source Repositories API Organisationen, die bereits Cloud Source Repositories verwendet haben 17. Juni 2024 sind von dieser Änderung nicht betroffen.

Erforderliche IAM-Berechtigungen

Fügen Sie Ihrem Konto die Rolle "GKE-Entwickler" hinzu:

1. Öffnen Sie die Seite mit den Cloud Build-Einstellungen:

   Zur Seite mit den Cloud Build-Einstellungen

   Sie sehen die Seite Dienstkontoberechtigungen:

   

2. Setzen Sie den Status der Rolle Kubernetes Engine Developer (Kubernetes Engine-Entwickler) auf Enabled (Aktiviert).

Vorkonfiguriertes Containerimage bereitstellen

So stellen Sie eine bestimmte Version der Anwendung mit gke-deploy bereit:

1. Achten Sie darauf, dass die Kubernetes-Konfigurationsdatei auf das richtige Containerimage-Tag oder -Digest verweist.

2. Fügen Sie den Schritt gke-deploy der Build-Konfigurationsdatei hinzu:

   YAML

   steps:
   ...
   # deploy container image to GKE
   - name: "gcr.io/cloud-builders/gke-deploy"
     args:
     - run
     - --filename=kubernetes-resource-file
     - --location=location
     - --cluster=cluster
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/gke-deploy",
         "args": [
           "run",
           "--filename=kubernetes-resource-file",
           "--location=location",
           "--cluster=cluster"
         ]
       }
     ]
   }
   

   Wobei:

   • kubernetes-resource-file ist der Dateipfad der Kubernetes-Ressourcendatei oder der Pfad zu dem Verzeichnis, das die Kubernetes-Ressourcendateien enthält.
   • cluster ist der Name des GKE-Clusters, in dem die Anwendung bereitgestellt wird.
   • location ist die Region/Zone des Clusters.

   Weitere Informationen zu verfügbaren Flags finden Sie unter gke-deploy run-Flags.

   Hinweis: Bei der Bereitstellung in mehreren GKE-Clustern behält Cloud Build das Basisverzeichnis über die Build-Schritte hinweg bei, d. h., dass der kubectl-Kontext des vorherigen Schritts für nachfolgende Schritte standardmäßig verwendet werden soll. Damit das vermieden wird, fügen Sie jedem Schritt der Build-Konfigurationsdatei eine Umgebungsvariablendeklaration (KUBECONFIG=/tmp/kubeconfig) hinzu.

3. Starten Sie den Build:

   gcloud builds submit --region=REGION --project=project-id --config build-config
   

   Wobei:

   • project-id ist die ID für Ihr Projekt.
   • build-config ist der Name Ihrer Build-Konfigurationsdatei.
   • REGION ist eine der unterstützten Build-Regionen.

Neues Containerimage erstellen und bereitstellen

So erstellen Sie ein neues Containerimage und stellen das neue Containerimage bereit:

1. Aktualisieren Sie die Kubernetes-Konfigurationsdatei mithilfe des Attributs --image mit dem neuen Containerimage:

   YAML

   steps:
     # build the container image
   - name: "gcr.io/cloud-builders/docker"
     args: ["build", "-t", "gcr.io/project-id/image:tag", "."]
     # push container image
   - name: "gcr.io/cloud-builders/docker"
     args: ["push", "gcr.io/project-id/image:tag"]
     # deploy container image to GKE
   - name: "gcr.io/cloud-builders/gke-deploy"
     args:
     - run
     - --filename=kubernetes-resource-file
     - --image=gcr.io/project-id/image:tag
     - --location=location
     - --cluster=cluster
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "build",
           "-t",
           "gcr.io/project-id/image:tag",
           "."
         ]
       },
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "push",
           "gcr.io/project-id/image:tag"
         ]
       },
       {
         "name": "gcr.io/cloud-builders/gke-deploy",
         "args": [
           "run",
           "--filename=kubernetes-resource-file",
           "--image=gcr.io/project-id/image:tag",
           "--location=location",
           "--cluster=cluster"
         ]
       }
     ]
   }
   

   Wobei:

   • project-id ist die ID für Ihr Projekt.
   • image ist der gewünschte Name des Container-Images, normalerweise der Anwendungsname.
   • tag ist das Tag des Container-Images.
     • Wenn Sie bei jedem Commit ein neues Container-Image erstellen, empfiehlt es sich, das Commit-Kürzel "SHA" als Tag zu verwenden. Cloud Build stellt dies als Standardsubstitution $SHORT_SHA zur Verfügung.
   • kubernetes-resource-file ist der Dateipfad der Kubernetes-Ressourcendatei oder der Pfad zu dem Verzeichnis, das die Kubernetes-Ressourcendateien enthält.
   • cluster ist der Name des GKE-Clusters, in dem die Anwendung bereitgestellt wird.
   • location ist die Region/Zone des Clusters, in dem die Anwendung bereitgestellt wird.
   Hinweis: gke-deploy kann nur auf ein Image in der Build-Konfigurationsdatei verweisen. Wenn Ihre Kubernetes-Konfigurationsdateien mehrere Imagereferenzen enthalten, werden nur die Images, die mit gcr/project-id/image beginnen, so aktualisiert, dass sie auf das angegebene Tag verweisen.

2. Starten Sie den Build:

   gcloud builds submit --region=REGION --project=project-id --config build-config
   

   Wobei:

   • project-id ist die ID für Ihr Projekt.
   • build-config ist der Name Ihrer Build-Konfigurationsdatei.
   • REGION ist eine der unterstützten Build-Regionen.

Bereitstellungen automatisieren

Sie können die Bereitstellung Ihrer Anwendung in GKE automatisieren, indem Sie in Cloud Build einen Trigger erstellen. Sie können den Trigger so konfigurieren, dass Images erstellt und bereitgestellt werden, wenn Sie Änderungen an Ihrem Code per Push-Befehl übertragen.

So erstellen Sie einen Build-Trigger:

1. Öffnen Sie in der Google Cloud Console die Seite Trigger:

   Zur Seite "Trigger"

2. Wählen Sie oben auf der Seite im Drop-down-Menü zur Projektauswahl Ihr Projekt aus.

3. Klicken Sie auf Öffnen.

4. Klicken Sie auf Trigger erstellen.

   Auf der Seite Erstellen Sie einen Trigger geben Sie die folgenden Einstellungen ein:

   1. Geben Sie einen Namen für den Trigger ein.

   2. Wählen Sie das Repository-Ereignis aus, das den Trigger aufrufen soll.

   3. Wählen Sie das Repository aus, das Ihren Quellcode enthält, und erstellen Sie die Konfigurationsdatei.

   4. Geben Sie den regulären Ausdruck für den Zweig- oder Tag-Namen an, mit dem der Trigger gestartet wird.

   5. Wählen Sie eine Konfiguration für den Trigger aus.

      Wenn Sie eine Cloud Build-Konfigurationsdatei auswählen, können Sie Substitutionsvariablen angeben. Stellen Sie dazu einen Variablennamen und den Wert bereit, den Sie mit dieser Variablen verknüpfen möchten. Im unteren Beispiel gibt die benutzerdefinierte Substitutionsvariable _CLOUDSDK_CONTAINER_CLUSTER den Cluster für die Bereitstellung und die benutzerdefinierte Substitutionsvariable _CLOUDSDK_COMPUTE_ZONE dessen Standort an. Wenn Sie die Bereitstellung in einem anderen Cluster vornehmen möchten, können Sie dieselbe Build-Konfiguration verwenden und müssen nur die Werte der Substitutionsvariablen ändern:

      YAML

      steps:
      ...
      # deploy container image to GKE
      - name: "gcr.io/cloud-builders/gke-deploy"
        args:
        - run
        - --filename=kubernetes-resource-file
        - --image=gcr.io/project-id/image:tag
        - --location=${_CLOUDSDK_COMPUTE_ZONE}
        - --cluster=${_CLOUDSDK_CONTAINER_CLUSTER}
      

      JSON

      {
        "steps": [
          {
            "name": "gcr.io/cloud-builders/gke-deploy",
            "args": [
              "run",
              "--filename=kubernetes-resource-file",
              "--image=gcr.io/project-id/image:tag",
              "--location=${_CLOUDSDK_COMPUTE_ZONE}",
              "--cluster=${_CLOUDSDK_CONTAINER_CLUSTER}"
            ]
          }
        ]
      }
      

      Wobei:

      • kubernetes-resource-file ist der Dateipfad der Kubernetes-Konfigurationsdatei oder der Pfad zu dem Verzeichnis, das die Kubernetes-Ressourcendateien enthält.
      • project-id ist die ID für Ihr Projekt.
      • image ist der gewünschte Name des Container-Images, normalerweise der Anwendungsname.
      • tag ist das Tag des Container-Images.

      Weitere Informationen zum Definieren von Substitutionen für Build-Konfigurationsdateien finden Sie unter Benutzerdefinierte Substitutionen verwenden.

5. Klicken Sie auf Erstellen, um den Build-Trigger zu speichern.

Wenn Sie Code in Ihr Repository übertragen, löst Cloud Build automatisch einen Build aus. Weitere Informationen zu Build-Triggern finden Sie unter Build-Trigger erstellen und verwalten.

Nächste Schritte

• Automatisierte Bereitstellungen für Ihre Arbeitslasten in GKE konfigurieren
• CI-/CD-Pipeline im GitOps-Stil erstellen, die mit Cloud Build Bereitstellungen in GKE vornimmt
• Weitere Informationen zu gke-deploy-Optionen
• Weitere Informationen zu Blau/Grün-Bereitstellungen in der Compute Engine
• Weitere Informationen zu Cloud-Buildern
• Build-Fehler beheben