Yapay zekâ ajanları ile Kubernetes operatörleri, kontrol döngüsü içinde eşdeğer alternatifler olarak ele alınmamalıdır. Operatör, gerçek durumu izlemek, bunu istenen durumla karşılaştırmak ve sistemi beyan edilen sonuca yaklaştırana kadar belirli kuralları tekrarlanabilir biçimde uygulamak üzere tasarlanmıştır. Ajan ise sonucun bilindiği, ancak bu sonuca ulaşmak için araştırma, bilgi toplama ve ödünleşimlerin değerlendirilmesi gerektiği durumlarda daha faydalıdır.
Cloud Native Computing Foundation’ın (CNCF) sponsor olduğu makale, ajanların bulut-yerel mimariye dâhil edilmesinin yetki sınırlarını belirlemeyi yalnızca bir convention değil, bir tasarım meselesi hâline getirdiğini söylüyor. En güvenli yaklaşım, ajanın düşünme, bağlam oluşturma ve öneriden sorumlu olması; operatörlerin, politika motorlarının ve deterministik sistemlerin ise uygulama yetkisini elinde tutmasıdır.
Düşünmeyi uygulamadan ayıran işletim döngüsü
Bu model, altı aşamalı pratik bir sıra öneriyor: izleme, ardından teşhis, öneri, onay, mutabakat ve son olarak doğrulama. Ajan ilk aşamalarda kaynakları, günlükleri, olayları, metrikleri ve belgeleri inceleyebilir; ancak değişiklikleri uygulama ya da kaynakları değiştirme veya silme yetkisini otomatik olarak almaz. Hassas olmayan okuma işlemleri otomatikleştirilebilirken, etkili değişiklikler açık bir onaydan veya politika geçidinden geçirilir.
CNCF Sandbox kapsamındaki açık kaynaklı bir proje olan kagent, buna örnek teşkil ediyor. Proje, ajanları Kubernetes kaynakları olarak çalıştırıyor ve onları Kubernetes, Helm, gözlemlenebilirlik araçları ve özel araçlarla bağlıyor. Böylece analiz ile uygulama arasındaki bariyerleri kaldırmadan sorunlar araştırılabiliyor veya uzmanlaşmış ajanlar koordine edilebiliyor.
Neden operatörler bir dil modeliyle değiştirilmemeli?
Karpenter’ın durumu bu farkı açıkça ortaya koyuyor. Karpenter, zamanlama kısıtlarıyla ilgilenen ve NodePools ile NodeClaims kaynaklarını eşleştiren bir operatördür. Kullanılmayan düğümler, Spot kaynaklarında dalgalanmalar veya zamanlamayı bekleyen workload’lar ortaya çıktığında, operasyonel bir ajan nedeni araştırmak için NodePool ve EC2NodeClass yapılandırmalarını, olayları, günlükleri, Pod Disruption Budgets’ı ve Prometheus metriklerini inceleyebilir.
Araştırma, tahliyeyi devre dışı bırakma politikasının birleştirmeyi engellediğini, kesinti bütçesinin tahliyeyi kısıtladığını veya consolidateAfter değerinin değişken bir yükte önlenebilir dalgalanmalara yol açtığını ortaya çıkarabilir. Ancak gerekli çıktı “NodePool’u iyileştirin” gibi genel bir öneri değil; kanıtları ve ödünleşimi, etkilenmesi muhtemel düğüm sayısını ve istikrarın izleneceği süreyi açıklayan belirli bir yapılandırma yaması olmalıdır.
Onayın ardından Karpenter, değişikliği kendi mevcut zamanlama ve kesinti mantığına göre uygular. Ajan da sonucu izler ve workload’ların bekleme süresini artırmadan veya zararlı bir kesintiye yol açmadan birleştirmenin iyileşip iyileşmediğini doğrular. Kabul kriterleri karşılanmazsa aynı yol üzerinden geri alma önerilebilir.
Diğer örnek: Argo CD ve Helm yükseltmeleri
Argo CD tarafından yönetilen bir Helm chart yükseltmesinde sürümün Git’te değiştirilmesi görece kolaydır, ancak bunun çalışan uygulama üzerindeki etkisini tahmin etmek daha zordur. Ajan, örneğin readiness probe’u yapılandırmak için kullanılan bir değerin yeni adının sessizce varsayılan bir değere dönmeye yol açabileceğini tespit etmek amacıyla sürüm notlarını, mevcut değerleri ve oluşturulan çıktıları karşılaştırabilir.
Bu bulgu, sürümü ve etkilenen değerleri güncelleyen, operasyonel riski açıklayan ve dağıtım öncesi kontrolleri belirleyen odaklı bir birleştirme isteğine dönüştürülmelidir. İnceleme ve birleştirmenin ardından Argo CD, uygulama politikasına göre çıktıları oluşturur ve senkronize eder. Ancak senkronizasyonun başarılı olması tek başına yükseltmenin güvenli olduğunu kanıtlamaz; yanıt süresi göstergeleri, hata oranları ve kullanılabilirlik incelenmelidir. Kontroller başarısız olursa ajan, veri veya şema değişikliklerinin tamamen geri alınamayabileceğini dikkate alarak değişikliği tersine çevirmeyi veya bir kurtarma planını önerebilir.
Özerklik kademeli olarak kazanılır
Makale, yalnızca okuma ve araştırma yapan bir ajanla başlanmasını, ardından ajana yamalar veya birleştirme istekleri oluşturma izni verilmesini ve sonrasında açık geri alma koşullarına sahip, düşük riskli ve kapsamı belirli değişikliklerin uygulanmasına geçilmesini öneriyor. Bir işlem ancak anlaşılır ve ölçülebilir olduğunda bağımsız hâle gelmelidir.
Editoryal okuma: Buradaki gerçek değişiklik, kubectl veya Helm çağırabilen bir ajan eklemek değil; olasılıksal çıkarımın sınırsız yürütme yetkisine dönüşmemesi için kontrol döngüsünü yeniden tasarlamaktır. Modelin pratik değeri denetlenebilir yetkilendirmenin, sınırlı kapsamın, izlemenin ve etkinin geri alınabilmesinin varlığına bağlıdır. Öneriden özerkliğe geçiş hızını belirleme sorumluluğu insanda kalır; ayrıca makale bu yaklaşımın hata risklerini ortadan kaldırdığını veya her durumda geri almayı mümkün kıldığını kanıtlamıyor.