Kubernetes für Linux-Admins: So steigst du vom Server auf den Cluster um

Wer Linux administriert, bringt für Kubernetes mehr mit, als ihm meist bewusst ist. Container sind keine neue Technologie, sondern eine Kombination aus Namespaces, cgroups und Capabilities, also aus Kernel-Funktionen, die du bereits kennst. Auch Routing, DNS, TLS, Dateisysteme und Logrotation verschwinden nicht, sie tauchen nur an einer anderen Stelle wieder auf. Der eigentliche Bruch liegt woanders: Du konfigurierst keinen Zustand mehr direkt, sondern beschreibst einen Zielzustand und überlässt es Controllern, ihn herzustellen.

Genau daran scheitern viele Umsteiger im Alltag. Sie behandeln Pods wie kleine VMs, loggen sich per kubectl exec ein, ändern etwas im Container und wundern sich, dass die Änderung beim nächsten Rollout weg ist. Sie kopieren Manifeste aus Blogartikeln, ohne Requests und Limits zu setzen, und stehen dann vor OOMKills und CPU-Throttling, die im Monitoring schwer zuzuordnen sind. Oder sie debuggen ein Netzwerkproblem mit tcpdump auf dem Node, obwohl die Ursache in einer NetworkPolicy oder im Service-Objekt liegt.

Dazu kommt der organisatorische Teil. Ein Cluster ist selten die Aufgabe einer einzelnen Person. Wer vorher allein für seine Server zuständig war, arbeitet plötzlich mit RBAC, Namespaces als Mandantengrenze und Deployments, die aus einer Pipeline kommen und nicht mehr von Hand. Ohne ein klares Bild davon, wer welche Objekte verantwortet, entstehen Cluster, die technisch laufen, aber im Betrieb niemandem gehören.