Cara kerja Kubernetes
Penginstalan Kubernetes yang berhasil dikonfigurasi bergantung pada pemahaman yang solid tentang arsitektur sistem Kubernetes. Di sini, Anda akan melihat semua komponen yang membentuk penginstalan Kubernetes.
Apa itu kluster komputer?
Kluster adalah sekumpulan komputer yang Anda konfigurasi untuk bekerja sama dan melihat sebagai satu sistem. Komputer yang dikonfigurasi dalam kluster menangani jenis tugas yang sama. Misalnya, mereka semua akan menghost situs web, API, atau menjalankan pekerjaan intensif komputasi.
Kluster menggunakan perangkat lunak terpusat yang bertanggung jawab untuk menjadwalkan dan mengontrol tugas-tugas ini. Komputer dalam kluster yang menjalankan tugas disebut node, dan komputer yang menjalankan perangkat lunak penjadwalan disebut bidang kontrol.
Arsitektur Kubernetes
Ingat dari sebelumnya bahwa orkestrator adalah sistem yang menyebarkan dan mengelola aplikasi. Anda juga mempelajari bahwa kluster adalah sekumpulan komputer yang bekerja sama dan dilihat sebagai sistem tunggal. Anda menggunakan Kubernetes sebagai perangkat lunak orkestrasi dan kluster untuk menyebarkan aplikasi dan merespons perubahan kebutuhan sumber daya komputasi.
Kluster Kubernetes berisi setidaknya satu pesawat utama dan satu atau beberapa node. Baik bidang kontrol dan instans node dapat menjadi perangkat fisik, mesin virtual, atau instans di cloud. OS host default di Kubernetes adalah Linux, dengan dukungan default untuk beban kerja berbasis Linux.
Anda juga dapat menjalankan beban kerja Microsoft dengan menggunakan Windows Server 2019 atau yang lebih baru pada node kluster. Misalnya, asumsikan bahwa layanan pemrosesan data di aplikasi pelacakan drone ditulis sebagai aplikasi .NET 4.5 yang menggunakan panggilan WINDOWS OS API tertentu. Layanan ini hanya dapat berjalan pada node yang menjalankan OS Windows Server.
Sekarang, lihat sarana kontrol dan simpul pekerja dan perangkat lunak yang berjalan pada masing-masing secara lebih rinci. Memahami peran masing-masing komponen dan di mana setiap komponen berjalan di kluster membantu Anda dalam hal menginstal Kubernetes.
Pesawat kontrol Kubernetes
Pesawat kontrol Kubernetes dalam kluster Kubernetes menjalankan koleksi layanan yang mengelola fungsi orkestrasi di Kubernetes.
Dari perspektif pembelajaran, masuk akal untuk menggunakan satu pesawat kontrol di lingkungan pengujian saat Anda mengeksplorasi fungsionalitas Kubernetes. Namun, dalam penyebaran produksi dan cloud seperti Azure Kubernetes Service (AKS), Anda menemukan bahwa konfigurasi yang disukai adalah penyebaran ketersediaan tinggi dengan tiga hingga lima sarana kontrol yang direplikasi.
Catatan
Fakta bahwa pesawat kontrol menjalankan perangkat lunak tertentu untuk mempertahankan keadaan kluster tidak mengecualikannya dari menjalankan beban kerja komputasi lainnya. Namun, Anda biasanya ingin mengecualikan pesawat kontrol agar tidak menjalankan beban kerja non-kritis dan aplikasi pengguna.
Node Kubernetes
Sebuah node dalam kluster Kubernetes adalah tempat beban kerja komputasi anda berjalan. Setiap node berkomunikasi dengan pesawat kontrol melalui API server untuk menginformasikannya tentang perubahan status pada node.
Layanan yang berjalan pada pesawat kontrol
Kubernetes mengandalkan beberapa layanan administratif yang berjalan pada pesawat kontrol. Layanan ini mengelola aspek-aspek seperti komunikasi komponen kluster, penjadwalan beban kerja, dan persistensi status kluster.
Layanan berikut membentuk sarana kontrol kluster Kubernetes:
- Server API
- Toko latar
- Scheduler
- Manajer pengontrol
- Manajer pengontrol cloud
Apa itu API server?
Anda dapat menganggap server API sebagai ujung depan ke sarana kontrol kluster Kubernetes Anda. Semua komunikasi antar komponen di Kubernetes dilakukan melalui API ini.
Misalnya, sebagai pengguna, Anda menggunakan aplikasi baris perintah yang disebut kubectl yang memungkinkan Anda menjalankan perintah terhadap server API kluster Kubernetes. Komponen yang menyediakan API ini disebut kube-apiserver, dan Anda dapat menerapkan beberapa instans komponen ini untuk mendukung penskalaan di kluster Anda.
API ini memaparkan API RESTful yang dapat Anda gunakan untuk memposting perintah atau file konfigurasi berbasis YAML. YAML adalah standar serialisasi data yang dapat dibaca manusia untuk bahasa pemrograman. Anda menggunakan berkas YAML untuk mendefinisikan keadaan yang dimaksudkan dari semua objek dalam kluster Kubernetes.
Misalnya, asumsikan bahwa Anda ingin meningkatkan jumlah instans aplikasi Anda di kluster. Anda menentukan status baru dengan file berbasis YAML dan mengirimkan file ini ke server API. Server API memvalidasi konfigurasi, menyimpannya ke kluster, dan akhirnya memberlakukan peningkatan penyebaran aplikasi yang dikonfigurasi.
Apa itu backing store?
Penyimpanan backing adalah penyimpanan persisten di mana kluster Kubernetes Menyimpan konfigurasi yang telah selesai. Kubernetes menggunakan toko bernilai kunci tinggi, terdistribusi, dan andal yang disebut etcd. Toko utama ini menyimpan status saat ini dan status yang diinginkan dari semua objek dalam kluster Anda.
Dalam kluster Kubernetes produksi, panduan resmi Kubernetes adalah untuk memiliki tiga hingga lima instans etcd replikasi dari database untuk ketersediaan tingkat tinggi.
Catatan
etcd tidak bertanggung jawab atas pencadangan data. Anda bertanggung jawab untuk memastikan bahwa rencana pencadangan yang efektif ada untuk mencadangkan etcd data.
Apa itu penjadwal?
Penjadwal adalah komponen yang bertanggung jawab atas penugasan beban kerja di semua node. Penjadwal memantau kluster untuk kontainer yang baru dibuat dan menetapkannya ke simpul.
Apa manajer pengontrol?
Manajer pengontrol meluncurkan dan memantau pengontrol yang dikonfigurasi untuk kluster melalui API server.
Kubernetes menggunakan pengontrol untuk melacak status objek dalam kluster. Setiap pengontrol berjalan dalam perulangan yang tidak menentukan saat menonton dan merespons peristiwa di kluster. Misalnya, ada pengontrol untuk memantau node, kontainer, dan endpoint.
Pengontrol berkomunikasi dengan server API untuk menentukan status objek. Jika status saat ini berbeda dari status objek yang diinginkan, pengontrol mengambil tindakan untuk memastikan status yang diinginkan.
Misalkan salah satu dari tiga kontainer yang berjalan di kluster Anda berhenti merespons dan gagal. Dalam hal ini, pengontrol memutuskan apakah Anda perlu meluncurkan kontainer baru untuk memastikan bahwa aplikasi Anda selalu tersedia. Jika keadaan yang diinginkan adalah menjalankan tiga kontainer kapan saja, maka kontainer baru dijadwalkan untuk dijalankan.
Apa itu manajer pengontrol cloud?
Manajer pengontrol cloud terintegrasi dengan teknologi cloud yang mendasarinya di kluster Anda saat kluster berjalan di lingkungan cloud. Layanan ini dapat memuat penyeimbang, antrean, dan penyimpanan, misalnya.
Layanan yang berjalan pada node
Ada beberapa layanan yang berjalan pada Kube untuk mengontrol cara beban kerja berjalan.
Layanan berikut berjalan pada node Kubernetes:
- Kubelet
- Proksi Kube
- Runtime kontainer
Apa itu kubelet?
Kubelet adalah agen yang berjalan pada setiap simpul dalam kluster dan memantau permintaan kerja dari server API. Ini memastikan bahwa unit kerja yang diminta berjalan dan sehat.
Kubelet memantau simpul dan memastikan bahwa kontainer yang dijadwalkan pada setiap simpul berjalan seperti yang diharapkan. Kubelet hanya mengelola kontainer yang dibuat Kubernetes. Tidak bertanggung jawab untuk menjadwal ulang pekerjaan untuk berjalan pada node lain jika node saat ini tidak dapat menjalankan pekerjaan.
Apa itu kube-proxy?
Komponen kube-proxy bertanggung jawab atas jaringan kluster lokal, dan berjalan pada setiap node. Ini memastikan bahwa setiap node memiliki alamat IP yang unik. Ini juga menerapkan aturan untuk menangani perutean dan keseimbangan beban lalu lintas dengan menggunakan iptable dan IPVS.
Proksi ini tidak menyediakan layanan DNS dengan sendirinya. Add-on kluster DNS berdasarkan CoreDNS disarankan dan diinstal secara default.
Apa itu runtime kontainer?
Runtime kontainer adalah perangkat lunak yang mendasari yang menjalankan kontainer pada kluster Kubernetes. Runtime bertanggung jawab untuk mengambil, memulai, dan menghentikan gambar kontainer. Kubernetes mendukung beberapa runtime kontainer, termasuk namun tidak terbatas pada Docker, containerd, rkt, CRI-O, dan frakti. Dukungan untuk banyak jenis runtime kontainer didasarkan pada Container Runtime Interface (CRI). CRI adalah desain plug-in yang memungkinkan kubelet berkomunikasi dengan runtime kontainer yang tersedia.
Runtime kontainer default di AKS adalah kontainer, runtime kontainer standar industri.
Berinteraksi dengan kluster Kubernetes
Kubernetes menyediakan alat garis komando yang dipanggil kubectl untuk mengelola kluster. Anda menggunakan kubectl untuk mengirim perintah ke sarana kontrol kluster atau mengambil informasi tentang semua objek Kubernetes melalui server API.
kubectl menggunakan file konfigurasi yang menyertakan informasi konfigurasi berikut:
- Konfigurasi kluster menentukan nama kluster, informasi sertifikat, dan titik akhir API layanan yang terkait dengan kluster. Definisi ini memungkinkan Anda untuk terhubung dari satu stasiun kerja ke beberapa kluster.
- Konfigurasi pengguna menentukan pengguna dan tingkat izin mereka saat mereka mengakses kluster yang dikonfigurasi.
- Grup konfigurasi Context mengelompokkan dan pengguna dengan menggunakan nama yang bersahabat. Misalnya, Anda mungkin memiliki "dev-cluster" dan "prod-cluster" untuk mengidentifikasi kluster pengembangan dan produksi Anda.
Anda dapat mengonfigurasi kubectl untuk menyambungkan ke beberapa kluster dengan menyediakan konteks yang benar sebagai bagian dari sintaksis baris perintah.
Pod Kubernetes
Sebuah pod mewakili satu instans dari aplikasi yang berjalan di Kubernetes. Beban kerja yang Anda jalankan di Kubernetes adalah aplikasi kontainer. Tidak seperti di lingkungan Docker, Anda tidak dapat menjalankan kontainer langsung di Kubernetes. Anda mengemas kontainer ke dalam objek Kubernetes yang disebut pod. Sebuah pod adalah objek terkecil yang dapat Anda buat di Kubernetes.
Satu pod dapat menampung satu atau beberapa kontainer. Namun, sebuah pod biasanya tidak berisi kelipatan dari aplikasi yang sama.
Sebuah pod mencakup informasi tentang penyimpanan bersama dan konfigurasi jaringan dan spesifikasi tentang cara menjalankan kontainer kemasannya. Anda menggunakan template pod untuk menentukan informasi tentang pod yang berjalan di kluster Anda. Template pod adalah file berkode YAML yang digunakan kembali dan disertakan dalam objek lain untuk mengelola penyebaran pod.
Misalnya, Anda ingin menyebarkan situs web ke kluster Kubernetes. Anda membuat file definisi pod yang menentukan gambar dan konfigurasi kontainer aplikasi. Selanjutnya, Anda menyebarkan berkas definisi pod ke Kubernetes.
Tidak mungkin aplikasi web memiliki situs web sebagai satu-satunya komponen dalam solusi. Aplikasi web biasanya memiliki semacam toko data dan elemen pendukung lainnya. pod Kubernetes juga dapat berisi lebih dari satu kontainer.
Misalnya situs Anda menggunakan database. Situs web dikemas dalam wadah utama, dan database dikemas dalam wadah pendukung. Beberapa kontainer berkomunikasi satu sama lain melalui lingkungan. Kontainer ini mencakup layanan untuk OS host, tumpukan jaringan, namespace layanan kernel, memori bersama, dan volume penyimpanan. Pod adalah lingkungan sandbox yang menyediakan semua layanan ini ke aplikasi Anda. Pod juga memungkinkan kontainer untuk berbagi alamat IP yang ditetapkan.
Karena Anda berpotensi membuat banyak pod yang berjalan di banyak node, mungkin sulit untuk mengidentifikasinya. Anda dapat mengenali dan mengelompokkan pod dengan menggunakan label string yang Anda tentukan saat menentukan pod.
Siklus hidup sebuah pod Kubernetes
Pod Kubernetes memiliki siklus hidup berbeda yang mempengaruhi cara Anda menyebarkan, menjalankan, dan memperbarui pod. Anda mulai dengan mengirimkan pod YAML manifes ke kluster. Setelah file manifes dikirimkan dan berlanjut ke kluster, ia mendefinisikan keadaan pod yang diinginkan. Penjadwal menjadwalkan pod ke node sehat yang memiliki cukup sumber daya untuk menjalankan pod.
Berikut adalah fase dalam siklus hidup pod:
| Fase | Deskripsi |
|---|---|
| Tertunda | Pod menerima kluster, tetapi tidak semua kontainer dalam kluster disiapkan atau siap dijalankan. Status Tertunda menunjukkan waktu pod menunggu untuk dijadwalkan dan waktu yang dihabiskan untuk mengunduh gambar kontainer. |
| Sedang berjalan | Pod akan beralih ke keadaan berjalan setelah semua sumber daya dalam pod siap. |
| Berhasil | Pod beralih ke status berhasil setelah pod menyelesaikan tugas yang dimaksudkan dan berhasil dijalankan. |
| Gagal | Pod dapat gagal karena berbagai alasan. Kontainer dalam pod mungkin gagal, yang menyebabkan penghentian semua kontainer lain, atau mungkin gambar tidak ditemukan selama persiapan kontainer pod. Dalam jenis kasus ini, pod dapat masuk ke status Gagal. Pod dapat beralih ke status gagal dari status Tertunda atau status Berjalan. Kegagalan tertentu juga dapat menempatkan pod kembali dalam keadaan tertunda. |
| Tidak dikenal | Jika status pod tidak dapat ditentukan, pod berada dalam status Tidak Diketahui. |
Pod disimpan pada kluster hingga pengontrol, pesawat kontrol, atau pengguna secara eksplisit menghapusnya. Ketika sebuah pod dihapus, sebuah pod baru akan dibuat segera setelahnya. Pod baru dianggap sebagai instans yang sama sekali baru berdasarkan manifes pod bukanlah salinan yang tepat, sehingga berbeda dari pod yang dihapus.
Kluster tidak menyimpan keadaan pod atau konfigurasi yang ditetapkan secara dinamis. Misalnya, ia tidak menyimpan ID atau alamat IP pod. Aspek ini memengaruhi cara anda menyebarkan pod dan cara mendesain aplikasi. Misalnya, Anda tidak dapat mengandalkan alamat IP yang telah ditetapkan untuk pod Anda.
Keadaan kontainer
Perlu diingat bahwa fase adalah ringkasan di mana pod berada dalam siklus hidupnya. Ketika Anda memeriksa sebuah pod, kluster menggunakan tiga keadaan untuk melacak kontainer Anda di dalam pod:
| Provinsi | Deskripsi |
|---|---|
| Menunggu | Status default kontainer dan status bahwa kontainer berada ketika tidak berjalan atau dihentikan. |
| Sedang berjalan | Kontainer berjalan seperti yang diharapkan tanpa masalah. |
| Diakhiri | Kontainer tidak lagi berjalan. Alasannya adalah bahwa semua tugas selesai atau kontainer gagal karena alasan tertentu. Alasan dan kode keluar tersedia untuk men-debug kedua kasus. |