KI-Agenten und Kubernetes-Operatoren sollten innerhalb eines Regelkreises nicht als gleichwertige Alternativen betrachtet werden. Ein Operator ist darauf ausgelegt, den tatsächlichen Zustand zu überwachen, ihn mit dem gewünschten Zustand zu vergleichen und anschließend klar definierte Regeln wiederholbar auszuführen, bis sich das System dem angegebenen Ergebnis annähert. Ein Agent ist dagegen besonders nützlich, wenn das Ergebnis bekannt ist, der Weg dorthin jedoch Untersuchung, Informationssammlung und die Abwägung von Zielkonflikten erfordert.
Der von der Cloud Native Computing Foundation (CNCF) unterstützte Beitrag erklärt, dass die Einbindung von Agenten in Cloud-native-Infrastrukturen die Festlegung von Berechtigungsgrenzen zu einer Designfrage und nicht bloß zu einer Konvention macht. Die sicherste Form besteht darin, den Agenten für Schlussfolgerungen, Kontext und Vorschläge verantwortlich zu machen, während Operatoren, Policy-Engines und deterministische Systeme die Ausführungsbefugnis behalten.
Ein Betriebsregelkreis, der Schlussfolgerungen und Ausführung trennt
Dieses Modell schlägt eine praktische Abfolge von sechs Phasen vor: Überwachung, anschließend Diagnose, Vorschlag, Genehmigung, Abgleich und schließlich Überprüfung. In den frühen Phasen kann der Agent Ressourcen, Logs, Ereignisse, Metriken und Dokumentation prüfen, erhält jedoch nicht automatisch die Berechtigung, Änderungen anzuwenden oder Ressourcen zu ändern oder zu löschen. Nicht sensible Lesevorgänge können automatisiert ausgeführt werden, während folgenreiche Änderungen eine ausdrückliche Genehmigung oder ein Policy-Gateway durchlaufen.
Das Projekt kagent, ein Open-Source-Projekt innerhalb der CNCF Sandbox, veranschaulicht dies. Es führt Agenten als Kubernetes-Ressourcen aus und verbindet sie mit Kubernetes, Helm, Monitoring-Tools und benutzerdefinierten Werkzeugen. Dadurch können Probleme untersucht oder spezialisierte Agenten koordiniert werden, ohne die Schranken zwischen Analyse und Ausführung aufzuheben.
Warum Operatoren nicht durch ein Sprachmodell ersetzt werden sollten
Der Fall Karpenter verdeutlicht den Unterschied. Karpenter ist ein Operator, der mit Scheduling-Einschränkungen umgeht und die Ressourcen von NodePools und NodeClaims abgleicht. Wenn nicht ausgelastete Nodes, Schwankungen bei Spot-Ressourcen oder Pods auftreten, die auf ihre Einplanung warten, kann ein Betriebsagent die Konfigurationen von NodePool und EC2NodeClass sowie Ereignisse, Logs, Pod Disruption Budgets und Prometheus-Metriken prüfen, um die Ursache zu ermitteln.
Die Untersuchung kann ergeben, dass eine Eviction-Deaktivierungsrichtlinie die Konsolidierung verhindert, dass ein Disruption Budget die Eviction behindert oder dass der Wert consolidateAfter bei einer wechselnden Last vermeidbare Schwankungen verursacht. Das gewünschte Ergebnis ist jedoch keine allgemeine Empfehlung wie „NodePool optimieren“, sondern ein konkreter Konfigurations-Patch, der die Belege und den Zielkonflikt erläutert sowie die potenziell betroffene Anzahl von Nodes und die Dauer der Stabilitätsüberwachung angibt.
Nach der Genehmigung führt Karpenter die Änderung gemäß seiner vorhandenen Scheduling- und Disruption-Logik aus. Anschließend überwacht der Agent das Ergebnis und überprüft, ob sich die Konsolidierung verbessert, ohne die Wartezeit der Pods zu erhöhen oder schädliche Störungen zu verursachen. Wenn die Akzeptanzkriterien nicht erfüllt werden, kann über denselben Pfad ein Rollback vorgeschlagen werden.
Das andere Beispiel: Argo CD und Helm-Upgrades
Bei einem von Argo CD verwalteten Helm-Chart-Upgrade ist die Änderung der Version in Git vergleichsweise einfach, die Einschätzung ihrer Auswirkungen auf die laufende Anwendung jedoch schwieriger. Der Agent kann Release Notes, aktuelle Werte und generierte Daten vergleichen und beispielsweise feststellen, dass ein neuer Name für einen Wert zur Konfiguration der Readiness-Probe dazu führen könnte, dass stillschweigend auf einen Standardwert zurückgefallen wird.
Dieses Ergebnis sollte in eine fokussierte Merge-Anfrage überführt werden, die die Version und die betroffenen Werte aktualisiert, das Betriebsrisiko erläutert und Prüfungen vor der Bereitstellung festlegt. Nach Prüfung und Merge übernimmt Argo CD die Generierung der Daten und deren Synchronisierung gemäß der Anwendungspolitik. Eine erfolgreiche Synchronisierung allein reicht nicht aus, um die Sicherheit des Upgrades zu belegen; vielmehr müssen Kennzahlen zu Latenz, Fehlerraten und Verfügbarkeit geprüft werden. Wenn die Prüfungen fehlschlagen, kann der Agent das Rückgängigmachen der Änderung oder einen Wiederherstellungsplan vorschlagen, wobei zu berücksichtigen ist, dass Änderungen an Daten oder am Schema möglicherweise nicht vollständig rückgängig gemacht werden können.
Autonomie wird schrittweise erworben
Der Beitrag empfiehlt, mit einem Agenten zu beginnen, der ausschließlich liest und Untersuchungen durchführt, ihm anschließend das Erstellen von Patches oder Merge-Anfragen zu gestatten und danach Änderungen mit geringem Risiko und begrenztem Umfang auszuführen, sofern klare Rollback-Bedingungen vorhanden sind. Eine Aktion wird erst dann autonom, wenn sie verständlich und messbar ist.
Redaktionelle Einschätzung: Die eigentliche Veränderung besteht hier nicht darin, einen Agenten hinzuzufügen, der kubectl oder Helm aufrufen kann, sondern darin, den Kontrollregelkreis neu zu gestalten, damit probabilistische Schlussfolgerungen nicht zu uneingeschränkter Ausführungsbefugnis werden. Der praktische Wert des Modells hängt von überprüfbarer Delegation, begrenztem Umfang, Überwachung und der Möglichkeit ab, Auswirkungen rückgängig zu machen. Die Verantwortung des Menschen bleibt bei der Festlegung bestehen, wie schnell vom Vorschlag zur Autonomie übergegangen wird. Außerdem belegt der Beitrag nicht, dass dieser Ansatz Fehlerrisiken beseitigt oder ein Rollback in allen Fällen ermöglicht.