Registry-Spiegel für Container-Images verwenden

Auf dieser Seite wird erläutert, wie Sie Cluster mit Images erstellen und aktualisieren, die aus einer Registry-Spiegelung anstelle einer öffentlichen Registry wie gcr.io abgerufen wurden. Diese Funktion kann jederzeit während des Clusterlebenszyklus aktiviert oder deaktiviert werden.

Diese Seite richtet sich an Bediener und Speicherspezialisten, die Speicherleistung, ‑nutzung und ‑kosten konfigurieren 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.

Eine Registry-Spiegelung ist eine lokale Kopie einer öffentlichen Registry, die die Dateistruktur der öffentlichen Registry kopiert oder spiegelt. Angenommen, der Pfad zu Ihrer lokalen Registry-Spiegelung lautet 172.18.0.20:5000. Wenn containerd auf eine Anfrage zum Abrufen eines Images wie gcr.io/kubernetes-e2e-test-images/nautilus:1.0 stößt, versucht containerd, dieses Image nicht von gcr.io, sondern aus Ihrer lokalen Registry unter dem folgenden Pfad abzurufen: 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Wenn sich das Image nicht in diesem lokalen Registry-Pfad befindet, wird das Image automatisch aus der öffentlichen Registry gcr.io abgerufen.

Die Verwendung einer Registry-Spiegelung bietet die folgenden Vorteile:

  • Schützt vor Ausfällen der öffentlichen Registry.
  • Beschleunigt die Pod-Erstellung.
  • Sie können Ihre eigenen Scans auf Sicherheitslücken durchführen.
  • Vermeidet Limits, die durch öffentliche Registries festgelegt werden, wie häufig Sie Befehle ausführen können.

Hinweise

  • In Ihrem Netzwerk muss ein Artifact Registry-Server eingerichtet sein.
  • Wenn Ihr Registry-Server ein privates TLS-Zertifikat ausführt, benötigen Sie die Datei der Zertifizierungsstelle (Certificate Authority, CA).
  • Wenn Ihr Registry-Server eine Authentifizierung benötigt, benötigen Sie die entsprechenden Anmeldedaten oder eine Docker-Konfigurationsdatei.
  • Wenn Sie eine Red Hat Quay-Registry verwenden, müssen Sie die Verzeichnisstruktur der lokalen Registry möglicherweise manuell erstellen.
  • Wenn Sie eine Registry-Spiegelung verwenden möchten, müssen Sie die Containerlaufzeit auf containerd festlegen.
  • Achten Sie darauf, dass auf Ihrer Administrator-Workstation genügend Speicherplatz für das Hochladen von Bildern vorhanden ist. Mit dem Befehl zum Hochladen von Bildern, bmctl push images, wird die heruntergeladene Paketdatei mit Bildern dekomprimiert und dann werden alle Bilddateien lokal extrahiert, bevor sie hochgeladen werden. Sie sollten mindestens dreimal so viel Speicherplatz auf der Festplatte haben wie die Größe der heruntergeladenen Bildpaketdatei, um die Bilder hochladen zu können. Die komprimierte Datei bmpackages_1.31.200-gke.59.tar.xz belegt beispielsweise etwa 8,5 GB Speicherplatz. Sie sollten also mindestens 25,5 GB Speicherplatz frei haben, bevor Sie die Datei herunterladen.

Alle erforderlichen Images für Google Distributed Cloud herunterladen

Laden Sie die neueste Version des bmctl-Tools und des Image-Pakets von der Downloadseite herunter.

Container-Images auf den Registry-Server hochladen

Wenn Sie bmctl push images verwenden, um Container-Images auf Ihren Repository-Server hochzuladen, führt bmctl die folgenden Schritte in der angegebenen Reihenfolge aus:

  1. Dekomprimieren Sie ein heruntergeladenes Bilderpaket, das als TAR-Datei komprimiert wurde, z. B. bmpackages_1.32.200-gke.104.tar.xz, in bmpackages_1.32.200-gke.104.tar.

  2. Extrahieren Sie alle Bilder aus der dekomprimierten TAR-Datei in ein Verzeichnis mit dem Namen bmpackages_1.32.200-gke.104.

  3. Übertragen Sie jede Bilddatei in die angegebene private Registry.

    bmctl verwendet die Werte --username und --password für die grundlegende Authentifizierung, um die Bilder in Ihre private Registry zu übertragen.

In den folgenden Abschnitten werden einige gängige Varianten des bmctl push images-Befehls zum Hochladen von Bildern auf Ihren Repository-Server veranschaulicht.

Authentifizieren Sie sich bei Ihrer Registry und geben Sie das TLS-Zertifikat weiter.

Der folgende Befehl enthält die Flags --username und --password für die Nutzerauthentifizierung bei Ihrem Registrierungsserver. Der Befehl enthält auch das Flag --cacert zum Übergeben des TLS-Zertifikats der Zertifizierungsstelle, das für die sichere Kommunikation mit dem Registrierungsserver verwendet wird, einschließlich des Push- und Pull-Vorgangs von Images. Diese Flags bieten grundlegende Sicherheit für Ihren Registry-Server.

Wenn für Ihren Registry-Server eine Authentifizierung erforderlich ist und Sie die Flags --username und --password nicht verwenden, werden Sie beim Ausführen von bmctl push images zur Eingabe von Anmeldedaten aufgefordert. Sie können entweder Ihr Passwort eingeben oder die Docker-Konfigurationsdatei auswählen, die die Anmeldedaten enthält.

Wenn Sie Bilder mit Authentifizierung und einem privaten CA-Zertifikat hochladen möchten, verwenden Sie einen Befehl wie den folgenden:

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --username USERNAME \
    --password PASSWORD \
    --cacert CERT_PATH

Ersetzen Sie Folgendes:

  • IMAGES_TAR_FILE_PATH: der Pfad zur TAR-Datei des heruntergeladenen Bildpakets, z. B. bmpackages_1.32.200-gke.104.tar.xz.

  • REGISTRY_IP:PORT: die IP-Adresse und der Port des privaten Registrierungsservers.

  • USERNAME: Der Nutzername eines Nutzers mit Zugriffsberechtigungen zum Hochladen von Bildern auf den Registrierungsserver.

  • PASSWORD: das Passwort des Nutzers für die Authentifizierung beim Registrierungsserver.

  • CERT_PATH: Der Pfad zur CA-Zertifikatsdatei, wenn Ihr Registry-Server ein privates TLS-Zertifikat verwendet.

Beispiel:

bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --username alex --password pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

Bilder ohne Nutzerauthentifizierung oder Zertifikate hochladen

Wenn für Ihren Registry-Server keine Anmeldedaten wie Nutzername und Passwort erforderlich sind, geben Sie im bmctl-Befehl --need-credential=false an. Wenn Ihr Registry-Server ein öffentliches TLS-Zertifikat verwendet, müssen Sie das Flag --cacert nicht verwenden. Diese Art von Upload-Befehl eignet sich am besten für Testumgebungen, in denen die Sicherheit weniger wichtig ist als in der Produktion.

Wenn Sie Bilder ohne Authentifizierung oder ein privates CA-Zertifikat hochladen möchten, verwenden Sie einen Befehl wie den folgenden:

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --need-credential=false

Beispiel:

bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --need-credential=false.

Anzahl der Threads anpassen

Das Hochladen von Bildern kann aufgrund der Größe und Anzahl der Container-Images in der Tar-Datei des Bildpakets zeitaufwendig sein. Wenn Sie die Anzahl der parallelen Threads erhöhen, wird die Routine schneller ausgeführt. Mit dem Flag --threads können Sie die Anzahl der parallelen Threads ändern, die von bmctl push images verwendet werden.

Standardmäßig werden beim Hochladen von Bildern vier Threads verwendet. Wenn das Hochladen von Bildern zu lange dauert, erhöhen Sie diesen Wert. In einer Google-Testumgebung dauert das Hochladen von Bildern von einer Workstation mit 4 CPUs mit 8 parallelen Threads etwa 10 Minuten.

bmctl push images \
    --source IMAGES_TAR_FILE_PATH \
    --private-registry REGISTRY_IP:PORT \
    --cacert CERT_PATH \
    --threads NUM_THREADS

Ersetzen Sie NUM_THREADS durch die Anzahl der parallelen Threads, die zum Verarbeiten der Bild-Uploads verwendet werden. Standardmäßig verwendet bmctl push images vier parallele Threads.

Mit dem folgenden Befehl wird die Anzahl der Threads für den Upload von 4 auf 8 erhöht, um die Uploadzeit zu verkürzen:

bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem \
    --threads 8

Über Proxy hochladen

Wenn Sie einen Proxy zum Hochladen der Bilder von Ihrer Workstation auf den Registry-Server benötigen, können Sie die Proxy-Details vor dem bmctl-Befehl hinzufügen:

HTTPS_PROXY=http://PROXY_IP:PORT bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT \
    --cacert=CERT_PATH

Ersetzen Sie Folgendes:

  • PROXY_IP:PORT: Die IP-Adresse und der Port des Proxys.

  • IMAGES_TAR_FILE_PATH: der Pfad zur TAR-Datei des heruntergeladenen Bildpakets, z. B. bmpackages_1.32.200-gke.104.tar.xz.

  • REGISTRY_IP:PORT: die IP-Adresse und der Port des privaten Registrierungsservers.

  • CERT_PATH: Der Pfad zur CA-Zertifikatsdatei, wenn Ihr Registry-Server ein privates TLS-Zertifikat verwendet.

Geben Sie Ihren Nutzernamen und Ihr Passwort ein, wenn Sie dazu aufgefordert werden, oder wählen Sie eine Docker-Konfigurationsdatei aus.

Mit dem folgenden Befehl werden Bilder über einen Proxy hochgeladen:

HTTPS_PROXY=http://10.128.0.136:3128 bmctl push images \
    --source bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry 172.18.0.20:5000 \
    --cacert ~/cert.pem

Eigenen Namespace mit bmctl push images verwenden

Wenn Sie auf dem Registry-Server Ihren eigenen Namespace anstelle des Stamm-Namespace verwenden möchten, kann containerd aus diesem Namespace abrufen, wenn Sie den API-Endpunkt für Ihre private Registry im Feld registryMirrors.endpoint Ihrer Clusterkonfigurationsdatei angeben. Der Endpunkt hat normalerweise das Format <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Weitere Informationen finden Sie im Nutzerhandbuch für Ihre private Registry. Weitere Informationen finden Sie unter Verwendung von v2 im Registrierungsendpunkt.

bmctl push images \
    --source=IMAGES_TAR_FILE_PATH \
    --private-registry=REGISTRY_IP:PORT/NAMESPACE \
    --cacert=CERT_PATH

Ersetzen Sie NAMESPACE durch den Namen des Namespace auf dem Registrierungsserver, in den Sie Bilder hochladen möchten.

Wenn Sie beispielsweise nur Zugriff auf 198.51.20:5000/test-namespace/ haben, können Sie einen Befehl wie den folgenden verwenden, um alle Bilder unter dem Namespace test-namespace hochzuladen:

bmctl push images \
    --source=./bmpackages_1.32.200-gke.104.tar.xz \
    --private-registry=198.51.20:5000/test-namespace \
    --username=alex \
    --password=pa55w0rd \
    --cacert /etc/pki/tls/certs/ca-bundle.crt

Anschließend können Sie in der Clusterkonfigurationsdatei Folgendes hinzufügen, um containerd aus dem Namespace test-namespace abzurufen:

registryMirrors:
  - endpoint: https://198.51.20:5000/v2/test-namespace

Weitere Informationen zum Befehl bmctl push images finden Sie in der bmctl-Befehlsreferenz.

Cluster für die Verwendung einer Registry-Spiegelung konfigurieren

Sie können einen Registry-Mirror für einen Cluster beim Erstellen des Clusters oder beim Aktualisieren eines vorhandenen Clusters konfigurieren. Die Konfigurationsmethode, die Sie verwenden, hängt vom Clustertyp ab und bei Nutzerclustern davon, ob Sie einen Cluster erstellen oder einen Cluster aktualisieren. In den folgenden beiden Abschnitten werden die beiden Methoden zum Konfigurieren von Registry-Spiegeln beschrieben.

Header-Abschnitt in der Cluster-Konfigurationsdatei verwenden

Mit Google Distributed Cloud können Sie Registry-Spiegel außerhalb der Clusterspezifikation im Header-Abschnitt der Clusterkonfigurationsdatei angeben:

  • Bei Administrator-, Hybrid- und Standalone-Clustern können Sie einen Registry-Mirror nur über den Header-Abschnitt in der Clusterkonfigurationsdatei konfigurieren. Diese Methode gilt für die Clustererstellung oder Clusteraktualisierungen.

  • Bei Nutzerclustern können Sie diese Methode nur während der Clustererstellung zum Konfigurieren einer Registry-Spiegelung verwenden. Alternativ können Sie eine Registry-Spiegelung für einen vorhandenen Nutzercluster konfigurieren, indem Sie den Abschnitt nodeConfig.registryMirrors in der Clusterspezifikation verwenden.

Die folgende Beispielcluster-Konfigurationsdatei gibt an, dass Images von einer lokalen Registry-Spiegelung mit dem Endpunkt https://198.51.20:5000 abgerufen werden sollen. Einige der am Anfang dieser Konfigurationsdatei angezeigten Felder werden in den folgenden Abschnitten beschrieben.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://198.51.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
    hosts:
      - somehost.io
      - otherhost.io
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

Abschnitt nodeConfig.registryMirrors in der Clusterspezifikation verwenden

Diese Methode zum Erstellen oder Aktualisieren eines Registry-Spiegels gilt nur für Nutzercluster. Da Sie die für den Verwaltungscluster erstellten Secrets für Ihren Nutzercluster freigeben können, können Sie mit dem Befehl nodeConfig.registryMirrors aus dem Verwaltungs-Administrator- oder Hybridcluster die Registry-Spiegelung im Clusterspezifikationsabschnitt für den Nutzercluster angeben.

So konfigurieren Sie einen Nutzercluster für die Verwendung derselben Registry-Spiegelung wie der Administratorcluster:

  1. Rufen Sie den Abschnitt nodeConfig.registryMirror, einschließlich der Secret-Referenzen, aus nodeConfig.registryMirrors der Admincluster-Ressource ab:

    kubectl get cluster CLUSTER_NAME -n CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG \
    -o yaml

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des Administrator- oder Hybridclusters, der den Nutzercluster verwaltet.

    • CLUSTER_NAMESPACE: der Namespace-Name für den Verwaltungscluster.

    • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des verwaltenden Clusters.

  2. Fügen Sie die nodeConfig.registryMirrors-Konfiguration aus dem Administratorcluster der Clusterkonfigurationsdatei des Nutzerclusters hinzu.

    Der Abschnitt registryMirrors in der Konfigurationsdatei des Nutzerclusters sollte in etwa so aussehen:

    ---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  nodeConfig:
    containerRuntime: containerd
    registryMirrors:
    -   caCertSecretRef:
        name: the-secret-created-for-the-admin-cluster
        namespace: anthos-creds
      endpoint: https://172.18.0.20:5000
      hosts:
        -   somehost.io
        -   otherhost.io
      pullCredentialSecretRef:
        name: the-image-pull-creds-created-for-the-admin-cluster
        namespace: anthos-creds
...

Wenn Sie später Änderungen an der Registry-Spiegelkonfiguration für Ihren Nutzercluster vornehmen möchten, bearbeiten Sie nodeConfig.registryMirrors in der Konfigurationsdatei des Nutzerclusters und wenden Sie die Änderungen mit bmctl update an.

Sie können den Header-Abschnitt der Clusterkonfigurationsdatei nicht verwenden, um die Konfiguration der Registry-Spiegelungen für einen Nutzercluster zu aktualisieren.

Feld hosts

containerd prüft den Abschnitt hosts der Clusterkonfigurationsdatei, um zu ermitteln, welche Hosts lokal gespiegelt werden. Diese Hosts werden dem in der Clusterkonfigurationsdatei angegebenen Registry-Spiegelungsendpunkt (registryMirror.endpoint) zugeordnet. In der Beispielkonfigurationsdatei aus dem vorherigen Abschnitt sind die im Abschnitt hosts aufgeführten öffentlichen Registries somehost.io und otherhost.io. Da diese öffentlichen Registries im Abschnitt hosts angezeigt werden, prüft containerd die private Registry-Spiegelung erst, wenn Pull-Anfragen für Images von somehost.io oder otherhost.io auftreten.

Angenommen, containerd empfängt einen Pull-Befehl an somehost.io/kubernetes-e2e-test-images/nautilus:1.0. Da somehost.io als einer der Hosts im Abschnitt hosts der Clusterkonfigurationsdatei aufgeführt ist, sucht containerd in der lokalen Registry-Spiegelung nach dem kubernetes-e2e-test-images/nautilus:1.0-Image. Wenn somehost.io nicht im Abschnitt hosts aufgeführt ist, weiß containerd nicht, dass eine lokale Spiegelung von somehost.io vorhanden ist. In diesem Fall prüft containerd nicht die Spiegelung auf das Image und ruft das Image einfach aus der öffentlichen Registry somehost.io ab.

Beachten Sie, dass Google Distributed Cloud standardmäßig Images von gcr.io spiegelt, sodass Sie gcr.io nicht als Host im Abschnitt hosts auflisten müssen.

Die hosts-Werte und der endpoint-Wert dürfen sich nicht überschneiden. Im folgenden Konfigurationsbeispiel wird ein Host (europe-docker.pkg.dev) gezeigt, der mit dem Domainteil des Endpunktwerts übereinstimmt. In diesem Fall müssen Sie keinen hosts-Wert angeben:

...
registryMirrors:
  ...
  endpoint: https://europe-docker.pkg.dev:5000/v2/cloud-data-fusion-images
  hosts:
    - europe-docker.pkg.dev
    ...

Feld gcrKeyPath

Wenn Sie möchten, dass Google Distributed Cloud automatisch Artifact Registry (gcr.io) verwendet, um Images abzurufen, die nicht in Ihrer lokalen Registry angezeigt werden, müssen Sie den Pfad zum Artifact Registry-Dienstkontoschlüssel angeben. Google Distributed Cloud hat keinen Mechanismus, um Schlüssel für andere öffentliche Registries bereitzustellen.

Wenn Sie nicht vorhaben, die Funktion zu verwenden, bei der Images aus gcr.io abgerufen werden, wenn sie nicht in Ihrer lokalen Registry angezeigt werden, müssen Sie keinen gcrKeyPath in der Cluster-Konfigurationsdatei hinzufügen.

Feld caCertPath

Wenn für Ihre Registry ein privates TLS-Zertifikat (Transport Layer Security) erforderlich ist, geben Sie in diesem Feld den Pfad zur CA-Zertifikatsdatei des Serverstamms an. Diese Zertifikatsdatei sollte sich auf der Administrator-Workstation befinden, also auf dem Computer, auf dem bmctl-Befehle ausgeführt werden. Wenn Ihre Registry kein privates TLS-Zertifikat erfordert, können Sie das Feld caCertPath leer lassen.

Feld pullCredentialConfigPath

Wenn Ihr Registry-Server keine Docker-Konfigurationsdatei zur Authentifizierung erfordert, können Sie das Feld pullCredentialConfigPath leer lassen. Dies ist der Pfad zur Konfigurationsdatei auf dem Computer, auf dem bmctl-Befehle ausgeführt werden.

Registry-Spiegelung mit Nutzerclustern verwenden

Nutzercluster rufen Images nicht automatisch von einer Registry-Spiegelung ab, wenn ihr Administratorcluster für sie konfiguriert wurde. Wenn Sie Nutzercluster aus einer Registry-Spiegelung abrufen möchten, müssen Sie sie einzeln konfigurieren, wie unter Cluster für die Verwendung einer Registry-Spiegelung konfigurieren beschrieben.

Registry-Spiegelungs-Endpunkte, Zertifikate und Pull-Anmeldedaten aktualisieren

So aktualisieren Sie Endpunkte, Zertifikate oder Pull-Anmeldedaten für die Registry-Spiegelung:

  1. Aktualisieren Sie in der Clusterkonfigurationsdatei den Endpunkt, die CA-Zertifikatsdatei und den Pfad zur Konfigurationsdatei für die Pull-Anmeldedaten.

  2. Übernehmen Sie die Änderungen mit dem folgenden Befehl:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME durch den Namen des Clusters, den Sie aktualisieren möchten.

    • ADMIN_KUBECONFIG durch den Pfad der Konfigurationsdatei seines Administratorclusters.

Abrufen von Images aus der Registry-Spiegelung prüfen

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 folgenden Datei: /etc/containerd/config.toml.

  2. Überprüfen Sie im Abschnitt plugins."io.containerd.grpc.v1.cri".registry.mirrors der Datei config.toml, ob Ihr Registry-Server im Feld endpoint aufgeführt ist. Hier ein Auszug aus der Beispieldatei config.toml, in der das Feld endpoint fett dargestellt wird:

    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", "https://privateregistry2.io"]
...

    Wenn Ihre Registry-Spiegelung im Feld endpoint angezeigt wird, ruft der Knoten Images aus Ihrer Registry-Spiegelung und nicht aus einer öffentlichen Registry ab.

Fehlerbehebung bei Registry-Spiegel-Einstellungen

Mit crictl, dem Befehlszeilentool für die Container-Laufzeitschnittstelle, können Sie Ihre Registrierungseinstellungen testen, indem Sie einzelne Bilddateien herunterladen. Jede Bilddatei wird unabhängig mit einem aussagekräftigen Versionsstring getaggt. Das Cluster-API-Controller-Image ist beispielsweise mit der Google Distributed Cloud-Releaseversion und das etcd-Image mit der entsprechenden etcd-Version getaggt.

Für die Version 1.31.200-gke.59 von Google Distributed Cloud for Bare Metal haben das Cluster API-Controller-Image cluster-api-controller und das etcd-Image etcd die folgenden Tags:

  • cluster-api-controller:1.31.200-gke.59
  • etcd:v3.4.30-0-gke.1

Image aus der Registry-Spiegelung herunterladen

Wenn in Ihrer Registry-Spiegelung keine Namespaces verwendet werden, verwenden Sie den folgenden Befehl, um ein Image abzurufen:

crictl pull REGISTRY_IP:PORT/IMAGE_PATH:IMAGE_TAG

Image aus einem Registry-Spiegel mit Namespaces abrufen

Wenn für Ihre Registry-Spiegelung Namespaces verwendet werden, verwenden Sie den folgenden Befehl, um ein Image abzurufen:

crictl pull REGISTRY_IP:PORT/NAMESPACE/IMAGE_PATH:IMAGE_TAG

Verwendung von v2 im Registrierungsendpunkt

Wenn in Ihrer Registry benutzerdefinierte Namespaces verwendet werden, müssen Sie dem Namespace im Registry-Endpunkt (registryMirror.endpoint) in der Clusterkonfigurationsdatei v2/ voranstellen. Wenn Sie keine Namespaces verwenden, verwenden Sie v2 nicht. Verwenden Sie in beiden Fällen nicht v2 im Wert des Flags --private-registry oder in Befehlen zum Herunterladen von Bildern:

Ohne Namespaces

  • Gültig:
    • endpoint: https://172.18.0.20:5000
    • crictl pull 172.18.0.20:5000/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
  • Ungültig:
    • endpoint: https://172.18.0.20:5000/v2
    • crictl pull 172.18.0.20:5000/v2/anthos-baremetal-release/etcd:v3.4.30-0-gke.1

Mit Namespaces

  • Gültig:
    • endpoint: https://172.18.0.21:5000/v2/namespace
    • crictl 172.18.0.21:5000/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1
  • Ungültig:
    • endpoint: https://172.18.0.21:5000/namespace
    • crictl pull 172.18.0.21:5000/v2/namespace/anthos-baremetal-release/etcd:v3.4.30-0-gke.1