Überwachung von Image Versionen im Kubernetes Cluster

Kubernetes
Wer Kubernetes Cluster betreut kennt das Problem: Irgendwann verliert man den Überblick darüber wo welche Images eingesetzt wurden und ob diese noch aktuell sind oder dringend aktualisiert werden sollten. In diesem Blog-Beitrag zeigen wir euch zwei Wege, wie ihr zukünftig unkompliziert die eingesetzten Image-Versionen in eurem Kubernetes Cluster ermitteln könnt.
November 22, 2021 Dennis Hemeier
Überwachung von Image Versionen

1. VIA KUBECTL OUTDATED

kubectl outdated ist ein kubectl plugin, dass dir alle eingesetzten Image-Versionen auf der CLI ausgibt (Es kann dir nur die Images anzeigen, die in den Pods verwendet werden, auf die du mindestens lesenden Zugriff hast). Wenn die Quelle eine Public-Image-Registry ist, wird zudem überprüft, welche die aktuellste Image-Version ist.

VORAUSSETZUNGEN

kubectl outdated wird über den krew Plugin-Manager für kubectl installiert. Wie krew installiert wird, findest du hier. Nach der erfolgreichen Installation von krew kannst du nun mit der eigentlichen Installation beginnen.

INSTALLATION

$ kubectl krew install outdated

VERWENDEN

$ kubectl outdated

Ausgabe:

outdated.png

In der Auflistung könnt ihr auf einem Blick sehen welche Image-Versionen eingesetzt werden und welche davon aktuell bzw. veraltet sind.
 
Weitere Informationen: replicatedhq/outdated

2. VIA JETSTACK/VERSION-CHECKER + PROMETHEUS-METRIKEN

Jetstack bietet als OpenSource-Lösung ein Kubernetes-Stack an, der fortlaufend die eingesetzten Image-Versionen innerhalb eines Kubernetes Clusters für dich überwacht und als Prometheus-Metriken bereitstellt, um diese beispielsweise über Grafana anzeigen zu lassen.

UNTERSTÜTZTE REGISTRIES

  • ACR

  • Docker Hub

  • ECR

  • GCR (inkl. GCR derivate wie zum Beispiel k8s.gcr.io)

  • Quay

  • Self-Hosted (Docker V2 API compliant registries - Mit Multi-Registry Unterstützung)

INSTALLATION

ServiceAccount + ClusterRole

Damit der Version-Checker die Image-Versionen aus den Pod-Spezifikationen auslesen kann, benötigt das Deployment die hierfür notwendigen Berechtigungen. Hierfür legen wir zunächst einen neuen Service-Account sowie eine neue ClusterRole an.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: version-checker
  namespace: version-checker
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: version-checker
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: version-checker
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: version-checker
subjects:
  - kind: ServiceAccount
    name: version-checker
    namespace: version-checker

Wie du der ClusterRole entnehmen kannst, hat der Service-Account ausschließlich lesenden Zugriff (get, watch, list) auf Pod-Ressourcen innerhalb des Clusters.

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: version-checker
  name: version-checker
  namespace: version-checker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: version-checker
  template:
    metadata:
      labels:
        app: version-checker
      annotations:
        prometheus.io/path: /metrics
        prometheus.io/port: "8080"
        prometheus.io/scrape: "true"
    spec:
      serviceAccountName: version-checker
      containers:
        - image: quay.io/jetstack/version-checker:v0.2.1
          imagePullPolicy: Always
          resources:
            requests:
              cpu: 50m
              memory: 50Mi
            limits:
              cpu: 500m
              memory: 75Mi
          ports:
            - containerPort: 8080
              name: http
          name: version-checker
          command: ["version-checker"]
          args: ["--test-all-containers"]

Die Prometheus-Metriken werden über die Route /metrics (Port 8080) zur Verfügung gestellt.

Service (optional)

Zu guter Letzt können wir noch einen Service einrichten, sollte der Zugriff auf die Prometheus-Metriken von außerhalb erforderlich sein.

apiVersion: v1
kind: Service
metadata:
  name: version-checker
  namespace: version-checker
  labels:
    app: version-checker
spec:
  selector:
    app: version-checker
  ports:
    - protocol: TCP
      name: http
      port: 8080
      targetPort: 8080

Version-Checker testen

Nachdem Service-Account, ClusterRole, ClusterRoleBinding und das Deployment im Kubernetes Cluster installiert wurden, können wir testen, ob der Version-Checker ordnungsgemäß funktioniert.

❯ kubectl -n version-checker get pod NAME READY STATUS RESTARTS AGE version-checker-586bbf4f88-qtcf9 1/1 Running 0 3d18h
❯ kubectl -n version-checker port-forward version-checker-586bbf4f88-qtcf9 8080 Forwarding from 127.0.0.1:8080 -> 8080 Forwarding from [::1]:8080 -> 8080

Anschließend kannst du über http://localhost:8080/metrics überprüfen, ob der Version-Checker die Prometheus-Metriken ordnungsgemäß bereitstellt.

metrics.png

Grafana Dashboard

Jetstack stellt ein rudimentäres Grafana-Dashboard zur Darstellung der Prometheus-Metriken zur Verfügung.

Zum Grafana-Dashboard

grafana-dashboard.png

Tipp:
Das bereitgestellte Grafana-Dashboard berücksichtigt in der Standard-Konfiguration aus Kompatibilitätsgründen nicht alle Werte. Bearbeitet das Grafana-Dashboard und aktualisiert die Query, um alle Werte wie im Screenshot zu erhalten.

sum by(image, namespace, pod, current_version,latest_version) (version_checker_is_latest_version)

Weitere Informationen und Konfigurationsmöglichkeiten zum Version-Checker von Jetstack findet ihr hier.

Über den Autor

Dennis Hemeier

Seit 2015 navigiert Dennis durch die Welt von Kubernetes und Cloud Native, modernisiert kritische Infrastrukturen und bringt sein Praxiswissen in Schulungen und Projekte ein. Mit ihm bleibt die Crew auch in rauer See immer auf Kurs.

Alle Blogeinträge von Dennis