In Google Kubernetes Engine bereitstellen

In diesem Leitfaden wird beschrieben, wie Sie Images aus Artifact Registry abrufen, um sie in Google Kubernetes Engine bereitzustellen. Wenn Sie die Bereitstellung in selbst gehosteten Kubernetes-Diensten oder Kubernetes-Diensten von Drittanbietern vornehmen möchten, müssen Sie die Authentifizierung bei Google Cloud konfigurieren, bevor Sie Images aus Artifact Registry abrufen. Informationen zum Authentifizieren bei Google Cloud von Kubernetes-Arbeitslasten außerhalb von Google Cloud finden Sie unter Workload Identity-Föderation mit Kubernetes konfigurieren.

Mit Google Kubernetes Engine können Sie Images direkt aus Docker-Repositories abrufen. Einige Versionen bieten eine vorkonfigurierte Unterstützung zum Abrufen von Images aus Artifact Registry-Docker-Repositories.

Voraussetzungen

In diesem Abschnitt werden die Anforderungen für die Einbindung in GKE beschrieben.

Berechtigungen

GKE verwendet beim Erstellen von Knotenpools oder -clustern die folgenden Standardeinstellungen:

• Das Compute Engine-Standarddienstkonto ist die Identität für Knoten. Dieses Standarddienstkonto hat die Artifact Registry-Rolle „Leser“ (roles/artifactregistry.reader), wenn die Erteilung der einfachen Rolle „Bearbeiter“ deaktiviert ist.
• Knoten, die Sie mit dem Standarddienstkonto erstellen, haben die Compute Engine-Standardzugriffsbereiche, einschließlich Lesezugriff auf den Speicher. Zugriffsbereiche auf vorhandenen Knoten können nicht geändert werden.

Wenn Sie diese Standardeinstellungen verwenden, kann GKE Images aus Artifact Registry-Repositories im selben Google Cloud-Projekt abrufen. Wenn Sie Images von Knoten übertragen, Images projektübergreifend abrufen oder übertragen müssen, ein vom Nutzer bereitgestelltes Dienstkonto verwenden oder andere Anforderungen haben, die von den Standardeinstellungen nicht unterstützt werden, finden Sie in der Dokumentation zur Zugriffssteuerung Informationen zum Konfigurieren des Zugriffs.

Wenn der Fehler „Berechtigung verweigert“ auftritt, lesen Sie den Fehler „Berechtigung verweigert“.

GKE-Version

In der folgenden Tabelle sind die erforderlichen Mindestversionen für GKE aufgeführt, um Cluster zu erstellen, die Standardberechtigungen zum Herunterladen von Containern aus Docker-Repositories im selben Projekt haben.

Version	Mindestens erforderlicher Patch
1,14	1.14.10-gke.22
1.15	1.15.9-gke.8

Wenn Ihre GKE-Version älter als die Mindestversion ist, müssen Sie Kubernetes imagePullSecrets konfigurieren, damit GKE Images abrufen kann.

Wenn sich GKE in einem anderen Projekt als Artifact Registry befindet, müssen Sie dem Dienstkonto, das Ihr GKE-Knoten verwendet, Artifact Registry-Berechtigungen erteilen. Standardmäßig verwenden Knoten das Standarddienstkonto von Compute Engine.

Image ausführen

Mit dem folgenden Befehl führen Sie ein Artifact Registry-Image in einem Google Kubernetes Engine-Cluster aus:

kubectl run [NAME] --image=LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG

Dabei gilt:

• LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
• PROJECT ist Ihre Projekt-ID der Google Cloud Console. Wenn die Projekt-ID einen Doppelpunkt (:) enthält, finden Sie weitere Informationen unter Auf Domains beschränkte Projekte.
• REPOSITORY ist der Name des Repositorys, in dem das Image gespeichert ist.
• IMAGE ist der Name des Images im Repository.
• TAG ist das Tag für die Image-Version, die Sie herunterladen möchten.

Weitere Informationen zu Kubernetes-Befehlen finden Sie in der Übersicht zu kubectl.

Fehlerbehebung bei containerd-Knoten-Images

Ab GKE-Knotenversion 1.19 ist das standardmäßige Knoten-Image für Linux-Knoten das Container-Optimized OS mit containerd (cos_containerd)-Variante anstelle der Variante Container-Optimized OS mit Docker (cos).

Das Docker-Binärprogramm ist zwar auf Linux-Knoten verfügbar, die containerd als Laufzeit verwenden, wird jedoch nicht empfohlen. Docker verwaltet die Container nicht, die Kubernetes auf containerd-Knoten ausführt. Daher können Sie es nicht verwenden, um laufende Kubernetes-Container mithilfe von Docker-Befehlen oder der Docker API anzuzeigen oder mit ihnen zu interagieren.

Zum Debugging und zur Problembehebung auf Linux-Knoten können Sie mithilfe des speziell für Kubernetes-Containerlaufzeiten erstellten portablen Befehlszeilentools mit containerd interagieren: crictl crictl unterstützt allgemeine Funktionen, mit denen Sie Container und Images aufrufen, Logs lesen und Befehle in den Containern ausführen können.

Weitere Informationen finden Sie im Nutzerhandbuch für crictl und in der GKE-Dokumentation zu containerd.

Bei Windows Server-Knoten wird der Containerd-Daemon als Windows-Dienst mit dem Namen containerd ausgeführt. Logs sind im folgenden Logverzeichnis verfügbar: C:\etc\kubernetes\logs\containerd.log und werden im Log-Explorer unter LOG NAME: "container-runtime" angezeigt.

Warnung: Docker kann keine Container für Linux- und Windows-Knotenpools aufrufen oder darauf zugreifen, die containerd als Laufzeit verwenden.

Daten aus einem öffentlichen Artifact Registry-Repository abrufen

Nachdem Sie ein Image in einem GKE-Cluster mit containerd-Knoten bereitgestellt haben, können Sie mit SSH eine Verbindung zu einer VM-Instanz herstellen und crictl-Befehle zur Fehlerbehebung ausführen.

Public Artifact Registry-Repositories erfordern keine Authentifizierung. crictl kann auch verwendet werden, um Images in privaten Artifact Registry-Repositories abzurufen.

Console

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der VM-Instanzen in der Zeile der Instanz, zu der Sie eine Verbindung herstellen möchten, auf den Pfeil neben SSH.

   

   Hinweis: Wenn Sie über die Google Cloud Console eine Verbindung zu VMs herstellen, erstellt Compute Engine einen sitzungsspezifischen SSH-Schlüssel für Sie. Weitere Informationen zu SSH-Schlüsseln finden Sie unter SSH-Verbindungen zu Linux-VMs.

3. Wählen Sie „Im Browserfenster öffnen“ oder die gewünschte Verbindungsmethode aus den Drop-down-Optionen aus.

4. In der Google Cloud Console wird ein neues Terminalfenster geöffnet. Verwenden Sie crictl, um ein Image aus Artifact Registry abzurufen:

   crictl pull IMAGE_LOCATION:TAG
   

   Die Ausgabe sieht in etwa so aus:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

   Wenn Sie ein Image aus einem privaten Artifact Registry-Repository abrufen, müssen Sie sich beim Repository authentifizieren. Sie können ein Zugriffstoken verwenden, um Ihre Anmeldedaten bereitzustellen.

gcloud

1. Achten Sie darauf, dass Sie die neueste Version der Google Cloud CLI verwenden

   gcloud components update
   

2. Stellen Sie eine Verbindung zur VM her.

   gcloud compute ssh --project=PROJECT_ID \
    --zone=ZONE \
    VM_NAME
   

   Ersetzen Sie Folgendes:

   • PROJECT_ID: Die ID des Projekts, das die VM enthält
   • ZONE: Der Name der Zone, in der sich die VM befindet
   • VM_NAME: Der Name der VM

   Wenn Sie Standardeigenschaften für das Google Cloud CLI festgelegt haben, können Sie die Flags --project und --zone bei diesem Befehl weglassen. Beispiel:

   gcloud compute ssh VM_NAME
   

3. Wenn Sie noch keinen SSH-Schlüssel erstellt haben, generiert SSH Keygen einen für Sie. Geben Sie eine Passphrase ein oder lassen Sie das Feld leer, wenn Sie dazu aufgefordert werden.

4. Verwenden Sie crictl, um ein Image aus Artifact Registry abzurufen:

   crictl pull IMAGE_LOCATION:TAG
   

5. Die Ausgabe sieht in etwa so aus:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

   Wenn Sie ein Image aus einem privaten Artifact Registry-Repository abrufen, müssen Sie sich beim Repository authentifizieren. Sie können ein Zugriffstoken verwenden, um Ihre Anmeldedaten bereitzustellen.

Daten aus einem privaten Artifact Registry-Repository abrufen

Console

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der VM-Instanzen in der Zeile der Instanz, zu der Sie eine Verbindung herstellen möchten, auf den Pfeil neben SSH.

   

   Hinweis: Wenn Sie über die Google Cloud Console eine Verbindung zu VMs herstellen, erstellt Compute Engine einen sitzungsspezifischen SSH-Schlüssel für Sie. Weitere Informationen zu SSH-Schlüsseln finden Sie unter SSH-Verbindungen zu Linux-VMs.

3. Wählen Sie im Dropdown-Menü die Option "Im Browserfenster öffnen" aus.

4. In der Google Cloud Console wird ein neues Terminalfenster geöffnet. Generieren Sie mit curl ein Zugriffstoken für das Compute Engine-Dienstkonto.

   curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
   

   Die Ausgabe sieht so aus:

   "access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
   HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
   sh","expires_in":3526,"token_type":"Bearer"}

5. Kopieren Sie den Wert von access_token aus der zurückgegebenen Ausgabe ohne die Anführungszeichen.

6. Rufen Sie das Bild mit crictl pull --creds und dem access_token-Wert ab, den Sie im vorherigen Schritt kopiert haben.

   crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

   Die Ausgabe sieht in etwa so aus:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

gcloud

1. Achten Sie darauf, dass Sie die neueste Version der Google Cloud CLI verwenden

   gcloud components update
   

2. Stellen Sie eine Verbindung zur VM her.

   gcloud compute ssh --project=PROJECT_ID \
    --zone=ZONE \
    VM_NAME
   

   Ersetzen Sie die folgenden Variablen:

   • PROJECT_ID: Die ID des Projekts, das die VM enthält
   • ZONE: Der Name der Zone, in der sich die VM befindet
   • VM_NAME: Der Name der VM

   Wenn Sie Standardeigenschaften für das Google Cloud CLI festgelegt haben, können Sie die Flags --project und --zone bei diesem Befehl weglassen. Beispiel:

   gcloud compute ssh VM_NAME
   

3. Wenn Sie noch keinen SSH-Schlüssel erstellt haben, generiert SSH Keygen einen für Sie. Geben Sie eine Passphrase ein oder lassen Sie das Feld leer, wenn Sie dazu aufgefordert werden.

4. Generieren Sie mit curl ein Zugriffstoken für das Compute Engine-Dienstkonto.

   curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
   

   Die Ausgabe sieht in etwa so aus:

   "access_token":"ya29.c.KpkBCQgdwv6LrZ2tjrCpG6snWwPMX29LzMeUmAV_Hq_XaxUurfXcCfGZfASGh_KbdmUYTvkuV3sh-WaSBplEskdP6Tc
   HDsTv4B9hMyvoL4M9HrzKHuKTa1ZGj_3iQ1lwq_dAMxAPGjxEVKexatwN2KP0EAWyb6R55Cuu8ItgLf9f4pm9lC5zH4Qo0fkxPUsnCGRBe4AYxEpN6T
   sh","expires_in":3526,"token_type":"Bearer"}

5. Kopieren Sie den Wert von access_token aus der zurückgegebenen Ausgabe ohne die Anführungszeichen.

6. Rufen Sie das Bild mit crictl pull --creds und dem access_token-Wert ab, den Sie im vorherigen Schritt kopiert haben.

   crictl pull --creds "oauth2accesstoken:ACCESS_TOKEN" IMAGE_LOCATION:TAG

   Die Ausgabe sieht in etwa so aus:

   Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

Mit crictl können Entwickler ihre Laufzeit debuggen, ohne Kubernetes-Komponenten einrichten zu müssen. Eine vollständige Liste der Befehle finden Sie in der crictl-Dokumentation und in den Kubernetes-Debugging-Dokumenten.