Checkmk
to checkmk.com

1. Vorwort

Sowohl an dieser Beschreibung als auch an dem Feature des neuen Kubernetes-Monitorings in der Checkmk-Version 2.1.0 selbst kann es noch Änderungen geben. Beachten Sie dazu die Änderungen an diesem Artikel auf GitHub bzw. unsere Werks bezüglich Änderungen am Feature selbst.

Da die Integration von Kubernetes in Checkmk nativ in Kubernetes selbst eingebaut wurde, nutzen wir auch direkt die README-Dateien in den GitHub-Repositories. Vor allem die Anleitungen zur Installation des Agenten ist eine direkte Quelle, um die aktuell empfohlenen Wege in Kurzform nachzulesen.

1.1. Einstieg in das Kubernetes-Monitoring

Für einen Einstieg in das neue Monitoring von Kubernetes empfehlen wir die beiden Videos Kubernetes Monitoring with Checkmk und Detecting issues and configuring alerts for Kubernetes clusters.

1.2. Unterschiede zum bisherigen Kubernetes-Monitoring

Das Kubernetes-Monitoring in Checkmk wurde von Grund auf neu geschrieben. Der Umfang der überwachbaren Daten ist stark gewachsen. Da die technische Grundlage für das Kubernetes-Monitoring in Checkmk 2.1.0 grundlegend anders ist, ist eine Übernahme oder auch eine Weiterschreibung bisheriger Monitoring-Daten Ihrer Kubernetes-Objekte nicht möglich.

2. Einleitung

kubernetes logo

Kubernetes ist seit geraumer Zeit das am meisten verwendete Werkzeug für die Orchestrierung von Containern. Checkmk unterstützt Sie bei der Überwachung Ihrer Kubernetes-Umgebungen.

Ab Version 2.1.0 können Sie mit Checkmk die folgenden Kubernetes-Objekte überwachen:

  • Cluster

  • Nodes

  • Deployments

  • Pods

  • DaemonSets

  • StatefulSets

Eine vollständige Auflistung aller verfügbaren Check-Plugins für die Überwachung von Kubernetes finden Sie in unserem Katalog der Check-Plugins.

3. Voraussetzungen im Cluster schaffen

Um Ihr Kubernetes-Cluster in Checkmk überwachen zu können, schaffen Sie zuerst die Voraussetzungen in Ihrem Cluster. Vor allem, indem Sie dem Cluster mitteilen, welche Pods/Container bereitgestellt werden sollen und wie die Konfiguration derselben aussehen muss.

3.1. Helm-Repository einrichten

Aktuell empfehlen wir die Installation des Kubernetes-Monitoring mit Hilfe des Tools helm, da es sich auch für weniger versierte Nutzer eignet und die Verwaltung der Konfigurationen standardisiert. Helm ist eine Art Paketmanager für Kubernetes. Sie können darüber Repositories als Quellen einbinden und die darin enthaltenen Helm-Charts wie Pakete ganz einfach Ihrem Cluster hinzufügen. Machen Sie dafür zuallererst das Repository bekannt. In dem folgenden Beispiel nutzen wir den Namen tribe29, um später einfacher auf das Repository zugreifen zu können. Sie können aber selbstverständlich auch jeden anderen Namen nutzen:

user@host:~$ helm repo add tribe29 https://tribe29.github.io/checkmk_kube_agent

Nachdem Sie das frisch geklonte Repository mit dem Kommando helm repo update optional aktualisiert haben, können Sie mit dem zweiten Schritt die weitere Konfiguration angehen.

3.2. Anpassungen an der Konfiguration vornehmen

Mit Helm erzeugen Sie die notwendigen Konfigurationsdateien komplett selbstständig. Um bestimmte Parameter über alle Konfigurationen hinweg selbst bestimmen zu können, geben Sie dabei eine Steuerdatei mit, die sogenannte values.yaml. Als Ausgangsbasis empfehlen wir die von uns bereitgestellte Vorlage. Kopieren Sie sich diese und passen Sie sie an die eigene Umgebung an.

Da wir im Vorfeld nicht wissen können, wie Ihr Kubernetes-Cluster aufgebaut ist, haben wir die sicherste Variante gewählt, wie die Checkmk-Kollektoren gestartet werden: Sie stellen standardmäßig keine Ports bereit, um von außen erreicht werden zu können. Damit Sie später auf die Kollektoren zugreifen können, passen Sie diese Einstellungen entsprechend an.

Der Einfachheit halber nehmen wir unsere Vorlage als Ausgangsbasis. Wir unterstützen standardmäßig zwei Kommunikationspfade: Die Abfrage über Ingress und die Abfrage über NodePort. Je nachdem, welche Variante Sie in Ihrem Cluster unterstützen, ist die Konfiguration unterschiedlich.

Kommunikation per Ingress bereitstellen

Falls Sie Ingress verwenden, um die Zugriffe zu Ihren Diensten zu steuern, passen Sie entsprechend die bereits vorbereiteten Teile in der values.yaml an. Zur besseren Übersicht ist in dem folgenden Beispiel nur der relevante Ausschnitt gezeigt. Den Wert enabled setzen Sie auf true. Die restlichen Werte passen Sie entsprechend Ihrer Umgebung an:

  ingress:
    enabled: true
    className: ""
    annotations:
      nginx.ingress.kubernetes.io/rewrite-target: /
    hosts:
      - host: checkmk-cluster-collector.local
        paths:
          - path: /
            pathType: Prefix
    tls: []
    #  - secretName: chart-example-tls
    #    hosts:
    #      - chart-example.local

Kommunikation per NodePort bereitstellen

Sie können den Zugriff auf die Dienste auch direkt über einen Port bereitstellen. Das ist dann notwendig, wenn Sie kein Ingress verwenden. Auch in dem nachfolgenden Beispiel wird nur der relevante Ausschnitt gezeigt. Sie setzen dabei den Wert type auf NodePort und entfernen die Auskommentierung zu dem Wert nodePort:

  service:
    # if required specify "NodePort" here to expose the cluster-collector via the "nodePort" specified below
    type: NodePort
    port: 8080
    nodePort: 30035

3.3. Konfigurationsdateien erstellen lassen

Nachdem Sie die values.yaml angepasst oder eine eigene erstellt haben, erstellen Sie mit dem folgenden Kommando alle notwendigen Konfigurationsdateien, um Ihr Kubernetes-Cluster für die Überwachung in Checkmk einzurichten:

user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring checkmk tribe29/checkmk -f values.yaml

Da das Kommando nicht selbsterklärend ist, bieten wir Ihnen nachfolgend eine Erläuterung zu den einzelnen Optionen:

BefehlsteilBedeutung

helm upgrade --install

Dieser Teil ist der Basisbefehl, um dem Kubernetes-Cluster die Konfiguration zu übermitteln

--create-namespace

In Kubernetes geben Sie immer an, zu welchem Namespace die Konfiguration hinzugefügt werden soll. Diese Option benötigen Sie, falls es den Namespace noch nicht gibt. Helm wird ihn in diesem Fall mit anlegen.

-n checkmk-monitoring

Diese Option bestimmt den Namespace, zu dem die Konfiguration hinzugefügt werden soll. checkmk-monitoring ist dabei nur ein Beispiel, wie dieser heißen könnte.

checkmk

checkmk steht hier als Beispiel für den Namen des Helm-Charts. Idealerweise belassen Sie diesen Namen auch so, da Sie nur dann automatisch davon profitieren, dass die Kubernetes-Objekte kurze Namen bekommen

tribe29/checkmk

Der erste Teil dieser Option beschreibt das Repository, welches Sie mit dem Kommando zuvor angelegt haben. Der zweite Teil — nach dem Schrägstrich — ist das Paket, in dem die notwendigen Informationen liegen, um die Konfiguration ihres Kubernetes-Monitoring erstellen zu können.

-f values.yaml

Zuletzt geben Sie die Konfigurationsdatei an, die Sie zuvor erstellt bzw. angepasst haben. Sie enthält alle Anpassungen, die in den Konfigurationsdateien berücksichtigt werden sollen, die mit helm erstellt werden.

Nachdem Sie das Kommando ausgeführt haben, ist Ihr Kubernetes-Cluster vorbereitet, um mit Checkmk überwacht zu werden. Das Cluster wird sich nun selbstständig darum kümmern, dass die notwendigen Pods und die darin enthaltenen Container laufen und erreichbar sind.

3.4. Alternative: Einrichten per Manifest

Normalerweise ist es nicht sinnvoll, dass Sie die Manifeste (Konfigurationsdateien) selbst anpassen. Zum einen, da Sie dafür genaue Kenntnisse der Architektur der Checkmk Kubernetes Collectors benötigen und zum anderen, da die händische Anpassung sehr viel fehleranfälliger ist. So richten Sie in helm die Kommunikation über TLS einmalig ein, anstatt sie an allen relevanten Stellen in den Manifesten selbst einzutragen.

Wenn Sie jedoch kein helm nutzen, oder die Kontrolle über alle Details der Einrichtung haben wollen, können Sie diesen Weg dennoch gehen.

Laden Sie dafür zuerst die von uns vorgefertigten Manifeste aus unserem entsprechenden Repository bei GitHub herunter. Wir haben die gesamte Konfiguration auf mehrere Dateien aufgeteilt, um deren Wartung zu erleichtern bzw. übersichtlichere Dateien für klar definierte Zwecke zur Verfügung zu stellen.

Sie benötigen mindestens die folgenden fünf Dateien:

DateinameZweck

00_namespace.yaml

Namespace namens checkmk-monitoring anlegen

checkmk-serviceaccount.yaml

Service-Account namens checkmk und Cluster-Rolle namens checkmk-metrics-reader im Namespace checkmk-monitoring anlegen

cluster-collector.yaml

Hier wird der von uns so getaufte Cluster Collector erzeugt. Dazu werden u.a. ein Service-Account namens cluster-collector im Namespace checkmk-monitoring erzeugt und die Service-Accounts werden Rollen innerhalb des Clusters zugewiesen. Außerdem wird eben das Deployment namens cluster-collector definiert.

node-collector.yaml

Analog zu cluster-collector.yaml für die Nodes

service.yaml

Service namens cluster-collector im Namespace checkmk-monitoring anlegen. Service namens cluster-collector-nodeport im Namespace checkmk-monitoring anlegen. Hier wird auch der Port für den NodePort festgelegt.

Wenn Sie nicht gleich das gesamte Repository klonen wollen, können Sie mit dem folgenden Befehl gezielt die fünf benötigten Dateien herunterladen:

user@host:~$ URL='https://raw.githubusercontent.com/tribe29/checkmk_kube_agent/main/deploy/kubernetes/'; for i in 00_namespace checkmk-serviceaccount cluster-collector node-collector service; do wget "${URL}${i}.yaml"; done

Wenn Sie zusätzlich noch eine Network Policy und eine Pod Security Policy einrichten wollen, benötigen Sie zusätzlich noch die beiden folgenden Dateien:

network-policy.yaml
pod-security-policy.yaml
user@host:~$ URL='https://raw.githubusercontent.com/tribe29/checkmk_kube_agent/main/deploy/kubernetes/'; for i in network-policy pod-security-policy; do wget "${URL}${i}.yaml"; done

In den Dateien cluster-collector.yaml und node-collector.yaml müssen Sie im Anschluss noch vier Platzhalter mit konkretem Inhalt füllen. In beiden Dateien finden Sie Stellen, an denen main_<YYYY.MM.DD> steht. Ersetzen Sie diese Platzhalter durch Tags unseres Kubernetes-Collectors auf Docker Hub. Beispielweise könnten Sie mit dem folgenden Befehl alle Vorkommnisse von main_<YYYY.MM.DD> mit dem Tag des Builds unseres Containers vom 1. März 2022 ersetzen.

user@host:~$ sed -i 's/main_<YYYY.MM.DD>/main_2022.03.01/g' node-collector.yaml cluster-collector.yaml

Für die Kommunikation nach außen wird ein Service vom Typ NodePort benötigt. Dieser erlaubt die Kommunikation von extern und wird in der Datei service.yaml fest auf den TCP-Port 30035 gesetzt. Sollte dieser Port in Ihrem Cluster schon vergeben sein, ändern sie den Port entsprechend.

Sobald Sie diese Einstellungen vorgenommen haben, können Sie diese Manifest-Dateien gesammelt auf Ihr Cluster anwenden. Führen Sie dazu am Speicherort der Manifeste den folgenden Befehl aus:

user@host:~$ kubectl apply -f .
namespace/checkmk-monitoring created
serviceaccount/checkmk created
clusterrole.rbac.authorization.k8s.io/checkmk-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/checkmk-metrics-reader-binding created
serviceaccount/cluster-collector created
clusterrolebinding.rbac.authorization.k8s.io/checkmk-cluster-collector created
clusterrolebinding.rbac.authorization.k8s.io/checkmk-token-review created
deployment.apps/cluster-collector created
serviceaccount/node-collector-machine-sections created
serviceaccount/node-collector-container-metrics created
clusterrole.rbac.authorization.k8s.io/node-collector-container-metrics-clusterrole created
podsecuritypolicy.policy/node-collector-container-metrics-podsecuritypolicy created
clusterrolebinding.rbac.authorization.k8s.io/node-collector-container-metrics-cluterrolebinding created
daemonset.apps/node-collector-container-metrics created
daemonset.apps/node-collector-machine-sections created
service/cluster-collector created
service/cluster-collector-nodeport created

Per kubectl können Sie im Anschluss auch prüfen, ob die Manifeste korrekt angewendet wurden. Lassen Sie sich dazu mit dem folgenden Befehl alle Pods des Namespace checkmk-monitoring anzeigen:

user@host:~$ kubectl get pods -n checkmk-monitoring

Des weiteren können Sie auch noch alle Services innerhalb des Namespace wie folgt prüfen:

user@host:~$ kubectl get svc -n checkmk-monitoring

4. Monitoring in Checkmk einrichten

Als nächstes geht es in der GUI von Checkmk an die Einrichtung des Spezialagenten und einer Regel für die automatische Erzeugung von Hosts für Ihre Kubernetes-Objekte. Für die Einrichtung des Spezialagenten müssen aber zuerst noch einige Voraussetzungen erfüllt werden:

4.1. Passwort (Token) in Checkmk hinterlegen

Das Passwort (Token) des Service-Accounts können Sie am besten im Passwortspeicher von Checkmk hinterlegen. Das ist die sicherste Variante, da Sie Hinterlegung und Benutzung des Passworts organisatorisch trennen können. Alternativ geben Sie es beim Anlegen der Regel (siehe weiter unten) direkt im Klartext ein.

Wenn Sie als Namespace für das Monitoring Ihres Kubernetes-Clusters das vorgegebene checkmk-monitoring beibehalten haben, schneidet die folgende Befehlszeile das Passwort direkt aus der Ausgabe von kubectl get secrets aus:

user@host:~$ kubectl get secret $(kubectl get serviceaccount checkmk -o=jsonpath='{.secrets[*].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJjaGVjay1tayIsI
mt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJjaGVjay1tay10b2tlbi16OWhicCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5
hbWUiOiJjaGVjay1tayIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjIxODE3OWEzLTFlZTctMTFlOS1iZjQzLTA4MDAyN2E1ZjE0MSIsInN1YiI6I
nN5c3RlbTpzZXJ2aWNlYWNjb3VudDpjaGVjay1tazpjaGVjay1tayJ9.gcLEH8jjUloTeaAj-U_kRAmRVIiETTk89ujViriGtllnv2iKF12p0L9ybT1fO-1Vx7XyU8jneQRO9lZw8JbhVmaPjrkEc8
kAcUdpGERUHmVFG-yj3KhOwMMUSyfg6wAeBLvj-y1-_pMJEVkVbylYCP6xoLh_rpf75JkAicZTDmhkBNOtSf9ZMjxEmL6kzNYvPwz76szLJUg_ZC636OA2Z47qREUtdNVLyutls7ZVLzuluS2rnfoP
JEVp_hN3PXTRei0F5rNeA01wmgWtDfo0xALZ-GfvEQ-O6GjNwHDlsqYmgtz5rC23cWLAf6MtETfyeEJjRqwituhqUJ9Jp7ZHgQ%

Das Passwort ist wirklich so lang. Wenn Sie direkt unter Linux arbeiten, können Sie hinten noch ein | xsel --clipboard hinzufügen. Dann wird das Passwort gar nicht ausgegeben, sondern direkt in die Zwischenablage kopiert (also als ob Sie das mit der Maus kopiert hätten):

user@host:~$ kubectl get secret $(kubectl get serviceaccount checkmk -o=jsonpath='{.secrets[*].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode | xsel --clipboard

Fügen Sie das Passwort in den Checkmk-Passwortspeicher ein mit Setup > General > Passwords > Add password z.B. unter der ID und dem Titel kubernetes:

kubernetes password

4.2. CA des Service-Accounts in Checkmk importieren

Damit Checkmk der Certificate Authority (CA) des Service-Accounts vertrauen kann, müssen Sie das CA-Zertifikat in Checkmk hinterlegen. Auslesen können Sie das Zertifikat — sofern Sie als Namespace checkmk-monitoring beibehalten haben — mit dem folgenden Befehl:

user@host:~$ kubectl get secret $(kubectl get serviceaccount checkmk -o=jsonpath='{.secrets[*].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode

Kopieren Sie hier alles inklusive der Zeilen BEGIN CERTIFICATE und END CERTIFIACTE und fügen Sie das Zertifikat im Setup-Menü unter Setup > General > Global settings > Site management > Trusted certificate authorities for SSL hinzu.

kubernetes ca

4.3. Piggyback Quell-Host anlegen

Erzeugen Sie in Checkmk auf gewohnte Weise einen neuen Host und nennen Sie diesen beispielsweise mykubernetesclusterhost. Wie Überschrift und Host-Name schon nahelegen, dient dieser Host dazu die Piggyback-Daten zu sammeln und außerdem alle Services und Metriken auf Cluster-Ebene abzubilden. Da dieser Host ausschließlich über den Spezialagenten Daten erhält, setzen Sie in den Eigenschaften des Hosts die Option IP address family auf No IP.

4.4. Dynamische Host-Konfiguration einrichten

Um eine Trennung zwischen den zahlreichen Kubernetes-Objekten und Ihrer restlichen Monitoring-Umgebung zu gewährleisten, bietet es sich an zuerst über Setup > Hosts > Add folder einen Ordner anzulegen, in welchem die dynamische Host-Konfiguration automatisch alle notwendigen Hosts anlegen kann. Einen solchen Ordner zu erzeugen bzw. zu nutzen ist aber optional.

Unbedingt notwendig hingegen ist die Einrichtung eines Konnektors fürs die anfallenden Piggyback-Daten. Über Setup > Hosts > Dynamic host management > Add connection gelangen Sie zur Seite für die entsprechende Einrichtung. Tragen Sie zuerst einen Titel ein und klicken Sie anschließend unter Connection Properties auf show more.

Klicken Sie als Nächstes auf Add new element und wählen Sie unter Create hosts in den zuvor angelegten Ordner aus.

In einer Kubernetes-Umgebung, in der überwachbare und überwachte Objekte kontinuierlich kommen und gehen, empfiehlt es sich auch die Option Automatically delete hosts without piggyback data zu aktivieren. Was genau diese Option bewirkt und unter welchen Umständen Hosts dann tatsächlich gelöscht werden, erklären wir im Kapitel Automatisches Löschen von Hosts im Artikel zur dynamischen Host-Konfiguration.

Tragen Sie nun noch unter Restrict source hosts den zuvor angelegten Piggyback Quell-Host ein und aktivieren Sie die Option Discover services during creation.

Der Abschnitt Connection Properties dieses neuen Konnektors könnte im Anschluss wie folgt aussehen:

Beispielhafte Einstellungen einer dynamische Host-Konfiguration.

4.5. Spezialagent einrichten

Nachdem nun alle Voraussetzungen im Cluster und in Checkmk geschaffen sind, können Sie sich der Konfiguration des Spezialagenten widmen. Diese finden Sie über Setup > Agents > VM, Cloud, Container > Kubernetes.

Zuallererst müssen Sie einen Namen für das zu überwachende Cluster vergeben. Diesen Namen können Sie frei wählen. Er dient dazu alle Objekte, die aus genau diesem Cluster stammen mit einem eindeutigen Namen zu versehen. Wenn Sie hier beispielsweise mycluster eintragen, werden die Namen der Hosts aller Pods aus diesem Cluster später mit pod_mycluster beginnen. Der nächste Teil des Host-Namens wird dann immer der Namespace sein, in dem dieses Kubernetes-Objekt existiert.

Wählen Sie unter Token nun den zuvor angelegten Eintrag aus dem Passwortspeicher von Checkmk aus.

Unter API server connection > Endpoint verlangt Checkmk nun die Eingabe der URL (bzw. IP-Adresse) über welche ihr Kubernetes API Server erreichbar ist. Die Angabe des Ports ist hier ebenfalls notwendig, wenn der Dienst nicht über einen virtuellen Host bereitgestellt wurde. Wie Sie diese IP-Adresse am einfachsten herausfinden können — falls Sie sie nicht bereits zur Hand haben — hängt von Ihrer Kubernetes-Umgebung ab. Mit dem folgenden Befehl erhalten Sie den Endpunkt des API-Servers als IP-Adresse und Port, den Sie als letzten Eintrag unter server in der gekürzten Ausgabe finden:

user@host:~$ kubectl config view
apiVersion: v1
clusters:
  - cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://10.73.42.21:6443
    name: my-kubernetes

Wird der Server über einen DNS-Eintrag bereitgestellt, wird die Ausgabe stattdessen eher so aussehen:

user@host:~$ kubectl config view
apiVersion: v1
clusters:
  - cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://DFE7A4191DCEC150F63F9DE2ECA1B407.mi6.eu-central-1.eks.amazonaws.com
    name: xyz:aws:eks:eu-central-1:150143619628:cluster/my-kubernetes

Wenn Sie die CA Ihres Clusters - wie oben beschrieben - in Checkmk hinterlegt haben, können Sie unter SSL certificate verification den Eintrag Verify the certificate auswählen.

Sollte Ihr Kubernetes API Server nur über einen Proxy erreichbar sein oder für die Verbindung spezielle Timeouts benötigt werden, können Sie diese unter HTTP proxy und TCP timeouts eintragen.

Als Nächstes haben Sie die Wahl das Monitoring Ihres Kubernetes-Clusters mit Nutzungsdaten anzureichern, welche der Checkmk Cluster Collector einsammelt. Dazu müssen Sie unter Collector NodePort/Ingress endpoint Protokoll, URL und Port des Cluster Collectors angeben. Wenn Sie die Einrichtung mit unseren Manifesten vorgenommen haben, ist der Port hier standardmäßig 30035. Falls Sie den Port in der Datei service.yaml angepasst haben, so ändern Sie den Port hier entsprechend. Die URL bzw. die IP-Adresse des Nodeport sollte sich über die Beschreibung des Pods cluster-collector herausfinden lassen. Führen Sie dazu einfach den folgenden Befehl aus und schauen Sie in der Ausgabe in der Zeile nach, die mit Node: beginnt:

user@host:~$ kubectl describe pod $(kubectl get pods --no-headers -o custom-columns=":metadata.name") | grep -A5 Name:.*cluster-collector
Name:         cluster-collector-5b7c8468cf-5t5hj
Namespace:    checkmk-monitoring
Priority:     0
Node:         minikube/172.16.23.2
Start Time:   Wed, 03 Mar 2022 20:54:45 +0100
Labels:       app=cluster-collector

Mit den Optionen Collect information about…​ können Sie nun endgültig auswählen, welche Objekte innerhalb Ihres Cluster denn überwacht werden sollen. Unsere Vorauswahl deckt hier die relevantesten Objekte ab. Sollten Sie sich dazu entscheiden auch die Pods of CronJobs zu überwachen, so beachten Sie die Inline-Hilfe zu diesem Punkt.

Zu guter Letzt können Sie noch auswählen, ob Sie nur bestimmte Namespaces innerhalb Ihres Clusters überwachen möchten oder ob explizite Namespaces aus der Überwachung ausgeschlossen werden sollen. Dies legen Sie über die Option Monitor namespaces fest.

Ihre Regel könnte jetzt wie folgt aussehen:

Exemplarisch ausgefüllte Regel für den Kubernetes Spezialagenten.

Wichtig: Unter Conditions > Explicit hosts müssen Sie nun den zuvor angelegten Host eintragen:

Regeln für Spezialagenten müssen, wie hier zu sehen, immer auf explizite Hosts festgelegt werden.

Speichern Sie anschließend die Regel und führen Sie eine Service-Erkennung auf diesem Host durch. Sie werden hier gleich die ersten Services auf Cluster-Ebene sehen:

Exemplarische Ansicht der ersten Service-Erkennung nach Abschluss der Konfiguration.

Aktivieren Sie im Anschluss alle vorgenommenen Änderungen und überlassen Sie ab jetzt der dynamischen Host-Konfiguration die Arbeit. Diese wird schon nach kurzer Zeit alle Hosts für Ihre Kubernetes-Objekte erzeugen.

5. Labels für Kubernetes-Objekte

Checkmk erzeugt Labels für die Kubernetes-Objekte wie Cluster, Deployments oder Namespace während der Service-Erkennung automatisch. Alle Labels zu Kubernetes-Objekten, die Checkmk automatisch erzeugt, beginnen mit cmk/kubernetes/. Ein Pod erhält beispielsweise immer ein Label der Node (cmk/kubernetes/node:mynode), ein Label, welches eben zeigt, dass es sich bei diesem Objekt um einen Pod handelt (cmk/kubernetes/object:pod) und ein Label für den Namespace (cmk/kubernetes/namespace:mynamespace). So lassen sich in der Folge sehr einfach Filter und Regeln für alle Objekte gleichen Typs bzw. im gleichen Namespace erstellen.

6. Hardware-/Software-Inventur

Die Kubernetes-Überwachung von Checkmk unterstützt auch die HW-/SW-Inventur.

Exemplarische Ansicht der Hardware- und Software-Inventur eines Pods

7. Checkmk entfernen

Wenn Sie Checkmk über unsere Manifeste in Ihrem Cluster bereitgestellt haben, können Sie erstellten Accounts, Service und so weiter genauso leicht wieder entfernen, wie Sie eingerichtet wurden. Gehen Sie dazu wieder in das Verzeichnis, in dem die YAML-Dateien liegen, und führen Sie den folgenden Befehl aus:

user@host:~$ kubectl delete -f .
namespace "checkmk-monitoring" deleted
serviceaccount "checkmk" deleted
clusterrole.rbac.authorization.k8s.io "checkmk-metrics-reader" deleted
clusterrolebinding.rbac.authorization.k8s.io "checkmk-metrics-reader-binding" deleted
serviceaccount "cluster-collector" deleted
clusterrolebinding.rbac.authorization.k8s.io "checkmk-cluster-collector" deleted
clusterrolebinding.rbac.authorization.k8s.io "checkmk-token-review" deleted
deployment.apps "cluster-collector" deleted
serviceaccount "node-collector-machine-sections" deleted
serviceaccount "node-collector-container-metrics" deleted
clusterrole.rbac.authorization.k8s.io "node-collector-container-metrics-clusterrole" deleted
podsecuritypolicy.policy "node-collector-container-metrics-podsecuritypolicy" deleted
clusterrolebinding.rbac.authorization.k8s.io "node-collector-container-metrics-cluterrolebinding" deleted
daemonset.apps "node-collector-container-metrics" deleted
daemonset.apps "node-collector-machine-sections" deleted
service "cluster-collector" deleted
service "cluster-collector-nodeport" deleted
Auf dieser Seite