Private Image-Registry ohne Secrets verwenden

Mit GKE on AWS können Sie private Images aus Artifact Registry oder Container Registry abrufen, ohne ein Kubernetes-Secret verwenden zu müssen. Bisher mussten Sie die folgenden Schritte ausführen:

1. Erstellen Sie ein Google Identity and Access Management-Dienstkonto (IAM).
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. Verweise in deinem YAML-Manifest für Pods oder Bereitstellungen auf dieses Secret, damit sie auf Images aus dem privaten Container-Repository zugreifen können.
5. Rotieren und verwalten Sie die mit dem Google IAM-Dienstkonto verknüpften Schlüssel regelmäßig.

GKE on AWS macht all diese manuellen Schritte überflüssig und übernimmt automatisch die Authentifizierung und Autorisierung, die zum Abrufen privater Images erforderlich sind.

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 zu Container-Images erstellen und Docker-Image per Push an Artifact Registry übertragen, die Teil der GKE on Google Cloud -Dokumentation 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 Secrets für das Abrufen von Images 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 einen 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, in der sich Ihre Registry befindet. Beispiel: us-west1
   • PROJECT_NAME: der Name des Google-Projekts, in dem Ihr Artifact Registry-Repository gehostet wird. Dieser kann mit dem Projekt Ihres Clusters übereinstimmen. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie unter Artifact Registry verwenden, wenn sich das Repository nicht im selben Projekt wie Ihr Cluster befindet weitere Schritte.
   • REPOSITORY_NAME: der Name Ihres Repositorys.
   • IMAGE_NAME: der Name des Images
   • IMAGE_VERSION: die Version des Bilds.

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 ein Beispiel für das Erstellen eines Kubernetes-Pods ohne Image-Pull-Secrets: Der Pod ruft das hello-app-Image 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 Secrets für den Abruf von Images erstellen

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

1. Bereitstellungsdefinition ohne das Feld spec.imagePullSecrets erstellen:

   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 der 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, in der sich Ihre Registry befindet. Beispiel: us-west1
   • PROJECT_NAME: der Name des Google-Projekts, in dem Ihr Artifact Registry-Repository gehostet wird. Dieser Name muss nicht mit dem Projekt Ihres Clusters übereinstimmen. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie unter Artifact Registry verwenden, wenn sich das Repository nicht im selben Projekt wie Ihr Cluster befindet weitere Schritte.
   • REPOSITORY_NAME: der Name Ihres Repositorys.
   • IMAGE_NAME: der Name des Images
   • IMAGE_VERSION: die Version des Bilds.

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

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

Beispiel für die Erstellung eines Deployments ohne Image-Pull-Secrets

Hier ist ein Beispiel für das Erstellen eines Deployments ohne Secrets für das 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, in der sich Ihre Registry befindet. Beispiel: us-west1
   • PROJECT_NAME: der Name des Google-Projekts, in dem Ihr Artifact Registry-Repository gehostet wird. Dieser Name muss nicht mit dem Projekt Ihres Clusters übereinstimmen. 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 weitere 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 befindet, das Ihren Cluster enthält, gehen Sie so vor:

Weisen Sie dem Dienstkonto für die virtuellen Maschineninstanzen des Knotenpools Ihres Clusters, dem sogenannten Knotenpool-Maschinen-Dienst-Agenten, 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

Dadurch kann Ihr Cluster Artefakte aus der Registry in diesem separaten Projekt abrufen.

Ersetzen Sie Folgendes:

• AR_PROJECT_ID: die ID des Google-Projekts, in dem 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 Images im Artifact Registry-Repository gewährt.

Private Google Container Registry verwenden

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

Gewähren Sie dem Node Pool Machine Service Agent, dem Dienstkonto für die virtuellen Maschineninstanzen des Knotenpools Ihres Clusters, 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 dem Clusterdienstkonto Zugriff auf die privaten Container-Images gewährt.

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 für ausreichenden Zugriff auf die Container Registry aus. Seien Sie bei storage.objectViewer vorsichtig mit dem Zugriff.

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