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 erstellen:
- Das Compute Engine-Standarddienstkonto ist die Identität für Knoten. Dieses Standarddienstkonto hat die einfache IAM-Rolle „Bearbeiter“, wenn Sie dieses Verhalten nicht deaktiviert haben.
- Knoten, die Sie mit dem Standarddienstkonto erstellen, haben die Standard-Zugriffsbereiche von Compute Engine, einschließlich Lesezugriff auf Speicher. Sie können Zugriffsbereiche auf vorhandenen Knoten nicht ändern.
Wenn Sie diese Standardeinstellungen verwenden, kann GKE Images aus Artifact Registry-Repositories im selben Google Cloud-Projekt abrufen. Wenn Sie Images von Knoten verschieben, 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.
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 | 14.10-gke.22 |
1.15 | 1.15.9-gke.8 |
Wenn Ihre GKE-Version vor der Mindestversion liegt, müssen Sie Kubernetes imagePullSecrets konfigurieren, damit GKE Images abrufen kann.
Wenn sich GKE in einem anderen Projekt als Artifact Registry befindet, gewähren Sie Artifact Registry Berechtigungen für das Dienstkonto, das Ihr GKE-Knoten verwendet. Knoten verwenden standardmäßig das Compute Engine-Standarddienstkonto.
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
wobei
- LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
- PROJECT ist die ID Ihres Projekts in 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 Container-Knoten-Images
Ab GKE-Knotenversion 1.19 ist das Standardknoten-Image für Linux-Knoten die Variante „Container-Optimized OS mit Containerd“ (cos_containerd
) anstelle der Variante „Container-Optimized OS mit Docker (cos
)“.
Das Docker-Binärprogramm ist derzeit auf Linux-Knoten verfügbar, die containerd als Laufzeit verwenden. Es wird jedoch nicht empfohlen. Docker verwaltet nicht die Container, die Kubernetes auf containerd-Knoten ausführt. Daher können Sie es nicht verwenden, um laufende Kubernetes-Container mit Docker-Befehlen oder der Docker API anzusehen oder mit diesen 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.
Aus einem öffentlichen Artifact Registry-Repository abrufen
Nachdem Sie das Image bereitgestellt und in einem GKE-Cluster mit Containerd-Knoten bereitgestellt haben, können Sie über SSH eine Verbindung zu einer VM-Instanz herstellen und crictl
-Befehle zur Fehlerbehebung ausführen.
Für öffentliche Artifact Registry-Repositories ist keine Authentifizierung erforderlich. 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.
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.
Wählen Sie im Drop-down-Menü die Option „Im Browserfenster öffnen“ oder die gewünschte Verbindungsmethode aus.
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 Repository von Artifact Registry abrufen, müssen Sie sich im Repository authentifizieren. Sie können Ihre Anmeldedaten mit einem Zugriffstoken bereitstellen.
gcloud
Sie benötigen die neueste Version der Google Cloud CLI.
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ältZONE
: Der Name der Zone, in der sich die VM befindetVM_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
Wenn Sie noch keinen SSH-Schlüssel erstellt haben, generiert SSH einen Schlüsselgener. 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 in etwa so aus:
Image is up to date for sha256:0f25067aa9c180176967b4b50ed49eed096d43fa8c17be9a5fa9bff05933bee5
Wenn Sie ein Image aus einem privaten Repository von Artifact Registry abrufen, müssen Sie sich im Repository authentifizieren. Sie können Ihre Anmeldedaten mit einem Zugriffstoken bereitstellen.
Aus einem privaten Artifact Registry-Repository abrufen
Console
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
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.
Wählen Sie im Drop-down-Menü die Option „Im Browserfenster öffnen“ aus.
In der Google Cloud Console wird ein neues Terminalfenster geöffnet. Generieren Sie mit
curl
ein Compute Engine-Dienstkonto-Zugriffstoken.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 Anführungszeichen.Rufen Sie das Image mit
crictl pull --creds
und dem im vorherigen Schritt kopierten Wertaccess_token
ab.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
Sie benötigen die neueste Version der Google Cloud CLI.
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ältZONE
: Der Name der Zone, in der sich die VM befindetVM_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
Wenn Sie noch keinen SSH-Schlüssel erstellt haben, generiert SSH einen Schlüsselgener. Geben Sie eine Passphrase ein oder lassen Sie das Feld leer, wenn Sie dazu aufgefordert werden.
Generieren Sie mit
curl
ein Compute Engine-Dienstkonto-Zugriffstoken.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"}
Kopieren Sie den Wert von
access_token
aus der zurückgegebenen Ausgabe ohne Anführungszeichen.Rufen Sie das Image mit
crictl pull --creds
und dem im vorherigen Schritt kopierten Wertaccess_token
ab.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 Fehler in ihrer Laufzeit beheben, ohne Kubernetes-Komponenten einrichten zu müssen. Eine vollständige Liste der Befehle finden Sie in der crictl
-Dokumentation und in der Kubernetes-Dokumentation zur Fehlerbehebung.