Rola agentów sztucznej inteligencji w pętli sterowania Kubernetes

abstract pink purple 3D render — Maxim Berg / Unsplash

Kubernetes od zawsze korzystał z agentów, jednak nie są to rodzaje znane z obecnych dyskusji o sztucznej inteligencji. W systemie tym kontroler monitoruje stan aktualny, porównuje go z zadeklarowanym stanem pożądanym i podejmuje działania, aby zniwelować różnicę. Choć przypomina to działanie agentów sztucznej inteligencji, nie są oni zamienni z operatorami Kubernetes.

Kwestia ta przestała być teoretyczna, ponieważ w ciągu ostatnich osiemnastu miesięcy narzędzia dla agentów stały się częścią stosu natywnego dla chmury. CNCF zaakceptowała frameworki agentowe do swojego projektu Sandbox, a Kubernetes SIG Apps przyjęła Agent Sandbox jako podprojekt służący do bezpiecznego uruchamiania obciążeń agentowych.

Zespoły platformowe decydują obecnie, co agent może zmienić w działającym klastrze, zazwyczaj za pomocą pojedynczych żądań o złączenie, bez spisanej polityki. Granica między rozumowaniem a wykonaniem jest ustalana przez konwencję, a nie przez projekt.

Operator Kubernetes jest zaprojektowany tak, aby być przewidywalnym, uzgadnia zasoby zgodnie z zakodowanymi regułami i dąży do zadeklarowanego stanu. Agent sztucznej inteligencji jest przydatny, gdy cel jest jasny, ale ścieżka do niego nie. Potrafi on zbadać nieznaną sytuację, zebrać kontekst z wielu systemów, rozważyć kompromisy i zaproponować plan działania.

Bezpieczniejszy wzorzec architektoniczny łączy te cechy, gdzie agent dostarcza rozumowanie i kontekst, a operatorzy, silniki polityk i inne systemy deterministyczne zachowują kontrolę nad wykonaniem. Przykładem jest kagent, projekt CNCF Sandbox, który uruchamia agentów sztucznej inteligencji jako zasoby Kubernetes i łączy ich z Helm, narzędziami do obserwowalności oraz innymi instrumentami. Agent może sprawdzać zasoby, pobierać logi, zdarzenia i metryki oraz konsultować dokumentację.

Nie każde narzędzie powinno mieć pełną swobodę wykonawczą. Operacje odczytu niejawnych danych mogą być automatyczne, ale zmiany, takie jak nakładanie, poprawianie lub usuwanie zasobów, mogą wymagać wyraźnej zgody. Pozwala to agentowi na szerokie badanie bez dawania niepewnemu procesowi rozumowania nieograniczonej władzy nad klastrem.

Operacyjna pętla składa się z etapów: obserwacja, diagnoza, propozycja, zatwierdzenie, uzgadnianie i weryfikacja. Pierwsze trzy kroki wykorzystują rozumowanie agentowe, natomiast Kubernetes i jego operatorzy zajmują się uzgadnianiem. Weryfikacja zamyka pętlę, nie zakładając, że zaakceptowana zmiana przyniosła zamierzony rezultat.

Przykładem jest Karpenter, który jest operatorem oceniającym ograniczenia harmonogramowania. Zastąpienie jego logiki dużym modelem językowym uczyniłoby pętlę sterowania mniej przewidywalną. Agent oparty na kagent powinien działać powyżej Karpenter, analizując konfiguracje, zdarzenia i metryki Prometheus, aby zrozumieć, dlaczego zachowanie systemu różni się od celu zespołu. Wynikiem pracy agenta nie powinna być ogólna rekomendacja, lecz dowody, analiza kompromisów i precyzyjna poprawka konfiguracji, która przechodzi przez bramkę zatwierdzeń.

Podobnie w przypadku Argo CD, zmiana wersji wykresu Helm w systemie Git jest prosta, ale zrozumienie wpływu tej zmiany na aplikację wymaga więcej pracy. Agent może porównać notatki z wydania, istniejące wartości i wyrenderowane manifesty, aby zidentyfikować ryzyka operacyjne i przygotować ukierunkowane żądanie o złączenie.