Schmerzfreie Kubernetes-Überwachung und -Benachrichtigung

Kubernetes ist komplex, aber lassen Sie uns die Überwachung und Benachrichtigung für Kubernetes vereinfachen!

Bei ilert erstellen wir Architekturen aus Mikroservices und serverlosen Funktionen, die massiv und nahtlos skalieren, um unseren Kunden den unterbrechungsfreien Zugriff auf unsere Dienste zu garantieren. Wie viele andere in der Branche verlassen wir uns bei der Orchestrierung unserer Dienste auf Kubernetes. Eine schnelle Reaktion auf jede Art von Vorfall ist ein absolutes Muss für unsere Uptime-Plattform, da jede Sekunde zählt und wir die Komplexität so weit wie möglich reduzieren möchten. ilerts Kubernetes-Agent und Vorfallaktionen helfen uns, extrem schnell auf Probleme zu reagieren.

Einführung

Heute gibt es viele Lösungen zur Erfassung von Metriken von Kubernetes-Clustern wie Prometheus und zur Umwandlung dieser Metriken in Diagramme und Alarme mit Hilfe von Grafana. Dies sind großartige Lösungen mit vielen Funktionen und Beiträgen, aber damit gehen einige Probleme einher:

• Komplexität (Infrastruktur-Setup)
• Komplexität (Alarmierung basierend auf Schwellenwerten)
• Hoher Ressourcenverbrauch
• Wartung
• Reaktionszeit bei einem Vorfall

Zuerst bedeutet die Komplexität solcher Überwachungssysteme, dass unser Ziel (eine Benachrichtigung zu erhalten, wenn ein Problem auftritt) nicht erreicht werden kann, wenn eine der Überwachungskomponenten selbst ausfällt. Schauen wir uns das genauer an. Angenommen, ich möchte benachrichtigt werden, wenn mein Dienst oder mein Kubernetes-Knoten das Speicherlimit erreicht hat. Was benötige ich dafür? Das Mindeste, was wir brauchen, ist Prometheus, Grafana, kube-state-metrics und Node Exporter, die in meinem Cluster ausgeführt werden. Dann muss ich ein Grafana-Dashboard mit den Metriken erstellen, die mich interessieren, und individuelle Alarmbedingungen für jeden Dienst festlegen, da der Speicherverbrauch für jeden unterschiedlich ist. Es ist weit davon entfernt, einfach zu sein, und es fügt eine ganze Reihe von Diensten hinzu, die zusätzliche Überwachung erfordern. Jetzt, wenn ich benachrichtigt werden möchte, wenn eine meiner Überwachungskomponenten ausfällt, muss ich dafür HA-Lösungen wie Cortex verwenden, was wiederum eine weitere Ebene von Komplexität in mein System einbringt.

Neben der zusätzlichen Komplexität und Wartung überschreitet der Ressourcenverbrauch von Überwachungssystemen oft den Ressourcenverbrauch von Geschäftsdiensten (insbesondere in kleineren Unternehmen oder Start-ups). Dies mag normal sein, wenn wir Transparenz im Ressourcenverbrauch und in der Leistung unserer Dienste erreichen möchten oder wenn wir Geschäftsmetriken visualisieren müssen. Aber wenn wir nur eine Benachrichtigung über ein Standardproblem in unserem Cluster erhalten möchten, z. B. einen ausgefallenen POD, ist das eindeutig zu viel Aufwand.

Die Open-Source-Community ist sehr aktiv, und wir sind ihnen sehr dankbar, aber das führt dazu, dass wir mehrmals im Monat mehrere Updates erhalten und diese natürlich verwenden wollen und sie immer wieder auf unserem Cluster installieren. Leider verlaufen diese Updates nicht immer reibungslos, und wir müssen uns mit den Folgen der Updates befassen.

Schließlich, wenn ein Problem auftritt, müssen wir sehr schnell handeln, damit die Kunden nicht beeinträchtigt werden. Dies ist nicht immer einfach, insbesondere wenn Sie ein paar Stunden mitten in der Nacht geschlafen haben und schnell auf eine eingehende Benachrichtigung reagieren müssen. Sie möchten wirklich jede Ablenkung und Reibung auf ein Minimum reduzieren. Neben dem Einloggen und der Suche nach Problemen könnte ein weiteres Problem die Art und Weise sein, wie das Überwachungssystem Metriken sammelt und wie die auf aggregierten Metriken basierenden Alarme funktionieren. Wenn ich z.B. benachrichtigt werden möchte, wenn mein Dienst beendet wurde (z.B. ein Fehler, der zu einer NPE führt oder unser beliebtes OOMKilled). Prometheus sammelt Metriken mit einer bestimmten Häufigkeit. Normalerweise ist es einmal alle 15 Sekunden, also verlieren wir im schlimmsten Fall diese 15 Sekunden, wenn ein Problem unmittelbar nach der erneuten Erfassung von Daten durch Prometheus auftritt. Danach verarbeitet Grafana die Daten normalerweise alle Minute und führt einen Zeitraum von 5 Minuten aus, um einen Alarm auszulösen oder nicht. Das bedeutet im besten Fall erhalten wir etwa nach einer Minute einen Alarm, dass unser wichtiger Dienst beendet wurde, in einigen Fällen nach 5 oder 10 Minuten. Warum so viel Zeit verschwenden, wenn wir die Informationen direkt von Kubernetes im gleichen Augenblick erhalten und viel schneller reagieren können?

Also schauen wir uns an, wie wir unser Leben einfacher machen und Alarme von Metriken mit dem ilert Kubernetes-Agenten trennen können.

Anforderungen

Sie benötigen:

• einen Mac / Unix-Rechner
• ein ilert-Konto. Melden Sie sich jetzt an, es ist kostenlos.
• ein Kubernetes-Cluster
• möglicherweise ein AWS-Konto mit AWS Lambda-Zugriff (wenn Sie Vorfallaktionen auslösen möchten)

Verständnis des Setups

Bevor wir beginnen, lassen Sie uns zunächst verstehen, wie es funktioniert. Im folgenden Beispiel möchte ich über Probleme in meinem Cluster per SMS, Sprachanruf oder Push-Benachrichtigungen benachrichtigt werden und so schnell wie möglich reagieren, um das Problem zu beheben.

Der ilert-kube-agent ist ein Dienst, der auf den Kubernetes-API-Server hört und Vorfallmeldungen über den Gesundheitszustand der Pods und Knoten generiert. Der Agent erkennt die häufigsten Probleme im Kubernetes-Cluster und erfordert keine zusätzliche Konfiguration. Es ist jedoch möglich, eine einfache Konfiguration zu übergeben, wenn Sie z.B. eine bestimmte Art von Benachrichtigung nicht erhalten möchten. Sobald ein Problem erkannt wird, erstellt der Agent einen Vorfall in ilert. Als nächstes kommt die Reaktion auf den Vorfall, in diesem Fall mit Hilfe einer Lambda-Funktion, um das potenzielle Problem schnell zu beheben - ohne einen weiteren Kontextwechsel zu erfordern.

ilert-Einrichtungsanweisungen

1. Gehen Sie zum Tab "Alert sources" und klicken Sie auf "Create new alert source".

2. Geben Sie einen Namen ein und wählen Sie Ihre gewünschte Eskalationsrichtlinie aus. Wählen Sie Kubernetes als Integrationstyp aus und klicken Sie auf "Save".

3. Auf der nächsten Seite wird ein API-Schlüssel generiert. Sie benötigen ihn unten, wenn Sie die ilert-kube-agent-Bereitstellung einrichten.

Anweisungen zur Einrichtung des Kubernetes-Agenten

In diesem Beispiel verwende ich die Helm-Einrichtung. Wenn Sie eine Installation mit einem einfachen YAML-Manifest oder Terraform oder Serverless (Lambda) in Betracht ziehen, können Sie sich hier an unsere Anweisungen wenden.

1. Fügen Sie das Helm-Chart-Repository hinzu und aktualisieren Sie es

helm repo add ilert https://ilert.github.io/charts/
helm repo update

‍

2. Deployen Sie den Agenten mit dem API-Schlüssel, den Sie in ilert generiert haben

   helm upgrade --install --namespace kube-system \
    ilert-kube-agent ilert/ilert-kube-agent \
    --set config.settings.apiKey=""

3. Überprüfen Sie Ihre Agenteninstallation

✗ kubectl --namespace kube-system get pod -l app=ilert-kube-agent -w
NAME                                READY   STATUS    RESTARTS   AGE
ilert-kube-agent-57d8747dd5-b7z1x   1/1     Running   0          37s
ilert-kube-agent-57d8747dd5-kzx8t   1/1     Running   0          25s

‍

Fertig! Jetzt erstellen Kubernetes-Ereignisse Vorfalls in ilert.

Anweisungen zur Einrichtung von Vorfallaktionen

Für diese Demonstration verwenden wir AWS Lambda. Sie können auch jede andere extern auslösbare Ressource verwenden.

Um auf einen Vorfall mit Vorfallaktionen in unserem Kubernetes-Cluster zu reagieren, müssen wir einen Lambda-Connector und eine Vorfallaktion für unsere Kubernetes-Alarmquelle in ilert erstellen. Das erste, was zu tun ist, ist die Erstellung einer Lambda-Funktion in AWS. Für unsere Demonstrationszwecke habe ich dieses Repository erstellt, das eine einfache Lambda-Funktion mit den Hilfsprogrammen zum Skalieren unserer Bereitstellung oder unserer Statefulset enthält.

1. Deployen Si die Lambda-API

# Clone repo
git clone git@github.com:iLert/kubernetes-alerting-lambda-sample.git
cd kubernetes-alerting-lambda-sample
# Install dependencies
npm install
# Build binary
make build
# Deploy
serverless deploy --cluster= --region=

2. Nach dem Deployment werden eine Lambda-URL und ein Autorisierungs-API-Schlüssel generiert. Sie benötigen ihn unten, wenn Sie den Connector und die Vorfallaktion in ilert einrichten.

3. Gehen Sie zur Seite Connectors Ihres ilert-Kontos und klicken Sie auf Create connector.

4. Geben Sie auf der nächsten Seite einen Namen für den Connector ein, z. B. Serverless API, wählen Sie AWS Lambda als Typ aus und fügen Sie den Autorisierungs-API-Key ein, den Sie im Schritt 2 generiert haben.

4. Gehen Sie zu Ihrer zuvor erstellten Kubernetes-Alarmquelle und navigieren Sie zum Tab Connections, klicken Sie dann auf die Schaltfläche Create first connection.

4. Wählen Sie auf der nächsten Seite AWS Lambda als Typ aus, wählen Sie den gerade generierten Connector aus, wählen Sie Manuelle via incident action aus als Auslösemodus, geben Sie einen Namen für die Vorfallaktion ein, z. B. Meinen Dienst skalieren, fügen Sie die Lambda-URL ein, die Sie im Schritt 2 generiert haben, und fügen Sie die benutzerdefinierte Inhaltsvorlage ein:

4. Jetzt sind wir in der Lage, auf jeden Kubernetes-Vorfall mit einer schnellen Vorfallaktion direkt aus ilert zu reagieren.

Reaktion auf Alarme

Lassen Sie uns nun unser Setup in der Praxis sehen. In diesem Beispiel erhalten wir einen Alarm, dass unser Dienst eine erhöhte Speichernutzung aufweist, wahrscheinlich weil er mehr Traffic als üblich verarbeiten muss. Ich möchte die Last dieses Dienstes sofort verteilen, sobald ich über dieses Problem benachrichtigt werde, und das Problem danach analysieren.

‍

Wie Sie sehen können, habe ich die Vorfallaktion verwendet, die wir zuvor erstellt haben, um das Problem direkt von meinem Smartphone aus zu lösen.

Bei Überprüfung des Status unseres Dienstes in Kubernetes sehen wir, dass er jetzt mehr Replikate hat.

Fazit

Natürlich werden nicht alle Probleme durch Skalierung oder Rollback gelöst, aber die Reaktionszeit ist immer entscheidend für ein erfolgreiches Geschäft.

Unsere Erfahrung mit Clustern verschiedener Größen und Überwachungssystemen zeigt, dass Sie sich nicht immer auf eine einzige Lösung verlassen sollten, auch nicht auf eine sehr beliebte und etablierte Lösung. Die Lösung eines Alltagsproblems auf kürzestem und effizientestem Weg kann Ihr Leben erheblich erleichtern.