Mempelajari Panduan Dasar Kubernetes

Konsep

Edit This Page

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 klasterSeseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster. yang ingin memahami bagaimana menyesuaikan klaster Kubernetes dengan kebutuhan lingkungan kerja mereka.

Developer yang prospektif Developer PlatformSeseorang yang menyesuaikan platform Kubernetes agar sesuai dengan kebutuhan proyek mereka. atau KontributorSeseorang yang menyumbangkan kode, dokumentasi, atau waktu mereka untuk membantu proyek atau komunitas Kubernetes. 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:

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

Masukan