Überwachen von Kubernetes
1. Einleitung
Der große Erfolg von Docker hat dazu geführt, dass Leute Docker in immer größerem Maßstab einsetzen. Der im Gegensatz zu virtuellen Maschinen ala VMWare sehr geringe Overhead macht den Container „billig“ und damit quasi zur Massenware. Dass dabei ein gutes Werkzeug für die Orchestrierung der Container essentiell ist, versteht sich von selbst. Für die Mehrheit ist das Open-Source-Tool Kubernetes das Mittel der Wahl.
Check_MK unterstützt ab Version 1.5.0p12 die Überwachung von Kubernetes. Der Schwerpunkt liegt aktuell dabei auf Zuständen und Metriken, die vor allem für den Administrator interessant sind. Folgende Checkplugins sind in Version 1.5.0p12 verfügbar:
- Kubernetes CPU resources
- Kubernetes component status
- Kubernetes conditions
- Kubernetes memory resources
- Kubernetes namespaces
- Kubernetes nodes
- Kubernetes persistent volume claims
- Kubernetes persistent volumes
- Kubernetes pod resources
- Kubernetes pods CPU resources
- Kubernetes pods Filesystem resources
- Kubernetes pods memory resources
- Kubernetes roles
- Kubernetes storage classes
Dies ist allerdings nur ein erster Schritt. Zukünftige Versionen von Check_MK werden das Monitoring von Kubernetes weiter ausbauen und verfeinern. Dabei kann es auch sein, dass wir die Architektur der Überwachung nochmal ändern und Sie Ihre Konfiguration dabei anpassen müssen.
2. Einrichten der Überwachung
2.1. Service-Account
Um einen Kubernetes-Cluster in Check_MK einzurichten, benötigen Sie zunächst einen Service-Account und eine damit verbundene Clusterrolle in Kubernetes, damit Check_MK auf die API zugreifen kann. Wir stellen für Sie als Schablone die Datei check_mk_rbac.yaml bereit, die Sie in den „Treasures“ finden, und zwar im Verzeichnis share/doc/check_mk/treasures/kubernetes. Deren Anfang sieht etwa so aus:
--- apiVersion: v1 kind: Namespace metadata: name: check-mk --- kind: ServiceAccount apiVersion: v1 metadata: name: check-mk namespace: check-mk --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: check-mk rules:
Wir verwenden hier als Name und Namespace jeweils check-mk.
Spielen Sie diese Datei auf Ihrem Kubernetes-Cluster mit dem Befehl kubectl ein:
user@host:~$ kubectl apply -f check_mk_rbac.yaml namespace/check-mk created serviceaccount/check-mk created clusterrole.rbac.authorization.k8s.io/check-mk created clusterrolebinding.rbac.authorization.k8s.io/check-mk created
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):
user@host:~$ kubectl create clusterrolebinding MYNAME-cluster-admin-binding --clusterrole=cluster-admin --user=MYNAME@example.org
Wenn alles gut gegangen ist, können Sie den neuen Service-Account mit kubectl get serviceaccounts abfragen:
user@host:~$ kubectl get serviceaccounts check-mk -n check-mk -o yaml apiVersion: v1 kind: ServiceAccount metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"check-mk","namespace":"check-mk"}} creationTimestamp: "2019-01-23T08:16:05Z" name: check-mk namespace: check-mk resourceVersion: "4004661" selfLink: /api/v1/namespaces/check-mk/serviceaccounts/check-mk uid: 218179a3-1ee7-11e9-bf43-080027a5f141 secrets: - name: check-mk-token-z9hbp
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:
user@host:~$ kubectl get secrets check-mk-token-z9hbp -n check-mk -o yaml apiVersion: v1 data: ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQVRBTkJna3Foa2lHO... namespace: Y2hlY2stbWs= token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObG... kind: Secret metadata: annotations: kubernetes.io/service-account.name: check-mk kubernetes.io/service-account.uid: 218179a3-1ee7-11e9-bf43-080027a5f141 creationTimestamp: "2019-01-23T08:16:06Z" name: check-mk-token-z9hbp namespace: check-mk resourceVersion: "4004660" selfLink: /api/v1/namespaces/check-mk/secrets/check-mk-token-z9hbp uid: 2183cee6-1ee7-11e9-bf43-080027a5f141 type: kubernetes.io/service-account-token
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 Check_MK benötigen:
user@host:~$ kubectl get secrets check-mk-token-z9hbp -n check-mk -o yaml | grep "ca.crt" | cut -f4 -d' ' | base64 --decode -----BEGIN CERTIFICATE----- MIIC5zCCAc+gAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwptaW5p a3ViZUNBMB4XDTE4MDkxMDE2MDAwMVoXDTI4MDkwODE2MDAwMVowFTETMBEGA1UE AxMKbWluaWt1YmVDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK9Z iG0gNZK5VU94a0E6OrUqxOQRdkv6S6vG3LnuozdgNfxsEetR9bMGu15DWaSa40JX FbC5RxzNq/W9B2pPmkAlAguqHvayn7lNWjoF5P+31tucIxs3AOfBsLetyCJQduYD jbe1v1/KCn/4YUzk99cW0ivPqnwVHBoMPUfVof8yA00RJugH6lMZL3kmOkD5AtRH FTThW9riAlJATBofLfkgRnUEpfb3u1xF9vYEDwKkcV91ealZowJ/BciuxM2F8RIg LdwF/vOh6a+4Cu8adTyQ8mAryfVPDhFBhbsg+BXRykhNzNDPruC+9wAG/50vg4kV 4wFpkPOkOCvB8ROYelkCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgKkMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3 DQEBCwUAA4IBAQAeNwON8SACLl2SB8t8P4/heKdR3Hyg3hlAOSGjsyo396goAPS1 t6IeCzWZ5Z/LsF7o8y9g8A7blUvARLysmmWOre3X4wDuPvH7jrYt+PUjq+RNeeUX 5R1XAyFfuVcWstT5HpKXdh6U6HfzGpKS1JoFkySrYARhJ+MipJUKNrQLESNqdxBK 4gLCdFxutTTFYkKf6crfIkHoDfXfurMo+wyEYE4Yeh8KRSQWvaKTdab4UvMwlUbO +8wFZRe08faBqyvavH31KfmkBLZbMMM5r4Jj0Z6a56qZDuiMzlkCl6rmKynQeFzD KKvQHZazKf1NdcCqKOoU+eh6q6dI9uVFZybG -----END CERTIFICATE-----
2.2. Zertifikat in Check_MK importieren
Damit Check_MK 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 Check_MK-Service des Kubernetes-Clusters mit bad handshake und certificate verify failed fehlschlagen:
2.3. Passwort (Token) im Check_MK hinterlegen
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:
user@host:~$ kubectl get secrets check-mk-token-z9hbp -n check-mk -o yaml | grep "token:" | cut -f4 -d' ' | base64 --decode eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJjaGVjay1tayIsI mt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJjaGVjay1tay10b2tlbi16OWhicCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5 hbWUiOiJjaGVjay1tayIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjIxODE3OWEzLTFlZTctMTFlOS1iZjQzLTA4MDAyN2E1ZjE0MSIsInN1YiI6I nN5c3RlbTpzZXJ2aWNlYWNjb3VudDpjaGVjay1tazpjaGVjay1tayJ9.gcLEH8jjUloTeaAj-U_kRAmRVIiETTk89ujViriGtllnv2iKF12p0L9ybT1fO-1Vx7XyU8jneQRO9lZw8JbhVmaPjrkEc8 kAcUdpGERUHmVFG-yj3KhOwMMUSyfg6wAeBLvj-y1-_pMJEVkVbylYCP6xoLh_rpf75JkAicZTDmhkBNOtSf9ZMjxEmL6kzNYvPwz76szLJUg_ZC636OA2Z47qREUtdNVLyutls7ZVLzuluS2rnfoP JEVp_hN3PXTRei0F5rNeA01wmgWtDfo0xALZ-GfvEQ-O6GjNwHDlsqYmgtz5rC23cWLAf6MtETfyeEJjRqwituhqUJ9Jp7ZHgQ%
Wenn Sie direkt unter Linux arbeiten können Sie hinten noch ein | xsel --clipboard hinzufügen. Dann wird das Passwort garnicht ausgegeben, sondern direkt auf Clipboard kopiert (also als ob Sie das mit der Maus kopiert hätten):
user@host:~$ kubectl get secrets check-mk-token-z9hbp -n check-mk -o yaml | grep "token:" | cut -f4 -d' ' | base64 --decode | xsel --clipboard
Das „Passwort“ ist wirklich so lang. Fügen Sie das z. B. unter der ID kubernetes in den Passwortspeicher ein:
2.4. Kubernetes-Cluster ins Monitoring aufnehmen
Die Überwachung von Check_MK 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 Check_MK überwacht wird. Die Monitoringdaten dieser Hosts werden aber nicht separat von Kubernetes abgerufen, sondern aus den Daten vom Kubernetes-Cluster abgezweigt.
Da Kubernetes nicht über den normalen Check_MK-Agenten abgefragt werden kann, benötigen Sie dafür den Kubernetes-Spezialagenten, welcher auch als Datenquellenprogramm bezeichnet wird. Hierbei kontaktiert Check_MK den Zielhost nicht wie üblich über TCP Port 6556, sondern ruft stattdessen ein Hilfsprogramm auf, welches mit dem Zielsystem über ein die anwendungsspezifische API von Kubernetes kommuniziert.
Deswegen benötigen Sie noch einen weiteren Schritt: Legen Sie eine Regel an, welche Ihrem Kubernetes-Host diesen Spezialagenten zuordnet. Diese 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 die Servicekonfiguration für den Kubernetes-Cluster abrufen, sollten Sie bereits einige der Services finden:
2.5. Überwachung der Nodes
Damit auch die Nodes überwacht werden, müssen Sie diese ebenfalls im WATO als Host anlegen. Dies können Sie (ab Version 1.6.0 von Check_MK) mit dem neuen Dynamic Configuration Daemon (DCD) erledigen lassen. Oder Sie legen diese einfach von Hand als Hosts an.
Dabei ist es wichtig, dass die Hostnamen im Check_MK exakt mit den Namen der Kubernetesnodes übereinstimmen. Sie können diese Namen einfach aus dem Nodes-Service des Kubernetes-Hosts ablegen.
Sofern Sie auf den Nodes selbst keinen Check_MK-Agenten installiert haben (was auch in der Regel eher ungewöhnlich wäre), müssen Sie den Check_MK Agent auf No agent einstellen.
3. Hardware-/Softwareinventur
Die Kubernetesintegration von Check_MK unterstützt auch die Hardware-/Softwareinventur. In Version 1.5.0p12 beschränkt sich dies auf die Kubernetes-Rollen. Weitere Plugins sind geplant.
4. Check_MK entfernen
Wenn Sie den Service-Account und die Custerrolle von Check_MK wieder aus Kubernetes entfernen wollen, können Sie das mit folgenden Befehlen tun:
user@host:~$ kubectl -f check_mk_rbac.yaml namespace "check-mk" deleted serviceaccount "check-mk" deleted clusterrole.rbac.authorization.k8s.io "check-mk" deleted clusterrolebinding.rbac.authorization.k8s.io "check-mk" deleted