Fallen bei der Wartung von Platform Engineering und clevere Strategien, um voraus zu bleiben

TL;DR

Platform Engineering zielt darauf ab, die Produktivität von Software-Engineering-Teams durch die Entwicklung und Wartung interner Plattformen zu steigern. Die Wartung solcher Plattformen, insbesondere in Kubernetes-Umgebungen, erfordert kontinuierliche Anpassungen an Software-Upstream-Änderungen, Sicherheitsupdates und Helm-Chart-Upgrades. Automatisierung und strategische Planung sind entscheidend, um die Herausforderungen in der Software-Lieferkette zu bewältigen.

Hauptinhalt

Platform Engineering ist eine Disziplin, die darauf abzielt, die Effizienz von Software-Engineering-Teams zu erhöhen, indem interne Plattformen entwickelt werden, die die Komplexität der zugrunde liegenden Infrastruktur abstrahieren und Selbstbedienungsfunktionen bereitstellen. [Kubernetes]-basierte Plattformen sind häufig komplexe Integrationen verschiedener Open-Source-Software (OSS), was bedeutet, dass Platform Engineering kein einmaliger Prozess ist. Vielmehr erfordert es eine kontinuierliche Wartung der Abhängigkeiten und Strategien zur Handhabung unvermeidlicher Breaking Changes.

Die Integration von 14 OSS-Projekten, die auf einem Kubernetes-Cluster basieren, stellt eine Vielzahl von Herausforderungen dar. Dazu gehören das Aufholen von Software-Upstream-Änderungen, die Kontrolle der Lieferkette, die Aktualisierung von Kubernetes-Versionen, die Pflege von Helm-Chart-Upgrades und die Wartung von Anwendungen mit persistenten Daten.

Ein zentrales Problem besteht darin, mit den Upstream-Änderungen Schritt zu halten. Analysen zeigen, dass jährlich zwischen 2-5 große Upgrades, 43-52 kleinere Upgrades und 276-327 Software-Patches anfallen. Diese häufigen Änderungen erfordern eine proaktive Überwachung und schnelle Implementierung von Sicherheits-Patches, da täglich Sicherheitsanfälligkeiten entdeckt werden.

Die Kontrolle der Lieferkette hat sich als kritisch erwiesen, da [Container]-Registries und Helm-Chart-Repositories anfällig für plötzliche Änderungen oder Ratenbegrenzungen sind. Um die Auswirkungen solcher Änderungen zu minimieren, kann es sinnvoll sein, einen dedizierten Container-Registry-Cache und ein Mono-Repository für Helm-Charts zu pflegen. Dies ermöglicht es Plattform-Ingenieuren, sich Zeit zu verschaffen, um sich auf neue Versionen vorzubereiten.

Kubernetes-Versionen werden in der Regel 12 Monate lang unterstützt, wobei Cloud-Plattformanbieter häufig schnellere Adoptionszyklen fordern. Dies kann dazu führen, dass Helm-Charts auf veraltete APIs angewiesen sind, was eine unvermeidliche Aktualisierung erforderlich macht. Ein Kubernetes-Konformitätstest kann dabei helfen, potenzielle Breaking Changes frühzeitig zu identifizieren.

Die Verantwortung für die Auswirkungen von Deployments liegt vollständig bei den Plattformbetreibern. Obwohl Community-Helm-Charts den Aufwand zur Definition von Manifests reduzieren können, bleibt die Notwendigkeit, die Auswirkungen neuer Chart-Versionen zu verstehen, bestehen. In vielen Fällen ist eine bloße Überprüfung des Go-Template-Codes nicht ausreichend, um die Folgen eines neuen Charts zu bewerten.

Technische Details/Implikationen

Die Automatisierung von Wartungsaufgaben, insbesondere bei der Identifizierung neuer Anwendungsversionen, kann den Wartungsaufwand erheblich reduzieren. Dazu können Skripte verwendet werden, die Pull-Requests für neue Versionen generieren. Zudem ist die Implementierung eines benutzerdefinierten Plattform-Operators ratsam, um Änderungen an unveränderlichen Kubernetes-Eigenschaften zu verwalten und reibungslose Upgrades zu gewährleisten.

Fazit/Ausblick

Die Herausforderungen im Platform Engineering erfordern eine strategische Herangehensweise an Wartung, Automatisierung und Planung. Zukünftige Entwicklungen in der OSS-Community und der Kubernetes-Landschaft werden weiterhin neue Anforderungen an die Wartung und Anpassung von Plattformen stellen.