From 14d0710b2ead03bc664214569b2bd3b8f7e7b76f Mon Sep 17 00:00:00 2001 From: Gede Wahyu Adi Pramana Date: Sat, 19 Oct 2019 18:13:37 +0700 Subject: [PATCH] Translating Pod to ID Localization (#16979) --- .../id/docs/concepts/workloads/pods/pod.md | 262 ++++++++++++++++++ 1 file changed, 262 insertions(+) create mode 100644 content/id/docs/concepts/workloads/pods/pod.md diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md new file mode 100644 index 0000000000..8431fde570 --- /dev/null +++ b/content/id/docs/concepts/workloads/pods/pod.md @@ -0,0 +1,262 @@ +--- +reviewers: +title: Pod +content_template: templates/concept +weight: 20 +--- + +{{% capture overview %}} + +Pod adalah unit komputasi terkecil yang bisa di-_deploy_ dan dibuat serta dikelola dalam Kubernetes. + +{{% /capture %}} + + +{{% capture body %}} + +## Apa Itu Pod? + +Sebuah Pod (seperti pod pada paus atau kacang polong) adalah sebuah kelompok yang +terdiri dari satu atau lebih {{< glossary_tooltip text="kontainer" term_id="container" >}} +(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](/docs/concepts/policy/pod-security-policy/). Kontainer ini +biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod. + +Aplikasi dalam suatu Pod juga memiliki akses ke {{< glossary_tooltip text="ruang penyimpanan" term_id="volume" >}} bersama, +yang didefinisikan sebagai bagian dari Pod dan dibuat bisa diikatkan ke masing-masing +_filesystem_ pada aplikasi. + +Dalam istilah konsep [Docker](https://www.docker.com/), sebuah Pod dimodelkan sebagai +gabungan dari kontainer Docker yang berbagi _namespacs_ 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](/docs/concepts/workloads/pods/pod-lifecycle/), Pod dibuat, diberikan +ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan +(bergantung pada aturan _restart_) atau dihapus. Jika {{< glossary_tooltip text="mesin" term_id="node" >}} +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_](/docs/concepts/workloads/controllers/replicationcontroller/) +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. + +{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} + +*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](/docs/concepts/cluster-administration/networking/). + +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. + +## Pengunaan 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 file 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](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). + + +## 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. +1. 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. +1. Mudah digunakan. Penguna tidak diharuskan menjalankan manajer prosesnya sendiri, + khawatir dengan sinyal dan propagasi _exit-code_, dan lain sebagainya. +1. 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_](/docs/concepts/workloads/controllers/deployment/). Pengontrol +menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan +pengelolaan replikasi dan penluncuran. +Pengontrol seperti [_StatefulSet_](/docs/concepts/workloads/controllers/statefulset.md) +bisa memberikan dukungan terhadap Pod yang _stateful_. + +Pengunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang +relatif umum diantara sistem penjadwalan kluster, seperti +[Borg](https://research.google.com/pubs/pub43438.html), +[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), +[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), dan +[Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997). + +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 kluster. 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 kluster, sangat +penting untuk memperbolehkan proses ini berhenti secara normal ketika sudah tidak +dibutuhkan (dibandingkan dengan dihentikan paksa dengan sinyak 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 sinyak 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) +1. Pod dalam API server akan diperbarui dengan waktu dimana Pod dianggap "mati" +bersama dengan masa tenggang. +1. Pod ditampilkan dalam status "Terminating" ketika tercantum dalam perintah klien +1. (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_](/docs/concepts/containers/container-lifecycle-hooks/#hook-details), + 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. + 1. 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. +1. (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. +1. Ketika masa tenggang sudah lewat, semua proses yang masih berjalan dalam Pod +akan dihentikan dengan sinyak SIGKILL. +1. 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=` yang akan +memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan +pengguna. Nilai `0` akan membuat Pod +[dihapus paksa](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods). +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_ +kluster 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](/docs/tasks/run-application/force-delete-stateful-set-pod/). + +## Hak istimewa untuk kontainer pada Pod + +Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode _previleged_), dengan menggunakan tanda +`privileged` pada [konteks keamanan](/docs/tasks/configure-pod-container/security-context/) +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. + +{{< note >}} +_Runtime_ kontainer kamu harus mendukung konsep hak istimewa kontainer untuk membuat +pengaturan ini menjadi relevan. +{{< /note >}} + +## API Object + +Pod adalah sumber daya tingkat tinggi dalam Kubernetes REST API. +Definisi [Objek Pod API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) menjelaskan mengenai objek secara lengkap. + +{{% /capture %}}