E-Book, Deutsch, 1148 Seiten
Reihe: Rheinwerk Computing
Das Handbuch für Planung und Administration
E-Book, Deutsch, 1148 Seiten
Reihe: Rheinwerk Computing
ISBN: 978-3-8362-9755-4
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection
Aus dem Inhalt:
Container: Einsatzgebiete, Planungsstrategien, Kubernetes in Multi-/ Hybrid-Cloud-Umgebungen
Kubernetes-Architektur im Detail, LTS-Betrachtungen, Produkte und Kosten
Trusted Registries, Security-Konzepte, automatisiertes Zertifikatsmanagement, Backup und Disaster Recovery
Integration von IDM-Backends per Keycloak via Operator
Maximale Infrastruktur-Automation, Air-gapped/Offline-Installation und Betrieb
FinOps/Kostenkontrolle, Wirtschaftlichkeitsaspekte, Sustainability
Planung, Installation und fortgeschrittene Orchestrierung hochverfügbarer Kubernetes- und OpenShift-Cluster, On-Premises und in der Cloud
Metrics, Monitoring und Logging
Services, Ingress, Cloud-native API-Gateways und Service Meshes
Maximale In-Cluster Automation: Operatoren für hunderte Applikationsstacks, eigene Operatoren und Operator-Bundles erstellen und bereitstellen
Autoskalierbare KI/ML-taugliche Kubernetes Cluster mit Datacenter-GPUs von NVIDIA
Enterprise-taugliche CI/CD-Pipelines und GitOps, Progressive Delivery mit Analysis
Autoren/Hrsg.
Weitere Infos & Material
1. Catch-22 ... 39
1.1 ... Vorbemerkungen ... 43
1.2 ... Kernziele und rote Fäden ... 45
1.3 ... Was dieses Buch sein soll und was nicht ... 46
1.4 ... Wie dieses Buch zu lesen ist ... 46
1.5 ... Docker-Replacement-Tools ... 48
Teil I. Strategische Vorbetrachtungen, Foundations und Preflights ... 51
2. Grundsätzliche strategische Fragen ... 53
2.1 ... Worum geht es? ... 53
2.2 ... Überblick: Container- und Infrastruktur-Konzepte ... 54
2.3 ... Generelle Infrastruktur-Fragen: Cloud vs. On-Prem, Managed Kubernetes, Managed Server, hybrider Mischbetrieb ... 58
2.4 ... Maximale Vollautomation -- IaC, Operatoren, GitOps ... 66
2.5 ... Registries ... 73
2.6 ... Ganzheitliche Security -- High-Level View ... 76
Teil II. Kubernetes-Architektur, Core-Concepts, Workloads und Day 1 Operations ... 87
3. Kubernetes ... 89
3.1 ... Kubernetes im Überblick ... 89
3.2 ... Vanilla Kubernetes und das traurige Thema LTS ... 91
3.3 ... Kubernetes-Komponenten ... 100
3.4 ... Dienste auf allen Node-Typen: Kubelet, Container-Engine, Overlay-Netze, Proxies ... 103
3.5 ... Dienste auf den Kubernetes-Master-/Controlplane-Nodes ... 106
3.6 ... Etcd als Key/Value-Store in Kubernetes-basierten Clustern ... 112
3.7 ... Networking in Kubernetes ... 118
3.8 ... Windows-Nodes in Kubernetes-Clustern? ... 121
3.9 ... Container-Engines für Kubernetes ... 126
4. Kubernetes-Setup-Varianten im kompakten Überblick ... 131
4.1 ... Optionen und Grad der Verwaltbarkeit ... 131
4.2 ... Setup-Ansätze (Auszüge) ... 133
4.3 ... Zeitsynchronisation ... 137
4.4 ... Instance Sizing ... 137
5. Kubernetes-Cluster-Setups (Cloud) ... 141
5.1 ... GKE ... 142
5.2 ... EKS ... 158
5.3 ... AKS ... 160
5.4 ... Vergleichstabelle für Managed-Kubernetes-Angebote ... 164
6. Kubernetes: Deployment-Tools und -Konzepte, API-Foundations, Manifest- und CLI-Handling ... 165
6.1 ... Überblick: Tools zum Deployment von Kubernetes-Ressourcen ... 165
6.2 ... Helm und Kustomize -- the Big Short ... 167
6.3 ... Editoren und Tools: VI(M), Visual Studio Code und K9s ... 172
6.4 ... Grundlegende Verfahren zum Erstellen von Workloads ... 176
6.5 ... Grundlagen zu kubectl ... 178
6.6 ... kubectl-Operations ... 188
6.7 ... Debugging von Kubernetes-Ressourcen ... 198
7. Kubernetes-Cluster: Day 1 Operations -- Core-Workloads ... 201
7.1 ... Namespaces: Foundations ... 201
7.2 ... Namespaces: Multi-Tenancy- und Security-Aspekte ... 207
7.3 ... Pods und Container ... 210
7.4 ... Pod-Sidecar-Patterns und das Applikations-Design ... 220
7.5 ... Pods und Init-Container ... 222
7.6 ... Pod- und Container-Security ... 225
7.7 ... Pod-/Container-Attribute über Umgebungsvariablen nutzen ... 231
7.8 ... Überblick: ConfigMaps, ServiceAccounts und Secrets ... 233
7.9 ... ConfigMaps ... 234
7.10 ... ServiceAccounts ... 245
7.11 ... Secrets ... 249
7.12 ... Jobs ... 255
7.13 ... Label, Selektoren und Annotations ... 260
7.14 ... Deployments ... 265
7.15 ... DaemonSets ... 275
7.16 ... StatefulSets ... 279
7.17 ... Entscheidungshilfe: Wann Deployment, wann DaemonSet, wann StatefulSet? ... 282
7.18 ... Update-Strategien für Pods im Überblick ... 284
7.19 ... Kubernetes: Autorisierung/RBAC ... 289
7.20 ... Kubernetes-Volumes und dynamische Storage-Provisionierung ... 296
7.21 ... Storage für cloudbasiertes Kubernetes: GKE, EKS und AKS ... 323
7.22 ... Services ... 327
7.23 ... Ingress ... 358
Teil III. Skalierbare Container-Cluster mit Kubernetes: Day 2 Operations ... 365
8. Day 2 Operations: In-Cluster-Vollautomation mit Operatoren -- Foundations ... 367
8.1 ... Vorbetrachtungen: Zwei Operator-spezifische Hauptkapitel ... 367
8.2 ... CustomResourceDefinitions ... 368
8.3 ... Operatoren unter Kubernetes ... 382
8.4 ... Operator-Typen und Maturitäts-Level: Helm vs. Ansible vs. Go ... 387
8.5 ... Operator-Typen im funktionalen Vergleich: Ansible vs. Go ... 391
8.6 ... Operator-Preflights: OLM -- wer überwacht die Wächter? ... 392
8.7 ... Operator-Management ... 396
8.8 ... Hands on: PostgreSQL-Operator (Level 5) ... 401
9. Kubernetes-Cluster: Day 2 Operations -- Pod-Lifecycle, De-Scheduling, Tenancy und Limits ... 411
9.1 ... Pod-Lifecycle und Health-Checks ... 411
9.2 ... (De-)Scheduling: Überblick ... 429
9.3 ... (De-)Scheduling: Constraints -- Node-Selektoren, Pod Topology Spread Constraints ... 438
9.4 ... (De-)Scheduling: (Anti-)Affinity, Taints und Tolerations ... 443
9.5 ... (De-)Scheduling: QoS-Classes, Compute Resource Requests und Limits ... 450
9.6 ... (De-)Scheduling: Pod-Priorities ... 469
9.7 ... (De-)Scheduling: PodDisruptionBudgets ... 474
9.8 ... (De-)Scheduling: Node-Kapazitäten ... 483
9.9 ... De-Scheduling und HA-Abstinenz: Descheduler und Re-Balancing ... 485
9.10 ... Namespaces und (Compute-)Resource-Limits ... 490
9.11 ... Namespaces und NetworkPolicies ... 501
10. Kubernetes-Cluster: Day 2 Operations -- DNS, Certificates, API-Gateways ... 513
10.1 ... ExternalDNS für externe Hostnamenauflösung ... 513
10.2 ... Automatisierte Zertifikatserzeugung (alle Plattformen): Cert-Manager ... 519
10.3 ... Gateway-API ... 536
10.4 ... API-Gateway: Foundations ... 541
10.5 ... API-Gateway: Beispiel-Setup (GKE) ... 543
10.6 ... API-Gateway: Beispiel-Setup mit Kong (alle Plattformen) ... 551
11. Kubernetes-Cluster: Day 2 Operations -- Metrics, Monitoring, Logging, APM/Observability, Autoscaler ... 563
11.1 ... Kubernetes-Standard-Metriken: Metrics Server und kube-metrics ... 563
11.2 ... Log-Erfassung und mehr unter Kubernetes: Elastic ... 566
11.3 ... Log-Erfassung und mehr unter Kubernetes: Loki -- Grafana-Logging ... 584
11.4 ... Cluster-Monitoring mit Prometheus ... 589
11.5 ... Federated Prometheus mit Thanos ... 615
11.6 ... Tracing mit Jaeger ... 625
11.7 ... Full-Stack-Monitoring: APM und Observability ... 627
11.8 ... HPA -- Horizontaler Pod-Autoscaler ... 640
11.9 ... Custom-Metrics-Autoscaling mit KEDA und HPA ... 650
11.10 ... Vertical Pod Autoscaler ... 665
11.11 ... Multidimensionales Pod-AutoScaling (GKE) ... 678
11.12 ... Cluster-Autoscaling ... 678
12. Kubernetes-Cluster: Day 2 Operations -- Meshes, Authentication, Debugging, Backup/Recovery ... 681
12.1 ... Service-Meshes ... 681
12.2 ... Kubernetes: Authentifizierung und Autorisierung (Keycloak-basiert) ... 692
12.3 ... Debugging und Troubleshooting ... 709
12.4 ... Backup und Disaster-Recovery ... 710
Teil IV. Vollautomation und Resilienz mit eigenen Operatoren ... 721
13. Day 3 Operations: In-Cluster-Vollautomation mit Operatoren -- Advanced Concepts ... 723
13.1 ... Operator-SDK, OLM und weitere Konzepte ... 723
13.2 ... Ansible oder Go? ... 727
13.3 ... Operator-Build-Demo: Level-5-Operator in Go ... 733
13.4 ... Operator-Bundle für den L5-Operator erzeugen ... 745
13.5 ... Index/Catalog (für L5-Operator und andere) erzeugen ... 749
13.6 ... Hands-On: Memcached-Operator mit Ansible ... 756
13.7 ... Diverses ... 760
Teil V. High-Level-Setup- und Orchestrierungs-Tools für Kubernetes-basierte Container-Infrastrukturen ... 763
14. Red Hat OpenShift ... 765
14.1 ... Vorbetrachtungen und Historisches ... 765
14.2 ... Lizenzierung und Lifecycle ... 767
14.3 ... OpenShift, das Enterprise-Kubernetes in »ready to use« ... 773
15. OpenShift-Setup ... 775
15.1 ... Generelle Vorbetrachtungen und Vorbereitungen ... 775
15.2 ... Setup von OpenShift 4.12 (IPI) auf AWS ... 789
15.3 ... Setup von OpenShift 4.12 (IPI) auf GCP ... 795
15.4 ... Setup von OpenShift 4.13 (IPI) auf vSphere ... 798
15.5 ... Post-install Tasks und Day 2 Operations für OpenShift ... 808
15.6 ... Disconnected/Air-Gapped-Installation und der Betrieb ... 813
16. OpenShift-Administration ... 819
16.1 ... CLI-Tools ... 819
16.2 ... Administration per GUI ... 823
16.3 ... OpenShifts Cluster-Operatoren ... 824
16.4 ... OpenShift-Networking im Überblick ... 826
16.5 ... Authentifizierung und Autorisierung unter OpenShift ... 830
16.6 ... Authentifizierung und Autorisierung: Security Context Constraints ... 834
16.7 ... Imagestreams ... 841
16.8 ... OpenShift-Router ... 845
16.9 ... OpenShift-Router: Ingress-Operator und Ingress-Controller ... 847
16.10 ... Egress-Limitierung und Priorisierung ... 864
16.11 ... DNS-Customizing ... 870
16.12 ... MachineConfigs, Machines, MachineSets und Scaling ... 871
16.13 ... Cluster-Autoscaler und Machine-Autoscaler ... 879
16.14 ... Customisierte MachineSets für spezielle Instanztypen -- (z. B. GPU- oder Storage-Nodes) erzeugen ... 884
16.15 ... Infrastructure-Nodes in OpenShift ... 890
16.16 ... HA für das OpenShift-Controlplane mit ControlPlaneMachineSets ... 894
16.17 ... OpenShift-Upgrades: Foundations ... 897
16.18 ... OpenShift-Upgrades: EUS Upgrades ... 899
16.19 ... Interaktive OpenShift-Workshops ... 903
Teil VI. Day 3 Operations: Cluster-Federation, Security, CI/CD-GitOps-Systeme, SDS und mehr ... 905
17. Day 3 Operations: Multi-Cluster-Management und Federated Cluster ... 907
17.1 ... Historisches ... 907
17.2 ... Multi-Cluster-Management mit Red Hat Advanced Cluster Management ... 909
17.3 ... Setup und grundlegende Cluster-Verwaltung per RHACM ... 914
17.4 ... Services, Ingress und Gateways in Multi-Cluster-Umgebungen ... 927
Teil VII. Virtualisierung, Security und GitOps ... 933
18. Day 3 Operations: VMs in Kubernetes/OpenShift-Cluster einbinden ... 935
18.1 ... KubeVirt -- VMs als Container ... 936
19. Day 3 Operations: Container-Security -- Full-Featured Security-Stacks ... 947
19.1 ... Vorbetrachtungen zu Security-Lösungen ... 948
19.2 ... NeuVector ... 950
19.3 ... RHACS -- Red Hat Advanced Cluster Security für OpenShift ... 956
20. Day 3 Operations: Container-Security -- Advanced Secret Management ... 961
20.1 ... EncryptionConfiguration für Secrets und andere Objekte ... 962
20.2 ... Secret Encryption unter GKE und EKS ... 963
20.3 ... HashiCorp Vault ... 964
20.4 ... Setup des Vault Clusters ... 973
20.5 ... Vault PKI Secrets Engine ... 995
20.6 ... Sealed Secrets (Bitnami) ... 998
Teil VIII. Vollautomatisierte CI/CD-GitOps-Pipelines ... 1003
21. Day 3 Operations: CI/CD-Pipelines und GitOps ... 1005
21.1 ... GitOps ... 1005
21.2 ... GitOps mit Tekton (CI-Fokus) ... 1009
21.3 ... Tekton-Setup ... 1017
21.4 ... Beispiele für Tekton Pipeline (Pi-Calculator, Build, Push & Deploy) ... 1022
21.5 ... Tekton Pipelines unter OpenShift (OpenShift Pipelines) ... 1026
21.6 ... GitOps mit Argo CD (CD-Fokus) ... 1033
21.7 ... Argo Rollouts ... 1042
Teil IX. Software-Defined Storage für verteilte Container-Infrastrukturen ... 1059
22. Day 3 Operations: Software-Defined Storage für Container-Cluster ... 1061
22.1 ... SDS-Funktionsprinzipien ... 1061
22.2 ... Ceph ... 1064
22.3 ... Ceph: Storage-Bereitstellungsverfahren für Container-Cluster ... 1067
22.4 ... Containerized SDS -- Ceph per Rook ... 1068
22.5 ... Setup von Rook ... 1072
22.6 ... Rook-Administration ... 1084
23. Day 3 Operations: Kostenkontrolle in Kubernetes/OpenShift-Clustern (FinOps) ... 1105
23.1 ... FinOps ... 1106
24. Day 3 Operations: GPU-beschleunigte KI/ML-Container-Infrastrukturen ... 1113
24.1 ... GPUs und autoskalierbare KI/ML-Stacks ... 1113
24.2 ... Konkrete Einsatzszenarien und Kosten ... 1115
24.3 ... NVIDIAs GPU-Operator ... 1118
24.4 ... GKE-Cluster mit NVIDIA-A100-Instanzen und MIG-Partitionierung ... 1121
24.5 ... OpenShift-Cluster mit NVIDIA-A100-GPUs in der GCP ... 1128
24.6 ... AKS- und EKS-Cluster mit NVIDIA-GPUs ... 1131
25. The Road ahead ... 1133
Index ... 1135
1 Catch-22
»How hard can it be?«
– Jeremy Clarkson, Top Gear Ja, wie schwer kann das alles schon sein ... Nun, wenn ich an die mittlerweile weit mehr als 6.000 Seiten denke, die ich in den letzten 6 Jahren im Rahmen von nunmehr 5 deutsch- und englischsprachigen Container- und KI/ML-Infrastruktur- Publikationen zu Papier bzw. in E-Books gebracht habe, stellt sich die Frage von Mister Clarkson bei ernsthafter Betrachtung schon lange nicht mehr. Denn mittlerweile sind Vanilla-Kubernetes-Cluster und die von ihnen für ein halbwegs produktivtaugliches Umfeld benötigten 3rd-Party Tool Stacks dank ihrer extremen Komplexität und hohen Volatilität oft nur noch eines: eine Arbeitsbeschaffungsmaßnahme erster Güte. Ein Selbstzweck, eine meist kaum noch seriös auflösbare Sisyphus-Schleife, die mittlerweile ein kleines bisschen an den legendären, koordinierten Wahnsinn aus dem im Titel benannten Antikriegsdrama Catch-22 erinnert. Der Catch-22 besagt vereinfacht: Nur ein Pilot, der verrückt ist, kann beim Arzt einen Antrag auf Fluguntauglichkeit stellen. Ist der Pilot jedoch in der Lage, seinen Antrag auf Fluguntauglichkeit zu stellen, kann er anscheinend doch rational denken und ist daher nicht verrückt, ergo ist er diensttauglich. Portieren wir das Ganze: Kunde: »Wir wollen Vanilla Kubernetes einsetzen, damit wir effizienter arbeiten können.« Neutraler Berater: »Aber mit Vanilla Kubernetes und allen benötigten 3rd-Party Stacks wird sich dank der hohen Volatilität und kurzen Lifecycles Ihr HR- und Kosten-Aufwand eher erhöhen.« Kunde: »Aber dank des hohen Automationsgrades lässt sich das doch kompensieren.« Berater: »Prinzipiell ja, wenn sich unter der Kubernetes-Haube nicht alles ständig verändern würde und selbst jede Drittkomponente bei jedem Update immer wieder an etliche andere neu angepasst werden müsste. Wie oft sollen Ihre DevOps-Teams die Automation denn neu aufsetzen? Zudem gibt es keinen Long Term Support. Stattdessen permanent change. Ist sogar der offizielle, stolze CNCF Tenor.« Kunde: »Aber alle sind doch längst auf den Zug aufgesprungen und es scheint gut zu funktionieren, vor allem in der Cloud, also muss die Sache doch Hand und Fuß haben.« Berater, in Gedanken: Sicher. Und im Fernsehen gibt es sprechende Knuffelhäschen. Berater, in Worten: »Wenn Sie statt Vanilla Kubernetes beispielsweise OpenShift einsetzen, dann wahrscheinlich.« Kunde: »Aber das ist doch auch nur ein Kubernetes von Red Hat und kostet zudem Lizenzgebühren. Wir nehmen Vanilla Kubernetes. Punkt.« Berater, in Gedanken: Ich hab’s versucht. Dann eben das dreifache Beratungskontingent. Ka-Tsching. Berater, in Worten: »Gern, selbstverständlich.« Als ich mich 2017 entschloss, die erste Publikation über Container-Cluster auf den Weg zu bringen, dachte ich bereits damals, dass Kubernetes als legitimer Nachfolger der guten, alten Pacemaker-HA-Cluster aus der Legacy-Welt ganz sicher einiges umkrempeln würde. So weit, so gut. Und die Veränderungen kamen, und sie hörten nicht auf. Und es wurden mehr und mehr. Ich begleitete Kubernetes und Co über die Jahre, versuchte mit meinen Büchern halbwegs am Innovationspuls zu bleiben, aber letztlich blieben meine Publikationen nur Snapshots eines bestimmten Evolutionsstandes. Von Version zu Version beglückte und beglückt uns die CNCF-gesteuerte Innovationsmaschine dank Tausenden von Kontributoren und Millionen von Entwicklern weltweit mit unzähligen neuen Konzepten, Features und Changes, ausgespuckt vom High-Speed-CI/CD-Fließband, und oft genug ohne Backward-Compatibility. Neue Funktionen wurden und werden im gefühlten Sekundentakt eingeführt, alte verworfen, und bestehende, wichtige, aber unausgereifte Funktionalitäten krebsen oft jahrelang mit eklatanten Mankos herum, weil dank ADHS-Mentalität lieber fleißig an neuen Nischen-Features entwickelt wird, die eventuell irgendwann einmal irgendjemand gebrauchen kann, anstatt für den Unternehmensbereich wichtige Features rock-solid zu Ende zu denken. Um das wortwörtliche Ausmaß etwas besser zu verdeutlichen: Der Punkt, an dem Ihnen eine einzelne Person einen Kubernetes-Cluster mit allen für Produktivsysteme benötigten Tool Stacks von der ersten bis zur letzten, einhundertmillionsten Schraube wirklich vollumfänglich, bis ins letzte Bit, erklären könnte, ist längst passé. Es sei denn, auf diesem Planeten existiert ein Superhirn, das mir persönlich nicht bekannt ist. Auch in Beratungen oder Workshops entdecke ich immer wieder den gleichen Verlauf bei Teilnehmern: die anfängliche Euphorie, sich ›mal eben‹ etwas Know-how zu Kubernetes anzuschaffen, die nach und nach der etwas bedrückenden Erkenntnis weicht, dass man selbst nach vier mit vielen Informationen angefüllten Tagen lediglich einen kleinen, oberflächlichen Blick in die gewaltige Tiefe geworfen hat, die Kubernetes-Cluster längst darstellen. Die Problematik wurde noch deutlicher, als ich in den Jahren 2020 bis 2022 zusammen mit NVIDIA an meiner Publikation über Skalierbare KI/ML-Infrastrukturen arbeitete, die Ende 2022 erschien. Obwohl das KI-Infra-Buch mit einem Volumen von 468 Seiten gerade einmal einem Drittel des Umfangs meiner bisherigen Container-Publikation entsprach, dauerte die Arbeit daran erstmals ganze drei Jahre, und damit fast dreimal so lange wie die an einer meiner Container-Publikationen. Ursache: das hochvolatile und komplexe Kubernetes im Unterbau, und dazu der hochvolatile und hochkomplexe KI/ML-Stack mit GPU-, NFD- und AI-Workspace-Operatoren on top, dazu die Virtualisierungsschicht mit IaC-Automation, deren GPU-Hardware mithilfe Dutzender Einstellschrauben, die sich ebenfalls gern und schnell verändern, für den jeweiligen Anwendungsfall vernünftig und vollautomatisiert integriert werden will. Und alles in permanenter Veränderung. Trauriger Fakt war, dass ich nach Beendigung der Arbeit an einem Themenblock oft genug den vorherigen, bereits fertiggestellten wieder überarbeiten oder gar komplett neu erstellen musste. Sisyphus lässt grüßen, aber wie üblich sucht sich jeder sein zu tragendes Päckchen meist selber aus. Und das gilt auch für die Unternehmen, die sich entscheiden, Vanilla Kubernetes einzusetzen – und darunter fallen auch alle Managed-Cloud-Derivate wie GKE, AKS, EKS und Co. Die Gründe für die Ineffizienz im Vergleich zu echten Enterprise-Kubernetes-Lösungen sind vielfältig und werden später im Buch ausführlich thematisiert. Aber die Vanilla-Kubernetes-basierten Lösungen sind zumindest eines: eine unlimitierte Gelddruckmaschine für Beratungsunternehmen, die mit oftmals brandgefährlichem Halbwissen ihren Kunden Kubernetes-Cluster nach wie vor als die simple Universal-Lösung für alle IT-Probleme schmerzfrei anpreisen. Zügige Migration? Kein Problem. Know-how-Transfer? Alles schnell erledigt, vertrauen Sie uns! Na sicher. Und genau diese Praktiken sind wiederum erfahrungsgemäß auch der Hauptgrund, warum ebenfalls zahllose Unternehmen – nach ebendiesen fragwürdigen Versprechungen – in den fatalen Irrglauben versetzt werden, dass die Migration ihrer hochkomplexen Legacy-Systeme in containerisierte Umgebungen in maximal zwei Wochen komplett abgefrühstückt ist. Und ihre Mitarbeiter nebenbei »mal eben«, am besten in maximal zwei Tagen, vollumfänglich zu hochkompetenten Container-Spezialisten ausgebildet werden können. Und wieder: Na sicher. Willkommen im Schwurbel-Bingo-Einhorn-Land. Eine höchst bedauerliche Problematik, auf die ich bereits in meinen letzten vier Container-Publikationen mehr als ausdrücklich hingewiesen habe und an der sich bis heute herzlich wenig geändert hat. Im Gegenteil. Aber was soll’s – denn den Sales-Fraktionen von AWS, GCP, Azure, Red Hat, VMware, NVIDIA und Co. bereitet das meist keine mächtigen Kopfschmerzen. Allen übrigen Beteiligten sehr wohl. Denn im Grunde gilt nur noch eine Regel: dass nichts mehr gilt. Oder in Langform: Das meiste, was gestern noch superhip und State of the Art war, ist heute gern nur noch alter Krempel, der keinen mehr wirklich interessiert. LTS, Long Term Support ... was war das gleich noch? Und das trifft auf fast alle Beteiligten zu – mit Ausnahme des Endkunden im Unternehmensbereich. Denn der würde sich gern einfach mal eine etwas langsamere Pace wünschen, deutlich weniger Komplexität und dass die mittlerweile unzähligen Schrauben einfach mal länger als gefühlte zwei Tage supported werden – Innovation hin oder her. Was schätzen Sie, wie viele Unternehmenskunden aktuell noch auf einer Vanilla-Kubernetes-Version herumjonglieren, deren EOL bereits vor einem Jahr oder deutlich längerer Zeit abgelaufen ist – ganz einfach, damit die Systeme beim längst überfälligen Upgrade nicht komplett explodieren und dann ohnehin from scratch neu aufgebaut werden müssen? Seien Sie versichert, es sind nicht wenige. Und es sind einige durchaus bekannte Namen dabei. Selbstverständlich ist das keine Info, die die CNCF oder die betroffenen Unternehmen gern an die große Glocke hängen. Fatalerweise müssen sich die Unternehmen aber ebendieser hochvolatilen und auf Dauer explosiven Gemengelage permanent neu stellen und anpassen, und dies oft zu einem – im wahrsten Sinne des Wortes – hohen Preis. Kosteneffizienz ist langfristig nun einmal nur mit maximaler Vollautomation zu erreichen. Und die kann mittel- und langfristig niemals erreicht werden, wenn sich das Kernsystem im Unterbau und alle wichtigen...
