Kubernetes beta

Klaster Kubernetes (k3s) di server milik Anda sendiri, dipasang dan dirawat Saka. Tanpa biaya control plane, tanpa load balancer cloud, dan tanpa YAML untuk aplikasi biasa.

Untuk siapa

Tim yang sudah memakai container dan Kubernetes, atau mulai menjalankan banyak layanan di banyak server. Untuk satu situs atau satu aplikasi, Situs dan Aplikasi dari Git lebih sederhana.

Buat klaster

1. Siapkan server kosong (tanpa situs Saka), Ubuntu 24.04, RAM minimal 2 GB, sebaiknya di satu region. Hubungkan ke Saka seperti server biasa.
2. Buka menu Kubernetes, tekan Buat klaster, beri nama, lalu pilih servernya.
3. Peran ditentukan otomatis: 1-2 server = 1 control plane; 3 atau lebih = 3 control plane (klaster tetap jalan saat satu mati) dan sisanya worker.

Saka memasang k3s, menggabungkan node lewat jaringan privat bila server satu subnet (di luar itu lewat WireGuard terenkripsi di IP publik), lalu memasang komponen bawaan. Klaster 3 node siap dalam sekitar 2 menit; Anda dikabari saat selesai.

Token gabung diambil dari node pertama dan langsung diteruskan ke node lain tanpa disimpan Saka. Kubeconfig juga tidak disimpan; perintah dijalankan agent di control plane.

Komponen & setelan bawaan

• Traefik di setiap node (DaemonSet). Bawaan k3s hanya satu salinan; dalam uji kami, matinya node yang memegang salinan itu membuat 11% permintaan gagal.
• cert-manager dengan penerbit Let's Encrypt, untuk HTTPS otomatis.
• Node mati terdeteksi dalam 20 detik dan pod dipindah 30 detik kemudian (bawaan Kubernetes sekitar 5 menit). Ingress aplikasi mencoba ulang ke salinan lain.

Hasil uji di IDCloudHost, 6 node dengan jaringan privat: control plane yang memegang etcd dan Traefik dimatikan paksa, 1% permintaan gagal selama 14 detik, API Kubernetes tetap menjawab, dan semuanya lengkap lagi dalam 76 detik.

Adopsi klaster yang sudah ada

Untuk klaster k3s yang Anda pasang sendiri: pasang agent Saka di setiap server klaster, lalu tekan Adopsi klaster dan pilih salah satu control plane. Node lain dikenali lewat IP atau hostname. Saka menambahkan Traefik di setiap node dan cert-manager; workload Anda tidak diubah.

Deploy aplikasi

Semua aplikasi mulai dari satu tombol, Deploy aplikasi, lalu pilih sumbernya: Upload kode, Dari Git, Docker image, atau Helm chart. Terapkan YAML ada di bagian Lanjutan.

Upload kode. Unggah folder proyek sebagai .zip, .tar.gz, atau .tar (maksimal 300 MB; buang node_modules, vendor, dan folder build). Arsip dialirkan langsung ke control plane klaster dan dibangun di sana, sama seperti aplikasi dari Git; Saka Panel tidak menyimpannya. Bila arsip berisi satu folder teratas, folder itu dibuka otomatis. Unggah kode baru di kartu aplikasi untuk merilis versi berikutnya; database, variabel, skala, dan kembali ke rilis lama tetap berlaku.

Docker image. Isi image container (mis. nginx:1.27 atau ghcr.io/nama/aplikasi:v1), port, jumlah salinan, batas RAM, domain, dan variabel. Saka menyusun Deployment (salinan disebar ke node berbeda), Service, dan Ingress dengan HTTPS. Arahkan A record domain ke IP publik node mana pun; sertifikat Let's Encrypt terbit sendiri, dalam uji kami 42 detik. Deploy lagi dengan nama yang sama untuk memperbarui image atau jumlah salinan.

Aplikasi dari Git

Di tab Aplikasi, Dari Git menerima alamat repo GitHub, GitLab, atau Gitea, cabang, dan (bila perlu) subfolder. Saka membangun image di dalam klaster dengan BuildKit, memakai Dockerfile Anda atau mengenali sendiri jenis aplikasinya (Node, Python, PHP, Go, dan lainnya), menyimpannya di registry privat di klaster, lalu menjalankannya dengan HTTPS. Tidak perlu akun registry atau menulis YAML.

• Repo privat: Saka membuat kunci deploy; tempel sekali di pengaturan repo (Deploy keys, baca saja).
• Deploy otomatis: pasang webhook yang ditampilkan; setiap push ke cabang itu membangun dan merilis ulang. Tanda tangan webhook diperiksa per aplikasi.
• Variabel disimpan sebagai Secret Kubernetes, bukan di dalam image; mengubahnya merestart aplikasi tanpa build ulang.
• Rilis & kembalikan: 10 rilis terakhir disimpan; Kembali ke rilis ini menjalankan image rilis lama tanpa build.
• Skala: pilih jumlah salinan, atau nyalakan Tambah salinan otomatis saat ramai dengan batas atas. Saka menambah salinan saat CPU rata-rata di atas 70% dan menguranginya lagi sekitar 5 menit setelah sepi (HorizontalPodAutoscaler).

Database sekali klik. Tombol Database di aplikasi Git memasang PostgreSQL, MySQL (MariaDB), atau Redis di klaster khusus untuk aplikasi itu, dengan volume sendiri (Longhorn bila terpasang, sehingga tahan satu node mati). Sandinya dibuat di dalam klaster dan tidak pernah tersimpan di Saka. Variabel DATABASE_URL, DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD (atau REDIS_URL, REDIS_HOST, REDIS_PASSWORD) langsung terisi; variabel yang Anda isi sendiri tetap menang. Satu database SQL ditambah satu Redis per aplikasi. Aplikasi tidak bisa dihapus selama masih punya database, dan menghapus database wajib mengetik namanya. Cadangkan isinya dengan cadangan volume.

Pratinjau per cabang. Nyalakan di bagian Pratinjau per cabang: setiap push ke cabang selain cabang utama dibangun sebagai salinan sendiri di https://<cabang>-<aplikasi>.<ip-node>.sslip.io, dan Anda dikabari alamatnya lewat Telegram. Pratinjau memakai variabel aplikasi tetapi tidak tersambung ke database aplikasi, supaya data asli aman (variabel SAKA_PRATINJAU berisi nama cabang). Pratinjau dihapus saat cabangnya dihapus, setelah 7 hari tanpa push, atau dari panel; maksimal 5 per aplikasi.

Build memakai CPU dan RAM node; untuk aplikasi besar, pastikan ada node dengan RAM minimal 2 GB kosong.

Untuk hal lain (Secret, ConfigMap, StatefulSet, CronJob, chart Helm lewat HelmChart k3s), pakai Terapkan YAML, sama dengan kubectl apply.

Pantau & kelola

Halaman klaster dibagi lima tab: Ringkasan (saran susunan, pod bermasalah, dan ikhtisar node Ready, aplikasi, domain serta snapshot terakhir), Aplikasi, Node, Data & cadangan, dan Akses. Tab yang aktif ikut tersimpan di alamat halaman, jadi bisa dibagikan. Proses yang sedang berjalan dan galat selalu tampil di atas tab.

• Node: peran, IP privat dan publik, Ready atau tidak.
• Aplikasi & workload: salinan siap/diinginkan, image, log, hapus. Komponen sistem (kube-system, cert-manager) disembunyikan dan dilindungi.
• Pod bermasalah beserta alasannya, mis. ImagePullBackOff atau CrashLoopBackOff, dengan tombol log.

Upgrade k3s

Saat ada versi k3s baru, halaman klaster menampilkan tombol Upgrade tersedia. Pilihannya hanya tambalan terbaru dari minor yang sama (perbaikan keamanan) atau minor berikutnya; Kubernetes tidak boleh melompati minor. Patokannya node tertua, jadi upgrade yang berhenti di tengah bisa dilanjutkan.

1. Snapshot etcd dibuat dulu. Bila gagal, tidak ada node yang diubah.
2. Satu node per satu, control plane dulu, baru worker: cordon dan drain (pod pindah ke node lain), binari k3s diganti dengan rilis resmi GitHub yang dicek SHA256-nya, k3s dimulai ulang, lalu ditunggu sampai Ready dengan versi baru dan node menerima pod lagi.
3. Bila satu node gagal (unduhan gagal, tidak Ready dalam 5 menit), node itu dikembalikan ke binari lamanya, di-uncordon, dan upgrade berhenti dengan penjelasan. Node yang sudah baru dilewati saat upgrade dijalankan lagi.

Klaster 1 node berhenti sebentar (biasanya kurang dari 1 menit) saat k3s dimulai ulang. Untuk minor baru, periksa catatan rilis Kubernetes bila aplikasi atau chart Anda memakai API beta lama.

Uji 9 Okt 2026 (control plane + worker, aplikasi 2 salinan tetap 2/2 sepanjang upgrade): v1.35.8 ke v1.36.5 dalam 78 detik, lalu ke v1.37.1. Unduhan yang sengaja diblokir di worker menghentikan upgrade dengan aman; setelah dibuka, upgrade dilanjutkan dan control plane yang sudah baru dilewati.

Volume tahan node mati (Longhorn)

Bawaan k3s, local-path, menyimpan isi volume di satu node. Bila node itu mati, pod yang memakainya tertahan sampai node hidup lagi atau data dipulihkan dari cadangan. Untuk database dan unggahan di klaster 2 node atau lebih, nyalakan Volume tahan node mati di bagian Penyimpanan volume:

• Saka memasang open-iscsi di setiap node (termasuk node yang ditambahkan nanti), lalu Longhorn 1.12. Setiap volume disalin di 3 node (2 node bila klaster hanya 2 node).
• Bila node mati, pod dipindah otomatis ke node lain dan volumenya ikut, tanpa menunggu node itu kembali. Saat node hidup lagi, salinan yang kurang dibangun ulang otomatis.
• Bisa dijadikan kelas bawaan untuk PVC baru (Saka juga mencegah k3s mengembalikan local-path sebagai bawaan). Volume yang sudah ada tidak dipindah otomatis.
• Setiap volume ditampilkan beserta kesehatannya. Volume yang kekurangan salinan lebih dari 30 menit, atau rusak, dikabarkan lewat Telegram.
• Memakai sekitar 300-500 MB RAM per node; disarankan node 4 GB.

Uji 9 Okt 2026 (3 node): server yang menjalankan pod database dimatikan paksa. Pod berjalan lagi di node lain dan aplikasi kembali menulis 104 detik setelah penulisan terakhir sebelum server mati, dengan data utuh. Saat server dinyalakan lagi, salinan ketiga dibangun ulang dan volume kembali sehat dalam ±2,5 menit.

Domain aplikasi tetap jalan saat node mati

Traefik berjalan di setiap node, jadi node mana pun bisa melayani semua aplikasi. Masalahnya bila domain diarahkan ke IP satu node: node itu mati, situs ikut mati walau aplikasinya sudah pindah. Karena itu setiap klaster punya alamat masuk app-<id>.k8s.saka.work dengan A record ke setiap node yang Ready, tersambung, dan benar-benar menjawab di port 80 (diperiksa tiap menit). Node yang mati dikeluarkan dari DNS dalam ±1 menit dan dimasukkan lagi saat pulih.

• Subdomain (toko.contoh.com): buat CNAME ke alamat masuk itu. Paling tahan, karena mengikuti node secara otomatis.
• Domain utama (contoh.com, tidak bisa CNAME): buat A record ke semua IP yang ditampilkan.

Bagian Alamat di halaman klaster memeriksa DNS setiap domain lewat resolver publik: CNAME ke klaster, A ke semua node, hanya sebagian node, ke IP di luar klaster (mis. proxy), atau belum mengarah. Traefik juga diatur agar permintaan ke pod di node yang mati segera dicoba ulang ke pod lain (3 detik, bukan 30).

Uji 9 Okt 2026 (3 node, aplikasi 2 salinan, domain CNAME ke alamat masuk): node yang menjalankan salah satu pod dimatikan paksa saat curl berjalan tiap 2 detik dari luar; 127 dari 128 permintaan berhasil. Satu permintaan gagal karena klien sendiri mencoba IP node yang mati sebelum DNS diperbarui; ini batas wajar failover lewat DNS.

Peringatan ke Telegram

Saka memeriksa setiap klaster tiap menit dan mengabari lewat Telegram (atau email bila Telegram belum ditautkan), lalu mengabari lagi saat pulih:

• Node NotReady lebih dari 90 detik (server mati, jaringan antarnode putus, k3s berhenti). Bila server itu juga terputus dari Saka, cukup peringatan server terputus.
• Node kehabisan sumber daya (MemoryPressure, DiskPressure, PIDPressure) lebih dari 2 menit.
• Pod tertahan karena CPU/RAM habis dipesan lebih dari 5 menit, dengan saran menambah worker.
• Pod aplikasi gagal (CrashLoopBackOff, OOMKilled, ImagePullBackOff) lebih dari 5 menit.
• Sertifikat HTTPS belum terbit lebih dari 15 menit (biasanya DNS belum mengarah ke klaster).
• Snapshot etcd tidak dibuat lebih dari sehari.

Peringatan ditahan selama klaster sedang menambah, mengeluarkan node, atau dipulihkan, karena NotReady sesaat itu wajar. Pemeriksaannya ringan (tiga panggilan kubectl di satu control plane). Semua peringatan juga tampil di halaman Peringatan panel.

Cadangan per klaster, bukan per VM

Di Kubernetes, yang dicadangkan adalah klaster, bukan masing-masing VM. Karena itu kartu cadangan situs per VM disembunyikan di halaman server yang menjadi node.

• Snapshot etcd berisi semua resource klaster (Deployment, Service, Ingress, Secret, dan lainnya). Dibuat otomatis tiap 12 jam, 5 terakhir disimpan di setiap control plane, plus tombol Cadangkan sekarang.
• Ke S3 milik Anda, terenkripsi. Di halaman klaster, atur tujuan S3 sekali (Amazon S3, Cloudflare R2, DigitalOcean Spaces, Wasabi, Backblaze B2, atau S3 lain). Saka memasangnya di semua control plane dengan kunci enkripsi yang sama, lalu setiap control plane mengirim snapshot-nya terenkripsi (age) ke saka/k8s/<klaster>/<node>/. Snapshot tetap ada walau semua node rusak. Kunci S3 dan kunci enkripsi hanya disimpan di node, tidak di Saka.
• Kode pemulihan sama seperti cadangan situs: simpan di tempat aman, karena tanpa kode itu snapshot tidak bisa dibuka.
• Data aplikasi di volume (database di dalam pod, unggahan) tidak termasuk snapshot etcd; untuk itu ada cadangan volume di bawah.

Cadangan volume aplikasi (Velero)

Opsional, satu tombol di bagian cadangan: Nyalakan cadangan volume. Saka memasang Velero (open source) beserta plugin S3 dan agen kecil di setiap node, diarahkan ke tujuan S3 klaster yang sama. Resource dan isi volume semua namespace aplikasi dicadangkan setiap hari jam 02.00, plus tombol Cadangkan volume sekarang; masa simpan mengikuti pengaturan S3. Tambahan RAM sekitar 150 MB, plus agen di setiap node.

• Terenkripsi dengan kode pemulihan Anda. Velero mengenkripsi isi volume dengan kata sandi repositori yang bawaannya sama di semua instalasi. Saka menurunkan kata sandi itu dari kunci di kode pemulihan, jadi kode yang sama cukup untuk membuka cadangan volume walau seluruh klaster hilang.
• Pulihkan dari daftar cadangan. Resource yang masih ada tidak ditimpa: untuk memulihkan aplikasi yang rusak sepenuhnya, hapus dulu namespace atau aplikasinya.

Uji 9 Okt 2026: aplikasi dengan data di volume dicadangkan (38 item), namespace-nya dihapus total, lalu dipulihkan; data kembali utuh. Kata sandi repositori yang dihitung dari kode pemulihan cocok dengan yang dipakai di klaster.

Uji 9 Okt 2026: snapshot di S3 terbukti terenkripsi, dan dengan kode pemulihan terbuka kembali menjadi database etcd yang utuh.

Pulihkan klaster dari snapshot

Tombol Pulihkan klaster di bagian Cadangan mengembalikan seluruh isi klaster (deployment, service, secret, ingress, dan resource lain di etcd) ke saat snapshot dibuat. Pilih snapshot lokal atau dari S3 per control plane, lalu ketik nama klaster. Urutannya:

1. Snapshot keadaan sekarang disimpan dulu sebagai sebelum-pulih, jadi pemulihan bisa dibatalkan dengan memulihkan snapshot itu.
2. Semua control plane dihentikan, etcd di-reset dari snapshot pilihan (snapshot S3 diunduh dan dibuka dengan kunci di node).
3. Control plane lain menyisihkan data etcd lamanya (tidak dihapus, di db.sebelum-pulih-*) lalu bergabung lagi.

API Kubernetes berhenti sebentar; aplikasi yang sedang berjalan umumnya tetap melayani. Semua control plane harus tersambung ke Saka. Isi volume tidak ikut; pulihkan lewat Velero bila perlu.

Uji 9 Okt 2026 (2 control plane): pemulihan dari snapshot S3 selesai dalam 47 detik dan dari snapshot lokal 42 detik; resource yang dihapus sesudah snapshot kembali, yang dibuat sesudahnya hilang, kedua node Ready.

Tambah & keluarkan node

Klaster bisa tumbuh kapan saja. Pasang agent Saka di server baru (VM dari penyedia mana pun atau mesin fisik, Ubuntu 22.04/24.04, RAM minimal 2 GB, tanpa situs Saka), lalu di halaman klaster tekan Tambah node dan pilih perannya:

• Worker (bawaan): menjalankan aplikasi. Tambahkan worker saat RAM atau CPU klaster mulai penuh.
• Control plane: ikut menyimpan data klaster (etcd). Jumlah ganjil paling aman: 3 tahan satu mati, 5 tahan dua mati.

Saka memakai versi k3s dan jaringan yang sama dengan klaster. Klaster yang semua node-nya di satu jaringan privat (vxlan) hanya menerima server di jaringan privat yang sama; server di penyedia atau lokasi lain ditolak dengan penjelasan, karena lalu lintas antarnode harus lewat jaringan privat itu. Klaster lintas jaringan (WireGuard) menerima server mana saja yang punya IP publik. Hostname server harus unik di klaster karena menjadi nama node.

Mesin fisik (bare metal): pasang Ubuntu Server, lalu jalankan perintah pasang agent dari menu Server seperti VM biasa. Setelah tersambung, mesin itu muncul di daftar Tambah node.

Keluarkan di baris node: pod dipindah dulu ke node lain (drain), node dihapus dari klaster, lalu k3s dicopot dari server. Volume local-path di node itu ikut hilang, jadi pastikan cadangan volume aktif. Server tetap terdaftar di Saka sebagai server biasa. Control plane terakhir tidak bisa dikeluarkan.

Tambah kapasitas sekali klik

Di tab Node (atau dari saran kartu Kapasitas di Ringkasan saat hampir penuh), tekan + Tambah kapasitas, pilih akun cloud, ukuran, dan jumlah (1-3). Saka membuat server baru di akun cloud Anda, otomatis di jaringan privat yang sama dengan klaster, menunggu server menyala, lalu menggabungkannya sebagai worker. Selesai dalam ±5-10 menit dan Anda dikabari; biaya server mengikuti penyedia cloud. Butuh akun cloud yang tersambung (Pengaturan, Akun cloud). Agent AI memakai alat MCP k8s_tambah_kapasitas.

Kartu Kapasitas di Ringkasan menunjukkan total, terpakai, dan sisa CPU, RAM, dan disk, jatah yang sudah dipesan aplikasi, serta ruang yang masih bisa dipakai volume.

Label & taint node

Saat menambah node, atau lewat tombol Label di baris node, Anda bisa memberi label (jenis=gpu, zona=jakarta) agar aplikasi memilih node lewat nodeSelector/affinity, dan taint (khusus=gpu:NoSchedule) agar hanya pod dengan toleration yang cocok yang dijadwalkan ke node itu. Taint pada node baru berlaku sejak node mendaftar, jadi tidak ada pod lain yang sempat masuk. Label dan taint milik Kubernetes/k3s (kubernetes.io, k3s.io) dilindungi.

Di dialog Deploy aplikasi, pilihan Jalankan di menampilkan label node yang ada. Memilihnya memasang nodeSelector, dan taint di node-node itu otomatis ditoleransi, jadi node khusus (mis. GPU) bisa dipakai tanpa menulis YAML.

Kapan menambah control plane, kapan worker

Patokannya: control plane untuk ketahanan, worker untuk kapasitas. Kartu Saran susunan klaster di halaman klaster membaca keadaan klaster dan memberi tahu langkah berikutnya, lengkap dengan tombol yang langsung memilih peran yang tepat:

• 1 control plane: klaster tidak bisa dikelola bila server itu mati. Tambah 2 control plane (jadi 3).
• Jumlah control plane genap (2, 4): etcd butuh mayoritas, jadi 2 sama tahannya dengan 1. Tambah 1 agar ganjil.
• Lebih dari 5 control plane: tidak menambah ketahanan; tambahkan worker.
• Pod menunggu karena CPU/RAM habis dipesan, CPU/RAM yang dipesan di atas 70%, atau RAM nyata rata-rata di atas 80%: tambah worker.
• Control plane yang juga menjalankan aplikasi dan RAM-nya hampir penuh: tambah worker agar etcd tidak ikut tersendat.
• Pod tidak mendapat node karena taint/label tidak cocok: periksa label & taint; menambah node biasa tidak membantu.

Ringkasan node di halaman server

Halaman server yang menjadi node menampilkan status node (Ready, tekanan memori/disk), pemakaian CPU/RAM, label & taint, dan daftar pod di node itu beserta keadaan, restart, dan pemakaiannya, setara kubectl describe node dan kubectl get pods --field-selector spec.nodeName=....

Reboot node tanpa menghentikan aplikasi

Tombol Reboot di halaman server (juga tombol Perbaiki saat ada reboot tertunda setelah pembaruan sistem) pada node Kubernetes tidak langsung mematikan server. Saka lebih dulu menandai node tidak menerima pod baru dan memindahkan pod-nya ke node lain (cordon & drain), me-reboot server, menunggu server benar-benar mati lalu hidup dan node kembali Ready, kemudian mengizinkannya menerima pod lagi. Bila pod tidak bisa dipindahkan, reboot dibatalkan dan node tetap berjalan. Reboot satu node pada klaster 6 node selesai sekitar 1,5 menit tanpa aplikasi berhenti.

Akses kubectl (kubeconfig)

Bagian Akses kubectl membuat kubeconfig untuk kubectl, Lens, CI, atau agent AI. Setiap akses adalah ServiceAccount sendiri dengan token yang kedaluwarsa sendiri (1 sampai 365 hari) dan bisa dicabut kapan saja; token yang dicabut langsung ditolak. Saka tidak menyimpan tokennya; kubeconfig hanya ditampilkan sekali.

Alamat API tetap. Kubeconfig menunjuk <id>.k8s.saka.work, bukan IP satu server. Nama itu punya A record ke setiap control plane yang sehat; kubectl mencoba alamat satu per satu, dan Saka mengeluarkan control plane yang mati dari DNS dalam ±1 menit lalu memasukkannya lagi saat pulih. Klaster baru langsung memakainya; untuk klaster lama tekan Aktifkan alamat API tetap (control plane dimulai ulang satu per satu; aplikasi tidak terganggu), lalu buat ulang kubeconfig.

Uji 9 Okt 2026 (3 control plane): satu control plane dimatikan paksa saat kubectl berjalan tiap 3 detik dari luar klaster; 100 dari 100 perintah berhasil (dua di antaranya ±10 detik saat berpindah alamat), DNS diperbarui dalam ±18 detik dan kembali lengkap saat server dinyalakan lagi.

• Lihat: membaca resource dan node, tanpa Secret. Cocok untuk agent AI yang menganalisis klaster.
• Pengembang: deploy dan ubah aplikasi (termasuk Secret), tanpa RBAC atau node. Bisa dibatasi ke satu namespace.
• Admin: kendali penuh seluruh klaster. Hanya untuk Anda sendiri.

Jangan berikan /etc/rancher/k3s/k3s.yaml ke orang lain atau agent AI: itu sertifikat admin yang tidak bisa dicabut. kubectl tersambung ke port 6443 control plane, jadi port itu harus terjangkau dari komputer Anda.

Helm chart

Bagian Helm chart memasang aplikasi dari repo Helm (https) atau registry OCI lewat helm-controller bawaan k3s, tanpa helm di komputer Anda. Isi repo, chart, versi (opsional), nama release, namespace, dan values seperti values.yaml. Nama release yang sama berarti upgrade. Bila gagal (chart tidak ada, values salah), log Helm ditampilkan. Mencopot release menjalankan helm uninstall; namespace dan PersistentVolumeClaim tidak ikut dihapus.

Bangun ulang saat semua node hilang

Bila semua server klaster hilang (dihapus, rusak, penyedia bermasalah), klaster bisa dibangun ulang di server baru hanya dengan kode pemulihan S3. Di halaman Kubernetes tekan Pulihkan dari cadangan, pilih server baru yang kosong, tempel kode pemulihan, lalu Cari cadangan. Server baru itu yang membaca bucket; Saka tidak pernah melihat isi cadangan. Ada dua cara:

• Aplikasi + isi volume (Velero, disarankan). Klaster baru dibuat, lalu semua namespace aplikasi beserta isi volume (database, unggahan) dipulihkan dari cadangan Velero klaster lama. Cadangan lama dibaca lewat lokasi kedua yang hanya-baca, jadi tidak tertimpa; cadangan baru disimpan di tempat klaster baru. Kubeconfig lama tidak berlaku.
• Seluruh isi klaster (snapshot etcd). Semua resource kembali persis, termasuk CA, sehingga kubeconfig dan akses kubectl lama tetap berlaku dan cadangan S3 berlanjut di tempat yang sama. Node lama dihapus otomatis. Isi volume lokal di node lama tidak ikut; pod yang memakainya menunggu sampai volumenya dipulihkan atau dibuat ulang. Cara ini butuh token klaster asal, yang dicadangkan ke S3 (terenkripsi) sejak 9 Okt 2026.

Uji 9 Okt 2026: server klaster asal dihapus, lalu dibangun ulang dua kali. Lewat Velero selesai dalam 3,5 menit dan isi volume aplikasi kembali sama persis; lewat etcd selesai dalam 34 detik dengan CA dan rentang IP yang sama.

Jaringan 10.42.x / 10.43.x

k3s memakai 10.42.0.0/16 untuk pod dan 10.43.0.0/16 untuk Service. Bila IP privat server berada di rentang itu (mis. jaringan bawaan IDCloudHost 10.43.x), Saka otomatis memakai 10.52.0.0/16 dan 10.53.0.0/16 agar IP Service tidak bertabrakan dengan IP server. Pilihan ini ikut ke setiap control plane baru dan ke pemulihan.

Node bukan VM kosong

Server yang menjadi node Kubernetes ditandai di daftar server. Buat situs, pasang aplikasi, firewall, swap, dan pemindahan port web gaya VM disembunyikan dan ditolak, karena bisa berebut port 80/443 dengan ingress atau menutup port antarnode. Pemantauan, Keamanan server, Perisai, dan pembaruan sistem tetap berjalan.

Lewat agent AI

Alat MCP: k8s_daftar, k8s_status, k8s_buat, k8s_adopsi, k8s_aplikasi, k8s_terapkan, k8s_hapus, k8s_log, k8s_cadangan, k8s_node, k8s_pulihkan, k8s_cari_cadangan, k8s_upgrade, k8s_penyimpanan, k8s_domain, k8s_akses, k8s_helm, k8s_volume, dan k8s_temuan. Aksi yang mengubah klaster wajib persetujuan Anda.

Lepas dari Saka

Lepas klaster dari Saka hanya menghentikan pengelolaan oleh Saka; k3s dan semua aplikasi tetap berjalan, dan klaster bisa diadopsi lagi kapan saja.