Penyedia Kubernetes
Penyedia Kubernetes memungkinkan Anda membuat klaster Kubernetes yang siap pakai dari Cockpit hanya dalam beberapa langkah terpandu. Cockpit membangun mesin virtual, memasang distribusi Kubernetes yang ringan dan sepenuhnya kompatibel (k3s), menyiapkan jaringan dan penyimpanan, lalu menyerahkan klaster yang bisa langsung Anda hubungkan menggunakan alat standar kubectl.
Anda tidak perlu menyiapkan server, menjalankan installer, atau menyalin perintah join secara manual. Anda cukup menentukan seberapa besar klaster yang diinginkan, bentuk nodenya, dan di mana ia berjalan, selebihnya Cockpit yang mengerjakan di latar belakang sementara Anda tetap bisa bekerja.
Untuk siapa panduan ini
Panduan ini ditujukan bagi mereka yang ingin menjalankan klaster Kubernetes — tim aplikasi, operator platform, dan administrator. Fokusnya pada apa yang Anda lakukan di antarmuka Cockpit dan cara memakai klaster setelahnya.
Lisensi
Penyedia Kubernetes memerlukan hak (entitlement) Kubernetes pada lisensi Cockpit Anda. Jika belum ada, tambahkan ke langganan Anda dan impor lisensi yang diperbarui sebelum Anda mulai. Semua kemampuan dalam panduan ini — membuat klaster, beberapa pool node worker, konfigurasi CPU dan node kustom, menambah dan menghapus pool, menskalakan, serta memutakhirkan — dicakup oleh satu entitlement tersebut.
Sebelum memulai
Dua hal harus tersedia sebelum klaster pertama Anda. Jika administrator sudah menyiapkan lingkungannya, Anda bisa langsung ke Membuat klaster.
- Templat klaster. Cockpit mengkloning setiap node dari citra templat Ubuntu yang sudah disiapkan. Templat memuat komponen Kubernetes untuk versi yang dibangun bersamanya, sehingga node terpasang dengan cepat dan tanpa perlu mengunduh apa pun saat boot. Pilihan ini muncul otomatis di wizard.
- Jaringan yang sesuai. Setiap node harus berada di jaringan terdistribusi — jaringan yang menjangkau host fisik di klaster komputasi Anda — sehingga node yang ditempatkan di host berbeda dapat saling menjangkau. Lihat Memilih jaringan.
Membuat klaster
- Pada pohon inventaris di sebelah kiri, klik kanan Cluster komputasi Anda (atau Datacenter tempatnya berada).
- Pilih Kubernetes → New Cluster.
- Wizard Penyediaan Kubernetes akan terbuka dengan lima langkah singkat.
Karena Anda memulainya dari lokasi tertentu di inventaris, wizard sudah mengetahui pusat data dan klaster komputasi yang Anda maksud. Semua penempatan node terbatas pada host di klaster komputasi tersebut — node tidak akan pernah ditempatkan di host pada pusat data lain.
Setelah wizard selesai, Cockpit mulai membangun klaster di latar belakang. Anda dapat menutup wizard dan memantau kemajuannya di panel Tasks. Klaster muncul di inventaris dan berpindah dari provisioning ke active saat siap digunakan.
Langkah 1 — Dasar
| Kolom | Fungsinya |
|---|---|
| Nama Klaster | Nama yang mudah dikenali untuk klaster. Digunakan di inventaris, dalam nama node, dan pada berkas konfigurasi yang diunduh. |
| Jaringan Target | Jaringan terdistribusi tempat node terhubung. Hanya jaringan terdistribusi yang ditawarkan. Lihat Memilih jaringan. |
| Pengalamatan IP Node | DHCP (bawaan) membiarkan jaringan membagikan alamat. Statis memungkinkan Anda memesan rentang tetap untuk klaster — lihat Alamat node statis. |
| Versi Kubernetes | Versi k3s yang akan dipasang. Versi yang sudah terpasang di templat akan terpasang paling cepat; pilih yang terbaru kecuali ada alasan lain. |
| Plugin Jaringan (CNI) | Cara pod saling berkomunikasi. Lihat Plugin jaringan. Biarkan pada Flannel jika ragu. |
Langkah 2 — Control Plane
Control plane adalah "otak" klaster. Pilih seberapa tangguh ia harus dibuat:
- Tunggal (1 node) — Paling sederhana dan ringan. Cocok untuk pengembangan dan pengujian. Jika node satu-satunya ini hilang, klaster tidak tersedia hingga pulih.
- Ketersediaan Tinggi / High Availability (3 node) — Direkomendasikan untuk produksi. Klaster tetap berjalan meski salah satu node control plane gagal.
Anda juga mengatur CPU, Memori, Datastore, dan Ukuran Disk untuk setiap node control plane, serta pilihan Penempatan (Placement):
- Auto-Distribute (direkomendasikan) — Cockpit menyebar ketiga node HA ke tiga host fisik berbeda secara otomatis, sehingga kegagalan satu host tidak menjatuhkan seluruh control plane.
- Manual — Anda memilih sendiri host mana yang menjalankan tiap node, dari host yang ada di klaster komputasi Anda.
Dua bagian lanjutan diciutkan secara bawaan dan dapat dibiarkan apa adanya untuk sebagian besar klaster:
- Mode & Topologi CPU — bagaimana virtual CPU disajikan ke node. Lihat Mode dan topologi CPU.
- Label & Taint Node — metadata Kubernetes yang diterapkan ke node control plane. Lihat Label dan taint node. Penggunaan umum adalah menambahkan taint
NoScheduledi sini agar pod aplikasi biasa tidak dijadwalkan ke control plane.
Langkah 3 — Node Pekerja (Workers)
Worker menjalankan aplikasi Anda yang sebenarnya. Sebuah klaster dapat memiliki satu atau beberapa pool node worker. Setiap pool adalah kelompok node identik dengan nama, ukuran, bentuk perangkat keras, penempatan, dan metadata Kubernetes miliknya sendiri. Lihat Pool node worker untuk alasan menggunakan lebih dari satu pool.
Untuk setiap pool Anda mengatur:
| Kolom | Fungsinya |
|---|---|
| Nama Pool | Nama pendek untuk pool. Nama node dibangun dari nama ini: klaster prod, pool gpu → node prod-gpu-1, prod-gpu-2, dan seterusnya. Lihat Aturan penamaan. |
| Jumlah Node | Jumlah node awal. Anda dapat mengubahnya kapan saja nanti. |
| CPU, Memori, Datastore, Ukuran Disk | Sumber daya untuk setiap node di pool ini. |
| Penempatan | Auto-Distribute menyeimbangkan node antar-host di klaster komputasi Anda, atau gunakan Manual untuk menyematkannya ke host tertentu (berguna bila host tertentu memiliki perangkat keras khusus seperti GPU). |
| Mode & Topologi CPU (lanjutan) | Lihat Mode dan topologi CPU. |
| Label & Taint Node (lanjutan) | Lihat Label dan taint node. |
Klik Add Node Pool untuk menentukan pool lain dengan pengaturan berbeda. Pool pertama diberi nama workers kecuali Anda mengubah namanya.
Langkah 4 — Kredensial & CSI
- Kunci Publik SSH — Opsional. Tempelkan kunci publik di sini bila Anda ingin akses SSH langsung ke VM node untuk pemecahan masalah. Ini tidak wajib untuk memakai klaster; Cockpit juga membuat pasangan kuncinya sendiri untuk klaster, yang dapat Anda unduh dari halaman klaster.
- Tingkat Penyimpanan (CSI) — Pilih cara aplikasi memperoleh penyimpanan permanen. Anda boleh mengaktifkan lebih dari satu. Lihat Penyimpanan untuk aplikasi Anda.
Langkah 5 — Tinjau
Tinjau ringkasannya — ukuran klaster, masing-masing pool dan pengaturannya, sumber daya yang akan digunakan, dan host mana yang akan menjalankan tiap node. Klik Provision untuk memulai. Wizard menutup dan tugas dimulai.
Memilih jaringan
Jaringan yang Anda pilih pada Langkah 1 paling menentukan keberhasilan pembentukan klaster, jadi perlu dipertimbangkan dengan baik.
Setiap node harus dapat menjangkau setiap node lainnya, dan menjangkau internet selama proses penyiapan untuk kebutuhan apa pun yang belum ada di templat. Karena Cockpit menyebar node ke seluruh host fisik di klaster komputasi Anda, jaringan harus menjangkau host-host tersebut — itulah sebabnya wizard hanya menawarkan jaringan terdistribusi. Jaringan yang hanya ada di satu host tidak dapat menghubungkan node di dua host berbeda, dan tidak akan dicantumkan.
WARNING
Gateway jaringan harus benar-benar memberikan akses internet nyata bagi node, bukan hanya meneruskan lalu lintasnya. Gateway yang merutekan namun tidak menerjemahkan alamat (NAT) akan membiarkan node boot dan merespons ping sementara setiap unduhan gagal tanpa pesan kesalahan yang jelas, dan klaster tidak akan pernah selesai disediakan. Jika Anda tidak yakin jaringan mana yang diperuntukkan bagi Kubernetes, tanyakan kepada administrator Anda.
Alamat node statis
Secara bawaan node memperoleh alamatnya dari DHCP. Jika jaringan Anda tidak memiliki server DHCP, atau Anda ingin alamat klaster dapat diprediksi, pilih Static pada Langkah 1 dan isi:
| Kolom | Contoh |
|---|---|
| Subnet | 192.168.1.0/24 |
| Gateway | 192.168.1.1 |
| Nameserver | 8.8.8.8, 1.1.1.1 |
| Rentang IP | 192.168.1.100 – 192.168.1.120 |
Cockpit menetapkan alamat bebas berikutnya dalam rentang tersebut ke setiap node dan mempertahankannya selama masa hidup node. Rentang tersebut harus memiliki ruang untuk setiap node yang Anda rencanakan — control plane, setiap pool worker, dan node apa pun yang Anda tambahkan nanti. Jika scale-up atau pool baru di kemudian hari akan menghabiskan rentang alamat, Cockpit akan menolaknya sejak awal dengan pesan yang jelas daripada meninggalkan node yang setengah jadi.
Plugin jaringan (CNI)
Plugin jaringan mengatur cara pod berkomunikasi dan apakah Anda dapat menerapkan kebijakan keamanan jaringan. Anda memilihnya sekali, di Langkah 1.
| Plugin | Paling cocok untuk | Catatan |
|---|---|---|
| Flannel (bawaan) | Sebagian besar klaster, pengembangan, penyiapan sederhana | Ringan dan andal. Tanpa kebijakan jaringan. |
| Calico | Produksi dengan isolasi antar-tenant | Menambahkan dukungan NetworkPolicy Kubernetes untuk mengontrol lalu lintas antar-pod. |
| Cilium | Jaringan berperforma tinggi dan canggih | Berbasis eBPF, dengan kebijakan L3–L7 yang kaya serta visibilitas lalu lintas. |
Jika Anda tidak memiliki kebutuhan khusus, Flannel adalah pilihan aman.
Pool node worker
Sebuah node pool adalah kelompok node worker yang berbagi konfigurasi yang sama. Sebagian besar klaster kecil hanya membutuhkan satu pool. Anda memerlukan lebih dari satu pool ketika beban kerja yang berbeda membutuhkan mesin yang berbeda:
- Pool
databasedengan memori lebih besar dan datastore lebih cepat, berdampingan dengan pool umumworkers. - Pool
gpuyang disematkan ke host yang memiliki GPU, dengan taint sehingga hanya beban kerja GPU yang ditempatkan di sana. - Pool
ingressdengan label yang dipilih oleh ingress controller Anda, dibuat kecil dan stabil sementara bagian klaster lainnya diskalakan.
Setiap pool memiliki nama, jumlah node, CPU / memori / disk / datastore, penempatan, mode dan topologi CPU, serta label dan taint miliknya sendiri. Pool dikelola dari tab Node Pool pada klaster setelah pembuatan — lihat Mengelola pool node.
Aturan penamaan
Nama pool menjadi bagian dari nama setiap node, sehingga mengikuti aturan yang sama dengan nama host Kubernetes:
- Huruf kecil, angka, dan
-; harus diawali dan diakhiri dengan huruf atau angka; maksimal 40 karakter. - Harus unik di dalam klaster.
- Nama
worker,master, dancontrol-planeadalah dicadangkan (reserved), karena penamaan node darinya akan bertabrakan dengan pool worker bawaan atau control plane. Gunakanworkersuntuk pool default, atau nama berbeda sepertiinfraataucompute.
Mode dan topologi CPU
Secara bawaan setiap node mendapatkan CPU virtual serbaguna. Bagian Mode & Topologi CPU pada setiap pool memungkinkan Anda mengubah bagaimana CPU disajikan, yang penting untuk beban kerja yang memeriksa prosesor atau yang berlisensi per soket.
Mode CPU
| Mode | Yang dilihat node | Kapan digunakan |
|---|---|---|
| Host Model | CPU yang cocok dengan model host fisik | Keseimbangan yang baik antara performa dan portabilitas. |
| Host Passthrough | CPU host fisik secara persis, dengan setiap fiturnya | Performa maksimal; beban kerja yang membutuhkan instruksi CPU spesifik. Node harus tetap berada di host dengan CPU yang identik. |
| Custom Named Model | Model CPU tertentu yang Anda sebutkan (misalnya Broadwell-IBRS) | Saat Anda memerlukan fitur CPU yang identik di berbagai host dengan prosesor fisik berbeda. |
Topologi memungkinkan Anda mengatur vCPU menjadi soket × die × core × thread. Hasil perkaliannya harus sama dengan jumlah vCPU pool — wizard menampilkan perhitungannya saat Anda mengetik dan tidak akan membiarkan Anda melanjutkan jika tidak cocok. Misalnya, 4 vCPU dapat berupa 1 × 1 × 4 × 1 (satu soket, empat core) atau 2 × 1 × 2 × 1 (dua soket, masing-masing dua core), yang memengaruhi penghitungan lisensi perangkat lunak per soket.
Biarkan bagian ini diciutkan untuk menerima nilai bawaan. Mode dan topologi yang dikonfigurasi ditampilkan untuk setiap pool pada tab Node Pool setelah pembuatan.
Label dan taint node
Label adalah tag kunci-nilai yang memungkinkan Anda mengarahkan beban kerja ke node tertentu menggunakan nodeSelector atau afinitas node. Taint melakukan hal sebaliknya: menahan beban kerja agar tidak masuk ke node kecuali beban kerja tersebut secara eksplisit mentoleransi taint tersebut. Bersama-sama, keduanya adalah cara Kubernetes mengubah "kumpulan mesin GPU" menjadi sesuatu yang benar-benar dipahami oleh penjadwal (scheduler).
Atur keduanya per pool pada bagian Label & Taint Node:
| Pengaturan | Format | Contoh |
|---|---|---|
| Label | kunci = nilai | tier = database |
| Taint | kunci=nilai:Effect, dengan Effect berupa NoSchedule, PreferNoSchedule, atau NoExecute | dedicated=gpu:NoSchedule |
Wizard memvalidasi format saat Anda mengetik — efek yang salah ketik atau kunci yang tidak valid akan ditolak sebelum apa pun dibangun, alih-alih menghasilkan node yang diam-diam tidak memiliki taint-nya.
Diterapkan saat pembuatan
Label dan taint diberikan ke setiap node saat pertama kali bergabung ke klaster, dan setiap node yang ditambahkan kemudian melalui penskalaan atau pool baru mendapatkan label dan taint pool-nya dengan cara yang sama. Pengaturan ini tidak dapat diubah pada pool yang sudah ada dari Cockpit — untuk mengubahnya pada node yang sudah ada, gunakan kubectl label dan kubectl taint, atau buat pool baru dengan pengaturan yang Anda inginkan dan hapus pool yang lama.
Beban kerja kemudian menargetkan pool seperti ini:
spec:
nodeSelector:
tier: database
tolerations:
- key: dedicated
operator: Equal
value: gpu
effect: NoScheduleMenjaga aplikasi di luar control plane
k3s tidak memberi taint pada node control plane-nya, sehingga secara bawaan pod biasa dapat dijadwalkan ke sana. Untuk klaster produksi, tambahkan taint seperti dedicated=control-plane:NoSchedule ke control plane pada Langkah 2. Komponen sistem klaster sudah berjalan di tempat yang dibutuhkannya; aplikasi Anda akan tetap berada di worker.
Kunci di bawah awalan kubernetes.io/ dan k8s.io/ (termasuk node-role.kubernetes.io/) dicadangkan untuk Kubernetes sendiri dan tidak dapat diatur di sini — pilih kunci Anda sendiri.
Penyimpanan untuk aplikasi Anda
Aplikasi yang perlu menyimpan data (basis data, unggahan berkas, dan sebagainya) meminta penyimpanan melalui tingkat penyimpanan (storage tier). Aktifkan tingkat yang Anda butuhkan di Langkah 4; Anda boleh menyalakan lebih dari satu dan memilih per aplikasi mana yang dipakai.
| Tingkat | Yang Anda dapatkan | Kapan digunakan |
|---|---|---|
| Local Path (aktif secara bawaan) | Penyimpanan cepat pada node tempat pod berjalan | Penyimpanan sederhana dan berkecepatan tinggi. Data tetap di satu node, jadi tidak tersedia bila pod berpindah ke node lain. |
| Bersama (NFS) | Penyimpanan yang bisa dipakai banyak pod sekaligus, tersedia lintas node | Saat pod perlu berbagi berkas (ReadWriteMany), atau tetap menyimpan datanya ketika berpindah antar-node. |
| Replikasi (Longhorn) | Penyimpanan blok dengan ketersediaan tinggi, disalin antar-node | Beban kerja stateful seperti basis data yang harus bertahan dari kegagalan node. |
Bersama (NFS). Pilih datastore NFS yang sudah terdaftar di Cockpit dan alamat server beserta jalur ekspornya akan diisi untuk Anda, atau masukkan server NFS eksternal secara manual. Cockpit memeriksa bahwa server dapat dijangkau dari jaringan klaster itu sendiri — ini hal yang penting, karena dari sanalah setiap mount dilakukan — sebelum memasang driver, dan memastikan driver berjalan di setiap node sebelum klaster dinyatakan aktif.
Replikasi (Longhorn). Tetapkan jumlah replika — berapa banyak salinan dari setiap volume yang disimpan Longhorn, masing-masing pada worker yang berbeda. Nilai bawaan 3 dapat bertahan dari hilangnya dua worker. Jumlah replika tidak boleh melebihi jumlah node worker; wizard menolak jumlah yang tidak akan pernah bisa dipenuhi klaster, karena Longhorn akan membiarkan setiap volume terus berstatus degraded. Longhorn dikonfigurasi untuk menyimpan replika hanya pada node worker, tidak pernah pada control plane.
Menambahkan penyimpanan nanti
Tingkat penyimpanan dipilih saat pembuatan klaster. Jika Anda mengurangi node worker di bawah jumlah replika Longhorn Anda nanti, volume akan menjadi degraded hingga jumlah worker mencukupi kembali — skalakan kembali untuk memulihkan redundansi penuh.
Menghubungi klaster Anda
Setelah status klaster menjadi active, Anda dapat terhubung dengan kubectl, alat baris perintah standar Kubernetes.
Buka halaman detail klaster dan klik Download Kubeconfig. Cockpit memberikan berkas siap pakai dengan alamat server yang sudah terisi dengan benar.
Simpan lalu arahkan
kubectlkepadanya:bashmkdir -p ~/.kube mv ~/Downloads/kubeconfig-klaster-saya.yaml ~/.kube/config-klaster-saya chmod 600 ~/.kube/config-klaster-saya export KUBECONFIG=~/.kube/config-klaster-sayaPastikan berfungsi:
bashkubectl get nodes --show-labelsAnda akan melihat node control plane dan worker tercantum sebagai Ready, masing-masing membawa label dari pool-nya.
TIP
Agar tidak perlu mengatur KUBECONFIG setiap kali, tambahkan baris export ke profil shell Anda (~/.bashrc atau ~/.zshrc).
Mengelola pool node
Buka klaster dan pilih tab Node Pool. Setiap pool adalah sebuah baris dalam tabel yang menampilkan nama, peran, jumlah node beserta berapa banyak yang Ready, vCPU / memori / disk / datastore dari nodenya, serta konfigurasi CPU, label, dan taint. Pool control plane dicantumkan sebagai referensi dan ditandai Locked — pool ini tidak dapat diskalakan atau dihapus di sini.
Setiap pool worker memiliki tindakan Scale dan Remove pada barisnya, dan tab tersebut memiliki tombol Add Pool. Ketiganya hanya tersedia saat status klaster active; selama ada perubahan apa pun tindakan dinonaktifkan sehingga dua operasi tidak akan bertabrakan. Setiap perubahan muncul di tab Tasks klaster dan di panel Tasks.
Skalakan pool
- Klik Scale pada baris pool.
- Atur jumlah node yang diinginkan yang baru lalu konfirmasi.
Menambah (scale up) menambahkan VM node baru dengan konfigurasi yang sama persis dengan pool — sumber daya, mode CPU, label, dan taint — dan otomatis menggabungkannya ke klaster. Saat node baru berstatus Ready, mereka mulai menerima beban kerja.
Mengurangi (scale down) dilakukan secara anggun (gracefully). Sebelum sebuah node dihapus, Cockpit terlebih dahulu memindahkan replika Longhorn darinya agar volume tetap memiliki redundansinya, kemudian melakukan drain — memindahkan beban kerja yang berjalan ke node yang tersisa — dan baru kemudian menghapus VM serta membebaskan sumber dayanya.
Bila sebuah node gagal ditambahkan
Jika node baru tidak dapat dibuat (misalnya host yang dipilih sedang kehabisan kapasitas), Cockpit membersihkan node yang belum selesai secara otomatis dan menyesuaikan pool ke jumlah yang benar-benar tercapai. Cukup jalankan scale-up lagi untuk mencoba kembali — Anda tidak akan ditinggali node setengah jadi.
Menambah pool ke klaster yang sedang berjalan
Anda tidak perlu membangun ulang klaster untuk memberinya kelas node baru.
- Klik Add Pool pada tab Node Pool.
- Isi pengaturan yang sama seperti pada Langkah 3 wizard — nama, jumlah, sumber daya, datastore, penempatan, dan secara opsional mode CPU serta label/taint.
- Konfirmasi. Node baru disediakan dan digabungkan, dan pool akan muncul sebagai baris baru.
Aturan yang sama berlaku seperti saat pembuatan: nama harus mengikuti aturan penamaan, nama tidak boleh sudah digunakan, dan pada klaster beralamat statis harus ada cukup alamat bebas untuk node baru. Cockpit memeriksa semua hal ini sebelum membuat apa pun.
Menghapus pool
- Klik Remove pada baris pool dan konfirmasi — penghapusan akan menghancurkan node pool tersebut dan tidak dapat dibatalkan.
- Setiap node ditangani seperti cara scale-down: replika Longhorn dipindahkan terlebih dahulu, beban kerja di-drain, dan baru kemudian VM dihancurkan. Saat node terakhir selesai dihapus, pool akan hilang dari tabel.
Pool worker terakhir tetap dipertahankan
Sebuah klaster selalu mempertahankan setidaknya satu pool worker. Tindakan Remove tidak tersedia pada satu-satunya pool yang tersisa, dan API akan menolak permintaan tersebut. Jika Anda ingin klaster tidak memiliki worker, turunkan skala pool tersebut; jika Anda ingin klaster dihapus, hapus klasternya.
Memutakhirkan klaster
Cockpit melakukan pemutakhiran bergulir (rolling upgrade), memindahkan klaster ke versi Kubernetes yang lebih baru satu node pada satu waktu agar aplikasi Anda tetap tersedia.
- Buka klaster dan pilih Upgrade.
- Pilih versi tujuan dari daftar.
- Konfirmasi. Cockpit memutakhirkan control plane lebih dulu, lalu worker, satu node pada satu waktu.
Selama pemutakhiran, tiap node di-drain, diperbarui, dan dikembalikan bertugas sebelum node berikutnya dimulai. Klaster menampilkan versi tujuan berdampingan dengan versi saat ini hingga pemutakhiran selesai.
Kemajuan muncul di tab Tasks klaster. Di bawah tugas, daftar Node Upgrade Jobs menampilkan satu entri per node saat pengontrol pemutakhiran dalam klaster memprosesnya; klik View log pada node mana pun untuk membaca apa yang terjadi secara tepat padanya. Log tersebut adalah tempat untuk memeriksa jika sebuah node terhenti — tugas mungkin menyatakan node selesai, tetapi hanya log yang dapat memberi tahu apa yang dilakukannya.
Memantau kesehatan klaster
Setelah klaster berstatus active, Cockpit terus mengawasinya dan menampilkan status kesehatan pada halaman klaster:
- Healthy — Semua node ada dan Ready.
- Degraded — Satu atau lebih node tidak Ready (misalnya node dihentikan atau kehilangan jaringan). Klaster masih berjalan tetapi kapasitas atau ketangguhannya berkurang.
Status kesehatan diperbarui otomatis saat node pulih atau gagal, sehingga Anda bisa langsung tahu apakah perlu perhatian.
Pemecahan masalah
Klaster macet di "provisioning" dan tak pernah menjadi active. Penyebab paling umum adalah jaringan. Pastikan jaringan yang Anda pilih menjangkau host di klaster komputasi Anda dan bahwa gateway-nya memberi node akses internet nyata — bukan sekadar penerusan. Node yang boot dan merespons ping tetapi tidak pernah selesai menginstal hampir selalu tidak memiliki rute keluar yang berfungsi. Lihat Memilih jaringan.
Wizard menolak nama pool saya. Nama harus berupa huruf kecil, angka, dan -, serta nama worker, master, dan control-plane dicadangkan. Lihat Aturan penamaan.
Menambah pool atau scale up ditolak dengan pesan "static IP pool is exhausted". Rentang alamat statis klaster tidak memiliki alamat bebas tersisa untuk node baru. Pesan tersebut menyatakan berapa banyak yang bebas dan berapa banyak yang dibutuhkan. Turunkan skala node lain terlebih dahulu, atau buat klaster baru dengan rentang yang lebih besar — rentang alamat tidak dapat diperlebar pada klaster yang sudah ada.
Wizard tidak mengizinkan saya melanjutkan melewati topologi CPU. Soket × die × core × thread harus sama dengan jumlah vCPU pool. Sesuaikan topologi atau jumlah vCPU hingga perhitungan matematika yang ditampilkan di wizard cocok.
Label atau taint ditolak. Taint harus berformat kunci=nilai:Effect dengan effect tepat NoSchedule, PreferNoSchedule, atau NoExecute. Kunci dan nilai label mengikuti aturan Kubernetes (maksimal 63 karakter, huruf, angka, -, _, dan .), dan kunci di bawah kubernetes.io/ atau k8s.io/ dicadangkan. Wizard memberi tahu Anda entri mana yang salah.
Tombol Remove berwarna abu-abu pada pool worker. Itu adalah satu-satunya pool worker klaster, dan klaster selalu mempertahankan setidaknya satu. Tambahkan pool lain terlebih dahulu jika Anda ingin menggantinya, turunkan skalanya jika Anda menginginkan node yang lebih sedikit, atau hapus klasternya.
Volume Longhorn berstatus "degraded". Jumlah node worker lebih sedikit daripada jumlah replika, sehingga Longhorn tidak dapat menempatkan setiap salinan pada node terpisah. Skalakan pool worker hingga jumlah worker setidaknya sama dengan jumlah replika, dan volume akan pulih dengan sendirinya.
Tingkat NFS melaporkan server tidak dapat dijangkau. Pemeriksaan dilakukan dari jaringan klaster, bukan dari Cockpit, karena di sanalah mount dilakukan. Pastikan server NFS benar-benar mendengarkan pada alamat yang dapat dijangkau oleh node dan ekspornya mengizinkan subnet node — server yang dapat dijangkau dari komputer kerja Anda namun hanya terikat ke antarmuka manajemen akan gagal dalam pemeriksaan ini.
Sebuah node berstatus "NotReady" atau klaster "Degraded". Periksa apakah VM node tersebut sedang berjalan (mungkin dihentikan, atau host-nya mati). Setelah VM kembali menyala dan tersambung ke jaringan, node bergabung kembali dan status kesehatan pulih ke Healthy dengan sendirinya.
kubectl tidak bisa terhubung setelah kubeconfig diunduh. Pastikan KUBECONFIG mengarah ke berkas yang diunduh dan mesin Anda dapat menjangkau alamat node control plane di jaringan. Unduh ulang kubeconfig jika alamat klaster berubah.
Aplikasi kehilangan datanya setelah pod berpindah ke node lain. Ini terjadi pada tingkat penyimpanan Local Path, yang menyimpan data di satu node saja. Untuk data yang harus mengikuti aplikasi, gunakan tingkat Bersama (NFS) atau Replikasi (Longhorn). Lihat Penyimpanan untuk aplikasi Anda.
Topik terkait
- Distributed Resource Scheduler (DRS) & Ketersediaan Tinggi — cara Cockpit menempatkan dan menyeimbangkan VM node antar-host.
- Jaringan Virtual — jaringan terdistribusi tempat node klaster Anda terhubung.
- Penyimpanan & Datastore — datastore bersama yang memungkinkan klaster berjalan lintas host.