diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md index 529865af660f8..dae11dc036b26 100644 --- a/content/id/docs/concepts/_index.md +++ b/content/id/docs/concepts/_index.md @@ -7,8 +7,8 @@ weight: 40 {{% capture overview %}} -Bagian konsep ini membantu kamu belajar tentang bagian-bagian sistem serta abstraksi -yang digunakan Kubernetes untuk merepresentasikan kluster kamu, serta membantu +Bagian konsep ini membantu kamu belajar tentang bagian-bagian sistem serta abstraksi +yang digunakan Kubernetes untuk merepresentasikan kluster kamu, serta membantu kamu belajar lebih dalam bagaimana cara kerja Kubernetes. {{% /capture %}} @@ -17,37 +17,37 @@ kamu belajar lebih dalam bagaimana cara kerja Kubernetes. ## Ikhtisar -Untuk menggunakan Kubernetes, kamu menggunakan obyek-obyek *Kubernetes API* untuk merepresentasikan -*state* yang diinginkan: apa yang aplikasi atau *workload* lain yang ingin kamu -jalankan, *image* kontainer yang digunakan, jaringan atau *resource disk* apa yang ingin -kamu sediakan, dan lain sebagainya. Kamu membuat *state* yang diinginkan dengan cara membuat +Untuk menggunakan Kubernetes, kamu menggunakan obyek-obyek *Kubernetes API* untuk merepresentasikan +*state* yang diinginkan: apa yang aplikasi atau *workload* lain yang ingin kamu +jalankan, *image* kontainer yang digunakan, jaringan atau *resource disk* apa yang ingin +kamu sediakan, dan lain sebagainya. Kamu membuat *state* yang diinginkan dengan cara membuat obyek dengan menggunakan API Kubernetes, dan biasanya menggunakan `command-line interface`, yaitu `kubectl`. -Kamu juga dapat secara langsung berinteraksi dengan kluster untuk membuat atau mengubah +Kamu juga dapat secara langsung berinteraksi dengan kluster untuk membuat atau mengubah *state* yang kamu inginkan. -Setelah kamu membuat *state* yang kamu inginkan, *Control Plane* Kubernetes -menggunakan `Pod Lifecycle Event Generator (PLEG)` untuk mengubah -*state* yang ada saat ini supaya sama dengan *state* yang diinginkan. -Untuk melakukan hal tersebut, Kubernetes melakukan berbagai *task* secara otomatis, -misalnya dengan mekanisme `start` atau `stop` kontainer, melakukan *scale* replika dari -suatu aplikasi, dan lain sebagainya. *Control Plane* Kubernetes terdiri dari sekumpulan +Setelah kamu membuat *state* yang kamu inginkan, *Control Plane* Kubernetes +menggunakan `Pod Lifecycle Event Generator (PLEG)` untuk mengubah +*state* yang ada saat ini supaya sama dengan *state* yang diinginkan. +Untuk melakukan hal tersebut, Kubernetes melakukan berbagai *task* secara otomatis, +misalnya dengan mekanisme `start` atau `stop` kontainer, melakukan *scale* replika dari +suatu aplikasi, dan lain sebagainya. *Control Plane* Kubernetes terdiri dari sekumpulan `process` yang dijalankan di kluster: * **Kubernetes Master** terdiri dari tiga buah *process* yang dijalankan pada sebuah *node* di kluster kamu, *node* ini disebut sebagai *master*, yang terdiri [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) dan [kube-scheduler](/docs/admin/kube-scheduler/). -* Setiap *node* non-master pada kluster kamu menjalankan dua buah *process*: +* Setiap *node* non-master pada kluster kamu menjalankan dua buah *process*: * **[kubelet](/docs/admin/kubelet/)**, yang menjadi perantara komunikasi dengan *master*. * **[kube-proxy](/docs/admin/kube-proxy/)**, sebuah *proxy* yang merupakan representasi jaringan yang ada pada setiap *node*. ## Obyek Kubernetes -Kubernetes memiliki beberapa abstraksi yang merepresentasikan *state* dari sistem kamu: -apa yang aplikasi atau *workload* lain yang ingin kamu jalankan, jaringan atau *resource disk* apa yang ingin -kamu sediakan, serta beberapa informasi lain terkait apa yang sedang kluster kamu lakukan. -Abstraksi ini direpresentasikan oleh obyek yang tersedia di API Kubernetes; -lihat [ikhtisar obyek-obyek Kubernetes](/docs/concepts/abstractions/overview/) +Kubernetes memiliki beberapa abstraksi yang merepresentasikan *state* dari sistem kamu: +apa yang aplikasi atau *workload* lain yang ingin kamu jalankan, jaringan atau *resource disk* apa yang ingin +kamu sediakan, serta beberapa informasi lain terkait apa yang sedang kluster kamu lakukan. +Abstraksi ini direpresentasikan oleh obyek yang tersedia di API Kubernetes; +lihat [ikhtisar obyek-obyek Kubernetes](/docs/concepts/abstractions/overview/) untuk penjelasan yang lebih mendetail. -Obyek mendasar Kubernetes termasuk: +Obyek mendasar Kubernetes termasuk: * [Pod](/docs/concepts/workloads/pods/pod-overview/) * [Service](/docs/concepts/services-networking/service/) @@ -65,31 +65,31 @@ Kontroler merupakan obyek mendasar dengan fungsi tambahan, contoh dari kontroler ## *Control Plane* Kubernetes -Berbagai bagian *Control Plane* Kubernetes, seperti *master* dan *process-process* kubelet, -mengatur bagaimana Kubernetes berkomunikasi dengan kluster kamu. *Control Plane* -menjaga seluruh *record* dari obyek Kubernetes serta terus menjalankan -iterasi untuk melakukan manajemen *state* obyek. *Control Plane* akan memberikan respon -apabila terdapat perubahan pada kluster kamu dan mengubah *state* saat ini agar sesuai +Berbagai bagian *Control Plane* Kubernetes, seperti *master* dan *process-process* kubelet, +mengatur bagaimana Kubernetes berkomunikasi dengan kluster kamu. *Control Plane* +menjaga seluruh *record* dari obyek Kubernetes serta terus menjalankan +iterasi untuk melakukan manajemen *state* obyek. *Control Plane* akan memberikan respon +apabila terdapat perubahan pada kluster kamu dan mengubah *state* saat ini agar sesuai dengan *state* yang diinginkan. -Contohnya, ketika kamu menggunakan API Kubernetes untuk membuat sebuah *Deployment*, -kamu memberikan sebuah *state* baru yang harus dipenuhi oleh sistem. *Control Plane* -kemudian akan mencatat obyek apa saja yang dibuat, serta menjalankan instruksi yang kamu berikan -dengan cara melakukan `start` aplikasi dan melakukan `scheduling` aplikasi tersebut +Contohnya, ketika kamu menggunakan API Kubernetes untuk membuat sebuah *Deployment*, +kamu memberikan sebuah *state* baru yang harus dipenuhi oleh sistem. *Control Plane* +kemudian akan mencatat obyek apa saja yang dibuat, serta menjalankan instruksi yang kamu berikan +dengan cara melakukan `start` aplikasi dan melakukan `scheduling` aplikasi tersebut pada *node*, dengan kata lain mengubah *state* saat ini agar sesuai dengan *state* yang diinginkan. ### Master -Master Kubernetes bertanggung jawab untuk memelihara *state* yang diinginkan pada kluster kamu. -Ketika kamu berinteraksi dengan Kubernetes, misalnya saja menggunakan perangkat `kubectl`, -kamu berkomunikasi dengan *master* kluster Kubernetes kamu. +Master Kubernetes bertanggung jawab untuk memelihara *state* yang diinginkan pada kluster kamu. +Ketika kamu berinteraksi dengan Kubernetes, misalnya saja menggunakan perangkat `kubectl`, +kamu berkomunikasi dengan *master* kluster Kubernetes kamu. > "master" merujuk pada tiga buah *process* yang dijalankan pada sebuah *node* pada kluster kamu, *node* ini disebut sebagai *master*, yang terdiri [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) dan [kube-scheduler](/docs/admin/kube-scheduler/). ### Node -*Node* di dalam kluster Kubernetes adalah mesin (mesin virtual maupun fisik) yang -menjalankan aplikasi kamu. Master mengontrol setiap node; kamu akan jarang berinteraksi +*Node* di dalam kluster Kubernetes adalah mesin (mesin virtual maupun fisik) yang +menjalankan aplikasi kamu. Master mengontrol setiap node; kamu akan jarang berinteraksi dengan *node* secara langsung. #### Metadata obyek diff --git a/content/id/docs/concepts/architecture/master-node-communication.md b/content/id/docs/concepts/architecture/master-node-communication.md index 6c31bbf63f812..75a6cecc05abf 100644 --- a/content/id/docs/concepts/architecture/master-node-communication.md +++ b/content/id/docs/concepts/architecture/master-node-communication.md @@ -17,7 +17,7 @@ Hal ini cukup penting, karena kluster bisa saja berjalan pada jaringan tak terpe ## Kluster menuju Master -Semua jalur komunikasi dari kluster menuju master diterminasi pada apiserver. +Semua jalur komunikasi dari kluster menuju master diterminasi pada apiserver. Tidak ada komponen apapun di dalam master, selain apiserver, yang terekspos ke luar untuk diakses dari servis remote. Untuk instalasi kluster pada umumnya, apiserver diatur untuk listen ke koneksi remote melalui port HTTPS (443) yang aman, dengan satu atau beberapa metode [autentikasi](/docs/reference/access-authn-authz/authentication/) client yang telah terpasang. Sebaiknya, satu atau beberapa metode [otorisasi](/docs/reference/access-authn-authz/authorization/) juga dipasang, terutama jika kamu memperbolehkan [permintaan anonim (anonymous request)](/docs/reference/access-authn-authz/authentication/#anonymous-requests) ataupun [service account token](/docs/reference/access-authn-authz/authentication/#service-account-tokens). @@ -39,7 +39,7 @@ Dan juga, kluster dan master bisa terhubung melalui jaringan publik dan/atau yan Ada dua jalur komunikasi utama dari master (apiserver) menuju kluster. Pertama, dari apiserver ke process kubelet yang berjalan pada setiap node di dalam kluster. -Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi proxy pada apiserver. +Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi proxy pada apiserver. ### Apiserver menuju kubelet diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md index ab5cb4d091ef0..2da2a20328257 100644 --- a/content/id/docs/concepts/architecture/nodes.md +++ b/content/id/docs/concepts/architecture/nodes.md @@ -62,12 +62,12 @@ Penggunaan field-field ini bergantung pada penyedia layanan cloud ataupun ``` Jika status untuk `Ready condition` bernilai `Unknown` atau `False` untuk waktu yang lebih dari `pod-eviction-timeout`, tergantung bagaimana [kube-controller-manager](/docs/admin/kube-controller-manager/) dikonfigurasi, semua pod yang dijalankan pada node tersebut akan dihilangkan oleh Kontroler Node. -Durasi eviction timeout yang standar adalah **lima menit**. -Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berkomunikasi dengan kubelet yang ada pada node. -Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali. +Durasi eviction timeout yang standar adalah **lima menit**. +Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berkomunikasi dengan kubelet yang ada pada node. +Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali. Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan. -Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver. +Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa ([force delete](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)) pod-pod yang terputus dari apiserver. Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam kluster. Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan kluster, admin kluster mungkin perlu untuk menghilangkan node secara manual. Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali. diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md index ae2cfd0902dc0..b082b76a1636b 100644 --- a/content/id/docs/concepts/cluster-administration/federation.md +++ b/content/id/docs/concepts/cluster-administration/federation.md @@ -10,85 +10,85 @@ weight: 80 {{< include "federation-deprecation-warning-note.md" >}} {{< /deprecationfilewarning >}} -Laman ini menjelaskan alasan dan cara penggunaan _federation_ untuk melakukan manajemen +Laman ini menjelaskan alasan dan cara penggunaan _federation_ untuk melakukan manajemen kluster Kubernetes. {{% /capture %}} {{% capture body %}} ## Kenapa _Federation_ ? -_Federation_ membuat proses manajemen kluster multipel menjadi lebih mudah. +_Federation_ membuat proses manajemen kluster multipel menjadi lebih mudah. _Federation_ mencapai hal ini dengan cara menyediakan 2 buah fondasi: - * Melakukan sinkronisasi _resource_ di seluruh kluster: _Federation_ - menyediakan kemampuan untuk melakukan sinkronisasi _resources_ pada _multiple_ - kluster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama - tersedia pada kluster multipel. - * _Cross_ _cluster_ _Discovery_: _Federation_ menyediakan kemampuan untuk melakukan - konfigurasi otomatis server DNS dan _load balancer_ dari semua kluster. - Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan + * Melakukan sinkronisasi _resource_ di seluruh kluster: _Federation_ + menyediakan kemampuan untuk melakukan sinkronisasi _resources_ pada _multiple_ + kluster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama + tersedia pada kluster multipel. + * _Cross_ _cluster_ _Discovery_: _Federation_ menyediakan kemampuan untuk melakukan + konfigurasi otomatis server DNS dan _load balancer_ dari semua kluster. + Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan untuk mengakses _backend_ dari kluster multipel. Beberapa penggunaan _federation_ adalah sebagai berikut: -* _High Availability_: Melakukan _load balance_ di seluruh kluster serta - melakukan konfigurasi otomatis server DNS dan _load balancer_, _federation_ +* _High Availability_: Melakukan _load balance_ di seluruh kluster serta + melakukan konfigurasi otomatis server DNS dan _load balancer_, _federation_ meminimalisasi dampak yang terjadi apabila terjadi kegagalan kluster. -* Mencegah _lock-in_ yang terjadi akibat penyedia layanan: Dengan cara mempermudah +* Mencegah _lock-in_ yang terjadi akibat penyedia layanan: Dengan cara mempermudah proses migrasi antar kluster. -Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa kluster. +Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa kluster. Beberapa alasan kenapa kamu butuh beberapa kluster adalah: -* _Latency_ yang rendah: Memiliki kluster yang berada di _region_ yang berbeda - meminimalisasi _latency_ dengan cara menyajikan konten ke pengguna +* _Latency_ yang rendah: Memiliki kluster yang berada di _region_ yang berbeda + meminimalisasi _latency_ dengan cara menyajikan konten ke pengguna berdasarkan _region_ yang paling dekat dengan pengguna tersebut. -* Isolasi _fault_: Akan lebih baik apabila kita memiliki beberapa kluster kecil - dibandingkan sebuah kluster besar untuk melakukan isolasi _fault_ (misalnya saja - kluster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_ +* Isolasi _fault_: Akan lebih baik apabila kita memiliki beberapa kluster kecil + dibandingkan sebuah kluster besar untuk melakukan isolasi _fault_ (misalnya saja + kluster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_ yang berbeda). -* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah kluster Kubernetes, - hal ini sebenarnya tidak menjadi masalah bagi sebagian besar pengguna. Untuk informasi - lebih lanjut kamu bisa membaca +* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah kluster Kubernetes, + hal ini sebenarnya tidak menjadi masalah bagi sebagian besar pengguna. Untuk informasi + lebih lanjut kamu bisa membaca [_Kubernetes Scaling_ dan Perencanaan Performa](https://git.k8s.io/community/sig-scalability/goals.md)). -* [_Hybrid cloud_](#hybrid-cloud-capabilities): Kamu dapat memiliki _multiple_ klsuter +* [_Hybrid cloud_](#hybrid-cloud-capabilities): Kamu dapat memiliki _multiple_ klsuter pada penyedia layanan _cloud_ yang berbeda ataupun menggunakan _on-premsie_. ### Kekurangan -Meskipun terdapat banyak kelebihan dari penggunaan _federation_, +Meskipun terdapat banyak kelebihan dari penggunaan _federation_, terdapat beberapa kekurangan _federation_ yang dijabarkan sebagai berikut: -* Peningkatan _bandwidth_ dan biaya untuk jaringan: _control plane_ _federation_ bertugas mengawasi semua - kulster yang ada untuk menjamin _state_ yang ada saat ini sesuai dengan _state_ yang diinginkan. Hal ini dapat menyebabkan - peningkatan biaya jaringan apabila kluster yang ada dijalankan pada _region_ yang berbeda baik pada penyedia +* Peningkatan _bandwidth_ dan biaya untuk jaringan: _control plane_ _federation_ bertugas mengawasi semua + kulster yang ada untuk menjamin _state_ yang ada saat ini sesuai dengan _state_ yang diinginkan. Hal ini dapat menyebabkan + peningkatan biaya jaringan apabila kluster yang ada dijalankan pada _region_ yang berbeda baik pada penyedia layanan _cloud_ yang sama maupun berbeda. -* Berkurangnya isolasi antar kluster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat - berdampak pada semua kluster. Hal ini dapat dihindari dengan cara mejaga logika yang ada pada _control plane_ _federation_ +* Berkurangnya isolasi antar kluster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat + berdampak pada semua kluster. Hal ini dapat dihindari dengan cara mejaga logika yang ada pada _control plane_ _federation_ seminimum mungkin. -* Kematangan: Proyek _federation_ ini tergolong baru dan belum cukup matang. +* Kematangan: Proyek _federation_ ini tergolong baru dan belum cukup matang. Tidak semua _resource_ yang ada tersedia dan masih banyak feature _alpha_. [_Issue_ - 88](https://github.com/kubernetes/federation/issues/88) memberikan detail + 88](https://github.com/kubernetes/federation/issues/88) memberikan detail isu-isu terkait sistem yang masih berusaha dicari solusinya. ### Kemampuan _Hybrid_ Penggunaan Layanan Penyedian _Cloud_ -_Federation_ pada Kubernetes memungkinkan kluster untuk dijalankan +_Federation_ pada Kubernetes memungkinkan kluster untuk dijalankan pada penyedia layanan _cloud_ yang berbeda (misalnya Google Cloud, AWS), dan _on-premise_ -(misalnya OpenStack). [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/) -adalah salah satu cara yang direkomendasikan untuk melakukan proses _deploy_ +(misalnya OpenStack). [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/) +adalah salah satu cara yang direkomendasikan untuk melakukan proses _deploy_ kluster _federation_. -Dengan demikian, [_resources_ API](#resources-api) yang kamu miliki +Dengan demikian, [_resources_ API](#resources-api) yang kamu miliki dapat berada di kluster atau bahkan penyedia layanan _cloud_ yang berbeda. ## Mengaktifkan _Federation_ -Untuk bisa melakukan _federation_ pada kluster yang berbeda, +Untuk bisa melakukan _federation_ pada kluster yang berbeda, pertama kamu harus mengaktifkan _control plane_ _federation_. -Ikuti [petunjuk mengaktifkan _control plane_ _federation_](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) -untuk informasi lebih lanjut. +Ikuti [petunjuk mengaktifkan _control plane_ _federation_](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) +untuk informasi lebih lanjut. ## `Resources` API @@ -109,41 +109,41 @@ Berikut merupakan panduan yang akan menjelaskan masing-masing _resource_ secara * [Services](/docs/concepts/cluster-administration/federation-service-discovery/) -[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar +[Referensi Dokumentasi API](/docs/reference/federation/) memberikan semua daftar _resources_ yang disediakan _apiserver_ _federation_. ## Penghapusan Berantai -Kubernetes versi 1.6 menyediakan mekanisme penghapusan berantai -untuk _resource_ yang ada pada _federation_. Dengan penghapusan berantai, -ketika kamu menghapus sebuah _resource_ dari _control plane_ _federation_, +Kubernetes versi 1.6 menyediakan mekanisme penghapusan berantai +untuk _resource_ yang ada pada _federation_. Dengan penghapusan berantai, +ketika kamu menghapus sebuah _resource_ dari _control plane_ _federation_, kamu juga akan menghapus segala _resource_ tersebut pada semua kluster yang ada. -Mekanisme penghapusan berantai ini tidak diaktifkan secara _default_ -ketika menggunakan REST API. Untuk mengaktifkannya, ubah nilai dari opsi -`DeleteOptions.orphanDependents=false` ketika kamu menghapus sebuah _resource_ -dari _control plane_ _federation_ dengan menggunakan REST API. -Penggunaan `kubectl delete`mengaktifkan penhapusan berantai secara _default_. +Mekanisme penghapusan berantai ini tidak diaktifkan secara _default_ +ketika menggunakan REST API. Untuk mengaktifkannya, ubah nilai dari opsi +`DeleteOptions.orphanDependents=false` ketika kamu menghapus sebuah _resource_ +dari _control plane_ _federation_ dengan menggunakan REST API. +Penggunaan `kubectl delete`mengaktifkan penhapusan berantai secara _default_. Kamu dapat menonaktifkannya dengan menggunakan `kubectl delete --cascade=false` -Catatan: Kubernetes versi 1.5 menyediakan penghapusan berantai +Catatan: Kubernetes versi 1.5 menyediakan penghapusan berantai untuk sebagian _resource_ _federation_. ## Cakupan dari Sebuah Kluster -Pada penyedia IaaS seperti Google Compute Engine atau Amazon Web Services, sebuah VM ada di dalam +Pada penyedia IaaS seperti Google Compute Engine atau Amazon Web Services, sebuah VM ada di dalam [zona](https://cloud.google.com/compute/docs/zones) atau [_availability zone_](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html). -Kami menyarankan agar semua VM pada kluster Kubernetes berada pada _availability_ zona yang sama, karena: +Kami menyarankan agar semua VM pada kluster Kubernetes berada pada _availability_ zona yang sama, karena: - dibandingkan dengan sebuah kluster global Kubernetes, terdapat lebih sedikit _single-points of failure_. - - dibandingkan dengan sebuah kluster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah + - dibandingkan dengan sebuah kluster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah kluster yang berada pada satu zona. - - ketika pengembang Kubernetes mendesain sistem (misalnya, memperkirakan _latency_, _bandwidth_, atau + - ketika pengembang Kubernetes mendesain sistem (misalnya, memperkirakan _latency_, _bandwidth_, atau _failure_ yang mungkin terjadi) pengembang tersebut memperkirakan semua mesin akan berada pada sebuah _data center_ yang sama, atau setidaknya masih terdapat pada satu wilayah. -Sangat direkomendasikan untuk menjalankan sedikit kluster dengan lebih banyak VM pada setiap _availability_ zona; -meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan kluster multipel +Sangat direkomendasikan untuk menjalankan sedikit kluster dengan lebih banyak VM pada setiap _availability_ zona; +meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan kluster multipel pada setiap _availability_ zona. Alasan kenapa menjalankan lebih sedikit kluster pada setiap _availability_ zona lebih dianjurkan: @@ -159,26 +159,26 @@ Alasan untuk memiliki kluster multipel: ## Memilih jumlah kluster yang tepat -Pemilihan jumlah kluster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu. +Pemilihan jumlah kluster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu. Sebaliknya, jumlah _node_ dan _pod_ dalam suatu _service_ dapat berubah secara cepat seiring bertambahnya _workload_. -Untuk memilih jumlah kluster, pertama, pilih _region_ yang memiliki _latency_ yang masih dapat dimaklumi untuk semua pengguna aplikasi kamu -(jika kamu menggunakan _Content Distribution Network_, kebutuhan informasi nilai _latency_ CDN tidak perlu diperhatikan). -Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih kluster di _region_ +Untuk memilih jumlah kluster, pertama, pilih _region_ yang memiliki _latency_ yang masih dapat dimaklumi untuk semua pengguna aplikasi kamu +(jika kamu menggunakan _Content Distribution Network_, kebutuhan informasi nilai _latency_ CDN tidak perlu diperhatikan). +Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih kluster di _region_ US, EU, AP, dan SA. Jumlah _region_ ini dimisalkan dengan `R`. -Kedua, pilih berapa banyak kluster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_. -Misalkan jumlah kluster _unavailable_ ini sebagai `U`. Jika kamu tidak yakin, maka 1 merupakan pilihan yang tergolong +Kedua, pilih berapa banyak kluster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_. +Misalkan jumlah kluster _unavailable_ ini sebagai `U`. Jika kamu tidak yakin, maka 1 merupakan pilihan yang tergolong dapat diterima. -Jika aplikasimu memungkinkan trafik untuk di-_load balance_ ke _region_ mana saja ketika terjadi _failure_ pada kluster, -maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` kluster. Jika tidak (misalnya, kamu -ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada kluster) maka kamu membutuhkan `R * (U + 1)` kluster -(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu kluster +Jika aplikasimu memungkinkan trafik untuk di-_load balance_ ke _region_ mana saja ketika terjadi _failure_ pada kluster, +maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` kluster. Jika tidak (misalnya, kamu +ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada kluster) maka kamu membutuhkan `R * (U + 1)` kluster +(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu kluster pada zona yang berbeda. -Terakhir, jika kluster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah kluster Kubernetes, -maka kamu membutuhkan lebih banyak kluster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap kluster. Kubernetes v1.8 +Terakhir, jika kluster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah kluster Kubernetes, +maka kamu membutuhkan lebih banyak kluster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap kluster. Kubernetes v1.8 mampu menangani hingga 5000 node untuk tiap kluster. Baca [Membangun Kluster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut. {{% /capture %}} diff --git a/content/id/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/id/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 8c1b5bc825242..fd92c4896b46e 100644 --- a/content/id/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/id/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -6,7 +6,7 @@ weight: 70 {{% capture overview %}} -*Garbage collection* merupakan fitur kubelet yang sangat bermanfaat, yang akan membersihkan *image-image* dan juga kontainer-kontainer +*Garbage collection* merupakan fitur kubelet yang sangat bermanfaat, yang akan membersihkan *image-image* dan juga kontainer-kontainer yang tidak lagi digunakan. Kubelet akan melakukan *garbage collection* untuk kontainer setiap satu menit dan *garbage collection* untuk *image* setiap lima menit. @@ -22,7 +22,7 @@ menghilangkan kontainer-kontainer yang sebenarnya masih diperlukan. Kubernetes mengelola *lifecycle* untuk seluruh *image* melalui *imageManager*, dengan bantuan cadvisor. -*Policy* untuk melakukan *garbage collection* memperhatikan dua hal: `HighThresholdPercent` dan `LowThresholdPercent`. +*Policy* untuk melakukan *garbage collection* memperhatikan dua hal: `HighThresholdPercent` dan `LowThresholdPercent`. Penggunaan disk yang melewati batas atas (*high threshold*) akan men-*trigger* *garbage collection*. *Garbage collection* akan mulai menghapus dari *image-image* yang paling jarang digunakan (*least recently used*) sampai menemui batas bawah (*low threshold*) kembali. @@ -31,15 +31,15 @@ sampai menemui batas bawah (*low threshold*) kembali. *Policy* untuk melakukan *garbage collection* pada kontainer memperhatikan tiga variabel yang ditentukan oleh pengguna (*user-defined*). `MinAge` merupakan umur minimal dimana suatu kontainer dapat terkena *garbage collection*. -`MaxPerPodContainer` merupakan jumlah maksimum yang diperbolehkan untuk setiap pod (UID, container name) *pair* memiliki +`MaxPerPodContainer` merupakan jumlah maksimum yang diperbolehkan untuk setiap pod (UID, container name) *pair* memiliki kontainer-kontainer yang sudah mati (*dead containers*). `MaxContainers` merupakan jumlah maksimal total dari seluruh kontainer yang sudah mati. Semua variabel ini dapat dinonaktifkan secara individual, dengan mengatur `MinAge` ke angka nol serta mengatur `MaxPerPodContainer` dan `MaxContainers` ke angka di bawah nol. -Kubelet akan mengambil tindakan untuk kontainer-kontainer yang tidak dikenal, sudah dihapus, atau diluar batasan-batasan yang diatur +Kubelet akan mengambil tindakan untuk kontainer-kontainer yang tidak dikenal, sudah dihapus, atau diluar batasan-batasan yang diatur sebelumnya melalui *flag*. Kontainer-kontainer yang paling lama (tertua) biasanya akan dihapus terlebih dahulu. `MaxPerPodContainer` dan `MaxContainer` berpotensi mengalami konflik satu sama lain pada situasi saat menjaga jumlah maksimal kontainer per pod (`MaxPerPodContainer`) akan melebihi -jumlah kontainer mati (*dead containers*) yang diperbolehkan (`MaxContainers`). +jumlah kontainer mati (*dead containers*) yang diperbolehkan (`MaxContainers`). `MaxPerPodContainer` dapat diatur sedemikian rupa dalam situasi ini: Seburuk-buruhknya dengan melakukan *downgrade* `MaxPerPodContainer` ke angka 1 dan melakukan *evict* kontainer-kontainer yang paling lama. Selain itu, kontainer-kontainer milik Pod yang telah dihapus akan dihilangkan saat umur mereka telah melebihi `MinAge`. @@ -85,7 +85,7 @@ Beberapa fitur *Garbage Collection* pada kubelet di laman ini akan digantikan ol | `--maximum-dead-containers-per-container` | | *deprecated* saat log yang telah usang tersimpan di luar konteks kontainer | | `--minimum-container-ttl-duration` | | *deprecated* saat log yang telah usang tersimpan di luar konteks kontainer | | `--low-diskspace-threshold-mb` | `--eviction-hard` atau `eviction-soft` | *eviction* memberi generalisasi *threshold* disk untuk *resource-resource* lainnya | -| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | *eviction* memberi generalisasi transisi tekanan *disk* (*disk pressure*)untuk *resource-resource* lainnya | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | *eviction* memberi generalisasi transisi tekanan *disk* (*disk pressure*)untuk *resource-resource* lainnya | {{% /capture %}} diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md index 0d9ab08793631..73872f3d08394 100644 --- a/content/id/docs/concepts/cluster-administration/logging.md +++ b/content/id/docs/concepts/cluster-administration/logging.md @@ -122,7 +122,7 @@ Kamu dapat menggunakan kontainer _sidecar_ dengan salah satu cara berikut: Kamu dapat memanfaatkan kubelet dan agen _logging_ yang telah berjalan pada tiap _node_ dengan menggunakan kontainer _sidecar_. Kontainer _sidecar_ dapat membaca log dari sebuah berkas, _socket_ atau journald. Tiap kontainer _sidecar_ menuliskan log ke `stdout` atau `stderr` mereka sendiri. -Dengan menggunakan cara ini kamu dapat memisahkan aliran log dari bagian-bagian yang berbeda dari aplikasimu, yang beberapa mungkin tidak mendukung log ke `stdout` dan `stderr`. Perubahan logika aplikasimu dengan menggunakan cara ini cukup kecil, sehingga hampir tidak ada _overhead_. Selain itu, karena `stdout` dan `stderr` ditangani oleh kubelet, kamu juga dapat menggunakan alat bawaan seperti `kubectl logs`. +Dengan menggunakan cara ini kamu dapat memisahkan aliran log dari bagian-bagian yang berbeda dari aplikasimu, yang beberapa mungkin tidak mendukung log ke `stdout` dan `stderr`. Perubahan logika aplikasimu dengan menggunakan cara ini cukup kecil, sehingga hampir tidak ada _overhead_. Selain itu, karena `stdout` dan `stderr` ditangani oleh kubelet, kamu juga dapat menggunakan alat bawaan seperti `kubectl logs`. Sebagai contoh, sebuah pod berjalan pada satu kontainer tunggal, dan kontainer menuliskan ke dua berkas log yang berbeda, dengan dua format yang berbeda pula. Berikut ini _file_ konfigurasi untuk Pod: diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md index b8265b1f7a6db..76b88beaf4ae5 100644 --- a/content/id/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md @@ -332,7 +332,7 @@ NAME READY STATUS RESTARTS AGE my-nginx-2035384211-j5fhi 1/1 Running 0 30m ``` -Agar sistem dapat menyesuaikan jumlah replika nginx yang dibutuhkan secara otomatis dari 1 hingga 3, lakukan: +Agar sistem dapat menyesuaikan jumlah replika nginx yang dibutuhkan secara otomatis dari 1 hingga 3, lakukan: ```shell kubectl autoscale deployment/my-nginx --min=1 --max=3 diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md index 06a9c4cb1bb6e..8dfc6ddf6b035 100644 --- a/content/id/docs/concepts/cluster-administration/proxies.md +++ b/content/id/docs/concepts/cluster-administration/proxies.md @@ -55,7 +55,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes - support untuk SCTP tergantung pada load balancer yang diimplementasikan oleh penyedia cloud - implementasi bervariasi tergantung pada penyedia cloud -Pengguna Kubernetes biasanya hanya cukup perlu tahu tentang kubectl proxy dan apiserver proxy. +Pengguna Kubernetes biasanya hanya cukup perlu tahu tentang kubectl proxy dan apiserver proxy. Untuk proxy-proxy lain di luar ini, admin kluster biasanya akan memastikan konfigurasinya dengan benar. ## Melakukan request redirect diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/configuration/assign-pod-node.md index aaddac7334b7e..c536b13eba3a8 100644 --- a/content/id/docs/concepts/configuration/assign-pod-node.md +++ b/content/id/docs/concepts/configuration/assign-pod-node.md @@ -35,7 +35,7 @@ Kamu dapat memastikan perintah telah berhasil dengan menjalankan ulang perintah ### Langkah Dua: Menambahkan sebuah nodeSelector ke konfigurasi pod kamu -Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya: +Ambil berkas konfigurasi pod manapun yang akan kamu jalankan, dan tambahkan sebuah bagian `nodeSelector` pada berkas tersebut, seperti berikut. Sebagai contoh, jika berikut ini adalah konfigurasi pod saya: ```yaml apiVersion: v1 @@ -116,7 +116,7 @@ Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node den Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. -Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat. +Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat. Jika kamu menyatakan beberapa `nodeSelectorTerms` yang terkait dengan tipe `nodeAffinity`, maka pod akan dijadwalkan pada node **jika salah satu** dari `nodeSelectorTerms` dapat terpenuhi. @@ -132,7 +132,7 @@ Untuk informasi lebih lanjut tentang afinitas node kamu dapat melihat [design do ### Afinitas and anti-afinitas antar pod (fitur beta) Afinitas and anti-afinitas antar pod diperkenalkan pada Kubernetes 1.4. Afinitas and anti-afinitas antar pod memungkinkan kamu untuk membatasi node yang memenuhi syarat untuk penjadwalan pod *berdasarkan label-label pada pod yang sudah berjalan pada node* daripada berdasarkan label-label pada node. Aturan tersebut berbentuk "pod ini harus (atau, dalam kasus -anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels). +anti-afinitas, tidak boleh) berjalan dalam X jika X itu sudah menjalankan satu atau lebih pod yang memenuhi aturan Y". Y dinyatakan sebagai sebuah LabelSelector dengan daftar namespace terkait; tidak seperti node, karena pod are namespaced (maka dari itu label-label pada pod diberi namespace secara implisit), sebuah label selector di atas label-label pod harus menentukan namespace yang akan diterapkan selector. Secara konsep X adalah domain topologi seperti node, rack, zona penyedia cloud, daerah penyedia cloud, dll. Kamu dapat menyatakannya menggunakan `topologyKey` yang merupakan kunci untuk label node yang digunakan sistem untuk menunjukkan domain topologi tersebut, contohnya lihat kunci label yang terdaftar di atas pada bagian [Selingan: label node built-in](#interlude-built-in-node-labels). {{< note >}} Afinitas and anti-afinitas antar pod membutuhkan jumlah pemrosesan yang substansial yang dapat memperlambat penjadwalan pada kluster berukuran besar secara signifikan. Kami tidak merekomendasikan penggunaan mereka pada kluster yang berukuran lebih besar dari beberapa ratus node. @@ -159,14 +159,14 @@ maupun `preferredDuringSchedulingIgnoredDuringExecution`. Operator yang sah untuk afinitas dan anti-afinitas pod adalah `In`, `NotIn`, `Exists`, `DoesNotExist`. -Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`: +Pada dasarnya, `topologyKey` dapat berupa label-kunci apapun yang sah. Namun, untuk alasan performa dan keamanan, ada beberapa batasan untuk `topologyKey`: 1. Untuk afinitas and anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, `topologyKey` tidak boleh kosong. 2. Untuk anti-afinitas pod `requiredDuringSchedulingIgnoredDuringExecution`, pengontrol penerimaan `LimitPodHardAntiAffinityTopology` diperkenalkan untuk membatasi `topologyKey` pada `kubernetes.io/hostname`. Jika kamu menginginkan untuk membuatnya tersedia untuk topologi khusus, kamu dapat memodifikasi pengontrol penerimaan, atau cukup menonaktifkannya saja. 3. Untuk anti-afinitas pod `preferredDuringSchedulingIgnoredDuringExecution`, `topologyKey` yang kosong diinterpretasikan sebagai "semua topologi" ("semua topologi" sekarang dibatasi pada kombinasi dari `kubernetes.io/hostname`, `failure-domain.beta.kubernetes.io/zone` dan `failure-domain.beta.kubernetes.io/region`). 4. Kecuali untuk kasus-kasus di atas, `topologyKey` dapat berupa label-kunci apapun yang sah. -Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`) +Sebagai tambahan untuk `labelSelector` and `topologyKey`, kamu secara opsional dapat menyatakan daftar `namespaces` dari namespaces yang akan digunakan untuk mencocokan `labelSelector` (daftar ini berjalan pada level definisi yang sama dengan `labelSelector` dan `topologyKey`) Jika dihilangkan atau kosong, daftar ini sesuai standar akan merujuk pada _namespace_ dari pod tempat definisi afinitas/anti-afinitas dinyatakan. @@ -175,7 +175,7 @@ Semua `matchExpressions` berkaitan dengan afinitas and anti-afinitas `requiredDu #### Penggunaan yang lebih praktikal Afinitas and anti-afinitas antar pod dapat menjadi lebih berguna saat digunakan bersamaan dengan koleksi dengan level yang lebih tinggi seperti ReplicaSets, StatefulSets, Deployments, dll. Pengguna dapat dengan mudah mengkonfigurasi bahwa satu set workload harus -ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama. +ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang sama. ##### Selalu ditempatkan bersamaan pada node yang sama @@ -280,7 +280,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy kluster redis sehingga tidak ada dua instance terletak pada hos yang sama. -Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama. +Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama. Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md index 3c255d4224264..8a71c40dbd2e7 100644 --- a/content/id/docs/concepts/configuration/taint-and-toleration.md +++ b/content/id/docs/concepts/configuration/taint-and-toleration.md @@ -7,14 +7,14 @@ weight: 40 {{% capture overview %}} Afinitas Node, seperti yang dideskripsikan [di sini](/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature), -adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi -untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau -_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas -- +adalah salah satu properti dari Pod yang menyebabkan pod tersebut memiliki preferensi +untuk ditempatkan di sekelompok Node tertentu (preferensi ini dapat berupa _soft constraints_ atau +_hard constraints_ yang harus dipenuhi). _Taint_ merupakan kebalikan dari afinitas -- properti ini akan menyebabkan Pod memiliki preferensi untuk tidak ditempatkan pada sekelompok Node tertentu. -_Taint_ dan _toleration_ bekerja sama untuk memastikan Pod dijadwalkan pada Node -yang sesuai. Satu atau lebih _taint_ akan diterapkan pada suatu node; hal ini akan menyebabkan -node tidak akan menerima pod yang tidak mengikuti _taint_ yang sudah diterapkan. +_Taint_ dan _toleration_ bekerja sama untuk memastikan Pod dijadwalkan pada Node +yang sesuai. Satu atau lebih _taint_ akan diterapkan pada suatu node; hal ini akan menyebabkan +node tidak akan menerima pod yang tidak mengikuti _taint_ yang sudah diterapkan. {{% /capture %}} @@ -29,19 +29,19 @@ Misalnya, kubectl taint nodes node1 key=value:NoSchedule ``` -akan menerapkan _taint_ pada _node_ `node1`. _Taint_ tersebut memiliki _key_ `key`, _value_ `value`, -dan _effect_ _taint_ `NoSchedule`. Hal ini artinya pod yang ada tidak akan dapat dijadwalkan pada `node1` +akan menerapkan _taint_ pada _node_ `node1`. _Taint_ tersebut memiliki _key_ `key`, _value_ `value`, +dan _effect_ _taint_ `NoSchedule`. Hal ini artinya pod yang ada tidak akan dapat dijadwalkan pada `node1` kecuali memiliki _taint_ yang sesuai. -Untuk menghilangkan _taint_ yang ditambahkan dengan perintah di atas, kamu dapat menggunakan +Untuk menghilangkan _taint_ yang ditambahkan dengan perintah di atas, kamu dapat menggunakan perintah di bawah ini: ```shell kubectl taint nodes node1 key:NoSchedule- ``` -Kamu dapat memberikan spesifikasi _toleration_ untuk _pod_ pada bagian PodSpec. -Kedua _toleration_ yang diterapkan di bawa ini "sesuai" dengan _taint_ yang -_taint_ yang dibuat dengan perintah `kubectl taint` di atas, sehingga sebuah _pod_ +Kamu dapat memberikan spesifikasi _toleration_ untuk _pod_ pada bagian PodSpec. +Kedua _toleration_ yang diterapkan di bawa ini "sesuai" dengan _taint_ yang +_taint_ yang dibuat dengan perintah `kubectl taint` di atas, sehingga sebuah _pod_ dengan _toleration_ yang sudah didefinisikan akan mampu di-_schedule_ ke node `node`: ```yaml @@ -59,7 +59,7 @@ tolerations: effect: "NoSchedule" ``` -Sebuah _toleration_ "sesuai" dengan sebuah _taint_ jika _key_ dan efek yang +Sebuah _toleration_ "sesuai" dengan sebuah _taint_ jika _key_ dan efek yang ditimbulkan sama: * `operator` dianggap `Exists` (pada kasus dimana tidak ada `value` yang diberikan), atau @@ -87,29 +87,29 @@ tolerations: ``` {{< /note >}} -Contoh yang diberikan di atas menggunakan `effect` untuk `NoSchedule`. +Contoh yang diberikan di atas menggunakan `effect` untuk `NoSchedule`. Alternatif lain yang dapat digunakan adalah `effect` untuk `PreferNoSchedule`. -`PreferNoSchedule` merupakan "preferensi" yang lebih fleksibel dari `NoSchedule` -- -sistem akan mencoba untuk tidak menempatkan pod yang tidak menoleransi _taint_ -pada _node_, tapi hal ini bukan merupakan sesuatu yang harus dipenuhi. Jenis ketiga +`PreferNoSchedule` merupakan "preferensi" yang lebih fleksibel dari `NoSchedule` -- +sistem akan mencoba untuk tidak menempatkan pod yang tidak menoleransi _taint_ +pada _node_, tapi hal ini bukan merupakan sesuatu yang harus dipenuhi. Jenis ketiga dari `effect` adalah `NoExecute`, akan dijelaskan selanjutnya. -Kamu dapat menerapkan beberapa _taint_ sekaligus pada _node_ atau -beberapa _toleration_ sekaligus pada sebuah _pod_. Mekanisme Kubernetes dapat -memproses beberapa _taint_ dan _toleration_ sekaligus sama halnya seperti sebuah -_filter_: memulai dengan _taint_ yang ada pada _node_, kemudian mengabaikan -_taint_ yang sesuai pada pod yang memiliki _toleration_ yang sesuai; kemudian -_taint_ yang diterapkan pada pod yang sudah disaring tadi akan menghasilkan suatu +Kamu dapat menerapkan beberapa _taint_ sekaligus pada _node_ atau +beberapa _toleration_ sekaligus pada sebuah _pod_. Mekanisme Kubernetes dapat +memproses beberapa _taint_ dan _toleration_ sekaligus sama halnya seperti sebuah +_filter_: memulai dengan _taint_ yang ada pada _node_, kemudian mengabaikan +_taint_ yang sesuai pada pod yang memiliki _toleration_ yang sesuai; kemudian +_taint_ yang diterapkan pada pod yang sudah disaring tadi akan menghasilkan suatu _effect_ pada pod. Secara khusus: -* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule` maka Kubernetes tidak akan menempatkan +* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule` maka Kubernetes tidak akan menempatkan _pod_ pada _node_ tersebut -* jika tidak terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule` -tapi terdapat setidaknya satu _taint_ yang tidak tersaring dengan -_effect_ `PreferNoSchedule` maka Kubernetes akan mencoba untuk tidak akan menempatkan +* jika tidak terdapat _taint_ yang tidak tersaring dengan _effect_ `NoSchedule` +tapi terdapat setidaknya satu _taint_ yang tidak tersaring dengan +_effect_ `PreferNoSchedule` maka Kubernetes akan mencoba untuk tidak akan menempatkan _pod_ pada _node_ tersebut -* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoExecute` maka _pod_ akan -berada dalam kondisi _evicted_ dari _node_ (jika _pod_ tersebut sudah terlanjur ditempatkan pada _node_ +* jika terdapat _taint_ yang tidak tersaring dengan _effect_ `NoExecute` maka _pod_ akan +berada dalam kondisi _evicted_ dari _node_ (jika _pod_ tersebut sudah terlanjur ditempatkan pada _node_ tersebut), dan tidak akan di-_schedule_ lagi pada _node_ tersebut. Sebagai contoh, bayangkan kamu memberikan _taint_ pada _node_ sebagai berikut: @@ -134,17 +134,17 @@ tolerations: effect: "NoExecute" ``` -Pada kasus ini, _pod_ tidak akan di-_schedule_ pada _node_, karena tidak ada -_toleration_ yang sesuai dengan _taint_ ketiga. Akan tetapi, _pod_ yang sebelumnya -sudah dijalankan di _node_ dimana _taint_ ditambahkan akan tetap jalan, karena _taint_ +Pada kasus ini, _pod_ tidak akan di-_schedule_ pada _node_, karena tidak ada +_toleration_ yang sesuai dengan _taint_ ketiga. Akan tetapi, _pod_ yang sebelumnya +sudah dijalankan di _node_ dimana _taint_ ditambahkan akan tetap jalan, karena _taint_ ketiga merupakan _taint_ yang tidak ditoleransi oleh _pod_. -Pada umumnya, jika sebuah _taint_ memiliki _effect_ `NoExecute` ditambahkan pada _node_, -maka semua pod yang tidak menoleransi _taint_ tersebut akan berada dalam _state_ -_evicted_ secara langsung, dan semua _pod_ yang menoleransi _taint_ tersebut -tidak akan berjalan seperti biasanya (tidak dalam _state_ _evicted_). Meskipun demikian, -_toleration_ dengan _effect_ `NoExecute` dapat dispesfikasikan sebagai _field_ opsional -`tolerationSeconds` yang memberikan perintah berapa lama suatu _pod_ akan berada +Pada umumnya, jika sebuah _taint_ memiliki _effect_ `NoExecute` ditambahkan pada _node_, +maka semua pod yang tidak menoleransi _taint_ tersebut akan berada dalam _state_ +_evicted_ secara langsung, dan semua _pod_ yang menoleransi _taint_ tersebut +tidak akan berjalan seperti biasanya (tidak dalam _state_ _evicted_). Meskipun demikian, +_toleration_ dengan _effect_ `NoExecute` dapat dispesfikasikan sebagai _field_ opsional +`tolerationSeconds` yang memberikan perintah berapa lama suatu _pod_ akan berada pada _node_ apabila sebuah _taint_ ditambahkan. Contohnya: ```yaml @@ -156,61 +156,61 @@ tolerations: tolerationSeconds: 3600 ``` -ini berarti apabila sebuah _pod_ sedang dalam berada dalam _state_ _running_, -kemudian sebuah _taint_ yang sesuai ditambahkan pada _node_, maka _pod_ tersebut -akan tetap berada di dalam _node_ untuk periode 3600 detik sebelum _state_-nya -berubah menjadi _evicted_. Jika _taint_ dihapus sebelum periode tersebut, maka _pod_ +ini berarti apabila sebuah _pod_ sedang dalam berada dalam _state_ _running_, +kemudian sebuah _taint_ yang sesuai ditambahkan pada _node_, maka _pod_ tersebut +akan tetap berada di dalam _node_ untuk periode 3600 detik sebelum _state_-nya +berubah menjadi _evicted_. Jika _taint_ dihapus sebelum periode tersebut, maka _pod_ tetap berjalan sebagaimana mestinya. ## Contoh Penggunaan -_Taint_ dan _toleration_ adalah mekanisme fleksibel yang digunakan untuk -memaksa _pod_ agar tidak dijadwalkan pada _node-node_ tertentu atau +_Taint_ dan _toleration_ adalah mekanisme fleksibel yang digunakan untuk +memaksa _pod_ agar tidak dijadwalkan pada _node-node_ tertentu atau mengubah _state_ _pod_ menjadi _evicted_. Berikut adalah beberapa contoh penggunaannya: -* **Node-Node yang Sifatnya _Dedicated_**: Jika kamu ingin menggunakan -sekumpulan _node_ dengan penggunaan eksklusif dari sekumpulan pengguna, -kamu dapat menambahkan _taint_ pada _node-node_ tersebut (misalnya, -`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) dan kemudian -menambahkan _toleration_ yang sesuai pada _pod-pod_ yang berada di dalamnya (hal ini -dapat dilakukan dengan mudah dengan cara menulis -[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang -bersifat khusus). _Pod-pod_ dengan _toleration_ nantinya akan diperbolehkannya untuk menggunakan -_node_ yang sudah di-_taint_ (atau dengan kata lain didedikasikan penggunaannya) maupun -_node_ lain yang ada di dalam kluster. Jika kamu ingin mendedikasikan _node_ khusus -yang hanya digunakan oleh _pod-pod_ tadi serta memastikan _pod-pod_ tadi hanya menggunakan -_node_ yang didedikasikan, maka kamu harus menambahkan sebuah _label_ yang serupa dengan -_taint_ yang diberikan pada sekelompok _node_ (misalnya, `dedicated=groupName`), dan -_admission controller_ sebaiknya menambahkan afininitas _node_ untuk memastikan _pod-pod_ +* **Node-Node yang Sifatnya _Dedicated_**: Jika kamu ingin menggunakan +sekumpulan _node_ dengan penggunaan eksklusif dari sekumpulan pengguna, +kamu dapat menambahkan _taint_ pada _node-node_ tersebut (misalnya, +`kubectl taint nodes nodename dedicated=groupName:NoSchedule`) dan kemudian +menambahkan _toleration_ yang sesuai pada _pod-pod_ yang berada di dalamnya (hal ini +dapat dilakukan dengan mudah dengan cara menulis +[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang +bersifat khusus). _Pod-pod_ dengan _toleration_ nantinya akan diperbolehkannya untuk menggunakan +_node_ yang sudah di-_taint_ (atau dengan kata lain didedikasikan penggunaannya) maupun +_node_ lain yang ada di dalam kluster. Jika kamu ingin mendedikasikan _node_ khusus +yang hanya digunakan oleh _pod-pod_ tadi serta memastikan _pod-pod_ tadi hanya menggunakan +_node_ yang didedikasikan, maka kamu harus menambahkan sebuah _label_ yang serupa dengan +_taint_ yang diberikan pada sekelompok _node_ (misalnya, `dedicated=groupName`), dan +_admission controller_ sebaiknya menambahkan afininitas _node_ untuk memastikan _pod-pod_ tadi hanya dijadwalkan pada _node_ dengan _label_ `dedicated=groupName`. -* **Node-Node dengan Perangkat Keras Khusus**: Pada suatu kluster dimana -sebagian kecuali _node_ memiliki perangkat keras khusus (misalnya GPU), kita ingin -memastikan hanya _pod-pod_ yang membutuhkan GPU saja yang dijadwalkan di _node_ dengan GPU. -Hal ini dapat dilakukan dengan memberikan _taint_ pada _node_ yang memiliki perangkat keras +* **Node-Node dengan Perangkat Keras Khusus**: Pada suatu kluster dimana +sebagian kecuali _node_ memiliki perangkat keras khusus (misalnya GPU), kita ingin +memastikan hanya _pod-pod_ yang membutuhkan GPU saja yang dijadwalkan di _node_ dengan GPU. +Hal ini dapat dilakukan dengan memberikan _taint_ pada _node_ yang memiliki perangkat keras khusus (misalnya, `kubectl taint nodes nodename special=true:NoSchedule` atau -`kubectl taint nodes nodename special=true:PreferNoSchedule`) serta menambahkan _toleration_ -yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada -kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis -[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang -bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) -untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus -dengan nama _extended resource_ dan jalankan _admission controller_ -[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration). -Setelah itu, karena _node_ yang ada sudah di-_taint_, maka tidak akan ada _pod_ yang -tidak memiliki _toleration_ yang akan dijadwalkan pada _node_ tersebut_. +`kubectl taint nodes nodename special=true:PreferNoSchedule`) serta menambahkan _toleration_ +yang sesuai pada _pod_ yang menggunakan _node_ dengan perangkat keras khusus. Seperti halnya pada +kebutuhan _dedicated_ _node_, hal ini dapat dilakukan dengan mudah dengan cara menulis +[_admission controller_](/docs/reference/access-authn-authz/admission-controllers/) yang +bersifat khusus. Misalnya, kita dapat menggunakan [_Extended Resource_](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) +untuk merepresentasikan perangkat keras khusus, kemudian _taint_ _node_ dengan perangkat keras khusus +dengan nama _extended resource_ dan jalankan _admission controller_ +[ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration). +Setelah itu, karena _node_ yang ada sudah di-_taint_, maka tidak akan ada _pod_ yang +tidak memiliki _toleration_ yang akan dijadwalkan pada _node_ tersebut_. Meskipun begitu, ketika kamu membuat suatu _pod_ yang membutuhkan _extended resource_, -maka _admission controller_ dari `ExtendedResourceToleration` akan mengoreksi -_toleration_ sehingga _pod_ tersebut dapat dijadwalkan pada _node_ dengan perangkat keras khusus. +maka _admission controller_ dari `ExtendedResourceToleration` akan mengoreksi +_toleration_ sehingga _pod_ tersebut dapat dijadwalkan pada _node_ dengan perangkat keras khusus. Dengan demikian, kamu tidak perlu menambahkan _toleration_ secara manual pada pod yang ada. -* **_Eviction_ berbasis _Taint_ (fitur beta)**: Konfigurasi _eviction_ per _pod_ -yang terjadi ketika _pod_ mengalami gangguan, hal ini akan dibahas lebih lanjut di bagian +* **_Eviction_ berbasis _Taint_ (fitur beta)**: Konfigurasi _eviction_ per _pod_ +yang terjadi ketika _pod_ mengalami gangguan, hal ini akan dibahas lebih lanjut di bagian selanjutnya. -## _Eviction_ berbasis _Taint_ +## _Eviction_ berbasis _Taint_ -Sebelumnya, kita sudah pernah membahas soal _effect_ _taint_ `NoExecute`, +Sebelumnya, kita sudah pernah membahas soal _effect_ _taint_ `NoExecute`, yang memengaruhi _pod_ yang sudah dijalankan dengan cara sebagai berikut: * _pod_ yang tidak menoleransi _taint_ akan segera diubah _state_-nya menjadi _evicted_ @@ -219,44 +219,44 @@ yang memengaruhi _pod_ yang sudah dijalankan dengan cara sebagai berikut: * _pod_ yang menoleransi _taint_ yang menspesifikasikan `tolerationSeconds` spesifikasi _toleration_ yang ada akan tetap berada di dalam _node_ hingga batas waktu tertentu -Sebagai tambahan, Kubernetes 1.6 memperkenalkan dukungan alfa untuk merepresentasikan -_node_ yang bermasalah. Dengan kata lain, _node controller_ akan secara otomatis memberikan _taint_ -pada sebuah _node_ apabila _node_ tersebut memenuhi kriteria tertentu. Berikut merupakan _taint_ -yang secara _default_ disediakan: +Sebagai tambahan, Kubernetes 1.6 memperkenalkan dukungan alfa untuk merepresentasikan +_node_ yang bermasalah. Dengan kata lain, _node controller_ akan secara otomatis memberikan _taint_ +pada sebuah _node_ apabila _node_ tersebut memenuhi kriteria tertentu. Berikut merupakan _taint_ +yang secara _default_ disediakan: - * `node.kubernetes.io/not-ready`: _Node_ berada dalam _state_ _not ready_. Hal ini terjadi apabila + * `node.kubernetes.io/not-ready`: _Node_ berada dalam _state_ _not ready_. Hal ini terjadi apabila _value_ dari _NodeCondition_ `Ready` adalah "`False`". - * `node.kubernetes.io/unreachable`: _Node_ berada dalam _state_ _unreachable_ dari _node controller_ + * `node.kubernetes.io/unreachable`: _Node_ berada dalam _state_ _unreachable_ dari _node controller_ Hal ini terjadi apabila _value_ dari _NodeCondition_ `Ready` adalah "`Unknown`". * `node.kubernetes.io/out-of-disk`: _Node_ kehabisan kapasitas _disk_. * `node.kubernetes.io/memory-pressure`: _Node_ berada diambang kapasitas memori. * `node.kubernetes.io/disk-pressure`: _Node_ berada diambang kapasitas _disk_. * `node.kubernetes.io/network-unavailable`: Jaringan pada _Node_ bersifat _unavailable_. * `node.kubernetes.io/unschedulable`: _Node_ tidak dapat dijadwalkan. - * `node.cloudprovider.kubernetes.io/uninitialized`: Ketika _kubelet_ dijalankan dengan - penyedia layanan _cloud_ "eksternal", _taint_ ini akan diterapkan pada _node_ untuk menandai - _node_ tersebut tidak digunakan. Setelah kontroler dari _cloud-controller-manager_ melakukan + * `node.cloudprovider.kubernetes.io/uninitialized`: Ketika _kubelet_ dijalankan dengan + penyedia layanan _cloud_ "eksternal", _taint_ ini akan diterapkan pada _node_ untuk menandai + _node_ tersebut tidak digunakan. Setelah kontroler dari _cloud-controller-manager_ melakukan inisiasi _node_ tersebut, maka _kubelet_ akan menghapus _taint_ yang ada. -Pada versi 1.13, fitur `TaintBasedEvictions` diubah menjadi beta dan diaktifkan secara _default_, -dengan demikian _taint-taint_ tersebut secara otomatis ditambahkan oleh _NodeController_ (atau _kubelet_) -dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ tertentu berdasarkan _value_ +Pada versi 1.13, fitur `TaintBasedEvictions` diubah menjadi beta dan diaktifkan secara _default_, +dengan demikian _taint-taint_ tersebut secara otomatis ditambahkan oleh _NodeController_ (atau _kubelet_) +dan logika normal untuk melakukan _eviction_ pada _pod_ dari suatu _node_ tertentu berdasarkan _value_ dari _Ready_ yang ada pada _NodeCondition_ dinonaktifkan. {{< note >}} -Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang -ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan -_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_ +Untuk menjaga perilaku [_rate limiting_](/docs/concepts/architecture/nodes/) yang +ada pada _eviction_ _pod_ apabila _node_ mengalami masalah, sistem sebenarnya menambahkan +_taint_ dalam bentuk _rate limiter_. Hal ini mencegah _eviction_ besar-besaran pada _pod_ pada skenario dimana master menjadi terpisah dari _node_ lainnya. {{< /note >}} -Fitur beta ini, bersamaan dengan `tolerationSeconds`, mengizinkan sebuah _pod_ -untuk menspesifikasikan berapa lama _pod_ harus tetap sesuai dengan sebuah _node_ +Fitur beta ini, bersamaan dengan `tolerationSeconds`, mengizinkan sebuah _pod_ +untuk menspesifikasikan berapa lama _pod_ harus tetap sesuai dengan sebuah _node_ apabila _node_ tersebut bermasalah. -Misalnya, sebuah aplikasi dengan banyak _state_ lokal akan lebih baik untuk tetap -berada di suatu _node_ pada saat terjadi partisi jaringan, dengan harapan partisi jaringan -tersebut dapat diselesaikan dan mekanisme _eviction_ _pod_ tidak akan dilakukan. +Misalnya, sebuah aplikasi dengan banyak _state_ lokal akan lebih baik untuk tetap +berada di suatu _node_ pada saat terjadi partisi jaringan, dengan harapan partisi jaringan +tersebut dapat diselesaikan dan mekanisme _eviction_ _pod_ tidak akan dilakukan. _Toleration_ yang ditambahkan akan berbentuk sebagai berikut: ```yaml @@ -267,41 +267,41 @@ tolerations: tolerationSeconds: 6000 ``` -Perhatikan bahwa Kubernetes secara otomatis menambahkan _toleration_ untuk +Perhatikan bahwa Kubernetes secara otomatis menambahkan _toleration_ untuk `node.kubernetes.io/not-ready` dengan `tolerationSeconds=300` kecuali konfigurasi lain disediakan oleh pengguna. -Kubernetes juga secara otomatis menambahkan _toleration_ untuk +Kubernetes juga secara otomatis menambahkan _toleration_ untuk `node.kubernetes.io/unreachable` dengan `tolerationSeconds=300` kecuali konfigurasi lain disediakan oleh pengguna. -_Toleration_ yang ditambahkan secara otomatis ini menjamin bahwa -perilaku _default_ dari suatu _pod_ adalah tetap bertahan selama 5 menit pada +_Toleration_ yang ditambahkan secara otomatis ini menjamin bahwa +perilaku _default_ dari suatu _pod_ adalah tetap bertahan selama 5 menit pada _node_ apabila salah satu masalah terdeteksi. Kedua _toleration_ _default_ tadi ditambahkan oleh [DefaultTolerationSeconds _admission controller_](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds). -_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_ +_Pod-pod_ pada [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) dibuat dengan _toleration_ `NoExecute` untuk _taint_ tanpa `tolerationSeconds`: * `node.kubernetes.io/unreachable` * `node.kubernetes.io/not-ready` -Hal ini menjamin _pod-pod_ yang merupakan bagian dari DaemonSet tidak pernah berada di dalam +Hal ini menjamin _pod-pod_ yang merupakan bagian dari DaemonSet tidak pernah berada di dalam _state_ _evicted_ apabila terjadi permasalahan pada _node_. ## _Taint_ pada _Node_ berdasarkan Kondisi Tertentu -Pada versi 1.12, fitur `TaintNodesByCondition` menjadi fitur beta, dengan demikian _lifecycle_ +Pada versi 1.12, fitur `TaintNodesByCondition` menjadi fitur beta, dengan demikian _lifecycle_ dari kontroler _node_ akan secara otomatis menambahkan _taint_ sesuai dengan kondisi _node_. -Hal yang sama juga terjadi pada _scheduler_, _scheduler_ tidak bertugas memeriksa kondisi _node_ -tetapi kondisi _taint_. Hal ini memastikan bahwa kondisi _node_ tidak memengaruhi apa -yang dijadwalkan di _node_. Pengguna dapat memilih untuk mengabaikan beberapa permasalahan yang -ada pada _node_ (yang direpresentasikan oleh kondisi _Node_) dengan menambahkan _toleration_ _Pod_ `NoSchedule`. -Sedangkan _taint_ dengan _effect_ `NoExecute` dikendalikan oleh `TaintBasedEviction` yang merupakan +Hal yang sama juga terjadi pada _scheduler_, _scheduler_ tidak bertugas memeriksa kondisi _node_ +tetapi kondisi _taint_. Hal ini memastikan bahwa kondisi _node_ tidak memengaruhi apa +yang dijadwalkan di _node_. Pengguna dapat memilih untuk mengabaikan beberapa permasalahan yang +ada pada _node_ (yang direpresentasikan oleh kondisi _Node_) dengan menambahkan _toleration_ _Pod_ `NoSchedule`. +Sedangkan _taint_ dengan _effect_ `NoExecute` dikendalikan oleh `TaintBasedEviction` yang merupakan fitur beta yang diaktifkan secara _default_ oleh Kubernetes sejak versi 1.13. -Sejak Kubernetes versi 1.8, kontroler DaemonSet akan secara otomatis -menambahkan _toleration_ `NoSchedule` pada semua _daemon_ untuk menjaga +Sejak Kubernetes versi 1.8, kontroler DaemonSet akan secara otomatis +menambahkan _toleration_ `NoSchedule` pada semua _daemon_ untuk menjaga fungsionalitas DaemonSet. * `node.kubernetes.io/memory-pressure` @@ -310,5 +310,5 @@ fungsionalitas DaemonSet. * `node.kubernetes.io/unschedulable` (versi 1.10 atau yang lebih baru) * `node.kubernetes.io/network-unavailable` (hanya untuk jaringan _host_) -Menambahkan _toleration_ ini menjamin _backward compatibility_. +Menambahkan _toleration_ ini menjamin _backward compatibility_. Kamu juga dapat menambahkan _toleration_ lain pada DaemonSet. diff --git a/content/id/docs/concepts/containers/container-environment-variables.md b/content/id/docs/concepts/containers/container-environment-variables.md index 439308c81e020..102b2b8676571 100644 --- a/content/id/docs/concepts/containers/container-environment-variables.md +++ b/content/id/docs/concepts/containers/container-environment-variables.md @@ -24,7 +24,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada ### Informasi tentang Kontainer *Hostname* sebuah Kontainer merupakan nama dari Pod dimana Kontainer dijalankan. -Informasi ini tersedia melalui perintah `hostname` atau panggilan (*function call*) +Informasi ini tersedia melalui perintah `hostname` atau panggilan (*function call*) [`gethostname`](http://man7.org/linux/man-pages/man2/gethostname.2.html) pada `libc`. Nama Pod dan *namespace* tersedia sebagai variabel *environment* melalui [API *downward*](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). diff --git a/content/id/docs/concepts/containers/container-lifecycle-hooks.md b/content/id/docs/concepts/containers/container-lifecycle-hooks.md index d92f02a417477..812bd81ec8a4b 100644 --- a/content/id/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/id/docs/concepts/containers/container-lifecycle-hooks.md @@ -16,7 +16,7 @@ untuk menjalankan kode yang di-*trigger* oleh *event* selama *lifecycle* berlang ## Ikhtisar -Kubernetes menyediakan *hook* untuk *lifecycle* Kontainer. Hal ini sejalan dengan *framework* bahasa +Kubernetes menyediakan *hook* untuk *lifecycle* Kontainer. Hal ini sejalan dengan *framework* bahasa pemrograman pada umumnya yang memiliki *hook* untuk *lifecycle* komponen, seperti Angular contohnya. *Hook* tersebut digunakan Kontainer untuk selalu siap menerima *event* selama *lifecycle* dan menjalankan kode yang diimplementasi pada suatu *handler*, ketika *hook lifecycle* terkait telah dieksekusi. @@ -62,7 +62,7 @@ atau *hang*, Kontainer tersebut tidak bisa sampai ke *state* `running`. Perilaku ini mirip dengan yang terjadi pada *hook* `PreStop`. Jika *hook* terlalu lama atau *hang* saat dieksekusi, Pod tersebut tetap ada pada *state* `Terminating` -dan akan dimatikan setelah `terminationGracePeriodSeconds` Pod selesai. +dan akan dimatikan setelah `terminationGracePeriodSeconds` Pod selesai. Jika sebuah *hook* `PostStart` atau `PreStop` gagal dieksekusi, Kontainer akan dimatikan. Para pengguna sangat disarankan membuat *handler* untuk *hook* seringan mungkin (*lightweight*). @@ -72,7 +72,7 @@ suatu perintah, misalnya saat proses penyimpanan *state* sebelum Kontainer dimat ### Jaminan pengiriman *hook* Proses pengiriman *hook* akan dilakukan **paling tidak satu kali**. -Artinya suatu *hook* boleh dipanggil beberapa kali untuk *event* yang sama, +Artinya suatu *hook* boleh dipanggil beberapa kali untuk *event* yang sama, seperti dalam `PostStart` atau`PreStop`. Namun begitu, implementasi *hook* masing-masing harus memastikan bagaimana menangani kasus ini dengan benar. diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md index ed6b83f70c9bd..9fdcfbaf31626 100644 --- a/content/id/docs/concepts/containers/runtime-class.md +++ b/content/id/docs/concepts/containers/runtime-class.md @@ -53,7 +53,7 @@ Nama _handler_ harus berupa valid label 1123 DNS (alfanumerik + karakter `-`). #### 2. Buat _resource_ `RuntimeClass` yang terkait -Masing-masing konfigurasi pada langkah no.1 punya nama `handler` yang merepresentasikan +Masing-masing konfigurasi pada langkah no.1 punya nama `handler` yang merepresentasikan konfigurasi-konfigurasi tersebut. Untuk masing-masing `handler`, buatlah sebuah objek RuntimeClass terkait. _Resource_ RuntimeClass saat ini hanya memiliki 2 _field_ yang penting: nama RuntimeClass tersebut @@ -69,8 +69,8 @@ handler: myconfiguration # Nama dari konfigurasi CRI terkait ``` {{< note >}} -Sangat disarankan untuk hanya memperbolehkan admin kluster melakukan operasi -_write_ pada RuntimeClass. Biasanya ini sudah jadi _default_. Lihat [Ikhtisar +Sangat disarankan untuk hanya memperbolehkan admin kluster melakukan operasi +_write_ pada RuntimeClass. Biasanya ini sudah jadi _default_. Lihat [Ikhtisar Autorisasi](/docs/reference/access-authn-authz/authorization/) untuk penjelasan lebih jauh. {{< /note >}} @@ -154,7 +154,7 @@ pembaruan fitur RuntimeClass dari versi alpha ke versi beta: ``` kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io ``` -- Fitur Alpha pada RuntimeClass akan menjadi tidak valid, jika `runtimeHandler` tidak ditentukan atau +- Fitur Alpha pada RuntimeClass akan menjadi tidak valid, jika `runtimeHandler` tidak ditentukan atau kosong atau menggunakan karakter `.` pada _handler_. Ini harus dimigrasi ke _handler_ dengan konfigurasi yang valid (lihat petunjuk di atas). diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md index 093d3d48b844d..3c79f29a83feb 100644 --- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md @@ -48,7 +48,7 @@ Sebagai hasilnya, kebanyakan pengguna Kubernetes perlu menginstal perluasan dan ## 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. +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 kluster atau di luar kluster. Dengan mengikuti panduan di dalam dokumen ini, kamu dapat menulis otomasi yang sangat tersedia dan kuat. diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md index bbdf5edbc46f4..b23e7bd6cfee5 100644 --- a/content/id/docs/concepts/overview/components.md +++ b/content/id/docs/concepts/overview/components.md @@ -2,13 +2,13 @@ title: Komponen-Komponen Kubernetes content_template: templates/concept weight: 20 -card: +card: name: concepts weight: 20 --- {{% capture overview %}} -Dokumen ini merupakan ikhtisar yang mencakup berbagai komponen +Dokumen ini merupakan ikhtisar yang mencakup berbagai komponen yang dibutuhkan agar kluster Kubernetes dapat berjalan secara fungsional. {{% /capture %}} @@ -20,13 +20,13 @@ Komponen master menyediakan control plane bagi kluster. Komponen ini berperan dalam proses pengambilan secara global pada kluster (contohnya, mekanisme schedule), serta berperan dalam proses deteksi serta pemberian respons terhadap events yang berlangsung di dalam kluster -(contohnya, penjadwalan pod baru apabila jumlah replika yang ada pada +(contohnya, penjadwalan pod baru apabila jumlah replika yang ada pada replication controller tidak terpenuhi). -Komponen master dapat dijalankan di mesin manapun yang ada di kluster. Meski begitu, -untuk memudahkan proses yang ada, script inisiasi awal yang dijalankan -biasanya memulai komponen master pada mesin yang sama, serta tidak menjalankan -kontainer bagi pengguna di mesin ini. Contoh konfigurasi multi-master VM +Komponen master dapat dijalankan di mesin manapun yang ada di kluster. Meski begitu, +untuk memudahkan proses yang ada, script inisiasi awal yang dijalankan +biasanya memulai komponen master pada mesin yang sama, serta tidak menjalankan +kontainer bagi pengguna di mesin ini. Contoh konfigurasi multi-master VM dapat dilihat di modul [Membangun Kluster HA] (/docs/admin/high-availability/). @@ -51,31 +51,31 @@ dapat dilihat di modul [Membangun Kluster HA] (/docs/admin/high-availability/). Kontroler-kontroler ini meliputi: - * Kontroler Node : Bertanggung jawab untuk mengamati dan memberikan + * Kontroler Node : Bertanggung jawab untuk mengamati dan memberikan respons apabila jumlah node berkurang. * Kontroler Replikasi : Bertanggung jawab untuk menjaga jumlah pod agar jumlahnya sesuai dengan kebutuhan setiap objek kontroler replikasi yang ada di sistem. - * Kontroler Endpoints : Menginisiasi objek Endpoints + * Kontroler Endpoints : Menginisiasi objek Endpoints (yang merupakan gabungan Pods dan Services). - * Kontroler Service Account & Token: Membuat akun dan + * Kontroler Service Account & Token: Membuat akun dan akses token API standar untuk setiap namespaces yang dibuat. ### cloud-controller-manager -[Cloud-controller-manager](/en/docs/tasks/administer-cluster/running-cloud-controller/) merupakan kontroler yang berinteraksi dengan penyedia layanan cloud. -Kontroler ini merupakat fitur alfa yang diperkenalkan pada Kubernetes versi 1.6. +[Cloud-controller-manager](/en/docs/tasks/administer-cluster/running-cloud-controller/) merupakan kontroler yang berinteraksi dengan penyedia layanan cloud. +Kontroler ini merupakat fitur alfa yang diperkenalkan pada Kubernetes versi 1.6. -Cloud-controller-manager hanya menjalankan iterasi kontroler cloud-provider-specific . -Kamu harus menonaktifkan iterasi kontroler ini pada kube-controller-manager. -Kamu dapat menonaktifka iterasi kontroler ini dengan mengubah nilai argumen `--cloud-provider` dengan `external` +Cloud-controller-manager hanya menjalankan iterasi kontroler cloud-provider-specific . +Kamu harus menonaktifkan iterasi kontroler ini pada kube-controller-manager. +Kamu dapat menonaktifka iterasi kontroler ini dengan mengubah nilai argumen `--cloud-provider` dengan `external` ketika menginisiasi kube-controller-manager. Adanya cloud-controller-manager memungkinkan kode yang dimiliki oleh penyedia layanan cloud dan kode yang ada pada Kubernetes saling tidak bergantung selama masa development. Pada versi sebelumnya, Kubernetes bergantung pada fungsionalitas spesifik yang disediakan oleh penyedia layanan cloud. Di masa mendatang, kode yang secara spesifik dimiliki oleh -penyedia layanan cloud akan dipelihara oleh penyedia layanan cloud itu sendiri, +penyedia layanan cloud akan dipelihara oleh penyedia layanan cloud itu sendiri, kode ini selanjutnya akan dihubungkan dengan cloud-controller-manager ketika Kubernetes dijalankan. Kontroler berikut ini memiliki keterkaitan dengan penyedia layanan cloud: @@ -84,11 +84,11 @@ Kontroler berikut ini memiliki keterkaitan dengan penyedia layanan cloud: * Kontroler Route : Melakukan pengaturan awal route yang ada pada penyedia layanan cloud * Kontroler Service : Untuk membuat, memperbaharui, menghapus load balancer yang disediakan oleh penyedia layanan cloud * Kontroler Volume : Untuk membuat, meng-attach, dan melakukan mount volume serta melakukan inetraksi dengan penyedia layanan cloud untuk melakukan orkestrasi volume - - + + ## Komponen Node -Komponen ini ada pada setiap node, fungsinya adalah melakukan pemeliharaan terhadap pod serta menyediakan environment runtime bagi Kubernetes. +Komponen ini ada pada setiap node, fungsinya adalah melakukan pemeliharaan terhadap pod serta menyediakan environment runtime bagi Kubernetes. ### kubelet @@ -103,7 +103,7 @@ Komponen ini ada pada setiap node, fungsinya adalah melakukan pemeliharaa ### Container Runtime -Container runtime adalah perangkat lunak yang bertanggung jawab dalam menjalankan kontainer. +Container runtime adalah perangkat lunak yang bertanggung jawab dalam menjalankan kontainer. Kubernetes mendukung beberapa runtime, diantaranya adalah: [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) dan semua implementasi [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). @@ -116,35 +116,35 @@ Beberapa addons akan dijelaskan selanjutnya. ### DNS -Meskipun tidak semua addons dibutuhkan, semua kluster Kubernetes hendaknya +Meskipun tidak semua addons dibutuhkan, semua kluster Kubernetes hendaknya memiliki DNS kluster. Komponen ini penting karena banyak dibutuhkan oleh komponen -lainnya. +lainnya. -[Kluster DNS](/en/docs/concepts/cluster-administration/addons/ ) adalah server DNS, selain beberapa server DNS lain yang sudah ada di +[Kluster DNS](/en/docs/concepts/cluster-administration/addons/ ) adalah server DNS, selain beberapa server DNS lain yang sudah ada di environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services -Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini +Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini ke dalam mekanisme pencarian DNS yang dimilikinya. ### Web UI (Dasbor) [Dasbor](/en/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada kluster Kubernetes. -Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting kluster maupun +Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting kluster maupun aplikasi yang ada pada kluster itu sendiri. ### Container Resource Monitoring -[Container Resource Monitoring](/en/docs/tasks/debug-application-cluster/resource-usage-monitoring/) mencatat metrik time-series yang diperoleh +[Container Resource Monitoring](/en/docs/tasks/debug-application-cluster/resource-usage-monitoring/) mencatat metrik time-series yang diperoleh dari kontainer ke dalam basis data serta menyediakan antar muka yang dapat digunakan untuk melakukan pencarian data yang dibutuhkan. ### Cluster-level Logging -[Cluster-level logging](/en/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada -penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan +[Cluster-level logging](/en/docs/concepts/cluster-administration/logging/) bertanggung jawab mencatat log kontainer pada +penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan pencarian. {{% /capture %}} diff --git a/content/id/docs/concepts/overview/kubernetes-api.md b/content/id/docs/concepts/overview/kubernetes-api.md index e997b0c59aaf3..03b2a34ba57f7 100644 --- a/content/id/docs/concepts/overview/kubernetes-api.md +++ b/content/id/docs/concepts/overview/kubernetes-api.md @@ -2,7 +2,7 @@ title: API Kubernetes content_template: templates/concept weight: 30 -card: +card: name: concepts weight: 30 --- @@ -19,7 +19,7 @@ API Kubernetes juga berperan sebagai skema konfigurasi yang deklaratif di dalam Kubernetes menyimpan bentuk terserialisasi dari obyek API yang dimilikinya di dalam [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/). -Kubernetes sendiri dibagi menjadi beberapa komponen yang saling dapat saling interaksi melalui API. +Kubernetes sendiri dibagi menjadi beberapa komponen yang saling dapat saling interaksi melalui API. {{% /capture %}} @@ -28,14 +28,14 @@ Kubernetes sendiri dibagi menjadi beberapa komponen yang saling dapat saling int ## Perubahan API -Berdasarkan pengalaman kami, semua sistem yang berhasil memerlukan kebutuhan +Berdasarkan pengalaman kami, semua sistem yang berhasil memerlukan kebutuhan untuk terus tumbuh dan berkembang seiring dengan bertambahnya kebutuhan -yang ada. Dengan demikian, kami berekspektasi bahwa API akan selalu berubah seiring dengan bertambahnya kebutuhan yang ada. -Meski begitu, perubahan yang ada akan selalu kompatibel dengan implementasi sebelumnya, untuk jangka waktu tertentu. -Secara umum, penambahan pada sebuah resource API atau field resource bisa sering terjadi.. Penghapusan resource API atau suatu field, di sisi lain, +yang ada. Dengan demikian, kami berekspektasi bahwa API akan selalu berubah seiring dengan bertambahnya kebutuhan yang ada. +Meski begitu, perubahan yang ada akan selalu kompatibel dengan implementasi sebelumnya, untuk jangka waktu tertentu. +Secara umum, penambahan pada sebuah resource API atau field resource bisa sering terjadi.. Penghapusan resource API atau suatu field, di sisi lain, diharapkan untuk dapat memenuhi [kaidah deprecation API](/docs/reference/using-api/deprecation-policy/). -Hal-hal apa saja yang perlu diperhatikan untuk menjamin kompatibilitas API +Hal-hal apa saja yang perlu diperhatikan untuk menjamin kompatibilitas API secara rinci dibahas di dalam [dokumentasi perubahan API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md). ## Swagger and OpenAPI Definition @@ -48,11 +48,11 @@ Format request dapat diterapkan dengan cara menambahkan header HTTPcontent-type standar yang digunakan adalah `application/json` untuk `*/*`) -Accept-Encoding | `gzip` +Accept-Encoding | `gzip` -Sebelum versi 1.14, terdapat 4 buah endpoint yang menyediakan spesifikasi OpenAPI -dalam format berbeda yang dapat digunakan (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`). -Endpoint ini bersifat deprecated dan akan dihapus pada Kubernetes versi 1.14. +Sebelum versi 1.14, terdapat 4 buah endpoint yang menyediakan spesifikasi OpenAPI +dalam format berbeda yang dapat digunakan (`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`). +Endpoint ini bersifat deprecated dan akan dihapus pada Kubernetes versi 1.14. **Cara mendapatkan spesifikasi OpenAPI**: @@ -62,54 +62,54 @@ GET /swagger.json | GET /openapi/v2 **Accept**: application/json GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip -Kubernetes juga menyediakan alternatif mekanisme serialisasi lain, -yaitu dengan menggunakan Protobuf, yang secara umum digunakan untuk mekanisme komunikasi -intra-kluster, hal ini didokumentasikan di dalam [proposal desain](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) -serta berkas IDL sebagai bentuk spesifikasi skema berada dalam package Go +Kubernetes juga menyediakan alternatif mekanisme serialisasi lain, +yaitu dengan menggunakan Protobuf, yang secara umum digunakan untuk mekanisme komunikasi +intra-kluster, hal ini didokumentasikan di dalam [proposal desain](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) +serta berkas IDL sebagai bentuk spesifikasi skema berada dalam package Go -Sebelum Kubernetes versi 1.14, apiserver Kubernetes juga mengekspos API +Sebelum Kubernetes versi 1.14, apiserver Kubernetes juga mengekspos API yang dapat digunakan untuk mendapatkan spesifikasi [Swagger v1.2](http://swagger.io/) pada endpoint `/swaggerapi`. -Endpoint ini akan sudah bersifat deprecated dan akan dihapus pada -Kubernetes versi 1.14. +Endpoint ini akan sudah bersifat deprecated dan akan dihapus pada +Kubernetes versi 1.14. ## Pemberian Versi pada API -Untuk memudahkan restrukturisasi field dan resource yang ada, -Kubernetes menyediakan beberapa versi API yang berada pada path yang berbeda, +Untuk memudahkan restrukturisasi field dan resource yang ada, +Kubernetes menyediakan beberapa versi API yang berada pada path yang berbeda, misalnya `/api/v1` atau `/apis/extensions/v1beta1`. -Kita dapat memilih versi yang akan digunakan pada tingkatan API -dan bukan pada tingkatan field atau resource untuk memastikan -API yang digunakan memperlihatkan gambaran yang jelas serta konsisten +Kita dapat memilih versi yang akan digunakan pada tingkatan API +dan bukan pada tingkatan field atau resource untuk memastikan +API yang digunakan memperlihatkan gambaran yang jelas serta konsisten mengenai resoure dan sifat sistem yang ada. Perhatikan bahwa pemberian versi pada API dan pemberian versi pada API dan perangkat lunak memiliki keterkaitan secara tak langsung. Proposal [API and release -versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) memberikan deskripsi keterkaitan antara +versioning](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) memberikan deskripsi keterkaitan antara pemberian versi pada API dan pemberian versi pada perangkat lunak. -API dengan versi yang berbeda menunjukan tingkatan kestabilan dan ketersediaan yang diberikan pada versi tersebut. -Kriteria untuk setiap tingkatan dideskripsikan secara lebih detail di dalam +API dengan versi yang berbeda menunjukan tingkatan kestabilan dan ketersediaan yang diberikan pada versi tersebut. +Kriteria untuk setiap tingkatan dideskripsikan secara lebih detail di dalam [dokumentasi perubahan API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). They are summarized here: - Tingkatan Alpha: - Nama dari versi ini mengandung string `alpha` (misalnya, `v1alpha1`). - - Bisa jadi terdapat bug. Secara default fitur ini tidak diekspos. - - Ketersediaan untuk fitur yang ada bisa saja dihilangkan pada suatu waktu tanpa pemberitahuan sebelumnya. + - Bisa jadi terdapat bug. Secara default fitur ini tidak diekspos. + - Ketersediaan untuk fitur yang ada bisa saja dihilangkan pada suatu waktu tanpa pemberitahuan sebelumnya. - API yang ada mungkin saja berubah tanpa memperhatikan kompatibilitas dengan versi perangkat lunak sebelumnya. - - Hanya direkomendasikan untuk kluster yang digunakan untuk tujuan testing. + - Hanya direkomendasikan untuk kluster yang digunakan untuk tujuan testing. - Tingkatan Beta: - Nama dari versi ini mengandung string `beta` (misalnya `v2beta3`). - Kode yang ada sudah melalui mekanisme testing yang cukup baik. Menggunakan fitur ini dianggap cukup aman. Fitur ini diekspos secara default. - - Ketersediaan untuk fitur secara menyeluruh tidak akan dihapus, meskipun begitu detail untuk suatu fitur bisa saja berubah. - - Skema dan/atau semantik dari suatu obyek mungkin saja berubah tanpa memerhatikan kompatibilitas pada rilis beta selanjutnya. - Jika hal ini terjadi, kami akan menyediakan suatu instruksi untuk melakukan migrasi di versi rilis selanjutnya. hal ini bisa saja terdiri dari penghapusan, pengubahan, ataupun pembuatan + - Ketersediaan untuk fitur secara menyeluruh tidak akan dihapus, meskipun begitu detail untuk suatu fitur bisa saja berubah. + - Skema dan/atau semantik dari suatu obyek mungkin saja berubah tanpa memerhatikan kompatibilitas pada rilis beta selanjutnya. + Jika hal ini terjadi, kami akan menyediakan suatu instruksi untuk melakukan migrasi di versi rilis selanjutnya. hal ini bisa saja terdiri dari penghapusan, pengubahan, ataupun pembuatan obyek API. Proses pengubahan mungkin saja membutuhkan pemikiran yang matang. Dampak proses ini bisa saja menyebabkan downtime aplikasi yang bergantung pada fitur ini. - Disarankan hanya untuk digunakan untuk penggunaan yang untuk penggunaan yang tidak berdampak langsung pada bisnis kamu. - **Kami mohon untuk mencoba versi beta yang kami sediakan dan berikan masukan terhadap fitur yang kamu pakai! Apabila fitur tersebut sudah tidak lagi berada di dalam tingkatan beta perubahan yang kami buat terhadap fitur tersebut bisa jadi tidak lagi dapat digunakan** - Tingkatan stabil: - Nama dari versi ini mengandung string `vX` dimana `X` merupakan bilangan bulat. - - Fitur yang ada pada tingkatan ini akan selalu muncul di rilis berikutnya. + - Fitur yang ada pada tingkatan ini akan selalu muncul di rilis berikutnya. ## API groups @@ -135,19 +135,19 @@ Ekstensi API dengan custom resources dapat dilakukan melalui dua buah path: ## Mengaktifkan API groups -Beberapa resources dan API groups sudah diaktifkan secara default. +Beberapa resources dan API groups sudah diaktifkan secara default. Resource dan API groups ini dapat diaktifkan dan dinonaktifkan dengan mengatur penanda `--runtime-config` pada apiserver. `--runtime-config` menerima nilai yang dipisahkan oleh koma. Sebagai contoh: untuk menonaktifkan batch/v1, tetapkan `--runtime-config=batch/v1=false`, untuk mengaktifkan batch/v2alpha1, tetapkan `--runtime-config=batch/v2alpha1`. Penanda menerima nilai yang dipisahkan oleh pasangan `key=value` yang mendeskripsikan konfigurasi runtime pada apiserver. -PENTING: Melakukan proses mengaktifkan atau menonaktifkan groups atau resources +PENTING: Melakukan proses mengaktifkan atau menonaktifkan groups atau resources membutuhkan mekanisme restart apiserver dan controller-manager agar apiserver dapat menerima perubahan `--runtime-config`. ## Mengaktifkan resources di dalam groups -DaemonSets, Deployments, HorizontalPodAutoscalers, +DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs, dan ReplicaSets diaktifkan secara default. Ekstensi lain dapat diaktifkan penanda `--runtime-config` pada apiserver. Penanda `--runtime-config` menerima nilai yang dipisahkan oleh koma. Sebagai contoh untuk menonaktifkan deployments dan ingress, tetapkan. diff --git a/content/id/docs/concepts/overview/what-is-kubernetes.md b/content/id/docs/concepts/overview/what-is-kubernetes.md index 7d91265dda993..9a44701803089 100644 --- a/content/id/docs/concepts/overview/what-is-kubernetes.md +++ b/content/id/docs/concepts/overview/what-is-kubernetes.md @@ -2,7 +2,7 @@ title: Apa itu Kubernetes? content_template: templates/concept weight: 10 -card: +card: name: concepts weight: 10 --- @@ -13,14 +13,14 @@ Laman ini merupakan ikhtisar Kubernetes. {{% capture body %}} Kubernetes merupakan platform open-source yang digunakan untuk melakukan -manajemen workloads aplikasi yang dikontainerisasi, serta menyediakan -konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem -yang besar dan berkembang cepat. Service, support, dan perkakas +manajemen workloads aplikasi yang dikontainerisasi, serta menyediakan +konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem +yang besar dan berkembang cepat. Service, support, dan perkakas Kubernetes tersedia secara meluas. -Google membuka Kubernetes sebagai proyek open source pada tahun 2014. -Kubernetes dibangun berdasarkan [pengalaman Google selama satu setengah dekade dalam menjalankan workloads](https://research.google.com/pubs/pub43438.html) -bersamaan dengan kontribusi berupa ide-ide terbaik yang diberikan oleh komunitas. +Google membuka Kubernetes sebagai proyek open source pada tahun 2014. +Kubernetes dibangun berdasarkan [pengalaman Google selama satu setengah dekade dalam menjalankan workloads](https://research.google.com/pubs/pub43438.html) +bersamaan dengan kontribusi berupa ide-ide terbaik yang diberikan oleh komunitas. ## Mengapa Kubernetes dan hal apa saja yang dapat dilakukan oleh Kubernetes? @@ -28,119 +28,119 @@ Kubernetes memiliki sejumlah fitur yang dapat dijabarkan sebagai berikut: - platform kontainer - platform microservices -- platform cloud yang tidak mudah dipindahkan +- platform cloud yang tidak mudah dipindahkan -Kubernetes menyediakan manajemen environment yang berpusat pada kontainer. -Kubernetes melakukan orkestrasi terhadap computing, networking, -dan inftrastruktur penyimpanan. Fitur inilah yang kemudian membuat konsep Platform as a Service (PaaS) +Kubernetes menyediakan manajemen environment yang berpusat pada kontainer. +Kubernetes melakukan orkestrasi terhadap computing, networking, +dan inftrastruktur penyimpanan. Fitur inilah yang kemudian membuat konsep Platform as a Service (PaaS) menjadi lebih sederhana dilengkapi dengan fleksibilitas yang dimiliki oleh Infrastructure as a Service (IaaS). -## Lalu apa yang menyebabkan Kubernetes disebut sebagai sebuah platform? +## Lalu apa yang menyebabkan Kubernetes disebut sebagai sebuah platform? -Meskipun Kubernetes menyediakan banyak fungsionalitas, selalu ada keadaan dimana -hal tersebut membutuhkan fitur baru. Workflow spesifik yang terkait dengan -proses pengembangan aplikasi dapat ditambahkan pada streamline untuk meningkatkan -produktivitas developer. Orkestrasi ad-hoc yang dapat diterima biasanya membutuhkan desain -otomatisasi yang kokoh agar bersifat scalable. Hal inilah yang membuat -Kubernetes juga didesain sebagai platform untuk membangun ekosistem komponen dan -dan perkakas untuk memudahkan proses deployment, scale, dan juga manajemen -aplikasi. +Meskipun Kubernetes menyediakan banyak fungsionalitas, selalu ada keadaan dimana +hal tersebut membutuhkan fitur baru. Workflow spesifik yang terkait dengan +proses pengembangan aplikasi dapat ditambahkan pada streamline untuk meningkatkan +produktivitas developer. Orkestrasi ad-hoc yang dapat diterima biasanya membutuhkan desain +otomatisasi yang kokoh agar bersifat scalable. Hal inilah yang membuat +Kubernetes juga didesain sebagai platform untuk membangun ekosistem komponen dan +dan perkakas untuk memudahkan proses deployment, scale, dan juga manajemen +aplikasi. -[Labels]() memudahkan pengguna mengkategorisasikan resources yang mereka miliki -sesuai dengan kebutuhan. [Annotations]() memungkinkan pengguna untuk menambahkan informasi -tambahan pada resource yang dimiliki. +[Labels]() memudahkan pengguna mengkategorisasikan resources yang mereka miliki +sesuai dengan kebutuhan. [Annotations]() memungkinkan pengguna untuk menambahkan informasi +tambahan pada resource yang dimiliki. -Selain itu, [Kubernetes control plane]() dibuat berdasarkan -[API](/docs/reference/using-api/api-overview/) yang tersedia bagi pengguna dan developer. Pengguna +Selain itu, [Kubernetes control plane]() dibuat berdasarkan +[API](/docs/reference/using-api/api-overview/) yang tersedia bagi pengguna dan developer. Pengguna dapat mengimplementasikan kontroler sesuai dengan kebutuhan mereka, contohnya adalah [schedulers](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), -dengan [API kustom yang mereka miliki](), kontroler kustom ini kemudian dapat digunakan +dengan [API kustom yang mereka miliki](), kontroler kustom ini kemudian dapat digunakan pada [command-line tool]() generik yang ada. [Desain](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) -inilah yang memungkinkan beberapa sistem lain untuk dapat dibangun di atas Kubernetes. +inilah yang memungkinkan beberapa sistem lain untuk dapat dibangun di atas Kubernetes. ## Lalu hal apakah yang tidak termasuk di dalam Kubernetes? Kubernetes bukanlah sebuah PaaS (Platform as a -Service) yang biasanya. Meskipun Kubernetes dijalankan pada tingkatan kontainer -dan bukan pada tingkatan perangkat keras, Kubernetes menyediakan beberapa fitur -yang biasanya disediakan oleh Paas, seperti deployment, scaling, -load balancing, logging, dan monitoring. Akan tetapi, -Kubernetes bukanlah sistem monolitik, melainkan suatu sistem yang bersifat sebagai -bulding block dan pluggable yang dapat digunakan untuk membangun sebuah +Service) yang biasanya. Meskipun Kubernetes dijalankan pada tingkatan kontainer +dan bukan pada tingkatan perangkat keras, Kubernetes menyediakan beberapa fitur +yang biasanya disediakan oleh Paas, seperti deployment, scaling, +load balancing, logging, dan monitoring. Akan tetapi, +Kubernetes bukanlah sistem monolitik, melainkan suatu sistem yang bersifat sebagai +bulding block dan pluggable yang dapat digunakan untuk membangun sebuah platform yang dibutuhkan oleh developer dengan tetap mengutamakan konsep fleksibilitas. Kubernetes: -* Tidak melakukan limitasi terhadap aplikasi yang di-support. Kubernetes bertujuan - untuk mendukung berbagai variasi workloads, termasuk - stateless, stateful, dan data-processing. Jika sebuah - aplikasi dapat dijalankan di atas kontainer, maka aplikasi tersebut juga dapat - dijalankan di atas Kubernetes. -* Tidak menyediakan mekanisme untuk melakukan deploy kode sumber - maupun mekanisme build sebuah aplikasi. Continuous Integration, Delivery, and Deployment - (CI/CD) workflows ditentukan oleh preferensi serta kebutuhan teknis organisasi. +* Tidak melakukan limitasi terhadap aplikasi yang di-support. Kubernetes bertujuan + untuk mendukung berbagai variasi workloads, termasuk + stateless, stateful, dan data-processing. Jika sebuah + aplikasi dapat dijalankan di atas kontainer, maka aplikasi tersebut juga dapat + dijalankan di atas Kubernetes. +* Tidak menyediakan mekanisme untuk melakukan deploy kode sumber + maupun mekanisme build sebuah aplikasi. Continuous Integration, Delivery, and Deployment + (CI/CD) workflows ditentukan oleh preferensi serta kebutuhan teknis organisasi. * Tidak menyediakan application-level services, seperti middleware (e.g., message buses), data-processing frameworks (for example, Spark), databases (e.g., mysql), caches, maupun cluster storage systems (e.g., Ceph) sebagai suatu built-in services. Komponen tersebut dapat dijalankan di atas Kubernetes, dan/atau - dapat diakses oleh aplikasi yang dijalankan di atas Kubernetes melalui sebuah mekanisme tidak mudah dipindahkan + dapat diakses oleh aplikasi yang dijalankan di atas Kubernetes melalui sebuah mekanisme tidak mudah dipindahkan misalnya saja Open Service Broker. -* Tidak membatasi penyedia layanan logging, monitoring, maupun alerting yang digunakan. - Kubernetes menyediakan proof of concept dan mekanisme integrasi yang dapat digunakan +* Tidak membatasi penyedia layanan logging, monitoring, maupun alerting yang digunakan. + Kubernetes menyediakan proof of concept dan mekanisme integrasi yang dapat digunakan untuk mengumpulkan serta mengekspor metriks yang ada. * Tidak menyediakan atau mengharuskan penggunaan configuration language/system (e.g., - [jsonnet](https://github.com/google/jsonnet)). Kubernetes menyediakan suatu API deklaratif - yang dapat digunakan oleh berbagai jenis spesifikasi deklaratif. -* Tidak menyediakan atau mengadaptasi sebuah konfigurasi, maintenance, manajemen, atau - self-healing mesin dengan spesifikasi khusus. + [jsonnet](https://github.com/google/jsonnet)). Kubernetes menyediakan suatu API deklaratif + yang dapat digunakan oleh berbagai jenis spesifikasi deklaratif. +* Tidak menyediakan atau mengadaptasi sebuah konfigurasi, maintenance, manajemen, atau + self-healing mesin dengan spesifikasi khusus. Sebagai tambahan, Kubernetes bukanlah sebuah *sitem orkestrasi biasa*. Bahkan pada kenyataannya, -Kubernetes menghilangkan kebutuhan untuk melakukan orkestrasi. Definisi teknis dari -*orkestrasi* merupakan eksekusi dari sebuah workflow yang sudah didefinisikan sebelumnya: pertama kerjakan A, kemudian B, -dan terakhir C. Sebaliknya, Kubernetes disusun oleh seperangkat -proses kontrol yang dapat idekomposisi yang selalu menjalankan state yang ada -saat ini hingga sesuai dengan state yang dinginkan. -Kita tidak perlu peduli proses apa saja yang perlu dilakukan untuk melakukan A hingga C. -Mekanisme kontrol yang tersentralisasi juga tidak dibutuhkan. Dengan demikian, sistem yang -dihasilkan lebih mudah digunakan lebih kokoh, serta lebih extensible. +Kubernetes menghilangkan kebutuhan untuk melakukan orkestrasi. Definisi teknis dari +*orkestrasi* merupakan eksekusi dari sebuah workflow yang sudah didefinisikan sebelumnya: pertama kerjakan A, kemudian B, +dan terakhir C. Sebaliknya, Kubernetes disusun oleh seperangkat +proses kontrol yang dapat idekomposisi yang selalu menjalankan state yang ada +saat ini hingga sesuai dengan state yang dinginkan. +Kita tidak perlu peduli proses apa saja yang perlu dilakukan untuk melakukan A hingga C. +Mekanisme kontrol yang tersentralisasi juga tidak dibutuhkan. Dengan demikian, sistem yang +dihasilkan lebih mudah digunakan lebih kokoh, serta lebih extensible. ## Mengapa kontainer? -Mencari alasan kenapa kita harus menggunakan kontainer? +Mencari alasan kenapa kita harus menggunakan kontainer? ![Mengapa kontainer?](/images/docs/why_containers.svg) -*Cara Lama* untuk melakukan mekanisme deploy suatu aplikasi -adalah dengan cara instalasi aplikasi tersebut pada sebuah mesin -dengan menggunakan package manager yang dimiliki oleh sistem operasi -mesin tersebut. Hal ini menciptakan suatu ketergantungan antara executables, -konfigurasi, serta ketergantungan lain yang dibutuhkan aplikasi dengan sistem operasi -yang digunakan oleh mesin. Untuk mengatasi hal ini, tentunya bisa saja kita melakukan -mekanisme build suatu image VM yang immutable untuk mendapatkan -mekanisme rollouts dan rollback yang dapat diprediksi. -Meskipun demikian, VM masih dianggap "berat" dan tidak tidak mudah dipindahkan. - -*Cara Baru* adalah dengan melakukan mekanisme deploy kontainer pada tingkatan -virtualisasi di level sistem operasi (OS) bukan pada tingkatan virtualisasi perangkat keras. -Kontainer ini berada dalam lingkungan yang terisolasi satu sama lain serta terisolasi dengan +*Cara Lama* untuk melakukan mekanisme deploy suatu aplikasi +adalah dengan cara instalasi aplikasi tersebut pada sebuah mesin +dengan menggunakan package manager yang dimiliki oleh sistem operasi +mesin tersebut. Hal ini menciptakan suatu ketergantungan antara executables, +konfigurasi, serta ketergantungan lain yang dibutuhkan aplikasi dengan sistem operasi +yang digunakan oleh mesin. Untuk mengatasi hal ini, tentunya bisa saja kita melakukan +mekanisme build suatu image VM yang immutable untuk mendapatkan +mekanisme rollouts dan rollback yang dapat diprediksi. +Meskipun demikian, VM masih dianggap "berat" dan tidak tidak mudah dipindahkan. + +*Cara Baru* adalah dengan melakukan mekanisme deploy kontainer pada tingkatan +virtualisasi di level sistem operasi (OS) bukan pada tingkatan virtualisasi perangkat keras. +Kontainer ini berada dalam lingkungan yang terisolasi satu sama lain serta terisolasi dengan mesin dimana kontainer ini berada. Kontainer ini memiliki filesystems masing-masing. -Selain itu, setiap kontainer tidak dapat "melihat" process yang sedang dijalankan di -kontainer lain. Selain itu resource komputasi yang digunakan oleh kontainer -ini juga dapat dibatasi. Kontainer juga dapat dengan lebih mudah di-build jika +Selain itu, setiap kontainer tidak dapat "melihat" process yang sedang dijalankan di +kontainer lain. Selain itu resource komputasi yang digunakan oleh kontainer +ini juga dapat dibatasi. Kontainer juga dapat dengan lebih mudah di-build jika dibandingkan dengan VM, karena kontainer tidak bergantung pada filesystem yang dimiliki mesin, serta dengan mudah dapat didistribusikan. -Karena kontainer ukurannya kecil dan lebih cepat, sebuah aplikasi dapat dibangun di setiap -image kontainer. Mekanisme pemetaan satu-satu antara kontainer dan aplikasi -inilah yang membuka keuntungan secara meyeluruh yang dapat diberikan oleh kontainer. -Dengan menggunakan kontainer, image kontainer dapat dibuat diwaktu rilis aplikasi. -Pembuatan image ini memungkinkan aplikasi secara konsisten dirilis pada -environment development maupun production. Selain itu, -kontainer juga memiliki transparasi yang lebih tinggi dibandingkan dengan VM. Maksudnya, +Karena kontainer ukurannya kecil dan lebih cepat, sebuah aplikasi dapat dibangun di setiap +image kontainer. Mekanisme pemetaan satu-satu antara kontainer dan aplikasi +inilah yang membuka keuntungan secara meyeluruh yang dapat diberikan oleh kontainer. +Dengan menggunakan kontainer, image kontainer dapat dibuat diwaktu rilis aplikasi. +Pembuatan image ini memungkinkan aplikasi secara konsisten dirilis pada +environment development maupun production. Selain itu, +kontainer juga memiliki transparasi yang lebih tinggi dibandingkan dengan VM. Maksudnya, infrastruktur punya tugas untuk mengatur lifecycle seluruh process yang ada di dalam kontainer. Ini bukanlah lagi tugas sebuah supervisor process yang tersembunyi di dalam kontainer. Secara garis besar, penggunaan kontainer memiliki keuntungan sebagai berikut: @@ -148,10 +148,10 @@ Secara garis besar, penggunaan kontainer memiliki keuntungan sebagai berikut: * **Mekanisme pembuatan aplikasi serta proses deployment yang lebih efektif**: Kontainer dapat meningkatkan kemudahan dan efisiensi jika dibandingkan dengan penggunaan VM. * **Continuous development, integration, and deployment**: - Digunakan untuk melakukan proses build dan deploy yang sering dilakukan - serta kemudahan mekanisme rollback karena image yang ada sifatnya immutable. + Digunakan untuk melakukan proses build dan deploy yang sering dilakukan + serta kemudahan mekanisme rollback karena image yang ada sifatnya immutable. * **Pemisahan kepentingan antara Dev dan Ops**: - Pembuatan image container dilakukan pada saat rilis dan bukan pada saat deploy + Pembuatan image container dilakukan pada saat rilis dan bukan pada saat deploy mengurangi ketergantungan aplikasi dan infrastruktur. * **Observabilitas** Tidak hanya informasi dan metriks pada level OS, tapi juga kesehatan aplikasi dan signal lain. @@ -161,10 +161,10 @@ Secara garis besar, penggunaan kontainer memiliki keuntungan sebagai berikut: Dapat dijalankan pada Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, dan dimanapun. * **Manajemen yang bersifat Aplikasi sentris**: Meningkatkan level abstraksi dari proses menjalankan OS pada perangkat keras virtual - ke proses menjalankan aplikasi pada sebuah OS dengan menggunakan resource logis. + ke proses menjalankan aplikasi pada sebuah OS dengan menggunakan resource logis. * **[Mikroservis](https://martinfowler.com/articles/microservices.html) yang renggang (loosely coupled), terdistribusi, elastis, dan terliberasi**: - Aplikasi dapat dipecah menjadi komponen yang lebih kecil yang independen dan dapat - di-deploy dan diatur secara dinamis -- bukan sebuah sistem monolitik yang dijalankan pada + Aplikasi dapat dipecah menjadi komponen yang lebih kecil yang independen dan dapat + di-deploy dan diatur secara dinamis -- bukan sebuah sistem monolitik yang dijalankan pada sebuah mesin yang hanya punya satu tujuan. * **Isolasi resource**: Performa aplikasi yang bisa diprediksi. diff --git a/content/id/docs/concepts/overview/working-with-objects/annotations.md b/content/id/docs/concepts/overview/working-with-objects/annotations.md index cdf11449282eb..c756c2d34c354 100644 --- a/content/id/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/id/docs/concepts/overview/working-with-objects/annotations.md @@ -49,13 +49,13 @@ Berikut merupakan beberapa contoh informasi yang dapat dicatat dengan menggunaka * Informasi yang berhubungan dengan pengguna atau perangkat/sistem, seperti URL objek yang terkait dengan komponen dari ekosistem lain. -* Metadata untuk perangkat *rollout* yang ringan (*lightweight*): contohnya, untuk +* Metadata untuk perangkat *rollout* yang ringan (*lightweight*): contohnya, untuk konfigurasi atau penanda (*checkpoint*). * Nomor telepon atau *pager* dari orang yang bertanggung jawab, atau entri direktori yang berisi informasi lebih lanjut, seperti *website* sebuah tim. -* Arahan dari pengguna (*end-user*) untuk melakukan implementasi, perubahan perilaku, +* Arahan dari pengguna (*end-user*) untuk melakukan implementasi, perubahan perilaku, ataupun untuk interaksi dengan fitur-fitur non-standar. Tanpa menggunakan anotasi, kamu dapat saja menyimpan informasi-informasi dengan tipe diff --git a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md index 5b9b83158a76c..7cd81495cdc62 100644 --- a/content/id/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/id/docs/concepts/overview/working-with-objects/field-selectors.md @@ -3,7 +3,7 @@ title: Selektor Field weight: 60 --- -Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan +Selektor *field* memungkinkan kamu untuk [memilih (*select*) *resource* Kubernetes](/docs/concepts/overview/working-with-objects/kubernetes-objects) berdasarkan nilai dari satu atau banyak *field resource*. Di bawah ini merupakan contoh dari beberapa *query* selektor *field*: * `metadata.name=my-service` diff --git a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md index c72f624fc578c..7cd1fc7fc04e8 100644 --- a/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/id/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -2,74 +2,74 @@ title: Memahami Konsep Objek-Objek yang ada pada Kubernetes content_template: templates/concept weight: 10 -card: +card: name: concepts weight: 40 --- {{% capture overview %}} -Laman ini menjelaskan bagaimana objek-objek Kubernetes direpresentasikan di dalam API Kubernetes, +Laman ini menjelaskan bagaimana objek-objek Kubernetes direpresentasikan di dalam API Kubernetes, dan bagaimana kamu dapat merepresentasikannya di dalam format `.yaml`. {{% /capture %}} {{% capture body %}} ## Memahami Konsep Objek-Objek yang Ada pada Kubernetes -Objek-objek Kubernetes adalah entitas persisten di dalam sistem Kubernetes. -Kubernetes menggunakan entitas ini untuk merepresentasikan _state_ yang ada pada +Objek-objek Kubernetes adalah entitas persisten di dalam sistem Kubernetes. +Kubernetes menggunakan entitas ini untuk merepresentasikan _state_ yang ada pada kluster kamu. Secara spesifik, hal itu dapat dideskripsikan sebagai: * Aplikasi-aplikasi kontainer apa sajakah yang sedang dijalankan (serta pada _node_ apa aplikasi tersebut dijalankan) * _Resource_ yang tersedia untuk aplikasi tersebut * _Policy_ yang mengatur bagaimana aplikasi tersebut dijalankan, misalnya _restart_, _upgrade_, dan _fault-tolerance_. -Objek Kubernetes merupakan sebuah _"record of intent"_--yang mana sekali kamu membuat suatu objek, -sistem Kubernetes akan bekerja secara konsisten untuk menjamin -bahwa objek tersebut akan selalu ada. Dengan membuat sebuah objek, secara tak langsung kamu +Objek Kubernetes merupakan sebuah _"record of intent"_--yang mana sekali kamu membuat suatu objek, +sistem Kubernetes akan bekerja secara konsisten untuk menjamin +bahwa objek tersebut akan selalu ada. Dengan membuat sebuah objek, secara tak langsung kamu memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu inginkan pada _workload_ kluster yang kamu miliki; dengan kata lain ini merupakan definisi _state_ kluster yang kamu inginkan. -Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu -harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/). -Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah -yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki +Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu +harus menggunakan [API Kubernetes](/docs/concepts/overview/kubernetes-api/). +Ketika kamu menggunakan perintah `kubectl`, perintah ini akan melakukan _API call_ untuk perintah +yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki menggunakan salah satu [_library_ klien](/docs/reference/using-api/client-libraries/) yang disediakan. ### _Spec_ dan Status Objek Setiap objek Kubernetes memiliki _field_ berantai yang mengatur konfigurasi sebuah objek: -_spec_ dan status. _Spec_, merupakan _field_ yang harus kamu sediakan, _field_ ini mendeskripsikan -_state_ yang kamu inginkan untuk objek tersebut--karakteristik dari objek yang kamu miliki. -Status mendeskripsikan _state_ yang sebenarnya dari sebuah objek, dan hal ini disediakan dan selalu diubah oleh -sistem Kubernetes. Setiap saat, _Control Plane_ Kubernetes selalu memantau apakah _state_ aktual sudah sesuai dengan +_spec_ dan status. _Spec_, merupakan _field_ yang harus kamu sediakan, _field_ ini mendeskripsikan +_state_ yang kamu inginkan untuk objek tersebut--karakteristik dari objek yang kamu miliki. +Status mendeskripsikan _state_ yang sebenarnya dari sebuah objek, dan hal ini disediakan dan selalu diubah oleh +sistem Kubernetes. Setiap saat, _Control Plane_ Kubernetes selalu memantau apakah _state_ aktual sudah sesuai dengan _state_ yang diinginkan. -Sebagai contoh, _Deployment_ merupakan sebuah objek yang merepresentasikan sebuah aplikasi yang dijalankan di kluster kamu. -Ketika kamu membuat sebuah _Deployment_, kamu bisa saja memberikan _spec_ bagi _Deployment_ untuk memberikan spesifikasi -berapa banyak _replica_ yang kamu inginkan. Sistem Kubernetes kemudian akan membaca konfigurasi yang kamu berikan -dan mengaktifkan tiga buah instans untuk aplikasi yang kamu inginkan--mengubah status yang ada saat ini agar sesuai dengan apa yang kamu inginkan. -Jika terjadi kegagalan dalam instans yang dibuat, sistem Kubernetes akan memberikan respons bahwa terdapat perbedaan antara _spec_ dan status serta +Sebagai contoh, _Deployment_ merupakan sebuah objek yang merepresentasikan sebuah aplikasi yang dijalankan di kluster kamu. +Ketika kamu membuat sebuah _Deployment_, kamu bisa saja memberikan _spec_ bagi _Deployment_ untuk memberikan spesifikasi +berapa banyak _replica_ yang kamu inginkan. Sistem Kubernetes kemudian akan membaca konfigurasi yang kamu berikan +dan mengaktifkan tiga buah instans untuk aplikasi yang kamu inginkan--mengubah status yang ada saat ini agar sesuai dengan apa yang kamu inginkan. +Jika terjadi kegagalan dalam instans yang dibuat, sistem Kubernetes akan memberikan respons bahwa terdapat perbedaan antara _spec_ dan status serta melakukan penyesuaian dengan cara memberikan instans pengganti. Informasi lebih lanjut mengenai _spec_ objek, status, dan _metadata_ dapat kamu baca di [Konvensi API Kubernetes](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md). ### Mendeskripsikan Objek Kubernetes -Ketika kamu membuat sebuah objek di Kubernetes, kamu harus menyediakan _spec_ objek yang -mendeskripsikan _state_ yang diinginkan, serta beberapa informasi tentang objek tersebut (seperti nama). -Ketika kamu menggunakan API Kubernetes untuk membuat objek tersebut (baik secara langsung atau menggunakan perintah -`kubectl`), _request_ API yang dibuat harus mencakup informasi seperti _request body_ dalam format JSON. -Apabila kamu memberikan **informasi dalam bentuk `.yaml` ketika menggunakan perintah `kubectl`** maka `kubectl` +Ketika kamu membuat sebuah objek di Kubernetes, kamu harus menyediakan _spec_ objek yang +mendeskripsikan _state_ yang diinginkan, serta beberapa informasi tentang objek tersebut (seperti nama). +Ketika kamu menggunakan API Kubernetes untuk membuat objek tersebut (baik secara langsung atau menggunakan perintah +`kubectl`), _request_ API yang dibuat harus mencakup informasi seperti _request body_ dalam format JSON. +Apabila kamu memberikan **informasi dalam bentuk `.yaml` ketika menggunakan perintah `kubectl`** maka `kubectl` akan mengubah informasi yang kamu berikan ke dalam format JSON ketika melakukan _request_ API. Berikut merupakan contoh _file_ `.yaml` yang menunjukkan _field_ dan _spec_ objek untuk _Deployment_: {{< codenew file="application/deployment.yaml" >}} -Salah satu cara untuk membuat _Deployment_ menggunakan _file_ `.yaml` -seperti yang dijabarkan di atas adalah dengan menggunakan perintah -[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) -pada _command-line interface_ `kubectl` kamu menerapkan _file_ `.yaml` sebagai sebuah argumen. +Salah satu cara untuk membuat _Deployment_ menggunakan _file_ `.yaml` +seperti yang dijabarkan di atas adalah dengan menggunakan perintah +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) +pada _command-line interface_ `kubectl` kamu menerapkan _file_ `.yaml` sebagai sebuah argumen. Berikut merupakan contoh penggunaannya: ```shell @@ -84,19 +84,19 @@ deployment.apps/nginx-deployment created ### _Field-Field_ yang dibutuhkan -Pada _file_ `.yaml` untuk objek Kubernetes yang ingin kamu buat, kamu perlu +Pada _file_ `.yaml` untuk objek Kubernetes yang ingin kamu buat, kamu perlu menyediakan _value_ untuk _field-field_ berikut: * _apiVersion_ - Version API Kubernetes mana yang kamu gunakan untuk membuat objek tersebut * _kind_ - Objek apakah yang ingin kamu buat * _metadata_ - Data yang dapat kamu gunakan untuk melakukan identifikasi objek termasuk _name_ dalam betuk string, _UID_, dan _namespace_ yang bersifat opsional -Kamu juga harus menyediakan _field_ _spec_. Format spesifik dari _spec_ sebuah objek akan berbeda bergantung -pada objek apakah yang ingin kamu buat, serta mengandung _field_ berantai yang spesifik bagi objek tersebut. -[Referensi API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) memberikan penjelasan -lebih lanjut mengenai format _spec_ untuk semua objek Kubernetes yang dapat kamu buat. Misalnya saja format _spec_ +Kamu juga harus menyediakan _field_ _spec_. Format spesifik dari _spec_ sebuah objek akan berbeda bergantung +pada objek apakah yang ingin kamu buat, serta mengandung _field_ berantai yang spesifik bagi objek tersebut. +[Referensi API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) memberikan penjelasan +lebih lanjut mengenai format _spec_ untuk semua objek Kubernetes yang dapat kamu buat. Misalnya saja format _spec_ untuk _Pod_ dapat kamu temukan [di sini](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core), -dan format _spec_ untuk _Deployment_ dapat ditemukan +dan format _spec_ untuk _Deployment_ dapat ditemukan [di sini](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps). {{% /capture %}} diff --git a/content/id/docs/concepts/overview/working-with-objects/namespaces.md b/content/id/docs/concepts/overview/working-with-objects/namespaces.md index 91637e67191c1..5c22adc89e7d0 100644 --- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md @@ -62,7 +62,7 @@ kubectl --namespace= run nginx --image=nginx kubectl --namespace= get pods ``` -### Mengkonfigurasi preferensi namespace +### Mengkonfigurasi preferensi namespace Kamu dapat menyimpan konfigurasi *namespace* untuk semua perintah `kubectl` dengan perintah: diff --git a/content/id/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/id/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index 50ecaa967659e..2245f9f96113f 100644 --- a/content/id/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/id/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -7,12 +7,12 @@ weight: 60 {{< toc >}} {{% capture overview %}} -Menambahkan entri pada berkas /etc/hosts Pod akan melakukan _override_ -resolusi _hostname_ pada level Pod ketika DNS dan opsi lainnya tidak tersedia. -Pada versi 1.7, pengguna dapat menambahkan entri yang diinginkan beserta _field_ HostAliases +Menambahkan entri pada berkas /etc/hosts Pod akan melakukan _override_ +resolusi _hostname_ pada level Pod ketika DNS dan opsi lainnya tidak tersedia. +Pada versi 1.7, pengguna dapat menambahkan entri yang diinginkan beserta _field_ HostAliases pada PodSpec. -Modifikasi yang dilakukan tanpa menggunakan HostAliases tidaklah disarankan +Modifikasi yang dilakukan tanpa menggunakan HostAliases tidaklah disarankan karena berkas ini diatur oleh Kubelet dan dapat di-_override_ ketika Pod dibuat/di-_restart_. {{% /capture %}} @@ -58,14 +58,14 @@ fe00::2 ip6-allrouters 10.200.0.4 nginx ``` -Secara default, berkas `hosts` hanya berisikan _boilerplate_ alamat IP IPv4 and IPv6 seperti +Secara default, berkas `hosts` hanya berisikan _boilerplate_ alamat IP IPv4 and IPv6 seperti `localhost` dan hostname dari Pod itu sendiri. ## Menambahkan Entri Tambahan dengan HostAliases -Selain _boilerplate default_, kita dapat menambahkan entri pada berkas +Selain _boilerplate default_, kita dapat menambahkan entri pada berkas `hosts` untuk melakukan resolusi `foo.local`, `bar.local` pada `127.0.0.1` dan `foo.remote`, -`bar.remote` pada `10.1.2.3`, kita dapat melakukannya dengan cara menambahkan +`bar.remote` pada `10.1.2.3`, kita dapat melakukannya dengan cara menambahkan HostAliases pada Pod di bawah _field_ `.spec.hostAliases`: {{< codenew file="service/networking/hostaliases-pod.yaml" >}} @@ -116,15 +116,15 @@ Dengan tambahan entri yang telah dispesifikasikan sebelumnya. ## Kenapa Kubelet Melakukan Mekanisme Manajemen Berkas `Hosts`? -Kubelet [melakukan proses manajemen](https://github.com/kubernetes/kubernetes/issues/14633) -berkas `hosts` untuk setiap container yang ada pada Pod untuk mencegah Docker melakukan -[modifikasi](https://github.com/moby/moby/issues/17190) pada berkas tersebut +Kubelet [melakukan proses manajemen](https://github.com/kubernetes/kubernetes/issues/14633) +berkas `hosts` untuk setiap container yang ada pada Pod untuk mencegah Docker melakukan +[modifikasi](https://github.com/moby/moby/issues/17190) pada berkas tersebut setelah kontainer dihidupkan. -Karena sifat dari berkas tersebut yang secara otomatis di-_manage_, -semua hal yang didefinisikan oleh pengguna akan ditimpa (_overwrite_) ketika berkas -`hosts` di-_mount_ kembali oleh Kubelet ketika ada kontainer yang di-_restart_ -atau Pod di-_schedule_ ulang. Dengan demikian tidak dianjurkan untuk +Karena sifat dari berkas tersebut yang secara otomatis di-_manage_, +semua hal yang didefinisikan oleh pengguna akan ditimpa (_overwrite_) ketika berkas +`hosts` di-_mount_ kembali oleh Kubelet ketika ada kontainer yang di-_restart_ +atau Pod di-_schedule_ ulang. Dengan demikian tidak dianjurkan untuk memodifikasi berkas tersebut secara langsung. {{% /capture %}} diff --git a/content/id/docs/concepts/services-networking/connect-applications-service.md b/content/id/docs/concepts/services-networking/connect-applications-service.md index d0b36e3832bed..5d7684d574230 100644 --- a/content/id/docs/concepts/services-networking/connect-applications-service.md +++ b/content/id/docs/concepts/services-networking/connect-applications-service.md @@ -81,7 +81,7 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-nginx ClusterIP 10.0.162.149 80/TCP 21s ``` -Seperti yang disebutkan sebelumnya, sebuah *Service* berisi sekumpulan *Pod*. *Pod* diekspos melalui `endpoints`. *Service selector* akan mengecek *Pod* secara terus-menerus dan hasilnya akan dikirim (*POSTed*) ke objek *endpoint* yang bernama `my-nginx`. Saat sebuah *Pod* mati, *IP Pod* di dalam *endpoint* tersebut akan otomatis dihapus, dan *Pod* baru yang sesuai dengan *Service selector* akan otomatis ditambahkan ke dalam *endpoint*. Cek *endpoint* dan perhatikan bahwa IP sama dengan *Pod* yang dibuat di langkah pertama: +Seperti yang disebutkan sebelumnya, sebuah *Service* berisi sekumpulan *Pod*. *Pod* diekspos melalui `endpoints`. *Service selector* akan mengecek *Pod* secara terus-menerus dan hasilnya akan dikirim (*POSTed*) ke objek *endpoint* yang bernama `my-nginx`. Saat sebuah *Pod* mati, *IP Pod* di dalam *endpoint* tersebut akan otomatis dihapus, dan *Pod* baru yang sesuai dengan *Service selector* akan otomatis ditambahkan ke dalam *endpoint*. Cek *endpoint* dan perhatikan bahwa IP sama dengan *Pod* yang dibuat di langkah pertama: ```shell kubectl describe svc my-nginx @@ -111,7 +111,7 @@ Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:< ## Mengakses Service -Kubernetes mendukung 2 mode utama untuk menemukan sebuah *Service* - variabel *environment* dan *DNS*. +Kubernetes mendukung 2 mode utama untuk menemukan sebuah *Service* - variabel *environment* dan *DNS*. *DNS* membutuhkan [tambahan CoreDNS di dalam kluster](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). ### Variabel Environment @@ -197,7 +197,7 @@ Hingga sekarang kita hanya mengakses *nginx* server dari dalam kluster. Sebelum * Sebuah [secret](/docs/concepts/configuration/secret/) yang membuat setifikat tersebut dapat diakses oleh *pod* -Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya: +Kamu dapat melihat semua itu di [contoh nginx https](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). Contoh ini mengaharuskan kamu melakukan instalasi *go* dan *make*. Jika kamu tidak ingin melakukan instalasi tersebut, ikuti langkah-langkah manualnya nanti, singkatnya: ```shell make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json @@ -215,7 +215,7 @@ default-token-il9rc kubernetes.io/service-account-token 1 1d nginxsecret Opaque 2 1m ``` -Berikut ini adalah langkah-langkah manual yang harus diikuti jika kamu mengalami masalah menjalankan *make* (pada windows contohnya): +Berikut ini adalah langkah-langkah manual yang harus diikuti jika kamu mengalami masalah menjalankan *make* (pada windows contohnya): ```shell #membuat sebuah key-pair public private diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md index b3be2c2103110..b90f4c2c63613 100644 --- a/content/id/docs/concepts/services-networking/ingress-controllers.md +++ b/content/id/docs/concepts/services-networking/ingress-controllers.md @@ -6,64 +6,64 @@ weight: 40 {{% capture overview %}} -Agar Ingress dapat bekerja sebagaimana mestinya, +Agar Ingress dapat bekerja sebagaimana mestinya, sebuah kluster harus memiliki paling tidak sebuah kontroler Ingress. -Berbeda dengan kontroler-kontroler lainnya yang dijalankan -sebagai bagian dari *binary* `kube-controller-manager`, kontroler Ingress -tidak secara otomatis dijalankan di dalam kluster. Kamu bisa menggunakan -laman ini untuk memilih implementasi kontroler Ingress yang kamu pikir -paling sesuai dengan kebutuhan kamu. +Berbeda dengan kontroler-kontroler lainnya yang dijalankan +sebagai bagian dari *binary* `kube-controller-manager`, kontroler Ingress +tidak secara otomatis dijalankan di dalam kluster. Kamu bisa menggunakan +laman ini untuk memilih implementasi kontroler Ingress yang kamu pikir +paling sesuai dengan kebutuhan kamu. Kubernetes sebagai sebuah proyek, saat ini, mendukung dan memaintain kontroler-kontroler [GCE](https://git.k8s.io/ingress-gce/README.md) dan [nginx](https://git.k8s.io/ingress-nginx/README.md). - + {{% /capture %}} {{% capture body %}} ## Kontroler-kontroler lainnya -* [Ambassador](https://www.getambassador.io/) *API Gateway* merupakan ingress berbasis [Envoy](https://www.envoyproxy.io) - kontroler dengan dukungan [komunitas](https://www.getambassador.io/docs) atau +* [Ambassador](https://www.getambassador.io/) *API Gateway* merupakan ingress berbasis [Envoy](https://www.envoyproxy.io) + kontroler dengan dukungan [komunitas](https://www.getambassador.io/docs) atau [komersial](https://www.getambassador.io/pro/) dari [Datawire](https://www.datawire.io/). -* [AppsCode Inc.](https://appscode.com) menawarkan dukungan dan pemeliharaan untuk ingress berbasis [HAProxy](http://www.haproxy.org/), [Voyager](https://appscode.com/products/voyager). -* [Contour](https://github.com/heptio/contour) merupakan ingress berbasis [Envoy](https://www.envoyproxy.io) +* [AppsCode Inc.](https://appscode.com) menawarkan dukungan dan pemeliharaan untuk ingress berbasis [HAProxy](http://www.haproxy.org/), [Voyager](https://appscode.com/products/voyager). +* [Contour](https://github.com/heptio/contour) merupakan ingress berbasis [Envoy](https://www.envoyproxy.io) yang disediakan dan didukung oleh Heptio. * Citrix menyediakan sebuah [kontroler Ingress](https://github.com/citrix/citrix-k8s-ingress-controller) untuk perangkat keras (MPX), virtualisasi (VPX) dan [kontainerisasi cuma-cuma (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html) untuk mesin [*baremetal*](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal) dan penyedia layanan [*cloud*](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) deployments. * F5 Networks menyediakan [dukungan dan pemeliharaan](https://support.f5.com/csp/article/K86859508) untuk [kontroler F5 BIG-IP bagi Kubernetes](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest). -* [Gloo](https://gloo.solo.io) adalah sebuah proyek kontroler Ingress *open source* berbasis [Envoy](https://www.envoyproxy.io) yang menawarkan fungsionalitas *API Gateway* dengan dukungan *enterprise* dari [solo.io](https://www.solo.io). +* [Gloo](https://gloo.solo.io) adalah sebuah proyek kontroler Ingress *open source* berbasis [Envoy](https://www.envoyproxy.io) yang menawarkan fungsionalitas *API Gateway* dengan dukungan *enterprise* dari [solo.io](https://www.solo.io). * Kontroler Ingress berbasis [HAProxy](http://www.haproxy.org/) - [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) yang disebutkan di dalam artikel + [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress) yang disebutkan di dalam artikel [HAProxy Ingress Controller for Kubernetes](https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/). [HAProxy Technologies](https://www.haproxy.com/) menawarkan dukungan dan pemeliharaan bagi HAProxy Enterprise dan Ingress kontroler [jcmoraisjr/haproxy-ingress](https://github.com/jcmoraisjr/haproxy-ingress). -* Kontroler Ingress berbasis [Istio](https://istio.io/) +* Kontroler Ingress berbasis [Istio](https://istio.io/) [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/). * [Kong](https://konghq.com/) menawarkan dukungan dan pemeliharaan [komunitas](https://discuss.konghq.com/c/kubernetes) atau - [komersial](https://konghq.com/kong-enterprise/) + [komersial](https://konghq.com/kong-enterprise/) [Kontroler Ingress untuk Kubernetes](https://github.com/Kong/kubernetes-ingress-controller). * [NGINX, Inc.](https://www.nginx.com/) menawarkan dukungan dan pemeliharaan [Kontroler Ingress NGINX untuk Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller). -* [Traefik](https://github.com/containous/traefik) adalah sebuah kontroler Ingress yang menyediakan semua fitur secara lengkap (fully featured) - ([Let's Encrypt](https://letsencrypt.org), *secrets*, *http2*, *websocket*), dengan tambahan dukungan +* [Traefik](https://github.com/containous/traefik) adalah sebuah kontroler Ingress yang menyediakan semua fitur secara lengkap (fully featured) + ([Let's Encrypt](https://letsencrypt.org), *secrets*, *http2*, *websocket*), dengan tambahan dukungan komersial oleh [Containous](https://containo.us/services). ## Menggunakan beberapa jenis kontroler Ingress sekaligus -Kamu dapat melakukan *deploy* [berapa pun banyaknya kontroler Ingress](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) -dalam sebuah kluster. Jika kamu ingin membuat Ingress, kamu tinggal memberikan anotasi setiap Ingress sesuai dengan -[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) -yang sesuai untuk menandai kontroler Ingress mana yang digunakan jika terdapat lebih dari satu kontroler Ingress yang ada di +Kamu dapat melakukan *deploy* [berapa pun banyaknya kontroler Ingress](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers) +dalam sebuah kluster. Jika kamu ingin membuat Ingress, kamu tinggal memberikan anotasi setiap Ingress sesuai dengan +[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +yang sesuai untuk menandai kontroler Ingress mana yang digunakan jika terdapat lebih dari satu kontroler Ingress yang ada di kluster kamu. Apabila kamu tidak mendefinisikan `class` yang dipakai, penyedia layanan *cloud* kamu akan menggunakan kontroler Ingress *default* yang mereka miliki. -Idealnya, semua ingress harus memenuhi spesifikasi ini, tetapi berbagai jenis -kontroler Ingress bisa saja memiliki sedikit perbedaan cara kerja. +Idealnya, semua ingress harus memenuhi spesifikasi ini, tetapi berbagai jenis +kontroler Ingress bisa saja memiliki sedikit perbedaan cara kerja. {{< note >}} -Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang akan kamu pakai sebelum memutuskan untuk memakai kontroler tersebut. +Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang akan kamu pakai sebelum memutuskan untuk memakai kontroler tersebut. {{< /note >}} {{% /capture %}} diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md index 311ea5aee4f65..d6ffbc6e066bc 100644 --- a/content/id/docs/concepts/services-networking/ingress.md +++ b/content/id/docs/concepts/services-networking/ingress.md @@ -11,17 +11,17 @@ weight: 40 {{% capture body %}} ## Terminologi -Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipakai: +Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipakai: -* Node: Sebuah mesin fisik atau virtual yang berada di dalam kluster Kubernetes. -* Kluster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*. +* Node: Sebuah mesin fisik atau virtual yang berada di dalam kluster Kubernetes. +* Kluster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*. * *Edge router*: Sebuah *router* mengatur *policy firewall* pada kluster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras. * Jaringan kluster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam kluster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/). -* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan kluster. +* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan kluster. ## Apakah *Ingress* itu? -Ingress ditambahkan sejak Kubernetes v1.1, mengekspos rute HTTP dan HTTPS ke berbagai +Ingress ditambahkan sejak Kubernetes v1.1, mengekspos rute HTTP dan HTTPS ke berbagai {{< link text="services" url="/docs/concepts/services-networking/service/" >}} di dalam kluster. Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pada *Ingress*. @@ -33,10 +33,10 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa [ Services ] ``` -Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar kluster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama. +Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar kluster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama. Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik. -Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan +Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan *service* dengan tipe [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) atau [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer). @@ -44,27 +44,27 @@ Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Se {{< feature-state for_k8s_version="v1.1" state="beta" >}} -Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta. +Sebelum kamu mulai menggunakan *Ingress*, ada beberapa hal yang perlu kamu ketahui sebelumnya. *Ingress* merupakan *resource* dengan tipe beta. {{< note >}} -Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun. +Kamu harus terlebih dahulu memiliki [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk dapat memenuhi *Ingress*. Membuat sebuah *Ingress* tanpa adanya kontroler *Ingres* tidak akan berdampak apa pun. {{< /note >}} GCE/Google Kubernetes Engine melakukan deploy kontroler *Ingress* pada *master*. Perhatikan laman berikut [keterbatasan versi beta](https://github.com/kubernetes/ingress-gce/blob/master/BETA_LIMITATIONS.md#glbc-beta-limitations) kontroler ini jika kamu menggunakan GCE/GKE. -Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus -[melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis +Jika kamu menggunakan *environment* selain GCE/Google Kubernetes Engine, kemungkinan besar kamu harus +[melakukan proses deploy kontroler ingress kamu sendiri](https://kubernetes.github.io/ingress-nginx/deploy/). Terdapat beberapa jenis [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang bisa kamu pilih. ### Sebelum kamu memulai -Secara ideal, semua kontroler Ingress harus memenuhi spesifikasi ini, tetapi beberapa -kontroler beroperasi sedikit berbeda satu sama lain. +Secara ideal, semua kontroler Ingress harus memenuhi spesifikasi ini, tetapi beberapa +kontroler beroperasi sedikit berbeda satu sama lain. {{< note >}} -Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang akan kamu pakai sebelum memutuskan untuk memakai kontroler tersebut. +Pastikan kamu sudah terlebih dahulu memahami dokumentasi kontroler Ingress yang akan kamu pakai sebelum memutuskan untuk memakai kontroler tersebut. {{< /note >}} ## *Resource* Ingress @@ -88,48 +88,48 @@ spec: servicePort: 80 ``` - Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`. + Seperti layaknya *resource* Kubernetes yang lain, sebuah Ingress membutuhkan *field* `apiVersion`, `kind`, dan `metadata`. Untuk informasi umum soal bagaimana cara bekerja dengan menggunakan file konfigurasi, silahkan merujuk pada [melakukan deploy aplikasi](/docs/tasks/run-application/run-stateless-application-deployment/), [konfigurasi kontainer](/docs/tasks/configure-pod-container/configure-pod-configmap/), [mengatur *resource*](/docs/concepts/cluster-administration/manage-deployment/). Ingress seringkali menggunakan anotasi untuk melakukan konfigurasi beberapa opsi yang ada bergantung pada kontroler Ingress yang digunakan, sebagai contohnya adalah [anotasi rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md). - [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi - kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan. + [Kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang berbeda memiliki jenis anotasi yang berbeda. Pastikan kamu sudah terlebih dahulu memahami dokumentasi + kontroler Ingress yang akan kamu pakai untuk mengetahui jenis anotasi apa sajakah yang disediakan. [Spesifikasi](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) Ingress -memiliki segala informasi yang dibutuhkan untuk melakukan proses konfigurasi *loadbalancer* atau server proxy. Hal yang terpenting adalah -bagian inilah yang mengandung semua *rules* yang nantinya akan digunakan untuk menyesuaikan trafik yang masuk. *Resource* Ingress hanya menyediakan +memiliki segala informasi yang dibutuhkan untuk melakukan proses konfigurasi *loadbalancer* atau server proxy. Hal yang terpenting adalah +bagian inilah yang mengandung semua *rules* yang nantinya akan digunakan untuk menyesuaikan trafik yang masuk. *Resource* Ingress hanya menyediakan fitur *rules* untuk mengarahkan trafik dengan protokol HTTP. ### *Rule* Ingress Setiap *rule* HTTP mengandung informasi berikut: -* *Host* opsional. Di dalam contoh ini, tidak ada *host* yang diberikan, dengan kata lain, semua *rules* berlaku untuk *inbound* +* *Host* opsional. Di dalam contoh ini, tidak ada *host* yang diberikan, dengan kata lain, semua *rules* berlaku untuk *inbound* trafik HTTP bagi alamat IP yang dispesifikasikan. JIka sebuah *host* dispesifikasikan (misalnya saja, foo.bar.com), maka *rules* yang ada akan berlaku bagi *host* tersebut. * Sederetan *path* (misalnya, /testpath), setiap *path* ini akan memiliki pasangan berupa sebuah *backend* yang didefinisikan dengan `serviceName` - dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum - *loadbalancer* akan mengarahkan trafik pada *service* yang sesuai. + dan `servicePort`. Baik *host* dan *path* harus sesuai dengan konten dari *request* yang masuk sebelum + *loadbalancer* akan mengarahkan trafik pada *service* yang sesuai. * Suatu *backend* adalah kombinasi *service* dan *port* seperti yang dideskripsikan di - [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan + [dokumentasi *Service*](/docs/concepts/services-networking/service/). *Request* HTTP (dan HTTPS) yang sesuai dengan *host* dan *path* yang ada pada *rule* akan diteruskan pada *backend* terkait. -*Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah - mengarahkan *request* yang tidak sesuai dengan *path* yang tersedia pada spesifikasi. +*Backend default* seringkali dikonfigurasi pada kontroler kontroler Ingress, tugas *backend default* ini adalah + mengarahkan *request* yang tidak sesuai dengan *path* yang tersedia pada spesifikasi. ### *Backend Default* -Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang +Sebuah Ingress yang tidak memiliki *rules* akan mengarahkan semua trafik pada sebuah *backend default*. *Backend default* inilah yang biasanya bisa dimasukkan sebagai salah satu opsi konfigurasi dari [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) dan tidak dimasukkan dalam spesifikasi *resource* Ingress. -Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut +Jika tidak ada *host* atau *path* yang sesuai dengan *request* HTTP pada objek Ingress, maka trafik tersebut akan diarahkan pada *backend default*. ## Jenis Ingress ### Ingress dengan satu Service -Terdapat konsep Kubernetes yang memungkinkan kamu untuk mengekspos sebuah Service, lihat [alternatif lain](#alternatif-lain). +Terdapat konsep Kubernetes yang memungkinkan kamu untuk mengekspos sebuah Service, lihat [alternatif lain](#alternatif-lain). Kamu juga bisa membuat spesifikasi Ingress dengan *backend default* yang tidak memiliki *rules*. {{< codenew file="service/networking/ingress.yaml" >}} @@ -145,18 +145,18 @@ NAME HOSTS ADDRESS PORTS AGE test-ingress * 107.178.254.228 80 59s ``` -Dimana `107.178.254.228` merupakan alamat IP yang dialokasikan oleh kontroler Ingress untuk +Dimana `107.178.254.228` merupakan alamat IP yang dialokasikan oleh kontroler Ingress untuk memenuhi Ingress ini. {{< note >}} -Kontroler Ingress dan *load balancer* membutuhkan waktu sekitar satu hingga dua menit untuk mengalokasikan alamat IP. +Kontroler Ingress dan *load balancer* membutuhkan waktu sekitar satu hingga dua menit untuk mengalokasikan alamat IP. Hingga alamat IP berhasil dialokasikan, kamu akan melihat tampilan kolom `ADDRESS` sebagai ``. {{< /note >}} ### *Fanout* sederhana -Sebuah konfigurasi fanout akan melakukan *route* trafik dari sebuah alamat IP ke banyak Service, -berdasarkan URI HTTP yang diberikan. Sebuah Ingress memungkinkan kamu untuk memiliki jumlah *loadbalancer* minimum. +Sebuah konfigurasi fanout akan melakukan *route* trafik dari sebuah alamat IP ke banyak Service, +berdasarkan URI HTTP yang diberikan. Sebuah Ingress memungkinkan kamu untuk memiliki jumlah *loadbalancer* minimum. Contohnya, konfigurasi seperti di bawah ini: ```shell @@ -214,17 +214,17 @@ Events: ``` Kontroler Ingress akan menyediakan *loadbalancer* (implementasinya tergantung dari jenis Ingress yang digunakan), selama *service-service* yang didefinisikan (`s1`, `s2`) ada. -Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbagai *loadbalancer* +Apabila *Ingress* selesai dibuat, maka kamu dapat melihat alamat IP dari berbagai *loadbalancer* pada kolom `address`. {{< note >}} -Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/) +Kamu mungkin saja membutuhkan konfigurasi default-http-backend [Service](/docs/concepts/services-networking/service/) bergantung pada [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) yang kamu pakai. {{< /note >}} ### Virtual Host berbasis Nama -Virtual Host berbasis Nama memungkinkan mekanisme *routing* berdasarkan trafik HTTP ke beberapa *host name* dengan alamat IP yang sama. +Virtual Host berbasis Nama memungkinkan mekanisme *routing* berdasarkan trafik HTTP ke beberapa *host name* dengan alamat IP yang sama. ```none foo.bar.com --| |-> foo.bar.com s1:80 @@ -232,7 +232,7 @@ foo.bar.com --| |-> foo.bar.com s1:80 bar.foo.com --| |-> bar.foo.com s2:80 ``` -Ingress di bawah ini memberikan perintah pada *loadbalancer* untuk melakukan mekanisme *routing* berdasarkan +Ingress di bawah ini memberikan perintah pada *loadbalancer* untuk melakukan mekanisme *routing* berdasarkan [header host](https://tools.ietf.org/html/rfc7230#section-5.4). ```yaml @@ -256,11 +256,11 @@ spec: servicePort: 80 ``` -Jika kamu membuat sebuah Ingress tanpa mendefinisikan *host* apa pun, maka -trafik web ke alamat IP dari kontroler Ingress tetap dapat dilakukan tanpa harus -menyesuaikan aturan *name based virtual host*. Sebagai contoh, -*resource* Ingress di bawah ini akan melakukan pemetaan trafik -dari `first.bar.com` ke `service1`, `second.foo.com` ke `service2`, dan trafik lain +Jika kamu membuat sebuah Ingress tanpa mendefinisikan *host* apa pun, maka +trafik web ke alamat IP dari kontroler Ingress tetap dapat dilakukan tanpa harus +menyesuaikan aturan *name based virtual host*. Sebagai contoh, +*resource* Ingress di bawah ini akan melakukan pemetaan trafik +dari `first.bar.com` ke `service1`, `second.foo.com` ke `service2`, dan trafik lain ke alamat IP tanpa *host name* yang didefinisikan di dalam *request* (yang tidak memiliki *request header*) ke `service3`. ```yaml @@ -292,11 +292,11 @@ spec: ### TLS Kamu dapat mengamankan *Ingress* yang kamu miliki dengan memberikan spesifikasi [secret](/docs/concepts/configuration/secret) -yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya -memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS. +yang mengandung *private key* dan sertifikat TLS. Saat ini, Ingress hanya +memiliki fitur untuk melakukan konfigurasi *single TLS port*, yaitu 443, serta melakukan terminasi TLS. Jika *section* TLS pada Ingress memiliki spesifikasi *host* yang berbeda, -*rules* yang ada akan dimultiplekskan pada *port* yang sama berdasarkan -*hostname* yang dispesifikasikan melalui ekstensi TLS SNI. *Secret* TLS harus memiliki +*rules* yang ada akan dimultiplekskan pada *port* yang sama berdasarkan +*hostname* yang dispesifikasikan melalui ekstensi TLS SNI. *Secret* TLS harus memiliki `key` bernama `tls.crt` dan `tls.key` yang mengandung *private key* dan sertifikat TLS, contohnya: ```yaml @@ -311,9 +311,9 @@ metadata: type: kubernetes.io/tls ``` -Ketika kamu menambahkan *secret* pada Ingress maka kontroler Ingress akan memberikan perintah untuk -memproteksi *channel* dari klien ke *loadbalancer* menggunakan TLS. -Kamu harus memastikan *secret* TLS yang digunakan memiliki sertifikat yang mengandung +Ketika kamu menambahkan *secret* pada Ingress maka kontroler Ingress akan memberikan perintah untuk +memproteksi *channel* dari klien ke *loadbalancer* menggunakan TLS. +Kamu harus memastikan *secret* TLS yang digunakan memiliki sertifikat yang mengandung CN untuk `sslexample.foo.com`. ```yaml @@ -337,27 +337,27 @@ spec: ``` {{< note >}} -Terdapat perbedaan di antara beberapa fitur TLS -yang disediakan oleh berbagai kontroler Ingress. Perhatikan dokumentasi +Terdapat perbedaan di antara beberapa fitur TLS +yang disediakan oleh berbagai kontroler Ingress. Perhatikan dokumentasi [nginx](https://git.k8s.io/ingress-nginx/README.md#https), -[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), atau -kontroler Ingress spesifik *platform* lainnya untuk memahami cara kerja TLS +[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https), atau +kontroler Ingress spesifik *platform* lainnya untuk memahami cara kerja TLS pada **environment** yang kamu miliki. {{< /note >}} ### *Loadbalancing* -Sebuah kontroler Ingress sudah dibekali dengan beberapa *policy* terkait mekanisme *load balance* +Sebuah kontroler Ingress sudah dibekali dengan beberapa *policy* terkait mekanisme *load balance* yang nantinya akan diterapkan pada semua Ingress, misalnya saja algoritma *load balancing*, *backend -weight scheme*, dan lain sebagainya. Beberapa konsep *load balance* yang lebih *advance* -(misalnya saja *persistent sessions*, *dynamic weights*) belum diekspos melalui Ingress. -Meskipun begitu, kamu masih bisa menggunakan fitur ini melalui +weight scheme*, dan lain sebagainya. Beberapa konsep *load balance* yang lebih *advance* +(misalnya saja *persistent sessions*, *dynamic weights*) belum diekspos melalui Ingress. +Meskipun begitu, kamu masih bisa menggunakan fitur ini melalui [loadbalancer service](https://github.com/kubernetes/ingress-nginx). -Perlu diketahui bahwa meskipun *health check* tidak diekspos secara langsung -melalui Ingress, terdapat beberapa konsep di Kubernetes yang sejalan dengan hal ini, misalnya +Perlu diketahui bahwa meskipun *health check* tidak diekspos secara langsung +melalui Ingress, terdapat beberapa konsep di Kubernetes yang sejalan dengan hal ini, misalnya [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) -yang memungkinkan kamu untuk memperoleh hasil yang sama. Silahkan pelajari lebih lanjut dokumentasi +yang memungkinkan kamu untuk memperoleh hasil yang sama. Silahkan pelajari lebih lanjut dokumentasi kontroler yang kamu pakai untuk mengetahui bagaimana implementasi *health checks* pada kontroler yang kamu pilih ([nginx](https://git.k8s.io/ingress-nginx/README.md), [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)). @@ -391,9 +391,9 @@ Events: kubectl edit ingress test ``` -Sebuah editor akan muncul dan menampilkan konfigurasi Ingress kamu -dalam format YAML apabila kamu telah menjalankan perintah di atas. -Ubah untuk menambahkan *host*: +Sebuah editor akan muncul dan menampilkan konfigurasi Ingress kamu +dalam format YAML apabila kamu telah menjalankan perintah di atas. +Ubah untuk menambahkan *host*: ```yaml spec: @@ -442,21 +442,21 @@ Events: Normal ADD 45s loadbalancer-controller default/test ``` -Kamu juga dapat mengubah Ingress dengan menggunakan perintah `kubectl replace -f` pada file konfigurasi +Kamu juga dapat mengubah Ingress dengan menggunakan perintah `kubectl replace -f` pada file konfigurasi Ingress yang ingin diubah. ## Mekanisme *failing* pada beberapa zona *availability* Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*. -Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers) +Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers) untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/) -untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi kluster. +untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi kluster. ## Pengembangan selanjutnya Silahkan amati [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) -untuk detail lebih lanjut mengenai perubahan Ingress dan *resource* terkait lainnya. Kamu juga bisa melihat -[repositori Ingress](https://github.com/kubernetes/ingress/tree/master) untuk informasi yang lebih detail +untuk detail lebih lanjut mengenai perubahan Ingress dan *resource* terkait lainnya. Kamu juga bisa melihat +[repositori Ingress](https://github.com/kubernetes/ingress/tree/master) untuk informasi yang lebih detail soal perubahan berbagai kontroler. ## Alternatif lain diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md index 3f0f7f25090d3..7e5b87d2962a1 100644 --- a/content/id/docs/concepts/services-networking/network-policies.md +++ b/content/id/docs/concepts/services-networking/network-policies.md @@ -9,7 +9,7 @@ weight: 50 {{% capture overview %}} Sebuah NetworkPolicy adalah spesifikasi dari sekelompok Pod atau _endpoint_ yang diizinkan untuk saling berkomunikasi. -`NetworkPolicy` menggunakan label untuk memilih Pod serta mendefinisikan serangkaian _rule_ yang digunakan +`NetworkPolicy` menggunakan label untuk memilih Pod serta mendefinisikan serangkaian _rule_ yang digunakan untuk mendefinisikan trafik yang diizinkan untuk suatu Pod tertentu. {{% /capture %}} @@ -17,18 +17,18 @@ untuk mendefinisikan trafik yang diizinkan untuk suatu Pod tertentu. {{% capture body %}} ## Prasyarat -NetworkPolicy diimplementasikan dengan menggunakan _plugin_ jaringan, -dengan demikian kamu harus memiliki penyedia jaringan yang mendukung `NetworkPolicy` - -membuat _resource_ tanpa adanya _controller_ tidak akan berdampak apa pun. +NetworkPolicy diimplementasikan dengan menggunakan _plugin_ jaringan, +dengan demikian kamu harus memiliki penyedia jaringan yang mendukung `NetworkPolicy` - +membuat _resource_ tanpa adanya _controller_ tidak akan berdampak apa pun. ## Pod yang terisolasi dan tidak terisolasi -Secara _default_, Pod bersifat tidak terisolasi; Pod-Pod tersebut +Secara _default_, Pod bersifat tidak terisolasi; Pod-Pod tersebut menerima trafik dari _resource_ apa pun. -Pod menjadi terisolasi apabila terdapat `NetworkPolicy` yang dikenakan pada Pod-Pod tersebut. -Apabila terdapat `NetworkPolicy` di dalam _namespace_ yang dikenakan pada suatu Pod, Pod tersebut -akan menolak koneksi yang tidak diizinkan `NetworkPolicy`. (Pod lain dalam _namespace_ +Pod menjadi terisolasi apabila terdapat `NetworkPolicy` yang dikenakan pada Pod-Pod tersebut. +Apabila terdapat `NetworkPolicy` di dalam _namespace_ yang dikenakan pada suatu Pod, Pod tersebut +akan menolak koneksi yang tidak diizinkan `NetworkPolicy`. (Pod lain dalam _namespace_ yang tidak dikenakan `NetworkPolicy` akan tetap menerima trafik dari semua _resource_.) ## _Resource_ `NetworkPolicy` @@ -74,12 +74,12 @@ spec: port: 5978 ``` -Mengirimkan ini ke API server dengan metode POST tidak akan berdampak apa pun +Mengirimkan ini ke API server dengan metode POST tidak akan berdampak apa pun kecuali penyedia jaringan mendukung network policy. **_Field-field_ yang bersifat wajib**: Sama dengan seluruh _config_ Kubernetes lainnya, sebuah `NetworkPolicy` -membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai -bagaimana bekerja dengan _file_ `config`, dapat dilihat di +membutuhkan _field-field_ `apiVersion`, `kind`, dan `metadata`. Informasi generik mengenai +bagaimana bekerja dengan _file_ `config`, dapat dilihat di [Konfigurasi Kontainer menggunakan `ConfigMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/), serta [Manajemen Objek](/docs/concepts/overview/object-management-kubectl/overview/). @@ -143,37 +143,37 @@ mengandung sebuah elemen `from` yang mengizinkan koneksi dari Pod-Pod dengan lab ... ``` -mengandung dua elemen pada _array_ `from`, dan mengizinkan koneksi dari Pod pada Namespace lokal dengan label +mengandung dua elemen pada _array_ `from`, dan mengizinkan koneksi dari Pod pada Namespace lokal dengan label `role=client`, *atau* dari Pod di _namespace_ apa pun dengan label `user=alice`. -Ketika kamu merasa ragu, gunakan `kubectl describe` untuk melihat bagaimana Kubernetes +Ketika kamu merasa ragu, gunakan `kubectl describe` untuk melihat bagaimana Kubernetes menginterpretasikan _policy_ tersebut. -**ipBlock**: Ini digunakan untuk memilih _range_ IP CIDR tertentu untuk berperan sebagai -_source_ _ingress_ atau destinasi _egress_. Alamat yang digunakan harus merupakan -alamat IP eksternal kluster, karena alamat IP Pod bersifat _ephemeral_ dan tidak dapat ditebak. +**ipBlock**: Ini digunakan untuk memilih _range_ IP CIDR tertentu untuk berperan sebagai +_source_ _ingress_ atau destinasi _egress_. Alamat yang digunakan harus merupakan +alamat IP eksternal kluster, karena alamat IP Pod bersifat _ephemeral_ dan tidak dapat ditebak. -Mekanisme _ingress_ dan _egress_ kluster seringkali membutuhkan mekanisme _rewrite_ alamat IP _source_ dan destinasi -paket. Pada kasus-kasus dimana hal ini, tidak dapat dipastikan bahwa apakah hal ini - terjadi sebelum atau setelah pemrosesan `NetworkPolicy`, dan perilaku yang ada mungkin saja berbeda - untuk kombinasi _plugin_ jaringan, penyedia layanan _cloud_, serta implementasi `Service` yang berbeda. +Mekanisme _ingress_ dan _egress_ kluster seringkali membutuhkan mekanisme _rewrite_ alamat IP _source_ dan destinasi +paket. Pada kasus-kasus dimana hal ini, tidak dapat dipastikan bahwa apakah hal ini + terjadi sebelum atau setelah pemrosesan `NetworkPolicy`, dan perilaku yang ada mungkin saja berbeda + untuk kombinasi _plugin_ jaringan, penyedia layanan _cloud_, serta implementasi `Service` yang berbeda. -Pada _ingress_, artinya bisa saja kamu melakukan _filter_ paket yang masuk berdasarkan `source IP`, -sementara di kasus lain "source IP" yang digunakan oleh Network Policy adalah alamat IP `LoadBalancer`, +Pada _ingress_, artinya bisa saja kamu melakukan _filter_ paket yang masuk berdasarkan `source IP`, +sementara di kasus lain "source IP" yang digunakan oleh Network Policy adalah alamat IP `LoadBalancer`, _node_ dimana Pod berada, dsb. -Pada _egress_, bisa saja sebuah koneksi dari Pod ke IP `Service` di-_rewrite_ ke IP eksternal kluster +Pada _egress_, bisa saja sebuah koneksi dari Pod ke IP `Service` di-_rewrite_ ke IP eksternal kluster atau bahkan tidak termasuk di dalam `ipBlock` _policy_. ## _Policy_ _Default_ -Secara _default_, jika tidak ada _policy_ yang ada dalam suatu _namespace_, maka semua trafik _ingress_ dan _egress_ yang diizinkan ke atau dari Pod dalam _namespace_. +Secara _default_, jika tidak ada _policy_ yang ada dalam suatu _namespace_, maka semua trafik _ingress_ dan _egress_ yang diizinkan ke atau dari Pod dalam _namespace_. Contoh di bawah ini akan memberikan gambaran bagaimana kamu dapat mengubah perilaku _default_ pada sebuah _namespace_. ### _Default_: tolak semua trafik _ingress_ -Kamu dapat membuat _policy_ isolasi `"default"` untuk sebuah _namespace_ -dengan membuat sebuah `NetworkPolicy` yang memilih semua Pod tapi tidak mengizinkan +Kamu dapat membuat _policy_ isolasi `"default"` untuk sebuah _namespace_ +dengan membuat sebuah `NetworkPolicy` yang memilih semua Pod tapi tidak mengizinkan trafik _ingress_ masuk ke Pod-Pod tersebut. ```yaml @@ -187,13 +187,13 @@ spec: - Ingress ``` -Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` lain masih terisolasi. +Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` lain masih terisolasi. _Policy_ ini tidak mengubah perilaku _default_ dari _egress_. ### _Default_: izinkan semua trafik _ingress_ -Jika kamu ingin mengizinkan semua trafik _ingress_ pada semua Pod dalam sebuah _namespace_ -(bahkan jika _policy_ ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu +Jika kamu ingin mengizinkan semua trafik _ingress_ pada semua Pod dalam sebuah _namespace_ +(bahkan jika _policy_ ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu dapat secara eksplisit mengizinkan semua trafik bagi _namespace_ tersebut. ```yaml @@ -211,8 +211,8 @@ spec: ### _Default_: tolak semua trafik _egress_ -Kamu dapat membuat _policy_ isolasi `"default"` untuk sebuah _namespace_ -dengan membuat sebuah `NetworkPolicy` yang memilih semua Pod tapi tidak mengizinkan +Kamu dapat membuat _policy_ isolasi `"default"` untuk sebuah _namespace_ +dengan membuat sebuah `NetworkPolicy` yang memilih semua Pod tapi tidak mengizinkan trafik _egress_ keluar dari Pod-Pod tersebut. ```yaml @@ -226,13 +226,13 @@ spec: - Egress ``` -Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` lain masih terisolasi. +Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` lain masih terisolasi. _Policy_ ini tidak mengubah perilaku _default_ dari _ingress_. ### _Default_: izinkan semua trafik _egress_ -Jika kamu ingin mengizinkan semua trafik _egress_ pada semua Pod dalam sebuah _namespace_ -(bahkan jika _policy_ ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu +Jika kamu ingin mengizinkan semua trafik _egress_ pada semua Pod dalam sebuah _namespace_ +(bahkan jika _policy_ ditambahkan dan menyebabkan beberapa Pod menjadi terisolasi), kamu dapat secara eksplisit mengizinkan semua trafik bagi _namespace_ tersebut. ```yaml diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md index 6ddf050cd49c9..f2d2bf9125bbc 100644 --- a/content/id/docs/concepts/services-networking/service.md +++ b/content/id/docs/concepts/services-networking/service.md @@ -3,7 +3,7 @@ title: Service feature: title: Service discovery dan load balancing description: > - Kamu tidak perlu memodifikasi aplikasi kamu untuk menggunakan mekanisme _service discovery_ tambahan. Kubernetes menyediakan IP untuk setiap kontainer serta sebuah DNS bagi sebuah sekumpulan kontainer, serta akan melakukan mekanisme _load balance_ bagi sekumpulan kontainer tersebut. + Kamu tidak perlu memodifikasi aplikasi kamu untuk menggunakan mekanisme _service discovery_ tambahan. Kubernetes menyediakan IP untuk setiap kontainer serta sebuah DNS bagi sebuah sekumpulan kontainer, serta akan melakukan mekanisme _load balance_ bagi sekumpulan kontainer tersebut. content_template: templates/concept weight: 10 @@ -12,33 +12,33 @@ weight: 10 {{% capture overview %}} -[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*. -Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut -tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara -khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*). -Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP -yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil. +[`Pod`](/docs/concepts/workloads/pods/pod/) pada Kubernetes bersifat *mortal*. +Artinya apabila _pod-pod_ tersebut dibuat dan kemudian mati, _pod-pod_ tersebut +tidak akan dihidupkan kembali. [`ReplicaSets`](/docs/concepts/workloads/controllers/replicaset/) secara +khusus bertugas membuat dan menghapus `Pod` secara dinamsi (misalnya, pada proses *scaling out* atau *scaling in*). +Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat mengandalkan alamat IP +yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil. Hal ini kemudian menimbulkan pertanyaan baru: apabila sebuah sekumpulan `Pod` (yang selanjutnya kita sebut _backend_) -menyediakan _service_ bagi sebuah sekumpulan `Pod` lain (yang selanjutnya kita sebut _frontend_) di dalam +menyediakan _service_ bagi sebuah sekumpulan `Pod` lain (yang selanjutnya kita sebut _frontend_) di dalam kluster Kubernetes, bagaimana cara _frontend_ menemukan _backend_ mana yang digunakan? Inilah alasan kenapa `Service` ada. -Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi +Sebuah `Service` pada Kubernetes adalah sebuah abstraksi yang memberikan definisi set logis yang terdiri beberapa `Pod` serta _policy_ bagaimana cara kamu mengakses sekumpulan `Pod` tadi - seringkali disebut sebagai _microservices_. -Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors) -(lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa +Set `Pod` yang dirujuk oleh suatu `Service` (biasanya) ditentukan oleh sebuah [`Label Selector`](/docs/concepts/overview/working-with-objects/labels/#label-selectors) +(lihat penjelasan di bawah untuk mengetahui alasan kenapa kamu mungkin saja membutuhkan `Service` tanpa sebuah _selector_). -Sebagai contoh, misalnya terdapat sebuah _backend_ yang menyediakan fungsionalitas _image-processing_ +Sebagai contoh, misalnya terdapat sebuah _backend_ yang menyediakan fungsionalitas _image-processing_ yang memiliki 3 buah _replica_. _Replica-replica_ tadi sifatnya sepadan - dengan kata lain _frontend_ -tidak peduli _backend_ manakah yang digunakan. Meskipun `Pod` penyusun sekumpulan _backend_ bisa berubah, -_frontend_ tidak perlu peduli bagaimana proses ini dijalankan atau menyimpan _list_ dari _backend-backend_ +tidak peduli _backend_ manakah yang digunakan. Meskipun `Pod` penyusun sekumpulan _backend_ bisa berubah, +_frontend_ tidak perlu peduli bagaimana proses ini dijalankan atau menyimpan _list_ dari _backend-backend_ yang ada saat itu. `Service` memiliki tujuan untuk _decouple_ mekanisme ini. -Untuk aplikasi yang dijalankan di atas Kubernetes, Kubernetes menyediakan API _endpoint_ sederhana -yang terus diubah apabila _state_ sebuah sekumpulan `Pod` di dalam suatu `Service` berubah. Untuk -aplikasi _non-native_, Kubernetes menyediakan _bridge_ yang berbasis _virtual-IP_ bagi `Service` +Untuk aplikasi yang dijalankan di atas Kubernetes, Kubernetes menyediakan API _endpoint_ sederhana +yang terus diubah apabila _state_ sebuah sekumpulan `Pod` di dalam suatu `Service` berubah. Untuk +aplikasi _non-native_, Kubernetes menyediakan _bridge_ yang berbasis _virtual-IP_ bagi `Service` yang diarahkan pada `Pod` _backend_. {{% /capture %}} @@ -47,9 +47,9 @@ yang diarahkan pada `Pod` _backend_. ## Mendefinisikan sebuah `Service` -Sebuah `Service` di Kubernetes adalah sebuah objek REST, layaknya sebuah `Pod`. Seperti semua -objek _REST_, definisi `Service` dapat dikirim dengan _method POST_ pada _apiserver_ untuk membuat -sebuah instans baru. Sebagai contoh, misalnya saja kamu memiliki satu sekumpulan `Pod` yang mengekspos _port_ +Sebuah `Service` di Kubernetes adalah sebuah objek REST, layaknya sebuah `Pod`. Seperti semua +objek _REST_, definisi `Service` dapat dikirim dengan _method POST_ pada _apiserver_ untuk membuat +sebuah instans baru. Sebagai contoh, misalnya saja kamu memiliki satu sekumpulan `Pod` yang mengekspos _port_ 9376 dan memiliki _label_ `"app=MyApp"`. ```yaml @@ -66,38 +66,38 @@ spec: targetPort: 9376 ``` -Spesifikasi ini akan ditranslasikan sebagai sebuah objek `Service` baru dengan nama `"my-service"` -dengan _target port_ 9376 pada setiap `Pod` yang memiliki _label_ `"app=MyApp"`. `Service` ini -juga akan memiliki alamat IP tersendiri (yang terkadang disebut sebagai _"cluster IP"_), yang nantinya -akan digunakan oleh _service proxy_ (lihat di bagian bawah). _Selector_ pada `Service` akan selalu dievaluasi -dan hasilnya akan kembali dikirim dengan menggunakan _method POST_ ke objek `Endpoints` +Spesifikasi ini akan ditranslasikan sebagai sebuah objek `Service` baru dengan nama `"my-service"` +dengan _target port_ 9376 pada setiap `Pod` yang memiliki _label_ `"app=MyApp"`. `Service` ini +juga akan memiliki alamat IP tersendiri (yang terkadang disebut sebagai _"cluster IP"_), yang nantinya +akan digunakan oleh _service proxy_ (lihat di bagian bawah). _Selector_ pada `Service` akan selalu dievaluasi +dan hasilnya akan kembali dikirim dengan menggunakan _method POST_ ke objek `Endpoints` yang juga disebut `"my-service"`. -Perhatikan bahwa sebuah `Service` dapat melakukan pemetaan setiap _incoming port_ pada `targetPort` +Perhatikan bahwa sebuah `Service` dapat melakukan pemetaan setiap _incoming port_ pada `targetPort` mana pun. Secara _default_, _field_ `targetPort` akan memiliki _value_ yang sama dengan _value_ dari _field_ `port`. -Hal menarik lainnya adalah _value_ dari `targetPort` bisa saja berupa string yang merujuk pada nama -dari _port_ yang didefinisikan pada `Pod` _backend_. Nomor _port_ yang diberikan pada _port_ dengan nama -tadi bisa saja memiliki nilai yang berbeda di setiap `Pod` _backend_. Hal ini memberikan fleksibilitas -pada saat kamu melakukan _deploy_ atau melakukan perubahan terhadap `Service`. Misalnya saja suatu saat -kamu ingin mengubah nomor _port_ yang ada pada `Pod` _backend_ pada rilis selanjutnya tanpa menyebabkan +Hal menarik lainnya adalah _value_ dari `targetPort` bisa saja berupa string yang merujuk pada nama +dari _port_ yang didefinisikan pada `Pod` _backend_. Nomor _port_ yang diberikan pada _port_ dengan nama +tadi bisa saja memiliki nilai yang berbeda di setiap `Pod` _backend_. Hal ini memberikan fleksibilitas +pada saat kamu melakukan _deploy_ atau melakukan perubahan terhadap `Service`. Misalnya saja suatu saat +kamu ingin mengubah nomor _port_ yang ada pada `Pod` _backend_ pada rilis selanjutnya tanpa menyebabkan permasalahan pada sisi klien. -Secara _default_, protokol yang digunakan pada _service_ adalah `TCP`, tapi kamu bisa saja menggunakan -[protokol yang tersedia](#protokol-yang-tersedia). Karena banyak `Service` memiliki kebutuhan untuk -mengekspos lebih dari sebuah _port_, Kubernetes menawarkan definisi _multiple_ _port_ pada sebuah objek -_Service_. Setiap definisi _port_ dapat memiliki protokol yang berbeda. +Secara _default_, protokol yang digunakan pada _service_ adalah `TCP`, tapi kamu bisa saja menggunakan +[protokol yang tersedia](#protokol-yang-tersedia). Karena banyak `Service` memiliki kebutuhan untuk +mengekspos lebih dari sebuah _port_, Kubernetes menawarkan definisi _multiple_ _port_ pada sebuah objek +_Service_. Setiap definisi _port_ dapat memiliki protokol yang berbeda. ### `Service` tanpa _selector_ -Secara umum, `Service` memberikan abstraksi mekanisme yang dilakukan untuk mengakses `Pod`, tapi +Secara umum, `Service` memberikan abstraksi mekanisme yang dilakukan untuk mengakses `Pod`, tapi mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja: - * Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_, - kamu ingin menggunakan basis datamu sendiri. - * Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada - [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan kluster yang berbeda. - * Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih - berada di luar kluster Kubernetes. + * Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_, + kamu ingin menggunakan basis datamu sendiri. + * Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada + [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan kluster yang berbeda. + * Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih + berada di luar kluster Kubernetes. Berdasarkan skenario-skenario di atas, kamu dapat membuat sebuah `Service` tanpa _selector_: @@ -113,7 +113,7 @@ spec: targetPort: 9376 ``` -Karena `Service` ini tidak memiliki _selector_, objek `Endpoints` bagi `Service` ini tidak akan dibuat. +Karena `Service` ini tidak memiliki _selector_, objek `Endpoints` bagi `Service` ini tidak akan dibuat. Dengan demikian, kamu bisa membuat `Endpoints` yang kamu inginkan: ```yaml @@ -129,62 +129,62 @@ subsets: ``` {{< note >}} -Perhatikan bahwa alamat IP yang kamu buat untuk `Endpoints` tidak boleh berupa -_loopback_ (127.0.0.0/8), _link-local_ (169.254.0.0/16), atau _link-local multicast_ (224.0.0.0/24). +Perhatikan bahwa alamat IP yang kamu buat untuk `Endpoints` tidak boleh berupa +_loopback_ (127.0.0.0/8), _link-local_ (169.254.0.0/16), atau _link-local multicast_ (224.0.0.0/24). Alamat IP tersebut juga tidak boleh berupa _cluster IP_ dari `Service` Kubernetes lainnya, karena `kube-proxy` belum menyediakan dukungan IP virtual sebagai _destination_. {{< /note >}} -Cara mengakses suatu `Service` tanpa _selector_ sama saja dengan mengakses suatu `Service` -dengan _selector_. Trafik yang ada akan di-*route* ke `Endpoints` yang dispesifikasikan oleh +Cara mengakses suatu `Service` tanpa _selector_ sama saja dengan mengakses suatu `Service` +dengan _selector_. Trafik yang ada akan di-*route* ke `Endpoints` yang dispesifikasikan oleh pengguna (dalam contoh kali ini adalah `1.2.3.4:9376`). -Sebuah `ExternalName` `Service` merupakan kasus spesial dari `Service` -dimana `Service` tidak memiliki _selector_ dan menggunakan penamaan _DNS_. Untuk +Sebuah `ExternalName` `Service` merupakan kasus spesial dari `Service` +dimana `Service` tidak memiliki _selector_ dan menggunakan penamaan _DNS_. Untuk informasi lebih lanjut silahkan baca bagian [ExternalName](#externalname). ## IP Virtual dan _proxy_ `Service` -Setiap *node* di kluster Kubernetes menjalankan `kube-proxy`. `kube-proxy` -bertanggung jawab terhadap implementasi IP virtual bagi _Services_ dengan tipe +Setiap *node* di kluster Kubernetes menjalankan `kube-proxy`. `kube-proxy` +bertanggung jawab terhadap implementasi IP virtual bagi _Services_ dengan tipe selain [`ExternalName`](#externalname). -Pada Kubernetes versi v1.0, _Services_ adalah "layer 4" (TCP/UDP pada IP), _proxy_ -yang digunakan murni berada pada _userspace_. Pada Kubernetes v1.1, API `Ingress` -ditambahkan untuk merepresentasikan "layer 7"(HTTP), _proxy_ `iptables` juga ditambahkan +Pada Kubernetes versi v1.0, _Services_ adalah "layer 4" (TCP/UDP pada IP), _proxy_ +yang digunakan murni berada pada _userspace_. Pada Kubernetes v1.1, API `Ingress` +ditambahkan untuk merepresentasikan "layer 7"(HTTP), _proxy_ `iptables` juga ditambahkan dan menjadi mode operasi _default_ sejak Kubernetes v1.2. Pada Kubernetes v1.8.0-beta.0, _proxy_ _ipvs_ juga ditambahkan. ### Mode _Proxy_: _userspace_ -Pada mode ini, `kube-proxy` mengamati master Kubernetes apabila terjadi penambahan -atau penghapusan objek `Service` dan `Endpoints`. Untuk setiap `Service`, `kube-proxy` -akan membuka sebuah _port_ (yang dipilih secara acak) pada *node* lokal. Koneksi -pada _"proxy port"_ ini akan dihubungkan pada salah satu `Pod` _backend_ dari `Service` -(yang tercatat pada `Endpoints`). `Pod` _backend_ yang akan digunakan akan diputuskan berdasarkan -`SessionAffinity` pada `Service`. Langkah terakhir yang dilakukan oleh `kube-proxy` -adalah melakukan instalasi _rules_ `iptables` yang akan mengarahkan trafik yang ada pada -`clusterIP` (IP virtual) dan _port_ dari `Service` serta melakukan _redirect_ trafik ke _proxy_ -yang memproksikan `Pod` _backend_. Secara _default_, mekanisme _routing_ yang dipakai adalah +Pada mode ini, `kube-proxy` mengamati master Kubernetes apabila terjadi penambahan +atau penghapusan objek `Service` dan `Endpoints`. Untuk setiap `Service`, `kube-proxy` +akan membuka sebuah _port_ (yang dipilih secara acak) pada *node* lokal. Koneksi +pada _"proxy port"_ ini akan dihubungkan pada salah satu `Pod` _backend_ dari `Service` +(yang tercatat pada `Endpoints`). `Pod` _backend_ yang akan digunakan akan diputuskan berdasarkan +`SessionAffinity` pada `Service`. Langkah terakhir yang dilakukan oleh `kube-proxy` +adalah melakukan instalasi _rules_ `iptables` yang akan mengarahkan trafik yang ada pada +`clusterIP` (IP virtual) dan _port_ dari `Service` serta melakukan _redirect_ trafik ke _proxy_ +yang memproksikan `Pod` _backend_. Secara _default_, mekanisme _routing_ yang dipakai adalah _round robin_. ![Ikhtisar diagram _Services_ pada _proxy_ _userspace_](/images/docs/services-userspace-overview.svg) ### Mode _Proxy_: iptables -Pada mode ini, `kube-proxy` mengamati master Kubernetes apabila terjadi penambahan -atau penghapusan objek `Service` dan `Endpoints`. Untuk setiap `Service`, +Pada mode ini, `kube-proxy` mengamati master Kubernetes apabila terjadi penambahan +atau penghapusan objek `Service` dan `Endpoints`. Untuk setiap `Service`, `kube-proxy` akan melakukan instalasi _rules_ `iptables` yang akan mengarahkan -trafik ke `clusterIP` (IP virtual) dan _port_ dari `Service`. Untuk setiap objek `Endpoints`, -`kube-proxy` akan melakukan instalasi _rules_ `iptables` yang akan memilih satu buah `Pod` +trafik ke `clusterIP` (IP virtual) dan _port_ dari `Service`. Untuk setiap objek `Endpoints`, +`kube-proxy` akan melakukan instalasi _rules_ `iptables` yang akan memilih satu buah `Pod` _backend_. Secara _default_, pemilihan _backend_ ini dilakukan secara acak. -Tentu saja, `iptables` yang digunakan tidak boleh melakukan _switching_ -antara _userspace_ dan _kernelspace_, mekanisme ini harus lebih kokoh dan lebih cepat -dibandingkan dengan _userspace_ _proxy_. Meskipun begitu, berbeda dengan mekanisme -_proxy_ _userspace_, _proxy_ `iptables` tidak bisa secara langsung menjalankan mekanisme -_retry_ ke `Pod` lain apabila `Pod` yang sudah dipilih sebelumnya tidak memberikan respons, -dengan kata lain hal ini akan sangat bergantung pada +Tentu saja, `iptables` yang digunakan tidak boleh melakukan _switching_ +antara _userspace_ dan _kernelspace_, mekanisme ini harus lebih kokoh dan lebih cepat +dibandingkan dengan _userspace_ _proxy_. Meskipun begitu, berbeda dengan mekanisme +_proxy_ _userspace_, _proxy_ `iptables` tidak bisa secara langsung menjalankan mekanisme +_retry_ ke `Pod` lain apabila `Pod` yang sudah dipilih sebelumnya tidak memberikan respons, +dengan kata lain hal ini akan sangat bergantung pada [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#defining-readiness-probes). ![Ikhtisar diagram _Services_ pada _proxy_ `iptables`](/images/docs/services-iptables-overview.svg) @@ -193,16 +193,16 @@ dengan kata lain hal ini akan sangat bergantung pada {{< feature-state for_k8s_version="v1.9" state="beta" >}} -Pada mode ini, `kube-proxy` mengamati _Services_ dan `Endpoints`, kemudian memanggil -_interface_ _netlink_ untuk membuat _rules_ _ipvs_ yang sesuai serta melakukan sinkronisasi -_rules_ _ipvs_ dengan _Services_ dan `Endpoints` Kubernetes secara periodik, untuk memastikan -status _ipvs_ konsisten dengan apa yang diharapkan. Ketika sebuah _Services_ diakses, +Pada mode ini, `kube-proxy` mengamati _Services_ dan `Endpoints`, kemudian memanggil +_interface_ _netlink_ untuk membuat _rules_ _ipvs_ yang sesuai serta melakukan sinkronisasi +_rules_ _ipvs_ dengan _Services_ dan `Endpoints` Kubernetes secara periodik, untuk memastikan +status _ipvs_ konsisten dengan apa yang diharapkan. Ketika sebuah _Services_ diakses, trafik yang ada akan diarahkan ke salah satu `Pod` _backend_. -Sama halnya dengan `iptables`, _ipvs_ juga berdasarkan pada fungsi _hook_ _netfilter_, +Sama halnya dengan `iptables`, _ipvs_ juga berdasarkan pada fungsi _hook_ _netfilter_, bedanya adalah _ipvs_ menggunakan struktur data _hash table_ dan bekerja di _kernelspace_. -Dengan kata lain _ipvs_ melakukan _redirect_ trafik dengan lebih cepat dan dengan performa yang lebih -baik ketika melakukan sinkronisasi _rules_ _proxy_. Selain itu, _ipvs_ juga menyediakan +Dengan kata lain _ipvs_ melakukan _redirect_ trafik dengan lebih cepat dan dengan performa yang lebih +baik ketika melakukan sinkronisasi _rules_ _proxy_. Selain itu, _ipvs_ juga menyediakan lebih banyak opsi algoritma _load balancing_: - `rr`: round-robin @@ -213,28 +213,28 @@ lebih banyak opsi algoritma _load balancing_: - `nq`: never queue {{< note >}} -Mode _ipvs_ menggunakan _module_ _IPVS_ _kernel_ yang diinstal pada *node* -sebelum `kube-proxy` dijalankan. Ketika `kube-proxy` dijalankan dengan mode _proxy_ _ipvs_, -`kube-proxy` akan melakukan proses validasi, apakah _module_ _IPVS_ sudah diinstal di *node*, +Mode _ipvs_ menggunakan _module_ _IPVS_ _kernel_ yang diinstal pada *node* +sebelum `kube-proxy` dijalankan. Ketika `kube-proxy` dijalankan dengan mode _proxy_ _ipvs_, +`kube-proxy` akan melakukan proses validasi, apakah _module_ _IPVS_ sudah diinstal di *node*, jika _module_ tersebut belum diinstal, maka `kube-proxy` akan menggunakan mode `iptables`. {{< /note >}} ![Ikhtisar diagram _Services_ pada _proxy_ _ipvs_](/images/docs/services-ipvs-overview.svg) -Dari sekian model _proxy_ yang ada, trafik _inbound_ apa pun yang ada diterima oleh _IP:Port_ pada `Service` -akan dilanjutkan melalui _proxy_ pada _backend_ yang sesuai, dan klien tidak perlu mengetahui -apa informasi mendetail soal Kubernetes, `Service`, atau `Pod`. afinitas _session_ (_session affinity_) berbasis -_Client-IP_ dapat dipilih dengan cara menerapkan nilai _"ClientIP"_ pada `service.spec.sessionAffinity` -(nilai _default_ untuk hal ini adalah _"None"_), kamu juga dapat mengatur nilai maximum _session_ -_timeout_ yang ada dengan mengatur opsi `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` jika -sebelumnya kamu sudah menerapkan nilai _"ClusterIP"_ pada `service.spec.sessionAffinity` +Dari sekian model _proxy_ yang ada, trafik _inbound_ apa pun yang ada diterima oleh _IP:Port_ pada `Service` +akan dilanjutkan melalui _proxy_ pada _backend_ yang sesuai, dan klien tidak perlu mengetahui +apa informasi mendetail soal Kubernetes, `Service`, atau `Pod`. afinitas _session_ (_session affinity_) berbasis +_Client-IP_ dapat dipilih dengan cara menerapkan nilai _"ClientIP"_ pada `service.spec.sessionAffinity` +(nilai _default_ untuk hal ini adalah _"None"_), kamu juga dapat mengatur nilai maximum _session_ +_timeout_ yang ada dengan mengatur opsi `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` jika +sebelumnya kamu sudah menerapkan nilai _"ClusterIP"_ pada `service.spec.sessionAffinity` (nilai _default_ untuk opsi ini adalah _"10800"_). ## _Multi-Port Services_ -Banyak _Services_ dengan kebutuhan untuk mengekspos lebih dari satu _port_. -Untuk kebutuhan inilah, Kubernetes mendukung _multiple_ _port_ _definitions_ pada objek `Service`. -Ketika menggunakan _multiple_ _port_, kamu harus memberikan nama pada setiap _port_ yang didefinisikan, +Banyak _Services_ dengan kebutuhan untuk mengekspos lebih dari satu _port_. +Untuk kebutuhan inilah, Kubernetes mendukung _multiple_ _port_ _definitions_ pada objek `Service`. +Ketika menggunakan _multiple_ _port_, kamu harus memberikan nama pada setiap _port_ yang didefinisikan, sehingga _Endpoint_ yang dibentuk tidak ambigu. Contoh: ```yaml @@ -256,35 +256,35 @@ spec: targetPort: 9377 ``` -Perhatikan bahwa penamaan _port_ hanya boleh terdiri dari karakter _alphanumeric_ _lowercase_ -dan _-_, serta harus dimulai dan diakhiri dengan karakter _alphanumeric_, misalnya saja `123-abc` dan `web` +Perhatikan bahwa penamaan _port_ hanya boleh terdiri dari karakter _alphanumeric_ _lowercase_ +dan _-_, serta harus dimulai dan diakhiri dengan karakter _alphanumeric_, misalnya saja `123-abc` dan `web` merupakan penamaan yang valid, tapi `123_abc` dan `-web` bukan merupakan penamaan yang valid. ## Memilih sendiri alamat IP yang kamu inginkan -Kamu dapat memberikan spesifikasi alamat _cluster IP_ yang kamu inginkan -sebagai bagian dari _request_ pembuatan objek `Service`. Untuk melakukan hal ini, -kamu harus mengisi _fields_ `.spec.clusterIP` field. Contoh penggunaannya adalah sebagai berikut, -misalnya saja kamu sudah memiliki _entry_ DNS yang ingin kamu gunakan kembali, -atau sebuah sistem _legacy_ yang sudah diatur pada alamat IP spesifik -dan sulit untuk diubah. Alamat IP yang ingin digunakan pengguna haruslah merupakan alamat IP -yang valid dan berada di dalam _range_ _CIDR_ `service-cluster-ip-range` yang dispesifikasikan di dalam -penanda yang diberikan _apiserver_. Jika _value_ yang diberikan tidak valid, _apiserver_ akan +Kamu dapat memberikan spesifikasi alamat _cluster IP_ yang kamu inginkan +sebagai bagian dari _request_ pembuatan objek `Service`. Untuk melakukan hal ini, +kamu harus mengisi _fields_ `.spec.clusterIP` field. Contoh penggunaannya adalah sebagai berikut, +misalnya saja kamu sudah memiliki _entry_ DNS yang ingin kamu gunakan kembali, +atau sebuah sistem _legacy_ yang sudah diatur pada alamat IP spesifik +dan sulit untuk diubah. Alamat IP yang ingin digunakan pengguna haruslah merupakan alamat IP +yang valid dan berada di dalam _range_ _CIDR_ `service-cluster-ip-range` yang dispesifikasikan di dalam +penanda yang diberikan _apiserver_. Jika _value_ yang diberikan tidak valid, _apiserver_ akan mengembalikan _response_ _code_ HTTP _422_ yang mengindikasikan _value_ yang diberikan tidak valid. ### Mengapa tidak menggunakan DNS _round-robin_? -Pertanyaan yang selalu muncul adalah kenapa kita menggunakan IP virtual dan bukan +Pertanyaan yang selalu muncul adalah kenapa kita menggunakan IP virtual dan bukan DNS _round-robin_ standar? Terdapat beberapa alasan dibalik semua itu: - * Terdapat sejarah panjang dimana _library_ DNS tidak mengikuti _TTL_ DNS dan + * Terdapat sejarah panjang dimana _library_ DNS tidak mengikuti _TTL_ DNS dan melakukan _caching_ hasil dari _lookup_ yang dilakukan. - * Banyak aplikasi yang melakukan _lookup_ DNS hanya sekali dan kemudian melakukan _cache_ hasil yang diperoleh. - * Bahkan apabila aplikasi dan _library_ melakukan resolusi ulang yang _proper_, _load_ dari setiap - klien yang melakukan resolusi ulang DNS akan sulit untuk di _manage_. + * Banyak aplikasi yang melakukan _lookup_ DNS hanya sekali dan kemudian melakukan _cache_ hasil yang diperoleh. + * Bahkan apabila aplikasi dan _library_ melakukan resolusi ulang yang _proper_, _load_ dari setiap + klien yang melakukan resolusi ulang DNS akan sulit untuk di _manage_. -Kami berusaha untuk mengurangi ketertarikan pengguna untuk melakukan yang mungkin akan menyusahkan pengguna. -Dengan demikian, apabila terdapat justifikasi yang cukup kuat, kami mungkin saja memberikan implementasi +Kami berusaha untuk mengurangi ketertarikan pengguna untuk melakukan yang mungkin akan menyusahkan pengguna. +Dengan demikian, apabila terdapat justifikasi yang cukup kuat, kami mungkin saja memberikan implementasi alternatif yang ada. ## _Discovering services_ @@ -293,10 +293,10 @@ Kubernetes mendukung 2 buah mode primer untuk melakukan `Service` - variabel _en ### Variabel _Environment_ -Ketika sebuah `Pod` dijalankan pada *node*, _kubelet_ menambahkan seperangkat variabel _environment_ -untuk setiap `Service` yang aktif. _Environment_ yang didukung adalah [Docker links compatible](https://docs.docker.com/userguide/dockerlinks/) variabel (perhatikan -[makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) -dan variabel `{SVCNAME}_SERVICE_HOST` dan `{SVCNAME}_SERVICE_PORT`, dinama nama `Service` akan diubah +Ketika sebuah `Pod` dijalankan pada *node*, _kubelet_ menambahkan seperangkat variabel _environment_ +untuk setiap `Service` yang aktif. _Environment_ yang didukung adalah [Docker links compatible](https://docs.docker.com/userguide/dockerlinks/) variabel (perhatikan +[makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) +dan variabel `{SVCNAME}_SERVICE_HOST` dan `{SVCNAME}_SERVICE_PORT`, dinama nama `Service` akan diubah menjadi huruf kapital dan tanda _minus_ akan diubah menjadi _underscore_. Sebagai contoh, `Service` `"redis-master"` yang mengekspos _port_ TCP 6379 serta _alamat_ @@ -312,116 +312,116 @@ REDIS_MASTER_PORT_6379_TCP_PORT=6379 REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11 ``` -Hal ini merupakan kebutuhan yang urutannya harus diperhatikan - `Service` apa pun yang -akan diakses oleh sebuah `Pod` harus dibuat sebelum `Pod` tersebut dibuat, -jika tidak variabel _environment_ tidak akan diinisiasi. +Hal ini merupakan kebutuhan yang urutannya harus diperhatikan - `Service` apa pun yang +akan diakses oleh sebuah `Pod` harus dibuat sebelum `Pod` tersebut dibuat, +jika tidak variabel _environment_ tidak akan diinisiasi. Meskipun begitu, DNS tidak memiliki keterbatasan ini. ### DNS -Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional -(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah -terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk -_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh kluster, maka semua `Pod` akan secara otomatis +Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional +(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah +terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk +_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh kluster, maka semua `Pod` akan secara otomatis dapat melakukan resolusi DNS. -Sebagai contoh, apabila kamu memiliki sebuah `Service` dengan nama `"my-service"` pada _Namespace_ -_"my-ns"_, maka _record_ DNS `"my-service.my-ns"` akan dibuat. `Pod` yang berada di dalam -_Namespace_ _"my-ns"_ dapat langsung melakukan _lookup_ dengan hanya menggunakan `"my-service"`. -Sedangkan `Pod` yang berada di luar _Namespace_ _my-ns"_ harus menggunakan `"my-service.my-ns"`. +Sebagai contoh, apabila kamu memiliki sebuah `Service` dengan nama `"my-service"` pada _Namespace_ +_"my-ns"_, maka _record_ DNS `"my-service.my-ns"` akan dibuat. `Pod` yang berada di dalam +_Namespace_ _"my-ns"_ dapat langsung melakukan _lookup_ dengan hanya menggunakan `"my-service"`. +Sedangkan `Pod` yang berada di luar _Namespace_ _my-ns"_ harus menggunakan `"my-service.my-ns"`. Hasil dari resolusi ini menrupakan _cluster IP_. -Kubernetes juga menyediakan _record_ DNS SRV (service) untuk _named ports_. Jika -_Service_ `"my-service.my-ns"` memiliki _port_ dengan nama `"http"` dengan protokol `TCP`, -kamu dapat melakukan _query_ DNS SRV untuk `"_http._tcp.my-service.my-ns"` untuk mengetahui +Kubernetes juga menyediakan _record_ DNS SRV (service) untuk _named ports_. Jika +_Service_ `"my-service.my-ns"` memiliki _port_ dengan nama `"http"` dengan protokol `TCP`, +kamu dapat melakukan _query_ DNS SRV untuk `"_http._tcp.my-service.my-ns"` untuk mengetahui nomor _port_ yang digunakan oleh _http_. -Server DNS Kubernetes adalah satu-satunya cara untuk mengakses -_Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di +Server DNS Kubernetes adalah satu-satunya cara untuk mengakses +_Service_ dengan tipe `ExternalName`. Informasi lebih lanjut tersedia di [DNS _Pods_ dan _Services_](/docs/concepts/services-networking/dns-pod-service/). ## `Service` _headless_ -Terkadang kamu tidak membutuhkan mekanisme _load-balancing_ dan sebuah _single_ IP _Sevice_. -Dalam kasus ini, kamu dapat membuat _"headless"_ `Service` dengan cara memberikan spesifikasi +Terkadang kamu tidak membutuhkan mekanisme _load-balancing_ dan sebuah _single_ IP _Sevice_. +Dalam kasus ini, kamu dapat membuat _"headless"_ `Service` dengan cara memberikan spesifikasi _None_ pada _cluster IP_ (`.spec.clusterIP`). -Opsi ini memungkinkan pengguna mengurangi ketergantungan terhadap sistem Kubernetes -dengan cara memberikan kebebasan untuk mekanisme _service discovery_. Aplikasi akan -tetap membutuhkan mekanisme _self-registration_ dan _adapter service discovery_ +Opsi ini memungkinkan pengguna mengurangi ketergantungan terhadap sistem Kubernetes +dengan cara memberikan kebebasan untuk mekanisme _service discovery_. Aplikasi akan +tetap membutuhkan mekanisme _self-registration_ dan _adapter service discovery_ lain yang dapat digunakan berdasarkan API ini. -Untuk `Service` _"headless"_ alokasi _cluster IP_ tidak dilakukan dan `kube-proxy` -tidak me-_manage_ _Service-Service_, serta tidak terdapat mekanisme _load balancing_ -yang dilakukan. Bagaimana konfigurasi otomatis bagi DNS dilakukan bergantung pada +Untuk `Service` _"headless"_ alokasi _cluster IP_ tidak dilakukan dan `kube-proxy` +tidak me-_manage_ _Service-Service_, serta tidak terdapat mekanisme _load balancing_ +yang dilakukan. Bagaimana konfigurasi otomatis bagi DNS dilakukan bergantung pada apakah `Service` tersebut memiliki _selector_ yang dispesifikasikan. ### Dengan _selector_ -Untuk `Service` _"headless"_ dengan _selector_, kontroler `Endpoints` akan membuat suatu -_record_ `Endpoints` di API, serta melakukan modifikasi konfigurasi DNS untuk mengembalikan +Untuk `Service` _"headless"_ dengan _selector_, kontroler `Endpoints` akan membuat suatu +_record_ `Endpoints` di API, serta melakukan modifikasi konfigurasi DNS untuk mengembalikan _A records (alamat)_ yang merujuk secara langsung pada `Pod` _backend_. ### Tanpa _selector_ -Untuk `Service` _"headless"_ tanpa _selector_, kontroler `Endpoints` -tidak akan membuat _record_ _Enpoints_. Meskipun demikian, +Untuk `Service` _"headless"_ tanpa _selector_, kontroler `Endpoints` +tidak akan membuat _record_ _Enpoints_. Meskipun demikian, sistem DNS tetap melakukan konfigurasi salah satu dari: * _record_ CNAME untuk [`ExternalName`](#externalname)-tipe services. - * _record_ untuk semua `Endpoints` yang memiliki nama `Service` yang sama, untuk + * _record_ untuk semua `Endpoints` yang memiliki nama `Service` yang sama, untuk tipe lainnya. ## Mekanisme _publish_ `Service` - jenis-jenis `Service` -Untuk beberapa bagian dari aplikasi yang kamu miliki (misalnya saja, _frontend_), -bisa saja kamu memiliki kebutuhan untuk mengekspos `Service` yang kamu miliki +Untuk beberapa bagian dari aplikasi yang kamu miliki (misalnya saja, _frontend_), +bisa saja kamu memiliki kebutuhan untuk mengekspos `Service` yang kamu miliki ke alamat IP eksternal (di luar kluster Kubernetes). -`ServiceTypes` yang ada pada Kubernetes memungkinkan kamu untuk menentukan -jenis `Service` apakah yang kamu butuhkan. Secara _default_, jenis `Service` +`ServiceTypes` yang ada pada Kubernetes memungkinkan kamu untuk menentukan +jenis `Service` apakah yang kamu butuhkan. Secara _default_, jenis `Service` yang diberikan adalah `ClusterIP`. _Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut: - * `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam kluster. Apabila kamu memilih _value_ ini - `Service` yang kamu miliki hanya dapat diakses secara internal. tipe ini adalah + * `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam kluster. Apabila kamu memilih _value_ ini + `Service` yang kamu miliki hanya dapat diakses secara internal. tipe ini adalah _default_ _value_ dari _ServiceType_. - * [`NodePort`](#nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis + * [`NodePort`](#nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis atau _port_ yang sama. Sebuah `Service` `ClusterIP`, yang mana `Service` `NodePort` akan di-_route_ , dibuat secara otomatis. Kamu dapat mengakses `Service` dengan tipe ini, dari luar kluster melalui `:`. - * [`LoadBalancer`](#loadbalancer): Mengekspos `Service` secara eksternal dengan menggunakan `LoadBalancer` - yang disediakan oleh penyedia layanan _cloud_. `Service` dengan tipe `NodePort` dan `ClusterIP`, + * [`LoadBalancer`](#loadbalancer): Mengekspos `Service` secara eksternal dengan menggunakan `LoadBalancer` + yang disediakan oleh penyedia layanan _cloud_. `Service` dengan tipe `NodePort` dan `ClusterIP`, dimana trafik akan di-_route_, akan dibuat secara otomatis. - * [`ExternalName`](#externalname): Melakukan pemetaan `Service` ke konten - dari _field_ `externalName` (misalnya: `foo.bar.example.com`), dengan cara mengembalikan - catatan `CNAME` beserta _value_-nya. Tidak ada metode _proxy_ apa pun yang diaktifkan. Mekanisme ini + * [`ExternalName`](#externalname): Melakukan pemetaan `Service` ke konten + dari _field_ `externalName` (misalnya: `foo.bar.example.com`), dengan cara mengembalikan + catatan `CNAME` beserta _value_-nya. Tidak ada metode _proxy_ apa pun yang diaktifkan. Mekanisme ini setidaknya membutuhkan `kube-dns` versi 1.7. ### Type NodePort {#nodeport} -Jika kamu menerapkan _value_ `NodePort` pada _field_ _type_, master Kubernetes akan mengalokasikan -_port_ dari _range_ yang dispesifikasikan oleh penanda `--service-node-port-range` (secara _default_, 30000-32767) -dan setiap _Node_ akan memproksikan _port_ tersebut (setiap _Node_ akan memiliki nomor _port_ yang sama) ke `Service` +Jika kamu menerapkan _value_ `NodePort` pada _field_ _type_, master Kubernetes akan mengalokasikan +_port_ dari _range_ yang dispesifikasikan oleh penanda `--service-node-port-range` (secara _default_, 30000-32767) +dan setiap _Node_ akan memproksikan _port_ tersebut (setiap _Node_ akan memiliki nomor _port_ yang sama) ke `Service` yang kamu miliki. `Port` tersebut akan dilaporkan pada _field_ `.spec.ports[*].nodePort` di `Service` kamu. -Jika kamu ingin memberikan spesifikasi IP tertentu untuk melakukan _poxy_ pada _port_. -kamu dapat mengatur penanda `--nodeport-addresses` pada `kube-proxy` untuk _range_ alamat IP -tertentu (mekanisme ini didukung sejak v1.10). Sebuah daftar yang dipisahkan koma (misalnya, _10.0.0.0/8_, _1.2.3.4/32_) -digunakan untuk mem-_filter_ alamat IP lokal ke _node_ ini. Misalnya saja kamu memulai `kube-proxy` dengan penanda -`--nodeport-addresses=127.0.0.0/8`, maka `kube-proxy` hanya akan memilih _interface_ _loopback_ untuk `Service` dengan tipe -`NodePort`. Penanda `--nodeport-addresses` memiliki nilai _default_ kosong (`[]`), yang artinya akan memilih semua _interface_ yang ada +Jika kamu ingin memberikan spesifikasi IP tertentu untuk melakukan _poxy_ pada _port_. +kamu dapat mengatur penanda `--nodeport-addresses` pada `kube-proxy` untuk _range_ alamat IP +tertentu (mekanisme ini didukung sejak v1.10). Sebuah daftar yang dipisahkan koma (misalnya, _10.0.0.0/8_, _1.2.3.4/32_) +digunakan untuk mem-_filter_ alamat IP lokal ke _node_ ini. Misalnya saja kamu memulai `kube-proxy` dengan penanda +`--nodeport-addresses=127.0.0.0/8`, maka `kube-proxy` hanya akan memilih _interface_ _loopback_ untuk `Service` dengan tipe +`NodePort`. Penanda `--nodeport-addresses` memiliki nilai _default_ kosong (`[]`), yang artinya akan memilih semua _interface_ yang ada dan sesuai dengan perilaku `NodePort` _default_. -Jika kamu menginginkan nomor _port_ yang berbeda, kamu dapat memberikan spesifikasi -_value_ dari _field_ _nodePort_, dan sistem yang ada akan mengalokasikan _port_ tersebut untuk kamu, -jika _port_ tersebut belum digunakan (perhatikan bahwa jika kamu menggunakan teknik ini, kamu perlu +Jika kamu menginginkan nomor _port_ yang berbeda, kamu dapat memberikan spesifikasi +_value_ dari _field_ _nodePort_, dan sistem yang ada akan mengalokasikan _port_ tersebut untuk kamu, +jika _port_ tersebut belum digunakan (perhatikan bahwa jika kamu menggunakan teknik ini, kamu perlu mempertimbangkan _collision_ yang mungkin terjadi dan bagaimana cara mengatasi hal tersebut) atau transaksi API yang dilakukan akan gagal. -Hal ini memberikan kebebasan bagi pengembang untuk memilih _load balancer_ yang akan digunakan, terutama apabila -_load balancer_ yang ingin digunakan belum didukung sepenuhnya oleh Kubernetes. +Hal ini memberikan kebebasan bagi pengembang untuk memilih _load balancer_ yang akan digunakan, terutama apabila +_load balancer_ yang ingin digunakan belum didukung sepenuhnya oleh Kubernetes. Perhatikan bahwa `Service` dapat diakses baik dengan menggunakan `:spec.ports[*].nodePort` atau `.spec.clusterIP:spec.ports[*].port`. (Jika penanda `--nodeport-addresses` diterapkan, dapat di-_filter_ dengan salah satu atau lebih _NodeIP_.) @@ -429,8 +429,8 @@ atau `.spec.clusterIP:spec.ports[*].port`. (Jika penanda `--nodeport-addresses` ### Type LoadBalancer {#loadbalancer} Pada penyedia layanan _cloud_ yang menyediakan pilihan _load balancer_ eksternal, pengaturan _field_ _type_ -ke `LoadBalancer` akan secara otomatis melakukan proses _provision_ _load balancer_ untuk `Service` yang kamu buat. -Informasi mengenai _load balancer_ yang dibuat akan ditampilkan pada _field_ `.status.loadBalancer` +ke `LoadBalancer` akan secara otomatis melakukan proses _provision_ _load balancer_ untuk `Service` yang kamu buat. +Informasi mengenai _load balancer_ yang dibuat akan ditampilkan pada _field_ `.status.loadBalancer` pada `Service` kamu. Contohnya: ```yaml @@ -454,37 +454,37 @@ status: - ip: 146.148.47.155 ``` -Trafik dari _load balancer_ eksternal akan diarahkan pada `Pod` _backend_, meskipun mekanisme -bagaimana hal ini dilakukan bergantung pada penyedia layanan _cloud_. Beberapa penyedia layanan -_cloud_ mengizinkan konfigurasi untuk _value_ `loadBalancerIP`. Dalam kasus tersebut, _load balancer_ akan dibuat -dengan _loadbalancerIP_ yang dispesifikasikan. Jika _value_ dari `loadBalancerIP` tidak dispesifikasikan. -sebuah IP sementara akan diberikan pada _loadBalancer_. Jika `loadBalancerIP` dispesifikasikan, -tetapi penyedia layanan _cloud_ tidak mendukung hal ini, maka _field_ yang ada akan diabaikan. - -**Catatan Khusus untuk Azure**: Untuk spesifikasi `loadBalancerIP` publik yang didefinisikan oleh pengguna, -sebuah alamat IP statis publik akan disediakan terlebih dahulu, dan alamat IP tersebut harus berada di -_resource group_ dari _resource_ yang secara otomatis dibuat oleh kluster. Misalnya saja, `MC_myResourceGroup_myAKSCluster_eastus`. -Berikan spesifikasi alamat IP sebagai `loadBalancerIP`. Pastikan kamu sudah melakukan _update_ pada -_securityGroupName_ pada _file_ konfigurasi penyedia layanan _cloud_. -Untuk informasi lebih lanjut mengenai _permission_ untuk `CreatingLoadBalancerFailed` kamu dapat membaca _troubleshooting_ untuk -[Penggunaan alamat IP statis pada _load balancer_ Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/static-ip) atau +Trafik dari _load balancer_ eksternal akan diarahkan pada `Pod` _backend_, meskipun mekanisme +bagaimana hal ini dilakukan bergantung pada penyedia layanan _cloud_. Beberapa penyedia layanan +_cloud_ mengizinkan konfigurasi untuk _value_ `loadBalancerIP`. Dalam kasus tersebut, _load balancer_ akan dibuat +dengan _loadbalancerIP_ yang dispesifikasikan. Jika _value_ dari `loadBalancerIP` tidak dispesifikasikan. +sebuah IP sementara akan diberikan pada _loadBalancer_. Jika `loadBalancerIP` dispesifikasikan, +tetapi penyedia layanan _cloud_ tidak mendukung hal ini, maka _field_ yang ada akan diabaikan. + +**Catatan Khusus untuk Azure**: Untuk spesifikasi `loadBalancerIP` publik yang didefinisikan oleh pengguna, +sebuah alamat IP statis publik akan disediakan terlebih dahulu, dan alamat IP tersebut harus berada di +_resource group_ dari _resource_ yang secara otomatis dibuat oleh kluster. Misalnya saja, `MC_myResourceGroup_myAKSCluster_eastus`. +Berikan spesifikasi alamat IP sebagai `loadBalancerIP`. Pastikan kamu sudah melakukan _update_ pada +_securityGroupName_ pada _file_ konfigurasi penyedia layanan _cloud_. +Untuk informasi lebih lanjut mengenai _permission_ untuk `CreatingLoadBalancerFailed` kamu dapat membaca _troubleshooting_ untuk +[Penggunaan alamat IP statis pada _load balancer_ Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/static-ip) atau [_CreatingLoadBalancerFailed_ pada kluster AKS dengan _advanced networking_](https://github.com/Azure/AKS/issues/357). {{< note >}} -Dukungan untuk SCTP _load balancer_ dari penyedia layanan _cloud_ bergantung pada -implementasi _load balancer_ yang disediakan oleh penyedia layanan _cloud_ tersebut. -Jika SCTP tidak didukung oleh _load balancer_ penyedia layanan publik maka _request_ pembuatan `Service` +Dukungan untuk SCTP _load balancer_ dari penyedia layanan _cloud_ bergantung pada +implementasi _load balancer_ yang disediakan oleh penyedia layanan _cloud_ tersebut. +Jika SCTP tidak didukung oleh _load balancer_ penyedia layanan publik maka _request_ pembuatan `Service` akan tetap diterima, meskipun proses pembuatan _load balancer_ itu sendiri gagal. {{< /note >}} #### _Load balancer_ internal -Di dalam _environment_, terkadang terdapat kebutuhan untuk melakukan _route_ trafik antar +Di dalam _environment_, terkadang terdapat kebutuhan untuk melakukan _route_ trafik antar _Service_ yang berada di dalam satu VPC. -Di dalam _environment_ _split-horizon DNS_ kamu akan membutuhkan dua _service_ yang mampu +Di dalam _environment_ _split-horizon DNS_ kamu akan membutuhkan dua _service_ yang mampu melakukan mekanisme _route_ trafik eskternal maupun internal ke _endpoints_ yang kamu miliki. -Hal ini dapat diraih dengan cara menambahkan anotasi berikut untuk _service_ yang disediakan oleh +Hal ini dapat diraih dengan cara menambahkan anotasi berikut untuk _service_ yang disediakan oleh penyedia layanan _cloud_. {{< tabs name="service_tabs" >}} @@ -547,8 +547,8 @@ metadata: #### Dukungan untuk SSL di AWS -Dukungan parsial untuk SSL bagi kluster yang dijalankan di AWS mulai diterapkan, -mulai versi 1.3 terdapat 3 anotasi yang dapat ditambahkan pada `Service` dengan tipe +Dukungan parsial untuk SSL bagi kluster yang dijalankan di AWS mulai diterapkan, +mulai versi 1.3 terdapat 3 anotasi yang dapat ditambahkan pada `Service` dengan tipe `LoadBalancer`: ```yaml @@ -558,8 +558,8 @@ metadata: service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012 ``` -Anotasi pertama memberikan spesifikasi ARN dari sertifikat yang akan digunakan. -Sertifikat yang digunakan bisa saja berasal dari _third party_ yang diunggah ke IAM atau +Anotasi pertama memberikan spesifikasi ARN dari sertifikat yang akan digunakan. +Sertifikat yang digunakan bisa saja berasal dari _third party_ yang diunggah ke IAM atau sertifikat yang dibuat secara langsung dengan menggunakan sertifikat manajer AWS. ```yaml @@ -570,18 +570,18 @@ metadata: ``` Anotasi kedua memberikan spesifikasi bagi protokol yang digunakan oleh `Pod` untuk saling berkomunikasi. -Untuk HTTPS dan SSL, ELB membutuhkan `Pod` untuk melakukan autentikasi terhadap dirinya sendiri melalui +Untuk HTTPS dan SSL, ELB membutuhkan `Pod` untuk melakukan autentikasi terhadap dirinya sendiri melalui koneksi yang dienkripsi. -Protokol HTTP dan HTTPS akan memilih mekanisme _proxy_ di tingkatan ke-7: -ELB akan melakukan terminasi koneksi dengan pengguna, melakukan proses _parsing_ _headers_, serta -memasukkan _value_ bagi _header_ `X-Forwarded-For` dengan alamat IP pengguna (_Pod_ hanya dapat melihat +Protokol HTTP dan HTTPS akan memilih mekanisme _proxy_ di tingkatan ke-7: +ELB akan melakukan terminasi koneksi dengan pengguna, melakukan proses _parsing_ _headers_, serta +memasukkan _value_ bagi _header_ `X-Forwarded-For` dengan alamat IP pengguna (_Pod_ hanya dapat melihat alamat IP dari ELB pada akhir koneksi yang diberikan) ketika melakukan _forwarding_ suatu _request_. - -Protokol TCP dan SSL akan memilih mekanisme _proxy_ pada tingkatan 4: ELB akan melakukan _forwarding_ trafik + +Protokol TCP dan SSL akan memilih mekanisme _proxy_ pada tingkatan 4: ELB akan melakukan _forwarding_ trafik tanpa melakukan modifikasi _headers_. -Pada _environment_ campuran dimana beberapa _port_ diamankan sementara _port_ lainnya dalam kondisi tidak dienkripsi, +Pada _environment_ campuran dimana beberapa _port_ diamankan sementara _port_ lainnya dalam kondisi tidak dienkripsi, anotasi-anotasi berikut dapat digunakan: ```yaml @@ -592,8 +592,8 @@ anotasi-anotasi berikut dapat digunakan: service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443,8443" ``` -Pada contoh di atas, jika `Service` memiliki 3 buah _port_, yaitu: `80`, `443`, dan -`8443`, maka `443` adan `8443` akan menggunakan sertifikat SSL, tetapi `80` hanya akan +Pada contoh di atas, jika `Service` memiliki 3 buah _port_, yaitu: `80`, `443`, dan +`8443`, maka `443` adan `8443` akan menggunakan sertifikat SSL, tetapi `80` hanya akan di-_proxy_ menggunakan protokol HTTP. Mulai versi 1.9, `Service` juga dapat menggunakan [_predefined_ _policy_](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html) @@ -603,7 +603,7 @@ untuk HTTPS atau _listener_ SSL. Untuk melihat _policy_ apa saja yang dapat digu aws elb describe-load-balancer-policies --query 'PolicyDescriptions[].PolicyName' ``` -_Policy_ ini kemudian dapat dispesifikasikan menggunakan anotasi +_Policy_ ini kemudian dapat dispesifikasikan menggunakan anotasi "_service.beta.kubernetes.io/aws-load-balancer-ssl-negotiation-policy_", contohnya: ```yaml @@ -625,19 +625,19 @@ untuk kluster yang dijalankan di AWS, kamu dapat menggunakan anotasi di bawah in service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*" ``` -Sejak versi 1.3.0, penggunaan anotasi berlaku untuk semua _port_ yang diproksi oleh ELB +Sejak versi 1.3.0, penggunaan anotasi berlaku untuk semua _port_ yang diproksi oleh ELB dan tidak dapat diatur sebaliknya. #### Akses _Log_ ELB pada AWS -Terdapat beberapa anotasi yang digunakan untuk melakukan manajemen +Terdapat beberapa anotasi yang digunakan untuk melakukan manajemen akses _log_ untuk ELB pada AWS. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` mengatur akses _log_ mana sajakah yang diaktifkan. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval` -mengatur interval (dalam menit) publikasi akses _log_. Kamu dapat memberikan spesifikasi interval +mengatur interval (dalam menit) publikasi akses _log_. Kamu dapat memberikan spesifikasi interval diantara _range_ 5-60 menit. Anotasi `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` @@ -662,11 +662,11 @@ memberikan spesifikasi hierarki logis yang kamu buat untuk _bucket_ Amazon S3 ya #### Mekanisme _Draining_ Koneksi pada AWS -Mekanisme _draining_ untuk ELB klasik dapat dilakukan dengan menggunakan anotasi -`service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` serta mengatur -_value_-nya menjadi `"true"`. Anotasi +Mekanisme _draining_ untuk ELB klasik dapat dilakukan dengan menggunakan anotasi +`service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled` serta mengatur +_value_-nya menjadi `"true"`. Anotasi `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout` juga -dapat digunakan untuk mengatur _maximum time_ (dalam detik), untuk menjaga koneksi yang ada +dapat digunakan untuk mengatur _maximum time_ (dalam detik), untuk menjaga koneksi yang ada agar selalu terbuka sebelum melakukan _deregistering_ _instance_. ```yaml @@ -679,7 +679,7 @@ agar selalu terbuka sebelum melakukan _deregistering_ _instance_. #### Anotasi ELB lainnya -Terdapat beberapa anotasi lain yang dapat digunakan untuk mengatur ELB klasik +Terdapat beberapa anotasi lain yang dapat digunakan untuk mengatur ELB klasik sebagaimana dijelaskan seperti di bawah ini: ```yaml @@ -734,23 +734,23 @@ dan atur _value_-nya dengan `nlb`. ``` Tidak seperti ELB klasik, NLB, melakukan _forwarding_ IP klien melalui _node_. -Jika _field_ `.spec.externalTrafficPolicy` diatur _value_-nya menjadi `Cluster`, maka +Jika _field_ `.spec.externalTrafficPolicy` diatur _value_-nya menjadi `Cluster`, maka alamat IP klien tidak akan diteruskan pada `Pod`. -Dengan mengatur _value_ dari _field_ `.spec.externalTrafficPolicy` ke `Local`, -alamat IP klien akan diteruskan ke `Pod`, tapi hal ini bisa menyebabkan distribusi trafik -yang tidak merata. _Node_ yang tidak memiliki `Pod` untuk `Service` dengan tipe `LoadBalancer` -akan menyebabkan kegagalan _health check_ _NLB Target_ pada tahapan _auto-assigned_ `.spec.healthCheckNodePort` +Dengan mengatur _value_ dari _field_ `.spec.externalTrafficPolicy` ke `Local`, +alamat IP klien akan diteruskan ke `Pod`, tapi hal ini bisa menyebabkan distribusi trafik +yang tidak merata. _Node_ yang tidak memiliki `Pod` untuk `Service` dengan tipe `LoadBalancer` +akan menyebabkan kegagalan _health check_ _NLB Target_ pada tahapan _auto-assigned_ `.spec.healthCheckNodePort` dan tidak akan menerima trafik apa pun. -Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan -_DaemonSet_ atau melakukan spesifikasi +Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan +_DaemonSet_ atau melakukan spesifikasi [pod anti-affinity](/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) agar `Pod` tidak di-_assign_ ke _node_ yang sama. NLB juga dapat digunakan dengan anotasi [internal load balancer](/docs/concepts/services-networking/service/#internal-load-balancer). -Agar trafik klien berhasil mencapai _instances_ dibelakang ELB, +Agar trafik klien berhasil mencapai _instances_ dibelakang ELB, _security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut: | _Rule_ | Protokol | `Port` | _IpRange(s)_ | Deskripsi _IpRange_ | @@ -759,12 +759,12 @@ _security group_ dari _node_ akan diberikan _rules_ IP sebagai berikut: | _Client Traffic_ | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\ | | _MTU Discovery_ | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\ | -Perhatikan bahwa jika `.spec.loadBalancerSourceRanges` tidak dispesifikasikan, -Kubernetes akan mengizinkan trafik dari `0.0.0.0/0` ke _Node Security Group_. -Jika _node_ memiliki akses publik, maka kamu harus memperhatikan tersebut karena trafik yang tidak berasal +Perhatikan bahwa jika `.spec.loadBalancerSourceRanges` tidak dispesifikasikan, +Kubernetes akan mengizinkan trafik dari `0.0.0.0/0` ke _Node Security Group_. +Jika _node_ memiliki akses publik, maka kamu harus memperhatikan tersebut karena trafik yang tidak berasal dari NLB juga dapat mengakses semua _instance_ di _security group_ tersebut. -Untuk membatasi klien IP mana yang dapat mengakses NLB, +Untuk membatasi klien IP mana yang dapat mengakses NLB, kamu harus memberikan spesifikasi _loadBalancerSourceRanges_. ```yaml @@ -780,8 +780,8 @@ untuk mengetahui lebih lanjut _intance_ apa saja yang didukung. ### Tipe ExternalName {#externalname} -Service dengan tipe `ExternalName` melakukan pemetaan antara `Service` dan DNS, dan bukan -ke _selector_ seperti `my-service` atau `cassandra`. Kamu memberikan spesifikasi `spec.externalName` +Service dengan tipe `ExternalName` melakukan pemetaan antara `Service` dan DNS, dan bukan +ke _selector_ seperti `my-service` atau `cassandra`. Kamu memberikan spesifikasi `spec.externalName` pada `Service` tersebut. Definisi `Service` ini, sebagai contoh, melaukan pemetaan @@ -798,20 +798,20 @@ spec: externalName: my.database.example.com ``` {{< note >}} -`ExternalName` menerima alamat IPv4 dalam bentuk string, +`ExternalName` menerima alamat IPv4 dalam bentuk string, tapi karena DNS tersusun atas angka dan bukan sebagai alamat IP. -`ExternalName` yang menyerupai alamat IPv4 tidak bisa di-_resolve_ oleh _CoreDNS_ -atau _ingress-nginx_ karena `ExternalName` memang ditujukan bagi penamaan _canonical_ DNS. +`ExternalName` yang menyerupai alamat IPv4 tidak bisa di-_resolve_ oleh _CoreDNS_ +atau _ingress-nginx_ karena `ExternalName` memang ditujukan bagi penamaan _canonical_ DNS. Untuk melakukan _hardcode_ alamat IP, kamu dapat menggunakan _headless_ `Service` sebagai alternatif. {{< /note >}} -Ketika melakukan pencarian _host_ `my-service.prod.svc.cluster.local`, -servis DNS kluster akan mengembalikan _record_ `CNAME` dengan _value_ `my.database.example.com`. -Mekanisme akses pada `my-service` bekerja dengan cara yang sama dengan -`Service` pada umumnya, perbedaan yang krusial untuk hal ini adalah mekanisme _redirection_ -terjadi pada tingkatan DNS dan bukan melalui _proxy forward_. Apabila kamu berniat memindahkan basis data -yang kamu pakai ke dalam kluster, kamu hanya perlu mengganti instans basis data kamu dan menjalankannya -di dalam `Pod`, menambahkan _selector_ atau _endpoint_ yang sesuai, serta mengupah _type_ dari +Ketika melakukan pencarian _host_ `my-service.prod.svc.cluster.local`, +servis DNS kluster akan mengembalikan _record_ `CNAME` dengan _value_ `my.database.example.com`. +Mekanisme akses pada `my-service` bekerja dengan cara yang sama dengan +`Service` pada umumnya, perbedaan yang krusial untuk hal ini adalah mekanisme _redirection_ +terjadi pada tingkatan DNS dan bukan melalui _proxy forward_. Apabila kamu berniat memindahkan basis data +yang kamu pakai ke dalam kluster, kamu hanya perlu mengganti instans basis data kamu dan menjalankannya +di dalam `Pod`, menambahkan _selector_ atau _endpoint_ yang sesuai, serta mengupah _type_ dari _Service_ yang kamu gunakan. {{< note >}} @@ -821,13 +821,13 @@ Bagian ini berasal dari tulisan [Tips Kubernetes - Bagian ### IP Eksternal -Jika terdapat sebuah alamat IP eksternal yang melakukan mekanisme _route_ ke satu atau lebih _node_ yang ada di kluster, `Service` Kubernetes dapat diekspos -dengan menggunakan `externalIP`. Trafik yang diarahkan ke kluster dengan IP eksternal -(sebagai destinasi IP), pada _port_ `Service` akan di-_route_ ke salah satu _endpoint_ `Service`. -_Value_ dari `externalIP` tidak diatur oleh Kubernetes dan merupakan tanggung jawab -dari administrator kluster. +Jika terdapat sebuah alamat IP eksternal yang melakukan mekanisme _route_ ke satu atau lebih _node_ yang ada di kluster, `Service` Kubernetes dapat diekspos +dengan menggunakan `externalIP`. Trafik yang diarahkan ke kluster dengan IP eksternal +(sebagai destinasi IP), pada _port_ `Service` akan di-_route_ ke salah satu _endpoint_ `Service`. +_Value_ dari `externalIP` tidak diatur oleh Kubernetes dan merupakan tanggung jawab +dari administrator kluster. -Pada _ServiceSpec_, kamu dapat memberikan spesifikasi `externalIP` dan `ServiceTypes`. +Pada _ServiceSpec_, kamu dapat memberikan spesifikasi `externalIP` dan `ServiceTypes`. Pada contoh di bawah ini. `"my-service"` dapat diakses oleh klien pada "`80.11.12.10:80`" (`externalIP:port`). ```yaml @@ -849,127 +849,127 @@ spec: ## Kekurangan -Penggunaan _proxy_ _userspace_ untuk VIP dapat digunakan untuk skala kecil hingga menengah, -meski begitu hal ini tidak _scalable_ untuk kluster yang sangat besar dan memiliki ribuan `Service`. -Perhatikan [Desain proposal orisinil untuk _portal_](http://issue.k8s.io/1107) untuk informasi +Penggunaan _proxy_ _userspace_ untuk VIP dapat digunakan untuk skala kecil hingga menengah, +meski begitu hal ini tidak _scalable_ untuk kluster yang sangat besar dan memiliki ribuan `Service`. +Perhatikan [Desain proposal orisinil untuk _portal_](http://issue.k8s.io/1107) untuk informasi lebih lanjut. -Penggunaan _proxy_ _userspace_ menghilangkan _source-IP_ dari _packet_ yang mengakses -sebuah `Service`. Hal ini membuat mekanisme _firewall_ menjadi sulit untuk diterapkan. -_Proxy_ `iptables` tidak menghilangkan _source IP_ yang berasal dari dalam kluster, -meski begitu, hal ini masih berimbas pada klien yang berasal dari `Service` dengan tipe +Penggunaan _proxy_ _userspace_ menghilangkan _source-IP_ dari _packet_ yang mengakses +sebuah `Service`. Hal ini membuat mekanisme _firewall_ menjadi sulit untuk diterapkan. +_Proxy_ `iptables` tidak menghilangkan _source IP_ yang berasal dari dalam kluster, +meski begitu, hal ini masih berimbas pada klien yang berasal dari `Service` dengan tipe _load-balancer_ atau _node-port_. -_Field_ tipe didesain sebagai fungsionalitas yang berantai - setiap tingkatan -menambahkan tambahan pada tingkatansebelumnya. Hal ini tidak selalu berlaku bagi -semua penyedia layanan _cloud_ (misalnya saja Google Compute Engine tidak perlu -melakukan alokasi `NodePort` untuk membuat `LoadBalancer` bekerja sebagaimana mestinya, -hal ini berbeda dengan AWS yang memerlukan hal ini, setidaknya untuk API yang mereka miliki +_Field_ tipe didesain sebagai fungsionalitas yang berantai - setiap tingkatan +menambahkan tambahan pada tingkatansebelumnya. Hal ini tidak selalu berlaku bagi +semua penyedia layanan _cloud_ (misalnya saja Google Compute Engine tidak perlu +melakukan alokasi `NodePort` untuk membuat `LoadBalancer` bekerja sebagaimana mestinya, +hal ini berbeda dengan AWS yang memerlukan hal ini, setidaknya untuk API yang mereka miliki saat ini). ## Pengerjaan lebih lanjut -Di masa mendatang, kami berencana untuk membuat _policy_ _proxy_ menjadi lebih +Di masa mendatang, kami berencana untuk membuat _policy_ _proxy_ menjadi lebih bervariasi dan bukan hanya _round robin_, misalnya saja _master-elected_ atau _sharded_. -Kami juga berharap bahwa beberapa `Service` bisa saja memiliki _load balancer_ yang sebenarnya, +Kami juga berharap bahwa beberapa `Service` bisa saja memiliki _load balancer_ yang sebenarnya, suatu kasus dimana VIP akan secara langsung mengantarkan paket. Kami ingin meningkatkan dukungan lebih lanjut untuk `Service` dengan tingkatan `Service` L7(HTTP). -Kami ingin memiliki mode _ingress_ yang lebih fleksibel untuk `Service` yang +Kami ingin memiliki mode _ingress_ yang lebih fleksibel untuk `Service` yang mencakup mode `ClusterIP`, `NodePort`, dan `LoadBalancer` dan banyak lagi. ## Detail mendalam mengenai IP virtual -Informasi sebelumnya sudah cukup bagi sebagian orang yang hanya ingin menggunakan -_Service_. Meskipun begitu, terdapat banyak hal yang sebenarnya terjadi dan akan +Informasi sebelumnya sudah cukup bagi sebagian orang yang hanya ingin menggunakan +_Service_. Meskipun begitu, terdapat banyak hal yang sebenarnya terjadi dan akan sangat bermanfaat untuk dipelajari lebih lanjut. ### Menghindari _collison_ -Salah satu filosofi Kubernetes adalah pengguna tidak mungkin menghadapi situasi -dimana apa yang mereka mengalami kegagalan tanpa adanya alasan yang jelas. Dalam kasus ini, -kita akan coba memahami lebih lanjut mengenai _network port_ - pengguna tidak seharusnya memilih -nomor _port_ jika hal itu memungkinkan terjadinya _collision_ dengan pengguna lainnya. Hal ini +Salah satu filosofi Kubernetes adalah pengguna tidak mungkin menghadapi situasi +dimana apa yang mereka mengalami kegagalan tanpa adanya alasan yang jelas. Dalam kasus ini, +kita akan coba memahami lebih lanjut mengenai _network port_ - pengguna tidak seharusnya memilih +nomor _port_ jika hal itu memungkinkan terjadinya _collision_ dengan pengguna lainnya. Hal ini merupakan mekanisme isolasi kegagalan. -Agar pengguna dapat menentukan nomor _port_ bagi `Service` mereka, kita harus -memastikan bahwa tidak ada dua `Service` yang mengalami _collision_. Kita melakukan +Agar pengguna dapat menentukan nomor _port_ bagi `Service` mereka, kita harus +memastikan bahwa tidak ada dua `Service` yang mengalami _collision_. Kita melakukan hal tersebut dengan cara melakukan alokasi alamat IP pada setiap `Service`. -Untuk memastikan setiap `Service` memiliki alamat IP yang unik, sebuah _allocator_ -internal akan secara atomik melakukan pemetaan alokasi global di dalam _etcd_ ketika -membuat sebuah `Service` baru. Pemetaan objek harus tersedia pada _registry_ `Service` -dimana `Service` akan diberikan sebuah IP, jika tidak, proses pembuatan `Service` akan gagal +Untuk memastikan setiap `Service` memiliki alamat IP yang unik, sebuah _allocator_ +internal akan secara atomik melakukan pemetaan alokasi global di dalam _etcd_ ketika +membuat sebuah `Service` baru. Pemetaan objek harus tersedia pada _registry_ `Service` +dimana `Service` akan diberikan sebuah IP, jika tidak, proses pembuatan `Service` akan gagal dan sebuah pesan akan memberikan informasi bahwa alamat IP tidak dapat dialokasikan. -Sebuah _backgroud_ _controller_ bertanggung jawab terhadap mekanisme pemetaan tersebut (migrasi -dari versi Kubernetes yang digunakan dalam _memory locking_) sekaligus melakukan pengecekan -terhadap _assignment_ yang tidak valid yang terjadi akibat intervensi administrator dan melakukan +Sebuah _backgroud_ _controller_ bertanggung jawab terhadap mekanisme pemetaan tersebut (migrasi +dari versi Kubernetes yang digunakan dalam _memory locking_) sekaligus melakukan pengecekan +terhadap _assignment_ yang tidak valid yang terjadi akibat intervensi administrator dan melakukan penghapusan daftar IP yang dialokasikan tapi tidak digunakan oleh `Service` mana pun. ### IP dan VIP -Tidak seperti alamat IP `Pod`, yang akan di _route_ ke destinasi yang "pasti", -IP `Service` tidak mengarahkan _request_ hanya pada satu _host_. Sebagai gantinya, -kita mneggunakan `iptables` (logika pemrosesan paket pada Linux) untuk melakukan definisi -alamat IP virtual yang secara transparan akan diarahkan sesuai kebutuhan. Ketika klien -dihubungkan pada VIP, trafik yang ada akan secara otomatis dialihkan pada _endpoint_ yang sesuai. +Tidak seperti alamat IP `Pod`, yang akan di _route_ ke destinasi yang "pasti", +IP `Service` tidak mengarahkan _request_ hanya pada satu _host_. Sebagai gantinya, +kita mneggunakan `iptables` (logika pemrosesan paket pada Linux) untuk melakukan definisi +alamat IP virtual yang secara transparan akan diarahkan sesuai kebutuhan. Ketika klien +dihubungkan pada VIP, trafik yang ada akan secara otomatis dialihkan pada _endpoint_ yang sesuai. Variabel _environment_ dan DNS untuk `Service` terdiri dalam bentuk VIP dan _port_. -Kami mendukung tiga jenis mode _proxy_ - _userspace_, `iptables`, dan _ipvs_ yang memiliki +Kami mendukung tiga jenis mode _proxy_ - _userspace_, `iptables`, dan _ipvs_ yang memiliki perbedaan cara kerja satu sama lainnya. #### _Userspace_ -Sebagai contoh, anggaplah kita memiliki aplikasi _image processing_ seperti yang sudah -disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan -sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_, -maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di kluster. -Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan membuka sebuah _port_ -_acak_, menyediakan `iptables` yang mengarahkan VIP pada _port_ yang baru saja dibuat, dan mulai +Sebagai contoh, anggaplah kita memiliki aplikasi _image processing_ seperti yang sudah +disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan +sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_, +maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di kluster. +Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan membuka sebuah _port_ +_acak_, menyediakan `iptables` yang mengarahkan VIP pada _port_ yang baru saja dibuat, dan mulai koneksi pada _port_ tersebut. -Ketika sebuah klien terhubung ke VIP dan terdapat _rules_ `iptables` -yang diterapkan, paket akan diarahkan ke _port_ dari _proxy_ `Service` itu sendiri. -_Proxy_ `Service` akan memilih sebuah _backend_, dan mulai melakukan mekanisme _proxy_ +Ketika sebuah klien terhubung ke VIP dan terdapat _rules_ `iptables` +yang diterapkan, paket akan diarahkan ke _port_ dari _proxy_ `Service` itu sendiri. +_Proxy_ `Service` akan memilih sebuah _backend_, dan mulai melakukan mekanisme _proxy_ trafik dari klien ke _backend_. -Dengan demikian, pemilik `Service` dapat memilih _port_ mana pun yang dia inginkan -tanpa adanya kemungkinan terjadinya _collision_. Klien dapat dengan mudah mengakses IP dan _port_, +Dengan demikian, pemilik `Service` dapat memilih _port_ mana pun yang dia inginkan +tanpa adanya kemungkinan terjadinya _collision_. Klien dapat dengan mudah mengakses IP dan _port_, tanpa harus mengetahui `Pod` mana yang sebenarnya diakses. #### _Iptables_ -Kembali, bayangkan apabila kita memiliki aplikasi _image processing_ seperti yang sudah -disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan -sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_, -maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di kluster. -Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan melakukan instalasi -serangkaian _rules_ `iptables` yang akan melakukan _redirect_ VIP ke _rules_ tiap `Service`. _Rules_ -untuk tiap `Service` ini terkait dengan _rules_ tiap `Endpoints` yang mengarahkan (destinasi NAT) +Kembali, bayangkan apabila kita memiliki aplikasi _image processing_ seperti yang sudah +disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan +sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_, +maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di kluster. +Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan melakukan instalasi +serangkaian _rules_ `iptables` yang akan melakukan _redirect_ VIP ke _rules_ tiap `Service`. _Rules_ +untuk tiap `Service` ini terkait dengan _rules_ tiap `Endpoints` yang mengarahkan (destinasi NAT) ke _backend_. -Ketika sebuah klien terhubung ke VIP dan terdapat _rules _iptables -yang diterapkan. Sebuah _backend_ akan dipilih (hal ini dapat dilakukan berdasarkan _session affinity_ -maupun secara _acak_) dan paket-paket yang ada akan diarahkan ke _backend_. Tidak seperti mekanisme -yang terjadi di _userspace_, paket-paket yang ada tidak pernah disalin ke _userspace_, `kube-proxy` +Ketika sebuah klien terhubung ke VIP dan terdapat _rules _iptables +yang diterapkan. Sebuah _backend_ akan dipilih (hal ini dapat dilakukan berdasarkan _session affinity_ +maupun secara _acak_) dan paket-paket yang ada akan diarahkan ke _backend_. Tidak seperti mekanisme +yang terjadi di _userspace_, paket-paket yang ada tidak pernah disalin ke _userspace_, `kube-proxy` tidak harus aktif untuk menjamin kerja VIP, serta IP klien juga tidak perlu diubah. -Tahapan yang dijalankan sama dengan tahapan yang dijalankan ketika trafik masuk melalui sebuah _node-port_ -atau _load-balancer_, meskipun pada dua kasus di atas klien IP tidak akan mengalami perubahan. +Tahapan yang dijalankan sama dengan tahapan yang dijalankan ketika trafik masuk melalui sebuah _node-port_ +atau _load-balancer_, meskipun pada dua kasus di atas klien IP tidak akan mengalami perubahan. #### _Ipvs_ -Operasi `iptables` berlangsung secara lambat pada kluster dengan skala besar (lebih dari 10.000 `Service`). -_IPVS_ didesain untuk mekanisme _load balance_ dan berbasis pada _hash tables_ yang berada di dalam _kernel_. -Dengan demikian kita dapat mendapatkan performa yang konsisten pada jumlah `Service` yang cukup besar dengan -menggunakan `kube-proxy` berbasis _ipvs_. Sementara itu, `kube-proxy` berbasis _ipvs_ memiliki algoritma +Operasi `iptables` berlangsung secara lambat pada kluster dengan skala besar (lebih dari 10.000 `Service`). +_IPVS_ didesain untuk mekanisme _load balance_ dan berbasis pada _hash tables_ yang berada di dalam _kernel_. +Dengan demikian kita dapat mendapatkan performa yang konsisten pada jumlah `Service` yang cukup besar dengan +menggunakan `kube-proxy` berbasis _ipvs_. Sementara itu, `kube-proxy` berbasis _ipvs_ memiliki algoritma _load balance_ yang lebih bervariasi (misalnya saja _least conns_, _locality_, _weighted_, _persistence_). ## Objek API -_Service_ merupakan _resource_ _top-level_ pada API Kubernetes. -Penjelasan lebih lanjut mengenai objek API dapat ditemukan pada: +_Service_ merupakan _resource_ _top-level_ pada API Kubernetes. +Penjelasan lebih lanjut mengenai objek API dapat ditemukan pada: [objek API `Service`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). ## Protokol yang didukung {#protokol-yang-tersedia} @@ -978,27 +978,27 @@ Penjelasan lebih lanjut mengenai objek API dapat ditemukan pada: {{< feature-state for_k8s_version="v1.0" state="stable" >}} -Kamu dapat menggunakan TCP untuk `Service` dengan _type_ apa pun, dan protokol ini merupakan +Kamu dapat menggunakan TCP untuk `Service` dengan _type_ apa pun, dan protokol ini merupakan protokol _default_ yang digunakan. ### UDP {{< feature-state for_k8s_version="v1.0" state="stable" >}} -Kamu dapat menggunakan UDP untuk sebagian besar `Service`. -Untuk `Service` dengan _type=LoadBalancer_, dukungan terhadap UDP -bergantung pada penyedia layanan _cloud_ yang kamu gunakan. +Kamu dapat menggunakan UDP untuk sebagian besar `Service`. +Untuk `Service` dengan _type=LoadBalancer_, dukungan terhadap UDP +bergantung pada penyedia layanan _cloud_ yang kamu gunakan. ### HTTP {{< feature-state for_k8s_version="v1.1" state="stable" >}} -Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, kamu dapat menggunakan -_Service_ dengan _type_ `LoadBalancer` untuk melakukan mekanisme _reverse_ _proxy_ +Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, kamu dapat menggunakan +_Service_ dengan _type_ `LoadBalancer` untuk melakukan mekanisme _reverse_ _proxy_ bagi HTTP/HTTPS, dan melakukan _forwarding_ ke `Endpoints` dari _Service. {{< note >}} -Kamu juga dapat menggunakan {{< glossary_tooltip term_id="ingress" >}} sebagai salah satu +Kamu juga dapat menggunakan {{< glossary_tooltip term_id="ingress" >}} sebagai salah satu alternatif penggunaan `Service` untuk HTTP/HTTPS. {{< /note >}} @@ -1007,11 +1007,11 @@ alternatif penggunaan `Service` untuk HTTP/HTTPS. {{< feature-state for_k8s_version="v1.1" state="stable" >}} Apabila penyedia layanan _cloud_ yang kamu gunakan mendukung, (misalnya saja, [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws)), -_Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_ -di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks +_Service_ dengan _type_ `LoadBalancer` untuk melakukan konfigurasi _load balancer_ +di luar Kubernetes sendiri, serta akan melakukan _forwarding_ koneksi yang memiliki prefiks [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). -_Load balancer_ akan melakukan serangkaian inisiasi _octet_ yang memberikan +_Load balancer_ akan melakukan serangkaian inisiasi _octet_ yang memberikan deskripsi koneksi yang datang, dengan bentuk yang menyerupai: ``` @@ -1023,28 +1023,28 @@ yang kemudian diikuti data dari klien. {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Kubernetes memberikan dukungan bagi SCTP sebagai _value_ dari _definition_ yang ada pada -_Service_, `Endpoints`, `NetworkPolicy` dan `Pod` sebagai fitur _alpha_. Untuk mengaktifkan fitur ini, -administrator kluster harus mengaktifkan _feature gate_ _SCTPSupport_ pada _apiserver_, contohnya -`“--feature-gates=SCTPSupport=true,...”`. Ketika _fature gate_ ini diaktifkan, pengguna dapat -memberikan _value_ SCTP pada _field_ _protocol_ `Service`, `Endpoints`, `NetworkPolicy` dan `Pod`. -Kubernetes kemudian akan melakukan pengaturan agar jaringan yang digunakan agar jaringan tersebut menggunakan SCTP, +Kubernetes memberikan dukungan bagi SCTP sebagai _value_ dari _definition_ yang ada pada +_Service_, `Endpoints`, `NetworkPolicy` dan `Pod` sebagai fitur _alpha_. Untuk mengaktifkan fitur ini, +administrator kluster harus mengaktifkan _feature gate_ _SCTPSupport_ pada _apiserver_, contohnya +`“--feature-gates=SCTPSupport=true,...”`. Ketika _fature gate_ ini diaktifkan, pengguna dapat +memberikan _value_ SCTP pada _field_ _protocol_ `Service`, `Endpoints`, `NetworkPolicy` dan `Pod`. +Kubernetes kemudian akan melakukan pengaturan agar jaringan yang digunakan agar jaringan tersebut menggunakan SCTP, seperti halnya Kubernetes mengatur jaringan agar menggunakan TCP. #### Perhatian {#kelemahan-penggunaan-sctp} ##### Dukungan untuk asoasiasi _multihomed_ SCTP {#kelemahan-sctp-multihomed} -Dukungan untuk asosiasi _multihomed_ SCTP membutuhkan _plugin_ CNI yang dapat memberikan +Dukungan untuk asosiasi _multihomed_ SCTP membutuhkan _plugin_ CNI yang dapat memberikan pengalokasian _multiple interface_ serta alamat IP pada sebuah `Pod`. NAT untuk asosiasi _multihomed_ SCTP membutuhkan logika khusus pada modul kernel terkait. ##### `Service` dengan _type=LoadBalancer_ {#kelemahan-sctp-loadbalancer-service-type} -Sebuah `Service` dengan _type_ `LoadBalancer` dan protokol SCTP dapat dibuat -hanya jika implementasi _load balancer_ penyedia layanan _cloud_ menyediakan dukungan -bagi protokol SCTP. Apabila hal ini tidak terpenuhi, maka _request_ pembuatan _Servixe_ ini akan ditolak. +Sebuah `Service` dengan _type_ `LoadBalancer` dan protokol SCTP dapat dibuat +hanya jika implementasi _load balancer_ penyedia layanan _cloud_ menyediakan dukungan +bagi protokol SCTP. Apabila hal ini tidak terpenuhi, maka _request_ pembuatan _Servixe_ ini akan ditolak. _Load balancer_ yang disediakan oleh penyedia layanan _cloud_ yang ada saat ini (_Azure_, _AWS_, _CloudStack_, _GCE_, _OpenStack_) tidak mendukung SCTP. ##### Windows {#kelemahan-sctp-windows-os} @@ -1053,7 +1053,7 @@ SCTP tidak didukung pada _node_ berbasis Windows. ##### _Kube-proxy_ _userspace_ {#kelemahan-sctp-kube-proxy-userspace} -_Kube-proxy_ tidak mendukung manajemen asosiasi SCTP ketika hal ini dilakukan pada mode +_Kube-proxy_ tidak mendukung manajemen asosiasi SCTP ketika hal ini dilakukan pada mode _userspace_ {{% /capture %}} diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md index 8f636373afb33..d07b69c2f4ce6 100644 --- a/content/id/docs/concepts/storage/dynamic-provisioning.md +++ b/content/id/docs/concepts/storage/dynamic-provisioning.md @@ -122,7 +122,7 @@ tidak bisa terbuat. Pada kluster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona pada sebuah Region. Penyimpanan dengan *backend* Zona-Tunggal seharusnya disediakan pada -Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur +Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur [Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). {{% /capture %}} diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md index a650aa6496d5a..e334a4182cb6b 100644 --- a/content/id/docs/concepts/storage/persistent-volumes.md +++ b/content/id/docs/concepts/storage/persistent-volumes.md @@ -85,7 +85,7 @@ Name: hostpath Namespace: default StorageClass: example-hostpath Status: Terminating -Volume: +Volume: Labels: Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath @@ -103,19 +103,19 @@ Annotations: Finalizers: [kubernetes.io/pv-protection] StorageClass: standard Status: Available -Claim: +Claim: Reclaim Policy: Delete Access Modes: RWO Capacity: 1Gi -Message: +Message: Source: Type: HostPath (bare host directory volume) Path: /tmp/data - HostPathType: + HostPathType: Events: ``` -### Melakukan Reklaim +### Melakukan Reklaim Ketika seorang pengguna telah selesai dengan volumenya, ia dapat menghapus objek PVC dari API yang memungkinkan untuk reklamasi dari sumber daya tersebut. Kebijakan reklaim dari sebuah `PersistentVolume` (PV) menyatakan apa yang dilakukan kluster setelah volume dilepaskan dari klaimnya. Saat ini, volume dapat dipertahankan (_Retained_), didaur ulang (_Recycled_), atau dihapus (_Deleted_). @@ -168,7 +168,7 @@ Namun, alamat yang dispesifikasikan pada templat _recycler pod_ kustom pada bagi {{< feature-state for_k8s_version="v1.11" state="beta" >}} -Dukungan untuk memperluas PersistentVolumeClaim (PVC) sekarang sudah diaktifkan sejak awal. Kamu dapat memperluas +Dukungan untuk memperluas PersistentVolumeClaim (PVC) sekarang sudah diaktifkan sejak awal. Kamu dapat memperluas tipe-tipe volume berikut: * gcePersistentDisk @@ -199,7 +199,7 @@ allowVolumeExpansion: true ``` Untuk meminta volume yang lebih besar pada sebuah PVC, ubah objek PVC dan spesifikasikan ukuran yang lebih -besar. Hal ini akan memicu perluasan dari volume yang berada di balik `PersistentVolume` (PV). Sebuah +besar. Hal ini akan memicu perluasan dari volume yang berada di balik `PersistentVolume` (PV). Sebuah `PersistentVolume` (PV) baru tidak akan dibuat untuk memenuhi klaim tersebut. Sebaliknya, volume yang sudah ada akan diatur ulang ukurannya. #### Perluasan Volume CSI @@ -209,7 +209,7 @@ besar. Hal ini akan memicu perluasan dari volume yang berada di balik `Persisten Perluasan volume CSI mengharuskan kamu untuk mengaktifkan gerbang fitur `ExpandCSIVolumes` dan juga membutuhkan _driver_ CSI yang spesifik untuk mendukung perluasan volume. Silakan merujuk pada dokumentasi _driver_ spesifik CSI untuk informasi lebih lanjut. -#### Mengubah ukuran sebuah volume yang memiliki _file system_ +#### Mengubah ukuran sebuah volume yang memiliki _file system_ Kamu hanya dapat mengubah ukuran volume yang memiliki _file system_ jika _file system_ tersebut adalah XFS, Ext3, atau Ext4. @@ -223,8 +223,8 @@ kubectl describe pvc Jika `PersistentVolumeClaim` (PVC) memiliki status `FileSystemResizePending`, maka berarti aman untuk membuat ulang _pod_ menggunakan PersistentVolumeClaim (PVC) tersebut. -FlexVolumes mengizinkan pengubahan ukuran jika _driver_ diatur dengan kapabilitas `RequiresFSResize` menjadi "_true_". -FlexVolume dapat diubah ukurannya pada saat _pod_ mengalami _restart_. +FlexVolumes mengizinkan pengubahan ukuran jika _driver_ diatur dengan kapabilitas `RequiresFSResize` menjadi "_true_". +FlexVolume dapat diubah ukurannya pada saat _pod_ mengalami _restart_. {{< feature-state for_k8s_version="v1.11" state="alpha" >}} @@ -236,8 +236,8 @@ PVC manapun yang sedang digunakan secara otomatis menjadi tersedia untuk _pod_ y Fitur ini tidak memiliki efek pada PVC yang tidak sedang digunakan oleh _Pod_ atau _deployment_. Kamu harus membuat sebuah _Pod_ yang menggunakan PVC sebelum perluasan dapat selesai dilakukan. -Memperluas PVC yang sedang digunakan sudah ditambahkan pada rilis 1.13. Untuk mengaktifkan fitur ini gunakan `ExpandInUsePersistentVolumes` dan gerbang fitur `ExpandPersistentVolumes`. Gerbang fitur `ExpandPersistentVolumes` sudah diaktifkan sejak awal. Jika `ExpandInUsePersistentVolumes` sudah terpasang, FlexVolume dapat diubah ukurannya secara langsung tanpa perlu melakukan _restart_ pada _pod_. - +Memperluas PVC yang sedang digunakan sudah ditambahkan pada rilis 1.13. Untuk mengaktifkan fitur ini gunakan `ExpandInUsePersistentVolumes` dan gerbang fitur `ExpandPersistentVolumes`. Gerbang fitur `ExpandPersistentVolumes` sudah diaktifkan sejak awal. Jika `ExpandInUsePersistentVolumes` sudah terpasang, FlexVolume dapat diubah ukurannya secara langsung tanpa perlu melakukan _restart_ pada _pod_. + {{< note >}} Pengubahan ukuran FlexVolume hanya mungkin dilakukan ketika _driver_ yang menjalankannya mendukung pengubahan ukuran. {{< /note >}} @@ -365,7 +365,7 @@ Dahulu, anotasi `volume.beta.kubernetes.io/storage-class` digunakan sebagai gant atribut `storageClassName`. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. -### Kebijakan Reklaim +### Kebijakan Reklaim Kebijakan-kebijakan reklaim saat ini antara lain: @@ -375,7 +375,7 @@ Kebijakan-kebijakan reklaim saat ini antara lain: Saat ini, hanya NFS dan HostPath yang mendukung daur ulang. AWS EBS, GCE PD, Azure Disk, dan Cinder Volume mendukung penghapusan. -### Opsi Pemasangan +### Opsi Pemasangan Seorang administrator Kubernetes dapat menspesifikasi opsi pemasangan tambahan untuk ketika sebuah _Persistent Volume_ dipasangkan pada sebuah _node_. @@ -405,7 +405,7 @@ Dahulu, anotasi `volume.beta.kubernetes.io/mount-options` digunakan sebagai gant atribut `mountOptions`. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. -### Afinitas Node +### Afinitas Node {{< note >}} Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini secara otomatis terisi untuk tipe blok volume [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) dan [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Kamu harus mengaturnya secara eksplisit untuk volume [lokal](/docs/concepts/storage/volumes/#local). @@ -413,7 +413,7 @@ Untuk kebanyakan tipe volume, kamu tidak perlu memasang kolom ini. Kolom ini sec Sebuah PV dapat menspesifikasi [afinitas node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) untuk mendefinisikan batasan yang membatasi _node_ mana saja yang dapat mengakses volume tersebut. _Pod_ yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke _node_ yang dipilih oleh afinitas _node_. -### Fase +### Fase Sebuah volume akan berada dalam salah satu fase di bawah ini: @@ -448,11 +448,11 @@ spec: - {key: environment, operator: In, values: [dev]} ``` -### Mode Akses +### Mode Akses Klaim menggunakan penulisan yang sama dengan volume ketika meminta _storage_ dengan mode akses tertentu. -### Mode Volume +### Mode Volume Klaim menggunakan penulisan yang sama dengan volume untuk mengindikasikan konsumsi dari volume sebagai _filesystem_ ataupun perangkat _block_. @@ -578,7 +578,7 @@ spec: lun: 0 readOnly: false ``` -### _Persistent Volume Claim_ meminta Volume _Raw Block_ +### _Persistent Volume Claim_ meminta Volume _Raw Block_ ```yaml apiVersion: v1 kind: PersistentVolumeClaim diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index ecde1b581e2cf..1119f5fe0c0bd 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -6,9 +6,9 @@ weight: 30 {{% capture overview %}} -Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes. -Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap -[volumes](/docs/concepts/storage/volumes/) dan +Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes. +Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap +[volumes](/docs/concepts/storage/volumes/) dan [peristent volume](/docs/concepts/storage/persistent-volumes) terlebih dahulu. {{% /capture %}} @@ -17,29 +17,29 @@ Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap ## Pengenalan -Sebuah StorageClass menyediakan cara bagi administrator untuk -mendeskripsikan "kelas" dari penyimpanan yang mereka sediakan. -Kelas yang berbeda bisa saja memiliki perbedaan dari segi kualitas -servis yang disediakan, pemulihan (_backup_) kebijakan, atau kebijakan lain yang ditentukan -oleh administrator kluster. Kubernetes sendiri tidak dipengaruhi oleh -kelas apakah yang digunakan pada mekanisme penyimpanan yang digunakan. -Mekanisme ini seringkali disebut sebagai _"profiles"_ pada sistem penyimpanan +Sebuah StorageClass menyediakan cara bagi administrator untuk +mendeskripsikan "kelas" dari penyimpanan yang mereka sediakan. +Kelas yang berbeda bisa saja memiliki perbedaan dari segi kualitas +servis yang disediakan, pemulihan (_backup_) kebijakan, atau kebijakan lain yang ditentukan +oleh administrator kluster. Kubernetes sendiri tidak dipengaruhi oleh +kelas apakah yang digunakan pada mekanisme penyimpanan yang digunakan. +Mekanisme ini seringkali disebut sebagai _"profiles"_ pada sistem penyimpanan yang lain. ## Sumber daya StorageClass -Setiap StorageClass (kelas penyimpanan) memiliki _field-field_ mendasar seperti -`provisioner`, `parameters`, dan `reclaimPolicy`, yang digunakan ketika +Setiap StorageClass (kelas penyimpanan) memiliki _field-field_ mendasar seperti +`provisioner`, `parameters`, dan `reclaimPolicy`, yang digunakan ketika `PersistentVolume` yang dimiliki oleh kelas tersebut perlu disediakan (di-_provision_). -Nama yang digunakan oleh suatu StorageClass sifatnya penting, karena -ini merupakan cara yang digunakan oleh pengguna untuk meminta -penyimpanan dengan kelas tertentu. Administrator dapat menentukan -nama dan parameter lain dari suatu kelas ketika membuat suatu objek `StorageClass`, +Nama yang digunakan oleh suatu StorageClass sifatnya penting, karena +ini merupakan cara yang digunakan oleh pengguna untuk meminta +penyimpanan dengan kelas tertentu. Administrator dapat menentukan +nama dan parameter lain dari suatu kelas ketika membuat suatu objek `StorageClass`, dan objek yang sudah dibuat tidak dapat diubah lagi definisinya. -Administrator dapat memberikan spesifikasi StorageClass _default_ bagi -PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_: +Administrator dapat memberikan spesifikasi StorageClass _default_ bagi +PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme _bind_: kamu dapat membaca [bagian `PersistentVolumeClaim`](/docs/concepts/storage/persistent-volumes/#class-1) untuk penjelasan lebih lanjut. @@ -59,8 +59,8 @@ volumeBindingMode: Immediate ### _Provisioner_ -Setiap kelas penyimpanan (_storage class_) memiliki sebuah _provisioner_ yang -menentukan _plugin_ manakah yang digunakan ketika sebuah PV disediakan (di-_provision_). +Setiap kelas penyimpanan (_storage class_) memiliki sebuah _provisioner_ yang +menentukan _plugin_ manakah yang digunakan ketika sebuah PV disediakan (di-_provision_). _Field_ ini haruslah didefinisikan. | Plugin Volume | Provisioner Internal| Contoh Konfigurasi | @@ -85,104 +85,104 @@ _Field_ ini haruslah didefinisikan. | StorageOS | ✓ | [StorageOS](#storageos) | | Local | - | [Local](#local) | -Kamu tidak dibatasi untuk hanya menggunakan _provisioner_ internal yang disediakan -pada list yang tersedia (yang memiliki nama dengan prefix "kubernetes.io" dan -didistribusikan bersamaan dengan Kubernetes). Kamu juga dapat menjalankan dan -mendefinisikan _provisioner_ eksternal yang merupakan program independen selama +Kamu tidak dibatasi untuk hanya menggunakan _provisioner_ internal yang disediakan +pada list yang tersedia (yang memiliki nama dengan prefix "kubernetes.io" dan +didistribusikan bersamaan dengan Kubernetes). Kamu juga dapat menjalankan dan +mendefinisikan _provisioner_ eksternal yang merupakan program independen selama program tersebut menerapkan [spesifikasi](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md) -yang didefinisikan oleh Kubernetes. Penulis dari _provisioner_ eksternal Kubernetes -memiliki kuasa penuh akan tempat dimana kode sumber yang mereka tulis, bagaimana -mekanisme penyediaan (_provisioning_) dilakukan, serta bagaimana hal tersebut dapat dijalankan, -serta _plugin_ volume apakah yang digunakan (termasuk Flex), dkk. +yang didefinisikan oleh Kubernetes. Penulis dari _provisioner_ eksternal Kubernetes +memiliki kuasa penuh akan tempat dimana kode sumber yang mereka tulis, bagaimana +mekanisme penyediaan (_provisioning_) dilakukan, serta bagaimana hal tersebut dapat dijalankan, +serta _plugin_ volume apakah yang digunakan (termasuk Flex), dkk. Repositori [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage) -menyimpan _library_ yang dibutukan untuk menulis _provisioner_ eksternal -yang mengimplementasi spesifikasi serta beberapa _provisioner_ eksternal yang +menyimpan _library_ yang dibutukan untuk menulis _provisioner_ eksternal +yang mengimplementasi spesifikasi serta beberapa _provisioner_ eksternal yang dipelihara oleh komunitas. -Sebagai contoh, NFS tidak menyediakan _provisioner_ internal, tetapi -sebuah _provisioner_ eksternal dapat digunakan. Beberapa _provisioner_ eksternal +Sebagai contoh, NFS tidak menyediakan _provisioner_ internal, tetapi +sebuah _provisioner_ eksternal dapat digunakan. Beberapa _provisioner_ eksternal dapat ditemukan di bawah repositori [kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage). Di sana juga terdapat beberapa kasus dimana vendor penyimpanan _3rd party_ menyediakan _provisioner_ eksternal yang mereka sediakan sendiri. ### Perolehan Kembali untuk Kebijakan (_Reclaim Policy_) -_Persistent Volumes_ yang secara dinamis dibuat oleh sebuah kelas penyimpanan -akan memiliki _reclaim policy_ yang didefinisikan di dalam _field_ `reclaimPolicy` -dari kelas tersebut, yang nilainya dapat diisi dengan `Delete` atau `Retain`. -Jika tidak terdapat `reclaimPolicy` yang dispesifikasikan ketika sebuah objek +_Persistent Volumes_ yang secara dinamis dibuat oleh sebuah kelas penyimpanan +akan memiliki _reclaim policy_ yang didefinisikan di dalam _field_ `reclaimPolicy` +dari kelas tersebut, yang nilainya dapat diisi dengan `Delete` atau `Retain`. +Jika tidak terdapat `reclaimPolicy` yang dispesifikasikan ketika sebuah objek StorageClass dibuat, maka nilai default bagi kelas tersebut adalah `Delete`. -PersistentVolume yang dibuat secara manual dan diatur dengan menggunakan -kelas penyimpanan akan menggunakan _reclaim policy_ apapun yang diberikan +PersistentVolume yang dibuat secara manual dan diatur dengan menggunakan +kelas penyimpanan akan menggunakan _reclaim policy_ apapun yang diberikan pada saat objek tersebut dibuat. ### Pilihan _Mount_ -PersistentVolume yang secara dinamis dibuat oleh sebuah kelas penyimpanan -akan memiliki pilihan _mount_ yang dapat dispesifikasikan pada _field_ +PersistentVolume yang secara dinamis dibuat oleh sebuah kelas penyimpanan +akan memiliki pilihan _mount_ yang dapat dispesifikasikan pada _field_ `mountOptions` dari kelas tersebut. -Jika sebuah _plugin_ volume tidak mendukung pilihan _mount_ -yang dispesifikasikan, mekanisme penyediaan (_provision_) akan digagalkan. Pilihan _mount_ -yang akan divalidasi pada kelas penyimpanan maupun PV, maka _mount_ tersebut +Jika sebuah _plugin_ volume tidak mendukung pilihan _mount_ +yang dispesifikasikan, mekanisme penyediaan (_provision_) akan digagalkan. Pilihan _mount_ +yang akan divalidasi pada kelas penyimpanan maupun PV, maka _mount_ tersebut akan gagal apabila salah satu dari keduanya bersifat invalid. ### Mode Volume _Binding_ -_Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan -_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning) -harus dilakukan. - -Secara _default_, ketika mode `Immediate` yang mengindikasikan -terjadinya volume _binding_ dan _provisioning_ dinamis terjadi ketika -PersistentVolumeClaim dibuat. Untuk _backend_ penyimpanan yang dibatasi oleh -topologi tertentu dan tidak dapat diakses secara global dari semua Node -yang ada di kluster, PersistentVolume akan di-_bound_ atau di-_provision_ -tanpa perlu memenuhi persyaratan _scheduling_ dari Pod. Hal ini dapat menyebabkan -adanya Pod yang tidak mendapatkan mekanisme _scheduling_. - -Seorang administrator kluster dapat mengatasi hal tersebut dengan cara memberikan -spesifikasi mode `WaitForFirstConsumer` yang akan memperlambat mekanisme _provisioning_ -dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan -PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_ -sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan -oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada, +_Field_ `volumeBindingMode` mengontrol kapan mekanisme [_binding_ volume dan +_provisioning_ dinamis](/docs/concepts/storage/persistent-volumes/#provisioning) +harus dilakukan. + +Secara _default_, ketika mode `Immediate` yang mengindikasikan +terjadinya volume _binding_ dan _provisioning_ dinamis terjadi ketika +PersistentVolumeClaim dibuat. Untuk _backend_ penyimpanan yang dibatasi oleh +topologi tertentu dan tidak dapat diakses secara global dari semua Node +yang ada di kluster, PersistentVolume akan di-_bound_ atau di-_provision_ +tanpa perlu memenuhi persyaratan _scheduling_ dari Pod. Hal ini dapat menyebabkan +adanya Pod yang tidak mendapatkan mekanisme _scheduling_. + +Seorang administrator kluster dapat mengatasi hal tersebut dengan cara memberikan +spesifikasi mode `WaitForFirstConsumer` yang akan memperlambat mekanisme _provisioning_ +dan _binding_ dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan +PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisioning_ +sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan +oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada, [persyaratan sumber daya](/docs/concepts/configuration/manage-compute-resources-container), [_node selector_](/docs/concepts/configuration/assign-pod-node/#nodeselector), [afinitas dan anti-afinitas Pod](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), serta [_taint_ dan _toleration_](/docs/concepts/configuration/taint-and-toleration). -Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_ +Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_ dinamis: * [AWSElasticBlockStore](#aws-ebs) * [GCEPersistentDisk](#gce-pd) * [AzureDisk](#azure-disk) -Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _binding_ +Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _binding_ PersistentVolume yang terlebih dahulu dibuat: * Semua hal di atas * [Lokal](#lokal) {{< feature-state state="beta" for_k8s_version="1.14" >}} -[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung -dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat, -meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi -untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung +[Volume-volume CSI](/docs/concepts/storage/volumes/#csi) juga didukung +dengan adanya _provisioning_ dinamis serta PV yang telah terlebih dahulu dibuat, +meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi +untuk driver spesifik CSI untuk melihat topologi _key_ yang didukung beserta contoh penggunaannya. _Feature gate_ `CSINodeInfo` haruslah diaktifkan. ### Topologi yang Diizinkan -Ketika sebuah operator kluster memberikan spesifikasi `WaitForFirstConsumer` pada -mode `binding` volume, mekanisme pembatasan (restriksi) `provisioning` tidak lagi dibutuhkan -pada sebagian besar kasus. Meskipun begitu, apabila hal tersebut masih dibutuhkan, +Ketika sebuah operator kluster memberikan spesifikasi `WaitForFirstConsumer` pada +mode `binding` volume, mekanisme pembatasan (restriksi) `provisioning` tidak lagi dibutuhkan +pada sebagian besar kasus. Meskipun begitu, apabila hal tersebut masih dibutuhkan, `field` `allowedTopologies` dapat dispesifikasikan. -Contoh ini memberikan demonstrasi bagaimana cara membatasi topologi -dari volume yang di-_provision_ pada suatu zona spesifik serta harus digunakan +Contoh ini memberikan demonstrasi bagaimana cara membatasi topologi +dari volume yang di-_provision_ pada suatu zona spesifik serta harus digunakan sebagai pengganti parameter `zone` dam `zones` untuk `plugin` yang akan digunakan. ```yaml @@ -204,11 +204,11 @@ allowedTopologies: ## Parameter-Parameter -Kelas-kelas penyimpanan memiliki parameter yang mendeskripsikan -volume yang dimiliki oleh kelas penyimpanan tersebut. Parameter yang berbeda -bisa saja diterima bergantung pada `provisioner`. Sebagai contohnya, nilai `io1`, -untuk parameter `type`, dan parameter `iopsPerGB` spesifik terhadap EBS. -Ketika sebuah parameter diabaikan, beberapa nilai _default_ akan digunakan sebagai +Kelas-kelas penyimpanan memiliki parameter yang mendeskripsikan +volume yang dimiliki oleh kelas penyimpanan tersebut. Parameter yang berbeda +bisa saja diterima bergantung pada `provisioner`. Sebagai contohnya, nilai `io1`, +untuk parameter `type`, dan parameter `iopsPerGB` spesifik terhadap EBS. +Ketika sebuah parameter diabaikan, beberapa nilai _default_ akan digunakan sebagai gantinya. ### AWS EBS @@ -225,29 +225,29 @@ parameters: fsType: ext4 ``` -* `type`: `io1`, `gp2`, `sc1`, `st1`. Lihat +* `type`: `io1`, `gp2`, `sc1`, `st1`. Lihat [dokumentasi AWS](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) untuk detail lebih lanjut. Nilai _default_: `gp2`. -* `zone` (_deprecated_): zona AWS. Jika tidak terdapat nilai `zone` atau `zones` - yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan - penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes +* `zone` (_deprecated_): zona AWS. Jika tidak terdapat nilai `zone` atau `zones` + yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan + penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes yang memiliki _node_. -* `zones` (_deprecated_): Nilai terpisahkan koma yang merupakan barisan zona pada AWS. - Jika tidak terdapat nilai `zone` atau `zones` yang dispesifikasikan, - volume secara generik dijadwalkan dengan menggunakan penjadwalan - `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes +* `zones` (_deprecated_): Nilai terpisahkan koma yang merupakan barisan zona pada AWS. + Jika tidak terdapat nilai `zone` atau `zones` yang dispesifikasikan, + volume secara generik dijadwalkan dengan menggunakan penjadwalan + `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes yang memiliki _node_. -* `iopsPerGB`: hanya untuk volume `io1`. Operasi per detik per GiB. Volume _plugin_ - AWS mengalikan nilai ini dengan ukuran volume yang dibutuhkan untuk menghitung IOPS - dari volume (nilai maksimum yang didukung adalah 20,000 IOPS baca [dokumentasi +* `iopsPerGB`: hanya untuk volume `io1`. Operasi per detik per GiB. Volume _plugin_ + AWS mengalikan nilai ini dengan ukuran volume yang dibutuhkan untuk menghitung IOPS + dari volume (nilai maksimum yang didukung adalah 20,000 IOPS baca [dokumentasi AWS](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html). Nilai masukan yang diharapkan merupakan string, misalnya `"10"`, bukan `10`. * `fsType`: fsType yang didukung oleh Kubernetes. Nilai _default_-nya adalah: `"ext4"`. * `encrypted`: menyatakan dimana volume EBS harus dienkripsi atau tidak. Nilai yang valid adalah `"true"` atau `"false"` (dalam string bukan boolean i.e. `"true"`, bukan `true`). -* `kmsKeyId`: opsional. Merupakan nama dari Amazon Resource Name dari _key_ yang digunakan - untuk melakukan enkripsi volume. Jika nilai ini tidak disediakan tetapi nilai dari - _field_ `encrypted` adalah _true_, sebuah _key_ akan dibuat oleh AWS. Perhatikan dokumentasi AWS +* `kmsKeyId`: opsional. Merupakan nama dari Amazon Resource Name dari _key_ yang digunakan + untuk melakukan enkripsi volume. Jika nilai ini tidak disediakan tetapi nilai dari + _field_ `encrypted` adalah _true_, sebuah _key_ akan dibuat oleh AWS. Perhatikan dokumentasi AWS untuk mengetahui nilai yang valid bagi ARN. {{< note >}} @@ -269,28 +269,28 @@ parameters: ``` * `type`: `pd-standard` atau `pd-ssd`. Nilai _default_: `pd-standard` -* `zone` (_deprecated_): zona GCE. Jika tidak terdapat nilai `zone` atau `zones` - yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan - penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes +* `zone` (_deprecated_): zona GCE. Jika tidak terdapat nilai `zone` atau `zones` + yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan + penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes yang memiliki _node_. -* `zones` (_deprecated_): Nilai terpisahkan koma yang merupakan barisan zona. - Jika tidak terdapat nilai `zone` atau `zones` yang dispesifikasikan, - volume secara generik dijadwalkan dengan menggunakan penjadwalan - `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes +* `zones` (_deprecated_): Nilai terpisahkan koma yang merupakan barisan zona. + Jika tidak terdapat nilai `zone` atau `zones` yang dispesifikasikan, + volume secara generik dijadwalkan dengan menggunakan penjadwalan + `round-robin-ed` pada semua zona aktif yang ada pada kluster Kubernetes yang memiliki _node_. * `replication-type`: `none` atau `regional-pd`. Nilai _default_: `none`. -Jika `replication-type` diubah menjadi `none`, sebuah PD reguler (zonal) akan +Jika `replication-type` diubah menjadi `none`, sebuah PD reguler (zonal) akan di-_provisioning_. Jika `replication-type` diubah menjadi `regional-pd`, sebuah [_Persistent_ Disk Regional (PD Regional)](https://cloud.google.com/compute/docs/disks/#repds) -akan di-_provisioning_. Pada kasus ini, pengguna harus menggunakan `zones` -dan bukan `zone` untuk menspesifikasikan zona replikasi yang diinginkan. Jika terdapat -tepat dua zona yang dispesifikasikan, PD Regional akan di-_provisioning_ pada -zona replikasi yang diinginkan. Jika terdapat lebih dari 2 zona yang dispesifikasikan, -Kubernetes akan memilih secara acak zona dari zona-zona yang dispesifikasikan. Jika -parameter `zones` tidak diinisialisasi, Kubernetes akan memilih secara acak dari +akan di-_provisioning_. Pada kasus ini, pengguna harus menggunakan `zones` +dan bukan `zone` untuk menspesifikasikan zona replikasi yang diinginkan. Jika terdapat +tepat dua zona yang dispesifikasikan, PD Regional akan di-_provisioning_ pada +zona replikasi yang diinginkan. Jika terdapat lebih dari 2 zona yang dispesifikasikan, +Kubernetes akan memilih secara acak zona dari zona-zona yang dispesifikasikan. Jika +parameter `zones` tidak diinisialisasi, Kubernetes akan memilih secara acak dari zona yang diatur oleh kluster Kubernetes. {{< note >}} @@ -318,28 +318,28 @@ parameters: volumetype: "replicate:3" ``` -* `resturl`: Servis REST Gluster/URL servis Heketi yang digunakan untuk - melakukan _provisioning_ volume gluster sesuai dengan kebutuhan. Format secara umum - haruslah dalam bentuk `IPaddress:Port` dan hal ini merupakan parameter wajib untuk - _provisioner_ dinamis GlusterFS. Jika servis Heketi diekspos sebagai servis yang dapat - melakukan _routing_ pada pengaturan openshift/kubernetes, ini dapat memiliki +* `resturl`: Servis REST Gluster/URL servis Heketi yang digunakan untuk + melakukan _provisioning_ volume gluster sesuai dengan kebutuhan. Format secara umum + haruslah dalam bentuk `IPaddress:Port` dan hal ini merupakan parameter wajib untuk + _provisioner_ dinamis GlusterFS. Jika servis Heketi diekspos sebagai servis yang dapat + melakukan _routing_ pada pengaturan openshift/kubernetes, ini dapat memiliki format yang sesuai dengan `http://heketi-storage-project.cloudapps.mystorage.com` dimana fqdn yang ada merupakan URL servis Heketi yang dapat di-_resolve_. -* `restauthenabled` : Servis REST Gluster menyediakan nilai boolean yang dapat digunakan - untuk mengajukan `authentication` untuk server REST yang ada. Jika nilai yang disediakan - adalah `"true"`, dengan kondisi dimana `restuser` dan `restuserkey` atau `secretNamespace` + `secretName` - harus diisi. Opsi ini sudah_deprecated_, mekanisme otentikasi akan diizinkan apabila +* `restauthenabled` : Servis REST Gluster menyediakan nilai boolean yang dapat digunakan + untuk mengajukan `authentication` untuk server REST yang ada. Jika nilai yang disediakan + adalah `"true"`, dengan kondisi dimana `restuser` dan `restuserkey` atau `secretNamespace` + `secretName` + harus diisi. Opsi ini sudah_deprecated_, mekanisme otentikasi akan diizinkan apabila salah satu dari _field_ `restuser`, `restuserkey`, `secretName` atau `secretNamespace` diterapkan. -* `restuser` : Pengguna servis REST Gluster/Heketi yang memiliki akses +* `restuser` : Pengguna servis REST Gluster/Heketi yang memiliki akses untuk membuat volume di dalam Trusted Pool Gluster. -* `restuserkey` : Password pengguna servis REST Gluster/Heketi - yang digunakan untuk mekanisme otentikasi server REST. Parameter ini _deprecated_ +* `restuserkey` : Password pengguna servis REST Gluster/Heketi + yang digunakan untuk mekanisme otentikasi server REST. Parameter ini _deprecated_ dan digantikan dengan parameter `secretNamespace` + `secretName`. -* `secretNamespace`, `secretName` : Identifikasi instans Secret yang mengandung - password pengguna yang digunakan untuk berkomunikasi dengan servis REST Gluster. - Parameter ini dianggap opsional, password kosong dapat digunakan ketika - nilai dari `secretNamespace` dan `secretName` tidak dispesifikasikan. - Secret yang disediakan haruslah memiliki tipe `"kubernetes.io/glusterfs"`, +* `secretNamespace`, `secretName` : Identifikasi instans Secret yang mengandung + password pengguna yang digunakan untuk berkomunikasi dengan servis REST Gluster. + Parameter ini dianggap opsional, password kosong dapat digunakan ketika + nilai dari `secretNamespace` dan `secretName` tidak dispesifikasikan. + Secret yang disediakan haruslah memiliki tipe `"kubernetes.io/glusterfs"`, yang dapat dibuat dengan menggunakan mekanisme dibawah ini: ``` @@ -348,38 +348,38 @@ parameters: --namespace=default ``` - Contoh Secret dapat ditemukan pada berkas berikut + Contoh Secret dapat ditemukan pada berkas berikut [glusterfs-provisioning-secret.yaml](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/glusterfs/glusterfs-secret.yaml). -* `clusterid`: `630372ccdc720a92c681fb928f27b53f` merupakan ID dari kluster - yang akan digunakan oleh Heketi ketikan melakukan _provisioning_ volume. ID ini juga - dapat berupa serangkaian list, misalnya: `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. +* `clusterid`: `630372ccdc720a92c681fb928f27b53f` merupakan ID dari kluster + yang akan digunakan oleh Heketi ketikan melakukan _provisioning_ volume. ID ini juga + dapat berupa serangkaian list, misalnya: `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. Parameter ini merupakan parameter opsional. * `gidMin`, `gidMax` : Nilai minimum dan maksimum dari GID untuk kelas penyimpanan (_storage class_). - Sebuah nilai unik dari GID di dalam _range_ ( gidMin-gidMax ) ini akan digunakan untuk melakukan - _provisioning_ volume secara dinamis. Nilai ini bersifat opsional. Jika tidak dispesifikasikan, - volume akan secara default di-_provisioning_ dalam _range_ 2000-2147483647 yang merupakan nilai default + Sebuah nilai unik dari GID di dalam _range_ ( gidMin-gidMax ) ini akan digunakan untuk melakukan + _provisioning_ volume secara dinamis. Nilai ini bersifat opsional. Jika tidak dispesifikasikan, + volume akan secara default di-_provisioning_ dalam _range_ 2000-2147483647 yang merupakan nilai default dari gidMin dan gidMax. -* `volumetype` : Tipe volume beserta paremeter-nya dapat diatur dengan menggunakan nilai opsional - berikut. Jika tipe dari volume tidak dispesifikasikan, maka _provisioner_ akan memutuskan tipe - volume apakah yang akan digunakan. - +* `volumetype` : Tipe volume beserta paremeter-nya dapat diatur dengan menggunakan nilai opsional + berikut. Jika tipe dari volume tidak dispesifikasikan, maka _provisioner_ akan memutuskan tipe + volume apakah yang akan digunakan. + Sebagai contoh: - + * Volume replika: `volumetype: replicate:3` dimana '3' merupakan jumlah replika. - + * Persebaran (_Disperse_)/EC volume: `volumetype: disperse:4:2` dimana'4' merupakan data dan '2' merupakan jumlah redundansi. - + * Distribusi volume: `volumetype: none` - Untuk tipe volume apa saja yang tersedia dan berbagai opsi administrasi yang ada, kamu dapat membaca + Untuk tipe volume apa saja yang tersedia dan berbagai opsi administrasi yang ada, kamu dapat membaca [Petunjuk Administrasi](https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/part-Overview.html). Untuk informasi lebih lanjut, kamu dapat membaca [Bagaimana Cara Mengatur Heketi](https://github.com/heketi/heketi/wiki/Setting-up-the-topology). - Ketika PersistentVolume di-_provisioning_ secara dinamis, plugin Gluster secara otomatis - akan membuat _endpoint_ serta sebuah servis _headless_ dengan nama `gluster-dynamic-`. + Ketika PersistentVolume di-_provisioning_ secara dinamis, plugin Gluster secara otomatis + akan membuat _endpoint_ serta sebuah servis _headless_ dengan nama `gluster-dynamic-`. _Endpoint_ dinamis dan servis secara otomatis akan dihapus ketika PVC dihapus. ### OpenStack Cinder @@ -394,8 +394,8 @@ parameters: availability: nova ``` -* `availability`: Zona _Availability_. Jika tidak dispesifikasikan, secara umum volume akan - diatur dengan menggunakan algoritma _round-robin_ pada semua zona aktif +* `availability`: Zona _Availability_. Jika tidak dispesifikasikan, secara umum volume akan + diatur dengan menggunakan algoritma _round-robin_ pada semua zona aktif dimana kluster Kubernetes memiliki sebuah node. {{< note >}} @@ -433,9 +433,9 @@ _Provisioner_ internal OpenStack ini sudah _deprecated_. Kamu dapat menggunakan ``` `datastore`: Pengguna juga dapat menspesifikasikan _datastore_ pada StorageClass. - Volume akan dibuat pada datastore yang dispesifikasikan pada kelas penyimpanan, - dalam hal ini adalah `VSANDatastore`. _Field_ ini bersifat opsional. Jika _datastore_ - tidak dispesifikasikan, maka volume akan dibuat dengan menggunakan _datastore_ yang dispesifikasikan + Volume akan dibuat pada datastore yang dispesifikasikan pada kelas penyimpanan, + dalam hal ini adalah `VSANDatastore`. _Field_ ini bersifat opsional. Jika _datastore_ + tidak dispesifikasikan, maka volume akan dibuat dengan menggunakan _datastore_ yang dispesifikasikan pada berkas konfigurasi vSphere yang digunakan untuk menginisialisasi penyedia layanan cloud vSphere. 3. Manajemen Kebijakan Penyimpanan di dalam Kubernetes @@ -443,29 +443,29 @@ _Provisioner_ internal OpenStack ini sudah _deprecated_. Kamu dapat menggunakan * Menggunakan kebijakan (_policy_) yang ada pada vCenter Salah satu dari fitur paling penting yang ada pada vSphere untuk manajemen penyimpanan - adalah manajemen bebasis _policy_. Storage Policy Based Management (SPBM) adalah _framework_ - yang menyediakan sebuah _control plane_ terpadu pada _data service_ yang meluas dan - solusi penyimpanannya yang tersedia. SPBM memungkinkan administrator vSphere menghadapi - permasalahan yang mungkin muncul seperti _capacity planning_, membedakan level servis, dan + adalah manajemen bebasis _policy_. Storage Policy Based Management (SPBM) adalah _framework_ + yang menyediakan sebuah _control plane_ terpadu pada _data service_ yang meluas dan + solusi penyimpanannya yang tersedia. SPBM memungkinkan administrator vSphere menghadapi + permasalahan yang mungkin muncul seperti _capacity planning_, membedakan level servis, dan melakukan manajemen _headroom capacity_. - _Policy_ SPBM dapat dispesifikasikan pada StorageClass menggunakan parameter + _Policy_ SPBM dapat dispesifikasikan pada StorageClass menggunakan parameter `storagePolicyName`. * Dukungan _policy_ SAN virtual di dalam Kubernetes - Administrator _Vsphere Infrastructure_ (VI) akan memiliki kemampuan - untuk menspesifikasikan Virtual SAN Storage Capabilities khusus - selama masa _provisioning_ volume secara dinamis. Persyaratan kapabilitas - penyimpanan diubah menjadi sebuah _policy_ Virtual SAN yang nantinya akan - dimasukkan ke dalam lapisan Virtual SAN ketika sebuah _persitent volume_ (penyimpanan - virtual) dibuat. Penyimpanan virtual kemudian akan didistribusikan pada semua + Administrator _Vsphere Infrastructure_ (VI) akan memiliki kemampuan + untuk menspesifikasikan Virtual SAN Storage Capabilities khusus + selama masa _provisioning_ volume secara dinamis. Persyaratan kapabilitas + penyimpanan diubah menjadi sebuah _policy_ Virtual SAN yang nantinya akan + dimasukkan ke dalam lapisan Virtual SAN ketika sebuah _persitent volume_ (penyimpanan + virtual) dibuat. Penyimpanan virtual kemudian akan didistribusikan pada semua _datastore_ Virtual SAN untuk memenuhi kebutuhan ini. - + Kamu dapat melihat [_Policy_ Penyimpanan Berdasarkan Manajemen untuk _Provisioning_ Dinamis Volume](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/policy-based-mgmt.html) untuk detil lebih lanjut mengenai penggunaan _policy_ penyimpanan untuk manajemen _persistent volume_. -Terdapat beberapa +Terdapat beberapa [contoh vSphere](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) yang dapat kamu gunakan untuk mencoba manajemen _persistent volume_ di dalam Kubernetes untuk vSpehere. @@ -498,10 +498,10 @@ parameters: Secret yang dibutuhkan haruslah memiliki tipe "kubernetes.io/rbd". * `adminSecretNamespace`: Namespace untuk `adminSecretName`. Nilai _default_-nya adalah "default". * `pool`: Pool Ceph RBD. Nilai _default_-nya adalah "rbd". -* `userId`: Klien ID Ceph yang digunakan untuk melakukan pemetaan image RBD. Nilai _default_-nya sama dengan +* `userId`: Klien ID Ceph yang digunakan untuk melakukan pemetaan image RBD. Nilai _default_-nya sama dengan `adminId`. -* `userSecretName`: Nama Secret Ceph untuk `userId` yang digunakan untuk memetakan image RBD. - Secret ini harus berada pada namespace yang sama dengan PVC. Parameter ini dibutuhkan. +* `userSecretName`: Nama Secret Ceph untuk `userId` yang digunakan untuk memetakan image RBD. + Secret ini harus berada pada namespace yang sama dengan PVC. Parameter ini dibutuhkan. Secret yang disediakan haruslah memiliki tipe "kubernetes.io/rbd", dibuat dengan cara: ```shell @@ -512,7 +512,7 @@ parameters: * `userSecretNamespace`: Namespace untuk `userSecretName`. * `fsType`: fsType yang didukung oleh kubernetes. Nilai _default_-nya adalah: `"ext4"`. * `imageFormat`: Format image Ceph RBD, nilai yang mungkin adalah "1" atau "2". Nilai _default_-nya adalah "2". -* `imageFeatures`: Parameter ini bersifat opsional dan hanya dapat digunakan jika kamu mengganti nilai +* `imageFeatures`: Parameter ini bersifat opsional dan hanya dapat digunakan jika kamu mengganti nilai dari `imageFormat` ke "2". Saat ini fitur yang didukung hanyalah `layering`. Nilai _default_-nya adalah "", dan tidak ada fitur yang diaktifkan. @@ -535,16 +535,16 @@ parameters: quobyteTenant: "DEFAULT" ``` -* `quobyteAPIServer`: API Server dari Quobyte dalam format +* `quobyteAPIServer`: API Server dari Quobyte dalam format `"http(s)://api-server:7860"` -* `registry`: Registri Quobyte yang digunakan untuk melakukan _mount_ volume. Kamu dapat menspesifikasikan - registri yang kamu inginkan dengan format pasangan ``:`` atau jika kamu ingin mendefinisikan - beberapa registri sekaligus kamu dapat menempatkan koma diantara setiap pasangan ``:`` yang ada, +* `registry`: Registri Quobyte yang digunakan untuk melakukan _mount_ volume. Kamu dapat menspesifikasikan + registri yang kamu inginkan dengan format pasangan ``:`` atau jika kamu ingin mendefinisikan + beberapa registri sekaligus kamu dapat menempatkan koma diantara setiap pasangan ``:`` yang ada, misalnya ``:,:,:``. Host dapat berupa alamat IP atau DNS. * `adminSecretNamespace`: Namespace `adminSecretName`. Nilai default-nya adalah "default". -* `adminSecretName`: Secret yang mengandung informasi mengenai pengguna Quobyte dan - password yang digunakan untuk melakukan otentikasi API server. Secret yang digunakan +* `adminSecretName`: Secret yang mengandung informasi mengenai pengguna Quobyte dan + password yang digunakan untuk melakukan otentikasi API server. Secret yang digunakan haruslah memiliki tipe "kubernetes.io/quobyte", yang dibuat dengan mekanisme berikut: ```shell @@ -553,11 +553,11 @@ parameters: --namespace=kube-system ``` -* `user`: Melakukan pemetaan terhadap semua akses yang dimiliki pengguna. +* `user`: Melakukan pemetaan terhadap semua akses yang dimiliki pengguna. Nilai _default_-nya adalah "root". * `group`: Melakukan pemetaan terhadap semua group. Nilai _default_-nya adalah "nfsnobody". * `quobyteConfig`: Menggunakan konfigurasi spesifik untuk membuat volume. - Kamu dapat membuat sebuah file konfigurasi atau melakukan modifikasi terhadap konfigurasi yang sudah ada + Kamu dapat membuat sebuah file konfigurasi atau melakukan modifikasi terhadap konfigurasi yang sudah ada dengan menggunakan tatap muka Web atau CLI quobyte. Nilai _default_-nya adalah "BASE". * `quobyteTenant`: Menggunakan ID tenant yang dispesifikasikan untuk membuat/menghapus volume. _Tenant_ Quobyte haruslah sudah berada di dalam Quobyte. Nilai _default_-nya adalah "DEFAULT". @@ -580,9 +580,9 @@ parameters: * `skuName`: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai _default_-nya adalah kosong. * `location`: Lokasi akun penyimpanan Azure. Nilai _default_-nya adalah kosong. -* `storageAccount`: Nama akun penyimpanan Azure. Jika sebuan akun penyimpanan disediakan, - akun tersebut haruslah berada pada grup sumber daya yang ada dengan kluster, - dan `location` akan diabaikan. Jika sebuah akun penyimpanan tidak disediakan, sebuah akun penyimpanan +* `storageAccount`: Nama akun penyimpanan Azure. Jika sebuan akun penyimpanan disediakan, + akun tersebut haruslah berada pada grup sumber daya yang ada dengan kluster, + dan `location` akan diabaikan. Jika sebuah akun penyimpanan tidak disediakan, sebuah akun penyimpanan baru akan dibuat pada grup sumber daya yang ada dengan kluster. #### Kelas Penyimpanan Disk Azure yang Baru (mulai versi v1.7.2) @@ -600,15 +600,15 @@ parameters: * `storageaccounttype`: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai _default_-nya adalah kosong. * `kind`: Nilai yang mungkin adalah `shared` (default), `dedicated`, dan `managed`. - Ketika `kind` yang digunakan adalah `shared`, semua disk yang tidak di-_manage_ akan + Ketika `kind` yang digunakan adalah `shared`, semua disk yang tidak di-_manage_ akan dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan kluster. - Ketika `kind` yang digunakan adalah `dedicated`, sebuah akun penyimpanan - baru akan dibuat pada grup sumber daya yang ada dengan kluster. Ketika `kind` yang digunakan adalah + Ketika `kind` yang digunakan adalah `dedicated`, sebuah akun penyimpanan + baru akan dibuat pada grup sumber daya yang ada dengan kluster. Ketika `kind` yang digunakan adalah `managed`, semua disk yang dikelola akan dibuat pada grup sumber daya yang ada dengan kluster. - VM premium dapat di-_attach_ baik pada Standard_LRS dan Premium_LRS disks, sementara Standard VM hanya dapat di-_attach_ pada disk Standard_LRS. -- VM yang dikelola hanya dapat meng-_attach_ disk yang dikelola dan VM yang tidak dikelola hanya dapat +- VM yang dikelola hanya dapat meng-_attach_ disk yang dikelola dan VM yang tidak dikelola hanya dapat meng-_attach_ disk yang tidak dikelola. ### Berkas Azure @@ -627,13 +627,13 @@ parameters: * `skuName`: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai _default_-nya adalah kosong. * `location`: Lokasi akun penyimpanan Azure. Nilai _default_-nya adalah kosong. -* `storageAccount`: Nama akun penyimpanan Azure. Nilai _default_-nya adalah kosong. Jika sebuah penyimpanan - tidak memiliki sebuah akun yang disediakan, semua akun penyimpanan yang diasosiasikan dengan - grup sumber daya yang ada dan kemudian melakukan pencarian terhadap akun yang sesuai dengan - `skuName` dan `location`. Jika sebuah akun penyimpanan disediakan, akun tersebut haruslah berada +* `storageAccount`: Nama akun penyimpanan Azure. Nilai _default_-nya adalah kosong. Jika sebuah penyimpanan + tidak memiliki sebuah akun yang disediakan, semua akun penyimpanan yang diasosiasikan dengan + grup sumber daya yang ada dan kemudian melakukan pencarian terhadap akun yang sesuai dengan + `skuName` dan `location`. Jika sebuah akun penyimpanan disediakan, akun tersebut haruslah berada di dalam grup sumber daya yang sama dengan kluster, serta `skuName` dan `location` akan diabaikan. -Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika kluster +Selama _provision_, sebuah secret dibuat untuk menyimpan _credentials_. Jika kluster menggunakan konsep [RBAC](/docs/reference/access-authn-authz/rbac/) dan [_Roles_ Controller](/docs/reference/access-authn-authz/rbac/#controller-roles), menambahkan kapabilitas `create` untuk sumber daya `secret` bagi clusterrole @@ -656,22 +656,22 @@ parameters: * `fs`: filesystem yang akan digunakan: `none/xfs/ext4` (nilai default-nya: `ext4`). * `block_size`: ukuran block dalam Kbytes (nilai _default_-nya: `32`). -* `repl`: jumlah replika _synchronous_ yang dapat disediakan dalam bentuk - faktor replikasi `1..3` (nilai _default_-nya: `1`) Nilai yang diharapkan dalam bentuk String +* `repl`: jumlah replika _synchronous_ yang dapat disediakan dalam bentuk + faktor replikasi `1..3` (nilai _default_-nya: `1`) Nilai yang diharapkan dalam bentuk String `"1"` dan bukan `1`. -* `io_priority`: menentukan apakah volume yang dibuat akan dari penyimpanan dengan kualitas +* `io_priority`: menentukan apakah volume yang dibuat akan dari penyimpanan dengan kualitas tinggi atau rendah dengan urutan prioritas `high/medium/low` (nilai _default_-nya: `low`). * `snap_interval`: interval waktu dalam menit yang digunakan untuk melakukan _trigger_ _snapshots_. - _Snapshots_ dibuat secara inkremen berdasarkan perbedaan yang ada dengan _snapshot_ yang dibuat sebelumnya, - nilai perbedaan 0 akan menonaktifkan pembuatan _snapshot_ (nilai default-nya: `0`). Sebuah string merupakan nilai + _Snapshots_ dibuat secara inkremen berdasarkan perbedaan yang ada dengan _snapshot_ yang dibuat sebelumnya, + nilai perbedaan 0 akan menonaktifkan pembuatan _snapshot_ (nilai default-nya: `0`). Sebuah string merupakan nilai yang diharapkan `"70"` dan bukan `70`. -* `aggregation_level`: menspesifikasikan jumlah _chunks_ dimana volume akan didistribusikan, - 0 mengindikasikan volume yang _non-aggregate_ (nilai default-nya: `0`). Sebuah string merupakan nilai +* `aggregation_level`: menspesifikasikan jumlah _chunks_ dimana volume akan didistribusikan, + 0 mengindikasikan volume yang _non-aggregate_ (nilai default-nya: `0`). Sebuah string merupakan nilai yang diharapkan `"0"` dan bukan `0`. -* `ephemeral`: menentukan apakah volume harus dihapus setelah di-_unmount_ - atau harus tetap ada. Penggunaan `emptyDir` dapat diubah menjadi true dan penggunaan +* `ephemeral`: menentukan apakah volume harus dihapus setelah di-_unmount_ + atau harus tetap ada. Penggunaan `emptyDir` dapat diubah menjadi true dan penggunaan `persistent volumes` untuk basisdata seperti Cassandra harus diubah menjadi false`, - true/false` (nilai default-nya: `false`). Sebuah string merupakan nilai + true/false` (nilai default-nya: `false`). Sebuah string merupakan nilai yang diharapkan `"true"` dan bukan `true`. ### ScaleIO @@ -705,7 +705,7 @@ parameters: * `fsType`: filesystem yang digunakan untuk volume (nilai default-nya: ext4) Plugin volume ScaleIO Kubernetes membutuhkan objek Secret yang suda dikonfigurasi sebelumnya. -Secret ini harus dibuat dengan tipe `kubernetes.io/scaleio` dan menggunakan namespace yang sama +Secret ini harus dibuat dengan tipe `kubernetes.io/scaleio` dan menggunakan namespace yang sama dengan PVC yang dirujuk, seperti ditunjukkan pada contoh yang ada: ```shell @@ -730,24 +730,24 @@ parameters: adminSecretName: storageos-secret ``` -* `pool`: Nama kapasitas distribusi StorageOS yang digunakan untuk melakukan +* `pool`: Nama kapasitas distribusi StorageOS yang digunakan untuk melakukan _provisioning_ volume. _Pool_ default akan digunakan apabila nilainya tidak dispesifikasikan. * `description`: Deskripsi untuk melakukan _assignment_ volume yang baru dibuat secara dinamis. - Semua deskripsi volume akan bernilai sama untuk kelas penyimpanan yang sama, meskipun begitu - kelas penyimpanan yang berbeda dapat digunakan untuk membuat deskripsi yang berbeda untuk penggunaan + Semua deskripsi volume akan bernilai sama untuk kelas penyimpanan yang sama, meskipun begitu + kelas penyimpanan yang berbeda dapat digunakan untuk membuat deskripsi yang berbeda untuk penggunaan yang berbeda. Nilai default-nya adalah `Kubernetes volume`. -* `fsType`: Tipe filesystem default yang digunakan. Perhatikan bahwa aturan - yang didefinisikan oleh pengguna di dalam StirageOS dapat meng-_override_ nilai ini. +* `fsType`: Tipe filesystem default yang digunakan. Perhatikan bahwa aturan + yang didefinisikan oleh pengguna di dalam StirageOS dapat meng-_override_ nilai ini. Nilai default-nya adalah `ext4`. -* `adminSecretNamespace`: Namespace dimana konfigurasi secret API berada. Hal ini bersifat wajib +* `adminSecretNamespace`: Namespace dimana konfigurasi secret API berada. Hal ini bersifat wajib apabila adminSecretName diaktifkan. * `adminSecretName`: Nama secret yang digunakan untuk memperoleh _credentials_ StorageOS API. Jika tidak dispesifikasikan, nilaidefault akan digunakan. -Plugin volume dapat menggunakan objek Secret untuk menspesifikasikan -endpoint dan kredensial yang digunakan untuk mengakses API StorageOS. +Plugin volume dapat menggunakan objek Secret untuk menspesifikasikan +endpoint dan kredensial yang digunakan untuk mengakses API StorageOS. Hal ini hanya akan dibutuhkan apabila terdapat perubahan pada nilai _default_. -Secret ini harus dibuat dengan tipe `kubernetes.io/storageos`, +Secret ini harus dibuat dengan tipe `kubernetes.io/storageos`, seperti ditunjukkan pada contoh yang ada: ```shell @@ -759,9 +759,9 @@ kubectl create secret generic storageos-secret \ --namespace=default ``` -Secret yang digunakan untuk melakukan _provisioning_ volume secara dinamis -dapat dibuat di namespace apapun dan dirujuk dengan menggunakan parameter `adminSecretNamespace`. -Secret yang digunakan oleh volume yang sedang di-_provisioning_ harus dibuat pada namespace yang sama +Secret yang digunakan untuk melakukan _provisioning_ volume secara dinamis +dapat dibuat di namespace apapun dan dirujuk dengan menggunakan parameter `adminSecretNamespace`. +Secret yang digunakan oleh volume yang sedang di-_provisioning_ harus dibuat pada namespace yang sama dengan PVC yang merujuk secret tersebut. ### Lokal @@ -777,12 +777,12 @@ provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer ``` -Volume lokal tidak mendukung adanya _provisioning_ secara dinamis, -meskipun begitu sebuah StorageClass akan tetap dibuat untuk mencegah terjadinya _bind_ volume -sampai _scheduling_ pod dilakukan. Hal ini dispesifikasikan oleh mode _binding_ volume +Volume lokal tidak mendukung adanya _provisioning_ secara dinamis, +meskipun begitu sebuah StorageClass akan tetap dibuat untuk mencegah terjadinya _bind_ volume +sampai _scheduling_ pod dilakukan. Hal ini dispesifikasikan oleh mode _binding_ volume `WaitForFirstConsumer`. -Memperlambat _binding_ volume mengizinkan _scheduler_ untuk memastikan +Memperlambat _binding_ volume mengizinkan _scheduler_ untuk memastikan batasan _scheduling_ semua pod ketika memilih PersistentVolume untuk sebuah PersistentVolumeClaim. {{% /capture %}} diff --git a/content/id/docs/concepts/storage/storage-limits.md b/content/id/docs/concepts/storage/storage-limits.md index 4a9ae8311c428..f2c4c9de93975 100644 --- a/content/id/docs/concepts/storage/storage-limits.md +++ b/content/id/docs/concepts/storage/storage-limits.md @@ -9,7 +9,7 @@ Laman ini menjelaskan soal jumlah volume maksimal yang dapat dihubungkan ke sebuah Node untuk berbagai penyedia layanan cloud. Penyedia layanan cloud seperti Google, Amazon, dan Microsoft pada umumnya memiliki -keterbatasan dalam jumlah volume yang bisa terhubung ke sebuah Node. Keterbatasn ini +keterbatasan dalam jumlah volume yang bisa terhubung ke sebuah Node. Keterbatasn ini sangatlah penting untuk diketahui Kubernetes dalam menentukan keputusan. Jika tidak, Pod-pod yang telah dijadwalkan pada sebuah Node akan macet dan menunggu terus-menerus untuk terhubung pada volume. diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md index bc9caa876718f..639083e26e7c5 100644 --- a/content/id/docs/concepts/storage/volumes.md +++ b/content/id/docs/concepts/storage/volumes.md @@ -411,7 +411,7 @@ spec: ### glusterfs {#glusterfs} -Sebuah Volume `glusterfs` memungkinkan sebuah volume [Glusterfs](http://www.gluster.org) (sebuah proyek _open-source_ _filesystem_ berbasis jaringan) untuk ditambatkan ke dalam Pod kamu. +Sebuah Volume `glusterfs` memungkinkan sebuah volume [Glusterfs](http://www.gluster.org) (sebuah proyek _open-source_ _filesystem_ berbasis jaringan) untuk ditambatkan ke dalam Pod kamu. Tidak seperti `emptyDir` yang ikut dihapus saat Pod dihapus, isi dari sebuah `glusterfs` dipertahankan dan _volume_-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah `glusterfs` dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod. GlusterFS dapat ditambatkan kepada beberapa penulis secara bersamaan. {{< caution >}} @@ -478,7 +478,7 @@ spec: ### iscsi {#iscsi} -Sebuah Volume `iscsi` memungkinkan sebuah volume iSCSI (_SCSI over IP_) yang sudah ada untuk ditambatkan ke dalam Pod kamu. +Sebuah Volume `iscsi` memungkinkan sebuah volume iSCSI (_SCSI over IP_) yang sudah ada untuk ditambatkan ke dalam Pod kamu. Tidak seperti `emptyDir` yang ikut dihapus saat Pod dihapus, isi dari sebuah `iscsi` dipertahankan dan _volume_-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah `iscsi` dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod. {{< caution >}} @@ -572,7 +572,7 @@ Saat ini, tipe-tipe sumber Volume berikut dapat diproyeksikan: Semua sumber harus berada pada `namespace` yang sama dengan Pod yang menggunakannya. Untuk lebih lanjut, lihat [dokumen desain Volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). Proyeksi `serviceAccountToken` adalah fitur yang diperkenalkan pada Kubernetes 1.11 dan dipromosikan menjadi Beta pada 1.12. -Untuk mengaktifkan fitur inipada 1.11, kamu harus menyetel [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `TokenRequestProjection` secara eksplisit menjadi `True`. +Untuk mengaktifkan fitur inipada 1.11, kamu harus menyetel [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `TokenRequestProjection` secara eksplisit menjadi `True`. #### Contoh Pod dengan sebuah Secret, Downward API, dan ConfigMap. @@ -725,7 +725,7 @@ Kamu harus sudah memiliki instalasi Quobyte dengan volume yang sudah disediakan {{< /caution >}} Quobyte mendukung {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. -CSI adalah _plugin_ yang direkomendasikan untuk menggunakan Volume Quobyte di dalam Kubernetes. Ada [petunjuk dan contoh](https://github.com/quobyte/quobyte-csi#quobyte-csi) untuk menggunakan Quobyte menggunakan CSI pada proyek GitHub Quobyte.j +CSI adalah _plugin_ yang direkomendasikan untuk menggunakan Volume Quobyte di dalam Kubernetes. Ada [petunjuk dan contoh](https://github.com/quobyte/quobyte-csi#quobyte-csi) untuk menggunakan Quobyte menggunakan CSI pada proyek GitHub Quobyte.j ### rbd {#rbd} @@ -1108,7 +1108,7 @@ Nilai-nilainya adalah sebagai berikut: Mode ini setara dengan _mount propagation_ `private`, seperti yang dideskripsikan pada [dokumentasi kernel Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) * `HostToContainer` - Tambatan volume ini akan menerima semua tambatan selanjutnya yang ditambatkan pada volume ini atau pada apapun sub-direktori yang dimilikinya. - + Dalam kata lain, jika _host_ yang bersangkutan menambatkan apapun di dalam tambatan volume, Container akan melihatnya ditambatkan di sana. Secara serupa, jika ada Pod dengan _mount propagation_ `Bidirectional` terhadap volume yang sama menambatkan apapun ke situ, maka Container dengan _mount propagation_ `HostToContainer` akan melihatnya. diff --git a/content/id/docs/concepts/workloads/controllers/garbage-collection.md b/content/id/docs/concepts/workloads/controllers/garbage-collection.md index 2c160b3b44d64..00e13f0c0c9b1 100644 --- a/content/id/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/id/docs/concepts/workloads/controllers/garbage-collection.md @@ -49,7 +49,7 @@ metadata: ``` {{< note >}} Referensi pemilik lintas _namespace_ tidak diperbolehkan oleh desain. Artinya: -1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan kluster. +1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan kluster. 2) Dependen dengan cakupan kluster hanya bisa menspesifikasikan pemilik yang memiliki cakupan kluster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan kluster. {{< /note >}} @@ -82,7 +82,7 @@ Pada *foreground cascading deletion*, pertama objek utama akan memasuki keadaan Sebelum Kubernetes 1.9, kebijakan _default_ dari _garbage collection_ untuk banyak _resource controller_ adalah **orphan**. Ini meliputi ReplicationController, ReplicaSet, StatefulSet, DaemonSet, dan Deployment. Untuk jenis pada kelompok versi `extensions/v1beta1`, `apps/v1beta1`, dan `apps/v1beta2`, kecuali kamu menspesifikasikan dengan cara lain, objek dependen adalah _orphan_ secara _default_. Pada Kubernetes 1.9, untuk semua jenis pada kelompok versi `apps/v1`, objek dependen dihapus secara _default_. Berikut sebuah contoh yang menghapus dependen di _background_: - + ```shell kubectl proxy --port=8080 curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \ diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md index 5681c4a9e8d53..8d4a63ffeb2d3 100644 --- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -8,13 +8,13 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu -objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani -[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), -dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan -misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. +Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu +objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani +[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), +dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan +misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. -Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan +Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifkan dengan [_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) `TTLAfterFinished`. @@ -28,33 +28,33 @@ Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifk ## Pengendali TTL -Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster -dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik -`Complete` atau `Failed`) secara otomatis dengan menentukan _field_ -`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di +Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster +dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik +`Complete` atau `Failed`) secara otomatis dengan menentukan _field_ +`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di [contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). -Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila -TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini -dilakukan secara berantai, dimana sumber daya lain yang -berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus, +Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila +TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini +dilakukan secara berantai, dimana sumber daya lain yang +berkaitan akan ikut terhapus. Perhatikan bahwa ketika sebuah sumber daya dihapus, siklus hidup yang ada akan menjaga bahwa _finalizer_ akan tetap dijalankan sebagaimana mestinya. -Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_ +Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk mengaktifkan _field_ `.spec.ttlSecondsAfterFinished` pada suatu Job: -* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan - dihapus secara otomatis beberapa saat setelah selesai dieksekusi. -* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk +* Spesifikasikan _field_ ini pada _manifest_ sumber daya, sehingga Job akan + dihapus secara otomatis beberapa saat setelah selesai dieksekusi. +* Aktifkan _field_ ini pada sumber daya yang sudah selesai dieksekusi untuk menerapkan fitur ini. -* Gunakan sebuah +* Gunakan sebuah [mengubah (_mutating_) _admission)](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) - untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya. - Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada + untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya. + Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada sumber daya yang telah selesai digunakan. -* Gunakan sebuah +* Gunakan sebuah [mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) - untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya - selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain + untuk mengaktifkan _field_ ini secara dinamis setelah sumber daya + selesai digunakan dan TTL didefinisikan sesuai dengan status, label, atau hal lain yang diinginkan. ## Peringatan @@ -62,20 +62,20 @@ Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk men ### Mengubah TTL Detik Perhatikan bahwa periode TTL, yaitu _field_ `.spec.ttlSecondsAfterFinished` pada Job, -dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan. -Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan +dapat dimodifikasi baik setelah sumber daya dibuat atau setelah selesai digunakan. +Meskipun begitu, setelah Job dapat dihapus (TTL sudah habis), sistem tidak akan menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah. ### _Time Skew_ -Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya -Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif -terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah +Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya +Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif +terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah bagi objek tersebut akibat adanya _time skew_. -Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_ -(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)). -_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi. +Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_ +(lihat [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)). +_Clock_ tidak akan selalu tepat, meskipun begitu perbedaan yang ada haruslah diminimalisasi. Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selain 0. {{% /capture %}} diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md index d54f18c0af993..48e53de71f882 100644 --- a/content/id/docs/concepts/workloads/pods/init-containers.md +++ b/content/id/docs/concepts/workloads/pods/init-containers.md @@ -58,7 +58,7 @@ Berikut beberapa contoh kasus penggunaan Init Container: * Menunggu beberapa waktu sebelum menjalankan Container aplikasi dengan perintah seperti `sleep 60`. * Mengklon sebuah _git repository_ ke dalam sebuah _volume_. * Menaruh nilai-nilai tertentu ke dalam sebuah _file_ konfigurasi dan menjalankan peralatan _template_ untuk membuat _file_ konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja. - + Contoh-contoh penggunaan yang lebih detail dapat dilihat pada [dokumentasi StatefulSet](/docs/concepts/workloads/controllers/statefulset/) dan [petunjuk Produksi Pod](/docs/tasks/configure-pod-container/configure-pod-initialization/). ### Menggunakan Init Container diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md index cc6c992ab874a..386e49640c288 100644 --- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md @@ -30,7 +30,7 @@ Nilai | Deskripsi :-----|:----------- `Pending` | Pod telah disetujui oleh sistem Kubernetes, tapi ada satu atau lebih _image_ kontainer yang belum terbuat. Ini termasuk saat sebelum dijadwalkan dan juga saat mengunduh _image_ melalui jaringan, yang mungkin butuh beberapa waktu. `Running` | Pod telah terikat ke suatu node, dan semua kontainer telah terbuat. Setidaknya ada 1 kontainer yang masih berjalan, atau dalam proses memulai atau _restart_. -`Succeeded` | Semua kontainer di dalam Pod sudah berhasil dihentikan, dan tidak akan dilakukan _restart_. +`Succeeded` | Semua kontainer di dalam Pod sudah berhasil dihentikan, dan tidak akan dilakukan _restart_. `Failed` | Semua kontainer dalan suatu Pod telah dihentikan, dan setidaknya ada satu kontainer yang terhenti karena kegagalan. Itu merupakan kontainer yang keluar dengan kode status bukan 0 atau dihentikan oleh sistem. `Unknown` | _State_ suatu Pod tidak dapat diperoleh karena suatu alasan, biasanya karena kesalahan dalam komunikasi dengan _host_ yang digunakan Pod tersebut. @@ -38,7 +38,7 @@ Nilai | Deskripsi Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) yang telah atau belum dilewati oleh Pod. Setiap elemen dari _array_ PodConditions mungkin memiliki enam _field_ berikut: -* _Field_ `lastProbeTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali kondisi kondisi Pod diperiksa. +* _Field_ `lastProbeTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali kondisi kondisi Pod diperiksa. * _Field_ `lastTransitionTime` memberikan nilai _timestamp_ yang menandakan kapan terakhir kali Pod berubah status ke status lain. @@ -48,16 +48,16 @@ Suatu Pod memiliki sebuah PodStatus, yang merupakan _array_ dari [PodConditions] * _Field_ `status` adalah sebuah kata dengan kemungkinan nilainya berupa "`True`", "`False`", dan "`Unknown`". -* _Field_ `type` adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut: +* _Field_ `type` adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut: - * `PodScheduled`: Pod telah dijadwalkan masuk ke node; + * `PodScheduled`: Pod telah dijadwalkan masuk ke node; * `Ready`: Pod sudah mampu menerima _request_ masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama; - * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. + * `Initialized`: Semua [init containers](/docs/concepts/workloads/pods/init-containers) telah berjalan sempurna. * `Unschedulable`: _scheduler_ belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan _resources_ atau ada batasan-batasan lain. - * `ContainersReady`: Semua kontainer di dalam Pod telah siap. + * `ContainersReady`: Semua kontainer di dalam Pod telah siap. -## Pemeriksaan Kontainer +## Pemeriksaan Kontainer Sebuah [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) adalah sebuah diagnosa yang dilakukan secara berkala oleh [kubelet](/docs/admin/kubelet/) dalam suatu kontainer. Untuk melakukan diagnosa, kubelet memanggil sebuah [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) yang diimplementasikan oleh kontainer. Ada 3 tipe _Handler_ yang tersedia, yaitu: @@ -79,21 +79,21 @@ _Kubelet_ dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemerik * `readinessProbe`: Ini menunjukan apakah kontainer sudah siap melayani _request_. Jika tidak berhasil melakukan pemeriksaan terhadap kesiapan dari kontainer, maka _endpoints controller_ akan menghapus alamat IP Pod dari daftar semua _endpoint_ untuk servis yang sama dengan Pod. Nilai awal _state_ sebelum jeda awal adalah `Failure`. Jika kontainer tidak menyediakan pemeriksaan terhadap _readiness_, maka nilai awal _state_ adalah `Success`. -### Kapan sebaiknya menggunakan pemeriksaan terhadap _liveness_ atau _readiness_? +### Kapan sebaiknya menggunakan pemeriksaan terhadap _liveness_ atau _readiness_? -Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah +Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah atau menjadi tidak sehat, maka pemeriksaan terhadap _liveness_ tidak diperlukan. Kubelet akan secara otomatis melakukan aksi yang tepat mengikuti `restartPolicy` dari Pod. -Jika kamu ingin kontainer bisa dimatikan dan dijalankan ulang ketika gagal melakukan +Jika kamu ingin kontainer bisa dimatikan dan dijalankan ulang ketika gagal melakukan pemeriksaan, maka tentukan pemeriksaan _liveness_ dan tentukan nilai `restartPolicy` sebagai `Always` atau `OnFailure`. Jika kamu ingin mulai mengirim _traffic_ ke Pod hanya ketika pemeriksaan berhasil, -maka tentukan pemeriksaan _readiness_. Dalam kasus ini, pemeriksaan _readiness_ mungkin +maka tentukan pemeriksaan _readiness_. Dalam kasus ini, pemeriksaan _readiness_ mungkin akan sama dengan pemeriksaan _liveness_, tapi keberadaan pemeriksaan _readiness_ dalam -_spec_ berarti Pod akan tetap dijalankan tanpa menerima _traffic_ apapun dan akan +_spec_ berarti Pod akan tetap dijalankan tanpa menerima _traffic_ apapun dan akan mulai menerima _traffic_ ketika pemeriksaan yang dilakukan mulai berhasil. -Jika kontainermu dibutuhkan untuk tetap berjalan ketika _loading_ data yang besar, +Jika kontainermu dibutuhkan untuk tetap berjalan ketika _loading_ data yang besar, _file_ konfigurasi, atau melakukan migrasi ketika _startup_, maka tentukanlah pemeriksaan _readiness_. Jika kamu ingin kontainermu dalam mematikan dirinya sendiri, kamu dapat menentukan @@ -103,30 +103,30 @@ _endpoint_ tersebut berbeda dengan _endpoint_ untuk pengecekan _liveness_. Perlu dicatat, jika kamu hanya ingin bisa menutup _request_ ketika Pod sedang dihapus maka kamu tidak perlu menggunakan pemeriksaan _readiness_. Dalam penghapusan, Pod akan secara otomatis mengubah _state_ dirinya menjadi _unready_ tanpa peduli apakah terdapat -pemeriksaan _readiness_ atau tidak. Pod tetap ada pada _state unready_ selama menunggu +pemeriksaan _readiness_ atau tidak. Pod tetap ada pada _state unready_ selama menunggu kontainer dalam Pod berhenti. Untuk informasi lebih lanjut mengenai pengaturan pemeriksaan _liveness_ atau _readiness_, lihat bagian [Konfigurasi _Liveness_ dan _Readiness_ _Probe_](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/). -## Status Pod dan Kontainer +## Status Pod dan Kontainer -Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat +Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) -dan +dan [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). -Mohon diperhatikan, informasi tentang status Pod bergantung pada +Mohon diperhatikan, informasi tentang status Pod bergantung pada [ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core). ## State Kontainer -Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan _runtime_ kontainer. +Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan _runtime_ kontainer. Ada tiga kemungkinan _state_ untuk suatu kontainer, yaitu Waiting, Running, dan Terminated. Untuk mengecek _state_ suatu kontainer, kamu bisa menggunakan perintah `kubectl describe pod [NAMA_POD]`. _State_ akan ditampilkan untuk masing-masing kontainer dalam Pod tersebut. -* `Waiting`: Merupakan _state_ default dari kontainer. Jika _state_ kontainer bukan Running atau Terminated, berarti dalam _Wating state_. -Suatu kontainer dalam Waiting _state_ akan tetap menjalan operasi-operasi yang dibutuhkan, misalnya mengunduh _images_, mengaplikasikan Secrets, dsb. +* `Waiting`: Merupakan _state_ default dari kontainer. Jika _state_ kontainer bukan Running atau Terminated, berarti dalam _Wating state_. +Suatu kontainer dalam Waiting _state_ akan tetap menjalan operasi-operasi yang dibutuhkan, misalnya mengunduh _images_, mengaplikasikan Secrets, dsb. Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditampilkan untuk memberi informasi lebih. ```yaml @@ -135,7 +135,7 @@ Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditam Reason: ErrImagePull ... ``` - + * `Running`: Menandakan kontainer telah berjalan tanpa masalah. Setelah kontainer masuk ke _state_ Running, jika terdapat _hook_ `postStart` maka akan dijalankan. _State_ ini juga menampilkan waktu ketika kontainer masuk ke _state_ Running. ```yaml @@ -143,8 +143,8 @@ Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditam State: Running Started: Wed, 30 Jan 2019 16:46:38 +0530 ... - ``` - + ``` + * `Terminated`: Menandakan kontainer telah menyelesaikan "tugasnya". Kontainer akan menjadi _state_ ini ketika telah menyelesaikan eksekusi atau terjadi kesalahan. Terlepas dari itu, sebuah alasan dan _exit code_ akan ditampilkan, bersama dengan waktu kontainer mulai dijalankan dan waktu berhenti. Sebelum kontainer masuk ke _state_ Terminated, jika terdapat `preStop` _hook_ maka akan dijalankan. ```yaml @@ -155,18 +155,18 @@ Bersamaan dengan _state_ ini, sebuah pesan dan alasan tentang _state_ akan ditam Started: Wed, 30 Jan 2019 11:45:26 +0530 Finished: Wed, 30 Jan 2019 11:45:26 +0530 ... - ``` + ``` ## Pod readiness gate {{< feature-state for_k8s_version="v1.14" state="stable" >}} -Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan +Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan injeksi umpan balik tambahan atau sinyal ke dalam `PodStatus`, Kubernetes 1.11 memperkenalkan sebuah fitur bernama [Pod ready++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md). -Kamu dapat menggunakan _field_ baru `ReadinessGate` dalam sebuah `PodSpec` untuk -menunjukan kondisi tambahan yang akan dievaluasi untuk kesiapan Pod. Jika Kubernetes -tidak dapat menemukan kondisi pada _field_ `status.conditions` dalam suatu Pod, +Kamu dapat menggunakan _field_ baru `ReadinessGate` dalam sebuah `PodSpec` untuk +menunjukan kondisi tambahan yang akan dievaluasi untuk kesiapan Pod. Jika Kubernetes +tidak dapat menemukan kondisi pada _field_ `status.conditions` dalam suatu Pod, maka statusnya akan secara otomatis menjadi `False`. Berikut adalah contoh pemakaiannya: ```yaml @@ -201,7 +201,7 @@ Dengan diperkenalkannya kondisi Pod yang baru, sebuah Pod akan dianggap siap han * Semua kontainer yang diatur dalam `ReadinessGates` bernilai "`True`". -Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu `ContainerReady`, +Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu `ContainerReady`, untuk dapat menangani kondisi Pod `Ready` yang sudah ada. Dalam K8s 1.11, sebagai fitur _alpha_, fitur "Pod Ready++" harus diaktifkan melalui pengaturan @@ -216,13 +216,13 @@ Sebuah PodSpec memiliki _field_ `restartPolicy` dengan kemungkinan nilai berupa Nilai awalnya berupa Always. `restartPolicy` akan berlaku untuk semua kontainer dalam Pod. Kontainer yang mati dan dijalankan ulang oleh kubelet akan dijalankan ulang dengan jeda waktu yang ekponensial (10s, 20s, 40s, ...) dengan batas atas senilai lima menit. Jeda waktu ini akan diatur ulang setelah sukses berjalan selama 10 menit. -Sesuai dengan diskusi pada [dokumen Pod](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), +Sesuai dengan diskusi pada [dokumen Pod](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof), setelah masuk ke suatu node, sebuah Pod tidak akan pindah ke node lain. ## Umur Pod Secara umum, Pod tidak hilang sampai ada yang menghapusnya. Ini mungkin dihapus oleh orang atau pengontrol. -Satu pengecualian untuk aturan ini adalah Pod dengan `phase` bernilai Succeeded atau Failed untuk waktu +Satu pengecualian untuk aturan ini adalah Pod dengan `phase` bernilai Succeeded atau Failed untuk waktu beberapa lama yang akan berakhir dan secara otomatis akan dihapus. (diatur dalam `terminated-pod-gc-threshold` pada master) @@ -232,9 +232,9 @@ Tiga tipe pengontrol yang tersedia yaitu: sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan `restartPolicy` yang bernilai OnFailure atau Never. -- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), +- Menggunakan sebuah [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/), [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), atau - [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, + [Deployment](/docs/concepts/workloads/controllers/deployment/) untuk Pod yang tidak diharapkan untuk berakhir, sebagai contoh, _web servers_. ReplicationControllers hanya cocok digunakan pada Pod dengan `restartPolicy` yang bernilai Always. @@ -242,7 +242,7 @@ Tiga tipe pengontrol yang tersedia yaitu: hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin. -Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat +Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat pengontrol yang sesuai dan membiarkan ini membuat Pod, daripada membuat Pod sendiri secara langsung. Karena Pod itu sendiri tidak tahan terhadap gagalnya suatu mesin, namun pengontrol tahan. @@ -253,7 +253,7 @@ Jika node mati atau sambungannya terputus dari kluster, Kubernetes mengatur ### Contoh _Liveness Probe_ tingkat lanjut -_Liveness probe_ dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan +_Liveness probe_ dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan di dalam _namespace_ jaringan kubelet. diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md index e83def7cdeb84..a363a8f87c40e 100644 --- a/content/id/docs/concepts/workloads/pods/pod-overview.md +++ b/content/id/docs/concepts/workloads/pods/pod-overview.md @@ -2,7 +2,7 @@ title: Pengenalan Pod content_template: templates/concept weight: 10 -card: +card: name: concepts weight: 60 --- @@ -36,7 +36,7 @@ Setiap *Pod* dimaksudkan untuk menjalankan satu *instance* aplikasi. Jika kamu i ### Bagaimana *Pod* mengelola beberapa Kontainer *Pod* didesain untuk mendukung banyak proses (sebagai kontainer) yang membentuk sebuah layanan. Kontainer di dalam sebuah *Pod* akan otomatis ditempatkan bersama di dalam satu mesin fisik atau mesin *virtual* di dalam kluster. Kontainer tersebut dapat berbagi *resource* dan dependensi, berkomunikasi satu sama lain, dan berkoordinasi kapan dan bagaimana mereka diterminasi. -Perhatikan bahwa mengelompokan kontainer di dalam satu *Pod* merupakan kasus lanjutan. Kamu dapat menggunakan pola ini hanya dalam kasus tertentu. Sebagai contoh, kamu memiliki kontainer yang bertindak sebagai *web server* yang menyajikan berkas dari *resource* penyimpanan bersama, dan kontainer *sidecar* melakukan pembaharuan terhadap berkas tersebut dari sumber lain, seperti dalam diagram *Pod* berikut: +Perhatikan bahwa mengelompokan kontainer di dalam satu *Pod* merupakan kasus lanjutan. Kamu dapat menggunakan pola ini hanya dalam kasus tertentu. Sebagai contoh, kamu memiliki kontainer yang bertindak sebagai *web server* yang menyajikan berkas dari *resource* penyimpanan bersama, dan kontainer *sidecar* melakukan pembaharuan terhadap berkas tersebut dari sumber lain, seperti dalam diagram *Pod* berikut: {{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} *Pod* menyediakan dua jenis *resource* sebagai penyusun dari kontainer: *jaringan* dan *penyimpanan*. diff --git a/content/id/docs/reference/glossary/cluster-operator.md b/content/id/docs/reference/glossary/cluster-operator.md index e1d09dbc7ddbe..af07cde13afcb 100644 --- a/content/id/docs/reference/glossary/cluster-operator.md +++ b/content/id/docs/reference/glossary/cluster-operator.md @@ -2,17 +2,17 @@ title: Cluster Operator id: cluster-operator date: 2018-04-12 -full_link: +full_link: short_description: > Seseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster. -aka: +aka: tags: - user-type --- Seseorang yang mengkonfigurasi, mengontrol, dan memonitor cluster. - + Tanggung jawab utama mereka adalah menjaga dan menjalankan cluster, yang mungkin melibatkan kegiatan pemeliharaan berkala atau peningkatan.
diff --git a/content/id/docs/reference/glossary/contributor.md b/content/id/docs/reference/glossary/contributor.md index 1c19bd173fee9..0c1a3d0694001 100644 --- a/content/id/docs/reference/glossary/contributor.md +++ b/content/id/docs/reference/glossary/contributor.md @@ -2,16 +2,16 @@ title: Contributor id: contributor date: 2018-04-12 -full_link: +full_link: short_description: > Seseorang yang menyumbangkan kode, dokumentasi, atau waktu mereka untuk membantu proyek atau komunitas Kubernetes. -aka: +aka: tags: - community --- Seseorang yang menyumbangkan kode, dokumentasi, atau waktu mereka untuk membantu proyek atau komunitas Kubernetes. - + Kontribusi termasuk _pull request_ (PR), masalah, umpan balik, partisipasi {{< glossary_tooltip text="special interest groups (SIG)" term_id="sig" >}}, atau mengorganisir acara komunitas. diff --git a/content/id/docs/reference/glossary/etcd.md b/content/id/docs/reference/glossary/etcd.md index 51a28fced1691..5dea98f0aff01 100644 --- a/content/id/docs/reference/glossary/etcd.md +++ b/content/id/docs/reference/glossary/etcd.md @@ -4,15 +4,15 @@ id: etcd date: 2019-04-21 full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ short_description: > - Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes. + Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes. -aka: +aka: tags: - architecture - storage --- - Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes. + Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes. - + Selalu perhatikan mekanisme untuk mem-backup data etcd pada kluster Kubernetes kamu. Untuk informasi lebih lanjut tentang etcd, lihat [dokumentasi etcd](https://github.com/coreos/etcd/blob/master/Documentation/docs.md). diff --git a/content/id/docs/reference/glossary/ingress.md b/content/id/docs/reference/glossary/ingress.md index f62acef0c3049..7b6fb316e95e1 100644 --- a/content/id/docs/reference/glossary/ingress.md +++ b/content/id/docs/reference/glossary/ingress.md @@ -6,7 +6,7 @@ full_link: /docs/concepts/services-networking/ingress/ short_description: > Sebuah obyek API yang mengatur akses eksternal terhadap *Service* yang ada di dalam kluster, biasanya dalam bentuk *request* HTTP. -aka: +aka: tags: - networking - architecture @@ -14,7 +14,7 @@ tags: --- Sebuah obyek API yang mengatur akses eksternal terhadap *Service* yang ada di dalam kluster, biasanya dalam bentuk *request* HTTP. - + Ingress juga menyediakan *load balancing*, terminasi SSL, serta *name-based virtual hosting*. diff --git a/content/id/docs/reference/glossary/kube-apiserver.md b/content/id/docs/reference/glossary/kube-apiserver.md index 0f6ec921031ec..db4442026e004 100644 --- a/content/id/docs/reference/glossary/kube-apiserver.md +++ b/content/id/docs/reference/glossary/kube-apiserver.md @@ -4,16 +4,16 @@ id: kube-apiserver date: 2019-04-21 full_link: /docs/reference/generated/kube-apiserver/ short_description: > - Komponen di master yang mengekspos API Kubernetes. Merupakan front-end dari kontrol plane Kubernetes. + Komponen di master yang mengekspos API Kubernetes. Merupakan front-end dari kontrol plane Kubernetes. -aka: +aka: tags: - architecture - fundamental --- - Komponen di master yang mengekspos API Kubernetes. Merupakan front-end dari kontrol plane Kubernetes. + Komponen di master yang mengekspos API Kubernetes. Merupakan front-end dari kontrol plane Kubernetes. - + Komponen ini didesain agar dapat di-scale secara horizontal. Lihat [Membangun Kluster HA](/docs/admin/high-availability/). diff --git a/content/id/docs/reference/glossary/kube-controller-manager.md b/content/id/docs/reference/glossary/kube-controller-manager.md index 1e8b2392f055b..436927afc75e0 100644 --- a/content/id/docs/reference/glossary/kube-controller-manager.md +++ b/content/id/docs/reference/glossary/kube-controller-manager.md @@ -6,14 +6,14 @@ full_link: /docs/reference/generated/kube-controller-manager/ short_description: > Komponen di master yang menjalankan kontroler. -aka: +aka: tags: - architecture - fundamental --- Komponen di master yang menjalankan kontroler. - + -Secara logis, setiap kontroler adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kontroler-kontroler ini dikompilasi menjadi sebuah binary yang dijalankan sebagai satu proses. +Secara logis, setiap kontroler adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kontroler-kontroler ini dikompilasi menjadi sebuah binary yang dijalankan sebagai satu proses. diff --git a/content/id/docs/reference/glossary/kube-scheduler.md b/content/id/docs/reference/glossary/kube-scheduler.md index c48f911624cd7..e1bf37a36b5d4 100644 --- a/content/id/docs/reference/glossary/kube-scheduler.md +++ b/content/id/docs/reference/glossary/kube-scheduler.md @@ -6,13 +6,13 @@ full_link: /docs/reference/generated/kube-scheduler/ short_description: > Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-assign ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan. -aka: +aka: tags: - architecture --- Komponen di master yang bertugas mengamati pod yang baru dibuat dan belum di-assign ke suatu node dan kemudian akan memilih sebuah node dimana pod baru tersebut akan dijalankan. - + Faktor-faktor yang diperhatikan dalam proses ini adalah kebutuhan resource secara individual dan kolektif, konstrain perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan non-afinitas, lokalisasi data, interferensi inter-workload dan deadlines. diff --git a/content/id/docs/reference/glossary/kubelet.md b/content/id/docs/reference/glossary/kubelet.md index 0ca31fdb6369d..5913aa7837193 100644 --- a/content/id/docs/reference/glossary/kubelet.md +++ b/content/id/docs/reference/glossary/kubelet.md @@ -6,7 +6,7 @@ full_link: /docs/reference/generated/kubelet short_description: > Agen yang dijalankan pada setiap node di kluster dan bertugas memastikan kontainer dijalankan di dalam pod. -aka: +aka: tags: - fundamental - core-object diff --git a/content/id/docs/reference/glossary/name.md b/content/id/docs/reference/glossary/name.md index 5a6cae63cc70d..aa47ab344eb98 100755 --- a/content/id/docs/reference/glossary/name.md +++ b/content/id/docs/reference/glossary/name.md @@ -6,12 +6,12 @@ full_link: /docs/concepts/overview/working-with-objects/names short_description: > String yang dihasilkan oleh klien yang mengacu pada sebuah objek dalam suatu URL resource, seperti `/api/v1/pods/some-name`. -aka: +aka: tags: - fundamental --- String yang dihasilkan oleh klien yang mengacu pada sebuah objek dalam suatu URL *resource*, seperti `/api/v1/pods/some-name`. - + Sebuah objek dengan kind yang sama tidak boleh memiliki nama yang sama pada suatu waktu tertentu. Meskipun begitu, apabila kamu menghapus sebuah objek, kamu membuat sebuah objek baru (yang memiliki kind yang sama) dengan nama yang sama dengan objek yang kamu hapus sebelumnya. diff --git a/content/id/docs/reference/glossary/platform-developer.md b/content/id/docs/reference/glossary/platform-developer.md index e0f90e84591d5..a3fa968c1e083 100644 --- a/content/id/docs/reference/glossary/platform-developer.md +++ b/content/id/docs/reference/glossary/platform-developer.md @@ -2,16 +2,16 @@ title: Platform Developer id: platform-developer date: 2018-04-12 -full_link: +full_link: short_description: > Seseorang yang menyesuaikan platform Kubernetes agar sesuai dengan kebutuhan proyek mereka. -aka: +aka: tags: - user-type --- Seseorang yang menyesuaikan platform Kubernetes agar sesuai dengan kebutuhan proyek mereka. - + Pengembang platform dapat, misalnya, menggunakan [Sumber Daya Kustom](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) atau [Memperluas API Kubernetes dengan lapisan agregasi](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) untuk menambahkan fungsionalitas ke instansi Kubernetes mereka, khususnya untuk aplikasi mereka. Beberapa Pengembang Platform juga {{}} dan mengembangkan perluasan yang berkontribusi pada komunitas Kubernetes. Lainnya mengembangkan sumber tertutup komersial atau perluasan spesifik situs. diff --git a/content/id/docs/reference/glossary/uid.md b/content/id/docs/reference/glossary/uid.md index f5068ebccdeec..f9da13e36bf1b 100755 --- a/content/id/docs/reference/glossary/uid.md +++ b/content/id/docs/reference/glossary/uid.md @@ -6,12 +6,12 @@ full_link: /docs/concepts/overview/working-with-objects/names short_description: > String yang dihasilkan oleh sistem Kubernetes untuk mengidentifikasi objek secara unik. -aka: +aka: tags: - fundamental --- String yang dihasilkan oleh sistem Kubernetes untuk mengidentifikasi objek secara unik. - + Setiap objek yang ada pada kluster Kubernetes memiliki UID yang unik. Hal ini dilakukan untuk membedakan keberadaan historis suatu entitas dengan kind dan nama yang serupa. diff --git a/content/id/docs/setup/_index.md b/content/id/docs/setup/_index.md index 490c3af5b513b..44fcb69673d9c 100644 --- a/content/id/docs/setup/_index.md +++ b/content/id/docs/setup/_index.md @@ -10,7 +10,7 @@ content_template: templates/concept Gunakan halaman ini untuk mencari solusi yang paling sesuai dengan kebutuhan kamu. -Menentukan dimana sebaiknya Kubernetes dijalankan sangat tergantung pada kapasitas yang kamu punya dan seberapa fleksibel kluster yang kamu inginkan. +Menentukan dimana sebaiknya Kubernetes dijalankan sangat tergantung pada kapasitas yang kamu punya dan seberapa fleksibel kluster yang kamu inginkan. Kamu dapat menjalankan Kubernetes hampir dimana saja, mulai dari laptop, VM di penyedia cloud, sampai pada rak-rak berisi server baremetal. Kamu juga bisa menyiapkan kluster yang diatur sepenuhnya (fully-managed), dengan hanya menjalankan satu perintah, ataupun membuat kluster dengan solusi custom kamu sendiri pada server baremetal. diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md index 01354141e368a..5e43aea0c471a 100644 --- a/content/id/docs/tutorials/_index.md +++ b/content/id/docs/tutorials/_index.md @@ -8,7 +8,7 @@ content_template: templates/concept {{% capture overview %}} Bagian ini membahas tentang tutorial Kubernetes. -Tutorial berfungsi untuk memperlihatkan bagaimana caranya mencapai suatu tujuan yang lebih dari sekedar [task](/docs/tasks/) sederhana. +Tutorial berfungsi untuk memperlihatkan bagaimana caranya mencapai suatu tujuan yang lebih dari sekedar [task](/docs/tasks/) sederhana. Biasanya, sebuah tutorial punya beberapa bagian, masing-masing bagian terdiri dari langkah-langkah yang berurutan. Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus Istilah](/docs/reference/glossary/) untuk referensi nanti. @@ -68,7 +68,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus {{% capture whatsnext %}} -Tertarik menulis tutorial? Lihat +Tertarik menulis tutorial? Lihat [Menggunakan Template Halaman](/docs/home/contribute/page-templates/) untuk info mengenai template dan ragam halaman tutorial. diff --git a/content/id/docs/tutorials/hello-minikube.md b/content/id/docs/tutorials/hello-minikube.md index 3f6b1dd7fe902..387e88d32acae 100644 --- a/content/id/docs/tutorials/hello-minikube.md +++ b/content/id/docs/tutorials/hello-minikube.md @@ -8,7 +8,7 @@ menu: weight: 10 post: >

Siap untuk mengotori tanganmu? Yuk kita buat kluster Kubernetes sederhana yang menjalankan Node.js aplikasi "Halo Dunia".

-card: +card: name: tutorials weight: 10 --- @@ -48,7 +48,7 @@ Untuk info lebih lanjut tentang perintah `docker build`, baca [dokumentasi Docke ## Membuat sebuah kluster Minikube -1. Tekan **Launch Terminal** +1. Tekan **Launch Terminal** {{< kat-button >}} @@ -62,7 +62,7 @@ Untuk info lebih lanjut tentang perintah `docker build`, baca [dokumentasi Docke 3. Hanya untuk environment Katacoda: Di layar terminal paling atas, tekan tombol plus, lalu lanjut tekan **Select port to view on Host 1**. -4. Hanya untuk environment Katacoda: Ketik `30000`, lalu lanjut tekan **Display Port**. +4. Hanya untuk environment Katacoda: Ketik `30000`, lalu lanjut tekan **Display Port**. ## Membuat sebuah Deployment @@ -72,7 +72,7 @@ saling terhubung untuk kebutuhan administrasi dan jaringan. Pod dalam tutorial i Pod kamu dan melakukan restart saat Kontainer di dalam Pod tersebut mati. Deployment adalah cara jitu untuk membuat dan mereplikasi Pod. 1. Gunakan perintah `kubectl create` untuk membuat Deployment yang dapat mengatur Pod. -Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. +Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. ```shell kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node @@ -114,7 +114,7 @@ Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. ```shell kubectl config view ``` - + {{< note >}}Untuk info lebih lanjut tentang perintah `kubectl`, lihat [ringkasan kubectl](/docs/user-guide/kubectl-overview/).{{< /note >}} ## Membuat sebuah Servis @@ -127,7 +127,7 @@ Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - + Tanda `--type=LoadBalancer` menunjukkan bahwa kamu ingin ekspos Servis keluar dari kluster. 2. Lihat Servis yang baru kamu buat: @@ -144,7 +144,7 @@ Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes kubernetes ClusterIP 10.96.0.1 443/TCP 23m ``` - Untuk penyedia cloud yang memiliki load balancer, sebuah alamat IP eksternal akan disediakan untuk mengakses Servis tersebut. + Untuk penyedia cloud yang memiliki load balancer, sebuah alamat IP eksternal akan disediakan untuk mengakses Servis tersebut. Pada Minikube, tipe `LoadBalancer` membuat Servis tersebut dapat diakses melalui perintah `minikube service`. 3. Jalankan perintah berikut: @@ -188,13 +188,13 @@ Minikube punya beberapa addons yang bisa diaktifkan, dinon-aktifkan, maup registry-creds: disabled storage-provisioner: enabled ``` - + 2. Aktifkan sebuah addon, misalnya `heapster`: ```shell minikube addons enable heapster ``` - + Keluaran: ```shell @@ -231,7 +231,7 @@ Minikube punya beberapa addons yang bisa diaktifkan, dinon-aktifkan, maup ```shell minikube addons disable heapster ``` - + Keluaran: ```shell