Private Container Registry konfigurieren

Auf dieser Seite wird erläutert, wie Sie einen vorhandenen Container-Registrierungsserver 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

Standardmäßig ruft Google Distributed Cloud beim Erstellen oder Aktualisieren von Clustern System-Images aus gcr.io/gke-on-prem-release mit dem Dienstkonto für den Komponentenzugriff 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 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 des Administratorclusters den Abschnitt privateRegistry hinzu, bevor Sie den Cluster erstellen.

Wenn dieser Abschnitt ausgefüllt ist:

  • Wenn Sie den Befehl gkectl prepare vor dem Erstellen oder Aktualisieren des Clusters ausführen, werden die Images aus der TAR-Datei extrahiert, die im Feld bundlePath in der Konfigurationsdatei des Administratorclusters angegeben ist. Anschließend werden die Images per Push auf Ihren privaten Registrierungsserver übertragen.

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

Terraform

  1. Folgen Sie der Anleitung auf dem Tab „Terraform“ unter Administratorcluster erstellen, um die Konfigurationsdatei des Administratorclusters auszufüllen.

  2. 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 (Fully Qualified Domain Name) der Maschine, auf der Ihre private Registry ausgeführt wird.

    • "CA_CERT": Der öffentliche Schlüssel des CA-Zertifikats für die private Registry.

  3. Fahren Sie mit den Schritten auf dem Tab „Terraform“ unter Administratorcluster erstellen fort, um die Terraform-Konfigurationsdatei und den Plan zu prüfen und dann den Bootstrap-Cluster zu erstellen.

  4. 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 gibt zwei Google Distributed Cloud-Pakete: „Full“ und „Regular“. Um herauszufinden, welches Bundle sich auf Ihrer Administrator-Workstation befindet, sehen Sie im Feld bundlePath Ihrer Konfigurationsdatei für den Administratorcluster nach. Wenn der Dateiname mit -full endet, befindet sich das vollständige Bundle auf Ihrer Administrator-Workstation. Wenn der Dateiname nicht mit -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 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 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 für den Administratorcluster.
  • Version 1.32: Die Verwendung des vollständigen Bundles wird unterstützt, aber mit dem Befehl gkectl prepare werden Bilder aus gcr.io/gke-on-prem-release anstelle der TAR-Datei abgerufen. Mit dem Befehl werden die Images jedoch in Ihre private Registry übertragen, sodass die System-Images beim Erstellen oder Aktualisieren des Clusters aus Ihrer privaten Registry abgerufen werden.

Abrufen von Images von Ihrem 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 Bilder in Ihrem Cluster an. Sie können prüfen, ob alle Google Distributed Cloud-Images von Ihrem eigenen Registrierungsserver 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.

      Im Folgenden finden Sie einen 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.