Registry-Spiegelung für die Erstellung von Clustern verwenden

Auf dieser Seite wird erläutert, wie Sie Cluster mit Images erstellen, die aus einer Registry-Spiegelung anstelle einer öffentlichen Registry wie gcr.io abgerufen wurden.

Eine Registry-Spiegelung ist eine lokale Kopie einer öffentlichen Registry, die die Dateistruktur der öffentlichen Registry kopiert oder spiegelt. Beispiel: 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 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0 abzurufen. 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.

Hinweis

In Ihrem Netzwerk muss ein Container 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 Registry-Spiegelung verwenden möchten, müssen Sie die Containerlaufzeit auf containerd festlegen.

Alle erforderlichen Images für Anthos-Cluster auf Bare Metal herunterladen

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

Container-Images auf den Registry-Server hochladen

Laden Sie die Images mit dem folgenden Befehl aus dem Image-Paket auf Ihren Registry-Server hoch:

[HTTPS_PROXY=http://PROXY_IP:PORT] ./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=REGISTRY_IP:PORT \
    [--cacert=CERT_PATH] \
    [--need-credential=false]

Dabei gilt:

PROXY_IP:PORT durch die IP-Adresse und den Port des Proxys, wenn Sie einen Proxy zum Hochladen der Images von Ihrer Workstation auf den Registry-Server benötigen.
VERSION durch die Version des Image-Pakets, das Sie von der Seite Downloads heruntergeladen haben.
REGISTRY_IP:PORT durch die IP-Adresse und den Port des privaten Registry-Servers.
CERT_PATH durch den 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. Wenn für Ihren Registry-Server keine Anmeldedaten erforderlich sind, geben Sie --need-credential=false an.

Weitere Informationen zum Befehl bmctl push images erhalten Sie durch:

bmctl push images --help

Eigenen Namespace 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 in registryMirrors.endpoint angeben. Der Endpunkt hat normalerweise das Format <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Weitere Informationen finden Sie im Nutzerhandbuch für Ihre private Registry.

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

./bmctl push images \
    --source=./bmpackages_VERSION.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace
    --username=<USERNAME>
    --password=<PASSWORD>
    --cacert <path/to/cert.crt>

Anschließend können Sie die folgende Clusterkonfigurationsdatei hinzufügen, um containerd aus dem Namespace abzurufen:

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

Cluster über die Registry-Spiegelung erstellen

Die folgende Beispielcluster-Konfigurationsdatei gibt an, dass Images von einer lokalen Registry-Spiegelung mit dem Endpunkt https://172.18.0.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://172.18.0.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
...

Feld `hosts`

containerd prüft den Abschnitt hosts der Clusterkonfigurationsdatei, um zu ermitteln, welche Hosts lokal gespiegelt werden. In der Beispielkonfigurationsdatei 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 Anthos-Cluster auf Bare-Metal standardmäßig Images von gcr.io spiegeln, sodass Sie gcr.io nicht als Host im Abschnitt hosts auflisten müssen.

Feld `gcrKeyPath`

Wenn Sie möchten, dass Anthos-Cluster auf Bare-Metal Container Registry automatisch (gcr.io) verwenden, um Images abzurufen, die nicht in Ihrer lokalen Registry angezeigt werden, müssen Sie den Pfad zum Container Registry-Dienstkontoschlüssel angeben. Anthos-Cluster auf Bare-Metal haben 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 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.

Nutzercluster aus der Registry-Spiegelung erstellen

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 aus der Registry-Spiegelung erstellen beschrieben.

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

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

Aktualisieren Sie in der Clusterkonfigurationsdatei den Endpunkt, die CA-Zertifikatsdatei und den Pfad zur Konfigurationsdatei für den Abruf der Anmeldedaten.
Übernehmen Sie die Änderungen mit dem folgenden Befehl:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Dabei gilt:
- CLUSTER_NAME durch den Namen des Clusters, den Sie aktualisieren möchten.
- ADMIN_KUBECONFIG durch den Pfad zur Konfigurationsdatei des Administratorclusters.

Abrufen von Images aus der Registry-Spiegelung prüfen

In diesem Abschnitt werden zwei Methoden beschrieben, mit denen Sie prüfen können, ob containerd Images von Ihrer lokalen Registry-Spiegelung und nicht von einer öffentlichen Registry abruft.

Methode 1: Repository-Digests vergleichen

Bei dieser Methode werden Repository-Digests verglichen, um zu bestimmen, ob ein Image von Ihrer Registry-Spiegelung abgerufen wurde.

Beachten Sie, dass eine Registry eine eindeutige Kennung hat, die als Repository-Digest bezeichnet wird, und ein Image eine eindeutige Kennung, die als Container-Image-Digest bezeichnet wird. Zwei Images, die identisch sind, haben denselben Container-Image-Digest, auch wenn die Images aus verschiedenen Registries stammen. Wenn Images jedoch aus verschiedenen Registries stammen, haben sie unterschiedliche Repository-Digests.

Melden Sie sich mit SSH bei einem Clusterknoten an.
Wählen Sie ein Image aus, dessen Ursprung Sie bestätigen möchten.
Rufen Sie das Image aus der öffentlichen Registry mit dem folgenden Befehl ab:
```
crictl pull PUBLIC_ENDPOINT
```
Ersetzen Sie PUBLIC_ENDPOINT durch den Pfad zum Image in der öffentlichen Registry. Beispiel: gcr.io/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0
Rufen Sie dasselbe Image aus Ihrer Registry-Spiegelung mit dem folgenden Befehl ab:
```
crictl pull MIRROR_ENDPOINT
```
Ersetzen Sie MIRROR_ENDPOINT durch den Image-Pfad in der Registry-Spiegelung. Beispiel: 10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy:v0.6.0-gke.0
Führen Sie den folgenden Befehl aus, um die Repository-Digests der beiden Images, die Sie in den vorherigen Schritten abgerufen haben, aufzurufen:
```
crictl inspecti PUBLIC_OR_MIRROR_ENDPOINT | grep -A 3 repoDigests
```
Ersetzen Sie PUBLIC_OR_MIRROR_ENDPOINT entweder durch den öffentlichen Endpunkt des Images oder über den Endpunkt der Registry-Spiegelung des Images. Beides ist in Ordnung, da der Befehl crictl inspecti den Container-Image-Digest des Arguments prüft, das Sie an ihn übergeben. Da das Image aus der öffentlichen Registry mit dem Image der Registry-Spiegelung identisch ist, haben beide das gleiche Container-Image-Digest.

Die Ausgabe des Befehls könnte in etwa so aussehen:
```
 "repoDigests": [
   "gcr.io/anthos-baremetal-release/kube-rbac-proxy@sha256:27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3",
   "10.168.15.224:5007/test-namespace/anthos-baremetal-release/kube-rbac-proxy@sha256:27be66fb9140d83c4af8794a234b998c90e844e3414108ce72db603f4f6ea0b3"
 ],
```
Vergleichen Sie die Repository-Digests, die in der Ausgabe im vorherigen Schritts fett angezeigt werden. Wenn die Digests identisch sind, werden die Knoten in Ihrem Cluster von Ihrer Registry-Spiegelung abgerufen. Andernfalls rufen Ihre Clusterknoten Images aus einer öffentlichen Registry ab.

Methode 2: Datei `config.toml` prüfen

Sie können feststellen, ob containerd Images aus Ihrer lokalen Registry abruft. Prüfen Sie dazu den Inhalt einer Datei config.toml:

Melden Sie sich bei einem Knoten an und prüfen Sie den Inhalt der folgenden Datei: /etc/containerd/config.toml.
Ü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", "http://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.