🧑🏽‍🤝‍🧑🏻 🍋 👵 7 fehlende Faktoren im Ansatz 12 Faktor App 👩🏽‍🏭 🚠 🎬

Hinweis perev. : Die Aufregung, die unsere Teamleiter erlebten, als sie dieses Material im IBM Cloud-Blog sahen - eine Art "Erweiterung" der legendären Twelve-Factor-App - spricht für sich. Die vom Autor aufgeworfenen Fragen sind nicht nur nach Gehör, sondern wirklich wichtig, d. H. relevant im Alltag. Ihr Verständnis ist nicht nur für DevOps-Ingenieure nützlich, sondern auch für Entwickler, die moderne Anwendungen erstellen, die in Kubernetes ausgeführt werden.

Die bekannte 12-Faktor-Anwendungsmethode besteht aus klar definierten Regeln für die Entwicklung von Mikrodiensten. Sie werden häufig zum Ausführen, Skalieren und Bereitstellen von Anwendungen verwendet. Auf der IBM Cloud Private-Plattform folgen wir bei der Entwicklung von Containeranwendungen denselben 12 Prinzipien. Der Artikel „ Kubernetes & 12-Faktor-Apps “ beschreibt die Besonderheiten der Verwendung dieser 12 Faktoren (sie werden vom Kubernetes-Container-Orchestrierungsmodell unterstützt).

Als wir über die Prinzipien der Entwicklung von containerisierten Mikrodiensten nachdachten, die unter der Kontrolle von Kubernetes arbeiten, kamen wir zu folgendem Schluss: Die oben genannten 12 Faktoren sind völlig richtig, aber andere sind auch äußerst wichtig für die Organisation einer Produktionsumgebung:

beobachtbar
Vorhersehbarkeit ( planbar ) ;
Aktualisierbarkeit (aktualisierbar) ;
Mindestrechte
Kontrollierbarkeit (überprüfbar) ;
Sicherheit (sicherbar) ;
messbar

Lassen Sie uns auf diese Prinzipien eingehen und versuchen, ihre Bedeutung zu bewerten. Um die Einheitlichkeit zu gewährleisten, fügen wir sie zu den vorhandenen hinzu - dementsprechend beginnen wir mit XIII ...

Prinzip XIII: Beobachtbarkeit

Anwendungen sollten Informationen über ihren aktuellen Status und Indikatoren bereitstellen.

Verteilte Systeme können schwierig zu verwalten sein, da viele Mikrodienste in eine Anwendung integriert sind. Tatsächlich müssen sich die verschiedenen Zahnräder gemeinsam bewegen, damit der Mechanismus (die Anwendung) funktioniert. Wenn ein Fehler in einem der Mikrodienste auftritt, sollte das System ihn automatisch erkennen und korrigieren. Kubernetes bietet hervorragende Rettungsmechanismen wie Bereitschafts- und Lebendigkeitstests .

Mit ihrer Hilfe stellt Kubernetes sicher, dass die Anwendung für den Empfang von Datenverkehr bereit ist. Wenn die Bereitschaft fehlschlägt, sendet Kubernetes keinen Datenverkehr mehr an den Pod, bis der nächste Test zeigt, dass der Pod bereit ist.

Angenommen, wir haben eine Anwendung, die aus drei Mikrodiensten besteht: Frontend, Geschäftslogik und einer Datenbank. Damit die Anwendung funktioniert, muss das Frontend vor dem Akzeptieren des Datenverkehrs sicherstellen, dass die Geschäftslogik und die Datenbanken bereit sind. Dies kann mithilfe des Bereitschaftstests erfolgen. Auf diese Weise können Sie sicherstellen, dass alle Abhängigkeiten funktionieren.

Die Animation zeigt, dass Anforderungen an den Pod erst gesendet werden, wenn der Bereitschaftstest seine Bereitschaft zeigt:

Bereitschaftstest in Aktion: Kubernetes verwendet den Bereitschaftstest, um zu überprüfen, ob Pods für den Empfang von Datenverkehr bereit sind

Es gibt drei Arten von Tests: Verwenden von HTTP, TCP-Anforderungen und Befehlen. Sie können die Konfiguration von Tests steuern, indem Sie beispielsweise die Häufigkeit der Starts, die Schwellenwerte für Erfolg / Misserfolg und die Wartezeit auf eine Antwort angeben. Bei Lebendigkeitstests müssen Sie einen sehr wichtigen Parameter initialDelaySeconds - initialDelaySeconds . Stellen Sie sicher, dass der Test erst startet, nachdem die Anwendung fertig ist. Wenn dieser Parameter falsch eingestellt ist, wird die Anwendung ständig neu gestartet. So kann es implementiert werden:

 livenessProbe: # an http probe httpGet: path: /readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5

Durch Lebendigkeitstests überprüft Kubernetes, ob Ihre Anwendung ausgeführt wird. Wenn die Anwendung normal funktioniert, unternimmt Kubernetes nichts. Wenn es "gestorben" ist, entfernt Kubernetes den Pod und startet im Gegenzug einen neuen. Dies entspricht den Anforderungen an den zustandslosen Mikroservice und deren Recyclingfähigkeit ( Faktor IX, Entsorgung ). Die folgende Animation zeigt eine Situation, in der Kubernetes den Pod neu startet, nachdem der Lebendigkeitstest nicht bestanden wurde:

Lebendigkeitstest in Aktion: Kubernetes prüft, ob die Pods damit „lebendig“ sind

Der große Vorteil dieser Tests besteht darin, dass Sie Anwendungen in beliebiger Reihenfolge bereitstellen können, ohne sich um Abhängigkeiten kümmern zu müssen.

Wir haben jedoch festgestellt, dass diese Tests für die Produktionsumgebung nicht ausreichen. In der Regel verfügen Anwendungen über eigene Metriken, die nachverfolgt werden müssen, z. B. die Anzahl der Transaktionen pro Sekunde. Clients legen Schwellenwerte für sie fest und konfigurieren Benachrichtigungen. IBM Cloud Private füllt diese Lücke mit dem hochsicheren Überwachungsstapel von Prometheus und Grafana mit einem rollenbasierten Zugriffskontrollsystem. Weitere Informationen finden Sie im Abschnitt IBM Cloud Private Cluster-Überwachung .

Prometheus sammelt Zieldaten aus Endpunktmetriken. Ihre Anwendung sollte Endpunktmetriken mithilfe der folgenden Anmerkung angeben:

 prometheus.io/scrape: 'true'

Danach erkennt Prometheus den Endpunkt automatisch und sammelt Metriken daraus (wie in der folgenden Animation gezeigt):

Sammlung von benutzerdefinierten Metriken

Hinweis perev. : Es wäre richtiger, die Pfeile in die entgegengesetzte Richtung zu drehen, da Prometheus Endpunkte geht und abfragt und Grafana selbst Daten von Prometheus entnimmt, aber im Sinne einer allgemeinen Darstellung ist dies nicht so kritisch.

Prinzip XIV: Vorhersagbarkeit

Anwendungen sollten eine Vorhersagbarkeit der Ressourcenanforderungen bieten.

Stellen Sie sich vor, ein Guide hat Ihr Team ausgewählt, um mit einem Kubernetes-Projekt zu experimentieren. Sie haben hart gearbeitet, um eine geeignete Umgebung zu schaffen. Das Ergebnis ist eine Anwendung, die eine beispielhafte Reaktionszeit und Leistung demonstriert. Dann schloss sich ein anderes Team der Arbeit an. Sie hat ihre Anwendung erstellt und in derselben Umgebung gestartet. Nach dem Start der zweiten Anwendung nahm die Leistung der ersten plötzlich ab. In diesem Fall sollte der Grund für dieses Verhalten in den für Ihre Container verfügbaren Rechenressourcen (CPU und Speicher) gesucht werden. Hohe Wahrscheinlichkeit ihres Mangels. Es stellt sich die Frage, wie die Zuweisung der von der Anwendung benötigten Rechenressourcen gewährleistet werden kann.

Kubernetes bietet eine hervorragende Option, mit der Sie Ressourcenminima und Einschränkungen für Container festlegen können. Mindestanforderungen sind garantiert. Wenn für einen Container eine Ressource erforderlich ist, führt Kubernetes diese nur auf dem Host aus, den diese Ressource bereitstellen kann. Andererseits stellt die Obergrenze sicher, dass der Appetit des Behälters niemals einen bestimmten Wert überschreitet.

Mindest- und Beschränkungen für Container

Der folgende Ausschnitt des YAML-Codes zeigt die Optimierung der Computerressourcen:

 resources: requests: memory: "64Mi" cpu: "150m" limits: memory: "64Mi" cpu: "200m"

Hinweis perev. : Weitere Informationen zum Bereitstellen von Ressourcen in Kubernetes, Anforderungen und Einschränkungen finden Sie in unserem aktuellen Bericht und dessen Überprüfung „ Automatische Skalierung und Ressourcenverwaltung in Kubernetes “ sowie in der K8-Dokumentation .

Eine weitere interessante Möglichkeit für Administratoren in einer Produktionsumgebung besteht darin, Kontingente für den Namespace festzulegen . Wenn das Kontingent festgelegt ist, erstellt Kubernetes keine Container, für die in diesem Namespace keine Anforderungen / Grenzwerte definiert sind. Ein Beispiel für das Festlegen von Kontingenten für den Namespace ist in der folgenden Abbildung dargestellt:

Kontingente für Namespaces

Prinzip XV. Aktualisierbarkeit

Anwendungen sollten Datenformate früherer Generationen aktualisieren.

Oft muss eine funktionierende Produktionsanwendung gepatcht werden, um eine Sicherheitsanfälligkeit zu beseitigen oder die Funktionalität zu erweitern. Es ist wichtig, dass das Update ohne Arbeitsunterbrechungen erfolgt. Kubernetes bietet einen fortlaufenden Aktualisierungsmechanismus, mit dem Sie Ihre Anwendung ohne Ausfallzeiten aktualisieren können. Mit diesem Mechanismus können Sie jeweils per Pod aktualisieren, ohne den gesamten Dienst zu beenden. Hier ist eine schematische Darstellung dieses Prozesses (darauf wird die Anwendung auf die zweite Version aktualisiert):

Ein Beispiel für eine entsprechende YAML-Beschreibung:

 minReadySeconds: 5 strategy: # ,      type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1

maxUnavailable maxSurge maxUnavailable und maxSurge :

maxUnavailable - Ein optionaler Parameter, der die maximale Anzahl von Pods festlegt, die während des Aktualisierungsvorgangs möglicherweise nicht verfügbar sind. Obwohl dies optional ist, lohnt es sich dennoch, einen bestimmten Wert festzulegen, um die Verfügbarkeit des Dienstes zu gewährleisten.
maxSurge ist ein weiterer optionaler, aber kritischer Parameter. Hiermit wird die maximale Anzahl von Pods festgelegt, die über die gewünschte Anzahl hinaus erstellt werden können.

Prinzip XVI: Mindestprivilegien

Container sollten mit einem Minimum an Berechtigungen arbeiten.

Es klingt pessimistisch, aber Sie sollten sich jede Auflösung im Container als potenzielle Sicherheitslücke vorstellen (siehe Abbildung). Wenn der Container beispielsweise als Root ausgeführt wird, kann jeder, der Zugriff darauf hat, dort einen böswilligen Prozess auslösen. Kubernetes bietet eine Pod Security Policy (PSP), um den Zugriff auf das Dateisystem, den Host-Port, die Linux-Funktionen und mehr einzuschränken. IBM Cloud Private bietet einen vorgefertigten Satz von PSPs, die an Container gebunden werden, wenn diese im Namespace bereitgestellt werden. Weitere Informationen finden Sie unter Verwenden von Namespaces mit Pod-Sicherheitsrichtlinien .

Alle Auflösung ist ein potentieller Angriffsvektor

Prinzip XVII: Kontrollierbarkeit

Sie müssen wissen, wer, was, wo und wann für alle unternehmenskritischen Operationen.

Die Steuerbarkeit ist für jeden Vorgang mit einem Kubernetes-Cluster oder einer Kubernetes-Anwendung von entscheidender Bedeutung. Wenn die Anwendung beispielsweise Kreditkartentransaktionen verarbeitet, müssen Sie eine Prüfung aktivieren, um eine Kontrollablaufverfolgung für jede Transaktion zu erhalten. IBM Cloud Private verwendet die branchenübliche Cloud Auditing Data Federation (CADF), die für bestimmte Cloud-Implementierungen unveränderlich ist. Weitere Informationen finden Sie unter Überwachungsprotokollierung in IBM Cloud Private .

Ein CADF-Ereignis enthält die folgenden Daten:

initiator_id - ID des Benutzers, der die Operation ausgeführt hat;
target_uri - Ziel-CADF-URI (zum Beispiel: Daten / Sicherheit / Projekt);
action - Die action , normalerweise operation: resource_type .

Prinzip XVIII: Sicherheit (Identifizierung, Netzwerk, Umfang, Zertifikate)

Es ist notwendig, die Anwendung und die Ressourcen vor Fremden zu schützen.

Dieser Artikel verdient einen separaten Artikel. Es genügt zu sagen, dass Produktionsanwendungen einen End-to-End-Schutz benötigen. IBM Cloud Private ergreift die folgenden Maßnahmen, um die Sicherheit von Produktionsumgebungen zu gewährleisten:

Authentifizierung: Identitätsprüfung;
Autorisierung: Authentifizierte Benutzerzugriffsprüfung;
Zertifikatsverwaltung: Arbeiten mit digitalen Zertifikaten, einschließlich Erstellung, Speicherung und Erneuerung;
Datenschutz: Gewährleistung der Sicherheit übertragener und gespeicherter Daten;
Netzwerksicherheit und -isolation: Verhinderung des Zugriffs unbefugter Benutzer und Prozesse auf das Netzwerk;
Schwachstellenberater: Identifizieren von Schwachstellen in Bildern;
Mutationsberater: Nachweis von Mutationen in Containern.

Weitere Informationen finden Sie im IBM Cloud Private Security Guide .

Besonders hervorzuheben ist der Zertifikatsmanager. Dieser Service bei IBM Cloud Private basiert auf dem Open Source- Projekt Jetstack . Mit Certificate Manager können Sie Zertifikate für Services ausstellen und verwalten, die unter IBM Cloud Private ausgeführt werden. Es unterstützt sowohl öffentliche als auch selbstsignierte Zertifikate und ist vollständig in kubectl und die rollenbasierte Zugriffskontrolle integriert.

Prinzip XIX: Messbarkeit

Die Verwendung des Antrags sollte für die Zwecke von Quoten und Abrechnungen zwischen Abteilungen messbar sein.

Letztendlich müssen Unternehmen die IT-Kosten bezahlen (siehe Abbildung unten). Rechenressourcen für die Ausführung von Containern müssen messbar sein, und Organisationen, die den Cluster verwenden, müssen rechenschaftspflichtig sein. Befolgen Sie unbedingt Prinzip XIV - Vorhersagbarkeit. IBM Cloud Private bietet einen Buchhaltungsservice , der Daten zu Computerressourcen für jeden Container sammelt und diese auf Namespace-Ebene für weitere Berechnungen (als Teil von Showbacks oder Rückbuchungen) kombiniert.

Die Nutzung der Anwendung muss messbar sein.

Fazit

Ich hoffe, Ihnen hat das in diesem Artikel angesprochene Thema gefallen, und Sie haben die Faktoren, die Sie bereits verwenden, zur Kenntnis genommen und über diejenigen nachgedacht, die noch am Rande stehen.

Für weitere Informationen empfehle ich Ihnen, sich mit der Aufzeichnung unserer Leistung auf der KubeCon 2019 in Shanghai vertraut zu machen. Darin diskutieren Michael Elder und ich 12 + 7 Prinzipien für die Kubernetes-basierte Container-Orchestrierung.

PS vom Übersetzer

Lesen Sie auch in unserem Blog:

7 fehlende Faktoren im Ansatz 12 Faktor App