Anthos Clusters on Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

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

Dieses Feature kann jederzeit im Clusterlebenszyklus aktiviert oder deaktiviert werden.

Vorbereitung

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

Dieses Feature ist für Nutzercluster und selbstverwaltete (Hybrid- und eigenständige) Cluster mit Worker-Knotenpools vorgesehen.
Die Clusterversion muss 1.29 sein.
Die Knotenpoolversion muss 1.29 sein (nicht alle Knotenpools müssen die Version 1.29 haben, aber das Feature funktioniert nur mit Knotenpools ab Version 1.29).
Der Cluster muss die Annotation preview.baremetal.cluster.gke.io/private-registry: "enable" zur Vorschau des Features haben.

Selbstverwaltete Cluster für private Registrys konfigurieren

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

Bearbeiten Sie die Clusterkonfigurationsdatei und fügen Sie im Abschnitt „Anmeldedaten“ den Block privateRegistries hinzu:
```
---
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"
    ...
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: Pfad der CA-Zertifikatsdatei (Server-Stammzertifizierungsstelle). Beispiel: /root/cert.pem Wenn Ihre private Registry kein privates TLS-Zertifikat erfordert, können Sie dieses Feld auslassen.
- CREDENTIALS_FILE_PATH: der Pfad der Datei, die die Anmeldedaten für den Zugriff auf Ihre private Registry enthält. Beispiel: /root/.docker/config.json. Wenn Ihr privater Registry-Server keine Anmeldedaten für die Authentifizierung benötigt, können Sie dieses Feld auslassen.
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 kubectl-Datei des selbstverwalteten (hybriden oder eigenständigen) Clusters.

Nutzercluster für private Registrys konfigurieren

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

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

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.
```
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 Annotation baremetal.cluster.gke.io/mark-source: "true" hinzu, wie im vorherigen Beispiel gezeigt.

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

Das Secret sieht in etwa 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:
1. Fügen Sie die Annotation preview.baremetal.cluster.gke.io/private-registry: "enable" hinzu, um die private Registry in der Vorabversion zu aktivieren.
```
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 caCertSecretRef-Block.
- CA_CERT_SECRET_NAMESPACE: der Name des Namespace für das CA-Zertifikats-Secret, wenn 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 Registry-Anmeldedaten.
- CREDS_SECRET_NAMESPACE: 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.