Diese Seite wurde von der Cloud Translation API übersetzt.

In Google Kubernetes Engine bereitstellen

In diesem Leitfaden wird beschrieben, wie Sie Images aus Artifact Registry abrufen, um sie dort bereitzustellen Google Kubernetes Engine Wenn Sie die Bereitstellung in einem selbst gehosteten oder Drittanbieter-Kubernetes vornehmen möchten müssen Sie vor dem Abrufen die Authentifizierung bei Google Cloud konfigurieren. Images aus Artifact Registry. Authentifizierung von Kubernetes bei Google Cloud Arbeitslasten außerhalb von Google Cloud, siehe Identitätsföderation von Arbeitslasten 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 die folgenden Standardeinstellungen, wenn Sie Knotenpools oder Cluster:

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

Mit diesen Standardeinstellungen kann GKE Images aus Artifact Registry-Repositories im selben Google Cloud-Projekt. Wenn Sie müssen Images von Knoten übertragen, projektübergreifend abrufen oder übertragen, eines vom Nutzer bereitgestellten Dienstkontos oder nicht unterstützen, finden Sie in der Dokumentation zur Zugriffssteuerung Informationen zum Konfigurieren des Zugriffs.

Wenn die Meldung „Berechtigung verweigert“ angezeigt wird Fehler finden Sie unter 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, muss Kubernetes imagePullSecrets so konfigurieren, dass GKE zum Abrufen von Images aktivieren.

Wenn sich GKE in einem anderen Projekt als Artifact Registry befindet, Artifact Registry-Berechtigungen zu gewähren für den Dienstkonto, das Ihr GKE-Knoten verwendet. 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 Google Cloud Console Projekt-ID. 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 Standardknoten-Image für Linux-Knoten ist das Container-Optimized OS mit containerd. (cos_containerd) anstelle von Container-Optimized OS mit Docker-Variante (cos).

Die Docker-Binärdatei ist auf Linux-Knoten verfügbar, containerd als Laufzeit verwendet werden soll. Docker verwaltet nicht Die Container, die Kubernetes auf containerd-Knoten ausführen, können nicht verwendet werden, Mit Docker-Befehlen ausgeführte Kubernetes-Container anzeigen oder mit ihnen interagieren der Docker API.

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 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.

Daten aus einem öffentlichen Artifact Registry-Repository abrufen

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

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

Console

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

Zu Seite „VM-Instanzen“
Klicken Sie in der Liste der VM-Instanzen auf den Pfeil neben SSH in der Zeile der Instanz, die Sie verbinden möchten an.

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, siehe SSH-Verbindungen zu Linux-VMs
Wählen Sie „Im Browserfenster öffnen“ aus. oder die Verbindungsmethode Ihrer Wahl. aus.
In der Google Cloud Console wird ein neues Terminalfenster geöffnet. crictl für Folgendes verwenden: Rufen Sie ein Image aus Artifact Registry ab:
```
crictl pull IMAGE_LOCATION:TAG
```
Die Ausgabe sieht 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. Mit einem Zugriffstoken können Sie Anmeldedaten angeben.

gcloud

Achten Sie darauf, dass Sie die neueste Version der Google Cloud CLI verwenden
```
gcloud components update
```
Stellen Sie eine Verbindung zur VM her.
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
Dabei gilt:
- 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
```
SSH-Schlüssel generieren, wenn Sie noch keinen SSH-Schlüssel erstellt haben. für Sie. Geben Sie eine Passphrase ein oder lassen Sie das Feld leer, wenn Sie dazu aufgefordert werden.
Verwenden Sie crictl, um ein Image aus Artifact Registry abzurufen:
```
crictl pull IMAGE_LOCATION:TAG
```
Die Ausgabe sieht 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. Mit einem Zugriffstoken können Sie Anmeldedaten angeben.

Daten aus einem privaten Artifact Registry-Repository abrufen

Console

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

Zu Seite „VM-Instanzen“
Klicken Sie in der Liste der VM-Instanzen auf den Pfeil neben SSH in der Zeile der Instanz, die Sie verbinden möchten an.

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, siehe SSH-Verbindungen zu Linux-VMs
Wählen Sie „Im Browserfenster öffnen“ aus. aus.

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

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"}

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

Rufen Sie das Image mit crictl pull --creds und dem Wert access_token ab kopiert haben.

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

Die Ausgabe sieht so aus:

Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

gcloud

Achten Sie darauf, dass Sie die neueste Version der Google Cloud CLI verwenden
```
gcloud components update
```
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
```
SSH-Schlüssel generieren, wenn Sie noch keinen SSH-Schlüssel erstellt haben. für Sie. Geben Sie eine Passphrase ein oder lassen Sie das Feld leer, wenn Sie dazu aufgefordert werden.

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

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"}

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

Rufen Sie das Image mit crictl pull --creds und dem Wert access_token ab kopiert haben.

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

Die Ausgabe sieht so aus:

Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5

Mit crictl können Entwickler ihre Laufzeit debuggen, ohne dass eine Einrichtung erforderlich ist Kubernetes-Komponenten Eine vollständige Liste der Befehle finden Sie in der crictl-Dokumentation. und in den Kubernetes-Debugging-Dokumenten.