1. Einleitung
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.
1.1. Einstieg in das Kubernetes-Monitoring
Für einen Einstieg in das neue Monitoring von Kubernetes empfehlen wir unsere beiden Videos Kubernetes Monitoring with Checkmk und Detecting issues and configuring alerts for Kubernetes clusters.
1.2. Aufbau der Monitoring-Umgebung
Da es in Kubernetes-Clustern sehr schnell auch zu größeren Veränderungen kommen kann, was die Anzahl und Verortung der einzelnen Komponenten angeht, empfehlen wir für das Monitoring Ihrer Kubernetes-Umgebung eine eigene Instanz zu erstellen. Diese können Sie dann wie üblich über das verteilte Monitoring an Ihre Zentralinstanz anbinden.
1.3. Ablauf des Kubernetes-Monitorings in Checkmk
Checkmk überwacht Ihre Kubernetes-Cluster auf zwei Wegen:
Grundlegende Informationen holt sich der Kubernetes-Spezialagent einfach über den API-Server Ihres Clusters ab. Hierüber lassen sich bereits die Zustände von Nodes und Containern abrufen. Auch die meisten Metadaten über Ihre Pods und Deployment werden auf diesem Wege gewonnen.
Für ein umfängliches Monitoring fehlt bis zum diesem Punkt allerdings noch etwas. Die Fragen, wie viel Last beispielsweise ein bestimmtes Deployment auf der CPU erzeugt, oder wie viel Arbeitsspeicher ein DaemonSet gerade bindet, lassen sich so nicht beantworten.
An dieser Stelle kommen unser Checkmk Node Collector und unser Checkmk Cluster Collector ins Spiel.
Diese sind ein unerlässlicher Teil des Kubernetes-Monitorings in Checkmk.
Ein nicht unerheblicher Teil der folgenden Ausführungen drehen sich dann auch darum, diese zu installieren und einzurichten.
Auch ist die Verwendung der Kubernetes-Dashboards in den 
Checkmk Enterprise Editions nur dann sinnvoll, wenn Node und Cluster Collector hierfür Daten zur Auslastung liefern können.
1.4. Unterschiede zum übrigen Monitoring in Checkmk
Beim Monitoring von Pods und Replicas in Ihren Kubernetes-Clustern kommt es mitunter wesentlich häufiger zu Statusänderungen bzw. zu Verzögerungen. Um dem Rechnung zu tragen, ändern die Checks bei bestimmten Zuständen dieser Objekte erst nach 10 Minuten ihren Status in Checkmk.
1.5. 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. 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.
2.1. Helm-Repository einrichten
Die Installation des Kubernetes-Monitoring geschieht mit Hilfe des Tools helm.
Helm eignet sich auch für weniger versierte Nutzer und standardisiert die Verwaltung der Konfigurationen.
Helm ist eine Art Paketmanager für Kubernetes.
Sollten Sie Helm noch nicht verwenden, so erhalten Sie es im Regelfall über die Paketverwaltung Ihrer Linux-Distribution oder über die Website des Helm-Projekts.
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_agentWir aktualisieren unsere Helm-Charts immer dann, wenn neue Gegebenheiten in Kubernetes dies erfordern.
Deshalb lohnt sich von Zeit zu Zeit eine Prüfung, ob im Repository neue Versionen verfügbar sind.
Wenn Sie ihre lokale Kopie unseres Repositories, wie in dem vorherigen Befehl, mit tribe29 bezeichnet haben, können Sie sich mit dem folgenden Befehl alle im Repository vorliegenden Versionen der Charts anzeigen lassen:
user@host:~$ helm search repo tribe29 --versions
NAME CHART VERSION APP VERSION DESCRIPTION
tribe29/checkmk 1.2.0 1.2.0 Helm chart for Checkmk - Your complete IT monit...
tribe29/checkmk 1.1.0 1.1.0 Helm chart for Checkmk - Your complete IT monit...
tribe29/checkmk 1.0.1 1.0.1 Helm chart for Checkmk - Your complete IT monit...
tribe29/checkmk 1.0.0 1.0.0 Helm chart for Checkmk - Your complete IT monit...Wenn eine neue Version für Sie vorliegt, können Sie das Update mit helm repo update durchführen.
2.2. Konfiguration auf Ihre Umgebung anpassen
Da wir im Vorfeld nicht wissen können, wie Ihr Kubernetes-Cluster aufgebaut ist, haben wir die sicherste Variante gewählt, wie die Cluster Collectors gestartet werden: Sie stellen standardmäßig keine Ports bereit, die von außen erreicht werden können. Damit Sie später auf die Collectors zugreifen können, müssen Sie diese Einstellungen an Ihr jeweiliges Cluster anpassen.
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.
Um bestimmte Parameter über alle Konfigurationen hinweg selbst bestimmen zu können, geben Sie dabei eine Steuerdatei mit, die sogenannte values.yaml.
Um eine solche values.yaml zu erstellen bieten sich zwei Wege an.
Sie können entweder die von uns in den Helm-Charts mitgelieferte Datei extrahieren und anpassen oder Sie erstellen eine minimale Version einfach selbst.
Immer wenn Sie Änderungen an dieser Datei in Ihrem Cluster bereitstellen möchten, können Sie erneut den später folgenden Befehl zur Installation der Helm Chart verwenden.
Minimale values.yaml selbst anlegen
Sie können eine values.yaml anlegen, in die Sie nur die Werte eintragen, die Sie auch ändern wollen.
In unserer Helm Chart ist der Servicetyp des Cluster Collectors bspw. auf ClusterIP voreingestellt.
Wenn Sie nun ausschließlich diesen Servicetyp auf NodePort und den Port auf 30035 umstellen möchten, genügt es auch eine values.yaml wie folgt zu erzeugen:
user@host:~$ echo 'clusterCollector: {service: {type: NodePort, nodePort: 30035}}' > values.yamlEine Aktivierung von Ingress könnte bspw. so aussehen:
user@host:~$ echo 'clusterCollector: {ingress: { enabled: true }}' > values.yamlvalues.yaml aus Helm-Charts extrahieren
Die vollständige von uns mitgelieferte values.yaml lässt sich ganz einfach mit dem folgenden Befehl extrahieren:
user@host:~$ helm show values tribe29/checkmk > values.yamlDie so erzeugte Datei können Sie nun nach Ihren Bedürfnissen anpassen und bei der Installation oder einem späteren Upgrade mit dem Parameter -f values.yaml an helm übergeben.
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 Parameter enabled setzen Sie auf true.
Die restlichen Parameter 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.localKommunikation 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: 30035Cluster Collector auf HTTPS umstellen
Wenn Sie die Kommunikation mit dem und zwischen den Cluster Collectors auf HTTPS umstellen möchten, müssen Sie hierzu ebenfalls Änderungen in der Datei values.yaml vornehmen.
Folgend sehen Sie den Abschnitt in unserer mitgelieferten values.yaml den Sie bearbeiten müssen, um HTTPS zu aktivieren:
tlsCommunication:
enabled: false
verifySsl: false
# clusterCollectorKey: |-
# -----BEGIN EC PRIVATE KEY-----
# XYZ
# -----END EC PRIVATE KEY-----
# clusterCollectorCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----
# checkmkCaCert: |-
# -----BEGIN CERTIFICATE-----
# XYZ
# -----END CERTIFICATE-----In den Zeilen, die mit enabled bzw. verifySsl beginnen, müssen Sie false durch true ersetzen.
Entfernen Sie als nächstes vor den drei Abschnitten clusterCollectorKey, clusterCollectorCert und checkmkCaCert die Rautezeichen und fügen Sie dahinter die entsprechenden Daten ein.
Ob Sie hierfür selbst-signierte Zertifikate nutzen oder sich Zertifikate von einer Certificate Authority (CA) besorgen, dürfte in erster Linie durch Ihre Organisation vorgegeben sein.
Bitte beachten Sie dabei nur die folgenden Voraussetzungen, die die Zertifikate erfüllen müssen:
Das CA-Zertifikat muss den Host-Namen bzw. den Namen des Ingress als FQDN enthalten.
Beim Server-Zertifikat muss der FQDN dem folgenden Muster entsprechen:
<service_name>.<namespace>.cluster.localIm Abschnitt
[ v3_ext ]der Konfigurationsdatei für die Erzeugung Ihres Certificate Signing Requests muss dersubjectAltNamedem folgenden Muster entsprechen:subjectAltName: DNS:<service_name>.<namespace>.cluster.local, IP:<service ip>
Eigenen Service-Account verwenden
Mithilfe unserer Helm-Charts würde standardmäßig ein Service-Account in Ihrem Cluster erstellt.
Wenn Sie bereits über einen passenden Service-Account verfügen, genügt es, wenn Sie diesen in der values.yaml hinzufügen und die Erstellung eines neuen Accounts unterbinden.
serviceAccount:
create: false
name: "myserviceaccount"Pod Security Policies und Network Policies
Die Policies PodSecurityPolicy (kurz: PSP) und NetworkPolicy sind in erster Linie aus Gründen der Kompatibilität in unserer Helm-Chart enthalten.
Die PSP ist hierbei standardmäßig aktiviert — denn sie schadet nicht, selbst wenn sie nicht verwendet wird.
Sollten Sie allerdings noch die PSP in Ihrem Cluster einsetzen, ist es unbedingt erforderlich, dass diese Option in der values.yaml aktiviert bleibt.
Der entsprechende Abschnitt sieht folgendermaßen aus:
rbac:
pspEnabled: trueDa die PSP gerade auf dem Weg des Dodos wandeln, wird diese Einstellung früher oder später aus unserer Chart entfernt.
Ähnliches gilt für die NetworkPolicy.
Wenn Sie diese in Ihrem Cluster einsetzen, müssen die Stelle in der values.yaml von enabled: false auf enabled: true umstellen.
Bitte beachten Sie in diesem Fall die folgende Dokumentation innerhalb der values.yaml, um die NetworkPolicy korrekt zu konfigurieren.
## ref: https://kubernetes.io/docs/concepts/services-networking/network-policies/
networkPolicy:
# keep in mind: your cluster network plugin has to support NetworkPolicies, otherwise they won't have any effect
enabled: false
# specify ipBlock cidrs here to allow ingress to the cluster-collector
# this is required for the checkmk servers to be able to scrape data from checkmk, so include the resprective ip range(s) here
allowIngressFromCIDRs: []
# - 127.0.0.1/32 # e.g. Checkmk Server
# - 127.0.0.1/24 # e.g. Metallb speakers
# the cluster-collector needs to be able to contact the kube-apiserver
# you have three options here to choose from, depending on your cluster setup:
# 1) if your apiserver resides outside the cluster, resp. you have a kubernetes endpoint available (check via "kubectl -n default get ep kubernetes")
# we can make use of helm lookup to automatically inject the endpoińt (cidr + port) here.
# This is the most comfortable one, just note that helm lookup won't work on a "helm template" or "helm diff" command.
# (see also: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function)
# 2) similar to 1) you can also specify the "ipBlockCidr" directly. Make sure to disable "enableCidrLookup", and also fill the "port".
# 3) if the apiserver resides inside the cluster, disable "enableCidrLookup", unset "ipBlockCidr", and fill the "labelSelectors" section
# with the name of the namespace where the kube-apiserver is availabe, and the label key and label value that defines your kube-apiserver pod.
egressKubeApiserver:
enableCidrLookup: true
# ipBlockCidr: 172.31.0.3/32
# port: 6443
# labelSelectors:
# namespace: kube-system
# key: app
# value: kube-apiserver2.3. Helm-Charts installieren
Nachdem Sie die values.yaml angepasst oder eine eigene erstellt haben, installieren Sie mit dem folgenden Kommando alle notwendigen Komponenten in Ihrem Cluster, um es in Checkmk überwachen zu können:
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease tribe29/checkmk -f values.yamlDa das Kommando nicht selbsterklärend ist, bieten wir Ihnen nachfolgend eine Erläuterung zu den einzelnen Optionen:
| Befehlsteil | Bedeutung |
|---|---|
| Dieser Teil ist der Basisbefehl, um dem Kubernetes-Cluster die Konfiguration zu übermitteln. |
| 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. |
| Diese Option bestimmt den Namespace, zu dem die Konfiguration hinzugefügt werden soll. |
|
|
| Der erste Teil dieser Option beschreibt das Repository, welches Sie 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. |
| 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 |
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.
Ausgabe der Helm-Charts
Als nächstes steht nun die Einrichtung in Checkmk an.
Um Ihnen diese Einrichtung so einfach wie möglich zu machen, haben wir den Output unserer Helm-Charts mit einer ganzen Reihe an Kommandos ausgestattet.
Dieser Output passt sich auch automatisch an die von Ihnen eingestellten Werte in der Datei values.yaml an.
Verwenden Sie also den NodePort, bekommen Sie hier unter anderem die Befehle um IP und Port des NodePort anzuzeigen.
Verwenden Sie stattdessen Ingress, wird die Ausgabe entsprechend angepasst.
Im Folgenden zeigen wir die - leicht gekürzte - Ausgabe nach erfolgreicher Installation bei der Verwendung des NodePort:
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease tribe29/checkmk -f values.yaml Release "myrelease" has been upgraded. Happy Helming! NAME: myrelease LAST DEPLOYED: Sat Dec 16 19:00:11 2022 NAMESPACE: checkmk-monitoring STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: You can access the checkmk: myrelease-checkmk-cluster-collector.checkmk-monitoring With the token of the service account namedcluster-collectorvia: NodePort: export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector); export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}"); echo http://$NODE_IP:$NODE_PORT # Cluster-internal DNS ofcluster-collectormyrelease-checkmk-checkmkin the namespacecheckmk-monitoringyou can now issue queries against thecluster-collector. Run the following to fetch its token and the ca-certificate of the cluster: export TOKEN=$(kubectl get secret $(kubectl get serviceaccount myrelease-checkmk-checkmk -o=jsonpath='{.secrets[].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode); export CA_CRT="$(kubectl get secret $(kubectl get serviceaccount myrelease-checkmk-checkmk -o=jsonpath='{.secrets[].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)"; # Note: Quote the variable when echo'ing to preserve proper line breaks:echo "$CA_CRT" To test access you can run: curl -H "Authorization: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
Kopieren Sie aus dieser Ausgabe einfach die farblich markierten Zeilen und führen Sie die Befehle aus.
Der erste Block zeigt Ihnen Informationen zum NodePort an:
user@host:~$ export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
user@host:~$ export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
user@host:~$ echo \http://$NODE_IP:$NODE_PORT
http://10.184.38.103:30035Genau diese Adresse müssen Sie in Checkmk später in der Kubernetes-Regel im Feld Collector NodePort / Ingress endpoint eintragen.
Mit den Befehlen aus dem nächsten Block erhalten Sie sowohl den Token and auch das Zertifikat des Service-Accounts.
Die Daten werden so in den Umgebungsvariablen TOKEN und CA_CRT gespeichert.
Achten Sie bei der Ausgabe der Variable CA_CRT unbedingt darauf diese in Hochkommata einzuschließen, da ansonsten die wichtigen Zeilenumbrüche des Zertifikats verloren gehen.
user@host:~$ export TOKEN=$(kubectl get secret $(kubectl get serviceaccount myrelease-checkmk-checkmk -o=jsonpath='{.secrets[].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode);
user@host:~$ export CA_CRT="$(kubectl get secret $(kubectl get serviceaccount myrelease-checkmk-checkmk -o=jsonpath='{.secrets[].name}' -n checkmk-monitoring) -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
user@host:~$ echo $TOKEN
eyJhbGciOiJSUzI1NiIsImtpZCI6InR6VXhGSU ...
user@host:~$ echo "$CA_CRT"
-----BEGIN CERTIFICATE-----
MIIBdjCCAR2gAwIBAgIBADAKBggqhkjOPQQDAjAjMSEwHwYDVQQDDBhrM3Mtc2Vy
dmVyLWNhQDE2NjIxNDc5NTMwHhcNMjIwOTAyMTk0NTUzWhcNMzIwODMwMTk0NTUz
...
-----END CERTIFICATE-----Bei der Einrichtung in Checkmk müssen Sie sowohl den Token als auch das das Zertifikat hinterlegen. Lassen Sie die Shell mit diesen Informationen geöffnet oder kopieren Sie Token und Zertifikat an einen Ort, an dem Sie während der folgenden Einrichtung in Checkmk zugreifen können.
Wenn Sie die beiden vorherigen Export-Befehle ausgeführt haben, können Sie mit dem letzten Befehl prüfen, ob die Einrichtung erfolgreich war:
curl -H "Authorization: Bearer $TOKEN" http://$NODE_IP:$NODE_PORT/metadata | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1815 100 1815 0 0 126k 0 --:--:-- --:--:-- --:--:-- 126k
{
"cluster_collector_metadata": {
"node": "mynode",
"host_name": "myrelease-checkmk-cluster-collector-58f97df9c9-mdhsw",
"container_platform": {
"os_name": "alpine",
"os_version": "3.15.4",
"python_version": "3.10.4",
"python_compiler": "GCC 10.3.1 20211027"
},
"checkmk_kube_agent": {
"project_version": "1.0.1"
}
}
...Am Anfang der stark gekürzten Ausgabe sehen Sie beispielsweise die Version des Cluster Collectors. Weiter unten würden dann noch Metadaten zu allen Nodes in diesem Cluster folgen.
3. 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:
3.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.
Wie Sie sich das benötigte Passwort anzeigen lassen können, steht in der Ausgabe der Helm-Charts.
Fügen Sie das Passwort in den Checkmk-Passwortspeicher ein mit Setup > General > Passwords > Add password z.B. unter der ID und dem Titel My Kubernetes Token:
3.2. CA-Zertifikat 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.
Wie Sie sich das benötigte Zertifikat anzeigen lassen können, steht ebenfalls in der Ausgabe der Helm-Charts.
Kopieren Sie hier alles inklusive der Zeilen BEGIN CERTIFICATE und END CERTIFICATE und fügen Sie das Zertifikat im Setup-Menü unter Setup > General > Global settings > Site management > Trusted certificate authorities for SSL hinzu:
3.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 unbedingt auf No IP.
3.4. Dynamische Host-Konfiguration einrichten
Um eine Trennung zwischen den Objekten verschiedener Kubernetes-Cluster zu gewährleisten, kann es sich anbieten über Setup > Hosts > Add folder pro Cluster einen Ordner anzulegen, in welchem die dynamische Host-Konfiguration automatisch alle Hosts eines Clusters anlegen kann.
Einen solchen Ordner zu erzeugen bzw. zu nutzen ist aber optional.
Als nächstes richten Sie in den Checkmk Enterprise Editions einen Konnektor für die anfallenden Piggyback-Daten ein:
mit Setup > Hosts > Dynamic host management > Add connection.
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:
3.5. Piggyback-Daten in der Raw Edition verarbeiten
In der Raw Edition von Checkmk müssen Sie die Hosts für die anfallenden Piggyback-Daten manuell erstellen.
Weil hier in einem Kubernetes-Cluster eine große Zahl an Piggyback-Hosts entstehen dürften, empfiehlt sich die Verwendung unseres Skript find_piggy_orphans im Verzeichnis ~/share/doc/check_mk/treasures/ Ihrer Checkmk-Instanz.
3.6. Periodische Service-Erkennung anpassen
Standardmäßig führt Checkmk alle zwei Stunden eine Service-Erkennung durch und zeigt das Ergebnis dieser Erkennung im Service Check_MK Discovery an.
Sie finden diese Einstellung im Regelsatz Periodic service discovery.
Im Kontext von Kubernetes empfehlen wir eine Regel für alle Hosts mit dem Label cmk/kubernetes:yes zu erstellen.
Dieses Label erhält nämlich jeder Host der Kubernetes-Objekte repräsentiert automatisch von Checkmk.
Sie sollten hier ein kürzeres Intervall für die Service-Erkennung wählen und auch die Option Automatically update service configuration aktivieren.
Die Einstellungen im folgenden Screenshot sind nur exemplarisch.
Was für Ihre Cluster sinnvoll ist, müssen Sie von Fall zu Fall entscheiden.
Um diese Regel auf alle Hosts Ihrer Cluster zu beschränken genügt es bei den Conditions unter Host labels cmk/kubernetes:yes einzutragen.
Wollen Sie jedoch für verschiedene Cluster auch verschiedene Regeln erstellen, verwenden Sie hier einfach das jeweilige Cluster-spezifische Label.
Diese Labels haben immer die Form cmk/kubernetes/cluster:mycluster.
3.7. 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. Erstellen Sie mit Add rule eine neue Regel.
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.
Der Host-Name eines Pods könnte dann beispielsweise pod_mycluster_kube-system_svclb-traefik-8bgw7 lauten.
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 nur notwendig, wenn der Dienst nicht über einen virtuellen Host bereitgestellt wird.
Wie Sie diese 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 in der Zeile server:
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-kubernetesDie tatsächlich Ausgabe von kubectl config view variiert allerdings sehr stark.
Wird hier in der Zeile server auch ein Port angegeben, so fügen Sie diesen unbedingt auch in der Regel ein.
Wenn Sie diese Anleitung bisher Schritt für Schritt befolgt haben und das CA-Zertifikat Ihres Clusters - wie oben beschrieben - in Checkmk hinterlegt haben, wählen Sie unter SSL certificate verification den Eintrag Verify the certificate aus.
Als Nächstes haben Sie die Wahl das Monitoring Ihres Kubernetes-Clusters mit Nutzungsdaten anzureichern, welche der Checkmk Cluster Collector einsammelt. Wir wiederholen es an dieser Stelle ein weiteres Mal, um die Wichtigkeit zu unterstreichen: Die Einrichtung des Cluster Collectors ist für ein vollumfängliches Monitoring Ihrer Cluster absolut unerlässlich. Nur so erhalten Sie wichtige Daten wie CPU- und Speicherauslastung und werden über die Dateisysteme der einzelnen Komponenten informiert.
Aktivieren Sie also die Option Enrich with usage data from Checkmk Cluster Collector und geben Sie den Endpunkt des NodePorts bzw. des Ingress an. Wie Sie sich diesen Endpunkt erneut anzeigen lassen können, steht in der Ausgabe der Helm-Charts.
Mit den Optionen Collect information about… können Sie nun noch auswählen, welche Objekte innerhalb Ihres Cluster ü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.
Mit den nächsten beiden Auswahlmöglichkeiten, können Sie die zu überwachenden Objekte weiter eingrenzen. Falls Sie sich nur für die Objekte aus bestimmten Namespaces interessieren, stellen Sie dies entsprechend unter Monitor namespaces ein. Hier können Sie entweder einzelne Namespaces eintragen, die überwacht werden sollen, oder aber einzelne Namespaces explizit vom Monitoring ausschließen.
Mit der Option Cluster resource aggregation können Sie Nodes benennen, welche keine Ressourcen für die Arbeitslast Ihres Clusters zur Verfügung stellen.
Diese Nodes sollten aus der Berechnung der zur Verfügung stehenden Ressourcen ausgenommen werden.
Ansonsten besteht die Gefahr, dass Kapazitätsengpässe nicht erkannt werden.
Standardmäßig nehmen wir daher bereits die Nodes control-plane und infra aus der Berechnung heraus.
Als letzte Option können Sie noch sogenannte Annotations aus Kubernetes importieren. In Checkmk werden diese Annotations zu Host-Labels und können somit als Bedingungen in Regeln weiterverwendet werden. Welche Annotations importiert werden sollen, können Sie über reguläre Ausdrücke festlegen. Konsultieren Sie an dieser Stelle erneut die ausführliche Inline-Hilfe.
Hinweis: Die Option Import all valid annotations bieten wir an dieser Stelle nur der Vollständigkeit halber an. Wir raten davon ab, einfach blind alle Annotations zu importieren, weil hierdurch mitunter ein sehr großer Berg nutzloser Labels in Checkmk erzeugt wird.
Wichtig: Unter Conditions > Explicit hosts müssen Sie nun den zuvor angelegten Host eintragen:
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:
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.
4. 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.
5. Dashboards und Ansichten
5.1. Kubernetes-Dashboards
Die Enterprise Editions von Checkmk werden mit sechs eingebauten Dashboards für Kubernetes ausgeliefert.
Um diese Dashboards sinnvoll verwenden zu können, ist es notwendig, dass unser Cluster Collector installiert und konfiguriert ist.
Im einzelnen heißen diese Dashboards:
Kubernetes
Kubernetes Cluster
Kubernetes DaemonSet
Kubernetes Deployment
Kubernetes Namespace
Kubernetes StatefulSet
Der Einstieg geschieht dabei immer über das Dashboard Kubernetes, welches Sie über Monitor > Applications > Kubernetes erreichen:
Im Dashboard Kubernetes werden auf der linken Seite alle Ihre überwachten Kubernetes-Cluster aufgelistet. Diese Auflistung der Cluster ist auch Ihr Einstieg um sich tiefer in die Kubernetes-Dashboards zu bohren. Mit einem Klick auf den Namen eines Clusters gelangen Sie in das Dashboard Kubernetes Cluster des angewählten Clusters. Im Dashboard Kubernetes Cluster führt ein Klick auf den jeweiligen Namen dann in die übrigen kontextabhängigen Dashboards:
5.2. Hardware-/Software-Inventur
Die Kubernetes-Überwachung von Checkmk unterstützt auch die HW-/SW-Inventur. Wenn Sie beispielsweise in dem obigen Cluster-Dashboard auf den großen Namen des Clusters (hier: mycluster) klicken, gelangen Sie zur Inventur des Clusters.
Auf dem gleichen Weg, also über die Boxen mit den großen Namen der Objekte, gelangen Sie auch in den anderen Dashboards zur Inventur des jeweiligen Objekts. Im folgenden Beispiel sehen Sie die HW-/SW-Inventur eines Pods:
6. Prüfung der Installation
Im Abschnitt Ausgabe der Helm-Charts haben Sie bereits die erste Möglichkeit kennengelernt, um die erfolgreiche Installation der Komponenten für das vollständige Monitoring von Kubernetes zu prüfen. In der GUI von Checkmk können Sie ebenfalls an einigen Stellen die erfolgreiche Installation und Konfiguration prüfen.
Die wichtigsten Services sind hier sicherlich Kubernetes API und Cluster Collector. Diese müssen auf dem von Ihnen erstellten Cluster-Host vorhanden sein und sollten auch bestimmte Informationen anzeigen.
Der Service Kubernetes API sollte im Normalfall unter Summary Live, Ready vermelden. Der Service Cluster Collector muss die Versionsnummer des installierten Cluster Collectors anzeigen. Ist eins von beidem nicht der Fall, müssen Sie die Installation der Helm-Charts und die Konfiguration des Spezialagenten überprüfen.
Weitere Möglichkeiten zur Prüfung bieten in den Checkmk Enterprise Editions die Cluster-Dashboards.
Im Dashboard Kubernetes können Sie bereits sehr früh erkennen, ob der Cluster Collector in einem Cluster läuft und Daten sammelt. Wenn die Spalten CPU resources und Memory resources keine Daten enthalten, ist dies bereits ein starker Indikator dafür, dass der Cluster Collector nicht ordnungsgemäß läuft. Bei korrekter Einrichtung sollte das Dashboard Kubernetes in etwa so aussehen:
Wenn Sie hier nun auf den Namen des Clusters klicken, landen Sie im Dashboard Kubernetes Cluster des jeweiligen Clusters. Hier sollten die drei Boxen Primary datasource, Cluster collector und API health grün sein und OK anzeigen.
7. Kubernetes in Rancher-Installationen
7.1. Service-Account anlegen
Mit Rancher ist die Einrichtung des Monitorings in Checkmk der oben beschriebenen Variante sehr ähnlich. Auch hier benötigen Sie den Service-Account, damit Checkmk auf das Cluster zugreifen kann. Den Account erstellen Sie direkt in der Rancher-Weboberfläche, wo Sie anschließend auch dessen Token und Zertifikat finden, die Sie wiederum in Checkmk importieren.
Navigieren Sie in Rancher zunächst nach Global > Security > Roles > Clusters, um eine neue Rolle checkmk anzulegen:
Der Einfachheit halber klonen Sie die Rolle Cluster Owner:
Entziehen Sie der geklonten Rolle unter Grant Resources die Rechte Create, Delete, Patch und Update:
Erstellen Sie nun einen neuen Rancher-Benutzer checkmk unter Global > Users > Add User.
Bei Global Permissions wählen Sie die Option User-Base, um dem Benutzer nur die nötigsten Leserechte einzuräumen:
7.2. Cluster-Rolle zuordnen
Wechseln Sie nun zu Ihrem Cluster und klicken Sie im Cluster-Menü oben rechts auf Edit. Hier können Sie über Add Member den eben angelegten Benutzer checkmk mit der zugehörigen Rolle checkmk zum Cluster hinzufügen:
7.3. Weiteres Vorgehen
Melden Sie sich anschließend mit dem neuen Benutzer bei Rancher an, rufen Sie das Cluster auf und klicken Sie auf Kubeconfig File. Hier finden Sie drei Angaben, die Sie für das Monitoring in Checkmk benötigen:
clusters>cluster>server: URL-/Pfadangabe für die Checkmk-Regelclusters>cluster>certificate-authority-data: Das base64-kodierte Zertifikatusers>user>token: Zugangspasswort in Form eines Bearer Tokens
Das Zertifikat müssen Sie noch dekodieren, auf der Kommandozeile beispielsweise mit base64 --decode oder in einem der vielen Online-Dienste.
Die Einrichtung in Checkmk entspricht ab hier dem Vorgehen bei purer Kubernetes-Nutzung ab dem Abschnitt Monitoring in Checkmk einrichten.
8. Monitoring-Komponenten aus Cluster entfernen
Wenn Sie Checkmk über unsere Helm-Charts in Ihrem Cluster bereitgestellt haben, können Sie die erstellten Accounts, Services, Pods und Node Ports genauso leicht wieder entfernen, wie Sie sie eingerichtet haben. Deinstallieren Sie dafür einfach das Release, welches Sie mithilfe unserer Charts installiert haben.
Sollten Sie sich beim Namen des Releases unsicher sein, lassen Sie sich zuerst alle Helm-Releases in allen Namespaces anzeigen:
user@host:~$ helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myrelease checkmk-monitoring 1 2022-08-15 19:00:42.318666784 +0200 CEST deployed checkmk-1.0.1 1.0.1Wie in der obigen Beispielausgabe sollten Sie hier ein Release finden, welches in der Spalte CHART einen Hinweis auf Checkmk enthält.
Entfernen Sie dieses Release anschließend - unter Angabe des korrekten Namespaces - mit folgendem Befehl:
user@host:~$ helm uninstall myrelease -n checkmk-monitoring
release "myrelease" uninstalled