Private Image-Registry ohne Secrets verwenden

GKE on AWS bietet eine Möglichkeit, private Images aus Artifact Registry oder Container Registry abzurufen, ohne ein Kubernetes-Secret verwenden zu müssen. Bisher mussten Sie die folgenden Schritte ausführen:

1. Erstellen Sie ein Google IAM-Dienstkonto (Identity and Access Management).
2. Gewähren Sie dem Dienstkonto Berechtigungen für den Zugriff auf die private Registry.
3. Laden Sie den Dienstkontoschlüssel herunter und speichern Sie ihn als Kubernetes-Secret in Ihrem Cluster.
4. Verweisen Sie in Ihrem YAML-Manifest für Pods oder Deployments auf dieses Secret, damit sie auf Images aus dem privaten Container-Repository zugreifen können.
5. Rotieren und verwalten Sie regelmäßig die Schlüssel, die mit dem Google IAM-Dienstkonto verknüpft sind.

GKE on AWS macht all diese manuellen Schritte überflüssig und übernimmt automatisch die für das Abrufen privater Images erforderliche Authentifizierung und Autorisierung.

Hinweise

Führen Sie zuerst die folgende Aufgaben aus, um die Schritte auf dieser Seite auszuführen:

• Cluster erstellen
• Erstellen Sie einen Knotenpool.

• Clusterzugriff für "kubectl" konfigurieren.

• Docker-Image erstellen und in die Artifact Registry verschieben In den Beispielen auf dieser Seite wird der Container hello-app verwendet. Um diesen Container zu erstellen, folgen Sie den Schritten zum Erstellen eines Container-Images und zum Übertragen des Docker-Images per Push an Artifact Registry, die Teil der Google Cloud -GKE sind.

• Führen Sie ein Upgrade auf Version 1.28 von GKE on AWS durch, damit Sie private Images aus Artifact Registry oder Container Registry abrufen können, ohne ein Kubernetes-Secret verwenden zu müssen.

In Artifact Registry nach Images suchen

Für die restlichen Schritte benötigen Sie ein Container-Image. Rufen Sie also den Namen Ihres Container-Images ab. Gehen Sie dazu so vor:

1. Konfigurieren Sie das Docker-Befehlszeilentool zur Authentifizierung bei Artifact Registry mit dem Google Cloud SDK:

   gcloud auth configure-docker
   

   Die Google Cloud CLI registriert einen Credential Helper für alle von Google unterstützten Docker-Registries.

2. Prüfen Sie, ob Ihre Artifact Registry ein Image mit dem Befehl docker images enthält:

   docker images
   

   Docker stellt eine Verbindung zu Artifact Registry her und gibt die in Ihrem Repository verfügbaren Images zurück. Die folgende Antwort zeigt beispielsweise ein Container-Image mit dem Namen hello-app im Repository PROJECT_NAME auf us-west1-docker.pkg.dev.

   REPOSITORY                                                            TAG          IMAGE ID       CREATED          SIZE
   us-west1-docker.pkg.dev/PROJECT_NAME/hello-repo/hello-app   v1           f7cfe0d58569   21 minutes ago   11.5MB
   

Wenn Sie noch kein Container-Image haben, erstellen Sie eines anhand der Schritte unter Container-Webanwendung bereitstellen.

Pods mit privaten Images ohne Image-Pull-Secrets erstellen

Wenn Sie einen Pod erstellen möchten, der auf ein privates Container-Image aus einer Registry zugreifen kann, müssen Sie das Feld spec.imagePullSecrets in Ihrer Pod-Spezifikation nicht mehr angeben. So richten Sie Ihren Pod ein:

1. Erstellen Sie eine Pod-Definition ohne das Feld spec.imagePullSecrets:

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
   spec:
     containers:
     - name: CONTAINER_NAME
       image: LOCATION-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:IMAGE_VERSION
   

   Ersetzen Sie Folgendes:

   • POD_NAME: der Name des Pods
   • CONTAINER_NAME: der Name des Containers im Pod.
   • LOCATION: die Google Cloud Region, die Ihre Registry enthält. Beispiel: us-west1
   • PROJECT_NAME: der Name des Google-Projekts, in dem sich Ihr Artifact Registry-Repository befindet. Dies kann dasselbe Projekt wie das Ihres Clusters sein. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie unter Artifact Registry verwenden, wenn sie sich nicht im selben Projekt wie Ihr Cluster befindet zusätzliche Schritte.
   • REPOSITORY_NAME: der Name Ihres Repositorys.
   • IMAGE_NAME: der Name des Images
   • IMAGE_VERSION: die Version des Bildes.

2. Wenden Sie die Konfiguration mit kubectl auf Ihren Cluster an:

   kubectl apply -f YAML_FILE_NAME
   

   Ersetzen Sie YAML_FILE_NAME durch den Namen Ihrer YAML-Datei.

Beispiel für das Erstellen von Pods ohne Image-Pull-Secrets

Hier ist ein Beispiel für das Erstellen eines Kubernetes-Pods ohne Image-Pull-Secrets. Der Pod ruft das Image hello-app aus Artifact Registry ab.

1. Wenn Sie das Image hello-app abrufen möchten, kopieren Sie die folgende YAML-Datei in eine Datei mit dem Namen hello-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-pod
   spec:
     containers:
     - name: hello-container
       image: us-west1-docker.pkg.dev/example-project/hello-repo/hello-app:v1
   

2. Wenden Sie die Konfiguration mit kubectl auf Ihren Cluster an:

   kubectl apply -f hello-pod.yaml
   

3. Prüfen Sie mit kubectl get, ob der Pod ausgeführt wird:

   kubectl get pod/hello-pod
   

   Die Antwort enthält einen Pod mit dem Status Running.

   NAME        READY   STATUS    RESTARTS   AGE
   hello-pod   1/1     Running   0          15s
   

Bereitstellungen mit privaten Images ohne Image-Pull-Secrets erstellen

Wenn Sie ein Deployment erstellen möchten, das auf ein privates Container-Image aus einer Registry zugreifen kann, müssen Sie das Feld spec.imagePullSecrets in der Deployment-Spezifikation nicht mehr angeben. So richten Sie Ihr Deployment ein:

1. Erstellen Sie eine Bereitstellungsdefinition ohne das Feld spec.imagePullSecrets:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: DEPLOYMENT_NAME
   spec:
     replicas: NUMBER_OF_REPLICAS
     template:
       spec:
         containers:
         - name: CONTAINER_NAME
           image: LOCATION-docker.pkg.dev/PROJECT_NAME/REPOSITORY_NAME/IMAGE_NAME:IMAGE_VERSION
   

   Ersetzen Sie Folgendes:

   • DEPLOYMENT_NAME: Der Name Ihrer Bereitstellung.
   • NUMBER_OF_REPLICAS: Gibt an, wie viele Instanzen des im Deployment definierten Pods zu einem bestimmten Zeitpunkt ausgeführt werden sollen.
   • CONTAINER_NAME: der Name des Containers im Pod.
   • LOCATION: die Google Cloud Region, die Ihre Registry enthält. Beispiel: us-west1
   • PROJECT_NAME: der Name des Google-Projekts, in dem sich Ihr Artifact Registry-Repository befindet. Dies ist möglicherweise nicht dasselbe wie das Projekt Ihres Clusters. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie unter Artifact Registry verwenden, wenn sie sich nicht im selben Projekt wie Ihr Cluster befindet zusätzliche Schritte.
   • REPOSITORY_NAME: der Name Ihres Repositorys.
   • IMAGE_NAME: der Name des Images
   • IMAGE_VERSION: die Version des Bildes.

2. Wenden Sie die Konfiguration mithilfe von kubectl auf Ihren Cluster an.

   kubectl apply -f name-of-your-yaml-file.yaml
   

Beispiel für das Erstellen eines Deployments ohne Image-Pull-Secrets

Hier ist ein Beispiel für das Erstellen einer Bereitstellung ohne Secrets zum Abrufen von Images. Bei der Bereitstellung wird ein hello-app-Image aus Artifact Registry abgerufen.

1. Erstellen Sie eine Datei mit dem Namen hello-deployment.yaml und mit folgendem Inhalt:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: hello-app-deployment
   spec:
     selector:
       matchLabels:
         app: products
         department: sales
     replicas: 3
     template:
       metadata:
         labels:
           app: products
           department: sales
       spec:
         containers:
         - name: hello
           image: LOCATION-docker.pkg.dev/PROJECT_NAME/hello-repo/hello-app:v1
           env:
           - name: "PORT"
             value: "50001"
   

   Ersetzen Sie Folgendes:

   • LOCATION: die Google Cloud Region, die Ihre Registry enthält. Beispiel: us-west1
   • PROJECT_NAME: der Name des Google-Projekts, in dem sich Ihr Artifact Registry-Repository befindet. Dies ist möglicherweise nicht dasselbe wie das Projekt Ihres Clusters. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie unter Artifact Registry verwenden, wenn es sich nicht im selben Projekt wie Ihr Cluster befindet zusätzliche Schritte.

2. Wenden Sie die Konfiguration mithilfe von kubectl auf Ihren Cluster an.

   kubectl apply -f hello-deployment.yaml
   

3. Bestätigen Sie mithilfe von kubectl pods, dass Ihre Bereitstellung ausgeführt wird.

   kubectl get pods --selector=app=products
   

   Die Ausgabe zeigt drei Running-Pods.

   NAME                                    READY   STATUS    RESTARTS   AGE
   hello-app-deployment-67d9c6d98c-b69f2   1/1     Running   0          14m
   hello-app-deployment-67d9c6d98c-d6k5c   1/1     Running   0          14m
   hello-app-deployment-67d9c6d98c-p2md5   1/1     Running   0          14m
   

Artifact Registry verwenden, wenn es sich nicht im selben Projekt wie Ihr Cluster befindet

Wenn Sie ein Artifact Registry-Repository verwenden möchten, das sich in einem anderen Google-Projekt als dem mit Ihrem Cluster befindet, führen Sie die folgenden Schritte aus:

Weisen Sie dem Dienstkonto für die VM-Instanzen des Knotenpools Ihres Clusters, dem Dienst-Agent für Maschinen mit Knotenpool, die erforderlichen Berechtigungen für den Zugriff auf diese Registry zu.

gcloud projects add-iam-policy-binding AR_PROJECT_ID \
  --member=NODE_POOL_MACHINE_SERVICE_AGENT \
  --role=ROLE

Mit diesem Schritt wird sichergestellt, dass Ihr Cluster Artefakte aus der Registry in diesem separaten Projekt abrufen kann.

Ersetzen Sie Folgendes:

• AR_PROJECT_ID: die ID des Google-Projekts, in dem die Artifact Registry gehostet wird.
• NODE_POOL_MACHINE_SERVICE_AGENT: Das Dienstkonto für den Knotenpool Ihres Clusters im folgenden Format: [e-mail]
• ROLE: die Rolle roles/artifactregistry.reader oder eine benutzerdefinierte Rolle, die ausreichende Berechtigungen für den Zugriff auf Bilder im Artifact Registry-Repository gewährt.

Private Google Container Registry verwenden

So binden Sie eine private Google Container Registry in Ihren GKE on AWS-Cluster ein, unabhängig vom Speicherort des Google-Projekts:

Erlauben Sie dem Dienstkonto für Maschinen mit dem Knotenpool-Dienst-Agenten, dem Dienstkonto für die VM-Instanzen des Knotenpools Ihres Clusters, den Zugriff auf die Container Registry:

gcloud projects add-iam-policy-binding GCR_PROJECT_ID \
  --member=NODE_POOL_MACHINE_SERVICE_AGENT \
  --role=ROLE

Mit diesem Schritt wird der Zugriff des Clusterdienstkontos auf die privaten Containerimages ermöglicht.

Ersetzen Sie Folgendes:

• GCR_PROJECT_ID: die ID des Projekts, in dem die Container Registry gehostet wird.
• NODE_POOL_MACHINE_SERVICE_AGENT: Das Dienstkonto des Knotenpools im Format [e-mail].
• ROLE: Wählen Sie storage.objectViewer oder eine benutzerdefinierte Rolle mit ausreichendem Container Registry-Zugriff aus. Seien Sie vorsichtig mit dem breiten Zugriff mit storage.objectViewer.

Bereinigen

Führen Sie die folgenden Befehle aus, um die auf dieser Seite erstellten Ressourcen zu entfernen:

kubectl apply -f POD_YAML_FILE
kubectl delete -f DEPLOYMENT_YAML_FILE

Ersetzen Sie Folgendes:

• POD_YAML_FILE: der Name der YAML-Datei, in der Sie den Pod definiert haben.
• DEPLOYMENT_YAML_FILE: der Name der YAML-Datei, in der Sie die Bereitstellung definiert haben.

Nächste Schritte

• Artifact Registry – Übersicht