Manajemen Klaster

Dokumen ini menjelaskan beberapa topik yang terkait dengan siklus hidup sebuah klaster: membuat klaster baru, memperbarui Node control plane dan Node pekerja dari klaster kamu, melakukan pemeliharaan Node (misalnya pembaruan kernel), dan meningkatkan versi API Kubernetes dari klaster yang berjalan.

Membuat dan mengonfigurasi klaster

Untuk menginstal Kubernetes dalam sekumpulan mesin, konsultasikan dengan salah satu Panduan Memulai tergantung dengan lingkungan kamu.

Memperbarui klaster

Status saat ini pembaruan klaster bergantung pada penyedia, dan beberapa rilis yang mungkin memerlukan perhatian khusus saat memperbaruinya. Direkomendasikan agar admin membaca Catatan Rilis, serta catatan khusus pembaruan versi sebelum memperbarui klaster mereka.

Memperbarui klaster Azure Kubernetes Service (AKS)

Azure Kubernetes Service memungkinkan pembaruan layanan mandiri yang mudah dari control plane dan Node pada klaster kamu. Prosesnya adalah saat ini dimulai oleh pengguna dan dijelaskan dalam Azure AKS documentation.

Memperbarui klaster Google Compute Engine

Google Compute Engine Open Source (GCE-OSS) mendukung pembaruan control plane dengan menghapus dan membuat ulang control plane, sambil mempertahankan Persistent Disk (PD) yang sama untuk memastikan bahwa data disimpan pada berkas untuk setiap kali pembaruan.

Pembaruan Node untuk GCE menggunakan grup instance yang di-manage, dimana setiap Node dihancurkan secara berurutan dan kemudian dibuat ulang dengan perangkat lunak baru. Semua Pod yang berjalan di Node tersebut harus dikontrol oleh pengontrol replikasi (Replication Controller), atau dibuat ulang secara manual setelah peluncuran.

Pembaruan versi pada klaster open source Google Compute Engine (GCE) yang dikontrol oleh skrip cluster/gce/upgrade.sh.

Dapatkan penggunaan dengan menjalankan cluster/gce/upgrade.sh -h.

Misalnya, untuk meningkatkan hanya control plane kamu ke versi tertentu (v1.0.2):

cluster/gce/upgrade.sh -M v1.0.2

Sebagai alternatif, untuk meningkatkan seluruh klaster kamu ke rilis yang stabil terbaru gunakan:

cluster/gce/upgrade.sh release/stable

Memperbarui klaster Google Kubernetes Engine

Google Kubernetes Engine secara otomatis memperbarui komponen control plane (misalnya, kube-apiserver, kube-scheduler) ke versi yang terbaru. Ini juga menangani pembaruan sistem operasi dan komponen lain yang dijalankan oleh control plane.

Proses pembaruan Node dimulai oleh pengguna dan dijelaskan dalam Dokumentasi Google Kubernetes Engine.

Memperbarui klaster Amazon EKS

Komponen control plane klaster pada Amazon EKS dapat diperbarui dengan menggunakan eksctl, AWS Management Console, atau AWS CLI. Prosesnya dimulai oleh pengguna dan dijelaskan di Dokumentasi Amazon EKS.

Memperbarui klaster Oracle Cloud Infrastructure Container Engine untuk Kubernetes (OKE)

Oracle membuat dan mengelola sekumpulan Node control plane pada control plane Oracle atas nama kamu (dan infrastruktur Kubernetes terkait seperti Node etcd) untuk memastikan kamu memiliki Kubernetes control plane yang terkelola dengan ketersedian tinggi. Kamu juga dapat memperbarui Node control plane ini dengan mulus ke versi Kubernetes baru tanpa berhenti. Tindakan ini dijelaskan dalam Dokumentasi OKE.

Memperbarui klaster pada platform yang lain

Penyedia dan alat yang berbeda akan mengelola pembaruan secara berbeda. Kamu disarankan untuk membaca dokumentasi utama mereka terkait pembaruan.

• kops
• kubespray
• CoreOS Tectonic
• Digital Rebar
• ...

Untuk memperbarukan sebuah klaster pada platform yang tidak disebutkan dalam daftar di atas, periksa urutan pembaruan komponen pada halaman Versi Skewed.

Merubah ukuran klaster

Jika klaster kamu kekurangan sumber daya, kamu dapat dengan mudah menambahkan lebih banyak mesin ke klaster tersebut jika klaster kamu menjalankan Mode Node Registrasi Sendiri. Jika kamu menggunakan GCE atau Google Kubernetes Engine, itu dilakukan dengan mengubah ukuran grup instance yang mengelola Node kamu. Ini dapat dilakukan dengan mengubah jumlah instance pada Compute > Compute Engine > Instance groups > your group > Edit group Laman Google Cloud Console atau dengan baris perintah gcloud:

gcloud compute instance-groups managed resize kubernetes-node-pool --size=42 --zone=$ZONE

Grup instance akan menangani penempatan image yang sesuai pada mesin baru dan memulainya, sedangkan Kubelet akan mendaftarkan Node-nya ke server API agar tersedia untuk penjadwalan. Jika kamu menurunkan skala grup instance, sistem akan secara acak memilih Node untuk dimatikan.

Di lingkungan lain kamu mungkin perlu mengonfigurasi mesin sendiri dan memberi tahu Kubelet di mana server API mesin itu berjalan.

Merubah ukuran klaster Azure Kubernetes Service (AKS)

Azure Kubernetes Service memungkinkan perubahan ukuran klaster yang dimulai oleh pengguna dari CLI atau portal Azure dan dijelaskan dalam Dokumentasi Azure AKS.

Penyekalaan otomatis klaster

Jika kamu menggunakan GCE atau Google Kubernetes Engine, kamu dapat mengonfigurasi klaster kamu sehingga secara otomatis diskalakan berdasarkan kebutuhan Pod.

Seperti yang dideskripsikan dalam Sumber daya komputasi, pengguna dapat memesan berapa banyak CPU dan memori yang dialokasikan ke Pod. Informasi ini digunakan oleh penjadwal Kubernetes untuk menemukan tempat menjalankan Pod. Jika tidak ada Node yang memiliki kapasitas kosong yang cukup (atau tidak sesuai dengan persyaratan Pod yang lainnya) maka Pod menunggu sampai beberapa Pod dihentikan atau Node baru ditambahkan.

Penyekala otomatis klaster mencari Pod yang tidak dapat dijadwalkan dan memeriksa apakah perlu menambahkan Node baru, yang serupa dengan Node yang lain dalam klaster untuk membantu. Jika ya, maka itu mengubah ukuran klaster agar dapat mengakomodasi Pod yang menunggu.

Penyekala otomatis klaster juga menurunkan skala klaster jika mengetahui bahwa satu atau beberapa Node tidak diperlukan lagi untuk periode waktu tambahan (selama 10 menit tetapi dapat berubah di masa mendatang).

Penyekala otomatis klaster dikonfigurasikan untuk per grup instance (GCE) atau kumpulan Node (Google Kubernetes Engine).

Jika kamu menggunakan GCE, kamu dapat mengaktifkannya sambil membuat klaster dengan skrip kube-up.sh. Untuk mengonfigurasi penyekala otomatis klaster, kamu harus menyetel tiga variabel lingkungan:

• KUBE_ENABLE_CLUSTER_AUTOSCALER - mengaktifkan penyekala otomatis klaster kalau di setel menjadi true.
• KUBE_AUTOSCALER_MIN_NODES - minimal jumlah Node dalam klaster.
• KUBE_AUTOSCALER_MAX_NODES - maksimal jumlah Node dalam klaster.

Contoh:

KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh

Pada Google Kubernetes Engine, kamu mengonfigurasi penyekala otomatis klaster baik saat pembuatan atau pembaruan klaster atau saat membuat kumpulan Node tertentu (yang ingin kamu skalakan secara otomatis) dengan meneruskan flag --enable-autoscaling, --min-nodes dan --max-nodes yang sesuai dengan perintah gcloud.

Contoh:

gcloud container clusters create mytestcluster --zone=us-central1-b --enable-autoscaling --min-nodes=3 --max-nodes=10 --num-nodes=5

gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=1 --max-nodes=15

Penyekala otomatis klaster mengharapkan bahwa Node belum dimodifikasi secara manual (misalnya dengan menambahkan label melalui kubectl) karena properti tersebut tidak akan disebarkan ke Node baru dalam grup instance yang sama.

Untuk detail selengkapnya tentang cara penyekala otomatis klaster memutuskan apakah, kapan dan bagaimana melakukan penyekalaan sebuah klaster, silahkan lihat dokumentasi FAQ dari proyek penyekala otomatis klaster.

Memelihara dalam Node

Jika kamu perlu memulai ulang Node (seperti untuk pembaruan kernel, pembaruan libc, pembaruan perangkat keras, dll.) dan waktu kegagalan (downtime) yang singkat, lalu ketika Kubelet memulai ulang, maka ia akan mencoba untuk memulai ulang Pod yang dijadwalkan. Jika mulai ulang membutuhkan waktu yang lebih lama (waktu bawaan adalah 5 menit, yang dikontrol oleh --pod-eviction-timeout pada controller-manager), maka pengontrol Node akan menghentikan Pod yang terikat ke Node yang tidak tersedia. Jika ada yang sesuai dengan kumpulan replika (atau pengontrol replikasi), maka salinan baru dari Pod akan dimulai pada Node yang berbeda. Jadi, dalam kasus di mana semua Pod direplikasi, pembaruan dapat dilakukan tanpa koordinasi khusus, dengan asumsi bahwa tidak semua Node akan mati pada saat yang bersamaan.

Jika kamu ingin lebih mengontrol proses pembaruan, kamu dapat menggunakan alur kerja berikut ini:

Gunakan kubectl drain untuk meghentikan perlahan-lahan semua Pod dalam Node ketika menandai Node sebagai unschedulable:

kubectl drain $NODENAME

Ini mencegah Pod baru mendarat pada Node saat kamu mencoba melepaskannya.

Untuk Pod dengan sebuah kumpulan replika, Pod tersebut akan diganti dengan Pod baru yang akan dijadwalkan ke Node baru. Selain itu, jika Pod adalah bagian dari layanan, maka klien akan secara otomatis dialihkan ke Pod baru.

Untuk Pod yang tidak memiliki replika, kamu perlu memunculkan salinan baru dari Pod tersebut, dan menganggapnya bukan bagian dari layanan, alihkan klien ke Pod tersebut.

Lakukan pekerjaan pemeliharaan pada Node.

Buat Node dapat dijadwal lagi:

kubectl uncordon $NODENAME

Jika kamu menghapus Node dari instance VM dan membuat yang baru, maka sumber daya Node baru yang dapat dijadwalkan akan dibuat secara otomatis (jika kamu menggunakan penyedia cloud yang mendukung pencarian Node; saat ini hanya Google Compute Engine, tidak termasuk CoreOS di Google Compute Engine menggunakan kube-register). Lihatlah Node untuk lebih detail.

Topik lebih lanjut

Mengaktifkan atau menonaktifkan versi API untuk klaster kamu

Versi API spesifik dapat dinyalakan dan dimatikan dengan meneruskan flag --runtime-config=api/<version> ketika menjalankan server API. Sebagai contoh: untuk menyalakan APIv1, teruskan --runtime-config=api/v1=false. runtime-config juga mendukung 2 kunci khusus: api/all dan api/legacy yang masing-masing untuk mengontrol semua dan API lama. Sebagai contoh, untuk mematikan versi API semua kecuali v1, teruskan --runtime-config=api/all=false,api/v1=true. Untuk tujuan flag ini, API lama adalah API yang sudah tidak digunakan lagi secara eksplisit (misalnya, v1beta3).

Mengalihkan versi API penyimpanan dari klaster kamu

Objek yang disimpan ke diska untuk representasi internal klaster dari sumber daya Kubernetes yang aktif dalam klaster ditulis menggunakan versi API tertentu. Saat API yang didukung berubah, objek ini mungkin perlu ditulis ulang dalam API yang lebih baru. Kegagalan melakukan ini pada akhirnya akan menghasilkan sumber daya yang tidak lagi dapat didekodekan atau digunakan oleh server API Kubernetes.

Mengalihkan berkas konfigurasi kamu ke versi API baru

Kamu dapat menggunakan perintah kubectl convert untuk mengubah berkas konfigurasi di antara versi API berbeda.

kubectl convert -f pod.yaml --output-version v1

Untuk opsi yang lainnya, silakan merujuk pada penggunaan dari perintah kubectl convert.