Im ersten Quartal 2026 startete die CNCF Platform Engineering Technology Community Group (TCG) die Aktualisierung von zwei grundlegenden Dokumenten:Whitepaper „Plattform als Produkt“.UndPlattform-Engineering-Reifegradmodell. Das Ziel der Community besteht darin, den Entwurf vor der KubeCon EU 2026 zu veröffentlichen und die Sicherheit von KI-Tools in die Plattform-Governance zu integrieren. Gleichzeitig ist der am 29. Mai 2026 von CNCF veröffentlichte Praxisartikel sehr einfach: Die moderne Bereitstellung wird nicht mehr durch den Anwendungscode, sondern durch die Plattform, die ihn hostet, eingeschränkt. Für ein Team wie Wishes Niu Technology, das unternehmensspezifische Entwicklungen durchführt, ist dieser Satz näher an den wirklichen Schwachstellen als „die Rekrutierung von zwei weiteren Backends“ – Umgebungsdrift, in die Pipeline geschriebene Schlüssel, Rollbacks, die auf mündlichen Vereinbarungen beruhen, und die Beobachtung, zu warten, bis etwas schief geht.
1. Zerlegen Sie zuerst die drei Schichten und sprechen Sie dann über „Sollen wir K8s verwenden?“
Die obige CNCF-Praxis unterteilt die Plattform inInfrastrukturschicht, Plattformschicht, AnwendungsschichtUnd eine klare Warnung: Wenn die drei Schichten zu früh in dasselbe Lager gebracht werden, steigen die späteren Wartungskosten stark an. Die Infrastrukturschicht ist für das Netzwerk, Cluster, Spiegellager und Schlüsselbasen verantwortlich; Die Plattformschicht stellt GitOps-Controller, Richtlinien, Service-Grids und beobachtbare Komponenten bereit. Die Anwendungsschicht sind die Geschäfts-Microservices des Kunden. Die häufigste Fehlbedienung bei Anpassungsprojekten besteht darin, Kundengeschäftscode, Jenkins-Skripte und Cluster-Parameter in dasselbe Dokument zu schreiben. Dies führt dazu, dass bei einer Änderung der Umgebung das gesamte Lager verändert werden muss.
1.1 Kleine und mittlere Teams sollten nicht die Werkzeugliste großer Hersteller kopieren
In demselben Artikel wurde auch eingeräumt, dass das vorzeitige Stapeln überlappender Werkzeuge eine typische Gefahr im CNCF-Ökosystem darstellt. Istio, OpenTelemetry und Multi-Cluster ApplicationSet können alle nachinstalliert werden. Für benutzerdefinierte Projekte mit einem halbjährigen Bereitstellungszyklus lautet der pragmatischere Mindestsatz: eine reproduzierbare Umgebungsdefinition, eine Build-Pipeline mit Scannen und Signieren sowie eine Release-Methode, die Git als die einzige Wahrheit behandelt. Ohne diese drei Dinge spaltet die sogenannte „Microservice-Transformation“ den Monolithen lediglich in eine Reihe von Prozessen auf, die sich gegenseitig in ihren Konfigurationen kopieren.
2. Behandeln Sie die Plattform als Produkt und nicht als Sammlung von Betriebs- und Wartungsskripten
CNCF schreibt Plattform-Engineering als „Platform as a Product“. Der Kern besteht nicht darin, eine weitere Reihe von Portalen zu kaufen, sondern darinInterne Entwickler als Kunden. Einer der Kernpunkte der Überarbeitung des Whitepapers und des Reifegradmodells im Jahr 2026 besteht darin, reale Szenarien hinzuzufügen, damit Organisationen beurteilen können, auf welchem Niveau sie sich befinden, und im nächsten Schritt nur eine Sache ändern können. Wenn ein Unternehmen für kundenspezifische Software Jenkins von Grund auf erstellt, Dockerfile von Grund auf schreibt und für jedes Projekt eine Testbibliothek von Grund auf beantragt, wird der Lieferzyklus durch die „Steuer auf doppelte Arbeit“ verschlungen. Das erste Ziel der internen Entwicklungsplattform (IDP) besteht darin, einen goldenen Weg für ähnliche Projekte bereitzustellen: Erstellen eines Lagers, Beantragen einer Umgebung, Ausführen von Tests, Vorschau und Veröffentlichung. Entwickler füllen lediglich die geschäftlichen Unterschiede aus.
- Deklarative Infrastruktur: Die Umgebung kann rekonstruiert werden, statt „nur Lao Wang kann diese Maschine besteigen“.
- Kontinuierliche GitOps-Abstimmung: Der Clusterstatus unterliegt Git und manuelle kubectl-Änderungen an der Produktion müssen zurückgezogen werden können.
-
Die Lieferkette ist standardmäßig aktiviert: Abhängigkeitsscan, Bildsignierung, Verbot
latestTags, die vor dem Eintritt in den Cluster abgefangen werden. - Beobachtbarkeit ist eine Plattformfähigkeit: Indikatoren, Protokolle und Alarme werden mit dem goldenen Pfad bereitgestellt, anstatt einen Satz hinzuzufügen, nachdem Sie online gegangen sind.
3. Die Sicherheit der Lieferkette muss auf „vor dem Einsatz“ verlagert werden.
Die IDP-Praxis der CNCF trennt Bau, Sicherheitsüberprüfung und Infrastrukturänderungen in unabhängige Pipelines. Die Anwendungspipeline ist für die Kompilierung, Unit-Tests, SAST, Trivy-Scanning auf Abhängigkeiten und Cosign-Signierung vor dem Betreten des Lagers verantwortlich. Die Sicherheitspipeline überprüft Signaturen erneut, scannt Bilder und verwendet KubeSec, um das Manifest anzuzeigen. Erst nach Übergabe des Codes darf der GitOps-Controller synchronisieren. Ihre Beobachtungen in der internen experimentellen Umgebung sind: Die Erfolgsquote der Bereitstellung ist von etwa 70 % in manuellen Prozessen auf etwa 95 % gestiegen, die Vorbereitung der Infrastruktur wurde von Stunden auf weniger als 15 Minuten reduziert und etwa 80 % der Schwachstellenentdeckungen können vor der Produktion verhindert werden. Diese Zahlen stammen aus dem Labor und vor der Veröffentlichung und können nicht direkt in Kundenverpflichtungen niedergeschrieben werden, aber die Richtung ist klar –—Ändern Sie das Verifizierungsrecht von „Personen starren auf den Bildschirm“ in „Ablehnung am Fließband“..
| Ebene | Plattformfunktionen | Was entspricht dem maßgeschneiderten Projekt? | Tun Sie es nicht sofort |
|---|---|---|---|
| Infrastruktur | Netzwerk, Cluster, Lager, Schlüssel | Drei Basissätze für Kundentests/Vorabversion/Produktion | Ändern Sie die Sicherheitsgruppe manuell, ohne den Code zurückzuschreiben |
| Plattform | GitOps, Strategie, Beobachtung | Einheitliche Veröffentlichung, einheitliches Rollback und einheitlicher Alarm | Jedes Projekt entwickelt seine eigene Jenkins-Philosophie |
| Anwendung | Unabhängig veröffentlichbare Unternehmensdienstleistungen | Bestell-, Inventar-, Genehmigungs- und andere Kundenmodule | Fügen Sie den Schlüssel und den Geschäftscode in dasselbe Bild ein |
| Regierungsführung | Unterschriften, Zulassungsrichtlinien, Prüfung | Sicherheits- und Akzeptanzklauseln in Verträgen können maschinell überprüft werden | Treffen Sie eine mündliche Vereinbarung, „vor dem Online-Gehen noch einmal zu scannen“ |
4. Die Landesequenz für das Anpassungsteam
Reifegradmodelle betonen umsetzbare nächste Schritte, anstatt das Portal auf einmal zu kaufen. Wishing Niu Technology empfiehlt, je nach Projekttyp den engsten goldenen Pfad zu kürzen: Beispielsweise sollte „Java-Dienst + MySQL + Objektspeicher“ zuerst durchlaufen und dann auf das Frontend und die Nachrichtenwarteschlange erweitert werden. Zugriffsstrategien wie Kyverno priorisieren nur das AbfangenlatestSpiegelungs- und Klartextschlüssel; Istio hält sich streng an mTLS und muss nicht für Cluster einheitlich sein. Wie im Übungsartikel beschrieben, führt eine zu frühe Aktivierung von Strict dazu, dass alle Dienste ohne Sidecars getrennt werden. Der richtige Ansatz besteht darin, zuerst „Permissiv“ zu sein und dann nach Namespace zu schneiden.
- Frieren Sie zunächst eine Reihe von Umgebungsmodulen (Netzwerk, Computer, Schlüssel) ein und verwenden Sie variable Dateien, um Entwicklung/Vorabversion/Produktion zu unterscheiden.
- Dann verwandeln Sie das Build-Produkt in ein „überprüfbares Artefakt“: Nur wenn Versionsnummer, Scan-Bericht und Signatur erfasst werden, kann es vorab veröffentlicht werden.
- Lassen Sie Git dann zum Release-Portal werden, und Rollback bedeutet, dass der Commit rückgängig gemacht wird, anstatt sich am Computer anzumelden, um die Datei zu überschreiben.
- Der letzte Schritt besteht darin, ein Self-Service-Portal aufzubauen. Ohne die ersten drei Schritte ist ein Portal nur Chaos, verpackt in Knöpfe.
Beim Plattform-Engineering geht es nicht darum, benutzerdefinierten Projekten ein „Cloud-natives Aussehen“ zu verleihen. Was gelöst werden soll, ist: Die zweite Lieferung des gleichen Systemtyps sollte nicht langsamer sein als die erste. Wenn Sie eine Reihe paralleler Unternehmenssysteme evaluieren, zählen Sie zunächst, wie viele Stunden das Team jede Woche damit verbringt, „auf die Umgebung zu warten, die Konfiguration zu korrigieren und zu erraten, wer sie geändert hat“, und entscheiden Sie dann, von welchem Geschäftsbereich der goldene Weg abgeschnitten werden soll. Dies ist beim nächsten Meilenstein einfacher zu akzeptieren, als zunächst einen großen Entwurf für die mittlere Phase zu zeichnen.