Was ist eine Kubernetes Platform?

Technologie ist einfach. Der menschliche Teil ist der Schwierige. Kommunikation und Terminologie wiederum sind Elemente dieses schwierigen Teils. In diesem Post soll es um den Begriff Platform im Kontext von Kubernetes gehen.

Wir reden von Agile, DevOps, Komplexität. Im Großen sicher nicht, aber haben wir im Kleinen, also innerhalb einer Organisation oder eines Teams ein gemeinsames Verständnis von den Begriffen welche wir täglich nutzen?

Platform: Wir kennen den Begriff aus dem Umfeld von Betriebssystemen (Cross-Plattform) und (Enterprise-)Laufzeitumgebungen (Java Platform, Java Enterprise Edition). Wir verstehen eine Platform als etwas Horizontales „Nicht-Funktionales“. Was ist es im Kontext von Kubernetes?

Eine Kubernetes Application Platform sollte Container basierte Anwendungen/Microservices also unterstützen in den Disziplinen

  • Observability
  • Authentication / Authorization
  • Networking
  • Key Management
  • Storage (Block, Object, File)
  • Databases (Relational, Key-Value, Document, Graph)
  • Continuous Integration/-Delivery
  • Backup/Recovery
  • Messaging

Konzeptionell ist vieles nicht neu. Container bedingen allerdings viele neue Implementierungen:

Die Open Source Upstream Basis Komponenten lassen aus Sicht von Anwendungs-Entwicklern, im Folgenden kurz Entwickler (!= Infrastruktur- / Platform Entwickler) offensichtlich noch sehr zu wünschen übrig. Aus Sicht von Entwicklern ist es schlicht eine zu niedrige Abstraktion. Man merkt es spätestens wenn man versucht mit kubectl zu arbeiten.

  • Muss jeder Entwickler wirklich wissen was ein Deployment, StatefulSet, DeamonSet, Pod, Service, ConfigMap, Secret, PersistentVolume(Claim) etc. sind und wie man damit umgeht?
  • Muss man wissen was ein Controller, eine CustomResourceDefinition oder ein Operator ist und wie diese Dinge arbeiten?
  • Muss man sich den Kopf darüber zerbrechen ob man imperativ oder deklarativ mit kubectl arbeiten sollte?

Ich denke nein. Ich würde sogar soweit gehen zu sagen man sollte Anwendungsentwicklern Kubernetes komplett ersparen können.

Was will ein Anwendungsentwickler eigentlich wirklich von einer Platform? PaaS Anbieter haben sich ausgiebig mit dieser Frage beschäftigt. Zwar nicht Kubernetes, aber schauen wir exemplarisch einfach einmal auf die CLI Hilfe von heroku:

USAGE
  $ heroku [COMMAND]

COMMANDS
  access          manage user access to apps
  addons          tools and services for developing, extending, and operating your app
  apps            manage apps on Heroku
  auth            check 2fa status
  authorizations  OAuth authorizations
  autocomplete    display autocomplete installation instructions
  buildpacks      scripts used to compile apps
  certs           a topic for the ssl plugin
  ci              run an application test suite on Heroku
  clients         OAuth clients on the platform
  config          environment variables of apps
  container       Use containers to build and deploy Heroku apps
  domains         custom domains for apps
  drains          forward logs to syslog or HTTPS
  features        add/remove app features
  git             manage local git repository for app
  help            display help for heroku
  keys            add/remove account ssh keys
  labs            add/remove experimental features
  local           run Heroku app locally
  logs            display recent log output
  maintenance     enable/disable access to app
  members         manage organization members
  notifications   display notifications
  orgs            manage organizations
  pg              manage postgresql databases
  pipelines       manage pipelines
  plugins         list installed plugins
  ps              Client tools for Heroku Exec
  psql            open a psql shell to the database
  redis           manage heroku redis instances
  regions         list available regions for deployment
  releases        display the releases for an app
  reviewapps      manage reviewapps in pipelines
  run             run a one-off process inside a Heroku dyno
  sessions        OAuth sessions
  spaces          manage heroku private spaces
  status          status of the Heroku platform
  teams           manage teams
  update          update the Heroku CLI
  webhooks        list webhooks on an app

Openshift, Garden, Rio, Tilt und Jenkins X sind in diesem Sinne vergleichbare Produkte für Kubernetes. Sie alle sind deutlich näher an den Bedürfnissen von Entwicklern und versuchen Kubernetes mehr oder weniger „verschwinden“ zu lassen. Jenkins X gefällt mir persönlich sehr gut weil sehr ausgereifte Kubernetes CI/CD Workflows für nahezu alle Laufzeitumgebungen git gesteuert out of the Box zur Verfügung stehen. Wer nicht mag sollte sich nicht mehr mit Kubernetes rumschlagen müssen. Zugegeben: On-Prem oder in Nischen Clouds ist Jenkins X heute kein Selbstgänger.

Was macht ein Platform Team?

Grundsätzlich wird ein dediziertes Platform Team erst ab einer gewissen Größe einer Organisation und Menge von Anwendungen Sinn machen. Primäre Aufgabe dieses Teams sollte es sein Entwicklern das Arbeiten mit der Platform so einfach wie möglich zu gestalten – sie sollten sich schließlich auf die Umsetzung der Anforderungen ihrer Kunden (der Business-Units) fokussieren.

In einer reifen Cloud-Umgebung „verschwinden“ viele Aspekte der Platform-Komplexität („Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.“). Man selbst hat nur noch wenig Arbeit mit diesen Dingen weil der Cloud (☝️Platform) Provider gut genug war sie verschwinden zu lassen ??. Otto beschreibt seinen Weg auf AWS und Erfahrungen im Kontext Platform im Post OTTO goes AWS – Teil 2.

Wie geht man mit einer Situation um wo man es mit einer weniger ausgereiften Umgebung zu tun hat? Wo gewisse essentielle Dienste womöglich fehlen? Sollte man selbst implementieren? (Und betreiben? Und langfristig warten?)

Pauschal kann man diese Fragen natürlich nicht beantworten. Ich denke man sollte vor allem ehrlich mit sich selbst sein und eigene Fähigkeiten nicht überschätzen bzw. Komplexität unterschätzen (Nerds neigen dazu). Ein guter Anwendungs-Entwickler ist noch lange kein guter Infrastruktur- oder Platform-Entwickler (Was ist eigentlich ein DevOps Engineer?)

In jeden Fall sollte man sich Zeit für ein gemeinsames Verständnis der Begriffe und Klarheit in Bezug auf Verantwortung nehmen.

Von autonomen Vertikalen haben wir inzwischen ein relativ gutes Verständnis. Wie in so einem Umfeld horizontale Plattform Dinge langfristig funktionieren scheint deutlich unklarer – insbesondere in Bezug auf die erforderlichen Strukturen in der Organisation und Planung. Make Boring Plans bietet viele wertvolle Anregungen Kontext Plattform.

Andreas Steffan
Pragmatic ? Scientist and DevOps Mind @ Contentreich. Believes in Open Source, the Open Web and Linux. Freelancing in DevOps-, Cloud-, Kubernetes, JVM- and Contentland and speaks Clojure, Kotlin, Groovy, Go, Python, JavaScript, Java, Alfresco and WordPress. Built infrastructure before it was cool. ❤️ Emacs.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.