Knoten für die Authentifizierung bei einer privaten Registry konfigurieren

Sie können Ihren Google Distributed Cloud-Cluster so konfigurieren, dass seine Worker-Knoten private Registries verwenden können, einschließlich Artifact Registry. Private Registries auf Knotenebene sind für die Verwendung mit Ihren Arbeitslasten vorgesehen, um Ihnen mehr Kontrolle über Image-Pulls und die damit verbundene Sicherheit zu geben. Wenn Sie einen Cluster mit den privaten Registries wie in diesem Dokument beschrieben konfigurieren, aktualisiert Google Distributed Cloud die containerd-Konfiguration entsprechend. Nachdem Ihr Cluster konfiguriert wurde, können alle Pods auf qualifizierten Knoten die Registries verwenden, ohne imagePullSecrets in der Pod-Spezifikation angeben zu müssen.

Diese Funktion kann jederzeit im Clusterlebenszyklus aktiviert oder deaktiviert werden.

Die folgende Liste zeigt die Startphase für diese Funktion pro Version:

Vorbereitung

1.30 und höher

Damit Sie diese GA-Funktion verwenden können, muss Ihr Cluster die folgenden Anforderungen erfüllen:

  • Die Clusterversion muss 1.30 oder höher sein.
  • Die Knotenpoolversion muss 1.29 oder höher sein. Ein Cluster der Version 1.30 kann Knotenpools der Version 1.28 haben, aber die Funktion funktioniert nur für Knotenpools der Version 1.29 oder höher.

  • Diese Funktion ist für Nutzercluster und selbstverwaltete (Hybrid- und eigenständige) Cluster mit Worker-Knotenpools vorgesehen, wie in der folgenden Tabelle dargestellt:

    Bereitstellungsmodell Unterstützte Clustertypen
    Bereitstellung von Administrator- und Nutzerclustern

    Administratorcluster

    Nutzercluster 1

    Nutzercluster 2
    Bereitstellung von Hybridclustern

    Hybrid-Cluster

    Nutzercluster 1

    Nutzercluster 2
    Bereitstellung des eigenständigen Clusters

    Eigenständiger Cluster

1.29

Damit Sie diese Vorschau-Funktion verwenden können, muss Ihr Cluster die folgenden Anforderungen erfüllen:

  • Die Clusterversion muss 1.29 sein.
  • Die Knotenpoolversion muss 1.29 sein. Nicht alle Knotenpools müssen Version 1.29 haben, aber die Funktion funktioniert nur für Knotenpools der Version 1.29.
  • Der Cluster muss die preview.baremetal.cluster.gke.io/private-registry: "enable" Vorschau Funktionsanmerkung haben.

  • Diese Funktion ist für Nutzercluster und selbstverwaltete (Hybrid- und eigenständige) Cluster mit Worker-Knotenpools vorgesehen, wie in der folgenden Tabelle dargestellt:

    Bereitstellungsmodell Unterstützte Clustertypen
    Bereitstellung von Administrator- und Nutzerclustern

    Administratorcluster

    Nutzercluster 1

    Nutzercluster 2
    Bereitstellung von Hybridclustern

    Hybrid-Cluster

    Nutzercluster 1

    Nutzercluster 2
    Bereitstellung des eigenständigen Clusters

    Eigenständiger Cluster

Selbstverwalteten Cluster für private Registries konfigurieren

So konfigurieren Sie einen eigenständigen oder Hybrid-Cluster für die Verwendung privater Registries auf Knotenebene:

  1. Bearbeiten Sie die Cluster-Konfigurationsdatei, um den Block privateRegistries im Abschnitt „Anmeldedaten“ hinzuzufügen:

    ---
gcrKeyPath: baremetal/gcr.json
sshPrivateKeyPath: .ssh/id_rsa
...
privateRegistries:
  - host: REGISTRY_HOST
    caCertPath: CA_CERT_PATH
    pullCredentialConfigPath: CREDENTIALS_FILE_PATH
...
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-hybrid-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-basic
  namespace: cluster-hybrid-basic
  annotations:
    preview.baremetal.cluster.gke.io/private-registry: "enable" # Version 1.29 clusters only
    ...
spec:
  type: hybrid
  ...

    Ersetzen Sie Folgendes:

    • REGISTRY_HOST: der Domainname oder die IP-Adresse der privaten Registry und der Port. Beispiel: 10.200.0.2:5007

    • CA_CERT_PATH: der Pfad der CA-Zertifikatsdatei (Stamm-CA des Servers). Beispiel: /root/cert.pem. Wenn Ihre private Registry kein privates TLS-Zertifikat erfordert, können Sie dieses Feld weglassen.

    • CREDENTIALS_FILE_PATH: der Pfad der Konfigurationsdatei config.json (z. B. $HOME/.docker/config.json). Damit containerd für den Zugriff auf Ihre private Registry authentifiziert werden kann, muss config.json eine base64-codierte Version Ihrer Anmeldedaten im Abschnitt auths der Datei enthalten.

      Authentifizieren Sie sich für Artifact Registry mit einem JSON-Schlüssel des Dienstkontos mit den folgenden Werten:

      • username: _json_key
      • password: der gesamte Inhalt der JSON-Schlüsseldatei des Dienstkontos. Setzen Sie den eingefügten JSON-Schlüsselinhalt in einfache Anführungszeichen ('), um Parsingfehler zu vermeiden.

      Weitere Informationen zum Generieren dieser Datei finden Sie in der Artifact Registry-Dokumentation unter Authentifizierung für Docker in Artifact Registry konfigurieren.

      Für andere private Registries wird der base64-codierte auth-String in der Regel aus USERNAME:PASSWORD mit Ihren spezifischen Anmeldedaten für die Registry gebildet. Wenn Ihr privater Registry-Server keine Anmeldedaten für die Authentifizierung erfordert, können Sie das Feld pullCredentialConfigPath weglassen.

      Zum Schutz sensibler Daten können Sie mit chown und chmod den Zugriff auf die Konfigurationsdatei einschränken.

  2. Wenden Sie die Änderungen auf Ihren Cluster an:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren möchten.

    • CLUSTER_KUBECONFIG: Pfad der kubeconfig-Datei des selbstverwalteten (Hybrid- oder eigenständigen) Clusters.

Nutzercluster für private Registries konfigurieren

Bei Nutzerclustern wird die Konfiguration der privaten Registry in der Spezifikation der Nutzercluster-Ressource angegeben, die sich im Administratorcluster befindet. Außerdem müssen Sie die Anmeldedaten der privaten Registry in einem Secret speichern, das sich ebenfalls im Administratorcluster befindet:

  1. Erstellen Sie ein Kubernetes-Secret vom Typ kubernetes.io/dockerconfigjson für die Anmeldedaten der Registry:

    Wenn Sie das Secret auf einen bestimmten Namespace beschränken möchten, fügen Sie dem folgenden Befehl das Flag --namespace hinzu, um den Namen des Namespace anzugeben. Wenn sich das Secret nicht im selben Namespace wie der Cluster befindet, fügen Sie die Anmerkung baremetal.cluster.gke.io/mark-source: "true" hinzu, wie im Beispiel am Ende dieses Schritts gezeigt.

    kubectl create secret docker-registry CREDS_SECRET_NAME \
    --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \
    --kubeconfig=ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CREDS_SECRET_NAME: der Name Ihres Secrets.

    • CREDENTIALS_FILE_PATH: der Pfad der Konfigurationsdatei config.json (z. B. $HOME/.docker/config.json). Damit containerd für den Zugriff auf Ihre private Registry authentifiziert werden kann, muss config.json eine base64-codierte Version Ihrer Anmeldedaten im Abschnitt auths der Datei enthalten.

      Authentifizieren Sie sich für Artifact Registry mit einem JSON-Schlüssel des Dienstkontos mit den folgenden Werten:

      • username: _json_key
      • password: der gesamte Inhalt der JSON-Schlüsseldatei des Dienstkontos. Setzen Sie den eingefügten JSON-Schlüsselinhalt in einfache Anführungszeichen ('), um Parsingfehler zu vermeiden.

      Weitere Informationen zum Generieren dieser Datei finden Sie in der Artifact Registry-Dokumentation unter Authentifizierung für Docker in Artifact Registry konfigurieren.

      Für andere private Registries wird der base64-codierte auth-String in der Regel aus USERNAME:PASSWORD mit Ihren spezifischen Anmeldedaten für die Registry gebildet. Wenn Ihr privater Registry-Server keine Anmeldedaten für die Authentifizierung erfordert, können Sie das Feld pullCredentialSecretRef weglassen.

      Zum Schutz sensibler Daten können Sie mit chown und chmod den Zugriff auf die Konfigurationsdatei einschränken.

    Ihr Secret sollte dem folgenden Beispiel ähneln:

    apiVersion: v1
data:
  .dockerconfigjson: ewoJImF1dGhzIjogewoJ...clpYSXdNak14IgoJCX0KCX0KfQ==
kind: Secret
metadata:
  creationTimestamp: "2024-04-28T22:06:06Z"
  name: private-registry-secret
  namespace: default
  resourceVersion: "5055821"
  ...
  annotations:
    ...
    baremetal.cluster.gke.io/mark-source: "true"
type: kubernetes.io/dockerconfigjson

  2. Speichern Sie gegebenenfalls das CA-Zertifikat für die Registry in einem Secret.

    Das Secret sieht dann ungefähr so aus:

    apiVersion: v1
kind: Secret
metadata:
  annotations:
    baremetal.cluster.gke.io/mark-source: "true"
  name: ca-9dd74fd308bac6df562c7a7b220590b5
  namespace: some-namespace
type: Opaque
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2RENDQXFTZ0F3SUJBZ0lVQi
  3UGxjUzVFVk8vS0xuYjZiMHRhRFVleXJvd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2ZqRUxNQWtHQ
  ...
  QnpPTkxTRFZJVk5LMm9YV1JvNEpJY0ZoNFZ4MWRMRHpqMldEaHhrUEljWEhLdGR3dk5iS2tocU
  LUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
  ```

  3. Bearbeiten Sie die Konfigurationsdatei des Nutzerclusters, um die private Registry zu aktivieren und zu konfigurieren:

    1. Fügen Sie nur für Cluster der Version 1.29 die Vorschau-Funktionsanmerkung preview.baremetal.cluster.gke.io/private-registry: "enable" hinzu, um die Funktion zu aktivieren. Für Cluster der Version 1.30 und höher ist die Funktion für die private Registry standardmäßig aktiviert.

      apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
  resourceVersion: "766027"
  annotations:
    ...
    preview.baremetal.cluster.gke.io/private-registry: "enable"
...

    2. Fügen Sie im Abschnitt nodeConfig der Konfigurationsdatei des Nutzerclusters den Block privateRegistries hinzu:

      apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
...
spec:
  bypassPreflightCheck: false
...
  nodeConfig:
    containerRuntime: containerd
    podDensity:
      maxPodsPerNode: 250
    privateRegistries:
    - caCertSecretRef:
        name: CA_CERT_SECRET_NAME
        namespace: CA_CERT_SECRET_NAMESPACE
      host: REGISTRY_HOST
      pullCredentialSecretRef:
        name: CREDS_SECRET_NAME
        namespace: CREDS_SECRET_NAMESPACE

    Ersetzen Sie Folgendes:

    • CA_CERT_SECRET_NAME: der Name des Secrets, das Sie zum Speichern des CA-Zertifikats erstellt haben. Wenn Sie dieses Secret nicht erstellt haben, entfernen Sie den Block caCertSecretRef. Wenn mehrere private Registries auf CA-Zertifikat-Secrets mit demselben Namen in verschiedenen Namespaces verweisen (außer im anthos-creds- oder Cluster-Namespace), fügt das System dem Namen des Ziel-Secrets ein Präfix hinzu, um sicherzustellen, dass die Namen der CA-Zertifikat-Secrets in allen Namespaces eindeutig sind. Das System fügt Secrets im Cluster-Namespace oder im Quell-Namespace in anthos-creds kein Präfix hinzu.

    • CA_CERT_SECRET_NAMESPACE: der Name des Namespace für das CA-Zertifikat-Secret, falls Sie es erstellt haben.

    • REGISTRY_HOST: der Domainname oder die IP-Adresse der privaten Registry und der Port. Beispiel: 10.200.0.2:5007.

    • CREDS_SECRET_NAME: der Name des Secrets vom Typ kubernetes.io/dockerconfigjson für die Anmeldedaten der Registry.

    • CREDS_SECRET_NAMESPACE: der Namespace-Name für das Secret für die Anmeldedaten der Registry.

  4. Wenden Sie die Änderungen auf Ihren Cluster an:

    bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • USER_CLUSTER_NAME: der Name des Clusters, den Sie aktualisieren.

    • ADMIN_KUBECONFIG: Pfad der kubeconfig-Datei des Administratorclusters