Merge pull request kubernetes#50311 from enchant3dmango/docs/pod-glossary-id

[id] Standardizing word 'klaster'

Author: k8s-ci-robot

Diff for: content/id/docs/concepts/architecture/controller.md

@@ -12,14 +12,14 @@ lingkaran tertutup yang mengatur keadaan suatu sistem.
 Berikut adalah salah satu contoh kontrol tertutup: termostat di sebuah ruangan.
 
 Ketika kamu mengatur suhunya, itu mengisyaratkan ke termostat
-tentang *keadaan yang kamu inginkan*. Sedangkan suhu kamar yang sebenarnya 
+tentang *keadaan yang kamu inginkan*. Sedangkan suhu kamar yang sebenarnya
 adalah *keadaan saat ini*. Termostat berfungsi untuk membawa keadaan saat ini
-mendekati ke keadaan yang diinginkan, dengan menghidupkan atau mematikan 
+mendekati ke keadaan yang diinginkan, dengan menghidupkan atau mematikan
 perangkat.
 
 Di Kubernetes, _controller_ adalah kontrol tertutup yang mengawasi keadaan klaster
-{{< glossary_tooltip term_id="cluster" text="klaster" >}} kamu, lalu membuat atau meminta 
-perubahan jika diperlukan. Setiap _controller_ mencoba untuk memindahkan status 
+{{< glossary_tooltip term_id="cluster" text="klaster" >}} kamu, lalu membuat atau meminta
+perubahan jika diperlukan. Setiap _controller_ mencoba untuk memindahkan status
 klaster saat ini mendekati keadaan yang diinginkan.
 
 {{< glossary_definition term_id="controller" length="short">}}
@@ -29,24 +29,24 @@ klaster saat ini mendekati keadaan yang diinginkan.
 
 <!-- body -->
 
-## Pola _controller_ 
+## Pola _controller_
 
-Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari 
+Sebuah _controller_ melacak sekurang-kurangnya satu jenis sumber daya dari
 Kubernetes.
 [objek-objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/) ini
-memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau 
-lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat 
+memiliki *spec field* yang merepresentasikan keadaan yang diinginkan. Satu atau
+lebih _controller_ untuk *resource* tersebut bertanggung jawab untuk membuat
 keadaan sekarang mendekati keadaan yang diinginkan.
 
-_Controller_ mungkin saja melakukan tindakan itu sendiri; namun secara umum, di 
+_Controller_ mungkin saja melakukan tindakan itu sendiri; namun secara umum, di
 Kubernetes, _controller_ akan mengirim pesan ke
-{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} yang 
-mempunyai efek samping yang bermanfaat. Kamu bisa melihat contoh-contoh 
+{{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} yang
+mempunyai efek samping yang bermanfaat. Kamu bisa melihat contoh-contoh
 di bawah ini.
 
 {{< comment >}}
 Beberapa _controller_ bawaan, seperti _controller namespace_, bekerja pada objek
-yang tidak memiliki *spec*. Agar lebih sederhana, halaman ini tidak 
+yang tidak memiliki *spec*. Agar lebih sederhana, halaman ini tidak
 menjelaskannya secara detail.
 {{< /comment >}}
 
@@ -57,92 +57,92 @@ bawaan dari Kubernetes. _Controller_ bawaan tersebut mengelola status melalui
 interaksi dengan server API dari suatu klaster.
 
 Job adalah sumber daya dalam Kubernetes yang menjalankan a
-{{< glossary_tooltip term_id="pod" >}}, atau mungkin beberapa Pod sekaligus, 
+{{< glossary_tooltip term_id="pod" >}}, atau mungkin beberapa Pod sekaligus,
 untuk melakukan sebuah pekerjaan dan kemudian berhenti.
 
-(Setelah [dijadwalkan](/id/docs/concepts/scheduling-eviction/), objek Pod 
+(Setelah [dijadwalkan](/id/docs/concepts/scheduling-eviction/), objek Pod
 akan menjadi bagian dari keadaan yang diinginkan oleh kubelet).
 
-Ketika _controller job_ melihat tugas baru, maka _controller_ itu memastikan bahwa, 
-di suatu tempat pada klaster kamu, kubelet dalam sekumpulan Node menjalankan 
-Pod-Pod dengan jumlah yang benar untuk menyelesaikan pekerjaan. _Controller job_ 
-tidak menjalankan sejumlah Pod atau kontainer apa pun untuk dirinya sendiri. 
-Namun, _controller job_ mengisyaratkan kepada server API untuk  membuat atau 
+Ketika _controller job_ melihat tugas baru, maka _controller_ itu memastikan bahwa,
+di suatu tempat pada klaster kamu, kubelet dalam sekumpulan Node menjalankan
+Pod-Pod dengan jumlah yang benar untuk menyelesaikan pekerjaan. _Controller job_
+tidak menjalankan sejumlah Pod atau kontainer apa pun untuk dirinya sendiri.
+Namun, _controller job_ mengisyaratkan kepada server API untuk  membuat atau
 menghapus Pod. Komponen-komponen lain dalam
 {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
-bekerja berdasarkan informasi baru (adakah Pod-Pod baru untuk menjadwalkan dan 
+bekerja berdasarkan informasi baru (adakah Pod-Pod baru untuk menjadwalkan dan
 menjalankan pekerjan), dan pada akhirnya pekerjaan itu selesai.
 
-Setelah kamu membuat Job baru, status yang diharapkan adalah bagaimana 
-pekerjaan itu bisa selesai. _Controller job_ membuat status pekerjaan saat ini 
-agar mendekati dengan keadaan yang kamu inginkan: membuat Pod yang melakukan 
-pekerjaan yang kamu inginkan untuk Job tersebut, sehingga Job hampir 
+Setelah kamu membuat Job baru, status yang diharapkan adalah bagaimana
+pekerjaan itu bisa selesai. _Controller job_ membuat status pekerjaan saat ini
+agar mendekati dengan keadaan yang kamu inginkan: membuat Pod yang melakukan
+pekerjaan yang kamu inginkan untuk Job tersebut, sehingga Job hampir
 terselesaikan.
 
-_Controller_ juga memperbarui objek yang mengkonfigurasinya. Misalnya: setelah 
-pekerjaan dilakukan untuk Job tersebut, _controller job_ memperbarui objek Job 
+_Controller_ juga memperbarui objek yang mengkonfigurasinya. Misalnya: setelah
+pekerjaan dilakukan untuk Job tersebut, _controller job_ memperbarui objek Job
 dengan menandainya `Finished`.
 
-(Ini hampir sama dengan bagaimana beberapa termostat mematikan lampu untuk 
-mengindikasikan bahwa kamar kamu sekarang sudah berada pada suhu yang kamu 
+(Ini hampir sama dengan bagaimana beberapa termostat mematikan lampu untuk
+mengindikasikan bahwa kamar kamu sekarang sudah berada pada suhu yang kamu
 inginkan).
 
 ### Kontrol Langsung
 
 Berbeda dengan sebuah Job, beberapa dari _controller_ perlu melakukan perubahan
 sesuatu di luar dari klaster kamu.
 
-Sebagai contoh, jika kamu menggunakan kontrol tertutup untuk memastikan apakah 
+Sebagai contoh, jika kamu menggunakan kontrol tertutup untuk memastikan apakah
 cukup {{< glossary_tooltip text="Node" term_id="node" >}}
-dalam kluster kamu, maka _controller_ memerlukan sesuatu di luar klaster saat ini 
+dalam klaster kamu, maka _controller_ memerlukan sesuatu di luar klaster saat ini
 untuk mengatur Node-Node baru apabila dibutuhkan.
 
-_controller_ yang berinteraksi dengan keadaan eksternal dapat menemukan keadaan 
-yang diinginkannya melalui server API, dan kemudian berkomunikasi langsung 
-dengan sistem eksternal untuk membawa keadaan saat ini mendekat keadaan yang 
+_controller_ yang berinteraksi dengan keadaan eksternal dapat menemukan keadaan
+yang diinginkannya melalui server API, dan kemudian berkomunikasi langsung
+dengan sistem eksternal untuk membawa keadaan saat ini mendekat keadaan yang
 diinginkan.
 
-(Sebenarnya ada sebuah [_controller_](https://github.com/kubernetes/autoscaler/) yang melakukan penskalaan node secara 
+(Sebenarnya ada sebuah [_controller_](https://github.com/kubernetes/autoscaler/) yang melakukan penskalaan node secara
 horizontal dalam klaster kamu.
 
 ## Status sekarang berbanding status yang diinginkan {#sekarang-banding-diinginkan}
 
 Kubernetes mengambil pandangan sistem secara _cloud-native_, dan mampu menangani
 perubahan yang konstan.
 
-Klaster kamu dapat mengalami perubahan kapan saja pada saat pekerjaan sedang 
+Klaster kamu dapat mengalami perubahan kapan saja pada saat pekerjaan sedang
 berlangsung dan kontrol tertutup secara otomatis memperbaiki setiap kegagalan.
-Hal ini berarti bahwa, secara potensi, klaster kamu tidak akan pernah mencapai 
+Hal ini berarti bahwa, secara potensi, klaster kamu tidak akan pernah mencapai
 kondisi stabil.
 
-Selama _controller_ dari klaster kamu berjalan dan mampu membuat perubahan yang 
+Selama _controller_ dari klaster kamu berjalan dan mampu membuat perubahan yang
 bermanfaat, tidak masalah apabila keadaan keseluruhan stabil atau tidak.
 
 ## Perancangan
 
-Sebagai prinsip dasar perancangan, Kubernetes menggunakan banyak _controller_ yang 
-masing-masing mengelola aspek tertentu dari keadaan klaster. Yang paling umum, 
-kontrol tertutup tertentu menggunakan salah satu jenis sumber daya 
-sebagai suatu keadaan yang diinginkan, dan memiliki jenis sumber daya yang 
+Sebagai prinsip dasar perancangan, Kubernetes menggunakan banyak _controller_ yang
+masing-masing mengelola aspek tertentu dari keadaan klaster. Yang paling umum,
+kontrol tertutup tertentu menggunakan salah satu jenis sumber daya
+sebagai suatu keadaan yang diinginkan, dan memiliki jenis sumber daya yang
 berbeda untuk dikelola dalam rangka membuat keadaan yang diinginkan terjadi.
 
-Sangat penting untuk memiliki beberapa _controller_ sederhana daripada hanya satu 
-_controller_ saja, dimana satu kumpulan monolitik kontrol tertutup saling 
+Sangat penting untuk memiliki beberapa _controller_ sederhana daripada hanya satu
+_controller_ saja, dimana satu kumpulan monolitik kontrol tertutup saling
 berkaitan satu sama lain. Karena _controller_ bisa saja gagal, sehingga Kubernetes
 dirancang untuk memungkinkan hal tersebut.
 
 Misalnya: _controller_ pekerjaan melacak objek pekerjaan (untuk menemukan
-adanya pekerjaan baru) dan objek Pod (untuk menjalankan pekerjaan tersebut dan 
-kemudian melihat lagi ketika pekerjaan itu sudah selesai). Dalam hal ini yang 
+adanya pekerjaan baru) dan objek Pod (untuk menjalankan pekerjaan tersebut dan
+kemudian melihat lagi ketika pekerjaan itu sudah selesai). Dalam hal ini yang
 lain membuat pekerjaan, sedangkan _controller_ pekerjaan membuat Pod-Pod.
 
 {{< note >}}
-Ada kemungkinan beberapa _controller_ membuat atau memperbarui jenis objek yang 
-sama. Namun di belakang layar, _controller_ Kubernetes memastikan bahwa mereka 
-hanya memperhatikan sumbr daya yang terkait dengan sumber daya yang mereka 
+Ada kemungkinan beberapa _controller_ membuat atau memperbarui jenis objek yang
+sama. Namun di belakang layar, _controller_ Kubernetes memastikan bahwa mereka
+hanya memperhatikan sumbr daya yang terkait dengan sumber daya yang mereka
 kendalikan.
 
-Misalnya, kamu dapat memiliki Deployment dan Job; dimana keduanya akan membuat 
+Misalnya, kamu dapat memiliki Deployment dan Job; dimana keduanya akan membuat
 Pod. _Controller Job_ tidak akan menghapus Pod yang dibuat oleh Deployment kamu,
 karena ada informasi ({{< glossary_tooltip term_id="label" text="labels" >}})
 yang dapat oleh _controller_ untuk membedakan Pod-Pod tersebut.
@@ -156,14 +156,14 @@ bawaan memberikan perilaku inti yang sangat penting.
 
 _Controller Deployment_ dan _controller Job_ adalah contoh dari _controller_ yang
 hadir sebagai bagian dari Kubernetes itu sendiri (_controller_ "bawaan").
-Kubernetes memungkinkan kamu menjalankan _control plane_ yang tangguh, sehingga 
-jika ada _controller_ bawaan yang gagal, maka bagian lain dari _control plane_ akan 
+Kubernetes memungkinkan kamu menjalankan _control plane_ yang tangguh, sehingga
+jika ada _controller_ bawaan yang gagal, maka bagian lain dari _control plane_ akan
 mengambil alih pekerjaan.
 
-Kamu juga dapat menemukan pengontrol yang berjalan di luar _control plane_, untuk 
-mengembangkan lebih jauh Kubernetes. Atau, jika mau, kamu bisa membuat 
+Kamu juga dapat menemukan pengontrol yang berjalan di luar _control plane_, untuk
+mengembangkan lebih jauh Kubernetes. Atau, jika mau, kamu bisa membuat
 _controller_ baru sendiri. Kamu dapat menjalankan _controller_ kamu sendiri sebagai
-satu kumpulan dari beberapa Pod, atau bisa juga sebagai bagian eksternal dari 
+satu kumpulan dari beberapa Pod, atau bisa juga sebagai bagian eksternal dari
 Kubernetes. Manakah yang paling sesuai akan tergantung pada apa yang _controller_
 khusus itu lakukan.
 

Diff for: content/id/docs/concepts/cluster-administration/networking.md

@@ -1,5 +1,5 @@
 ---
-title: Jaringan Kluster
+title: Jaringan Klaster
 content_type: concept
 weight: 50
 ---
@@ -24,7 +24,7 @@ Kubernetes adalah tentang berbagi mesin antar aplikasi. Pada dasarnya,
 saat berbagi mesin harus memastikan bahwa dua aplikasi tidak mencoba menggunakan
 _port_ yang sama. Mengkoordinasikan _port_ di banyak pengembang sangat sulit
 dilakukan pada skala yang berbeda dan memaparkan pengguna ke masalah
-tingkat kluster yang di luar kendali mereka.
+tingkat klaster yang di luar kendali mereka.
 
 Alokasi _port_ yang dinamis membawa banyak komplikasi ke sistem - setiap aplikasi
 harus menganggap _port_ sebagai _flag_, _server_ API harus tahu cara memasukkan
@@ -73,17 +73,17 @@ Detail tentang cara kerja sistem AOS dapat diakses di sini: http://www.apstra.co
 
 ### AWS VPC CNI untuk Kubernetes
 
-[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) menawarkan jaringan AWS _Virtual Private Cloud_ (VPC) terintegrasi untuk kluster Kubernetes. Plugin CNI ini menawarkan _throughput_ dan ketersediaan tinggi, latensi rendah, dan _jitter_ jaringan minimal. Selain itu, pengguna dapat menerapkan jaringan AWS VPC dan praktik keamanan terbaik untuk membangun kluster Kubernetes. Ini termasuk kemampuan untuk menggunakan catatan aliran VPC, kebijakan perutean VPC, dan grup keamanan untuk isolasi lalu lintas jaringan.
+[AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) menawarkan jaringan AWS _Virtual Private Cloud_ (VPC) terintegrasi untuk klaster Kubernetes. Plugin CNI ini menawarkan _throughput_ dan ketersediaan tinggi, latensi rendah, dan _jitter_ jaringan minimal. Selain itu, pengguna dapat menerapkan jaringan AWS VPC dan praktik keamanan terbaik untuk membangun klaster Kubernetes. Ini termasuk kemampuan untuk menggunakan catatan aliran VPC, kebijakan perutean VPC, dan grup keamanan untuk isolasi lalu lintas jaringan.
 
-Menggunakan _plugin_ CNI ini memungkinkan Pod Kubernetes memiliki alamat IP yang sama di dalam Pod seperti yang mereka lakukan di jaringan VPC. CNI mengalokasikan AWS _Elastic Networking Interfaces_ (ENIs) ke setiap node Kubernetes dan menggunakan rentang IP sekunder dari setiap ENI untuk Pod pada Node. CNI mencakup kontrol untuk pra-alokasi ENI dan alamat IP untuk waktu mulai Pod yang cepat dan memungkinkan kluster besar hingga 2.000 Node.
+Menggunakan _plugin_ CNI ini memungkinkan Pod Kubernetes memiliki alamat IP yang sama di dalam Pod seperti yang mereka lakukan di jaringan VPC. CNI mengalokasikan AWS _Elastic Networking Interfaces_ (ENIs) ke setiap node Kubernetes dan menggunakan rentang IP sekunder dari setiap ENI untuk Pod pada Node. CNI mencakup kontrol untuk pra-alokasi ENI dan alamat IP untuk waktu mulai Pod yang cepat dan memungkinkan klaster besar hingga 2.000 Node.
 
 Selain itu, CNI dapat dijalankan bersama [Calico untuk penegakan kebijakan jaringan](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). Proyek AWS VPC CNI adalah _open source_ dengan [dokumentasi di GitHub](https://github.com/aws/amazon-vpc-cni-k8s).
 
 ### Big Cloud Fabric dari Big Switch Networks
 
 [Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) adalah arsitektur jaringan asli layanan cloud, yang dirancang untuk menjalankan Kubernetes di lingkungan cloud pribadi / lokal. Dengan menggunakan SDN fisik & _virtual_ terpadu, Big Cloud Fabric menangani masalah yang sering melekat pada jaringan kontainer seperti penyeimbangan muatan, visibilitas, pemecahan masalah, kebijakan keamanan & pemantauan lalu lintas kontainer.
 
-Dengan bantuan arsitektur multi-penyewa Pod virtual pada Big Cloud Fabric, sistem orkestrasi kontainer seperti Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm akan terintegrasi secara alami bersama dengan sistem orkestrasi VM seperti VMware, OpenStack & Nutanix. Pelanggan akan dapat terhubung dengan aman berapa pun jumlah klusternya dan memungkinkan komunikasi antar penyewa di antara mereka jika diperlukan.
+Dengan bantuan arsitektur multi-penyewa Pod virtual pada Big Cloud Fabric, sistem orkestrasi kontainer seperti Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm akan terintegrasi secara alami bersama dengan sistem orkestrasi VM seperti VMware, OpenStack & Nutanix. Pelanggan akan dapat terhubung dengan aman berapa pun jumlah klasternya dan memungkinkan komunikasi antar penyewa di antara mereka jika diperlukan.
 
 Terbaru ini BCF diakui oleh Gartner sebagai visioner dalam [_Magic Quadrant_](http://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). Salah satu penyebaran BCF Kubernetes di tempat (yang mencakup Kubernetes, DC/OS & VMware yang berjalan di beberapa DC di berbagai wilayah geografis) juga dirujuk [di sini](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/).
 
@@ -113,7 +113,7 @@ Plugin ini dirancang untuk secara langsung mengkonfigurasi dan _deploy_ dalam VP
 
 ### DANM
 
-[DANM] (https://github.com/nokia/danm) adalah solusi jaringan untuk beban kerja telco yang berjalan di kluster Kubernetes. Dibangun dari komponen-komponen berikut:
+[DANM] (https://github.com/nokia/danm) adalah solusi jaringan untuk beban kerja telco yang berjalan di klaster Kubernetes. Dibangun dari komponen-komponen berikut:
 
    * Plugin CNI yang mampu menyediakan antarmuka IPVLAN dengan fitur-fitur canggih
    * Modul IPAM built-in dengan kemampuan mengelola dengan jumlah banyak, _cluster-wide_, _discontinous_ jaringan L3 dan menyediakan skema dinamis, statis, atau tidak ada permintaan skema IP
@@ -129,7 +129,7 @@ Dengan _toolset_ ini, DANM dapat memberikan beberapa antarmuka jaringan yang ter
 
 ### Google Compute Engine (GCE)
 
-Untuk skrip konfigurasi kluster Google Compute Engine, [perutean lanjutan](https://cloud.google.com/vpc/docs/routes) digunakan untuk menetapkan setiap VM _subnet_ (standarnya adalah `/24` - 254 IP). Setiap lalu lintas yang terikat untuk _subnet_ itu akan dialihkan langsung ke VM oleh _fabric_ jaringan GCE. Ini adalah tambahan untuk alamat IP "utama" yang ditugaskan untuk VM, yang NAT'ed untuk akses internet keluar. Sebuah linux _bridge_ (disebut `cbr0`) dikonfigurasikan untuk ada pada subnet itu, dan diteruskan ke _flag_ `-bridge` milik docker.
+Untuk skrip konfigurasi klaster Google Compute Engine, [perutean lanjutan](https://cloud.google.com/vpc/docs/routes) digunakan untuk menetapkan setiap VM _subnet_ (standarnya adalah `/24` - 254 IP). Setiap lalu lintas yang terikat untuk _subnet_ itu akan dialihkan langsung ke VM oleh _fabric_ jaringan GCE. Ini adalah tambahan untuk alamat IP "utama" yang ditugaskan untuk VM, yang NAT'ed untuk akses internet keluar. Sebuah linux _bridge_ (disebut `cbr0`) dikonfigurasikan untuk ada pada subnet itu, dan diteruskan ke _flag_ `-bridge` milik docker.
 
 Docker dimulai dengan: