Kubernetes überwachen

Um einen Kubernetes-Cluster in Checkmk einzurichten, benötigen Sie zunächst einen Service-Account und eine damit verbundene Clusterrolle in Kubernetes, damit Checkmk auf die API zugreifen kann. Wir stellen für Sie als Schablone die Datei check_mk_rbac.yaml bereit. Diese finden Sie den „Treasures“ im Verzeichnis share/doc/check_mk/treasures/kubernetes oder online hier. Deren Anfang sieht etwa so aus:

Wir verwenden hier als Name und Namespace jeweils check-mk.

Spielen Sie diese Datei auf Ihrem Kubernetes-Cluster mit dem Befehl kubectl ein:

Falls Sie die Google Kubernetes-Engine verwenden, kann es sein, dass Sie den Fehler "Error from server (Forbidden): error when creating "check_mk_rbac.yaml": bekommen. In diesem Fall müssen Sie zuvor die Berechtigungen Ihres Benutzers erweitern. Das geht mit folgendem Befehl (wobei Sie MYNAME durch Ihren Loginnamen bei Google ersetzen):

Wenn alles gut gegangen ist, können Sie den neuen Service-Account mit kubectl get serviceaccounts abfragen:

Dort finden Sie dann auch den Namen des zugehörigen Secrets. Dies hat die Form „check-mk-token-`ID“ (hier im Beispiel `check-mk-token-z9hbp). Die ID für das Secret wird von Kubernetes automatisch generiert. Den Inhalt des Secrets können Sie anschließend mit get secrets abfragen:

In der Ausgabe ist unter anderem das base64-kodierte CA-Zertifikat (ca.crt) und das base64-kodierte Token (token) für den Account enthalten. Sie können das Zertikat aus der Ausgabe von get secret z.B. mit folgendem Befehl ausschneiden und gleich in die Form umwandeln, die Sie für den Import in Checkmk benötigen:

Damit Checkmk dem CA-Zertifikat von Kubernetes vertraut, müssen Sie dieses in WATO unter Global Settings > Site Management > Trusted certificate authorities for SSL hinzufügen.

Ohne den korrekten Import der CA wird später der Checkmk-Service des Kubernetes-Clusters mit bad handshake und certificate verify failed fehlschlagen:

Das Token des Service-Accounts können Sie nun am besten im Passwortspeicher von WATO 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 an.

Folgende Befehlszeile schneidet das Passwort direkt aus der Ausgabe von get secrets aus:

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 auf Clipboard kopiert (also als ob Sie das mit der Maus kopiert hätten):

Tipp: Falls Sie das Kommandozeilenbwerkzeug jq installiert haben, geht das Ganze etwas einfacher. jq ist z.B. bei Debian/Ubuntu im gleichnamigen Paket. Es ist ein Programm, das strukturiert auf JSON-Daten zugreifen kann. Hiermit lautet die Befehlszeile dann:

Das „Passwort“ ist wirklich so lang. Fügen Sie das z.B. unter der ID kubernetes in den Passwortspeicher ein:

Die Überwachung von Checkmk geschieht in zwei Ebenen. Der Kubernetes-Cluster selbst wird als ein Host überwacht. Für die einzelnen Kubernetes-Nodes verwenden wir das Piggyback-Prinzip. Das bedeutet, dass jeder Node als ein eigener Host in Checkmk überwacht wird. Die Monitoring-Daten dieser Hosts werden aber nicht separat von Kubernetes abgerufen, sondern aus den Daten vom Kubernetes-Cluster abgezweigt.

Da Kubernetes nicht über den normalen Checkmk-Agenten abgefragt werden kann, benötigen Sie dafür den Kubernetes-Spezialagenten, welcher auch als Datenquellenprogramm bezeichnet wird. Hierbei kontaktiert Checkmk den Zielhost nicht wie üblich über TCP Port 6556, sondern ruft stattdessen ein Hilfsprogramm auf, welches mit dem Zielsystem über die anwendungsspezifische API von Kubernetes kommuniziert.

Das Vorgehen ist wie folgt:

Diese Regel finden Sie in WATO unter Host & Service Parameters > Datasource Programs > Kubernetes. In den Eigenschaften der Regel geben Sie entweder das Passwort im Klartext an oder Sie wählen das über den Passwortspeicher aus, falls Sie es vorhin dort abgelegt haben.

Im Normalfall benötigen Sie keine weiteren Angaben. Die Bedeutung der weiteren Optionen erfahren Sie am besten aus der Onlinehilfe.

Wenn Sie jetzt im WATO beim Kubernets-Host die Servicekonfiguration aufrufen (Discovery), sollten Sie bereits einige der Services finden:

Checkmk unterstützt auch die Überwachung von Pods, Services und Deployments. Diese werden jeweils als Host abgebildet. Wir empfehlen, dass Sie diese Hosts durch die ebenfalls neue dynamischen Hostkonfiguration automatisch verwalten lassen.

Die Konfiguration sieht jetzt so aus:

Der Custom URL prefix hat z.B. die Form mykuber01.comp.lan. Wenn Sie diesen nicht angeben, wird Checkmk als Protokoll HTTPS und anstelle eines Hostnamens die IP-Adresse des Kubernetes-Hosts in Checkmk verwenden. Diese neue Konfiguration ermöglicht alternativ HTTP (unsicher) und das Arbeiten mit einem Namen anstelle einer IP-Adresse.

Der Custom path prefix ist ein Pfad, welcher hinten an die URL angehängt wird. Ein Pfadpräfix ist z.B. bei Rancher wichtig, weil dort mehrere Kubernetes-Cluster aufgenommen werden können. Die API eines einzelnen Clusters erreicht man dann z.B. unter /k8s/cluster/mycluster.

Damit auch die Nodes überwacht werden, müssen Sie diese ebenfalls im WATO als Host anlegen. Dies können Sie mit vom Dynamic Configuration Daemon (DCD) erledigen lassen. Oder Sie legen diese einfach von Hand als Hosts an.

Dabei ist es wichtig, dass die Hostnamen im Checkmk exakt mit den Namen der Kubernetesnodes übereinstimmen. Sie können diese Namen einfach aus dem Nodes-Service des Kubernetes-Hosts ablesen.

Übrigens: Mit dem Regelsatz Access to agents > General settings > Hostname translation for piggybacked hosts können Sie recht flexibel Regeln definieren, nach denen Hostnamen, welche in Piggyback-Daten enthalten sind, umgewandelt werden. Somit können Sie in Checkmk Hostnamen verwenden, welche nicht mit den Namen der Nodes übereinstimmen.

Sofern Sie auf den Nodes selbst keinen Checkmk-Agenten installiert haben, müssen Sie den Check_MK Agent auf No agent einstellen.

Checkmk erzeugt Labels für Nodes, Pods, Deployments und Services währed der Service-Erkennung automatisch. Die Labels werden analog zu Docker definiert und haben die Form cmk/kubernetes_object:OBJECT.

OpenShift ist eine von Red Hat entwickelte Produktreihe von Container-Anwendungsplattformen für Cloud-Computing, welche unter anderem auf Kubernetes aufbaut.

Ab Version 1.5.0p13 kann Checkmk auch ein OpenShift-basiertes Kubernetes überwachen. Das Vorgehen ist sehr ähnlich wie oben beschrieben, weicht aber beim Aufsetzen des Clusters für das Monitoring in einigen Details ab. Für das Monitoring können Sie in OpenShift ein eigenes Projekt anlegen. Das get über die Kommandozeile mit:

Die restlichen Schritte für die Aufnahme des Clusters in das Monitoring sind wie am Anfang des Artikels beschrieben. Allerdings benutzen Sie als Kommandozeilenbefehl immer das Tool von Openshift, als oc, anstelle des im Artikel beschriebenen kubectl. (z.B. bei der Abfrage des Serviceaccounts und des Tokens). Die IP-Adresse und den Port des Clusters können Sie sich mit folgendem Befehl ausgeben lassen:

Um den Token für den Benutzer abzurufen, benutzen Sie diesen Befehl. Hier mit dem in diesem Artikel verwendeten Benutzer check-mk:

Mit Rancher ist die Einrichtung des Monitorings in Checkmk grundsätzlich identisch mit der oben beschriebenen Variante über Kubernetes direkt. Auch hier benötigen Sie den Service-Account, damit Checkmk auf das Cluster zugreifen kann. Dieses erstellen Sie direkt in der Rancher-Weboberfläche, wo Sie anschließend auch dessen Token und Zertifikat finden. Diese importieren Sie anschließend wie beschrieben in Checkmk.

Navigieren Sie in Rancher zunächst nach Global > Security > Roles > Cluster, 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-Nutzer checkmk unter Global > Users > Add User. Bei Global Permissions wählen Sie die Option User-Base, um dem Nutzer nur die nötigsten Leserechte einzuräumen.

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 Nutzer checkmk mit der zugehörigen Rolle checkmk zum Cluster hinzufügen.

Melden Sie sich anschließend mit dem neuen Nutzer bei Rancher an, rufen Sie den Cluster auf und klicken Sie auf Kubeconfig File. Hier finden Sie drei Angaben, die Sie für das Monitoring in Checkmk benötigen:

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 Kapitel Zertifikat in Checkmk importieren.

Wenn Sie Ihre Kubernetes-Cluster mit Rancher verwalten, können Sie Event Console nutzen, um die Ereignisse in Rancher zu überwachen. Die Anbindung aktivieren Sie ganz einfach für ein ganzes Cluster oder einzelne Projekte in der Rancher-Oberfläche.

Navigieren Sie wahlweise zu Ihrem Cluster oder zu einem Projekt unter Project/Namespaces und rufen Sie dort Tools > Logging auf. Die Konfiguration ist in beiden Fällen identisch, lediglich die Überschrift der Seite, Cluster Logging beziehungsweise Project Logging, zeigt an, wo Sie sich gerade befinden. Wählen Sie als Ziel Syslog und tragen Sie in der Konfigurationsmaske zunächst den Endpoint ein, hier die IP-Adresse Ihres Checkmk-Servers samt Port 514, also beispielsweise 192.168.178.100:514. Das Protokoll belassen Sie bei UDP. Unter Program tragen Sie den gewünschten Namen für den Log ein, so wie er in der Event Console erscheinen soll. Zuletzt legen Sie unter Log Severity den Log-Level fest — zum Testen empfiehlt sich hier Notice, um auch definitiv und unmittelbar Einträge ins System zu bekommen.

Damit die Daten auch im Monitoring ankommen, muss in Checkmk eine entsprechende Event-Console-Regel laufen. Sie können hier beispielsweise den Wert Match syslog application (tag) im Bereich Matching Criteria testweise auf den eben unter Program vergebenen Log-Namen filtern.

In der Checkmk-Oberfläche sehen Sie nun die Ereignisse Ihres Clusters oder Projekts in den Events-Ansichten, die Sie über die Widgets Views und Tactical Overview erreichen. In der Spalte Application erscheint der in der Rancher-Konfiguration unter Program festgelegte Log-Name.

Wenn die Cluster nicht mit einer Verwaltung wie Rancher aufgesetzt wurden, können Sie diese mittels Fluentd an die Event Console berichten lassen. Fluentd ist eine quelloffene, universelle Logging-Lösung, die zum Beispiel für Elasticsearch, aber eben auch für das syslog-Format Daten sammeln kann. Sie können Fluentd sehr einfach über ein Kubernetes-DaemonSet als Container laufen lassen.

Klonen Sie zunächst das Fluentd-Repository:

Darin finden Sie zum einen diverse Konfigurationsdateien im YAML-Format und zum anderen die zugehörigen Docker-Dateien. Für den Anschluss an Checkmk müssen Sie in der DaemonSet-Konfiguration fluentd-kubernetes-daemonset/fluentd-daemonset-syslog.yaml lediglich in Zeile 70 den Wert SYSLOG_HOST setzen. Tragen Sie hier also Hostnamen oder IP-Adresse des Syslog-Endpoints/Checkmk-Servers ein, etwa 192.168.178.101. Das Protokoll belassen Sie bei UDP, den Port bei 514.

Anschließend wenden Sie das DeamonSet mit dem Tool kubectl an:

Je nach Cluster dauert es ein wenig, bis auf jedem Node der Fluentd-Container läuft. Anschließend benötigen Sie wieder eine Event-Console-Regel, die die Daten ins Monitoring bringt. Zum Testen bietet sich hier der Wert fluentd als Filter für Match syslog application (tag) im Bereich Matching Criteria an, um alle Ereignisse der Fluentd-Instanzen zu bekommen. Setzen in der Regel nun fluentd statt Rancher2. Sie finden das Ergebnis dann ebenso, wie oben beschrieben unter Views > Even Console > Events oder der Tactical Overview. Dieses mal mit dem neuen Applikationsnamen: