Aus Versehen mal wieder alle Kubernetes-Cluster in einer Region gelöscht? Kein Problem, das passiert den Besten, erzählte ein Spotify-Mitarbeiter auf der Kubecon in Barcelona.
Mit seiner Failure-Story lieferte David Xia bislang die beste Keynote auf der Kubecon und Cloud Native Con Europe 2019 (kurz: Kubecon). Als Zuhörer hatte sich mengenmäßig eine komplette Kleinstadt zu den morgendlichen Keynotes versammelt.
Spotify betreibt Kubernetes-Cluster in drei Regionen: in Asien, Europa und den USA. Xia hatte einen Testcluster angelegt und sich beim Löschen des Clusters für das falsche Browsertab entschieden. Das zeigte den aktiven Cluster in Europa mit 50 Nodes an. Offenbar macht Googles Cloud sowohl das Anlegen als auch das Löschen von Kubernetes-Clustern besonders einfach. Dank kleiner Bugs auf dem Weg dauerte es dreieinhalb Stunden, das Cluster wieder zu restaurieren.
Upps, we did it again
Später löschten die Spotify-Admins dank eines Terraform-Bedienfehlers sogar zwei Cluster, einen in Asien, einen in den USA. Allerdings Xia würde die Story auf der Bühne vermutlich nicht erzählen, wäre sie nicht gut ausgegangen. Trotz nur einem verbliebenen Cluster kamen keine Spotify-Nutzer zu Schaden.
Drei Weisheiten
Dafür machte Xia vor allem drei Punkte verantwortlich: eine gute Lern- und Fehlerkultur, einen graduellen Wechsel auf Kubernetes und neue Tools sowie das strikte Einhalten von Best Practices. So migrierte Spotify Dienste nur teilweise auf Kubernetes, integrierte Failovers auf andere Cluster außerhalb der Container-Plattform.
Zugleich herrsche bei dem Unternehmen eine produktive Fehlerkultur. Diese kalkuliert Fehler mit ein und versucht die Gründe herauszufinden und die Fehlerquelle zu beheben.
Auch Backups, Restores und eine funktionierende Disaster Recovery gehören zum Standardrepertoire. Inzwischen sei es Spotify möglich, gelöschte Cluster mitsamt den Integrationen in einer Stunde zu restaurieren. Das gelinge auch, weil die Infrastruktur als Code vorliege.
Nicht zuletzt führe der langsame Schritt-für-Schritt-Wechsel auf Kubernetes dazu, dass Ausfälle nicht die komplette Plattform treffen. Erst seit kurzem dürfen endliche sämtliche Teams ihre Dienste auch auf Kubernetes migrieren.
Viele Leute, viele Probleme
Auch Jason McGee wusste eine Geschichte aus der Praxis zu erzählen, in diesem Fall von IBMs Cloudteam. Seine zentrale Aussage: Wenn Du ein kleines Team hast und hunderte oder gar tausende von Diensten betreuen musst: nutze ein einziges Tool. Konkret setzt IBM intern auf Slack. Das diene nicht nur zur Kommunikation der Mitarbeiter untereinander, sondern integriere auch diverse Bots und Chatops, über die sich zahlreiche Dienste anschubsen lassen. Auf diese Weise versammeln sich alle Mitarbeiter um dasselbe Tool und erledigen alles über eine Oberfläche.
Wolle man hingegen herausfinden, was überhaupt für Dienste und Workloads in der eigenen Cloud laufen, rät McGee zu Feature-Flags, Pull-basierten und selbst-aktualisierenden Clustern sowie label- und regelbasierten Konfigurationen.
Kubernetes ist kein Feenstaub
Auch Saad Ali von Google wusste Nützliches zu berichten. Er räumte ein, dass Kubernetes kein Feenstaub sei, mit dem sich der richtige Speichertyp auf magische Weise aussuchen lasse. Vielmehr bleibe dem Admins nichts weiter übrig, als sich seine Anwendung genau anzusehen und dann zu recherchieren.
Immerhin gab Ali den Zuhörern eine Vier-Punkte-Strategie bei der Storage-Auswahl mit auf den Weg: Select, Deploy, Integrate und Consume. Admins müssten unter anderem die Unterschiede zwischen den zahlreichen Speichermodellen und -Typen begreifen und die Anforderungen der Anwendung verstehen. Storage müsse nicht auf Kubernetes liegen. Aber wenn dies der Fall sei, riet er dazu, einen passenden Operator für die Stateful App zu verwenden.
Um den Storage für die App zu integrieren, sei wiederum ein Container Storage Interface als Treiber empfohlen. Das mach es auch über einen weiteren CSI-Treiber möglich, anderen Storage einzubinden. Nicht zuletzt lasse sich Storage bequem über das Portable Kubernetes Storage API anbinden und sei dann im Notfall auch recht einfach zu erweitern. Dennoch gehöre der Umgang mit Storage zu den schwierigsten Aufgaben als Kubernetes-Admin.
Pokémons halfen Kubernetes
Bereits gestern feierte die Kubecon zudem den fünften Geburtstag von Kubernetes. Zu diesem Anlass warf die Keynotes einen Blick zurück, auf die Kubernetes-Anfänge mit Borg. Insbesondere ein bekanntes Spiele habe die Adoption von Kubernetes voran getrieben: Pokémon Go. Die schnell steigende Zahl an Spielern habe beim Skalieren von Kubernetes extrem geholfen.
Für die Zukunft gehe es vor allem darum, das Ökosystem rund um Kubernetes auszubauen, also Plattformen und Frameworks. Man wolle weitere Projekte wie GRPC, Istio oder das Machine-Learning-Toolkit Kubeflow integrieren. In Sachen Skalierbarkeit soll Kubernetes den Daten-Overhead beim Ermitteln von Metriken reduzieren, etwa zum Node-Status.
Service Mesh Interface
Microsofts Gabe Monroy stellte gestern Nachmittag noch das Service Mesh Interface (SMI) vor, was bei den Zuhörern zu spontanem Applaus führte. Das Set von APIs soll die Interoperabilität verschiedener Service-Mesh-Technologien gewährleisten, darunter Istio, Linkerd und Consul Connect. “The problem is developers who turn to mesh technologies must choose a provider and write directly to those APIs. They become locked into a service mesh implementation.”, schreibt Microsoft in der offiziellen Ankündigung.
Generische Interfaces sollen den Vendor-Lock-in also verhindern. Zugleich sollen sie das Netzwerk smart machen. Während die Logik bislang meist in den Routern selbst steckte, würden Technologien wie Cloud Native, Kubernetes und Container intelligentere Netzwerke erfordern.
Die Idee für SMI kommt nicht von Microsoft allein, vielmehr sitzen mit Linkerd, Hashicorp, Solo.io, Kinvolk und Weaveworks noch weitere Unterstützer im Boot. Support für SMI komme aber auch von Aspen Mesh, Canonical, Docker, Pivotal, Rancher, Red Hat und VMware.
