Was sind Operatoren in Kubernetes?
Operatoren sind wie Software-Erweiterungen des API-Servers, die zusätzliche Funktionen in Kubernetes bereitstellen. Sie automatisieren den gesamten Lebenszyklus der von ihnen kontrollierten Software, indem sie uns das Paketieren, Bereitstellen und Verwalten einer Kubernetes-Anwendung ermöglichen. Wie machen sie das? Sie definieren CRs (Custom Resources), um eine Anwendung und alle ihre Komponenten auszuführen. CRs ermöglichen es IT-Administratoren, einzigartige Objekte und Typen in einen Kubernetes-Cluster einzubringen, um spezifische, benutzerdefinierte Anforderungen zu erfüllen, die die standardmäßig eingebauten API-Objekte und -Ressourcen nicht erfüllen können. Die CRD (Custom Resource Definition) definiert eine CR und listet alle Konfigurationsoptionen auf, die den Benutzern des Operators zur Verfügung stehen. Um sicherzustellen, dass der gewünschte und der aktuelle Zustand der Software übereinstimmen, überwacht ein Operator eine benutzerdefinierte Ressource und ergreift Maßnahmen, wenn es eine Diskrepanz zwischen dem, was wir haben" und dem, was wir haben wollen" gibt. Einige Beispiele für Operatoren sind der Istio Operator, der Postgres Operator, der Prometheus Operator, usw.
Was bietet der Prometheus Operator?
Prometheus ist ein Open-Source-Überwachungssystem, das sich zu einem bevorzugten Überwachungswerkzeug für verteilte Systeme entwickelt hat. Die Bereitstellung von Prometheus und dem Alertmanager-Tool kann kompliziert sein, aber es gibt eine Lösung, die die Bereitstellung vereinfacht und automatisiert. Dies ist das Prometheus Operator Projekt (https://github.com/prometheus-operator/prometheus-operator). Eine der Hauptfunktionen des Prometheus Operator besteht darin, den Kubernetes-API-Server auf Änderungen an bestimmten Ressourcen und Objekten zu überwachen und sicherzustellen, dass die aktuelle Prometheus-Bereitstellung diesen Objekten entspricht.
Wie überwacht man einen Prozess auf einer Linux-basierten AWS EC2-Instanz mit Prometheus und node_exporter?
Zunächst einmal brauchen wir eine Software auf dem EC2-Rechner, die die benötigten Daten sammelt und in einem Format ausgibt, das Prometheus versteht. An dieser Stelle kommt der node_exporter ins Spiel. Er ermöglicht es uns, Hardware, Kernel, benutzerdefinierte Statistiken usw. abzurufen und diese in einer URL darzustellen. Die Installation von node_exporter ist ganz einfach. Wir laden das Archiv herunter, entpacken es und verschieben die Binärdatei in einen geeigneten Ordner. Beachten Sie, dass es für node_exporter keine fertige Lösung zum Sammeln von Prozessdaten für Systeme gibt, die System V verwenden. Beim Starten von node_exporter stehen mehrere Flags zur Auswahl. Um alle systemd-Dienste zu überwachen, ist -collector.systemd das, was uns interessiert. Ein Beispiel für den Start der Dienstausführung für node_exporter.service ist unten zu sehen:
ExecStart=/usr/local/bin/node_exporter
--collector.ntp
--collector.systemd
--no-collector.fibrechannel
--no-collector.infiniband
--no-collector.xfs
--no-collector.zfs
--web.config=/etc/node_exporter/config.yaml
--web.listen-address=0.0.0.0:9100
--web.telemetry-path=/metrics
Im Grunde sammelt node_exporter also grundlegende Prozessdaten zusammen mit Daten, die von den anderen verwendeten Flags gesammelt wurden, und stellt sie lokal auf der EC2 an Port 9100 zur Verfügung. Die Daten können von der EC2-Maschine unter dieser URL abgerufen werden: https://0.0.0.0:9100/metrics. Sie können die URL mit der Option "-k" aufrufen, um zu überprüfen, ob die Informationen vorhanden sind. Ein Beispiel für Daten, die von einem node_exporeter für einen bestimmten Dienst bereitgestellt werden, sind folgende:
node_systemd_unit_state{name="auditd.service",state="activating",type="forking"} 0
node_systemd_unit_state{name="auditd.service",state="active",type="forking"} 1
node_systemd_unit_state{name="auditd.service",state="deactivating",type="forking"} 0
node_systemd_unit_state{name="auditd.service",state="failed",type="forking"} 0
node_systemd_unit_state{name="auditd.service",state="inactive",type="forking"} 0
Mit anderen Worten, es sagt uns einfach, in welchem Zustand sich ein Dienst gerade befindet. Die obige Angabe bedeutet, dass der "audit"-Daemon aktiv ist und läuft.
Wie kann man die von node_exporter veröffentlichten Daten in Prometheus verfügbar machen?
In einem ersten Schritt müssen wir eine eingehende Regel in der EC2-Sicherheitsgruppe definieren, die Verbindungen vom Kubernetes-EKS-Cluster zum EC2-Rechner an Port 9100 zulässt, auf dem der node_exporter lauscht. Als Typ sollten Sie "Custom TCP" verwenden und als Quelle für die Regel müssen wir das Netzwerk definieren, in dem Kubernetes läuft. Überprüfen Sie, ob die Kommunikation funktioniert, indem Sie von einem Container im Namensraum, in dem Prometheus Operator installiert ist, einen Telnet-Zugriff auf den Port 9100 der EC2 durchführen. In einem zweiten Schritt müssen wir ein Ziel im Prometheus Operator HELM-Diagramm definieren, das Prometheus anweist, Daten von diesem Ziel abzurufen. Es ist besser, einen DNS-Eintrag für den EC2-Rechner zu haben und diesen A-Eintrag für das Ziel zu verwenden. Da es sich um eine interne Kommunikation zwischen der EC2-Maschine und dem EKS-Cluster handelt, können wir ein selbstsigniertes Zertifikat verwenden und dessen Überprüfung überspringen. Beispielkonfiguration dafür:
- job_name: ec2-monitoring-node-exporter
scheme: https
tls_config:
insecure_skip_verify: true
static_configs:
- targets:
- 'ec2-dns-record:9100'
dns_sd_configs:
- type: A
port: 9100
names:
- 'ec2-dns-record'
Sobald die obige Konfiguration geladen ist und der Prometheus-Config-Reloader-Container neu geladen wurde, beginnt er mit dem Scraping von Daten vom EC2-Port 9100, die unter der definierten Prometheus-URL verfügbar gemacht werden. Auf dieser URL können wir auf "Targets" klicken und sehen dann das oben definierte Ziel.
Wie kann man einen Alarm einrichten, der ausgelöst wird, wenn ein Prozess nicht mehr funktioniert?
Nachdem wir nun die Netzwerkkonfiguration für die Kommunikation zwischen EKS und der EC2-Maschine vorgenommen, den node_exporter gestartet und ein Ziel in Prometheus definiert haben, sollten wir auch einen Alarm definieren, der ausgelöst wird, wenn ein Dienst nicht mehr funktioniert. Im Prometheus Operator HELM Diagramm können wir das so machen:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: ec2-monitoring-node-exporter
labels:
prometheus: infra-prometheus
spec:
groups:
- name: systemd.rules
rules:
- alert: HostSystemdServiceStopped
expr: node_systemd_unit_state{instance="ec2-dns-record", job="ec2-monitoring-node-exporter", name="auditd.service ", state="active", type="simple"} == 0
for: 5m
labels:
severity: critical
annotations:
summary: Host systemd service stopped (instance {{ $labels.instance }})
description: "systemd service stoppedn VALUE = {{ $value }}n LABELS = {{ $labels }}"
Der für das Ziel definierte "job_name" muss mit dem im Alert definierten "job_name" übereinstimmen. Der obige Alert löst einen Alarm aus, wenn sich der "auditd.service" nicht mehr im "aktiven" Zustand befindet, d.h. wenn er nicht mehr funktioniert.
Weitere Experten-Tutorials von unseren erfahrenen DevOps-Ingenieuren finden Sie in unserem Blog.
