NETWAYS Blog

Kubernetes 101: Die nächsten Schritte

von Daniel Bodky | Feb 22, 2024 | Container, Cloud Native, Kubernetes

This entry is part 7 of 7 in the series Alles rund um Kubernetes

Im Laufe des letzten Jahres haben wir uns in dieser Blogserie ausführlich mit Kubernetes beschäftigt. Von leicht verständlichen Erklärungen zu Design und Funktionsweise über den Aufbau eines ersten (lokalen) Clusters bis hin zur Inbetriebnahme und Absicherung haben wir viele Aspekte behandelt.
Im besten Fall konntest du erste Erfahrungen zu sammeln und vielleicht schon die eine oder andere Anwendung eigenständig bereitstellen. Die naheliegende Frage ist nun, „wohin“ geht die Reise von hier aus?

In diesem letzten Artikel unserer Serie werde ich daher einige Ausblicke geben. Was ist im täglichen Betrieb zu beachten? Wie wird das System heute noch genutzt? Und welche neuen Einsatzmöglichkeiten zeichnen sich gerade ab? Vielleicht ist ja der eine oder andere Anwendungsfall auch für dich interessant!

Kubernetes im Alltagsbetrieb

Nachdem du dein(e) Cluster eingerichtet hast, beginnt der Alltagsbetrieb in der schicken, neuen Cloud-nativen Umgebung. Und hier kann es (ungewollt) spannend werden! Die verteilte Architektur und das generelles Design erfordern eine andere Herangehensweise als in traditionellen IT-Umgebungen. Insbesondere beim Monitoring bzw. Observability oder beim Backup-Management.

Werden Anwendungen auf Kubernetes betrieben, reicht es nicht aus, nur die laufenden Anwendungen zu sichern und in das Monitoring einzubinden. Man muss sich auch um die zugrundeliegende Infrastruktur kümmern! Die Gründe hierfür sollten klar sein: Verliert man die Zustandsinformationen der Kubernetes-API in etcd, ist ein Betrieb nicht mehr möglich. Ist der Cluster selbst kompromittiert, sind auch die darauf laufenden Applikationen in Gefahr. Es gilt also, aufzupassen und vorzusorgen.

Zum Thema Sicherheit auf gibt es in dieser Blogserie bereits einen eigenen Beitrag, die wichtigsten Punkte möchte ich aber noch einmal zusammenfassen:
Anwendungen auf Kubernetes werden in der Regel als containerisierte Microservices betrieben, die über das clusterinterne Netzwerk miteinander kommunizieren. Eine entsprechende Absicherung der verwendeten Netzwerke, sowohl an den Clustergrenzen als innerhalb des Clusters, ist daher zwingend erforderlich. Hierzu gibt es die Möglichkeit der nativen Fähigkeiten von Kubernetes selbst (Stichwort NetworkPolicies) oder man greift auf externe Tools zurück, die in ihrem Funktionsumfang weniger eingeschränkt sind (z.B. CNIs wie Cilium oder Calico).

Darüber hinaus sollten auch die betriebenen Container selbst unter die Lupe genommen werden: Nutzen sie vulnerable Abhängigkeiten, benötigen sie alle zugewiesenen Privilegien, und wie sieht es mit der Aktualität der Images selbst aus? Für all diese Fragen gibt es Tools, die die Umsetzung erleichtern – von Imagescannern wie Trivyoder Docker Scoutbis zur Echtzeiterkennung von Sicherheitsproblemen mit NeuVector von unserem Partner SUSE.

Das Ökosystem bietet auch Lösungen für das Backup-Management: Angefangen bei Kasten, einer Enterprise-Backuplösung von Veeam, über Velero, einer FOSS-Lösung für Backups von Clusterzustand und PersistentVolumes, bis hin zu Kanister (ebenfalls von Veeam), das Backup-Management auf Anwendungsebene ermöglichen soll.
Je nach Anwendungsfall und Clusterspezifikationen (Anzahl an Nodes, onPrem vs. Cloud, etc.) wirst du dich wahrscheinlich für eine bestimmte Backup-Lösung und einen speziellen Ansatz für das Backup-Management wählen.
Mit den genannten Lösungen kannst du aber definitiv deine ersten Schritte gehen.

Kubernetes als Infrastruktur-Plattform

Ein stetig wachsender Anwendungsfall ist der Einsatz als zentrale Infrastruktur-Management-Plattform. Dank zahlreicher (Open-Source-) Projekte im Cloud-nativen Ökosystem ist Crossplane heute in der Lage, Ressourcen wie S3-Buckets, Cloud-VMs oder gemanagte Datenbanken in verschiedenen Public Clouds zu provisionieren und zu verwalten.

Du kannst das System auch als Hypervisor für deine VM-Flotte verwenden Möglich macht dies das Projekt kubeVirt, das KVM-VIrtualisierung auf Kubernetes bringt – alles unter einem Dach, quasi! kubeVirt selbst ist ein Projekt innerhalb der CNCF, das unter Anderem von namhaften Firmen wie SUSE, RedHat oder ARM unterstützt wird.

Kubernetes als Management-Plattform

Doch nicht nur für Infrastruktur kann Kubernetes als Plattform herhalten. Es bietet auch die Möglichkeit, dass andere Benutzer in der Organisation die zentrale Schnittstelle für Ihre tägliche Interaktion mit eurer IT-Landschaft werden. Das Schlagwort für diese Art der Nutzung lautet Internal Development Platform (IDP) und ist eines der Themen, die derzeit stark im Kommen sind:
Vorgelebt von Spotify und seiner modularen Plattform Backstage gibt es mittlerweile eine ganze Reihe von kommerziellen und nicht-kommerziellen Lösungen, die Entwicklern in Zeiten von SaaS-Lösungen und immer komplexeren Entwicklungsumgebungen helfen können, den Überblick zu behalten.

Ziel von IDPs ist es, verschiedene Informationen rund um den Entwicklungszyklus zusammenzuführen, Prozesse zu vereinheitlichen und „Golden Paths“ zu etablieren. Mit seiner mächtigen API und seinen Orchestrierungsmöglichkeiten bietet sich Kubernetes für so ein Vorhaben an. Schließlich sollen verschiedenste Drittanwendungen mit der Plattform interagieren, Informationen bereitstellen und im Gegenzug Anweisungen von der Plattform erhalten. Nicht umsonst ist das Thema „Kubernetes als IDP“ also eines der derzeit „heißesten“ Themen auf Konferenzen wie z.B. der KubeCon.

Fazit

Kubernetes wird nicht langweilig und bietet viele Möglichkeiten zur Erweiterung und zum Ausbau. Das ist ein bisschen Fluch und Segen zugleich. Denn mit den Vorteilen entstehen auch neue Risiken. Es kann sinnvoll sein klein anzufangen, sein(e) Cluster nach und nach zu erweitern und an neue Anwendungsfälle anzupassen.
Eine der wichtigsten Regeln ist, von der ersten Minute an Sicherheit und Observability zu bedenken. Das Risiko einer unentdeckten Schwachstelle ist ansonsten aufgrund der verteilten Architektur und den darauf laufenden Anwendungen schwer zu überblicken.

Wenn du nach der Lektüre dieser Serie Lust bekommen hast loszulegen, du dich aber noch nicht zu 100% bereit fühlst direkt loszulegen, ist vielleicht unser Kubernetes Training etwas für dich!
Ansonsten kannst du jederzeit unser Sales Team kontaktieren, und mit einem unsere Kubernetes-Spezialisten über deine Fragen sprechen.

Daniel Bodky

Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Lies mehr von Daniel und triff unser Team

CfgMgmtCamp 2024: Unser Rückblick

von Daniel Bodky | Feb 14, 2024 | Web Services

Vergangene Woche fuhr ein Teil unseres Teams bei NWS bis nach Ghent in Belgien, um am ConfigManagementCamp 2024 teilzunehmen.
Hierbei handelt es sich um eine kostenlose Konferenz, direkt im Anschluss an die FOSDEM, was Jahr für Jahr für ein großes Publikum aus Fans von Open Source, guten Gesprächen und neuen Ideen sorgt. Auch dieses Jahr war das nicht anders, und so wollen wir in diesem Artikel noch einmal auf das CfgMgmtCamp 2024 zurückblicken.

Die ollen Zuverlässigen

Configmanagement als Aufgabenbereich ist bereits seit Längerem eine Notwendigkeit im alltäglichen Betrieb von IT-Infrastruktur und Software. So ist es nur natürlich, dass es inzwischen eine Riege etablierter, „oller“ Lösungen gibt, z.B. Puppet, Terraform oder Ansible.
Es war schön zu sehen, dass die Projekte und ihre jeweiligen Ökosysteme weiterhin voller Leben sind: Egal ob event-driven Ansible oder neue ‚Hacks‘ im Umgang mit Puppet, es gab auf jeden Fall noch Neues zu lernen!

Spongebob Schwammkopf Meme "Ol' Reliable"

Ansible, Terraform und Konsorten sind weiterhin zuverlässige Wegbegleiter im Configmanagement

Terraform und sein brandneuer Fork OpenTofu, der im Januar seinen ersten stabilen Release feiern durfte, waren ebenfalls Thema einiger Talks.
Die Tatsache, dass OpenTofu innerhalb von fünf Monaten von Fork zu Stable Release gelangen konnte, zeigt gut, wie wichtig der Community das Projekt ist.
Es wird spannend zu sehen sein, wie sich die beiden Projekte weiter (auseinander) entwickeln.

Noch erwähnenswert ist, dass sowohl Puppet Labs als auch Ansible als Sponsoren am CfgMgmtCamp 2024 auftraten, sodass man sich direkt ‚an der Quelle‘ mit Maintainern und der Community austauschen konnte.

Neues Jahr, Neue Tools

Natürlich waren wir nicht nur vor Ort, um unser Wissen rund um existierende Tools zu vertiefen, wir wollten auch Neues kennenlernen!
Hierzu gab es so einige Möglichkeiten:

Pkl ist eine Konfigurationssprache, die intern bei Apple genutzt wird. Apple hat sich 3 Tage vor dem CfgMgmtCamp dazu entschlossen, diese zu opensourcen. Einen ersten Eindruck konnten wir beim weltweit ersten Talk zu Pkl erhalten:
Die Konfigurationssprache erlaubt es einem, typisierte und durchweg validierte Konfigurationen zu erstellen, die dann in Formate wie YAML oder JSON exportiert werden können. Genaueres findet man auf der Projektwebsite oder im GitHub-Repository des Projekts

Ein weiteres interessantes Projekt, das am CfgMgmtCamp 2024 vorgestellt wurde, ist winglang. Die zugrundeliegende Idee, eine Programmiersprache für Infrastruktur und Code zu haben, fand viel Anklang.
Winglang fokussiert sich dabei auf die Abstraktion der verschiedenen Bausteine „in er Cloud“, um das Definieren von Workloads und Infrastruktur zu erleichtern.
Uns gefiel vor allem der lokale Simulator, der die definierten Ressourcen und das Verhalten der Workloads in Echtzeit wiederspiegelt.

Die dritte Neuheit, die wir nicht unerwähnt lassen wollen, ist System Initiative, ein ‚collaborative power tool designed to remove the papercuts from DevOps work‘. Du kannst es Dir vorstellen wie DrawIO für Infrastructure, mit Multiplayer-Support: Es ist eine GUI mit einer Vielzahl an Cloud-Komponenten, mit denen Du deine Infrastruktur in den Wolken bauen kannst.
System Initiative gleicht im Hintergrund konstant die Korrektheit und den Zustand Deines Projekts mit der Cloud Deines Vertrauens ab.

Unsere Erkenntnisse vom CfgMgmtCamp 2024

Rückblickend konnten wir zwei grundsätzliche Erkenntnisse mit nach Nürnberg nehmen:

Niemand mag YAML, sogar im ‚YAMLCamp‘ – Ansätze wie CUElang, Pkl und winglang deuten mehr als offensichtlich darauf hin.
Ob Sprachen mit strikteren Regeln hinsichtlich Korrektheit der richtige Weg sind, um am Ende dann doch YAML zu generieren, wird sich noch zeigen müssen.

Ansible, Puppet und Terraform sind nachwievor relevant. Wir konnten auch dieses Jahr wieder Neuerungen, Weiterentwicklungen und lebhafte Diskussionen rund um die Tools und ihre jeweiligen Ökosysteme beobachten. Außerdem hat die Open Source Community im vergangenen Jahr eindrucksvoll gezeigt, dass sie die Dinge auch selbst in die Hand nehmen kann, falls nötig (Hallo, OpenTofu!).

Für uns besonders interessant waren einige der Talks rund um Terraform und Ansible, da wir diese rund um OpenStack ebenfalls nutzen: Sei es im Zusammenspiel von OpenStack mit Terraform oder dem Erzeugen dynamischer Inventare unserer Infrastruktur in der Cloud für Ansible.

Und solltest Du Dich noch nicht bereit fühle, direkt ins tiefe Wasser des Configmanagements zu springen, sind ja auch noch unsere MyEngineers bereit, Dir jederzeit zu helfen.

Daniel Bodky

Platform Advocate

Lies mehr von Daniel und triff unser Team

Kubernetes 101: Wie sichere ich Kubernetes ab?

von Daniel Bodky | Okt 9, 2023 | Cloud Native, Kubernetes

This entry is part 6 of 7 in the series Alles rund um Kubernetes

In meinen bisherigen Blogposts habe ich dir bereits einige wichtige Aspekte von Kubernetes näher gebracht. Von „Was ist Kubernetes“ über „Wie richte ich Kubernetes auf Linux ein“ zu „Wie installiere ich eine Anwendung in Kubernetes“. Im besten Fall hast du nun bereits Erfahrung in einer laufenden Umgebung sammeln können und bist bei der sogenannten „Day 2 Operation“, also dem alltäglichen, laufenden Betrieb angekommen. Eine Sache, die ich bisher allerdings ein wenig vernachlässigt habe, ist die Absicherung eines Kubernetes Clusters und der darin befindlichen Workloads.
In diesem Punkt ist Kubernetes‚ offener Standard Fluch und Segen gleichzeitig: Während die einfach erweiterbare Funktionalität ein großes Plus von Kubernetes ist, ist das Fehlen (fast) jeglicher Konfiguration von Security und Policing „out of the box“ definitiv ein großes Minus.
Deswegen zeige ich dir in diesem Beitrag, wie du in diesem Bereich nachbesserst!

Wie ist Kubernetes aufgebaut?

Wenn du meine bisherigen Blogposts verfolgt hast (oder bereits Erfahrung mit Kubernetes gesammelt hast) weißt du: Kubernetes ist ein verteiltes System.
Auf mehreren Nodes werden containerisierte Workloads geplant, die dann die eigentlichen Anwendungen ausführen. Hinzu kommen je nach Kubernetes-Distribution mehrere lokal auf dem jeweiligen Node laufende Services (bspw. Kubelet, kube-apiserver, containerd, etc.) sowie Container, die aufgrund ihrer Aufgaben manchmal erweiterte Privilegien auf den Nodes genießen. Etwa um den clusterinternen Netzwerkverkehr zu regeln oder im Cluster verteilten Speicher bereitstellen zu können.
Es gibt also eine einigermaßen klare Trennung zwischen Clusterinfrastruktur und Workloads, die in einer idealen Welt auch nur wenig miteinander zu tun haben (sollten). Eine Anwendung sollte schließlich in der Lage sein, ordnungsgemäß laufen zu können, ohne dass sie Kenntnisse über ihre Laufzeitumgebung (in diesem Fall Kubernetes) besitzt.
Wie klar diese Trennung in der Realität auch ausfallen mag, im Folgenden werde ich die zwei Welten und mögliche Ansatzpunkte für mehr Sicherheit getrennt voneinander betrachten.

Clustersicherheit bei Kubernetes

Wie bereits eingangs erwähnt, ist ein Kubernetes Cluster nach seiner Installation nicht unbedingt umfassend abgesichert – das beginnt bereits beim Zugriff auf das Kubernetes Cluster. Die kubeconfig, mit der du als Admin normalerweise arbeitest, ist mit maximalen Privilegien ausgestattet und sollte unter keinen Umständen verteilt oder von anderen Nutzern verwendet werden.
Deshalb solltest du weiteren User:innen einen alternativen Clusterzugriff (und damit verknüpfte Regeln) einrichten.

Zugriff und Zugriffskontrolle einrichten

Von Haus aus besitzt Kubernetes ein feingranular einstellbares RBAC-System (Role-based Access Control), mit dem sich grundsätzlich gut arbeiten lässt: Mittels (Cluster-)Roles, (Cluster-)RoleBindings und Usern bzw. ServiceAccounts lassen sich Verknüpfungen zwischen beliebigen Sets an Privilegien und einzelnen, im Cluster agierenden, Identitäten herstellen.
Für jede Gruppe an existierenden API-Objekten können durch Verbs die Privilegien entweder auf Namespace– oder auf Cluster-Ebene eingestellt werden. Die verfügbaren Verbs sind get, list, create, update, patch, watch, delete, und deletecollection und implizieren verschiedene Privilegien für die verknüpften API-Objekte.

Möchtest du eine hierarchische Struktur mehrerer Rollen erreichen, kannst du mehrere Clusterrollen zu einer übergeordneten Clusterrolle aggregieren. Auf diese Weise behältst du den Überblick, auch wenn die Anzahl an verfügbaren Rollen mit der Zeit wachsen sollte.
Überblick ist zudem ein gutes Stichwort, denn ab einer gewissen Anzahl an Rollen, Nutzern und Verknüpfungen zwischen den beiden Konzepten leidet unweigerlich die Übersichtlichkeit des Berechtigungskonstrukts. Zwar liefert Kubernetes‘ CLI kubectl mit dem Cmdlet auth can-i eine Möglichkeit des Auditings mit (siehe Auflistung aller Berechtigungen des Standard-Adminusers für den Namespace default unten), das Gelbe vom Ei ist dieser Ansatz der Nutzerverwaltung ab einer gewissen Clustergröße nicht mehr.

Oder möchtest du regelmäßig für alle User deines Clusters manuell die Berechtigungen prüfen?

kubectl auth can-i --list --namespace=default
Resources                                       Non-Resource URLs   Resource Names   Verbs
*.*                                             []                  []               [*]
                                                [*]                 []               [*]
selfsubjectaccessreviews.authorization.k8s.io   []                  []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                  []               [create]
                                                [/api/*]            []               [get]
                                                [/api]              []               [get]
                                                [/apis/*]           []               [get]
                                                [/apis]             []               [get]
                                                [/healthz]          []               [get]
                                                [/healthz]          []               [get]
                                                [/livez]            []               [get]
                                                [/livez]            []               [get]
                                                [/openapi/*]        []               [get]
                                                [/openapi]          []               [get]
                                                [/readyz]           []               [get]
                                                [/readyz]           []               [get]
                                                [/version/]         []               [get]
                                                [/version/]         []               [get]
                                                [/version]          []               [get]
                                                [/version]          []               [get]

Eine bessere Verwaltungsmöglichkeit für unsere Kubernetes Cluster User ist also dringend angeraten, sowohl aus Gründen der Übersichtlichkeit als auch der Sicherheit. Bei immer mehr Nutzern und komplexeren Berechtigungsstrukturen ist es sonst nur eine Frage der Zeit, bis bei einem Nutzer die falschen Berechtigungen gesetzt werden. Schaut man sich das Angebot an verfügbaren Lösungen für Zugriffskontrolle auf Kubernetes an, stechen ein paar Projekte heraus:

Als SUSE Partner setzen wir bei mehreren Kunden erfolgreich Rancher ein, ein Open-Source Tool zur ganzheitlichen Verwaltung von Clustern in der Cloud und on premise. Rancher setzt mit seinem Berechtigungskonzept direkt auf Kubernetes‘ RBAC-Modell auf und erweitert es um Projekte, die eine Abstrahierung um einen oder mehrere Namespaces bilden.
Das Web-Frontend bietet die Möglichkeit, (Cluster-)Rollen mit einzelnen Usern oder Usergruppen aus der in Rancher integrierten Benutzerverwaltung zu verknüpfen, zu auditieren und sich einen schnellen Überblick darüber zu verschaffen, welcher User in welchem Cluster welche Berechtigungen hat.

Grundlage für das Berechtigungskonzept sowohl in Rancher’s WebUI als auch in den verwalteten Clustern bieten die vielen verschiedenen Authentifizierungsplugins: Rancher unterstützt LDAP (z.B. Active Directory, OpenLDAP, AzureAD), OAuth (z.B. Google, GitHub), OIDC (z.B. Keycloak) und SAML (z.B. Okta, Shibboleth, ADFS).

Ein weiteres bewährtes Tool zur Zugriffskontrolle für u.A. Kubernetes ist Teleport, das ebenfalls eine Open-Source Software ist und kostenlos genutzt werden kann. Teleport fungiert als vorgelagerter Proxy, der die Anfragen an das Cluster terminiert, den Nutzer authentifiziert und authorisiert und diese Anfragen dann weitergibt. Stärken von Teleport sind zum Beispiel Policy-as-Code, umfangreiche Auditierbarkeit aller Zugriffe und vergangenen Sitzungen sowie die Kompatibilität nicht nur mit Kubernetes, sondern auch anderen gemanagten oder selbst betriebenen Services und Cloudressourcen.

Netzwerkabsicherung bei Kubernetes

Die Zugriffskontrolle für Endnutzer und Serviceaccounts, also handelnde Identitäten, haben wir nun abgearbeitet. Doch wie steht es mit Zugriffsversuchen, die von Services inner- und außerhalb des Clusters stammen und anderweitig beschränkt werden müssen? Schließlich besteht je nach Architektur und genutzten Dritt-Tools selbst ein „leeres“ Cluster aus (bis zu) mehreren hundert Containern, die untereinander kommunizieren (wollen), sich Updates aus dem Internet ziehen oder andere Services innerhalb der Infrastruktur deines Unternehmens (z.B. AD-Server) erreichen müssen.

Per Default können all diese Container das auch erst einmal ungestört. Kubernetes besitzt out-of-the-box kein Konzept einer „Firewall“ oder ähnlicher Maßnahmen, die den Netzwerkverkehr einschränken könnte. Weder in Ost-West, noch in Nord-Süd-Richtung, übrigens. Hierfür bedarf es eines Container Network Interfaces (CNI), das in der Lage ist, NetworkPolicies zu interpretieren und umzusetzen.
NetworkPolicies sind ein natives Konzept der Kubernetes-API, deren Umsetzung aber an externe CNIs übergeben wird. Ohne passendes CNI also keine Einschränkung des Netzwerkverkehrs.

Das Angebot an verfügbaren CNIs ist recht groß, beliebte Lösungen mit Support für NetworkPolicies auf Namespaceebene und teilweise einer ganzen Bandbreite weiterer Features (BGP-Routing, Nodefirewall, Networkpolicies auf Clusterebene) sind bspw. Cilium bzw. Calico.

„Best Practices“ für das Einrichten von Networkpolicies in Kubernetes gibt es wie Sand am Meer. Welche Blaupause für dein Unternehmen sinnvoll und geeignet sein könnte, ist meist eine Einzelfallentscheidung. Ein oft gesehenes Muster ist eine „globale“ NetworkPolicy über alle Namespaces hinweg (das CNI muss dieses Feature mitbringen!), die keinerlei Ingress bzw. Egress bis auf Anfragen an den clusterinternen DNS-Service erlaubt.
Auf diese Weise sperrst du sämtlichen Netzwerkverkehr, der nicht innerhalb eines einzigen Namespaces stattfindet und etablierst ein „Opt-in“-Modell, bei dem die Operatoren der Anwendungen bei Deployment die benötigten Networkpolicies mitdeployen müssen. Einziges Caveat hierbei ist, dass eventuell bereits vorhandene Infrastruktur im Cluster natürlich ebenfalls von den Regelungen betroffen ist. Es ist deshalb ratsam, dass also ein etwas genauerer Namespace-Filter als „alle Namespaces“ zum Einsatz kommt.

Ressourcenverwaltung in Kubernetes

Ein weiterer wichtiger Punkt neben Zugriffskontrolle und Netzwerkpolicies ist das Verwalten der im Cluster vorhandenen Ressourcen. Der Grund hierfür ist einfach – hat ein Pod die Möglichkeit, alle Ressourcen eines Nodes für sich zu beanspruchen, nimmt er allen anderen Workloads auf diesem Clusternode buchstäblich die Luft zum Atmen. Doch nicht nur „herkömmliche“ Ressourcen wie Arbeitsspeicher und CPUs sollten reguliert sein – auch abstraktere Dinge wie PIDs oder Sockets können zum Problem werden – die in Pods laufenden Container befinden sich schließlich nach wie vor in Namespaces des jeweiligen Nodes. Spielt ein Container verrückt, kann das unangenehme Nachwirkungen für den gesamten Node nach sich ziehen. So kann beispielsweise mit einer Fork Bomb ein Denial of Service (DoS) erreicht werden.

Fälle wie oben beschrieben gilt es natürlich zu unterbinden – für Arbeitsspeicher und CPUs lässt sich das entweder auf Container– oder Namespaceebene umsetzen: Für Container innerhalb eines Pods können unterhalb des Felds resources sowohl requests als auch limits gesetzt werden. Was hier konkret eingetragen werden sollte, um einen möglichst reibungslosen Betrieb bei möglichst kompletter Auslastung eines Nodes durch die dort geschedulten Workloads herzustellen, ist eine seit Jahren diskutierte Frage. Die inzwischen häufigste Antwort lautet:

Für CPUs sollten Requests, aber keine Limits gesetzt werden. Für Arbeitsspeicher sollten Requests==Limits gesetzt werden.

Die Gründe für diese Richtlinie mögen etwas unklar sein, ohne tiefer darauf einzugehen, deswegen verlinke ich an dieser Stelle zwei Blogposts – einen zum Thema CPU-Limits und einen zu Memory-Limits, inklusive lustiger Vergleiche 😉.

An dieser Stelle neben den gängigsten Verwaltungseinstellungen für CPUs und Arbeitsspeicher auf all die anderen zu berücksichtigenden Stellschrauben für sichere Workloads in Kubernetes einzugehen, würde den Rahmen dieses als Überblick gedachten Posts sprengen – deswegen hier nur eine kurze Auflistung einiger Dinge, die man im Hinterkopf behalten sollte:

PID Limits für Pods, Nodes und PID-based eviction
(un)privilegierte Container
Sicherheitskontexte für Container
zusätzliche Policies (bspw. Nutzung von ausschließlich signierten Images)
Handhabe von Secrets (bspw. Verschlüsselung at rest)

Nodesicherheit sicherstellen

Neben den einzelnen Workloads und Netzwerkverkehr im Cluster muss man natürlich auch die Nodes, aus denen das Cluster besteht, ordentlich absichern. Insbesondere gilt es, die Nodes des Controlplanes, auf denen typischerweise auch etcd mitläuft, abzusichern – Zugriff auf etcd ist gleichzusetzen mit unbegrenztem schreibenden Zugriff auf das Cluster selbst.

Für die Absicherung von Nodes können klassische Technologien wie lokale Firewalls, SELinux oder AppArmor und beliebige weitere Härtungsmaßnahmen zum Einsatz kommen. Doch auch hier gibt es einige Cloud-Native-Technologien, die helfen können:
So unterstützen einige CNIs das Einrichten von Networkpolicies auf Node-Level. Mit nur einem Tool kann also nicht nur Netzwerkverkehr im Cluster reguliert werden, sondern in erweitertem Rahmen auch schon auf den vorgelagerten Nodes selbst.

Darüber hinaus gibt es einige Tools, die in der Lage sind, die komplexen Abläufe, die im Kontext von Kubernetes im Kubelet, den Pods und der Containerlaufzeitumgebung vor sich gehen, zu durchleuchten und ungewünschtes Verhalten zu unterbinden. Oftmals kommt hierbei eBPF zum Einsatz, eine Technologie, die die modulare Erweiterung des Betriebssystemkernels mit kleinen Programmen ermöglicht.

Anwendungssicherheit erhöhen

Ist das Cluster erst einmal abgesichert, kann man sich den darauf betriebenen Anwendungen widmen – auch wenn einige Mechanismen aus dem vorherigen Abschnitt bereits greifen sollten, beispielsweise Netzwerkpolicies und Ressourcenverwaltung.
Damit ist es jedoch in vielen Organisationen nicht getan – vielleicht gibt es Richtlinien, welche Images genutzt werden dürfen, aus welchen Registries sie bezogen werden sollen, ob gewisse Scans laufen müssen oder ob gewisse Signaturen erforderlich sind. Und übrigens dürfen auch anfangs grob geschätzte Ressourcenlimits anhand der tatsächlichen Leistungsdaten angepasst werden 😉.

Für viele dieser Zwecke gibt es Werkzeuge, die das Einrichten individueller Policies im Cluster ermöglichen. Die am weitesten verbreiteten sind zum Einen der Open Policy Agent und zum Anderen Kubewarden. Mit solchen Tools lassen sich verschiedenste Policies entsprechend den Vorgaben eurer Organisationen und Prozesse definieren die -as-Code vorliegen, versioniert und deployed werden können.

Für das Scannen von Workloads und deren Konfiguration gibt es ebenfalls etablierte Lösungen zum Beispiel Trivy oder Kubescape.
Beide Lösungen ermöglichen die Integration von CI/CD-Pipelines, um Sicherheitsrisiken und Misskonfigurationen noch vor Deployment zu bemerken und darauf reagieren zu können.
Trivy bietet darüber hinaus einen Operator, der in regelmäßigen Abständen aus dem Cluster herausselbstständig nach Sicherheitslücken suchen kann.

Für das Finetuning von Ressourcenrequests oder -limits benötigst du hingegen in erster Linie Metriken. Diese können aus verschiedenen Quellen stammen, die sich unter dem Begriff Observability zusammenfassen lassen. Mit Hilfe von Prometheus können so zum Beispiel Performancedaten wie genutzter Arbeitsspeicher, CPU-Last, Netzwerkverkehr auf Anwendungsebene nachvollzogen werden, sofern die Anwendung entsprechend instrumentalisiert wurde.
Mithilfe dieser Daten lassen sich dann Rückschlüsse ziehen ob wir mit unseren initial gewählten Ressourcerequests/limits zu großzügig oder doch eher zu optimistisch umgegangen sind und nun nachbessern.

Ein weiteres Tool zur Erkennung von zu lockeren oder fehlenden Ressourcerequests/limits ist KRR (Kubernetes Resource Recommender), das ebenfalls anhand von Prometheus-Daten die bestehenden Konfigurationen für Pods analysiert und Verbesserungen vorschlägt.

Zu voll umfänglicher Anwendungssicherheit gehört jedoch auch die Absicherung und Überwachung der CI/CD-Pipeline mit der die Anwendung erstellt bzw. ausgeliefert wird. Hier empfiehlt sich die Orientierung an Frameworks wie SLSA (Supplychain Levels for Software Artifacts), eine von Google veröffentlichte Sammlung an Empfehlungen für Software-Entwickler, wie und wo sie ihre Anwendungen härten sollten.
Zusätzlich lassen sich Anwendungen auch im Betrieb in Kubernetes (automatisiert) überwachen. So erlauben Tools wie NeuVector, in Containern ausgeführte Prozesse und versuchte/erfolgte Netzwerkaufrufe zu protokollieren, gewünschtes Verhalten zu „erlernen“ und nicht vorgesehene Aufrufe in Echtzeit zu unterbinden.

Fazit

Am Ende eines weiteren Blogposts in unserer „Kubernetes 101“ Reihe angekommen stellen wir einmal mehr fest: Kubernetes ist komplex.

Eine Vielzahl an Tools können in Sachen Security in Betracht gezogen haben und welcher „Stack“ letzten Endes für eure Anforderungen ausreichend und passend ist muss sich oft erst einmal herausstellen. Nicht zur Diskussion steht, dass eben aufgrund dieser Komplexität eine voll umfängliche Absicherung des Clusters als Plattform und der darin laufenden Anwendungen (ab dem Moment ihrer Entwicklung) oberste Priorität haben sollte. Denn ist erst einmal „der Wurm drin“ kann es ansonsten schwierig werden, Sicherheitslücken klar zu benennen, „den Schuldigen“ zu finden und das Ausmaß der Kompromittierung einzuschätzen.

Sollte dir dieser Blogpost gefallen haben, schau doch gerne noch die anderen in dieser Serie erschienenen Artikel an.
Und solltest du auf den Geschmack gekommen sein, aber an manchen Stellen noch Hilfe in Sachen Kubernetes brauchen, schau entweder einmal bei unseren Trainings zum Einstieg in Kubernetes vorbei oder buche direkt Consulting zu (fast) Allem rund um Kubernetes bei mir oder meinen Kolleg:innen.

Daniel Bodky

Platform Advocate

Lies mehr von Daniel und triff unser Team

NETWAYS stellt sich vor – Daniel Bodky

von Daniel Bodky | Jul 28, 2023 | NETWAYS

This entry is part 54 of 62 in the series NETWAYS stellt sich vor

Name: Daniel Bodky

Alter: 25

Studium: B.A. Linguistische Informatik

Position bei NETWAYS: Consultant

Bei NETWAYS seit: Oktober 2021

Wie bist Du zu NETWAYS gekommen und was genau gehört zu Deinem Aufgabenbereich?

Zu NETWAYS gekommen bin ich in erster Linie, weil ich nach meinem Abschluss keine Lust auf einen weiteren Abschluss unter ungewissen (und teils einfach schlechten) Umständen aufgrund der Pandemie mehr hatte. Da ich während meines Studiums bereits als Werkstudent bei einem großen Medizintechnikunternehmen eine Icinga-Umgebung betreut hatte, war es ein naheliegender Schritt, mich bei dem Icinga-Experten, noch dazu in der Region, zu bewerben – und das hat super geklappt.
Dementsprechend startete ich auch mit einem Aufgabenbereich, der sich größtenteils auf Icinga2 konzentrierte, mit gelegentlichen Abstechern zu GitLab. Nach und nach hat sich das aber etwas verschoben, weg von Icinga2 und hin zu Docker, Kubernetes und DevOps im Allgemeinen. Gelegentliche Ausflüge zurück zu Icinga2 sind allerdings trotzdem noch möglich und machen mir nach wie vor Spaß.

Ganz egal um welches Themengebiet es geht, bin ich als Consultant natürlich in erster Linie für die Beratung von Kunden und ihren Projekten zuständig. Das kann von Reviews vorhandener Umgebungen und Projekte über die Erarbeitung von Plattformarchitekturen bis hin zu einer gemeinsamen Umsetzung erst einmal alles bedeuten. Am meisten Spaß macht es mir, wenn Theorie und Praxis Hand in Hand gehen, und ich weder ausschließlich über die Schulter des Kunden auf seinen Bildschirm schaue, noch alles alleine machen muss. So lernen meist beide Seiten etwas Neues, vorhandenes Wissen kann sich weiter „festklopfen“, und man kennt sich auch beim nächsten „Besuch“ noch aus.

Welche größeren, besonders interessanten Projekte stehen künftig an?

Puh, schwierige Frage. Grundsätzlich ist es gerade rund um das Thema Kubernetes so, dass viele Unternehmen gerade erst das Potenzial dieser Technologie und die damit einhergehenden Implikationen für sich entdecken – und teilweise möglichst schnell „umsteigen“ möchten. Hier gilt es dann, eine gesunde Strategie zu finden, nicht überhastet zu reagieren und die richtigen Lösungen für die gestellten Anforderungen zu finden. Das klingt erstmal nach einer Menge Stress, kann aber auch sehr lehrreich sein und wenn das Resultat passt, ist man enorm happy.
Darüber hinaus bin ich als Trainer für unsere Kubernetes- und GitLab-Trainings auch in die Weiterentwicklung der Trainings involviert, was deren Inhalt, Didaktik und Aufmachung angeht. Gemeinsam mit den anderen Trainern mache ich mir also von Zeit zu Zeit Gedanken, was man besser, interessanter, oder interaktiver gestalten könnte, und wenn das Feedback nach dem nächsten Training wieder etwas besser wurde, ist auch das immer ein interessantes und schönes Projekt.

Wie gefällt es Dir bisher bei NETWAYS?

Ich bin ja nun bereits etwas länger bei NETWAYS, und muss sagen – Vieles! Egal, ob gemeinsame Konferenzbesuche mit Kolleg:innen aus verschiedenen Abteilungen, die gelegentlich stattfindenden, mehr oder weniger geplante Bürofeiern, das Teamwochenende, oder unsere Amsterdamfahrt im vergangenen Sommer, bei uns gibt’s immer was zu feiern oder zumindest Gelegenheit und Mitstreiter, um einfach so eine gute Zeit zu haben, auch während der Arbeitszeit. Gerade arbeite ich z.B. mit meinem Kollegen Alex gemeinsam an einem größeren Kundenprojekt, unsere Trainings halten wir fast immer zu zweit, die Azubis kommen ungezwungen auf einen zu und man kommt ins Gespräch – es geht hier einfach sehr freundschaftlich zu.

Was machst Du, wenn Du mal nicht bei NETWAYS bist?

Was ich mache, wenn ich nicht bei NETWAYS bin, hängt auch etwas am Wetter bzw. den Jahreszeiten – seit einigen Wochen fahre ich wieder viel Fahrrad und gehe hin und wieder wandern Im Winter verlagern sich meine Hobbies eher nach innen, zum gelegentlichen Bouldern mit Freunden oder zu meiner Legosammlung. Eine Konstante, die sich fast allabendlich durchs Jahr zieht, sind zum einen Computerspiele mit Freunden aus Nah und Fern und zum anderen mehrere Programmierprojekte, die ich in meiner Freizeit verfolge (und die meistens im Sand verlaufen 😉). Seit ich bei NETWAYS mit dem Thema Kubernetes in Kontakt gekommen bin, probiere ich auch in meiner Freizeit öfters neue Technologien rund um das Thema aus, einfach, weil es mir Spaß macht und ich es auch nach Feierabend noch interessant finde.

Wie geht es in Zukunft bei Dir weiter?

Das kann man natürlich nie so ganz genau wissen, deshalb ist es ja schließlich die Zukunft – aber Vorstellungen, Wünsche und Ziele habe ich natürlich! Zum Einen habe ich schon während dem Studium gerne vor Publikum gesprochen und konnte das fast nahtlos bei NETWAYS weiterführen, in diesem Jahr bereits mit Talks in Tampa, Berlin, und im Juni in Amsterdam. Hier möchte ich dranbleiben, und die Qualität meiner Talks in 2024 nach und nach verbessern – denn da ist auf jeden Fall noch Luft nach oben. Für unser noch sehr kleines Team an „Kubernetes-Consultants“ würde ich mir noch etwas Zuwachs wünschen, um auch umfangreichere Projekte angehen zu können und von der jeweiligen Expertise profitieren zu können, aber das ist sicherlich nur eine Frage der Zeit. Ansonsten möchte ich einfach weiterhin einen guten Job machen, mich in meinem Feld weiterentwickeln und spannende Projekte umsetzen – mal schauen, was sich ergibt!

Daniel Bodky

Platform Advocate

Lies mehr von Daniel und triff unser Team

Kubernetes 101: Anwendungen in Kubernetes skalieren

von Daniel Bodky | Jun 19, 2023 | NETWAYS

This entry is part 5 of 7 in the series Alles rund um Kubernetes

Für viele Anwender ist die einfache Skalierbarkeit und Flexibilität von Anwendungen im Cluster der Hauptgrund für einen Umstieg auf Kubernetes. Doch auch hier geschieht nichts (oder nur sehr wenig) „magisch“ und von allein. Anwendungen müssen bereits zum Zeitpunkt der Entwicklung in Hinblick auf diese gewünschte Flexibilität gebaut und die Deployments entsprechend konfiguriert werden. Natürlich spielt die Infrastruktur, auf der K8s selbst läuft, ebenfalls eine wichtige Rolle. Aber bevor wir direkt zu tief einsteigen, fangen wir doch erstmal mit den Basics an und klären zunächst ein paar Begrifflichkeiten.

Bei Deployments handelt es sich um eine von Kubernetes definierte Abstraktion von zu betreibenden Anwendungen. Anstelle einer konkreten Konfiguration für genau einen Pod wird ein sogenanntes Template definiert, quasi eine Vorlage für eine beliebige Anzahl an zu betreibenden Pods. Durch diese Abstraktion können mehrere Pods des gleichen Deployments gebündelt betrachtet und verwaltet werden, was mehrere Vorteile mit sich bringt – unter anderem eine einfachere Skalierung.

Willst du deine Anwendungen nun skalieren, ist es wichtig den Unterschied zwischen horizontaler Skalierung und vertikaler Skalierung (Scaling out vs. Scaling up) zu verstehen.
Horizontale Skalierung beschreibt das Hinzufügen neuer Pods (oder Nodes, auf Clusterlevel) zum Cluster, um beispielsweise Anfragespitzen eines Webshops o.Ä. zu bewältigen. Vertikale Skalierung hingegen bezeichnet das Hinzufügen von mehr Ressourcen zu bestehenden Pods oder Nodes, beispielsweise in Form von mehr vCPUs oder Arbeitsspeicher.

Nachdem wir jetzt die wichtigsten Begriffe geklärt haben und (hoffentlich) auf dem gleichen Wissensstand sind, steigen wir ordentlich in das Thema Skalierung auf K8s ein!

Skalierung von Deployments

Wenn du und dein Team den Plan verfolgen Anwendungen auf Kubernetes skalieren, hast du dafür mehrere Möglichkeiten. Zum einen die grundlegende Unterscheidung zwischen horizontalem und vertikalem Scaling, zum anderen die Frage, ob und wie diese Skalierung automatisiert werden kann. Für Workload-Skalierung wird meistens horizontales Scaling genutzt. Wie du bereits weißt, ist das gleichbedeutend mit dem Hinzufügen neuer Pods zu dem bestehenden Deployment. Das kannst du theoretisch manuell umsetzen, bspw. mittels eines kubectl Befehls:

kubectl scale --replicas=5 deployment/application-a

In diesem Beispiel weist man Kubernetes‘ API an, das Deployment application-a auf 5 Pods zu skalieren. K8s kümmert sich dann automatisch um den Rest. Optional können bei Verwendung von kubectl auch Voraussetzungen mitgegeben werden, die für eine Skalierung notwendig sind, etwa die Anzahl momentan laufender Pods oder eine erwartete Versionsnummer. Treffen die Voraussetzungen nicht zu, wird auch keine Skalierung vorgenommen.

Du merkst, der manuelle Ansatz funktioniert relativ simpel. Er bringt aber auch einige Schwierigkeiten mit sich! So müssen bestehende Deployments kontinuierlich auf die Anzahl ihrer Repliken geprüft werden. Denn nach einer Skalierung der Deployments auf mehr Repliken z. B. aufgrund von hoher Last auf der Anwendung, kann diese nicht automatisch wieder herunterskaliert werden. Hier lassen sich also sehr einfach Geld und Clusterressourcen verschwenden.
Des Weiteren muss jede Skalierung, egal in welche Richtung, von einem Clusternutzer mit entsprechenden Rechten vorgenommen werden. Und ab einer gewissen Anzahl an Skalierungsanfragen ist diese Art zu arbeiten einfach nicht mehr praktikabel. Es benötigt also eine Form der Automatisierung.

Voraussetzungen für automatisierte Skalierung

Damit du eine automatisierte Skalierung von Deployments aber überhaupt durchführen kannst, ist ein entsprechender Controller im Cluster notwendig. Dieser muss zum Einen die zu definierenden Anforderungen an die Deployments erkennen und (re-)evaluieren, und zum anderen die daraus resultierenden Skalierungen vornehmen. Das Kubernetes-Projekt bietet hier sowohl für horizontales Autoscaling als auch für vertikales Autoscaling einen entsprechenden Controller:

Egal für welche Vorgehensweise du dich entscheidest, die Controller übernehmen die gleiche Aufgabe. Sie prüfen in einem zu definierenden Intervall (standardmäßig alle 15 Sekunden), ob die festgelegten Grenzwerte für ein Auf- oder Herunterskalieren des betroffenen Deployments über- bzw. unterboten werden und passen die Anzahl an Repliken entsprechend an.
Für die Konfiguration dieser Grenzwerte gibt es eine eigene API-Ressource namens HorizontalPodAutoscaler.

Eine weitere Voraussetzung der automatisierten Skalierung ist die Installation des sogenannten Metricsservers. Er übernimmt die Aufgabe, deine Pod- und Containermetriken innerhalb des Clusters zu aggregieren und via Kubernetes-API für beliebige Drittanwendungen bereitzustellen – zum Beispiel für unsere Autoscaler.

Einrichtung automatisierter Skalierung

An diesem Punkt habe ich dir hoffentlich die Vorteile einer automatisierten Skalierung näherbringen können und du kannst es kaum abwarten, selbst damit loszulegen. Dafür kannst du dich (wie so oft) zwischen zwei Möglichkeiten entscheiden: Imperativ durch einen kubectl Befehl oder deklarativ durch ein Kubernetes-Manifest. Um dir beide Varianten besser zu veranschaulichen, habe ich Beispiele für den HorizontalPodAutoscaler eines Deployments nginx geschrieben.

Imperativ

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Deklarativ

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
  namespace: default
spec:
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 50
        type: Utilization
    type: Resource
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx

Beide Varianten erstellen ein HorizontalPodAutoscaler Objekt, dass das Deployment nginx bei durchschnittlicher Auslastung von 50% hochskaliert bzw. bei 0% in einen Bereich zwischen 1-10 Pods herunterskaliert. Auf diese Weise lassen sich Kubernetes Deployments automatisch horizontal skalieren, die Grenzwerte sind dabei seit API-Version 2 des HorizontalPodAutoscalers sehr flexibel konfigurierbar.

Anstatt lediglich auf ein von der Kubernetes-Metrics-API bereitgestelltes Attribut zu schauen (CPU-Last/Memory) können mehrere Attribute kombiniert werden oder sogar externe Messwerte verglichen werden, beispielsweise resultierend aus einer Überwachung mittels Prometheus. Außerdem können statt der Metriken von Pods die einzelnen Metriken für Container als Basis des Autoscalings genutzt werden.

Und auch ansonsten bietet die API-Definition des HorizontalPodAutoScalers eine Bandbreite an konfigurierbarem Verhalten. So lässt sich mittels Scaling Policies das Skalierungsverhalten für Hoch- bzw. Herunterskalierung separat einstellen. Etwa wenn du Kubernetes Pods schnellstmöglich hochfahren lassen willst, der Abbau überflüssiger Pods aber in Erwartung weiterer Lastspitzen langsam stattfinden soll.
Ein weiteres nützliches Feature ist die Existenz der Eigenschaft StabilizationWindowSeconds, die eine Art Filter für Flapping, also stark und häufig wechselndes Verhalten der beobachteten Metriken, darstellt. Eine genauere Auseinandersetzung mit den Konfigurationsmöglichkeiten des HorizontalPodAutoscalers würde den Rahmen dieses Blogposts sprengen, stattdessen verweise ich einmal mehr auf die oben verlinkte offizielle Dokumentation.

Der VerticalPodAutoscaler ist noch in einer frühen Betaversion (momentan v0.13.0) und deswegen noch nicht in der offiziellen Kubernetes Dokumentation enthalten. Eine Auflistung seiner Fähigkeiten und Dokumentation findet sich im oben verlinkten Repository des Projekts.

Skalierung von Nodes

Hast du über einen längeren Zeitraum eine hohe Last auf deinem Cluster, und/oder wurden nach und nach immer mehr verschiedene Deployments hochskaliert, kann es passieren, dass die Nodes des Clusters selbst an die Grenzen ihrer Ressourcenkapazitäten zu gelangen. Auch hier hat man nun die Möglichkeit, horizontal oder vertikal zu skalieren, um das Cluster weiter funktionsfähig zu halten.
Für die horizontale Skalierung eines Kubernetes-Clusters stellt das Kubernetes-Projekt auf GitHub den Cluster-Scaler zur Verfügung, der in der Lage ist, dynamisch Nodes bei einer Vielzahl an Public-Cloud-Providern zu (de-)provisionieren.

Die vertikale Skalierung der Nodes eines Kubernetes-Clusters kann dir noch nicht durch einen Controller abgenommen werden – hier ist manuelle oder extern automatisierte Arbeit notwendig. Hast du also deine Kubernetes-Cluster auf VMs aufgesetzt, kannst du deren zugewiesene Ressourcen (vCPUs, Arbeitsspeicher, Festplattenspeicher) anpassen. Läuft Kubernetes als „Managed Kubernetes„, ist es oftmals möglich, die Node Pools anzupassen zu einer leistungsstärkeren Klasse an Nodes.

Fazit

Auf den ersten Blick erscheint die Skalierung von Workloads und des Clusters selbst, wie so viele Dinge rund um Kubernetes, als machbares Vorhaben. Dank kubectl und der von der API angebotenen Objekttypen in Kombination mit den vorhandenen Autoscalern können Workloads sowohl imperativ als auch deklarativ und horizontal sowie vertikal skaliert werden. Für Cluster in der Cloud lassen sich auch Nodes horizontal skalieren.

Geht man allerdings weiter ins Detail, findet man viele Stellschrauben, fortgeschrittene Konzepte und Designfragen, die es bei der Definition eines Autoscaler-Objekts zu beachten gilt. Hier ist die Erfahrung der zuständigen Clusteradministratoren gefragt, um die Kapazitäten des Clusters durch Autoscaling optimal zu nutzen, ohne Ressourcen unnötig zu verschwenden oder Workloads zu spät oder gar nicht zu skalieren.
Auch Monitoring der Workloads kann helfen, um nach und nach ein Gespür für zu erwartende Auslastung des Kubernetes-Clusters zu bekommen und das Autoscaling einiger oder gar aller Anwendungen im Cluster feinjustieren zu können.