Installieren und Verwalten von Kubernetes-Registries

Kubernetes kann vieles: Es koordiniert Anwendungen auf den Nodes, überwacht den Zustand der Nodes, versucht Anwendungsprobleme automatisch zu beheben und vieles mehr.

Eine Sache, die Kubernetes jedoch nicht von Haus aus mitbringt, ist eine Registry für das Hosting von Container-Images (die die Anwendungen enthalten, die Sie über Kubernetes bereitstellen möchten). Stattdessen erwartet Kubernetes, dass Sie eine externe Lösung zum Speichern und Teilen von Container-Images verwenden.

Es gibt eine Vielzahl von Optionen für Kubernetes-Registries, jede mit ihren eigenen Vor- und Nachteilen. Um Ihnen bei der Entscheidung zu helfen, welche Registry Sie mit Kubernetes verwenden sollten, zeigt dieses Tutorial einige der beliebtesten Kubernetes-kompatiblen Container-Registries und erklärt, wie man sie in Kubernetes integriert.

Was ist eine Kubernetes-Registry?

Bevor wir Beispiele für Registrys besprechen, die mit Kubernetes verwendet werden können, sollten wir klären, was mit dem Begriff “Kubernetes-Registry” gemeint ist, nämlich eine Container-Registry, die mit Kubernetes verwendet werden kann.

Eine Container-Registry ist eine Anwendung oder ein Dienst, der Container-Images speichert und sie auf Anfrage zur Verfügung stellt. Die meisten Container-Registries sind nicht speziell für die Verwendung mit Kubernetes konzipiert; sie speichern einfach Container-Images für alle Systeme, die sie benötigen.

Kubernetes selbst verfügt über keine integrierte Registry-Funktionalität (obwohl einige Kubernetes-Distributionen wie Red Hat OpenShift mit integrierten Registries ausgeliefert werden, die in Kubernetes-Clustern gehostet werden). In den meisten Fällen muss man sich für eine oder mehrere Registrierungen entscheiden, um Container-Images für die Anwendungen zu hosten, die man mit Kubernetes bereitstellen möchte, und diese Registrierungen dann mit Kubernetes verbinden.

Herunterladen von Images mit Kubernetes

Wenn Sie eine Registry für Kubernetes aufsetzen, lädt Kubernetes Container-Images von dort herunter, wenn Sie eine Anwendung ausführen möchten. Als Entwickler können Sie auch Images in Ihre Registry hochladen, um sie Kubernetes zur Verfügung zu stellen. Diese Uploads werden jedoch nicht mit Kubernetes durchgeführt, sondern mit einem separaten Tool, wie z.B. Docker.

Im Gegensatz zu einigen anderen Container-Tools ist es bei Kubernetes nicht erforderlich, dass Benutzer Container-Images auf lokale Systeme “pullen”, bevor sie verwendet werden können. In Kubernetes laden Sie Images herunter und führen Anwendungen aus, indem Sie ein Deployment erstellen. Dabei handelt es sich um eine YAML-Datei, die Kubernetes mitteilt, welches Container-Image bzw. welche Container-Images verwendet werden sollen. (In der YAML-Datei können auch zusätzliche Konfigurationsdaten angegeben werden, z.B. welcher Netzwerkport für die Container freigegeben werden soll.)

Wenn Sie beispielsweise eine Anwendung auf Basis des Apache-HTTPD-Webserver-Container-Images ausführen möchten, müssen Sie zunächst eine Deployment-Datei erstellen, die wie folgt aussieht:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  labels:
    role: webserver
spec:
  replicas: 4
  selector:
    matchLabels:
      role: webserver
  template:
    metadata:
      labels:
        role: webserver
    spec:
      containers:
        - name: frontend
          image: httpd
          ports:
            - containerPort: 80

Sie können die Datei dann mit einem kubectl apply-Befehl deployen, z. B.:

kubectl apply -f your_deployment_file.yml

Drei Arten von Kubernetes-Registries

Es gibt drei Möglichkeiten, eine Container-Registry mit Kubernetes zu verwenden:

• Externe öffentliche Registry: Eine externe öffentliche Registry ist eine öffentlich verfügbare Registry, wie z. B. Docker Hub, die außerhalb Ihres Kubernetes-Clusters gehostet wird.
• Externe private Registry: Eine externe private Registry ist nicht öffentlich verfügbar und wird nicht innerhalb Ihrer Kubernetes-Installation gehostet. Sie können sie nur in Ihrem lokalen Netzwerk verfügbar machen oder eine Docker-Registry-Instanz einrichten, die Sie in einem eigenen Container unabhängig von Ihrem Kubernetes-Cluster bereitstellen, oder Sie können ein privates Repository als Teil eines öffentlichen Registry-Dienstes wie Docker Hub einrichten.
• Private interne Registry: Eine private interne Registry ist eine Registry, die Sie innerhalb Ihres Kubernetes-Clusters einrichten und hosten. Das bedeutet, dass die Registry-Software neben anderen Anwendungen ausgeführt wird, die Sie in Kubernetes bereitstellen.

Externe öffentliche Registrys sind die einfachste Möglichkeit, eine Registry für Kubernetes zur Verfügung zu stellen. Sie müssen sich weder um die Konfiguration von Secrets (Zugangsinformationen, die benötigt werden, um Images aus einer privaten Registry zu ziehen) noch um die Einrichtung der Registry selbst kümmern.

Auf der anderen Seite sind private Registries notwendig, wenn Sie Ihre Container-Images nicht der Allgemeinheit zur Verfügung stellen möchten, sondern nur ausgewählten Benutzern, die diese in ihren eigenen Kubernetes-Clustern verwenden möchten. Wie bereits erwähnt, können Sie eine private Registry außerhalb von Kubernetes einrichten, was den Vorteil hat, dass sich Probleme mit der Registry nicht auf Ihre Kubernetes-Umgebung auswirken, aber Sie können auch eine Registry innerhalb von Kubernetes selbst hosten.

Die Default-Kubernetes-Registry

Wenn man von der “Standard-Kubernetes-Registry” spricht, ist in der Regel Docker Hub gemeint. Das liegt daran, dass Kubernetes standardmäßig davon ausgeht, dass Ihre Images in Docker Hub gehostet werden, es sei denn, Sie geben beim Erstellen Ihrer Bereitstellung etwas anderes an.

Betrachten Sie zum Beispiel diese Deployment-Datei:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2

Sie weist Kubernetes an, NGINX mit einem Image namens nginx:1.14.2 auszuführen. Da keine weiteren Informationen über den Registry-Namen oder den Ort, an dem das Image zu finden ist, angegeben werden, geht Kubernetes davon aus, dass das Image öffentlich auf Docker Hub gehostet wird.

Obwohl Docker Hub also nicht Teil von Kubernetes ist, macht die Tatsache, dass Kubernetes sich standardmäßig ohne zusätzliche Informationen mit damit verbinden kann, Docker Hub sozusagen zur “Standard”-Registry von Kubernetes.

Vier beliebte Kubernetes-Registries

Nachdem wir nun wissen, wie Kubernetes-Registries funktionieren, können wir uns ein paar beliebte Container-Registries ansehen, die sich mit Kubernetes verwenden lassen.

1. Docker Hub

Kubernetes ist standardmäßig für die Verwendung konfiguriert. Das bedeutet, dass Sie nichts tun müssen, um Docker Hub als Kubernetes-Registry zu verwenden – vorausgesetzt, die Images, die Sie herunterladen und ausführen möchten, sind in öffentlichen Docker Hub-Repositories gespeichert (d. h. die Repositories sind für die Allgemeinheit verfügbar und erfordern keine Anmeldungen).

Um private Docker Hub-Repositorys mit Kubernetes zu verwenden, müssen Sie ein Secret in Ihrem Kubernetes-Cluster konfigurieren. Das Secret enthält Ihre Docker Hub-Anmeldedaten, die Kubernetes benötigt, um sich mit Ihrem privaten Docker Hub-Repository zu verbinden.

Sie können kubectl verwenden, um das Secret zu erstellen (stellen Sie sicher, dass Sie Ihre Docker Hub-Anmeldedaten wie erforderlich angeben):

kubectl create secret docker-registry privatecred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

In diesem Beispiel haben wir unser Geheimnis privatecred genannt.

Um dann eine Anwendung in Kubernetes mit Images aus diesem privaten Repository bereitzustellen, erstellen Sie ein Deployment-File, das im Abschnitt imagePullSecrets den Namen des Secrets Ihrer Credentials angibt:

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
    - name: private-reg-container
      image: <your-private-image>
  imagePullSecrets:
    - name: privatecred

Abschließend deployen Sie die Datei mit kubectl apply.

2. Docker Registry

Docker Registry ist eine Open-Source-Container-Registry, die von Docker entwickelt wurde. Sie ist nicht zu verwechseln mit Docker Hub, einer auf Docker gehosteten Registry. Im Gegensatz dazu ist Docker Registry eine Software, die Sie herunterladen und auf Ihrem eigenen Server installieren können.

Die einfachste Möglichkeit, Docker Registry auszuführen, besteht darin, es als eigenständigen Container bereitzustellen. Sie können dies mit einem einzigen Befehl tun:

docker run -d -p 5000:5000 --name registry registry:2

Mit dem Docker-CLI-Dienstprogramm können Sie Images in die Registry schieben und abrufen.

Wenn Sie Images aus dieser lokalen Registry nutzen möchten, um Anwendungen innerhalb Ihres Kubernetes-Clusters bereitzustellen, müssen Sie ein Secret für eine private Registry einrichten, ähnlich wie im Docker Hub-Beispiel oben.

Erstellen Sie zunächst ein Secret in Kubernetes:

kubectl create secret docker-registry privatecred --docker-server=localhost:5000 --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

Beachten Sie, dass wir den Registry-Server als localhost:5000 angegeben haben, was mit dem Port übereinstimmt, den wir beim Starten des Docker Registry-Containers verwendet haben.

Nachdem Sie das Secret erzeugt haben, können Sie eine Deployment-Datei erstellen, die Kubernetes darauf verweist:

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  imagePullSecrets:
    - name: privatecred
  containers:
    - name: private-reg-container
      image: <your-private-image>

 

Abschließend deployen Sie die Datei mit kubectl apply.

3. Quay

Quay ist eine Registry, die ursprünglich von CoreOS (das jetzt zu Red Hat gehört) als Alternative zu Docker Hub und Docker Registry entwickelt wurde. Es gibt eine gehostete Version von Quay, aber Sie können Quay auch als private, selbst gehostete Registry nutzen.
Am einfachsten ist es, wenn Sie Quay innerhalb Ihres Kubernetes-Clusters ausführen. Sie können den Einrichtungsprozess mit Hilfe eines Operators automatisieren.

Erstellen Sie zunächst eine CatalogSource in Ihrem Cluster für Quay:

kubectl create -n openshift-marketplace -f ./bundle/quay-operator.catalogsource.yaml

Anschließend deployen Sie Quay mit:

kubectl create -n <your-namespace> -f ./config/samples/managed.quayregistry.yaml

Quay bietet ein webbasiertes Dashboard, mit dem Sie den Zugriff auf Ihr Quay-Repository verwalten können. Um Images aus Quay in Kubernetes zu pullen, müssen Sie wieder ein Secret erstellen und es als YAML-Datei über das UI herunterladen:

Quelle: https://docs.projectquay.io/use_quay.html

4. JFrog Artifactory

JFrog Artifactory kann sowohl als Container-Registry als auch als automatisierte DevOps-Plattform und Verwaltungstool für Binaries und Artefakte aller Art fungieren. Das bedeutet, dass Sie Artifactory nicht nur als Kubernetes-Registry verwenden können, sondern auch zur Verwaltung aller Objekte und Ressourcen, die mit der Anwendungsentwicklung und -bereitstellung verbunden sind.

Artifactory kann auf Kubernetes mit nur wenigen Befehlen unter Verwendung von Helm-Charts installiert werden:

helm repo add jfrog https://charts.jfrog.io
helm repo update
helm upgrade --install artifactory --namespace artifactory jfrog/artifactory

Um das Secret zu erstellen, das Kubernetes benötigt, um sich mit Artifactory zu verbinden, führen Sie einen Befehl wie den folgenden aus:

kubectl create secret docker-registry privatecred \
--docker-server=my-artifactory.jfrog.io \
--docker-username=read-only \
--docker-password=my-super-secret-pass \
--docker-email=johndoe@example.com \
-n my-app-ns

Dann fügen Sie einfach das Secret zu Ihrer Deployment Datei hinzu:

apiVersion: apps/v1
kind: Deployment
...
spec:
...
template:
spec:
containers:
- image: my-artifactory.jfrog.io/default-docker-virtual/my-app:1.0.1
imagePullSecrets:
- name: privatecred

Jetzt können Sie Ihre Artifactory-Instanz, die innerhalb von Kubernetes gehostet wird, zur Verwaltung von Images und anderen Dateien nutzen.

Neben der Flexibilität, die Artifactory durch seine Fähigkeit bietet, alle Arten von Artefakten zu verwalten (eine Funktion, die anderen großen Kubernetes-Registries fehlt), bietet Artifactory eine benutzerfreundliche Oberfläche für die Erstellung von Repositories und die Verwaltung von Images in diesen Repositories:

Quelle: https://jfrog.com/help/r/jfrog-artifactory-documentation/docker-registry

Wie Sie Ihre Kubernetes-Registry optimal nutzen

Obwohl Kubernetes standardmäßig so konfiguriert ist, dass öffentliche Docker Hub Repositories als Quelle für Images verwendet werden, ist dies nicht immer wünschenswert. Wenn einige oder alle Ihrer Kubernetes-Anwendungen privat sein sollen, müssen Sie eine private Registry-Lösung konfigurieren, indem Sie entweder ein privates Docker Hub-Repository verwenden oder Ihre eigene private Registry mit einer Plattform wie Artifactory betreiben.