Pod

Pod adalah unit komputasi terkecil yang bisa di-deploy dan dibuat serta dikelola dalam Kubernetes.

Apa Itu Pod?

Sebuah Pod (seperti pod pada paus atau kacang polong) adalah sebuah kelompok yang terdiri dari satu atau lebih kontainer (misalnya kontainer Docker), dengan ruang penyimpanan ataupun jaringan yang dipakai bersama, dan sebuah spesifikasi mengenai bagaimana menjalankan kontainer. Isi dari Pod akan selalu diletakkan dan dijadwalkan bersama, serta berjalan dalam konteks yang sama. Sebuah Pod memodelkan "logical host" yang spesifik terhadap aplikasi. Ini mengandung lebih dari satu kontainer aplikasi yang secara relatif saling terhubung erat. Sebelum masa kontainer, menjalankan aplikasi dalam mesin fisik atau virtual berarti menjalankan dalam logical host yang sama.

Walaupun Kubernetes mendukung lebih banyak runtime kontainer selain Docker, namun Docker adalah yang paling umum diketahui dan ini membantu dalam menjelaskan Pod dengan istilah pada Docker.

Konteks bersama dalam sebuah Pod adalah kumpulan Linux namespace, cgroup dan kemungkinan segi isolasi lain, hal yang sama yang mengisolasi kontainer Docker. Dalam sebuah konteks pada Pod, setiap aplikasi bisa menerapkan sub-isolasi lebih lanjut.

Semua kontainer dalam suatu Pod akan berbagi alamat IP dan port yang sama, dan bisa saling berkomunikasi melalui localhost. Komunikasi tersebut mengunakan standar inter-process communications (IPC) seperti SystemV semaphores atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa pengaturan khusus. Kontainer ini biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod.

Aplikasi dalam suatu Pod juga memiliki akses ke ruang penyimpanan bersama, yang didefinisikan sebagai bagian dari Pod dan dibuat bisa diikatkan ke masing-masing filesystem pada aplikasi.

Dalam istilah konsep Docker, sebuah Pod dimodelkan sebagai gabungan dari kontainer Docker yang berbagi namespace dan ruang penyimpanan filesystem.

Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal (tidak bertahan lama). Seperti yang didiskusikan dalam siklus hidup Pod, Pod dibuat, diberikan ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan (bergantung pada aturan restart) atau dihapus. Jika mesin mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa dengan nama yang sama, tapi dengan ID unik yang baru (baca replication controller untuk info lebih lanjut)

Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan, maka itu berarti akan tetap ada selama Pod tersebut masih ada. Jika Pod dihapus dengan alasan apapun, sekalipun Pod pengganti yang identik telah dibuat, semua yang berhubungan (misalnya ruang penyimpanan) akan dihapus dan dibuat ulang.

Sebuah Pod dengan banyak kontainer, yaitu File Puller dan Web Server yang menggunakan ruang penyimpanan persisten untuk berbagi ruang penyimpanan bersama antara kontainer.

Motivasi suatu Pods

Pengelolaan

Pod adalah suatu model dari pola beberapa proses yang bekerja sama dan membentuk suatu unit layanan yang kohesif. Menyederhanakan proses melakukan deploy dan pengelolaan aplikasi dengan menyediakan abstraksi tingkat yang lebih tinggi daripada konstituen aplikasinya. Pod melayani sebagai unit dari deployment, penskalaan horizontal, dan replikasi. Colocation (co-scheduling), berbagi nasib (misalnya dimatikan), replikasi terkoordinasi, berbagi sumber daya dan pengelolaan ketergantungan akan ditangani otomatis untuk kontainer dalam suatu Pod.

Berbagi sumber daya dan komunikasi

Pod memungkinkan berbagi data dan komunikasi diantara konstituennya.

Semua aplikasi dalam suatu Pod menggunakan namespace jaringan yang sama (alamat IP dan port yang sama), dan menjadikan bisa saling mencari dan berkomunikasi dengan menggunakan localhost. Oleh karena itu, aplikasi dalam Pod harus berkoordinasi mengenai penggunaan port. Setiap Pod memiliki alamat IP dalam satu jaringan bersama yang bisa berkomunikasi dengan komputer lain dan Pod lain dalam jaringan yang sama.

Kontainer dalam suatu Pod melihat hostname sistem sebagai sesuatu yang sama dengan konfigurasi name pada Pod. Informasi lebih lanjut terdapat dibagian jaringan.

Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod, Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan data untuk bertahan saat kontainer dijalankan ulang dan dibagikan kepada semua aplikasi dalam Pod tersebut.

Penggunaan Pod

Pod dapat digunakan untuk menjalankan beberapa aplikasi yang terintegrasi secara vertikal (misalnya LAMP), namun motivasi utamanya adalah untuk mendukung berlokasi bersama, mengelola program pembantu, diantaranya adalah:

• sistem pengelolaan konten, pemuat berkas dan data, manajer cache lokal, dll.
• catatan dan checkpoint cadangan, kompresi, rotasi, dll.
• pengamat perubahan data, pengintip catatan, adapter pencatatan dan pemantauan, penerbit peristiwa, dll.
• proksi, jembatan dan adaptor.
• pengontrol, manajer, konfigurasi dan pembaharu.

Secara umum, masing-masing Pod tidak dimaksudkan untuk menjalankan beberapa aplikasi yang sama.

Penjelasan lebih lengkap bisa melihat The Distributed System ToolKit: Patterns for Composite Containers.

Alternatif pertimbangan

Kenapa tidak menjalankan banyak program dalam satu kontainer (Docker)?

1. Transparansi. Membuat kontainer dalam suatu Pod menjadi terlihat dari infrastruktur, memungkinkan infrastruktur menyediakan servis ke kontainer tersebut, misalnya saja pengelolaan proses dan pemantauan sumber daya. Ini memfasilitasi sejumlah kenyamanan untuk pengguna.
2. Pemisahan ketergantungan perangkat lunak. Setiap kontainer mungkin memiliki versi, dibuat dan dijalankan ulang secara independen. Kubernetes mungkin mendukung pembaharuan secara langsung terhadap suatu kontainer, suatu saat nanti.
3. Mudah digunakan. Penguna tidak diharuskan menjalankan manajer prosesnya sendiri, khawatir dengan sinyal dan propagasi exit-code, dan lain sebagainya.
4. Efisiensi. Karena infrastruktur memegang lebih banyak tanggung jawab, kontainer bisa lebih ringan.

Kenapa tidak mendukung penjadwalan kontainer berdasarkan affinity?

Cara itu bisa menyediakan lokasi yang sama, namun tidak memberikan banyak keuntungan dari Pod, misalnya saja berbagi sumber daya, IPC, jaminan berbagi nasib dan kemudahan manajemen.

Ketahanan suatu Pod (atau kekurangan)

Pod tidak dimaksudkan untuk diperlakukan sebagai entitas yang tahan lama. Mereka tidak akan bertahan dengan kegagalan penjadwalan, kegagalan mesin, atau eviction (pengusiran), misalnya karena kurangnya sumber daya atau dalam suatu kasus mesin sedang dalam pemeliharaan.

Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya, Deployment. Pengontrol menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan pengelolaan replikasi dan penluncuran. Pengontrol seperti StatefulSet bisa memberikan dukungan terhadap Pod yang stateful.

Penggunaan API kolektif sebagai user-facing primitive utama adalah hal yang relatif umum diantara sistem penjadwalan kluster, seperti

Borg, Marathon, Aurora, dan Tupperware.

Pod diekspose sebagai primitive untuk memfasilitasi hal berikut:

• penjadwalan dan pengontrol sifat pluggability
• mendukung operasi pada level Pod tanpa perlu melakukan proksi melalui API pengontrol
• pemisahan antara umur suatu Pod dan pengontrol, seperti misalnya bootstrapping.
• pemisahan antara pengontrol dan servis, pengontrol endpoint hanya memperhatikan Pod
• komposisi yang bersih antara fungsionalitas dilevel Kubelet dan klaster. Kubelet secara efektif adalah pengontrol Pod.
• aplikasi dengan ketersediaan tinggi, yang akan mengharapkan Pod akan digantikan sebelum dihentikan dan tentu saja sebelum dihapus, seperti dalam kasus penggusuran yang direncanakan atau pengambilan gambar.

Penghentian Pod

Karena Pod merepresentasikan proses yang berjalan pada mesin didalam klaster, sangat penting untuk memperbolehkan proses ini berhenti secara normal ketika sudah tidak dibutuhkan (dibandingkan dengan dihentikan paksa dengan sinyal KILL dan tidak memiliki waktu untuk dibersihkan). Pengguna seharusnya dapat meminta untuk menghapus dan tahu proses penghentiannya, serta dapat memastikan penghentian berjalan sempurna. Ketika pengguna meminta menghapus Pod, sistem akan mencatat masa tenggang untuk penghentian secara normal sebelum Pod dipaksa untuk dihentikan, dan sinyal TERM akan dikirim ke proses utama dalam setiap kontainer. Setelah masa tenggang terlewati, sinyal KILL akan dikirim ke setiap proses dan Pod akan dihapus dari API server. Jika Kubelet atau kontainer manajer dijalankan ulang ketika menunggu suatu proses dihentikan, penghentian tersebut akan diulang dengan mengembalikan masa tenggang senilai semula.

Contohnya sebagai berikut:

1. Pengguna mengirim perintah untuk menghapus Pod, dengan masa tenggang (30 detik)
2. Pod dalam API server akan diperbarui dengan waktu dimana Pod dianggap "mati" bersama dengan masa tenggang.
3. Pod ditampilkan dalam status "Terminating" ketika tercantum dalam perintah klien
4. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai "Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod
   1. Jika salah satu kontainer pada Pod memiliki preStop hook, maka akan dipanggil di dalam kontainer. Jika preStop hook masih berjalan setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang yang sedikit, 2 detik.
   2. Semua kontainer akan diberikan sinyal TERM. Sebagai catatan, tidak semua kontainer akan menerima sinyal TERM dalam waktu yang sama dan mungkin butuh waktu untuk menjalankan preStop hook jika bergantung pada urutan penghentiannya.
5. (bersamaan dengan poin 3) Pod akan dihapus dari daftar endpoint untuk servis dan tidak lagi dianggap sebagai bagian dari Pod yang berjalan dalam replication controllers. Pod yang dihentikan, secara perlahan tidak akan melayani permintaan karena load balancer (seperti servis proksi) menghapus mereka dari daftar rotasi.
6. Ketika masa tenggang sudah lewat, semua proses yang masih berjalan dalam Pod akan dihentikan dengan sinyal SIGKILL.
7. Kubelet akan selesai menghapus Pod dalam API server dengan mengatur masa tenggang menjadi 0 (langsung menghapus). Pod akan menghilang dari API dan tidak lagi terlihat oleh klien.

Secara default, semua penghapusan akan berjalan normal selama 30 detik. Perintah kubectl delete mendukung opsi --grace-period=<waktu dalam detik> yang akan memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan pengguna. Nilai 0 akan membuat Pod dihapus paksa. Kamu harus memberikan opsi tambahan --force bersamaan dengan --grace-period=0 untuk melakukan penghapusan paksa.

Penghapusan paksa sebuah Pod

Penghapusan paksa dari sebuah Pod didefinisikan sebagai penghapusan Pod dari state klaster dan etcd secara langsung. Ketika penghapusan paksa dilakukan, API server tidak akan menunggu konfirmasi dari kubelet bahwa Pod sudah dihentikan pada mesin ia berjalan. Ini menghapus Pod secara langsung dari API, sehingga Pod baru bisa dibuat dengan nama yang sama. Dalam mesin, Pod yang dihentikan paksa akan tetap diberikan sedikit masa tenggang sebelum dihentikan paksa.

Penghentian paksa dapat menyebabkan hal berbahaya pada beberapa Pod dan seharusnya dilakukan dengan perhatian lebih. Dalam kasus StatefulSet Pods, silakan melihat dokumentasi untuk penghentian Pod dari StatefulSet.

Hak istimewa untuk kontainer pada Pod

Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode privileged), dengan menggunakan tanda privileged pada konteks keamanan pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer. Dengan hak istimerwa, seharusnya lebih mudah untuk menulis pada jaringan dan plugin ruang penyimpanan sebagai Pod berbeda yang tidak perlu dikompilasi ke dalam kubelet.

Catatan: Runtime kontainer kamu harus mendukung konsep hak istimewa kontainer untuk membuat pengaturan ini menjadi relevan.

API Object

Pod adalah sumber daya tingkat tinggi dalam Kubernetes REST API. Definisi Objek Pod API menjelaskan mengenai objek secara lengkap.