Diese Dokumentation bezieht sich auf die aktuelle Version von GKE on AWS, die im November 2021 veröffentlicht wurde. Weitere Informationen finden Sie in den Versionshinweisen.

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. Zuvor mussten Sie folgende Schritte ausführen:

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

GKE on AWS entfällt alle diese manuellen Schritte 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 können Sie private Images aus Artifact Registry oder Container Registry abrufen, 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:

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.
Prüfen Sie mit dem Befehl docker images, ob Artifact Registry ein Image 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. Folgen Sie dazu der Anleitung unter Container-Anwendung bereitstellen.

Pods mit privaten Images ohne Image-Pull-Secrets erstellen

Zum Erstellen eines Pods, der aus einer Registry auf ein privates Container-Image zugreifen kann, müssen Sie das Feld spec.imagePullSecrets in Ihrer Pod-Spezifikation nicht mehr angeben. So richten Sie Ihren Pod ein:

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, das Ihr Artifact Registry-Repository hostet. Dieser kann mit dem Projekt Ihres Clusters identisch sein. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie weitere Schritte unter Artifact Registry verwenden, wenn es sich nicht im selben Projekt wie Ihr Cluster befindet.
- REPOSITORY_NAME: der Name Ihres Repositorys.
- IMAGE_NAME: der Name des Images
- IMAGE_VERSION ist die Version des Images.
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

Im Folgenden finden Sie ein Beispiel für das Erstellen eines Kubernetes-Pods ohne Image-Abruf-Secrets. Der Pod ruft das Image hello-app aus Artifact Registry ab.

Kopieren Sie die folgende YAML-Datei in eine Datei mit dem Namen hello-pod.yaml, um das Image hello-app abzurufen:

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

Wenden Sie die Konfiguration mit kubectl auf Ihren Cluster an:
```
kubectl apply -f hello-pod.yaml
```

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

Deployments mit privaten Images ohne Image-Abruf-Secrets erstellen

Zum Erstellen eines Deployments, das über eine Registry auf ein privates Container-Image zugreifen kann, muss das Feld spec.imagePullSecrets in der Deployment-Spezifikation nicht mehr angegeben werden. Führen Sie zum Einrichten des Deployments die folgenden Schritte aus:

Erstellen Sie eine Deployment-Definition 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 Ihres Deployments.
- NUMBER_OF_REPLICAS: die Anzahl der im Deployment definierten Instanzen des Pods, die 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, das Ihr Artifact Registry-Repository hostet. Dieser ist möglicherweise nicht mit dem Projekt Ihres Clusters identisch. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie weitere Schritte unter Artifact Registry verwenden, wenn es sich nicht im selben Projekt wie Ihr Cluster befindet.
- REPOSITORY_NAME: der Name Ihres Repositorys.
- IMAGE_NAME: der Name des Images
- IMAGE_VERSION ist die Version des Images.
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 eines Deployments ohne Image-Pull-Secrets. Das Deployment ruft ein hello-app-Image aus Artifact Registry ab.

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, das Ihr Artifact Registry-Repository hostet. Dieser ist möglicherweise nicht mit dem Projekt Ihres Clusters identisch. Wenn sich das Repository in einem anderen Projekt befindet, finden Sie weitere Schritte unter Artifact Registry verwenden, wenn es sich nicht im selben Projekt wie Ihr Cluster befindet.
Wenden Sie die Konfiguration mithilfe von kubectl auf Ihren Cluster an.
```
kubectl apply -f hello-deployment.yaml
```

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

kubectl get pods --selector=app=products

In der Ausgabe werden drei Running-Pods angezeigt.

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

Führen Sie die folgenden Schritte aus, um ein Artifact Registry-Repository zu verwenden, das sich in einem anderen Google-Projekt als dem Projekt befindet, das Ihren Cluster enthält:

Geben Sie dem Dienstkonto für die VM-Instanzen des Knotenpools Ihres Clusters, bekannt als Knotenpool-Maschinendienst-Agent, die erforderlichen Berechtigungen für den Zugriff auf diese Registry.

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

Dadurch 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, das Artifact Registry hostet.
NODE_POOL_MACHINE_SERVICE_AGENT: das Dienstkonto für den Knotenpool Ihres Clusters im folgenden Format: service-CLUSTER_RESOURCE_PROJECT_NUMBER@gcp-sa-gkemulticloudnpmachine.iam.gserviceaccount.com
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 binden Sie eine private Google Container Registry in Ihren GKE on AWS-Cluster ein, unabhängig vom Speicherort des Google-Projekts:

Gewähren Sie dem Dienst-Agent für Knotenpoolmaschinen, dem Dienstkonto für die VM-Instanzen des Knotenpools Ihres Clusters, Zugriff auf 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 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 Knotenpool-Dienstkonto im Format service-CLUSTER_RESOURCE_PROJECT_NUMBER@gcp-sa-gkemulticloudnpmachine.iam.gserviceaccount.com.
ROLE: Wählen Sie storage.objectViewer oder eine benutzerdefinierte Rolle für einen ausreichenden Zugriff auf Container Registry aus. Seien Sie vorsichtig bei einem umfassenden 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 das Deployment definiert haben.

Nächste Schritte

Artifact Registry – Übersicht