Betrieb von OpenShift

Kapitel 1. Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Manuel Dewald

Der Betrieb von verteilter Software ist eine schwierige Aufgabe. Er erfordert Menschen, die das System, das sie betreuen, genau verstehen. Egal, wie viel Automatisierung du schaffst, sie wird niemals hochqualifiziertes Betriebspersonal ersetzen.

OpenShift ist eine Plattform, die entwickelt wurde, um Software-Teams bei der Entwicklung und dem Einsatz ihrer verteilten Software zu unterstützen. Sie wird mit einer großen Anzahl von Tools geliefert, die entweder bereits integriert sind oder einfach eingesetzt werden können. Obwohl OpenShift eine große Hilfe für seine Nutzer sein kann und viele traditionell manuelle Arbeitsschritte überflüssig macht, ist es selbst ein verteiltes System, das eingesetzt, betrieben und gewartet werden muss.

Viele Unternehmen haben Plattformteams, die Softwareteams Entwicklungsplattformen auf der Basis von OpenShift zur Verfügung stellen, damit der Wartungsaufwand zentralisiert und die Bereitstellungsmuster im gesamten Unternehmen standardisiert werden. Diese Plattformteams entwickeln sich immer mehr in Richtung Site Reliability Engineering (SRE)-Teams, in denen Softwareentwicklungspraktiken auf betriebliche Aufgaben angewendet werden. Skripte werden durch richtige Softwarelösungen ersetzt, die einfacher getestet und mit Hilfe von Continuous Integration/Continuous Delivery (CI/CD)-Systemen automatisch bereitgestellt werden können. Alarme werden von einfachen, ursachenbasierten Alarmen wie "auf der virtuellen Maschine 23 wird eine große Menge an Speicher verwendet" in symptombasierte Alarme umgewandelt, die auf Service Level Objectives (SLO) basieren, die die Kundenerfahrungen widerspiegeln, wie z. B. "die Bearbeitung von Anfragen dauert länger, als wir erwarten."

OpenShift bietet alle Tools, die du brauchst, um Software mit SRE-Paradigmen darauf zu betreiben, von einer Überwachungsplattform bis hin zu einem integrierten CI/CD-System, mit dem du sowohl die Software, die auf dem OpenShift-Cluster bereitgestellt wird, als auch den Cluster selbst beobachten und betreiben kannst. Aber der Aufbau der Automatisierung, die Implementierung einer guten Alarmierungsstrategie und schließlich die Behebung von Problemen, die beim Betrieb eines OpenShift-Clusters auftreten, sind immer noch schwierige Aufgaben, die qualifizierte Betriebs- oder SRE-Mitarbeiter/innen erfordern.

Selbst in SRE-Teams wird traditionell ein großer Teil der Zeit der Ingenieure für manuelle Betriebsaufgaben verwendet, die oft als "Toil" bezeichnet werden. Die Betriebszeit sollte jedoch begrenzt werden, da das Hauptziel von SRE darin besteht, die "Toil" mit Softwareentwicklung zu bewältigen.

O'Reilly hat eine Reihe von Büchern veröffentlicht, die von Site Reliability Engineers (SREs) bei Google geschrieben wurden und die sich mit den zentralen SRE-Konzepten befassen. Wir empfehlen dir, einen Blick in diese Bücher zu werfen, wenn du dich für Details zu diesen Prinzipien interessierst. Im ersten Buch, Site Reliability Engineering, sprechen die Autoren hauptsächlich aus ihrer Erfahrung als SREs bei Google und schlagen vor, die Zeit, die ein Ingenieursteam für die Arbeit aufwendet, auf 50 % der Zeit zu begrenzen.

Traditionelle Einsatzteams

Das Ziel von ist es, eine Obergrenze für den Arbeitsaufwand festzulegen, um zu vermeiden, dass die Mitarbeiter die meiste Zeit in einem Betriebsteam verbringen, in dem der Arbeitsaufwand mit dem Ausmaß der Serviceeinführung und der Weiterentwicklung der Software zunimmt.

Teil der zunehmenden Arbeit, während die Serviceannahme wächst, ist die Anzahl der Alarme, die ein Betriebsteam erhält, wenn die Alarmierungsstrategie nicht skalierbar ist. Wenn du eine Software unterhältst, die einen Alarm pro Tag und Tenant erzeugt, und ein Ingenieur damit beschäftigt ist, 10 Tenants zu betreuen, musst du die Anzahl der Bereitschaftsingenieure linear mit der Anzahl der Tenants skalieren, die das Team betreibt. Das heißt, wenn du die Anzahl der Tenants verdoppelst, musst du auch die Anzahl der Techniker verdoppeln, die auf Alarme reagieren. Diese Techniker werden nicht in der Lage sein, den durch die Alarme verursachten Aufwand zu reduzieren, während sie den Aufwand reduzieren und die Probleme untersuchen.

In einem traditionellen Betriebsteam, das OpenShift als Entwicklungsplattform für andere Abteilungen des Unternehmens betreibt, ist das Onboarding neuer Mieter oft eine manuelle Aufgabe. Es kann vom anfragenden Team initiiert werden, indem es ein Ticket öffnet, das nach einem neuen OpenShift-Cluster fragt. Jemand aus dem Betriebsteam nimmt das Ticket auf und beginnt mit der Erstellung der erforderlichen Ressourcen, startet den Installer, konfiguriert den Cluster, damit das anfragende Team Zugang erhält, und so weiter. Ein ähnlicher Prozess kann auch für die Stilllegung von Clustern eingerichtet werden, wenn sie nicht mehr benötigt werden. Die Verwaltung des Lebenszyklus von OpenShift-Clustern kann viel Arbeit verursachen, und solange der Prozess hauptsächlich manuell erfolgt, wird der Arbeitsaufwand mit der Akzeptanz des Dienstes wachsen.

Manuelles Lebenszyklus- und Konfigurationsmanagement ist nicht nur mühsam, sondern auch fehleranfällig. Wenn ein Ingenieur dieselbe Prozedur, die in einem vom Team verwalteten Wiki dokumentiert ist, mehrmals in der Woche ausführt, besteht die Chance, dass er einen wichtigen Schritt übersieht oder einen falschen Parameter an eines der Skripte übergibt, was zu einem fehlerhaften Zustand führt, der vielleicht nicht sofort entdeckt wird.

Wenn du mehrere OpenShift-Cluster verwaltest, ist es gefährlich, einen Cluster zu haben, der sich aufgrund eines Fehlers im Bereitstellungs- oder Konfigurationsprozess oder sogar aufgrund einer Kundenanforderung leicht von den anderen unterscheidet. Die Automatisierung, die das Team im Laufe der Zeit entwickelt hat, ist möglicherweise nicht auf die Besonderheiten eines einzelnen Snowflake-Clusters zugeschnitten. Die Ausführung dieser Automatisierung ist möglicherweise nicht möglich, was für das Betriebsteam noch mehr Arbeit bedeutet. Im schlimmsten Fall kann der Cluster dadurch sogar unbrauchbar werden.

Die Automatisierung in einem traditionellen Betriebsteam findet sich oft in einem zentralen Repository, das auf den Geräten der Techniker ausgecheckt werden kann, damit sie die Skripte ausführen können, die sie im Rahmen eines dokumentierten Prozesses benötigen. Das ist nicht nur problematisch, weil es immer noch manuelle Interaktion erfordert und daher nicht gut skalierbar ist, sondern auch, weil die Geräte der Techniker oft unterschiedlich konfiguriert sind. Sie können sich in den verwendeten Betriebssystemen unterscheiden, so dass es notwendig ist, verschiedene Anbieter in den Werkzeugen zu unterstützen, z.B. durch die Bereitstellung einer standardisierten Umgebung wie einer Container-Umgebung zur Ausführung der Automatisierung.

Aber selbst dann kann sich die Version der auszuführenden Skripte von Ingenieur zu Ingenieur unterscheiden, oder das auszuführende Skript wurde nicht aktualisiert, als eine neue Version von OpenShift veröffentlicht wurde. Automatisierte Tests sind etwas, das nur selten für Betriebsskripte implementiert wird, die gemacht wurden, um schnell ein Stück Arbeit loszuwerden. All das macht die Automatisierung in Skripten, die auf den Rechnern der Entwickler laufen, brüchig.

Wie das Site Reliability Engineering hilft

Bei besteht das Ziel eines SRE-Teams darin, solche Skripte durch tatsächliche Software zu ersetzen, die ordnungsgemäß versioniert ist, über eine ausgereifte Release-Strategie verfügt, einen kontinuierlichen Integrations- und Auslieferungsprozess hat und von der neuesten freigegebenen Version auf dedizierten Maschinen, zum Beispiel einem OpenShift-Cluster, läuft.

OpenShift SRE-Teams behandeln den Betrieb von OpenShift-Clustern, vom Aufbau bis zum Abbau, als ein Softwareproblem. Durch die Anwendung bewährter Methoden aus der Softwareentwicklung auf den Clusterbetrieb können viele der oben genannten Probleme gelöst werden. Die Software kann Unit-Tests unterzogen werden, um sicherzustellen, dass neue Änderungen das bestehende Verhalten nicht beeinträchtigen. Darüber hinaus können Integrationstests sicherstellen, dass die Software wie erwartet funktioniert, auch wenn sich die Umgebung ändert, z. B. wenn eine neue Version von OpenShift veröffentlicht wird.

Anstatt proaktiv auf immer mehr Kundenanfragen zu reagieren, wenn die Akzeptanz des Dienstes wächst, kann das SRE-Team einen Self-Service-Prozess bereitstellen, mit dem die Kunden ihre Cluster bereitstellen und konfigurieren können. Dies verringert auch das Risiko von Schneeflocken, da weniger manuelle Eingriffe durch das SRE-Team erforderlich sind. Was konfiguriert werden kann und was nicht, sollte Teil der Benutzeroberfläche sein, die dem Kunden zur Verfügung gestellt wird. Daher sollten Anfragen, einen einzelnen Cluster anders zu behandeln als alle anderen, in eine Feature-Anfrage für die Automatisierung oder die Benutzeroberfläche umgewandelt werden. Auf diese Weise wird es als unterstützter Zustand enden und nicht als manuelles Konfigurationsupdate.

Um sicherzustellen, dass die Alarmierungsstrategie skalierbar ist, gehen SRE-Teams in der Regel von einer ursachenbasierten Alarmierungsstrategie zu einer symptombasierten Alarmierungsstrategie über und stellen so sicher, dass nur Probleme, die das Nutzererlebnis beeinträchtigen, ihren Pager erreichen. Kleinere Probleme, die nicht sofort gelöst werden müssen, können in eine Ticket-Warteschlange verschoben werden, um sie zu bearbeiten, wenn es die Zeit erlaubt.

Die Umstellung auf eine SRE-Kultur bedeutet, dass die Mitarbeiter ihre eigene Software überwachen und das Team Schritt für Schritt von der Betriebslast befreien. Diese Umstellung braucht Zeit, ist aber ein lohnender Prozess. Aus einem Team, das Software betreibt, die jemand anderes geschrieben hat, wird ein Team, das selbst Software schreibt und betreibt, mit dem Ziel, den Lebenszyklus und den Betrieb der Software unter seiner Kontrolle zu automatisieren. Eine SRE-Kultur ermöglicht Service-Wachstum durch echte Automatisierung und Beobachtung der Kundenerfahrung statt des internen Zustands.

OpenShift als Werkzeug für Site Reliability Engineers

Dieses Buch hilft dir, die Tools zu nutzen, die bereits in OpenShift enthalten sind oder die mit minimalem Aufwand installiert werden können, um Software und OpenShift selbst auf SRE-Art zu betreiben.

Wir gehen davon aus, dass du über ein grundlegendes Verständnis der Funktionsweise von Containern, Kubernetes und OpenShift verfügst, um alle Beispiele zu verstehen und ihnen folgen zu können. Grundlegende Konzepte wie Pods werden nicht in allen Einzelheiten erklärt, aber vielleicht findest du eine kurze Auffrischung, wo wir es hilfreich fanden, einen bestimmten Aspekt von OpenShift zu verstehen.

Wir zeigen dir die verschiedenen Optionen für die Installation von OpenShift und helfen dir dabei, den Lebenszyklus von OpenShift-Clustern nach Bedarf zu automatisieren. Das Lebenszyklusmanagement umfasst nicht nur die Installation und den Abbau von Clustern, sondern auch die Verwaltung der Konfiguration deines OpenShift-Clusters nach dem GitOps-Prinzip. Selbst wenn du dieKonfiguration mehrerer Cluster verwalten musst, kannst du Argo CD auf OpenShift verwenden, um die Konfiguration einer Vielzahl von OpenShift-Clustern zu verwalten.

Dieses Buch zeigt dir anhand einer einfachen Beispielanwendung, wie du Workloads auf OpenShift ausführen kannst. Du kannst dieses Beispiel nutzen, um die Kapitel durchzugehen und die Codebeispiele auszuprobieren. Du solltest jedoch in der Lage sein, dieselben Muster für den Einsatz von ernsthafterer Software zu nutzen, z. B. für Automatisierungen, die du zur Verwaltung von OpenShift-Ressourcen erstellt hast - zum Beispiel einen OpenShift-Operator.

OpenShift bietet auch die Werkzeuge, die du brauchst, um die Erstellung und Bereitstellung deiner Software zu automatisieren, von einfachen automatisierten Container-Builds, wenn du eine neue Änderung eincheckst, über Versionskontrolle bis hin zu vollwertigen benutzerdefinierten Pipelines mit OpenShift Pipelines.

Neben der Automatisierung umfasst die SRE-Methode zur Verwaltung von OpenShift-Clustern auch eine angemessene Alarmierung, die es dir ermöglicht, zu skalieren. OpenShift verfügt über eine Reihe von eingebauten Alarmen, mit denen du informiert werden kannst, wenn in einem Cluster etwas schief läuft. Dieses Buch hilft dir, die Schweregrade dieser Alarme zu verstehen und zeigt dir, wie du deine eigenen Alarme auf der Grundlage von Metriken erstellst, die im eingebauten Überwachungssystem von OpenShift verfügbar sind.

Durch unsere gemeinsame Arbeit als OpenShift SREs bei Red Hat in den letzten zwei Jahren haben wir beide viel über die verschiedenen Arten von Alerts gelernt, die OpenShift ausgibt, und darüber, wie man Probleme untersucht und löst. Der Vorteil der engen Zusammenarbeit mit OpenShift Engineering ist, dass wir sogar zu Alerts in OpenShift beitragen können, wenn wir während unserer Arbeit Probleme damit finden.

Im Laufe der Zeit haben sich eine Reihe von Leuten gemeldet, die sich dafür interessieren, wie wir als SRE-Team arbeiten. Wir stellen fest, dass es ein wachsendes Interesse an allen verschiedenen Themen gibt, die mit unserer Arbeit zu tun haben: Von der Art und Weise, wie wir OpenShift betreiben, bis hin zur Erstellung von benutzerdefinierten Operatoren, zeigen die Leute auf Konferenzen Interesse an dem Thema oder wenden sich direkt an uns.

Dieses Buch soll dir helfen, einige unserer Erkenntnisse zu übernehmen und sie für den Betrieb von OpenShift in deiner spezifischen Umgebung zu nutzen. Wir glauben, dass OpenShift eine großartige Kubernetes-Distribution ist, die eine Menge zusätzlichen Komfort mit sich bringt, der es dir ermöglicht, schnell loszulegen und OpenShift erfolgreich zu betreiben.

Individuelle Herausforderungen für SRE-Teams

OpenShift verfügt über eine Vielzahl von Tools, die dir als Entwickler oder Betreiber in vielen Situationen helfen können. Dieses Buch kann nur einige dieser Tools abdecken und hat nicht den Anspruch, einen vollständigen Überblick über alle OpenShift-Funktionen zu geben. Anstatt zu versuchen, die OpenShift-Dokumentation nachzubilden, konzentriert sich dieses Buch darauf, die Dinge hervorzuheben, von denen wir glauben, dass sie dir den Einstieg in den Betrieb von OpenShift erleichtern werden. Da im Laufe der Zeit immer mehr Funktionen entwickelt und zu OpenShift hinzugefügt werden, ist es eine gute Idee, den OpenShift-Blog und die OpenShift-Dokumentation zu verfolgen, um einen ganzheitlichen Überblick über die Inhalte einer bestimmten Version zu erhalten.

Viele der in diesem Buch behandelten Tools werden derzeit weiterentwickelt, so dass sie sich möglicherweise etwas anders verhalten als zum Zeitpunkt der Veröffentlichung dieses Buches. In jedem Abschnitt wird auf die Dokumentation verwiesen, in der die Verwendung einer bestimmten Komponente genauer erläutert wird. Diese Dokumentation wird in der Regel häufig aktualisiert, so dass du dort aktuelle Informationen findest.

Wenn du Kubernetes als Plattform nutzt, weißt du wahrscheinlich, dass viele Dinge bereits für dich automatisiert sind: Du musst der Control Plane nur mitteilen, wie viele Ressourcen du in deinem Deployment benötigst, und Kubernetes findet einen Knoten, um sie zu platzieren. Du musst ein Rolling Upgrade einer neuen Version deiner Software nicht manuell durchführen, denn Kubernetes kann das für dich erledigen. Du musst lediglich die Kubernetes-Ressourcen nach deinen Bedürfnissen konfigurieren.

Da OpenShift auf Kubernetes basiert, bietet es noch mehr Annehmlichkeiten, wie z.B. das Routing des Datenverkehrs zu deinem Webservice von der Außenwelt aus: Die Freigabe deines Dienstes unter einem bestimmten DNS-Namen und das Routing des Datenverkehrs an den richtigen Ort erfolgt über den OpenShift-Router.

Dies sind nur einige der Aufgaben, die früher vom Betriebspersonal erledigt wurden, aber in OpenShift standardmäßig automatisiert werden können.

Abhängig von deinen spezifischen Bedürfnissen und der Umgebung, in der du OpenShift einsetzt, gibt es jedoch wahrscheinlich einige sehr spezifische Aufgaben, die du selbst lösen musst. Dieses Buch kann dir nicht Schritt für Schritt sagen, was du tun musst, um den Betrieb vollständig zu automatisieren. Wenn es so einfach wäre, sich an jede Umgebung anzupassen, wäre es wahrscheinlich schon Teil von OpenShift. Betrachte dieses Buch also bitte als informativen Leitfaden, aber sei dir bewusst, dass du immer noch einige Probleme lösen musst, damit OpenShift zu deiner Betriebsstrategie passt.

Ein Teil deiner Strategie besteht darin, zu entscheiden, wie und wo du OpenShift installieren willst. Möchtest du einen der Public Cloud-Provider nutzen? Das ist vielleicht am einfachsten zu erreichen, aber du musst OpenShift für einige Workloads vielleicht auch in deinem eigenen Rechenzentrum betreiben.

Der erste Schritt zum Betrieb von OpenShift ist die Einrichtung, und wenn du mehrere OpenShift-Cluster betreiben musst, möchtest du diesen Teil des Cluster-Lebenszyklus wahrscheinlich automatisieren.In Kapitel 2 werden verschiedene Möglichkeiten zur Installation eines OpenShift-Clusters besprochen, vom Betrieb auf einer Entwicklermaschine, was hilfreich sein kann, um Software zu entwickeln, die während der Entwicklung einen laufenden OpenShift-Cluster benötigt, bis hin zu einer öffentlich zugänglichen OpenShift-Bereitstellung über einen Public Cloud-Provider.