Читать книгу Kubernetes - Kelsey Hightower - Страница 18

Neben der Konsistenz, die Kubernetes in Operations mitbringt, sorgt das Entkoppeln und die Separation of Concerns, die durch den Kubernetes-Stack entsteht, für eine deutlich höhere Konsistenz bei den unteren Schichten Ihrer Infrastruktur. So kann Operations viele Maschinen mit einem kleinen, fokussierten Team verwalten. Sie haben schon viel über das Entkoppeln von Anwendungs-Containern und der Maschine beziehungsweise dem Betriebssystem (OS) gelesen, aber ein wichtiger Aspekt dieser Trennung ist, dass die Orchestrierungs-API für die Container zu einem klaren Vertrag wird, der die Verantwortlichkeiten von Anwendungs-Operator und Cluster-Orchestrierungs-Operator aufteilt. Wir nennen dies die »Not my monkey, not my circus«-Linie. Der Anwendungs-Entwickler verlässt sich auf das Service-Level Agreement (SLA) der Container-Orchestrierungs-API, ohne sich um die Details zu kümmern, wie dieses SLA erreicht wird. Genauso konzentriert sich der Techniker, der für die Zuverlässigkeit der Container-Orchestrierungs-API verantwortlich ist, darauf, das SLA der Orchestrierungs-API zu erreichen, ohne sich um die Anwendungen zu kümmern, die darauf laufen.

Dieses Entkoppeln der Verantwortung sorgt dafür, dass ein kleines Team, das ein Kubernetes-Cluster betreut, für die Unterstützung Hunderter oder gar Tausender von Teams verantwortlich sein kann, die Anwendungen in diesem Cluster laufen lassen (Abb. 1–1). Genauso kann ein kleines Team für Dutzende (oder mehr) Cluster zuständig sein, die auf der ganzen Welt verteilt sind. Es ist wichtig, darauf hinzuweisen, dass das gleiche Entkoppeln von Containern und OS es den für die Zuverlässigkeit des OS verantwortlichen Technikern ermöglicht, sich auf das SLA des OS für die einzelnen Maschinen zu konzentrieren. Das führt zu einer weiteren Trennlinie bei der Verantwortung – die Kubernetes-Operatoren bauen auf das SLA des OS und die OS-Operatoren kümmern sich nur darum, dieses SLA zu erfüllen. Auch hier kann so ein kleines Team von OS-Experten eine Flotte mit Tausenden von Maschinen betreuen.

Natürlich liegt ein Team – selbst ein kleines –, das sich nur um ein Betriebssystem kümmert, außerhalb der Möglichkeiten vieler Organisationen. In dieser Situation ist ein gemanagtes Kubernetes-as-a-Service (KaaS) von einem öffentlichen Cloud-Provider eine großartige Alternative. Mit zunehmender Verbreitung von Kubernetes sind auch immer mehr Angebote für KaaS entstanden – heutzutage wird es auf nahezu jeder öffentlichen Cloud angeboten. Natürlich hat der Einsatz von KaaS auch seine Grenzen, da der Operator Entscheidungen zum Aufbau und zur Konfiguration des Kubernetes-Clusters für Sie trifft. So sind beispielsweise auf vielen KaaS-Plattformen Alpha-Features abgeschaltet, weil sie das gemanagte Cluster destabilisieren können.

Abb. 1–1 Eine Möglichkeit, wie die verschiedenen Operations-Teams durch APIs entkoppelt sind

Neben einem vollständig gemanagten Kubernetes-Service gibt es ein wachsendes Ökosystem aus Firmen und Projekten, die dabei helfen, Kubernetes zu installieren und zu warten. Das Spektrum der Lösungen bewegt sich dabei von »auf die harte Tour« bis zu einem vollständig gemanagten Service.

Die Entscheidung, KaaS zu verwenden oder selbst zu managen (oder einen Weg dazwischen zu wählen), ist daher eine, die jede Organisation abhängig von den Fähigkeiten und Anforderungen ihrer Situation selbst treffen muss. Häufig bietet KaaS für eine kleine Organisation eine leicht einsetzbare Lösung, durch die sie ihre Zeit und Energie auf das Bauen von Software konzentrieren kann, mit der sie ihre eigene Arbeit unterstützt, statt sich auch noch um das Managen eines Clusters kümmern zu müssen. Für eine größere Organisation, die sich ein eigenes Team für das Managen ihres Kubernetes-Clusters leisten kann, mag solch ein Team sinnvoll sein, da sie so mehr Flexibilität in Bezug auf Leistungsfähigkeit und Operations erhält.