Skip to main content

Bereitstellen in der Google Kubernetes Engine

Du kannst Bereitstellungen in Google Kubernetes Engine im Rahmen deiner Continuous-Deployment-Workflows (CD) vornehmen.

Einführung

In diesem Leitfaden wird erläutert, wie GitHub Actions verwendet wird, um eine containerisierte Anwendung zu erstellen, sie in Google Container Registry (GCR) zu pushen und sie in Google Kubernetes Engine (GKE) bereitzustellen, wenn ein Push in den main-Branch erfolgt.

GKE ist ein verwalteter Kubernetes-Clusterdienst von Google Cloud, der deine containerisierten Workloads in der Cloud oder in deinem eigenen Rechenzentrum hosten kann. Weitere Informationen findest du unter Google Kubernetes Engine.

Note

Wenn deine GitHub Actions-Workflows auf Ressourcen eines Cloudanbieters zugreifen müssen, der OpenID Connect (OIDC) unterstützt, kannst du deine Workflows so konfigurieren, dass die Authentifizierung direkt beim Cloudanbieter erfolgt. Dadurch musst du diese Anmeldeinformationen nicht mehr als langlebige Geheimnisse speichern und profitierst zudem von weiteren Sicherheitsvorteilen. Weitere Informationen findest du unter Informationen zur Sicherheitshärtung mit OpenID Connect.

Voraussetzungen

Bevor du mit dem Erstellen des Workflows fortfährst, musst du die folgenden Schritte für dein Kubernetes-Projekt ausführen. In diesem Leitfaden wird davon ausgegangen, dass der Stamm deines Projekts bereits über eine Dockerfile-Datei und eine Konfigurationsdatei für die Kubernetes-Bereitstellung verfügt.

Erstellen eines GKE-Clusters

Um den GKE-Cluster zu erstellen, musst du dich zuerst mithilfe der gcloud-CLI authentifizieren. Weitere Informationen zu diesem Schritt findest du in den folgenden Artikeln:

Beispiel:

Shell
$ gcloud container clusters create $GKE_CLUSTER \
    --project=$GKE_PROJECT \
    --zone=$GKE_ZONE

Aktivieren der APIs

Aktiviere die Kubernetes Engine- und Container Registry-APIs. Beispiel:

Shell
$ gcloud services enable \
    containerregistry.googleapis.com \
    container.googleapis.com

Konfigurieren eines Dienstkontos und Speichern seiner Anmeldeinformationen

In diesem Verfahren wird gezeigt, wie du das Dienstkonto für deine GKE-Integration erstellst. Es erklärt, wie man das Konto erstellt, ihm Rollen hinzufügt, seine Schlüssel abruft und sie als Base64-verschlüsseltes verschlüsseltes Repository-Geheimnis mit dem Namen GKE_SA_KEY speichert.

  1. Erstelle ein neues Dienstkonto:

    Shell
    gcloud iam service-accounts create $SA_NAME
    
  2. Rufe die E-Mail-Adresse des soeben erstellten Dienstkontos ab:

    Shell
    gcloud iam service-accounts list
    
  3. Füge dem Dienstkonto Rollen hinzu.

    Note

    Du kannst restriktivere Rollen anwenden, um deine Anforderungen zu erfüllen.

    Shell
    gcloud projects add-iam-policy-binding $GKE_PROJECT \
      --member=serviceAccount:$SA_EMAIL \
      --role=roles/container.admin
    gcloud projects add-iam-policy-binding $GKE_PROJECT \
      --member=serviceAccount:$SA_EMAIL \
      --role=roles/storage.admin
    gcloud projects add-iam-policy-binding $GKE_PROJECT \
      --member=serviceAccount:$SA_EMAIL \
      --role=roles/container.clusterViewer
    
  4. Lade die JSON-Schlüsseldatei für das Dienstkonto herunter:

    Shell
    gcloud iam service-accounts keys create key.json --iam-account=$SA_EMAIL
    
  5. Speichere den Dienstkontoschlüssel als Geheimnis namens GKE_SA_KEY:

    Shell
    export GKE_SA_KEY=$(cat key.json | base64)
    

    Weitere Informationen zum Speichern eines Geheimnisses findest du unter Verwenden von Geheimnissen in GitHub-Aktionen.

Speichern des Projektnamens

Speichere den Namen deines Projekts als Geheimnis namens GKE_PROJECT. Weitere Informationen zum Speichern eines Geheimnisses findest du unter Verwenden von Geheimnissen in GitHub-Aktionen.

(Optional) Konfigurieren von Kustomize

Kustomize ist ein optionales Tool zum Verwalten von YAML-Spezifikationen. Nach dem Erstellen einer kustomization-Datei kann der folgende Workflow verwendet werden, um dynamisch Felder des Images festzulegen und das Ergebnis an kubectl weiterzuleiten. Weitere Informationen findest du unter Kustomize-Syntax.

(Optional) Konfigurieren einer Bereitstellungsumgebung

Umgebungen werden verwendet, um ein allgemeines Bereitstellungsziel wie production, staging oder development zu beschreiben. Wenn ein GitHub Actions-Workflow in einer Umgebung bereitgestellt wird, wird die Umgebung auf der Hauptseite des Repositorys angezeigt. Du kannst Umgebungen verwenden, um die Genehmigung für die Fortsetzung eines Auftrags anzufordern, einzuschränken, welche Branches einen Workflow auslösen können, Bereitstellungen mit benutzerdefinierten Bereitstellungsschutzregeln zu schützen oder den Zugriff auf Geheimnisse zu beschränken. Weitere Informationen zum Erstellen von Umgebungen findest du unter Verwalten von Umgebungen für die Bereitstellung.

Erstellen des Workflows

Nachdem die Voraussetzungen erfüllt sind, kannst du mit dem Erstellen des Workflows fortfahren.

Im folgenden Beispielworkflow wird gezeigt, wie du ein Containerimage erstellst und in GCR pushst. Anschließend werden die Kubernetes-Tools (z. B kubectl und kustomize) verwendet, um das Image in die Clusterbereitstellung zu pullen.

Ändere unter dem env-Schlüssel den Wert von GKE_CLUSTER in den Namen deines Clusters, GKE_ZONE in deine Clusterzone, DEPLOYMENT_NAME in den Namen deiner Bereitstellung und IMAGE in den Namen deines Images.

Wenn du eine Bereitstellungsumgebung konfiguriert hast, ändere den Wert environment in den Namen deiner Umgebung. Wenn du keine Umgebung konfiguriert hast oder wenn sich dein Workflow in einem privaten Repository befindet und du GitHub Enterprise Cloud nicht verwendest, lösche den environment-Schlüssel.

YAML
# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Build and Deploy to GKE

on:
  push:
    branches:
      - main

env:
  PROJECT_ID: ${{ secrets.GKE_PROJECT }}
  GKE_CLUSTER: cluster-1    # Add your cluster name here.
  GKE_ZONE: us-central1-c   # Add your cluster zone here.
  DEPLOYMENT_NAME: gke-test # Add your deployment name here.
  IMAGE: static-site

jobs:
  setup-build-publish-deploy:
    name: Setup, Build, Publish, and Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    # Setup gcloud CLI
    - uses: google-github-actions/setup-gcloud@1bee7de035d65ec5da40a31f8589e240eba8fde5
      with:
        service_account_key: ${{ secrets.GKE_SA_KEY }}
        project_id: ${{ secrets.GKE_PROJECT }}

    # Configure Docker to use the gcloud command-line tool as a credential
    # helper for authentication
    - run: |-
        gcloud --quiet auth configure-docker

    # Get the GKE credentials so we can deploy to the cluster
    - uses: google-github-actions/get-gke-credentials@db150f2cc60d1716e61922b832eae71d2a45938f
      with:
        cluster_name: ${{ env.GKE_CLUSTER }}
        location: ${{ env.GKE_ZONE }}
        credentials: ${{ secrets.GKE_SA_KEY }}

    # Build the Docker image
    - name: Build
      run: |-
        docker build \
          --tag "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA" \
          --build-arg GITHUB_SHA="$GITHUB_SHA" \
          --build-arg GITHUB_REF="$GITHUB_REF" \
          .

    # Push the Docker image to Google Container Registry
    - name: Publish
      run: |-
        docker push "gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA"

    # Set up kustomize
    - name: Set up Kustomize
      run: |-
        curl -sfLo kustomize https://github.com/kubernetes-sigs/kustomize/releases/download/v3.1.0/kustomize_3.1.0_linux_amd64
        chmod u+x ./kustomize

    # Deploy the Docker image to the GKE cluster
    - name: Deploy
      run: |-
        ./kustomize edit set image gcr.io/PROJECT_ID/IMAGE:TAG=gcr.io/$PROJECT_ID/$IMAGE:$GITHUB_SHA
        ./kustomize build . | kubectl apply -f -
        kubectl rollout status deployment/$DEPLOYMENT_NAME
        kubectl get services -o wide

Zusätzliche Ressourcen

Weitere Informationen zu den in diesen Beispielen verwendeten Tools findest du in der folgenden Dokumentation: