Container Registry anbinden

Images aus öffentlichen Registries lädt Ihr Cluster ohne weitere Konfiguration. Für private Registries hinterlegen Sie die Zugangsdaten als Secret vom Typ docker-registry und verweisen in Ihren Workloads darauf.

Voraussetzungen

Ein Kubernetes Cluster im Status Running und eine geprüfte Verbindung per kubectl

Zugangsdaten als Secret anlegen

kubectl create secret docker-registry registry-credentials \
  --docker-server=registry.example.com \
  --docker-username=<benutzername> \
  --docker-password=<passwort-oder-token> \
  --namespace=produktion

Die Parameter im Einzelnen:

--docker-server – Adresse der Registry, ohne Protokollangabe
--docker-username – Benutzername oder Kontoname
--docker-password – Passwort oder – bevorzugt – ein Zugriffstoken

Warnung

Ein Secret gilt immer nur innerhalb eines Namespace. Verwenden Sie mehrere Namespaces, legen Sie das Secret in jedem davon an.

Secret prüfen:

kubectl get secret registry-credentials -n produktion

Secret im Deployment verwenden

Verweisen Sie im Pod-Template über imagePullSecrets auf das Secret:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: produktion
spec:
  replicas: 2
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      imagePullSecrets:
        - name: registry-credentials
      containers:
        - name: app
          image: registry.example.com/team/app:1.4.2
          ports:
            - containerPort: 8080

Anwenden:

kubectl apply -f deployment.yaml

Registry für alle Workloads eines Namespace hinterlegen

Damit nicht jedes Manifest den Verweis enthalten muss, ergänzen Sie das Secret am default-ServiceAccount des Namespace:

kubectl patch serviceaccount default \
  -n produktion \
  -p '{"imagePullSecrets":[{"name":"registry-credentials"}]}'

Alle Pods, die diesen ServiceAccount verwenden, beziehen die Zugangsdaten anschließend automatisch. Bereits laufende Pods müssen dafür neu gestartet werden:

kubectl rollout restart deployment app -n produktion

Fehlersuche

Prüfen Sie bei Problemen zunächst den Pod-Status:

kubectl get pods -n produktion
kubectl describe pod <pod-name> -n produktion

Der Abschnitt Events benennt die Ursache:

Status	Bedeutung
`ImagePullBackOff`	Das Image konnte nicht geladen werden – Zugangsdaten, Image-Name oder Tag prüfen
`ErrImagePull`	Der Ladevorgang ist fehlgeschlagen; wiederholt sich der Fehler, wechselt der Status zu `ImagePullBackOff`
`unauthorized` in den Events	Die Zugangsdaten sind falsch oder das Secret fehlt im Namespace
`manifest unknown` in den Events	Das Image existiert, der angegebene Tag jedoch nicht

Häufige Ursachen:

Das Secret liegt in einem anderen Namespace als der Pod.
Die Angabe unter --docker-server weicht vom Registry-Anteil des Image-Namens ab. Beide müssen übereinstimmen.
Das verwendete Token ist abgelaufen oder besitzt keine Leserechte.

Empfehlungen

Verwenden Sie Zugriffstokens mit Leserechten statt Kontopasswörtern.
Setzen Sie feste Tags oder Digests statt latest, damit nachvollziehbar bleibt, welche Version ausgerollt wurde.
Beschränken Sie über RBAC, wer Secrets lesen darf – siehe RoleBindings einrichten.

Voraussetzungen​

Zugangsdaten als Secret anlegen​

Secret im Deployment verwenden​

Registry für alle Workloads eines Namespace hinterlegen​

Fehlersuche​

Empfehlungen​

Verwandte Themen​