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:
- 1.30 und höher: GA
- 1.29: Vorschau
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:
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, mussconfig.json
eine base64-codierte Version Ihrer Anmeldedaten im Abschnittauths
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 ausUSERNAME: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 FeldpullCredentialConfigPath
weglassen.Zum Schutz sensibler Daten können Sie mit
chown
undchmod
den Zugriff auf die Konfigurationsdatei einschränken.
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:
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 Annotationbaremetal.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, mussconfig.json
eine base64-codierte Version Ihrer Anmeldedaten im Abschnittauths
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 ausUSERNAME: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 FeldpullCredentialSecretRef
weglassen.Zum Schutz sensibler Daten können Sie mit
chown
undchmod
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
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== ```
Bearbeiten Sie die Konfigurationsdatei des Nutzerclusters, um die private Registry zu aktivieren und zu konfigurieren:
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" ...
Fügen Sie im Abschnitt
nodeConfig
der Konfigurationsdatei für den Nutzercluster den BlockprivateRegistries
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 dencaCertSecretRef
-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 Typkubernetes.io/dockerconfigjson
für die Anmeldedaten der Registry.CREDS_SECRET_NAMESPACE
: der Namespace-Name für das Secret für die Registry-Anmeldedaten.
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