Fitur AI

Nilai jual terbesar Kudashai adalah kapabilitas AI-Powered-nya. Kami mengintegrasikan Large Language Models (LLMs) ke dalam manajemen Kubernetes sehari-hari Anda.

Provider yang Didukung

Kudashai kompatibel secara fleksibel dengan berbagai provider AI:

• OpenAI (GPT-4)
• Anthropic (Claude)
• Google (Gemini)
• DeepSeek
• Ollama (Local AI)
• LMStudio
• OpenRouter

Model yang Sudah Diuji

Agen KudashAI diverifikasi dengan rangkaian skenario otomatis (diagnosa dari log, kegagalan image pull dan ConfigMap, konteks multi-giliran, penolakan demi keselamatan, dan daftar seluruh cluster). Model di bawah ini lulus semua skenario pada rilis saat ini dan menjadi model yang kami sarankan.

Model	Provider	Berjalan sebagai	Catatan
Gemini 3.8 Flash	Google	API cloud	Tercepat; kurang dari dua menit untuk seluruh rangkaian
DeepSeek V4 Pro	DeepSeek atau gateway yang kompatibel OpenAI	API cloud	Akurasi setara Gemini, sedikit lebih lambat
MiniMax M2.7	Gateway yang kompatibel OpenAI	API cloud	Diverifikasi dengan pagar keluaran bawaan
Qwen3 8B	Ollama	Lokal, sekitar 10 menit untuk rangkaian di Apple Silicon	Model lokal kecil terbaik; otomatis mendapat prompt model kecil
Gemma 4 12B	Ollama	Lokal, sekitar 10 menit untuk rangkaian di Apple Silicon	Lulus rangkaian; lebih lambat per giliran dibanding Qwen3

Model lain pada provider yang didukung tetap bisa dipakai, tetapi perilakunya tidak dijamin. Model lokal di bawah 14B diperlakukan sebagai model kecil: KudashAI meringkas system prompt dan menambahkan aturan yang lebih ketat untuk mereka. Jalankan Assess pada provider setelah menambahkannya agar tier yang tepat tersimpan.

Kapabilitas AI

Di halaman Resource, Anda dapat memanggil AI untuk melakukan:

1. Automated Troubleshooting: Jika sebuah Pod gagal (CrashLoopBackOff atau OOMKilled), AI akan membaca log, menganalisis status, dan menyarankan solusi, hingga memberikan kode konfigurasi yang telah diperbaiki.
2. Config Optimization: Anda bisa meminta AI mengkaji konfigurasi Security Context, limit Resource (CPU/Memory) yang tepat, dan Best Practices pada spesifikasi deployment Anda.
3. Multi-Cluster Diagnostic Scan: Melalui AI Console, Anda dapat meminta AI untuk memindai metrik dan merangkum seluruh status kesehatan klaster-klaster Anda secara sekaligus. Contoh perintah: "Berikan ringkasan pod yang error di semua cluster". AI akan mengekstrak informasi dan memberikan agregasinya kepada Anda secara rapi.

Otorisasi dan Keselamatan

Agen tidak pernah memutuskan sendiri apakah suatu perubahan diizinkan. Tiga pemeriksaan berjalan di kode sebelum perintah mutasi mencapai kartu konfirmasi, dan sekali lagi saat dieksekusi:

Kedua kontrol di bawah tersedia dari halaman Kube configurations: ikon perisai pada kartu cluster membuka dialog akses agen KudashAI (untuk pengguna dengan clusters:manage). Ikon berubah hijau selama ada pembatasan yang aktif.

1. Peran Kudashai. Pengguna yang perannya tidak punya k8s:write (peran Viewer) akan melihat setiap perintah mutasi ditolak, apa pun yang diusulkan model.
2. RBAC Kubernetes. Sebelum menampilkan konfirmasi, KudashAI bertanya ke API server (SelfSubjectAccessReview) apakah identitas yang dipakai boleh menghapus, mengubah skala, mem-patch, atau membuat resource itu. Kubeconfig read-only tidak akan pernah memunculkan kartu konfirmasi untuk perubahan yang tidak mungkin dilakukannya; penolakannya mengutip alasan dari server.
3. Impersonasi agen (opsional, per kredensial cluster). Bila diaktifkan, setiap permintaan agen membawa Impersonate-User: kudashai:<username> dan Impersonate-Group: kudashai:<role>. Kubeconfig yang terdaftar di Kudashai cukup punya hak impersonate, dan RBAC cluster sendiri yang menentukan apa yang boleh dilakukan tiap pengguna Kudashai lewat agen. Aktifkan dengan PATCH /api/v1/app/config/kubeconfigs/<id>/agent-impersonate dan body {"enabled": true}, lalu ikat peran di cluster, misalnya:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kudashai-viewers
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- kind: Group
  name: kudashai:viewer
  apiGroup: rbac.authorization.k8s.io

Terlepas dari semua itu, kebijakan keselamatan bawaan menolak penghapusan namespace terlindungi (kube-system, kube-public, kube-node-lease, default), node, dan penghapusan massal --all di dalam namespace terlindungi, bahkan setelah pengguna menyetujui.

Kebijakan persetujuan per cluster

Administrator dapat membatasi apa yang boleh diubah agen di sebuah cluster, terlepas dari siapa yang meminta dan dari RBAC, lewat PATCH /api/v1/app/config/kubeconfigs/<id>/agent-policy:

{
  "mode": "confirm",
  "disableAutoApprove": true,
  "denyVerbs": ["delete", "apply"],
  "readOnlyNamespaces": ["prod", "payments"]
}

• mode: read_only membuat seluruh cluster read-only bagi agen.
• disableAutoApprove menghilangkan "Approve All" dan rencana yang disetujui otomatis, sehingga setiap perubahan dikonfirmasi satu per satu. Disarankan untuk cluster produksi.
• denyVerbs berisi verb kubectl yang tidak boleh dijalankan agen di cluster ini.
• readOnlyNamespaces berisi namespace yang boleh diperiksa agen tetapi tidak boleh diubah, termasuk menghapus namespace itu sendiri.

Perintah yang ditolak tidak pernah mencapai kartu konfirmasi; pengguna melihat alasan kebijakannya. Kirim {} untuk mengembalikan cluster ke default (setiap mutasi dikonfirmasi, Approve All diizinkan).

Budget: batas keras per sesi dan per jam

Setiap cluster punya budget yang ditegakkan di kode sebelum setiap panggilan model dan sebelum setiap perubahan: token, panggilan model, dan perubahan yang dieksekusi per sesi, serta panggilan model dan perubahan per user per jam di cluster itu. Nilai bawaan (400.000 token, 80 panggilan dan 25 perubahan per sesi; 400 panggilan dan 80 perubahan per jam) bisa diturunkan atau dinaikkan per cluster lewat dialog akses agen, atau diatur untuk seluruh server dengan variabel lingkungan KUDASHAI_AGENT_BUDGET_*. Saat sebuah sesi kehabisan budget, agen berhenti dengan pesan yang menyebut batas mana yang tercapai; perubahan di luar budget ditolak seperti penolakan kebijakan lain dan tidak pernah mencapai kartu konfirmasi. Hitungannya diambil dari jejak agen, sehingga tahan restart dan mencakup semua jalur masuk. Budget ada untuk hari ketika alert, bukan orang, yang memulai sesi: badai alert tidak boleh menjadi badai panggilan model atau perubahan.

Data cluster bukan instruksi

Log, event, anotasi, dan nama resource ditulis oleh workload dan tenant, sehingga KudashAI memperlakukan semua keluaran perintah sebagai data tak tepercaya. Hasil dipagari dan diberi label sebelum model melihatnya; teks yang menyerupai instruksi (misalnya "ignore previous instructions", "system override", atau kubectl delete yang disisipkan di baris log) ditandai dan dilaporkan kepada Anda; dan mutasi yang targetnya hanya pernah muncul di dalam keluaran yang ditandai itu, tanpa Anda meminta perubahan, ditolak sebelum konfirmasi apa pun. Setiap langkah, termasuk penolakan, tercatat di jejak agen untuk audit.

Setiap perubahan di-dry-run sebelum Anda menyetujuinya

Kartu konfirmasi tidak pernah menampilkan perintah telanjang. Sebelum kartu muncul, KudashAI menjalankan dry-run mutasi itu ke cluster dan menaruh hasilnya di kartu: apa yang akan terjadi dalam bahasa operator ("deployment web di shop: replicas 3 → 0", "3 pod-nya akan dihentikan dan tidak dibuat ulang", "dikelola ReplicaSet api-7d9, sehingga pod pengganti akan dibuat") dan, untuk patch, label, anotasi, dan kubectl apply, diff terpadu objek sebelum dan sesudah. Delete diperiksa dengan membaca targetnya; create, patch, dan apply memakai dry-run sisi server API, sehingga kegagalan validasi, kuota, dan admission muncul di titik ini. Perintah yang ditolak cluster saat dry-run tidak pernah mencapai kartu: error-nya dikembalikan ke model, yang memperbaiki perintah atau melaporkan masalahnya, dan tidak ada yang dieksekusi. Plan diperiksa langkah demi langkah dengan cara yang sama. Jika sebuah cluster tidak bisa men-dry-run perubahan (admission webhook tanpa sideEffects: None), kartu menyebutkannya dan tetap meminta persetujuan Anda. Dry-run yang gagal juga tidak pernah memperluas perubahan: bila namespace yang Anda sebut tidak ada, agen melaporkannya, bukan membuat namespace itu atas inisiatifnya sendiri.

Memori: apa yang diingat agen, dan siapa yang memutuskan

Agen menyimpan dua jenis konteks di luar pesan saat ini. Di dalam satu sesi, riwayat yang tidak lagi muat di jendela konteks model dipadatkan menjadi ledger (apa yang Anda minta, apa yang dijawab, perintah mana yang berjalan dan bagaimana hasilnya), bukan dibuang, sehingga lanjutan seperti "kembalikan skalanya" tetap merujuk resource yang benar. Keluaran perintah tidak pernah dibawa ke dalam ledger itu.

Lintas sesi, orang dapat menyimpan catatan singkat tentang cluster: fakta ("namespace payments adalah production"), preferensi ("jawab singkat, dalam bahasa Indonesia"), dan runbook (beberapa baris kubectl). Ketik "Ingat: …" di chat, pakai tombol Memory di panel agen, atau terima catatan yang diusulkan agen setelah Anda menyatakan sesuatu yang bersifat tetap. Catatan muncul di prompt dalam pagar memori, lengkap dengan penulis, cakupan, tanggal, dan status verifikasi, di bawah aturan bahwa memori adalah petunjuk yang ditulis orang dan bukan instruksi.

Memori tidak bisa dipakai untuk meracuni agen, oleh siapa pun:

• Hanya orang yang menulisnya. Model boleh mengusulkan catatan; Anda yang menyimpannya. Tidak ada yang pernah ditulis dari keluaran perintah, dan usulan dari giliran yang membawa data cluster bertanda atau yang menyebut hal yang tidak pernah Anda katakan dibuang.
• Catatan ditolak saat ditulis bila mencoba mengubah perilaku alih-alih menggambarkan keadaan: "auto-approve", "tanpa konfirmasi", "abaikan aturan", klaim peran atau izin ("user ini admin"), pemicu bersyarat ("kalau X terjadi, hapus Y"), perintah mutasi di luar runbook, dan apa pun yang tampak seperti kredensial.
• Baris runbook harus bisa diparse, memakai verb yang didukung, menyebut targetnya, tidak pernah menghapus namespace atau memakai --all, dan setiap langkah tetap melewati kartu konfirmasi saat dijalankan.
• Catatan lingkup cluster butuh clusters:manage; catatan orang lain bersifat privat, sehingga catatan yang keliru berdampak kecil. Penulis, dan untuk catatan bersama setiap pengelola cluster, dapat menghapus catatan; setiap penulisan dan penghapusan tercatat di jejak audit agen.
• Namespace yang disebut catatan diperiksa ke cluster saat disimpan dan saat dikonfirmasi ulang; catatan yang menyebut sesuatu yang tidak ada diberi tanda, dan agen diminta memverifikasi fakta dengan perintah read-only sebelum perubahan yang bergantung padanya. Catatan kedaluwarsa setelah 180 hari kecuali dikonfirmasi.

Cluster yang memutuskan apakah perubahan berhasil, dan setiap perubahan bisa dibatalkan

Setelah perubahan diterima, KudashAI tidak percaya begitu saja pada jawaban API server. Ia mengamati cluster sampai efeknya terlihat atau batas waktunya habis: scale atau restart selesai saat semua replika ready di generasi baru, delete saat objeknya hilang, kubectl run saat pod Running dan Ready, apply saat setiap objek di manifest memenuhi ukuran yang sama. Hasilnya muncul sebagai baris post-check ("ok, 8s: deployment web di shop: 3/3 replika ready", atau "timeout, 45s: 1/3 ready; pod yang perlu perhatian: web-x (ImagePullBackOff)") di chat dan di hasil yang dilihat model, sehingga model melaporkan status yang teramati. Jawaban yang mengklaim berhasil setelah post-check gagal mendapat catatan sistem yang terlihat.

Sebelum perubahan berjalan, agen mencatat apa yang akan diubahnya: objek seperti apa adanya, atau fakta bahwa sebuah objek akan dibuat atau dihapus. Catatan itu menjadi tawaran Undo di bawah hasil. Undo lebih dulu menampilkan dry-run dari apa yang akan dipulihkan, dibuat ulang, atau dihapus, lalu menerapkannya setelah konfirmasi, memverifikasi efeknya dengan cara yang sama, dan tercatat di audit. Undo tunduk pada aturan yang sama dengan perubahan aslinya: peran Anda, kebijakan persetujuan cluster, verb yang dilarang, dan namespace read-only. Undo hanya sekali pakai dan kedaluwarsa setelah 24 jam; namespace dan pod milik controller tidak punya undo, karena membuatnya ulang tidak mengembalikan isinya atau akan dibatalkan sendiri oleh controller.

Desktop: shell yang mengikuti cluster

Di Kudashai Desktop, panel agent punya tombol Terminal. Tombol itu membuka shell di mesin Anda sendiri, di panel terminal bagian bawah, dengan KUBECONFIG yang menunjuk ke salinan privat credential untuk cluster yang sedang dibuka, context-nya sudah terpilih. Alias, plugin, dan CLI cloud Anda bekerja seperti di terminal biasa; salinan itu dihapus saat shell ditutup.

Dua hal yang menghubungkan shell itu dengan agent:

• Attach terminal. Setelah shell terbuka, tombol yang sama mengatur apakah baris-baris terakhir output-nya ikut dikirim bersama prompt berikutnya, jadi "error ini kenapa?" bisa merujuk ke apa yang baru Anda jalankan. Output itu diberikan ke model sebagai data untrusted, sama seperti output command lain.
• Run in my terminal. Setiap confirmation card punya pilihan keempat di samping Approve dan Reject: command diketikkan di prompt shell Anda dan tidak ada yang jalan sampai Anda menekan Enter. Agent tidak mengeksekusinya dan tidak mengulanginya. Setelah itu chat mengawasi shell Anda; begitu command selesai dan prompt kembali, muncul card berisi output-nya dengan tombol Show me the result, yang menyerahkan output itu ke agent sebagai pesan berikutnya. Kalau card tadi berasal dari task plan, langkah yang tersisa kembali sebagai Task Plan card untuk dijalankan saat Anda siap.

Host shell hanya ada di build desktop. Di server, endpoint-nya tidak tersedia. Terminal milik user yang membukanya, dan yang bisa masuk lewat HTTP hanya ketikan: API mengetik teks di prompt tapi tidak pernah menekan Enter, jadi tidak ada request yang bisa menjalankan command. Buka, ketik, dan tutup tercatat di audit log.

Mode sesi: Plan, Confirm, Auto

Pilih seberapa banyak agent boleh bertindak sendiri di sesi ini lewat menu Mode di sebelah pemilih model (tombol 1–3 saat menu terbuka):

• Plan — read-only. Setiap perubahan diusulkan sebagai plan; tidak ada yang berjalan sampai Anda mengeksekusi plan itu, dan tiap langkahnya pun tetap minta konfirmasi.
• Confirm — default. Setiap perubahan di-dry-run dan menunggu di confirmation card.
• Auto — perubahan berisiko rendah pada workload biasa (scale, rollout restart, label, annotate, patch, set) berjalan sendiri, tetap dengan dry-run, post-check, dan undo. Selain itu tetap bertanya, dan card-nya menjelaskan alasannya: delete, apply, apa pun yang menyentuh RBAC, namespace, node, secret, atau namespace sistem, dan target yang diberi warning oleh catatan memory. Kalau ada post-check yang gagal atau ada rollback, Auto berhenti untuk sisa sesi dan semua perubahan kembali bertanya.

Pilihan Anda dibatasi policy cluster: cluster read-only hanya mengizinkan Plan, "confirm one change at a time" berhenti di Confirm, dan Auto butuh provider yang sudah disertifikasi suite evaluasi. Kalau server menerapkan mode yang berbeda dari pilihan Anda, console memberi tahu.

Budget langkah dan mutasi per sesi hanya berlaku untuk kerja tanpa pengawasan (Auto, "Approve All"). Di Plan dan Confirm Anda sendiri yang menekan send dan menyetujui tiap perubahan, jadi sesi debugging yang panjang hanya dibatasi budget token dan rate limit per jam.

Diagnosis dari alert: langkah pertama tanpa pengawasan

Alert cluster (pod crash atau gagal, node NotReady, deployment gagal, autoscaler mentok) bisa memulai sesi KudashAI tanpa ada yang mengetik. Yang dimulai sengaja dibuat sempit: diagnosis. Sesi berjalan dengan executor read-only, sehingga setiap mutasi yang mungkin diusulkan model ditolak sebelum menyentuh cluster; hasilnya adalah sesi di riwayat administrator yang mengaktifkan trigger, berjudul [auto] …, berisi penyebab dan, bila model mengusulkannya, plan yang bisa dibuka dan disetujui orang. Budget, aturan memori, pertahanan injeksi, dan kebijakan cluster berlaku tanpa perubahan karena kode yang sama yang berjalan. Setiap resource mendapat satu sesi per cooldown (bawaan 30 menit) dan setiap cluster paling banyak beberapa sesi per jam (bawaan 6). Ringkasannya juga dikirim ke integrasi yang Anda konfigurasi sebagai custom event.

Tidak semua model boleh melakukannya. Trigger menunjuk satu provider, dan provider itu harus tersertifikasi: suite evaluasi verified, memory, dan outcome harus lulus semua pada model yang dipakai provider saat ini (jalankan agenteval -certify), dalam 30 hari terakhir, dan modelnya bukan tier kecil. Baru setelah itu administrator bisa menyalakan Allow unattended sessions untuk provider tersebut; run yang gagal mencabut sertifikasi sekaligus sakelarnya. Aktifkan trigger per cluster dari dialog akses agen, dengan memilih provider dan jenis alert.

AI Chat Interface

Kudashai juga dilengkapi ruang Chatbot AI terintegrasi di mana Anda dapat secara alami ("natural language") meminta informasi terkait cluster atau meminta pembuatan manifest.

Contoh interaksi:

"Tolong buatkan Deployment NGINX sebanyak 3 replika dengan port 80 diexpose lewat Service NodePort."

Kudashai akan men-generate konfigurasi K8s yang tepat berdasarkan pertanyaan Anda.

Privacy by Default: Karena mendukung Local AI (seperti Ollama), Anda dapat menjalankan model AI secara on-premise, menjaga kerahasiaan topologi cluster Anda dengan skema zero cloud dependency.