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, einschließlich Artifact Registry, verwenden können. Private Registries auf Knotenebene sind für die Verwendung mit Ihren Arbeitslasten vorgesehen, damit Sie mehr Kontrolle über das Abrufen von Images und die zugehörige Sicherheit haben. Wenn Sie einen Cluster mit den privaten Registries konfigurieren, wie in diesem Dokument beschrieben, aktualisiert Google Distributed Cloud die containerd-Konfiguration entsprechend. Sobald Ihr Cluster konfiguriert ist, können alle Pods auf qualifizierten Knoten die Registries verwenden, ohne dass imagePullSecrets in der Pod-Spezifikation angegeben werden muss.

Diese Funktion kann jederzeit während des Clusterlebenszyklus aktiviert oder deaktiviert werden.

In der folgenden Liste sehen Sie die Einführungsphase für diese Funktion nach 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 mindestens 1.30 sein.
  • Die Knotenpoolversion muss mindestens 1.29 sein. Ein 1.30-Cluster kann Knotenpools mit Version 1.28 haben, aber die Funktion funktioniert nur für Knotenpools mit Version 1.29 oder höher.

  • Dieses Feature ist für Nutzercluster und selbstverwaltete (Hybrid- und eigenständige) Cluster mit Worker-Knotenpools verfügbar, 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 dieses Vorschaufeature 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 mit Version 1.29.
  • Der Cluster muss die Anmerkung für die preview.baremetal.cluster.gke.io/private-registry: "enable"-Vorschaufunktion haben.

  • Dieses Feature ist für Nutzercluster und selbstverwaltete (Hybrid- und eigenständige) Cluster mit Worker-Knotenpools verfügbar, 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 Hybridcluster für die Verwendung privater Registries auf Knotenebene:

  1. Bearbeiten Sie die Clusterkonfigurationsdatei, um den privateRegistries-Block im Abschnitt „credentials“ 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 (Server-Stamm-CA). Beispiel: /root/cert.pem Wenn für Ihre private Registry kein privates TLS-Zertifikat erforderlich ist, können Sie dieses Feld weglassen.

    • CREDENTIALS_FILE_PATH: Der Pfad der Konfigurationsdatei, config.json (z. B. $HOME/.docker/config.json). Damit containerd auf Ihre private Registry zugreifen 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 für ein Dienstkonto 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 Parsing-Fehler zu vermeiden.

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

      Bei anderen privaten Registries wird der base64-codierte String auth in der Regel aus USERNAME:PASSWORD mit den Anmeldedaten Ihrer spezifischen Registry gebildet. Wenn für Ihren privaten Registry-Server keine Anmeldedaten für die Authentifizierung erforderlich sind, 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 Ressourcenspezifikation des Nutzerclusters 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 Registry-Anmeldedaten:

    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 Annotation 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 auf Ihre private Registry zugreifen 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 für ein Dienstkonto 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 Parsing-Fehler zu vermeiden.

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

      Bei anderen privaten Registries wird der base64-codierte String auth in der Regel aus USERNAME:PASSWORD mit den Anmeldedaten Ihrer spezifischen Registry gebildet. Wenn für Ihren privaten Registry-Server keine Anmeldedaten für die Authentifizierung erforderlich sind, 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 in etwa so aussehen:

    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 das CA-Zertifikat für die Registry gegebenenfalls 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 Anmerkung für die Vorabversion preview.baremetal.cluster.gke.io/private-registry: "enable" hinzu, um die Funktion zu aktivieren. Für Cluster mit Version 1.30 und höher ist die Funktion für private Registries 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 für den Nutzercluster 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 caCertSecretRef-Block.

    • 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 Registry-Anmeldedaten.

  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