Memperluas Kubernetes

• 1: Memperluas Klaster Kubernetes Kamu
• 2: Memperluas API Kubernetes
• 2.1: Memperluas Kubernetes API dengan Lapisan Agregasi
• 2.2: Custom Resource
• 3: Ekstensi Komputasi, Penyimpanan, dan Jaringan
• 3.1: Plugin Jaringan
• 3.2: Plugin Perangkat
• 4: Pola Operator
• 5: Service Catalog
• 6: Poseidon-Firmament - Sebuah Penjadwal Alternatif

1 - Memperluas Klaster Kubernetes Kamu

Kubernetes sangat mudah dikonfigurasi dan diperluas. Sehingga, jarang membutuhkan fork atau menambahkan patch ke kode proyek Kubernetes.

Panduan ini menjelaskan pilihan untuk menyesuaikan klaster Kubernetes. Dokumen ini ditujukan kepada operator klaster yang ingin memahami bagaimana menyesuaikan klaster Kubernetes dengan kebutuhan lingkungan kerja mereka.

Developer yang prospektif Developer Platform atau Kontributor Proyek Kubernetes juga mendapatkan manfaat dari dokumen ini sebagai pengantar apa saja poin-poin dan pola-pola perluasan yang ada, untung-rugi, dan batasan-batasannya.

Ikhtisar

Pendekatan-pendekatan kostumisasi secara umum dapat dibagi atas konfigurasi, yang hanya melibatkan perubahan flag, konfigurasi berkas lokal, atau objek-objek sumber daya API; dan perluasan, yang melibatkan berjalannya program atau layanan tambahan. Dokumen ini sebagian besar membahas tentang perluasan.

Konfigurasi

Flag-flag dan berkas-berkas konfigurasi didokumentasikan di bagian Referensi dari dokumentasi daring, didalam setiap binary:

• kubelet
• kube-apiserver
• kube-controller-manager
• kube-scheduler.

Flag-flag dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang hosted atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain.

API kebijakan bawaan, seperti ResourceQuota, PodSecurityPolicy, NetworkPolicy dan Role-based Access Control (RBAC), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang hosted dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari kebijakan pendukung yang jelas seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada berkas konfigurasi dan flag-flag saat mereka cocok dengan situasi yang dibutuhkan.

Perluasan

Perluasan adalah komponen perangkat lunak yang memperluas dan berintegrasi secara mendalam dengan Kubernetes. Mereka mengadaptasi Kubernetes untuk mendukung perangkat keras tipe baru dan jenis baru.

Kebanyakan administrator klaster akan menggunakan instansi Kubernetes yang didistribusikan atau yang hosted. Sebagai hasilnya, kebanyakan pengguna Kubernetes perlu menginstal perluasan dan lebih sedikit yang perlu untuk membuat perluasan-perluasan yang baru.

Pola-pola Perluasan

Kubernetes didesain untuk dapat diotomasi dengan menulis program-program klien. Program apapun yang membaca dan/atau menulis ke API Kubernetes dapat menyediakan otomasi yang berguna.

Otomasi dapat berjalan di dalam klaster atau di luar klaster. Dengan mengikuti panduan di dalam dokumen ini, kamu dapat menulis otomasi yang sangat tersedia dan kuat. Otomasi pada umumnya dapat bekerja dengan berbagai macam klaster Kubernetes, termasuk klaster yang hosted dan instalasi yang dikelola.

Ada pola spesifik untuk menulis program klien yang bekerja dengan baik bersama Kubernetes yang disebut pola Controller. Controller-controller biasanya membaca kolom .spec milik sebuah objek, kemungkinan melakukan sesuatu, dan kemudian memperbarui objek milik .status.

Controller adalah klien dari Kubernetes. Ketika Kubernetes adalah klien dan memanggil layanan terpisah, hal tersebut disebut Webhook. Layanan terpisah tersebut disebut sebuah Webhook Backend. Seperti Controller-controller, Webhook-webhook memang menambah sebuah titik untuk terjadinya kegagalan.

Di dalam model Webhook, Kubernetes membuat sebuah network request kepada sebuah layanan terpisah.

Di dalam model Binary Plugin, Kubernetes mengeksekusi sebuah program. Binary Plugin digunakan oleh kubelet (misalnya Plugin Flex Volume dan oleh Plugin Jaringan) dan oleh kubectl.

Berikut ini adalah diagram yang menunjukkan bagaimana titik-titik perluasan berinteraksi dengan control plane Kubernetes.

Titik-titik Perluasan

Diagram berikut menunjukkan titik-titik perluasan di sebuah Kubernetes.

1. Pengguna biasanya berinteraksi dengan API Kubernetes menggunakan kubectl. Plugin-plugin Kubectl memperluas binari kubectl. Mereka hanya memengaruhi lingkungan lokal pengguna, dan tidak dapat memaksakan kebijakan yang menyeluruh di seluruh situs.
2. apiserver menangani semua permintaan. Beberapa tipe titik perluasan di apiserver memperbolehkan otentikasi permintaan, atau memblokir mereka berdasarkan konten mereka, menyunting konten, dan menangani penghapusan. Hal ini dideskripsikan di bagian Perluasan Akses API
3. apiserver melayani berbagai macam sumber daya, tipe-tipe sumber daya bawaan, seperti pod, didefinisikan oleh proyek kubernetes dan tidak dapat diubah. kamu juga dapat menambahkan sumber daya yang kamu definisikan sendiri, atau yang proyek lain definisikan, disebut Custom Resources, seperti dijelaskan di bagian Sumber Daya Custom. Sumber daya Custom sering digunakan dengan Perluasan Akses API.
4. Penjadwal Kubernetes memutuskan ke Node mana Pod akan ditempatkan. Ada beberapa cara untuk memperluas penjadwalan. Hal ini dibahas pada bagian Perluasan-perluasan Penjadwal.
5. Sebagian besar perilaku Kubernetes diimplementasi oleh program yang disebut Controller-controller yang merupakan klien dari API-Server. Controller-controller sering digunakan bersama dengan Sumber Daya Custom.
6. Kubelet berjalan di server, dan membantu Pod-pod terlihat seperti server virtual dengan IP mereka sendiri di jaringan klaster. Plugin Jaringan memungkinkan adanya perbedaan implementasi pada jaringan Pod.
7. Kubelet juga melakukan penambatan dan pelepasan tambatan volume untuk kontainer. Tipe-tipe penyimpanan baru dapat didukung via Plugin Penyimpanan.

Jika kamu tidak yakin untuk memulai dari mana, diagram alir di bawah ini dapat membantu kamu. Ingat lah bahwa beberapa solusi mungkin melibatkan beberapa tipe perluasan.

Perluasan API

Tipe-tipe yang Ditentukan Pengguna

Pertimbangkan untuk menambahkan Sumber Daya Custom ke Kubernetes jika kamu ingin mendefinisikan pengontrol baru, objek konfigurasi aplikasi atau API deklaratif lainnya, dan untuk mengelolanya menggunakan alat Kubernetes, seperti kubectl.

Jangan menggunakan Sumber Daya Custom sebagai penyimpanan data untuk aplikasi, pengguna, atau untuk memonitor data.

Untuk lebih jelasnya tentang Sumber Daya Custom, lihat Panduan Konsep Sumber Daya Custom.

Menggabungkan API Baru dengan Otomasi

Kombinasi antara sebuah API sumber daya custom dan loop kontrol disebut Pola Operator. Pola Operator digunakan untuk mengelola aplikasi yang spesifik dan biasanya stateful. API-API custom dan loop kontrol ini dapat digunakan untuk mengatur sumber daya lainnya, seperti penyimpanan dan kebijakan-kebijakan.

Mengubah Sumber Daya Bawaan

Ketika kamu memperluas API Kubernetes dengan menambahkan sumber daya custom, sumber daya yang ditambahkan akan selalu masuk ke Grup API baru. Kamu tidak dapat mengganti atau mengubah Grup API yang sudah ada. Menambah sebuah API tidak secara langsung membuat kamu memengaruhi perilaku API yang sudah ada (seperti Pod), tetapi Perluasan Akses API dapat memengaruhinya secara langsung.

Perluasan-Perluasan Akses API

Ketika sebuah permintaan sampai ke Server API Kubernetes, permintaan tersebut diotentikasi terlebih dahulu, kemudian diotorisasi, kemudian diarahkan ke berbagai jenis Admission Control. Lihat dokumentasi Mengatur Akses ke API Kubernetes untuk lebih jelasnya tentang alur ini.

Setiap langkah berikut menawarkan titik-titik perluasan.

Kubernetes memiliki beberapa metode otentikasi bawaan yang didukungnya. Metode ini bisa berada di belakang proksi yang mengotentikasi, dan metode ini dapat mengirim sebuah token dari header Otorisasi ke layanan terpisah untuk verifikasi (sebuah webhook). Semua metode ini tercakup dalam Dokumentasi Otentikasi.

Otentikasi

Otentikasi memetakan header atau sertifikat dalam semua permintaan ke username untuk klien yang mebuat permintaan.

Kubernetes menyediakan beberapa metode otentikasi bawaan, dan sebuah metode Webhook Otentikasi jika metode bawaan tersebut tidak mencukupi kebutuhan kamu.

Otorisasi

Otorisasi menentukan apakah pengguna tertentu dapat membaca, menulis, dan melakukan operasi lainnya terhadap sumber daya API. Hal ini hanya bekerja pada tingkat sumber daya secara keseluruhan -- tidak membeda-bedakan berdasarkan field objek sembarang. Jika pilihan otorisasi bawaan tidak mencukupi kebutuhan kamu, Webhook Otorisasi memungkinkan pemanggilan kode yang disediakan pengguna untuk membuat keputusan otorisasi.

Kontrol Admisi Dinamis

Setalah permintaan diotorisasi, jika ini adalah operasi penulisan, permintaan ini akan melalui langkah Kontrol Admisi. Sebagai tambahan untuk step bawaan, ada beberapa perluasan:

• Webhook Kebijakan Image membatasi image mana saja yang dapat berjalan di kontainer.
• Untuk membuat keputusan kontrol admisi sembarang, Webhook Admisi umum dapat digunakan. Webhook Admisi dapat menolak pembuatan atau pembaruan.

Perluasan Infrastruktur

Plugin-plugin Penyimpanan

Flex Volume memungkinkan pengguna untuk memasang tipe-tipe volume tanpa dukungan bawaan dengan cara membiarkan Kubelet memanggil sebuah Plugin Binary untuk menambatkan volume.

Plugin Perangkat

Plugin perangkat memungkinkan sebuah node untuk menemukan sumber daya Node baru (sebagai tambahan dari bawaannya seperti CPU dan memori) melalui sebuah Plugin Perangkat.

Plugin-plugin Jaringan

Struktur-struktur jaringan yang berbeda dapat didukung melalui Plugin Jaringan pada tingkat Node.

Perluasan-perluasan Penjadwal

Penjadwal adalah jenis pengatur spesial yang mengawasi Pod, dan menempatkan Pod ke Node. Penjadwal bawaan dapat digantikan seluruhnya, sementara terus menggunakan komponen Kubernetes lainnya, atau penjadwal ganda dapat berjalan dalam waktu yang bersamaan.

Ini adalah usaha yang signifikan, dan hampir semua pengguna Kubernetes merasa mereka tidak perlu memodifikasi penjadwal tersebut.

Penjadwal juga mendukung webhook yang memperbolehkan sebuah webhook backend (perluasan penjadwal) untuk menyaring dan memprioritaskan Node yang terpilih untuk sebuah Pod.

Selanjutnya

• Pelajari lebih lanjut tentang Sumber Daya Custom
• Pelajari tentang Kontrol Admisi Dinamis
• Pelajari lebih lanjut tentang perluasan Infrastruktur
  • Plugin Jaringan
  • Plugin Perangkat
• Pelajari tentang Plugin kubectl
• Pelajari tentang Pola Operator

2 - Memperluas API Kubernetes

2.1 - Memperluas Kubernetes API dengan Lapisan Agregasi

Lapisan agregasi memungkinkan Kubernetes untuk diperluas dengan API tambahan, selain dari yang ditawarkan oleh API inti Kubernetes.

Ikhtisar

Lapisan agregasi memungkinkan instalasi tambahan beragam API Kubernetes-style di kluster kamu. Tambahan-tambahan ini dapat berupa solusi-solusi yang sudah dibangun (prebuilt) oleh pihak ke-3 yang sudah ada, seperti service-catalog, atau API yang dibuat oleh pengguna seperti apiserver-builder, yang dapat membantu kamu memulainya.

Lapisan agregasi berjalan di dalam proses bersama dengan kube-apiserver. Hingga sebuah sumber daya ekstensi terdaftar, lapisan agregasi tidak akan melakukan apapun. Untuk mendaftarkan sebuah API, pengguna harus menambahkan sebuah objek APIService, yang "mengklaim" jalur URL di API Kubernetes. Pada titik tersebut, lapisan agregasi akan mem-proxy apapun yang dikirim ke jalur API tersebut (misalnya /apis/myextension.mycompany.io/v1/…) ke APIService yang terdaftar.

Biasanya, APIService akan diimplementasikan oleh sebuah ekstensi-apiserver di dalam sebuah Pod yang berjalan di kluster. Ekstensi-apiserver ini biasanya perlu di pasangkan dengan satu atau lebih controller apabila manajemen aktif dari sumber daya tambahan diperlukan. Sebagai hasilnya, apiserver-builder sebenarnya akan memberikan kerangka untuk keduanya. Sebagai contoh lain, ketika service-catalog diinstal, ia menyediakan ekstensi-apiserver dan controller untuk layanan-layanan yang disediakannya.

Ekstensi-apiserver harus memiliki latensi koneksi yang rendah dari dan ke kube-apiserver. Secara Khusus, permintaan pencarian diperlukan untuk bolak-balik dari kube-apiserver dalam 5 detik atau kurang. Jika implementasi kamu tidak dapat menyanggupinya, kamu harus mempertimbangkan cara mengubahnya. Untuk sekarang, menyetel feature-gate EnableAggregatedDiscoveryTimeout=false di kube-apiserver akan menonaktifkan batasan waktu tersebut. Fitur ini akan dihapus dalam rilis mendatang.

Selanjutnya

• Untuk mengaktifkan agregator di lingkungan kamu, aktifkankonfigurasi lapisan agregasi.
• Kemudian, siapkan ekstensi api-server untuk bekerja dengan lapisan agregasi.
• Selain itu, pelajari caranya mengembangkan API Kubernetes menggunakan Custom Resource Definition.

2.2 - Custom Resource

Custom Resource adalah ekstensi dari Kubernetes API. Laman ini mendiskusikan kapan kamu melakukan penambahan sebuah Custom Resource ke klaster Kubernetes dan kapan kamu menggunakan sebuah layanan mandiri. Laman ini mendeskripsikan dua metode untuk menambahkan Custom Resource dan bagaimana cara memilihnya.

Custom Resource

Sebuah sumber daya adalah sebuah endpoint pada Kubernetes API yang menyimpan sebuah koleksi objek API dari sebuah jenis tertentu. Sebagai contoh, sumber daya bawaan Pod mengandung sebuah koleksi objek-objek Pod.

Sebuah Custom Resource adalah sebuah ekstensi dari Kubernetes API yang tidak seharusnya tersedia pada pemasangan default Kubernetes. Namun, banyak fungsi-fungsi inti Kubernetes yang sekarang dibangun menggunakan Custom Resource, membuat Kubernetes lebih modular.

Custom Resource bisa muncul dan menghilang dalam sebuah klaster yang berjalan melalui registrasi dinamis (dynamic registration), dan admin-admin klaster bisa memperbaharui Custom Resource secara independen dari klaster itu sendiri. Ketika sebuah Custom Resource dipasang, pengguna dapat membuat dan mengakses objek-objek Custom Resource menggunakan kubectl, seperti yang mereka lakukan untuk sumber daya bawaan seperti Pod.

Controller Khusus

Dengan sendirinya, Custom Resource memungkinkan kamu untuk menyimpan dan mengambil data terstruktur. Ketika kamu menggabungkan sebuah Custom Resource dengan controller khusus, Custom Resource akan memberikan sebuah API deklaratif yang sebenarnya.

Sebuah API deklaratif memungkinkan kamu untuk mendeklarasikan atau menspesifikasikan keadaan dari sumber daya kamu dan mencoba untuk menjaga agar keadaan saat itu tersinkronisasi dengan keadaan yang diinginkan. Controller menginterpretasikan data terstruktur sebagai sebuah rekaman dari keadaan yang diinginkan pengguna, dan secara kontinu menjaga keadaan ini.

Kamu bisa men-deploy dan memperbaharui sebuah controller khusus pada sebuah klaster yang berjalan, secara independen dari siklus hidup klaster itu sendiri. Controller khusus dapat berfungsi dengan sumber daya jenis apapun, tetapi mereka sangat efektif ketika dikombinasikan dengan Custom Resource. Operator pattern mengkombinasikan Custom Resource dan controller khusus. Kamu bisa menggunakan controller khusus untuk menyandi pengetahuan domain untuk aplikasi spesifik menjadi sebuah ekstensi dari Kubernetes API.

Haruskah Custom Resource ditambahkan ke dalam klaster Kubernetes saya?

Ketika membuat sebuah API baru, pikirkan apakah kamu ingin mengagregasikan API kamu dengan API klaster Kubernetes atau membiarkan API kamu berdiri sendiri.

API Deklaratif

Dalam sebuah API Deklaratif, biasanya:

• API kamu terdiri dari sejumlah kecil dari objek yang berukuran relatif kecil (sumber daya).
• Objek-objek mendefinisikan pengaturan dari aplikasi atau infrastruktur.
• Objek-objek relatif tidak sering diperbaharui.
• Manusia sering diperlukan untuk membaca dan menulis objek-objek tersebut.
• Operasi utama terhadap objek bersifat CRUD (creating, reading, updating, dan deleting).
• Transaksi antar objek tidak dibutuhkan; API merepresentasikan sebuah keadaan yang diinginkan, bukan keadaan yang eksak.

API imperatif bersifat tidak deklaratif. Tanda-tanda apabila API kamu tidak deklaratif termasuk:

• klien berkata "lakukan ini", dan kemudian mendapat sebuah respon serempak ketika selesai.
• klien berkata "lakukan ini", dan kemudian mendapat sebuah ID operasi kembali, dan harus melakukan sebuah cek terhadap objek Operation terpisah untuk menentukan selesainya sebuah permintaan.
• Kamu berbicara tentang Remote Procedure Call (RPC).
• Menyimpan secara langsung sejumlah data (mis. > beberapa kB per objek, atau >1000-an objek).
• Membutuhkan akses dengan bandwidth tinggi (10-an permintaan per detik dapat ditopang).
• Menyimpan data pengguna (seperti gambar, PII, dll) atau data berskala besar yang diproses oleh aplikasi.
• Operasi-operasi natural terhadap objek yang tidak bersifat CRUD.
• API yang tidak mudah dimodelkan dengan objek.
• Kamu memilih untuk merepresentasikan operasi tertunda dengan sebuah ID operasi atau sebuah objek operasi.

Apakah saya harus menggunakan sebuah ConfigMap atau sebuah Custom Resource?

Gunakan ConfigMap jika salah satu hal berikut berlaku:

• Terdapat sebuah format berkas pengaturan yang sudah ada, yang terdokumentasi dengan baik seperti sebuah mysql.cnf atau pom.xml.
• Kamu ingin menaruh seluruh berkas pengaturan kedalam sebuah key dari sebuah ConfigMap.
• Kegunaan utama dari berkas pengaturan adalah untuk dikonsumsi sebuah program yang berjalan di dalam sebuah Pod di dalam klaster kamu untuk mengatur dirinya sendiri.
• Konsumen dari berkas lebih suka untuk mengkonsumsi lewat berkas dalam sebuah Pod atau variabel lingkungan dalam sebuah Pod, dibandingkan melalui Kubernetes API.
• Kamu ingin melakukan pembaharuan bergulir lewat Deployment, dll, ketika berkas diperbaharui.

Gunakan sebuah Custom Resource (CRD atau Aggregated API) jika kebanyakan dari hal berikut berlaku:

• Kamu ingin menggunakan pustaka klien Kubernetes dan CLI untuk membuat dan memperbaharui sumber daya baru.
• Kamu ingin dukungan tingkat tinggi dari kubectl (sebagai contoh: kubectl get my-object object-name).
• Kamu ingin membangun sebuah otomasi baru yang mengawasi pembaharuan terhadap objek baru, dan kemudian melakukan CRUD terhadap objek lainnya, atau sebaliknya.
• Kamu ingin menulis otomasi yang menangani pembaharuan untuk objek.
• Kamu ingin menggunakan kesepakatan API Kubernetes seperti .spec, .status, dan .metadata.
• Kamu ingin objek tersebut untuk menjadi sebuah abstraksi terhadap sebuah kumpulan dari sumber daya terkontrol, atau peringkasan dari sumber daya lainnya.

Menambahkan Custom Resource

Kubernetes menyediakan dua cara untuk menambahkan sumber daya ke klaster kamu:

• CRD cukup sederhana dan bisa diciptakan tanpa pemrograman apapun.
• Agregasi API membutuhkan pemrograman, tetapi memungkinkan kendali lebih terhadap perilaku API seperti bagaimana data disimpan dan perubahan antar versi API.

Kubernetes menyediakan kedua opsi tersebut untuk memenuhi kebutuhan pengguna berbeda, jadi tidak ada kemudahan penggunaan atau fleksibilitas yang dikompromikan.

Aggregated API adalah bawahan dari APIServer yang duduk dibelakang API server utama, yang bertindak sebagai sebuah proxy. Pengaturan ini disebut Agregasi API (AA). Untuk pengguna, yang terlihat adalah Kubernetes API yang diperluas.

CRD memungkinkan pengguna untuk membuat tipe baru sumber daya tanpa menambahkan APIserver lain. Kamu tidak perlu mengerti Agregasi API untuk menggunakan CRD.

Terlepas dari bagaimana cara mereka dipasang, sumber daya baru disebut sebagai Custom Resource untuk memisahkan mereka dari sumber daya bawaan Kubernetes (seperti Pod).

CustomResourceDefinition

Sumber daya API CustomResourceDefinition memungkinkan kamu untuk medefinisikan Custom Resource. Mendefinisikan sebuah objek CRD akan membuat sebuah Custom Resource dengan sebuah nama dan skema yang kamu spesifikasikan. Kubernetes API melayani dan menangani penyimpanan dari Custom Resource kamu.

Ini membebaskan kamu dari menulis server API kamu sendiri untuk menangani Custom Resource, tetapi sifat dasar dari implementasi menyebabkan kamu memiliki fleksibilitas yang berkurang dibanding agregasi server API).

Lihat contoh controller khusus sebagai sebuah contoh dari bagaimana cara untuk mendaftarkan sebuah Custom Resource, bekerja dengan instans dari tipe baru sumber daya kamu, dan menggunakan sebuah controller untuk menangani event.

Agregasi server API

Biasanya, tiap sumber daya di API Kubernetes membutuhkan kode yang menangani permintaan REST dan mengatur peyimpanan tetap dari objek-objek. Server Kubernetes API utama menangani sumber daya bawaan seperti Pod dan Service, dan juga menangani Custom Resource dalam sebuah cara yang umum melalui CRD.

Lapisan agregasi memungkinkan kamu untuk menyediakan implementasi khusus untuk Custom Resource dengan menulis dan men-deploy API server kamu yang berdiri sendiri. API server utama menlimpahkan permintaan kepada kamu untuk Custom Resource yang kamu tangani, membuat mereka tersedia untuk semua kliennya.

Memilih sebuah metode untuk menambahkan Custom Resource

CRD lebih mudah digunakan. Aggregated API lebih fleksibel. Pilih metode yang paling baik untuk kebutuhan kamu.

Biasanya, CRD cocok jika:

• Kamu memiliki field yang banyak
• Kamu menggunakan sumber daya dalam perusahaan kamu, atau sebagai bagian dari proyek open-source kecil (berlawanan dengan sebuah produk komersil)

Membandingkan kemudahan penggunaan

CRD lebih mudah dibuat dibandingkan dengan Aggregated API.

Fitur lanjutan dan fleksibilitas

Aggregated API menawarkan fitur API lebih lanjut dan kustomisasi dari fitur lain, sebagai contoh: lapisan penyimpanan.

Fitur Umum

Ketika kamu membuat sebuah Custom Resource, baik melalui sebuah CRD atau sebuah AA, kamu mendapat banyak fitur untuk API kamu, dibandingkan dengan mengimplementasikannya diluar platform Kubernetes.

Persiapan pemasangan sebuah Custom Resource

Ada beberapa poin yang harus diperhatikan sebelum menambahkan sebuah Custom Resource ke klaster kamu.

Kode pihak ketiga dan poin kegagalan baru

Saat membuat sebuah CRD tidak secara otomatis menambahkan titik-titik kegagalan baru (sebagai contoh, dengan menyebabkan kode pihak ketiga untuk berjalan di API server kamu), paket-paket (sebagai contoh, Chart) atau bundel pemasangan lain seringkali sudah termasuk CRD dan juga sebagai Deployment dari kode pihak ketiga yang mengimplementasi logika bisnis untuk sebuah Custom Resource.

Memasang sebuah APIserver teragregasi selalu melibatkan tindakan menjalankan Deployment baru.

Penyimpanan

Custom Resource mengkonsumsi ruang penyimpanan dengan cara yang sama dengan ConfigMap. Membuat terlalu banyak sumber daya mungkin akan memenuhi ruang penyimpanan server API kamu.

Server Aggregated API dapat menggunakan penyimpanan yang sama dengan server API utama, dimana peringatan yang sama berlaku.

Authentication, authorization, and auditing

CRD selalu menggunakan otentikasi, otorisasi, dan audit pencatatan yang sama sebagai sumber daya bawaan dari server API kamu.

Jika kamu menggunakan RBAC untuk otorisasi, sebagian besar role RBAC tidak akan mengizinkan akses ke sumber daya baru (kecuali role cluster-admin atau role apapun yang dibuat menggunakan aturan wildcard). Kamu akan dibutuhkan untuk secara eksplisit mengizinkan akses ke sumber daya baru. CRD dan Aggregated API seringkali dibundel dengan definisi role baru untuk tipe yang mereka tambahkan.

API server teragregasi dapat atau tidak dapat menggunakan otentikasi, otorisasi, dan pengauditan yang sama dengan server API utama.

Mengakses sebuah Custom Resource

Pustaka klien Kubernetes dapat digunakan untuk mengakses Custom Resource. Tidak semua pustaka klien mendukung Custom Resource. Pustaka klien go dan python melakukannya.

Ketika kamu menambahkan sebuah Custom Resource, kamu dapat mengaksesnya dengan menggunakan:

• kubectl
• Klien dinamis kubernetes.
• Sebuah klien REST yang kamu tulis
• Sebuah klien yang dibuat menggunakan Kubernetes client generation tools (membuat satu adalah usaha lanjutan, tetapi beberapa proyek mungkin menyajikan sebuah klien bersama dengan CRD atau AA).

Selanjutnya

• Belajar bagaimana untuk Memperluas Kubernetes API dengan lapisan agregasi.

• Belajar bagaimana untuk Memperluas Kubernetes API dengan CustomResourceDefinition.

3 - Ekstensi Komputasi, Penyimpanan, dan Jaringan

3.1 - Plugin Jaringan

Plugin jaringan di Kubernetes hadir dalam beberapa varian:

• Plugin CNI : mengikuti spesifikasi appc / CNI, yang dirancang untuk interoperabilitas.
• Plugin Kubenet : mengimplementasi cbr0 sederhana menggunakan plugin bridge dan host-local CNI

Instalasi

Kubelet memiliki plugin jaringan bawaan tunggal, dan jaringan bawaan umum untuk seluruh kluster. Plugin ini memeriksa plugin-plugin ketika dijalankan, mengingat apa yang ditemukannya, dan mengeksekusi plugin yang dipilih pada waktu yang tepat dalam siklus pod (ini hanya berlaku untuk Docker, karena rkt mengelola plugin CNI sendiri). Ada dua parameter perintah Kubelet yang perlu diingat saat menggunakan plugin:

• cni-bin-dir: Kubelet memeriksa direktori ini untuk plugin-plugin saat startup
• network-plugin: Plugin jaringan untuk digunakan dari cni-bin-dir. Ini harus cocok dengan nama yang dilaporkan oleh plugin yang diperiksa dari direktori plugin. Untuk plugin CNI, ini (nilainya) hanyalah "cni".

Persyaratan Plugin Jaringan

Selain menyediakan antarmuka NetworkPlugin untuk mengonfigurasi dan membersihkan jaringan Pod, plugin ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi iptables jelas tergantung pada iptables, dan plugin ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk iptables. Misalnya, jika plugin menghubungkan kontainer ke bridge Linux, plugin harus mengatur nilai sysctl net/bridge/bridge-nf-call-iptables menjadi 1 untuk memastikan bahwa proksi iptables berfungsi dengan benar. Jika plugin ini tidak menggunakan bridge Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), plugin ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.

Secara bawaan jika tidak ada plugin jaringan Kubelet yang ditentukan, plugin noop digunakan, yang menetapkan net/bridge/bridge-nf-call-iptables=1 untuk memastikan konfigurasi sederhana (seperti Docker dengan sebuah bridge) bekerja dengan benar dengan proksi iptables.

CNI

Plugin CNI dipilih dengan memberikan opsi command-line --network-plugin=cni pada Kubelet. Kubelet membaca berkas dari --cni-conf-dir (bawaan /etc/cni/net.d) dan menggunakan konfigurasi CNI dari berkas tersebut untuk mengatur setiap jaringan Pod. Berkas konfigurasi CNI harus sesuai dengan spesifikasi CNI, dan setiap plugin CNI yang diperlukan oleh konfigurasi harus ada di --cni-bin-dir (nilai bawaannya adalah /opt/cni/bin).

Jika ada beberapa berkas konfigurasi CNI dalam direktori, Kubelet menggunakan berkas yang pertama dalam urutan abjad.

Selain plugin CNI yang ditentukan oleh berkas konfigurasi, Kubernetes memerlukan plugin CNI standar lo plugin , minimal pada versi 0.2.0.

Dukungan hostPort

Plugin jaringan CNI mendukung hostPort. Kamu dapat menggunakan plugin portmap resmi yang ditawarkan oleh tim plugin CNI atau menggunakan plugin kamu sendiri dengan fungsionalitas portMapping.

Jika kamu ingin mengaktifkan dukungan hostPort, kamu harus menentukan portMappings capability di cni-conf-dir kamu. Contoh:

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.0",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "nodename": "127.0.0.1",
      "ipam": {
        "type": "host-local",
        "subnet": "usePodCidr"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "portmap",
      "capabilities": {"portMappings": true}
    }
  ]
}

Dukungan pembentukan lalu-lintas

Plugin jaringan CNI juga mendukung pembentukan lalu-lintas yang masuk dan keluar dari Pod. Kamu dapat menggunakan plugin resmi bandwidth yang ditawarkan oleh tim plugin CNI atau menggunakan plugin kamu sendiri dengan fungsionalitas kontrol bandwidth.

Jika kamu ingin mengaktifkan pembentukan lalu-lintas, kamu harus menambahkan plugin bandwidth ke berkas konfigurasi CNI kamu (nilai bawaannya adalah /etc/cni/ net.d).

{
  "name": "k8s-pod-network",
  "cniVersion": "0.3.0",
  "plugins": [
    {
      "type": "calico",
      "log_level": "info",
      "datastore_type": "kubernetes",
      "nodename": "127.0.0.1",
      "ipam": {
        "type": "host-local",
        "subnet": "usePodCidr"
      },
      "policy": {
        "type": "k8s"
      },
      "kubernetes": {
        "kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
      }
    },
    {
      "type": "bandwidth",
      "capabilities": {"bandwidth": true}
    }
  ]
}

Sekarang kamu dapat menambahkan anotasi kubernetes.io/ingress-bandwidth dan kubernetes.io/egress-bandwidth ke Pod kamu. Contoh:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/ingress-bandwidth: 1M
    kubernetes.io/egress-bandwidth: 1M
...

Kubenet

Kubenet adalah plugin jaringan yang sangat mendasar dan sederhana, hanya untuk Linux. Ia, tidak dengan sendirinya, mengimplementasi fitur-fitur yang lebih canggih seperti jaringan cross-node atau kebijakan jaringan. Ia biasanya digunakan bersamaan dengan penyedia layanan cloud yang menetapkan aturan routing untuk komunikasi antar Node, atau dalam lingkungan Node tunggal.

Kubenet membuat bridge Linux bernama cbr0 dan membuat pasangan veth untuk setiap Pod dengan ujung host dari setiap pasangan yang terhubung ke cbr0. Ujung Pod dari pasangan diberi alamat IP yang dialokasikan dari rentang yang ditetapkan untuk Node baik melalui konfigurasi atau oleh controller-manager. cbr0 memiliki MTU yang cocok dengan MTU terkecil dari antarmuka normal yang diaktifkan pada host.

Plugin ini memerlukan beberapa hal:

• Plugin CNI bridge, lo dan host-local standar diperlukan, minimal pada versi 0.2.0. Kubenet pertama-tama akan mencari mereka di /opt/cni/bin. Tentukan cni-bin-dir untuk menyediakan lokasi pencarian tambahan. Hasil pencarian pertama akan digunakan.
• Kubelet harus dijalankan dengan argumen --network-plugin=kubenet untuk mengaktifkan plugin
• Kubelet juga harus dijalankan dengan argumen --non-masquerade-cidr=<clusterCidr> untuk memastikan lalu-lintas ke IP-IP di luar rentang ini akan menggunakan masquerade IP.
• Node harus diberi subnet IP melalui perintah kubelet --pod-cidr atau perintah controller-manager --allocate-node-cidrs=true --cluster-cidr=<cidr>.

Menyesuaikan MTU (dengan kubenet)

MTU harus selalu dikonfigurasi dengan benar untuk mendapatkan kinerja jaringan terbaik. Plugin jaringan biasanya akan mencoba membuatkan MTU yang masuk akal, tetapi terkadang logika tidak akan menghasilkan MTU yang optimal. Misalnya, jika bridge Docker atau antarmuka lain memiliki MTU kecil, kubenet saat ini akan memilih MTU tersebut. Atau jika kamu menggunakan enkapsulasi IPSEC, MTU harus dikurangi, dan perhitungan ini di luar cakupan untuk sebagian besar plugin jaringan.

Jika diperlukan, kamu dapat menentukan MTU secara eksplisit dengan opsi network-plugin-mtu kubelet. Sebagai contoh, pada AWS eth0 MTU biasanya adalah 9001, jadi kamu dapat menentukan --network-plugin-mtu=9001. Jika kamu menggunakan IPSEC, kamu dapat menguranginya untuk memungkinkan/mendukung overhead enkapsulasi pada IPSEC, contoh: --network-plugin-mtu=8873.

Opsi ini disediakan untuk plugin jaringan; Saat ini hanya kubenet yang mendukung network-plugin-mtu.

Ringkasan Penggunaan

• --network-plugin=cni menetapkan bahwa kita menggunakan plugin jaringan cni dengan binary-binary plugin CNI aktual yang terletak di --cni-bin-dir (nilai bawaannya /opt/cni/bin) dan konfigurasi plugin CNI yang terletak di --cni-conf-dir (nilai bawaannya /etc/cni/net.d).
• --network-plugin=kubenet menentukan bahwa kita menggunakan plugin jaringan kubenet dengan bridge CNI dan plugin-plugin host-local yang terletak di /opt/cni/bin atau cni-bin-dir.
• --network-plugin-mtu=9001 menentukan MTU yang akan digunakan, saat ini hanya digunakan oleh plugin jaringan kubenet.

Selanjutnya

3.2 - Plugin Perangkat

Kubernetes menyediakan kerangka kerja plugin perangkat sehingga kamu dapat memakainya untuk memperlihatkan sumber daya perangkat keras sistem ke dalam Kubelet.

Daripada menkustomisasi kode Kubernetes itu sendiri, vendor dapat mengimplementasikan plugin perangkat yang di-deploy secara manual atau sebagai DaemonSet. Perangkat yang dituju termasuk GPU, NIC berkinerja tinggi, FPGA, adaptor InfiniBand, dan sumber daya komputasi sejenis lainnya yang perlu inisialisasi dan setelan spesifik vendor.

Pendaftaran plugin perangkat

Kubelet mengekspor servis gRPC Registration:

service Registration {
	rpc Register(RegisterRequest) returns (Empty) {}
}

Plugin perangkat bisa mendaftarkan dirinya sendiri dengan kubelet melalui servis gRPC. Dalam pendaftaran, plugin perangkat perlu mengirim:

• Nama Unix socket-nya.
• Versi API Plugin Perangkat yang dipakai.
• ResourceName yang ingin ditunjukkan. ResourceName ini harus mengikuti skema penamaan sumber daya ekstensi sebagai vendor-domain/tipe-sumber-daya. (Contohnya, NVIDIA GPU akan dinamai nvidia.com/gpu.)

Setelah registrasi sukses, plugin perangkat mengirim daftar perangkat yang diatur ke kubelet, lalu kubelet kemudian bertanggung jawab untuk mengumumkan sumber daya tersebut ke peladen API sebagai bagian pembaruan status node kubelet. Contohnya, setelah plugin perangkat mendaftarkan hardware-vendor.example/foo dengan kubelet dan melaporkan kedua perangkat dalam node dalam kondisi sehat, status node diperbarui untuk menunjukkan bahwa node punya 2 perangkat “Foo” terpasang dan tersedia.

Kemudian, pengguna dapat meminta perangkat dalam spesifikasi Kontainer seperti meminta tipe sumber daya lain, dengan batasan berikut:

• Sumber daya ekstensi hanya didukung sebagai sumber daya integer dan tidak bisa overcommitted.
• Perangkat tidak bisa dibagikan antar Kontainer.

Semisal klaster Kubernetes menjalankan plugin perangkat yang menunjukkan sumber daya hardware-vendor.example/foo pada node tertentu. Berikut contoh Pod yang meminta sumber daya itu untuk menjalankan demo beban kerja:

---
apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
    - name: demo-container-1
      image: k8s.gcr.io/pause:2.0
      resources:
        limits:
          hardware-vendor.example/foo: 2
#
# Pod ini perlu 2 perangkat perangkat-vendor.example/foo
# dan hanya dapat menjadwalkan ke Node yang bisa memenuhi
# kebutuhannya.
#
# Jika Node punya lebih dari 2 perangkat tersedia,
# maka kelebihan akan dapat digunakan Pod lainnya.

Implementasi plugin perangkat

Alur kerja umum dari plugin perangkat adalah sebagai berikut:

• Inisiasi. Selama fase ini, plugin perangkat melakukan inisiasi spesifik vendor dan pengaturan untuk memastikan perangkat pada status siap.

• Plugin memulai servis gRPC, dengan Unix socket pada lokasi /var/lib/kubelet/device-plugins/, yang mengimplementasi antarmuka berikut:

  service DevicePlugin {
        // ListAndWatch mengembalikan aliran dari List of Devices
        // Kapanpun Device menyatakan perubahan atau kehilangan Device, ListAndWatch
        // mengembalikan daftar baru
        rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
  
        // Allocate dipanggil saat pembuatan kontainer sehingga Device
        // Plugin dapat menjalankan operasi spesifik perangkat dan menyuruh Kubelet
        // dari operasi untuk membuat Device tersedia di kontainer
        rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
  }
  

• Plugin mendaftarkan dirinya sendiri dengan kubelet melalui Unix socket pada lokasi host /var/lib/kubelet/device-plugins/kubelet.sock.

• Seteleh sukses mendaftarkan dirinya sendiri, plugin perangkat berjalan dalam mode peladen, dan selama itu dia tetap mengawasi kesehatan perangkat dan melaporkan balik ke kubelet terhadap perubahan status perangkat. Dia juga bertanggung jawab untuk melayani request gRPC Allocate. Selama Allocate, plugin perangkat dapat membuat persiapan spesifik-perangkat; contohnya, pembersihan GPU atau inisiasi QRNG. Jika operasi berhasil, plugin perangkat mengembalikan AllocateResponse yang memuat konfigurasi runtime kontainer untuk mengakses perangkat teralokasi. Kubelet memberikan informasi ini ke runtime kontainer.

Menangani kubelet yang restart

Plugin perangkat diharapkan dapat mendeteksi kubelet yang restart dan mendaftarkan dirinya sendiri kembali dengan instance kubelet baru. Pada implementasi sekarang, sebuah instance kubelet baru akan menghapus semua socket Unix yang ada di dalam /var/lib/kubelet/device-plugins ketika dijalankan. Plugin perangkat dapat mengawasi penghapusan socket Unix miliknya dan mendaftarkan dirinya sendiri kembali ketika hal tersebut terjadi.

Deployment plugin perangkat

Kamu dapat melakukan deploy sebuah plugin perangkat sebagai DaemonSet, sebagai sebuah paket untuk sistem operasi node-mu, atau secara manual.

Direktori canonical /var/lib/kubelet/device-plugins membutuhkan akses berprivilese, sehingga plugin perangkat harus berjalan dalam konteks keamanan dengan privilese. Jika kamu melakukan deploy plugin perangkat sebagai DaemonSet, /var/lib/kubelet/device-plugins harus dimuat sebagai Volume pada PodSpec plugin.

Jika kamu memilih pendekatan DaemonSet, kamu dapat bergantung pada Kubernetes untuk meletakkan Pod plugin perangkat ke Node, memulai-ulang Pod daemon setelah kegagalan, dan membantu otomasi pembaruan.

Kecocokan API

Dukungan pada plugin perangkat Kubernetes sedang dalam beta. API dapat berubah hingga stabil, dalam cara yang tidak kompatibel. Sebagai proyek, Kubernetes merekomendasikan para developer plugin perangkat:

• Mengamati perubahan pada rilis mendatang.
• Mendukung versi API plugin perangkat berbeda untuk kompatibilitas-maju/mundur.

Jika kamu menyalakan fitur DevicePlugins dan menjalankan plugin perangkat pada node yang perlu diperbarui ke rilis Kubernetes dengan versi API plugin yang lebih baru, perbarui plugin perangkatmu agar mendukung kedua versi sebelum membarui para node ini. Memilih pendekatan demikian akan menjamin fungsi berkelanjutan dari alokasi perangkat selama pembaruan.

Mengawasi Sumber Daya Plugin Perangkat

Dalam rangka mengawasi sumber daya yang disediakan plugin perangkat, agen monitoring perlu bisa menemukan kumpulan perangkat yang terpakai dalam node dan mengambil metadata untuk mendeskripsikan pada kontainer mana metrik harus diasosiasikan. Metrik prometheus diekspos oleh agen pengawas perangkat harus mengikuti Petunjuk Instrumentasi Kubernetes, mengidentifikasi kontainer dengan label prometheus pod, namespace, dan container.

Kubelet menyediakan servis gRPC untuk menyalakan pencarian perangkat yang terpakai, dan untuk menyediakan metadata untuk perangkat berikut:

// PodResourcesLister adalah layanan yang disediakan kubelet untuk menyediakan informasi tentang
// sumber daya node yang dikonsumsi Pod dan kontainer pada node
service PodResourcesLister {
    rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
}

Servis gRPC dilayani lewat socket unix pada /var/lib/kubelet/pod-resources/kubelet.sock. Agen pengawas untuk sumber daya plugin perangkat dapat di-deploy sebagai daemon, atau sebagai DaemonSet. Direktori canonical /var/lib/kubelet/pod-resources perlu akses berprivilese, sehingga agen pengawas harus berjalan dalam konteks keamanan dengan privilese. Jika agen pengawas perangkat berjalan sebagai DaemonSet, /var/lib/kubelet/pod-resources harus dimuat sebagai Volume pada plugin PodSpec.

Dukungan untuk "servis PodResources" butuh gerbang fitur KubeletPodResources untuk dinyalakan. Mulai dari Kubernetes 1.15 nilai bawaannya telah dinyalakan.

Integrasi Plugin Perangkat dengan Topology Manager

Topology Manager adalah komponen Kubelet yang membolehkan sumber daya untuk dikoordinasi secara selaras dengan Topology. Untuk melakukannya, API Plugin Perangkat telah dikembangkan untuk memasukkan struct TopologyInfo.

message TopologyInfo {
	repeated NUMANode nodes = 1;
}

message NUMANode {
    int64 ID = 1;
}

Plugin Perangkat yang ingin memanfaatkan Topology Manager dapat mengembalikan beberapa struct TopologyInfo sebagai bagian dari pendaftaran perangkat, bersama dengan ID perangkat dan status kesehatan perangkat. Manajer perangkat akan memakai informasi ini untuk konsultasi dengan Topology Manager dan membuat keputusan alokasi sumber daya.

TopologyInfo mendukung kolom nodes yang bisa nil (sebagai bawaan) atau daftar node NUMA. Ini membuat Plugin Perangkat mengumumkan apa saja yang bisa meliputi node NUMA.

Contoh struct TopologyInfo untuk perangkat yang dipopulate oleh Plugin Perangkat:

pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}}

Contoh plugin perangkat

Berikut beberapa contoh implementasi plugin perangkat:

• Plugin perangkat AMD GPU
• Plugin perangkat Intel untuk perangkat GPU, FPGA, dan QuickAssist Intel
• Plugin perangkat KubeVirt untuk virtualisasi hardware-assisted
• Plugin perangkat NVIDIA GPU
  • Perlu nvidia-docker versi 2.0 yang memungkinkan untuk menjalakan kontainer Docker yang memuat GPU.
• Plugin perangkat NVIDIA GPU untuk Container-Optimized OS
• Plugin perangkat RDMA
• Plugin perangkat Solarflare
• Plugin perangkat SR-IOV Network
• Plugin perangkat Xilinx FPGA untuk perangkat Xilinx FPGA

Selanjutnya

• Pelajari bagaimana menjadwalkan sumber daya GPU dengan plugin perangkat
• Pelajari bagaimana mengumumkan sumber daya ekstensi pada node
• Baca tentang penggunaan akselerasi perangkat keras untuk ingress TLS dengan Kubernetes
• Pelajari tentang [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)

4 - Pola Operator

Operator adalah ekstensi perangkat lunak untuk Kubernetes yang memanfaatkan custom resource untuk mengelola aplikasi dan komponen-komponennya. Operator mengikuti prinsip Kubernetes, khususnya dalam hal control loop.

Motivasi

Pola dari Operator bertujuan untuk menangkap tujuan utama dari Operator manusia yang mengelola layanan atau suatu kumpulan layanan. Operator manusia yang menjaga spesifik aplikasi dan layanan memiliki pengetahuan yang mendalam tentang bagaimana sistem harus berperilaku, bagaimana cara menyebarkannya, dan bagaimana bereaksi jika ada masalah.

Orang-orang yang menjalankan workload-workload di Kubernetes pada umumnya suka menggunakan otomatisasi untuk menangani tugas-tugas yang berulang. Pola Operator menangkap bagaimana kamu dapat menulis kode untuk mengotomatiskan sebuah tugas di luar batas apa yang dapat disediakan oleh Kubernetes itu sendiri.

Operator di Kubernetes

Kubernetes didesain untuk otomasi. Secara di luar nalar, kamu mendapatkan banyak otomatisasi bawaan dari komponen inti Kubernetes. Kamu dapat menggunakan Kubernetes untuk mengotomasikan penyebaran dan menjalankan workload-workload, dan kamu juga dapat mengotomasikan cara Kubernetes melakukan pekerjaan itu.

Konsep dari controller Kubernetes memungkinkan kamu memperluas perilaku klaster tanpa harus mengubah kode dari Kubernetes itu sendiri.

Operator adalah klien API dari Kubernetes yang bertindak sebagai controller untuk custome resource.

Contoh Operator

Beberapa hal yang dapat kamu gunakan untuk mengotomasi Operator meliputi:

• menyebarkan aplikasi sesuai dengan permintaan
• mengambil dan memulihkan backup status dari sebuah aplikasi
• menangani pembaruan kode aplikasi termasuk dengan perubahan terkait seperti skema basis data atau pengaturan konfigurasi tambahan
• mempublikasikan layanan ke sebuah aplikasi yang tidak mendukung API Kubernetes untuk menemukan mereka
• mensimulasikan kegagalan pada seluruh atau sebagian klaster kamu untuk menguji resiliensinya
• memilih suatu pemimpin untuk aplikasi yang terdistribusi tanpa adanya proses pemilihan anggota secara internal

Seperti apa sebuah Operator dalam kasus yang lebih terperinci? Berikut ini adalah contoh yang lebih detail:

1. Sebuah custom resource bernama SampleDB, bisa kamu konfigurasi ke dalam klaster.
2. Sebuah Deployment memastikan sebuah Pod berjalan dimana didalamnya berisi bagian controller dari Operator.
3. Kontainer Image dari kode Operator.
4. Kode controller yang menanyakan pada control-plane untuk mencari tahu apakah itu sumber daya SampleDB telah dikonfigurasi.
5. Inti dari Operator adalah kode untuk memberi tahu server API bagaimana membuatnya kondisi sebenarnya sesuai dengan sumber daya yang dikonfigurasi.    * Jika kamu menambahkan SampleDB baru, Operator menyiapkan PersistentVolumeClaims untuk menyediakan penyimpanan basis data yang tahan lama, sebuah StatefulSet untuk menjalankan SampleDB dan pekerjaan untuk menangani konfigurasi awal.    * Jika kamu menghapusnya, Operator mengambil snapshot, lalu memastikannya      StatefulSet dan Volume juga dihapus.
6. Operator juga mengelola backup basis data yang reguler. Untuk setiap resource SampleDB, Operator menentukan kapan membuat Pod yang dapat terhubung    ke database dan mengambil backup. Pod-Pod ini akan bergantung pada ConfigMap    dan / atau sebuah Secret yang memiliki basis data koneksi dan kredensial.
7. Karena Operator bertujuan untuk menyediakan otomatisasi yang kuat untuk resource yang dikelola, maka akan ada kode pendukung tambahan. Sebagai contoh , kode memeriksa untuk melihat apakah basis data menjalankan versi yang lama dan, jika demikian, kode membuat objek Job yang melakukan pembaruan untuk kamu.

Menyebarkan Operator

Cara paling umum untuk menyebarkan Operator adalah dengan menambahkan CustomResourceDefinition dan controller yang berkaitan ke dalam klaster kamu. Controller biasanya akan berjalan di luar control plane, seperti kamu akan menjalankan aplikasi apa pun yang dikontainerisasi. Misalnya, kamu bisa menjalankan controller di klaster kamu sebagai sebuah Deployment.

Menggunakan Operator {#menggunakan operator}

Setelah Operator disebarkan, kamu akan menggunakannya dengan menambahkan, memodifikasi, atau menghapus jenis sumber daya yang digunakan Operator tersebut. Melanjutkan contoh diatas, kamu akan menyiapkan Deployment untuk Operator itu sendiri, dan kemudian:

kubectl get SampleDB                   # find configured databases

kubectl edit SampleDB/example-database # manually change some settings

…dan itu saja! Operator akan berhati-hati dalam menerapkan perubahan serta menjaga layanan yang ada dalam kondisi yang baik.

Menulis Operator Kamu Sendiri

Jika tidak ada Operator dalam ekosistem yang mengimplementasikan perilaku kamu inginkan, kamu dapat kode kamu sendiri. Dalam Selanjutnya kamu akan menemukan beberapa tautan ke library dan perangkat yang dapat kamu gunakan untuk menulis Operator Cloud Native kamu sendiri.

Kamu juga dapat mengimplementasikan Operator (yaitu, Controller) dengan menggunakan bahasa / runtime yang dapat bertindak sebagai klien dari API Kubernetes.

Selanjutnya

• Memahami lebih lanjut tentang custome resources
• Temukan "ready-made" operators dalam OperatorHub.io untuk memenuhi use case kamu
• Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya:
  • menggunakan KUDO (Kubernetes Universal Declarative Operator)
  • menggunakan kubebuilder
  • menggunakan Metacontroller bersama dengan WebHooks yang kamu implementasikan sendiri
  • menggunakan the Operator Framework
• Terbitkan Operator kamu agar dapat digunakan oleh orang lain
• Baca artikel asli dari CoreOS yang memperkenalkan pola Operator
• Baca sebuah artikel dari Google Cloud soal panduan terbaik membangun Operator

5 - Service Catalog

Service Catalog adalah sebuah ekstensi API yang memungkinkan aplikasi berjalan pada klaster Kubernetes untuk mempermudah penggunaan perangkat lunak yang dikelola eksternal, seperti servis penyimpanan data yang ditawarkan oleh penyedia layanan komputasi awan.

Ini menyediakan cara untuk membuat daftar, melakukan pembuatan, dan mengikat dengan servis terkelola eksternal dari makelar servis tanpa membutuhkan pengetahuan mendalam mengenai cara servis tersebut dibuat dan diatur.

Sebuah makelar servis (service broker), seperti yang didefinisikan oleh [spesifikasi API makelar servis terbuka] (https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), adalah sebuah endpoint untuk beberapa layanan terkelola yang ditawarkan dan dikelola oleh pihak ketiga, yang bisa jadi sebuah penyedia layanan cloud seperti AWS, GCP atau Azure.

Beberapa contoh dari servis terkelola adalah Microsoft Azure Cloud Queue, Amazon Simple Queue Service, dan Google Cloud Pub/Sub, selain itu, bisa juga penawaran perangkat lunak apa pun yang dapat digunakan oleh suatu aplikasi.

Dengan menggunakan Service Catalog, seorang pengelola klaster dapat melihat daftar servis terkelola yang ditawarkan oleh makelar servis, melakukan pembuatan terhadap sebuah servis terkelola, dan menghubungkan (bind) untuk membuat tersedia terhadap aplikasi pada suatu klaster Kubernetes.

Contoh kasus penggunaan

Seorang pengembang aplikasi ingin menggunakan sistem antrian pesan sebagai bagian dari aplikasinya yang berjalan dalam klaster Kubernetes. Namun, mereka tidak ingin berurusan dengan kesulitan dalam pengaturan, misalnya menjaga servis tetap berjalan dan mengatur itu oleh mereka sendiri. Beruntungnya, sudah tersedia penyedia layanan cloud yang menawarkan sistem antrian pesan sebagai servis terkelola melalui makelar servisnya.

Seorang pengelola klaster dapat membuat Service Catalog dan menggunakannya untuk berkomunikasi dengan makelar servis milik penyedia layanan cloud untuk menyediakan sebuah servis antrian pesan dan membuat servis ini tersedia kepada aplikasi dalam klaster Kubernetes. Seorang pengembang aplikasi tidak perlu memikirkan detail implementasi atau mengatur sistem antrian pesan tersebut. Aplikasi dapat langsung menggunakan servis tersebut.

Arsitektur

Service Catalog menggunakan API dari Open Service Broker untuk berkomunikasi dengan makelar servis, bertindak sebagai perantara untuk API Server Kubernetes untuk merundingkan penyediaan awal dan mengambil kredensial untuk aplikasi bisa menggunakan servis terkelola tersebut.

Ini terimplementasi sebagai ekstensi API Server dan pengontrol, menggunakan etcd sebagai media penyimpanan. Ini juga menggunakan lapisan agregasi yang tersedia pada Kubernetes versi 1.7+ untuk menampilkan API-nya.

Sumber Daya API

Service Catalog memasang API servicecatalog.k8s.io dan menyediakan beberapa sumber daya Kubernetes berikut:

• ClusterServiceBroker: Sebuah representasi dalam klaster untuk makelar servis, membungkus detail koneksi peladen. Ini dibuat dan dikelola oleh pengelola klaster yang berharap untuk menggunakan makelar peladen untuk membuat tipe baru dari sebuah servis terkelola yang tersedia dalam klaster mereka.
• ClusterServiceClass: Sebuah servis terkelola ditawarkan oleh beberapa makelar servis. Ketika sumber daya ClusterServiceBroker ditambahkan ke dalam klaster, kontroler Service Catalog terhubung ke makelar servis untuk mendapatkan daftar servis terkelola yang tersedia. Kemudian membuat sumber daya ClusterServiceClass sesuai dengan masing-masing servis terkelola.
• ClusterServicePlan: Sebuah penawaran khusus dari servis terkelola. Sebagai contoh, sebuah servis terkelola bisa memiliki model harga, yaitu gratis atau berbayar, atau ini mungkin juga memiliki konfigurasi pilihan berbeda, misal menggunakan penyimpanan SSD atau memiliki sumber daya lebih. Mirip dengan ClusterServiceClass, ketika ClusterServiceBroker baru ditambahkan ke dalam klaster, Service Catalog akan membuat sumber daya ClusterServicePlan sesuai dengan Service Plan yang tersedia untuk masing-masing servis terkelola.
• ServiceInstance: Sebuah objek dari ClusterServiceClass. Ini dibuat oleh operator klaster untuk membuat bentuk spesifik dari servis terkelola yang tersedia untuk digunakan oleh salah satu atau lebih aplikasi dalam klaster. Ketika sumber daya ServiceInstance baru terbuat, pengontrol Service Catalog terhubung ke makelar servis yang sesuai dan menginstruksikan untuk menyediakan sebuah objek servis.
• ServiceBinding: Kredensial untuk mengakses suatu ServiceInstance. Ini dibuat oleh operator klaster yang ingin aplikasinya untuk menggunakan sebuah ServiceInstance. Saat dibuat, kontroler Service Catalog membuat sebuah Secret Kubernetes yang berisikan detail koneksi dan kredensial untuk objek servis, yang bisa dimuat ke dalam Pod.

Autentikasi

Service Catalog mendukung beberapa metode autentikasi, yaitu:

• Basic (nama pengguna/kata sandi)
• OAuth 2.0 Bearer Token

Penggunaan

Seorang operator klaster dapat menggunakan API sumber daya Service Catalog untuk membuat servis terkelola dan membuatnya tersedia dalam klaster Kubernetes. Langkah yang dilalui adalah sebagai berikut:

1. Membuat daftar servis terkelola dan model pembayaran yang tersedia dari makelar servis.
2. Membuat sebuah objek dari suatu servis terkelola.
3. Menghubungkan ke servis terkelola, yang mengembalikan kredensial koneksi.
4. Memetakan kredensial koneksi ke dalam aplikasi.

Membuat daftar servis terkelola dan model pembayaran

Pertama, seorang operator klaster harus membuat sumber daya ClusterServiceBroker dalam kelompok servicecatalog.k8s.io. Sumber daya ini memiliki URL dan detail koneksi untuk mengakses makelar servis.

Ini ada contoh dari suatu sumber daya ClusterServiceBroker:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ClusterServiceBroker
metadata:
  name: cloud-broker
spec:
  # Merujuk pada titik akhir dari makelar servis. (Ini adalah contoh URL yang tidak nyata)
  url:  https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
  #####
  # Nilai tambahan dapat ditambahkan disini, yang mungkin bisa digunakan untuk berkomunikasi
  # dengan makelar servis, misalnya saja informasi bearer token atau sebuah caBundle untuk TLS.
  #####

Berikut adalah sebuah diagram urutan yang mengilustrasikan langkah-langkah dalam mendaftarkan servis terkelola dan model pembayaran yang tersedia dari makelar servis:

1. Setelah sumber daya ClusterServiceBroker ditambahkan ke dalam Service Catalog, ini membuat panggilan makelar servis luar untuk membuat daftar servis yang tersedia.

2. Makelar servis akan mengembalikan daftar servis terkelola yang tersedia dan daftar model pembayaran, yang akan disimpan sementara sebagai ClusterServiceClass dan ClusterServicePlan.

3. Seorang operator klaster bisa mendapatkan daftar servis terkelola dengan menggunakan perintah berikut ini:

    kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
   

   Itu seharusnya memberikan daftar nama servis dengan format yang mirip dengan berikut:

    SERVICE NAME                           EXTERNAL NAME
    4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468   cloud-provider-service
    ...                                    ...
   

   Mereka juga dapat melihat model pembayaran yang tersedia menggunakan perintah berikut:

    kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
   

   Itu seharusnya memberikan daftar nama model pembayaran dengan format mirip dengan berikut:

    PLAN NAME                              EXTERNAL NAME
    86064792-7ea2-467b-af93-ac9694d96d52   service-plan-name
    ...                                    ...
   

Pembuatan sebuah objek

Seorang operator klaster dapat memulai pembuatan sebuah objek dengan membuat sumber daya ServiceInstance.

Ini adalah contoh dari sumber daya ServiceInstance:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
  name: cloud-queue-instance
  namespace: cloud-apps
spec:
  # Referensi untuk salah satu servis yang pernah dikembalikan
  clusterServiceClassExternalName: cloud-provider-service
  clusterServicePlanExternalName: service-plan-name
  #####
  # Parameter tambahan dapat ditambahkan disini,
  # yang mungkin akan digunakan oleh makelar servis.
  #####

Berikut adalah diagram urutan yang mengilustrasikan langkah-langkah dalam pembuatan sebuah objek dari servis terkelola:

1. Ketika sumber daya ServiceInstance sudah terbuat, Service Catalog memulai pemanggilan ke makelar servis luar untuk membuat sebuah objek dari suatu servis.
2. Makelar servis membuat sebuah objek baru dari suatu servis terkelola dan mengembalikan sebuah respons HTTP.
3. Seorang operator klaster dapat mengecek status dari objek untuk melihat apakah sudah siap atau belum.

Menghubungkan ke servis terkelola

Setelah sebuah objek terbuat, klaster operator harus menghubungkan ke servis terkelola untuk mendapatkan kredensial koneksi dan detail pengguna servis untuk aplikasi bisa mengguakan servis tersebut. Ini dilakukan dengan membuat sebuah sumber daya ServiceBinding.

Berikut adalah contoh dari sumber daya ServiceBinding:

apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: cloud-queue-binding
  namespace: cloud-apps
spec:
  instanceRef:
    name: cloud-queue-instance
  #####
  # Informasi tambahan dapat ditambahkan disini, seperti misalnya secretName atau
  # parameter pengguna servis, yang mungkin akan digunakan oleh makelar servis.
  #####

Berikut ada diagram urutan yang mengilustrasikan langkah-langkah dalam menghubungkan objek servis terkelola.

1. Setelah ServiceBinding terbuat, Service Catalog memanggil makelar servis luar untuk meminta informasi yang dibutuhkan untuk terhubung dengan objek servis.
2. Makelar servis memberikan izin atau peran kepada aplikasi sesuai dengan pengguna servis.
3. Makelar servis mengembalikan informasi untuk bisa terhubung dan mengakses servis terkelola. Ini tergantung pada penyedia layanan dan servis, sehingga informasi yang dikembalikan mungkin berbeda antara suatu penyedia layanan dan servis terkelolanya.

Memetakan kredensial koneksi

Setelah menghubungkan, langkah terakhir melibatkan pemetaan kredensial koneksi dan informasi spesifik mengenai servis kedalam aplikasi. Informasi ini disimpan dalam Secrets yang mana aplikasi dalam klaster dapat mengakses dan menggunakan untuk bisa terkoneksi secara langsung dengan servis terkelola.

Berkas konfigurasi Pod

Salah satu metode untuk melakukan pemetaan ini adalah dengan menggunakan deklarasi konfigurasi Pod.

Berikut adalah contoh yang mendekripsikan bagaimana pemetaan kredensial pengguna servis ke dalam aplikasi. Sebuah kunci yang disebut sa-key disimpan dalam media bernama provider-cloud-key, dan aplikasi memasang media ini pada /var/secrets/provider/key.json. Environment variable PROVIDER_APPLICATION_CREDENTIALS dipetakan dari nilai pada berkas yang dipasang.

...
    spec:
      volumes:
        - name: provider-cloud-key
          secret:
            secretName: sa-key
      containers:
...
          volumeMounts:
          - name: provider-cloud-key
            mountPath: /var/secrets/provider
          env:
          - name: PROVIDER_APPLICATION_CREDENTIALS
            value: "/var/secrets/provider/key.json"

Berikut adalah contoh yang mendeskripsikan cara memetakan nilai rahasia ke dalam environment variable aplikasi. Dalam contoh ini, nama topik dari sistem antrian pesan dipetakan dari secret bernama provider-queue-credentials dengan nama topic ke dalam environment variable TOPIC.

...
          env:
          - name: "TOPIC"
            valueFrom:
                secretKeyRef:
                   name: provider-queue-credentials
                   key: topic

Selanjutnya

• Jika kamu terbiasa dengan Helm Charts, pasang Service Catalog menggunakan Helm ke dalam klaster Kubernetes. Alternatif lain, kamu dapat memasang Service Catalog dengan SC tool.
• Lihat contoh makelar servis.
• Pelajari mengenai kubernetes-incubator/service-catalog proyek.
• Lihat svc-cat.io.

6 - Poseidon-Firmament - Sebuah Penjadwal Alternatif

Rilis saat ini dari Penjadwal Poseidon-Firmament adalah rilis alpha .

Penjadwal Poseidon-Firmament adalah penjadwal alternatif yang dapat digunakan bersama penjadwal Kubernetes bawaan.

Pengenalan

Poseidon adalah sebuah layanan yang berperan sebagai pemersatu antara Penjadwal Firmament dengan Kubernetes. Penjadwal Poseidon-Firmament menambah kapabilitas penjadwal Kubernetes saat ini. Penjadwal ini menggabungkan kemampuan penjadwalan berbasis grafik jaringan grafis (flow network graph) baru bersama penjadwal Kubernetes bawaan. Penjadwal Firmament memodelkan beban-beban kerja dan klaster-klaster sebagai jaringan aliran dan menjalankan optimisasi aliran biaya-minimum kepada jaringan ini untuk membuat keputusan penjadwalan.

Penjadwal ini memodelkan masalah penjadwalan sebagai optimasi berbasis batasan atas grafik jaringan aliran. Hal ini dicapai dengan mengurangi penjadwalan ke masalah optimisasi biaya-minimum aliran-maksimum. Penjadwal Poseidon-Firmament secara dinamis memperbaiki penempatan beban kerja.

Penjadwal Poseidon-Firmament berjalan bersamaan dengan penjadwal Kubernetes bawaan sebagai penjadwal alternatif, sehingga beberapa penjadwal dapat berjalan secara bersamaan.

Keuntungan Utama

Penjadwalan grafik jaringan (network graph) berbasis penjadwalan Poseidon-Firmament memberikan beberapa keuntungan utama sebagai berikut:

• Beban kerja (Pod) dijadwalkan secara kolektif untuk memungkinkan penjadwalan dalam skala besar.
• Berdasarkan hasil tes kinerja yang ekstensif, skala Poseidon-Firmament jauh lebih baik daripada penjadwal bawaan Kubernetes dilihat dari jumlah node meningkat dalam sebuah klaster. Hal ini disebabkan oleh fakta bahwa Poseidon-Firmament mampu mengamortisasi lebih banyak pekerjaan di seluruh beban kerja.
• Penjadwal Poseidon-Firmament mengungguli penjadwal bawaan Kubernetes dengan margin lebar ketika menyangkut jumlah kinerja throughput untuk skenario di mana kebutuhan sumber daya komputasi agak seragam di seluruh pekerjaan (Replicaset / Deployment / Job). Angka kinerja throughput end-to-end penjadwal Poseidon-Firmament , termasuk waktu bind, secara konsisten menjadi lebih baik seiring jumlah Node dalam sebuah klaster meningkat. Misalnya, untuk klaster 2.700 Node (ditampilkan dalam grafik di sini), penjadwal Poseidon-Firmament berhasil mencapai 7X atau lebih throughput end-to-end yang lebih besar dibandingkan dengan penjadwal bawaan Kubernetes, yang mencakup waktu bind.
• Tersedianya pembatasan aturan yang kompleks.
• Penjadwalan dalam Poseidon-Firmament bersifat dinamis; ini membuat sumber daya klaster dalam keadaan optimal secara global selama setiap berjalannya penjadwalan.
• Pemanfaatan sumber daya yang sangat efisien.

Penjadwal Poseidon-Firmament - Bagaimana cara kerjanya

Sebagai bagian dari pendukung penjadwal-penjadwal Kubernetes, setiap Pod baru biasanya dijadwalkan oleh penjadwal bawaan. Kubernetes dapat diinstruksikan untuk menggunakan penjadwal lain dengan menentukan nama penjadwal custom lain ("poseidon" dalam kasus ini) di field schedulerName dari PodSpec pada saat pembuatan pod. Dalam kasus ini, penjadwal bawaan akan mengabaikan Pod itu dan memungkinkan penjadwal Poseidon untuk menjadwalkan Pod pada Node yang relevan.

apiVersion: v1
kind: Pod

...
spec:
  schedulerName: poseidon

Kemungkinan Skenario Kasus Penggunaan - Kapan menggunakannya

Seperti yang disebutkan sebelumnya, penjadwal Poseidon-Firmament memungkinkan lingkungan penjadwalan dengan throughput yang sangat tinggi bahkan pada ukuran klaster dengan beban kerja besar, dikarenakan pendekatan penjadwalannya yang sekaligus dalam jumlah besar, dibandingkan dengan pendekatan bawaan pod-at-a-time Kubernetes. Dalam pengujian ekstensif kami, kami telah mengamati manfaat throughput substansial selama kebutuhan sumber daya (CPU / Memori) untuk Pod yang masuk seragam di seluruh tugas (Replicaset / Deployment / Job), terutama karena amortisasi pekerjaan yang efisien di seluruh tugas.

Meskipun penjadwal Poseidon-Firmament mampu menjadwalkan berbagai jenis beban kerja, seperti layanan-layanan, batch, dll., berikut ini adalah beberapa kasus penggunaan yang paling unggul:

1. Untuk pekerjaan "Big Data / AI" yang terdiri dari sejumlah besar tugas, manfaat dari throughput luar biasa.
2. Pekerjaan layanan atau batch job di mana kebutuhan sumber dayanya seragam di seluruh pekerjaan (Replicaset / Deployment / Job).

Tahap Proyek Saat Ini

• Rilis Alpha - Repo Inkubasi. di https://github.com/kubernetes-sigs/poseidon.
• Saat ini, penjadwal Poseidon-Firmament tidak memberikan dukungan untuk ketersediaan tinggi, implementasi kami mengasumsikan bahwa penjadwal tidak mungkin gagal. Dokumen desain menjelaskan cara-cara yang memungkinkan untuk mengaktifkan ketersediaan tinggi, tetapi kami membiarkannya untuk pekerjaan mendatang.
• Kami tidak mengetahui adanya production deployment dari penjadwal Poseidon-Firmament saat ini.
• Poseidon-Firmament didukung dari rilis Kubernetes 1.6 dan bekerja dengan semua rilis berikutnya.
• Proses rilis untuk repo Poseidon dan Firmament berjalan secara serentak. Rilis Poseidon saat ini dapat ditemukan di sini dan rilis Firmament yang sesuai dapat ditemukan di sini.

Matriks Perbandingan Fitur

Instalasi

Untuk instalasi Poseidon dalam-klaster, silakan mulai dari Petunjuk Instalasi.

Pengembangan

Untuk developer, silakan merujuk ke Instruksi Setup Developer.

Hasil Pengujian Kinerja Throughput Terbaru

Penjadwal pod-by-pod, seperti penjadwal bawaan Kubernetes, biasanya memproses satu Pod pada satu waktu. Penjadwal ini memiliki kelemahan penting berikut:

1. Penjadwal berkomitmen untuk penempatan Pod lebih awal dan membatasi pilihan untuk Pod lain yang menunggu untuk ditempatkan.
2. Ada peluang terbatas untuk amortisasi pekerjaan lintas Pod karena mereka dipertimbangkan untuk ditempatkan secara individual.

Kelemahan dari penjadwal pod-by-pod ini diatasi dengan penjadwalan secara terkumpul atau dalam jumlah banyak secara bersamaan di penjadwal Poseidon-Firmament. Memproses beberapa Pod dalam satu kumpulan memungkinkan penjadwal untuk bersama-sama mempertimbangkan penempatan mereka, dan dengan demikian untuk menemukan untung-rugi terbaik untuk seluruh kumpulan ketimbang satu Pod saja. Pada saat yang sama, amortisasi berfungsi lintas Pod yang menghasilkan throughput yang jauh lebih tinggi.