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 Enterprise-Nutzerrollen und -Aufgaben.

Übersicht

Beim Erstellen oder Aktualisieren eines Clusters ruft Google Distributed Cloud standardmäßig Systemabbilder über das Dienstkonto für den Komponentenzugriff von gcr.io/gke-on-prem-release ab. Optional können Sie Ihren eigenen Container Registry-Server angeben, damit System-Images stattdessen von Ihrem privaten Registry-Server abgerufen werden.

Google Distributed Cloud unterstützt keine ungesicherten Containerregistries. Wenn Sie den Containerregistrierungsserver 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 Containerregistrierung verwenden möchten, füllen Sie den Abschnitt privateRegistry in der Konfigurationsdatei des Administratorclusters aus, bevor Sie den Cluster erstellen. Wenn dieser Abschnitt ausgefüllt ist:

  • Wenn Sie den Befehl gkectl prepare vor dem Erstellen oder Aktualisieren eines Clusters ausführen, werden die Images aus der Tar-Datei extrahiert, die im Feld bundlePath in der Konfigurationsdatei des Administratorclusters angegeben ist, und auf Ihren privaten Registry-Server gesendet.

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

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

Es gibt zwei Google Distributed Cloud-Pakete: Vollständig und Standard. Welches Bundle sich auf Ihrer Administrator-Workstation befindet, sehen Sie im Feld bundlePath in der Konfigurationsdatei des Administratorclusters. 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 damit die VM der Administrator-Workstation 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 folgende Einschränkungen:

  • Version 1.31: Das vollständige Bundle wird nicht mit einer privaten Registry unterstützt. So verwenden Sie eine private Registry in einem erweiterten Cluster:

    1. Laden Sie das Bundle in der Standardgröß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 von gcr.io/gke-on-prem-release statt aus der Tar-Datei ab. Der Befehl überträgt die Images jedoch in Ihre private Registry, damit die System-Images beim Erstellen oder Upgraden des Clusters aus Ihrer privaten Registry abgerufen werden.

Prüfen, ob Images von Ihrem Registry-Server abgerufen werden

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.

    In der Ausgabe dieses Befehls werden alle Images in Ihrem Cluster angezeigt. Sie können prüfen, ob alle Google Distributed Cloud-Images von Ihrem eigenen Registry-Server stammen.

  • Wenn der erweiterte Cluster aktiviert ist, gehen Sie so vor:

    Sie können feststellen, ob containerd Images aus Ihrer lokalen Registry abruft. Prüfen Sie dazu den Inhalt einer Datei 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 pluginsio.containerd.grpc.v1.cri".registry.mirrors der Datei config.toml, ob Ihr Registry-Server im Feld endpoint aufgeführt ist.

      Im Folgenden finden Sie einen Auszug aus einer Beispiel-config.toml-Datei.

      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.