Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Private Container Registry konfigurieren

Auf dieser Seite wird erläutert, wie Sie einen vorhandenen Container Registry-Server für Google Distributed Cloud (nur Software) für VMware konfigurieren.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die technische Infrastrukturen einrichten, überwachen und verwalten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Übersicht

Standardmäßig ruft Google Distributed Cloud beim Erstellen oder Aktualisieren eines Clusters System-Images aus gcr.io/gke-on-prem-release mit dem Dienstkonto für den Komponentenzugriff ab. Optional können Sie einen eigenen Container-Registry-Server bereitstellen, damit System-Images stattdessen von Ihrem privaten Registry-Server abgerufen werden.

Google Distributed Cloud unterstützt keine unsicheren Container-Registries. Wenn Sie Ihren Container Registry-Server starten, müssen Sie ein Zertifikat und einen Schlüssel angeben. Das Zertifikat kann von einer öffentlichen Zertifizierungsstelle signiert werden oder es kann selbst signiert sein.

Container-Registry-Server erstellen

Informationen zum Erstellen eines Container-Registry-Servers finden Sie in der Docker-Dokumentation unter Extern zugängliche Registry ausführen.

Registry konfigurieren

Wenn Sie eine private Container-Registry verwenden möchten, können Sie entweder das gkectl-Befehlszeilentool oder Terraform verwenden.

`gkectl`

Fügen Sie der Konfigurationsdatei für den Administratorcluster den Abschnitt privateRegistry hinzu, bevor Sie den Cluster erstellen.

Wenn dieser Abschnitt ausgefüllt ist:
- Wenn Sie den Befehl gkectl prepare vor der Clustererstellung oder dem Upgrade ausführen, extrahiert der Befehl die Images aus der TAR-Datei, die im Feld bundlePath in der Konfigurationsdatei des Administratorclusters angegeben ist, und überträgt die Images auf Ihren privaten Registry-Server.
- Beim Erstellen oder Aktualisieren des Clusters werden die System-Images von Ihrem privaten Registry-Server abgerufen.
Wenn sich Ihr Netzwerk hinter einem Proxyserver befindet, füllen Sie den Abschnitt proxy aus.

Terraform

Führen Sie die Schritte auf dem Terraform-Tab unter Administratorcluster erstellen aus, um die Konfigurationsdatei für den Administratorcluster auszufüllen.

Fügen Sie der Konfigurationsdatei für den Administratorcluster Folgendes hinzu:
```
private_registry_config {
  address = "ADDRESS"
  ca_cert = "CA_CERT"
}
```
Ersetzen Sie Folgendes:
- ADDRESS: Die IP-Adresse oder der FQDN (voll qualifizierter Domainname) der Maschine, auf dem Ihre private Registry ausgeführt wird.
- CA_CERT: die CA-Zertifikatsdaten des öffentlichen Schlüssels, wobei jedoch alle Zeilenumbrüche durch den String \n ersetzt wurden.
1. Führen Sie den folgenden Befehl aus, um Zeilenumbrüche durch \n zu ersetzen:
```
awk 'ORS="\\n" {print}' PUBLIC_KEY_PATH
```
  Ersetzen Sie PUBLIC_KEY_PATH durch den Pfad zum öffentlichen Schlüssel.
2. Kopieren Sie die Ausgabe des vorherigen Befehls und fügen Sie sie in die Platzhaltervariable CA_CERT ein.
Wenn sich Ihr Netzwerk hinter einem Proxyserver befindet, fügen Sie Folgendes hinzu:
```
proxy {
  url: "PROXY_SERVER_ADDRESS"
  no_proxy: "BYPASS_LIST"
}
```
Ersetzen Sie Folgendes:
- PROXY_SERVER_ADDRESS: die HTTP-Adresse Ihres Proxyservers. Geben Sie die Portnummer an, auch wenn sie mit dem Standardport des Schemas identisch ist.
- BYPASS_LIST: Eine durch Kommas getrennte Liste mit IP-Adressen, IP-Adressbereichen, Hostnamen und Domainnamen, die nicht durch den Proxyserver geleitet werden sollen.
Beispiel:
```
url: "http://my-proxy.example.local:80"
no_proxy: "192.0.2.0/24,my-host.example.local,198.51.100.0"
```
Wenn Google Distributed Cloud eine Anfrage an eine dieser Adressen, Hosts oder Domains sendet, umgeht die Anfrage den Proxyserver und wird direkt an das Ziel gesendet.

Fahren Sie mit den Schritten auf dem Terraform-Tab unter Administratorcluster erstellen fort, um die Terraform-Konfigurationsdatei und den Plan zu prüfen und dann den Bootstrap-Cluster zu erstellen.
Wenn Sie den Befehl gkectl register bootstrap ausführen, werden Sie von gkectl aufgefordert, den Nutzernamen und dann das Passwort für die private Registry einzugeben.

Während der Clustererstellung werden die System-Images von Ihrem privaten Registry-Server abgerufen.

Einschränkungen bei erweiterten Clustern und dem vollständigen Bundle

Es sind zwei Google Distributed Cloud-Bundles verfügbar: „full“ und „regular“. Prüfen Sie das Feld bundlePath in der Konfigurationsdatei des Administratorclusters, um festzustellen, welches Bundle sich auf Ihrer Administrator-Workstation befindet. Wenn der Dateiname auf -full endet, befindet sich das vollständige Bundle auf Ihrer Administrator-Workstation. Wenn der Dateiname nicht auf -full endet, befindet sich das reguläre Bundle auf Ihrer Administrator-Workstation.

Wenn Sie Ihre Administrator-Workstation mit dem Befehl gkeadm erstellt haben, wird die Administrator-Workstation-VM mit dem vollständigen Bundle erstellt und das Feld bundlePath in der Konfigurationsdatei des Administratorclusters konfiguriert.

Wenn Erweiterter Cluster aktiviert ist, gelten für die Verwendung des vollständigen Bundles mit einer privaten Registry die folgenden Einschränkungen:

Version 1.31: Das vollständige Bundle wird mit einer privaten Registry nicht unterstützt. So verwenden Sie eine private Registry in einem erweiterten Cluster:
1. Laden Sie das Bundle in normaler Größe auf Ihre Administrator-Workstation herunter.
2. Aktualisieren Sie den Dateinamen im Feld bundlePath in der Konfigurationsdatei des Administratorclusters.
Version 1.32: Die Verwendung des vollständigen Bundles wird unterstützt, aber der Befehl gkectl prepare ruft Images aus gcr.io/gke-on-prem-release anstelle der TAR-Datei ab. Der Befehl überträgt die Images jedoch in Ihre private Registry, sodass die System-Images während der Clustererstellung oder des Upgrades aus Ihrer privaten Registry abgerufen werden.

Unterschiede zwischen normalen und erweiterten Clustern

Erweiterte Cluster weisen im Vergleich zu Standardclustern mehrere wichtige Unterschiede auf:

Wenn Sie eine private Registry verwenden, werden Images scheinbar von gcr.io und nicht vom Hostnamen Ihrer privaten Registry abgerufen. Diese Änderung ist zu erwarten, auch wenn Images tatsächlich von Ihrem privaten Registry-Server abgerufen werden.
Für Image-Abrufe werden Anmeldedaten aus der Datei /etc/containerd/config.toml auf jedem Computer verwendet, der eine Verbindung zur privaten Registry herstellt, anstatt aus dem Secret private-registry-creds im Cluster.
Bei allen gcr.io-Images versucht der Cluster zuerst, das Image aus der privaten Registry abzurufen. Wenn sich das Image nicht in der privaten Registry befindet, wird es über das Internet von gcr.io abgerufen. Wenn Sie diesen Fallback verhindern möchten, richten Sie noProxy ein oder verwenden Sie Firewallregeln, um gcr.io-Traffic zu blockieren.

Informationen dazu, wie Sie prüfen, ob Images aus der richtigen Quelle abgerufen werden, finden Sie unter Prüfen, ob Images von Ihrem Registry-Server abgerufen werden.

Abrufen von Images aus dem Registry-Server prüfen

Wie Sie prüfen, ob Images von Ihrem Registry-Server abgerufen werden, hängt davon ab, ob der erweiterte Cluster aktiviert ist.

Wenn der erweiterte Cluster nicht aktiviert ist, führen Sie den folgenden Befehl aus:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --all-namespaces -o jsonpath="{.items[*].spec['initContainers', 'containers'][*].image}"
```
Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei für Ihren Administratorcluster.

Die Ausgabe dieses Befehls zeigt alle Images in Ihrem Cluster an. Sie können prüfen, ob alle Google Distributed Cloud-Images von Ihrem eigenen Registry-Server stammen.
Wenn der erweiterte Cluster aktiviert ist, führen Sie die folgenden Schritte aus:

Sie können feststellen, ob containerd Images aus Ihrer lokalen Registry abruft. Prüfen Sie dazu den Inhalt einer Datei mit dem Namen config.toml:
1. Melden Sie sich bei einem Knoten an und prüfen Sie den Inhalt der Datei /etc/containerd/config.toml.
2. Überprüfen Sie im Feld plugins."io.containerd.grpc.v1.cri".registry.mirrors der Datei config.toml, ob Ihr Registry-Server im Feld endpoint aufgeführt ist.
  
  Das folgende Beispiel ist ein Auszug aus einer config.toml-Beispieldatei.
```
version = 2
root = "/var/lib/containerd"
state = "/run/containerd"
...
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.configs]
[plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io"]
[plugins."io.containerd.grpc.v1.cri".registry.configs."privateregistry2.io".tls]
ca_file = '/etc/containerd/certs.d/privateregistry2.io/ca.crt'
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
endpoint = ["http://privateregistry.io", "http://privateregistry2.io"]
...
```
3. Wenn Ihre Registry-Spiegelung im Feld endpoint angezeigt wird, ruft der Knoten Images aus Ihrer Registry-Spiegelung und nicht aus Artifact Registry ab.

Private Container Registry konfigurieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.