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. Private Registrierungen auf Knotenebene sind für die Verwendung mit Ihren Arbeitslasten vorgesehen. So haben Sie mehr Kontrolle über das Abrufen von Images und die damit verbundene Sicherheit. Wenn Sie einen Cluster wie in diesem Dokument beschrieben mit den privaten Registries konfigurieren, aktualisiert Google Distributed Cloud die containerd-Konfiguration entsprechend. Sobald Ihr Cluster konfiguriert ist, können alle Pods auf qualifizierten Knoten die Registrierungen verwenden, ohne imagePullSecrets in der Pod-Spezifikation angeben zu müssen.

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

In der folgenden Liste ist die Einführungsphase dieser Funktion nach Version aufgeführt:

• 1.30: GA
• 1.29: Vorschau
• 1.28: Nicht verfügbar

Vorbereitung

Selbstverwalteten Cluster für private Registrierungen konfigurieren

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

1. Bearbeiten Sie die Clusterkonfigurationsdatei, 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: Domainname oder IP-Adresse der privaten Registry und der Port. Beispiel: 10.200.0.2:5007

   • CA_CERT_PATH: 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 auslassen.

   • CREDENTIALS_FILE_PATH: Der Pfad zur Datei mit den Anmeldedaten für den Zugriff auf Ihre private Registry. Beispiel: /root/.docker/config.json. Wenn für Ihren privaten Registry-Server keine Anmeldedaten für die Authentifizierung erforderlich sind, können Sie dieses Feld weglassen.

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 Registrierungsstellen konfigurieren

Bei Nutzerclustern wird die Konfiguration der privaten Registry in der Clusterressourcenbeschreibung angegeben. Außerdem müssen Sie die Anmeldedaten der privaten Registry für Nutzercluster in einem Secret speichern:

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 Namespaces anzugeben.

   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 Docker-Konfigurationsdatei. Beispiel: /root/.docker/config.json.

   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
   

   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 vorherigen Beispiel gezeigt.

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 Anmerkung Vorabversion preview.baremetal.cluster.gke.io/private-registry: "enable" hinzu, um die Funktion zu aktivieren. Bei Clustern 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 in der Konfigurationsdatei des Nutzerclusters im Abschnitt nodeConfig 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: Domainname oder IP-Adresse der privaten Registry und der Port. Beispiel: 10.200.0.2:5007

   • CREDS_SECRET_NAME: Der Name des kubernetes.io/dockerconfigjson-Typs „Secret“ für die Anmeldedaten der Registry.

   • CREDS_SECRET_NAMESPACE: der Namespacename 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