From 39fe327423f908eeecceafe410dfb1b62dd0d906 Mon Sep 17 00:00:00 2001 From: irvifa <7439590+irvifa@users.noreply.github.com> Date: Mon, 16 Dec 2019 20:11:37 +0700 Subject: [PATCH] Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130) --- content/id/docs/concepts/_index.md | 24 ++-- .../concepts/architecture/cloud-controller.md | 14 +-- .../architecture/master-node-communication.md | 30 ++--- .../id/docs/concepts/architecture/nodes.md | 26 ++--- .../concepts/cluster-administration/_index.md | 2 +- .../concepts/cluster-administration/addons.md | 2 +- .../cluster-administration/certificates.md | 8 +- .../cluster-administration/cloud-providers.md | 10 +- .../cluster-administration-overview.md | 34 +++--- .../controller-metrics.md | 4 +- .../cluster-administration/federation.md | 104 +++++++++--------- .../cluster-administration/logging.md | 22 ++-- .../manage-deployment.md | 2 +- .../cluster-administration/proxies.md | 6 +- .../concepts/configuration/assign-pod-node.md | 16 +-- .../organize-cluster-access-kubeconfig.md | 44 ++++---- .../configuration/taint-and-toleration.md | 4 +- .../container-environment-variables.md | 4 +- .../docs/concepts/containers/runtime-class.md | 8 +- .../extend-kubernetes/extend-cluster.md | 22 ++-- .../poseidon-firmament-alternate-scheduler.md | 12 +- .../id/docs/concepts/overview/components.md | 26 ++--- .../docs/concepts/overview/kubernetes-api.md | 4 +- .../declarative-config.md | 2 +- .../imperative-command.md | 2 +- .../imperative-config.md | 2 +- .../working-with-objects/common-labels.md | 2 +- .../kubernetes-objects.md | 8 +- .../working-with-objects/namespaces.md | 10 +- .../working-with-objects/object-management.md | 8 +- .../concepts/policy/pod-security-policy.md | 8 +- .../connect-applications-service.md | 26 ++--- .../services-networking/dns-pod-service.md | 16 +-- .../ingress-controllers.md | 8 +- .../concepts/services-networking/ingress.md | 16 +-- .../services-networking/network-policies.md | 8 +- .../concepts/services-networking/service.md | 46 ++++---- .../concepts/storage/dynamic-provisioning.md | 22 ++-- .../concepts/storage/persistent-volumes.md | 40 +++---- .../docs/concepts/storage/storage-classes.md | 36 +++--- .../docs/concepts/storage/storage-limits.md | 2 +- .../docs/concepts/storage/volume-snapshots.md | 10 +- content/id/docs/concepts/storage/volumes.md | 30 ++--- .../controllers/garbage-collection.md | 4 +- .../workloads/controllers/replicaset.md | 4 +- .../workloads/controllers/statefulset.md | 8 +- .../workloads/controllers/ttlafterfinished.md | 6 +- .../concepts/workloads/pods/disruptions.md | 68 ++++++------ .../workloads/pods/init-containers.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 2 +- .../concepts/workloads/pods/pod-overview.md | 10 +- .../id/docs/concepts/workloads/pods/pod.md | 7 +- .../docs/concepts/workloads/pods/podpreset.md | 6 +- content/id/docs/home/_index.md | 4 +- content/id/docs/reference/glossary/etcd.md | 6 +- content/id/docs/reference/glossary/ingress.md | 4 +- .../docs/reference/glossary/kube-apiserver.md | 2 +- content/id/docs/reference/glossary/kubelet.md | 4 +- content/id/docs/reference/glossary/uid.md | 2 +- content/id/docs/setup/_index.md | 24 ++-- .../id/docs/templates/feature-state-alpha.txt | 2 +- content/id/docs/tutorials/_index.md | 4 +- content/id/docs/tutorials/hello-minikube.md | 12 +- .../tutorials/kubernetes-basics/_index.html | 4 +- .../id/examples/policy/restricted-psp.yaml | 2 +- 65 files changed, 459 insertions(+), 458 deletions(-) diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md index dae11dc036..31a1404f48 100644 --- a/content/id/docs/concepts/_index.md +++ b/content/id/docs/concepts/_index.md @@ -8,7 +8,7 @@ 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 +yang digunakan Kubernetes untuk merepresentasikan klaster kamu, serta membantu kamu belajar lebih dalam bagaimana cara kerja Kubernetes. {{% /capture %}} @@ -22,7 +22,7 @@ Untuk menggunakan Kubernetes, kamu menggunakan obyek-obyek *Kubernetes API* untu 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 klaster untuk membuat atau mengubah *state* yang kamu inginkan. Setelah kamu membuat *state* yang kamu inginkan, *Control Plane* Kubernetes @@ -31,10 +31,10 @@ menggunakan `Pod Lifecycle Event Generator (PLEG)` untuk mengubah 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: +`process` yang dijalankan di klaster: -* **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*: +* **Kubernetes Master** terdiri dari tiga buah *process* yang dijalankan pada sebuah *node* di klaster 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 klaster 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*. @@ -42,7 +42,7 @@ suatu aplikasi, dan lain sebagainya. *Control Plane* Kubernetes terdiri dari sek 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. +kamu sediakan, serta beberapa informasi lain terkait apa yang sedang klaster 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. @@ -66,10 +66,10 @@ 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* +mengatur bagaimana Kubernetes berkomunikasi dengan klaster 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 +apabila terdapat perubahan pada klaster kamu dan mengubah *state* saat ini agar sesuai dengan *state* yang diinginkan. Contohnya, ketika kamu menggunakan API Kubernetes untuk membuat sebuah *Deployment*, @@ -80,15 +80,15 @@ pada *node*, dengan kata lain mengubah *state* saat ini agar sesuai dengan *stat ### Master -Master Kubernetes bertanggung jawab untuk memelihara *state* yang diinginkan pada kluster kamu. +Master Kubernetes bertanggung jawab untuk memelihara *state* yang diinginkan pada klaster kamu. Ketika kamu berinteraksi dengan Kubernetes, misalnya saja menggunakan perangkat `kubectl`, -kamu berkomunikasi dengan *master* kluster Kubernetes kamu. +kamu berkomunikasi dengan *master* klaster 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/). +> "master" merujuk pada tiga buah *process* yang dijalankan pada sebuah *node* pada klaster 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 +*Node* di dalam klaster Kubernetes adalah mesin (mesin virtual maupun fisik) yang menjalankan aplikasi kamu. Master mengontrol setiap node; kamu akan jarang berinteraksi dengan *node* secara langsung. diff --git a/content/id/docs/concepts/architecture/cloud-controller.md b/content/id/docs/concepts/architecture/cloud-controller.md index 7c6d0feb4d..03bc1c1f6a 100644 --- a/content/id/docs/concepts/architecture/cloud-controller.md +++ b/content/id/docs/concepts/architecture/cloud-controller.md @@ -5,13 +5,13 @@ weight: 30 --- {{% capture overview %}} -Konsep _Cloud Controller Manager_/CCM (jangan tertukar dengan program biner kube-controller-manager) awalnya dibuat untuk memungkinkan kode vendor _cloud_ spesifik dan kode inti Kubernetes untuk berkembang secara independen satu sama lainnya. CCM berjalan bersama dengan komponen Master lainnya seperti Kubernetes Controller Manager, API Server, dan Scheduler. CCM juga dapat dijalankan sebagai Kubernetes Addon (tambahan fungsi terhadap Kubernetes), yang akan berjalan di atas kluster Kubernetes. +Konsep _Cloud Controller Manager_/CCM (jangan tertukar dengan program biner kube-controller-manager) awalnya dibuat untuk memungkinkan kode vendor _cloud_ spesifik dan kode inti Kubernetes untuk berkembang secara independen satu sama lainnya. CCM berjalan bersama dengan komponen Master lainnya seperti Kubernetes Controller Manager, API Server, dan Scheduler. CCM juga dapat dijalankan sebagai Kubernetes Addon (tambahan fungsi terhadap Kubernetes), yang akan berjalan di atas klaster Kubernetes. Desain CCM didasarkan pada mekanisme _plugin_ yang memungkinkan penyedia layanan _cloud_ untuk berintegrasi dengan Kubernetes dengan mudah dengan menggunakan _plugin_. Sudah ada rencana untuk pengenalan penyedia layanan _cloud_ baru pada Kubernetes, dan memindahkan penyedia layanan _cloud_ yang sudah ada dari model yang lama ke model CCM. Dokumen ini mendiskusikan konsep di balik CCM dan mendetail fungsi-fungsinya. -Berikut adalah arsitektur sebuah kluster Kubernetes tanpa CCM: +Berikut adalah arsitektur sebuah klaster Kubernetes tanpa CCM: ![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png) @@ -69,20 +69,20 @@ Kebanyakan fungsi CCM diturunkan dari KCM. Seperti yang telah disebutkan pada ba #### Node Controller -Node Controller bertugas untuk menyiapkan sebuah node dengan cara mengambil informasi node-node yang berjalan di dalam kluster dari penyedia layanan _cloud_. Node Controller melakukan fungsi-fungsi berikut: +Node Controller bertugas untuk menyiapkan sebuah node dengan cara mengambil informasi node-node yang berjalan di dalam klaster dari penyedia layanan _cloud_. Node Controller melakukan fungsi-fungsi berikut: 1. Menyiapkan sebuah node dengan memberi label _zone_/_region_ yang spesifik pada _cloud_. 2. Menyiapkan sebuah node dengan informasi _instance_ yang spesifik _cloud_ , misalnya tipe dan ukurannya. 3. Mendapatkan alamat jaringan dan _hostname_ milik node tersebut. -4. Dalam hal sebuah node menjadi tidak responsif, memeriksa _cloud_ untuk melihat apakah node tersebut telah dihapus dari _cloud_. Juga, menghapus objek Node tersebut dari kluster Kubernetes, jika node tersebut telah dihapus dari _cloud_. +4. Dalam hal sebuah node menjadi tidak responsif, memeriksa _cloud_ untuk melihat apakah node tersebut telah dihapus dari _cloud_. Juga, menghapus objek Node tersebut dari klaster Kubernetes, jika node tersebut telah dihapus dari _cloud_. #### Route Controller -Route Controller bertugas mengkonfigurasi rute jaringan di dalam _cloud_ secara sesuai agar Container pada node-node yang berbeda di dalam kluster Kubernetes dapat berkomunikasi satu sama lain. Route Controller hanya berlaku untuk kluster yang berjalan pada Google Compute Engine (GCE) di penyedia layanan _cloud_ GCP. +Route Controller bertugas mengkonfigurasi rute jaringan di dalam _cloud_ secara sesuai agar Container pada node-node yang berbeda di dalam klaster Kubernetes dapat berkomunikasi satu sama lain. Route Controller hanya berlaku untuk klaster yang berjalan pada Google Compute Engine (GCE) di penyedia layanan _cloud_ GCP. #### Service Controller -Service Controller bertugas memantau terjadinya operasi `create`, `update`, dan `delete` pada Service. Berdasarkan keadaan terkini Service-service pada kluster Kubernetes, Service Controller mengkonfigurasi _load balancer_ spesifik _cloud_ (seperti ELB, Google LB, atau Oracle Cloud Infrastructure LB) agar sesuai dengan keadaan Service-service pada kluster Kubernetes. Sebagai tambahan, Service Controller juga memastikan bahwa _service backend_ (target dari _load balancer_ yang bersangkutan) dari _load balancer cloud_ tersebut berada dalam kondisi terkini. +Service Controller bertugas memantau terjadinya operasi `create`, `update`, dan `delete` pada Service. Berdasarkan keadaan terkini Service-service pada klaster Kubernetes, Service Controller mengkonfigurasi _load balancer_ spesifik _cloud_ (seperti ELB, Google LB, atau Oracle Cloud Infrastructure LB) agar sesuai dengan keadaan Service-service pada klaster Kubernetes. Sebagai tambahan, Service Controller juga memastikan bahwa _service backend_ (target dari _load balancer_ yang bersangkutan) dari _load balancer cloud_ tersebut berada dalam kondisi terkini. ### 2. Kubelet @@ -230,7 +230,7 @@ Penyedia layanan cloud berikut telah mengimplementasikan CCM: * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) * [Linode](https://github.com/linode/linode-cloud-controller-manager) -## Administrasi Kluster +## Administrasi Klaster Petunjuk lengkap untuk mengkonfigurasi dan menjalankan CCM disediakan [di sini](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager). diff --git a/content/id/docs/concepts/architecture/master-node-communication.md b/content/id/docs/concepts/architecture/master-node-communication.md index 75a6cecc05..fcc9f66eed 100644 --- a/content/id/docs/concepts/architecture/master-node-communication.md +++ b/content/id/docs/concepts/architecture/master-node-communication.md @@ -6,23 +6,23 @@ weight: 20 {{% capture overview %}} -Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara kluster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja. -Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam kluster. -Hal ini cukup penting, karena kluster bisa saja berjalan pada jaringan tak terpercaya (untrusted network), ataupun melalui alamat-alamat IP publik pada penyedia cloud. +Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan master yang sebenarnya hanya berhubungan dengan apiserver saja. +Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam klaster. +Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpercaya (untrusted network), ataupun melalui alamat-alamat IP publik pada penyedia cloud. {{% /capture %}} {{% capture body %}} -## Kluster menuju Master +## Klaster menuju Master -Semua jalur komunikasi dari kluster menuju master diterminasi pada apiserver. +Semua jalur komunikasi dari klaster 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. +Untuk instalasi klaster 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). -Node-node seharusnya disediakan dengan public root certificate untuk kluster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial client yang valid. +Node-node seharusnya disediakan dengan public root certificate untuk klaster, sehingga node-node tersebut bisa terhubung secara aman ke apiserver dengan kredensial client yang valid. Contohnya, untuk instalasi GKE dengan standar konfigurasi, kredensial client harus diberikan kepada kubelet dalam bentuk client certificate. Lihat [menghidupkan TLS kubelet](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) untuk menyediakan client certificate untuk kubelet secara otomatis. @@ -31,14 +31,14 @@ Dengan ini, Kubernetes memasukkan public root certificate dan bearer t Kubernetes service (di dalam semua namespace) diatur dengan sebuah alamat IP virtual. Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju endpoint HTTPS dari apiserver. -Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam kluster. -Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari kluster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman. -Dan juga, kluster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (untrusted). +Komponen-komponen master juga berkomunikasi dengan apiserver melalui port yang aman di dalam klaster. +Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menuju master sudah terhubung dengan aman. +Dan juga, klaster dan master bisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (untrusted). -## Master menuju Kluster +## Master menuju Klaster -Ada dua jalur komunikasi utama dari master (apiserver) menuju kluster. -Pertama, dari apiserver ke process kubelet yang berjalan pada setiap node di dalam kluster. +Ada dua jalur komunikasi utama dari master (apiserver) menuju klaster. +Pertama, dari apiserver ke process kubelet yang berjalan pada setiap node di dalam klaster. Kedua, dari apiserver ke setiap node, pod, ataupun service melalui fungsi proxy pada apiserver. ### Apiserver menuju kubelet @@ -67,8 +67,8 @@ Koneksi ini **tidak aman** untuk dilalui pada jaringan publik dan/atau tak terpe ### Tunnel SSH -Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Kluster. -Dengan ini, apiserver menginisiasi sebuah tunnel SSH untuk setiap node di dalam kluster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui tunnel tesebut. +Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi Master -> Klaster. +Dengan ini, apiserver menginisiasi sebuah tunnel SSH untuk setiap node di dalam klaster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui tunnel tesebut. Tunnel ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada. Tunnel SSH saat ini sudah usang (deprecated), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan. diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md index 8019d4ef2d..75875425c0 100644 --- a/content/id/docs/concepts/architecture/nodes.md +++ b/content/id/docs/concepts/architecture/nodes.md @@ -7,7 +7,7 @@ weight: 10 {{% capture overview %}} Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan `minion`. -Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari kluster-nya. +Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya. Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak [pod](/docs/concepts/workloads/pods/pod/) dan diatur oleh komponen-komponen yang dimiliki oleh master. Servis-servis di dalam sebuah node terdiri dari [runtime kontainer](/docs/concepts/overview/components/#node-components), kubelet dan kube-proxy. Untuk lebih detail, lihat dokumentasi desain arsitektur pada [Node Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node). @@ -33,8 +33,8 @@ Masing-masing bagian dijelaskan secara rinci di bawah ini. Penggunaan field-field ini bergantung pada penyedia layanan cloud ataupun konfigurasi bare metal yang kamu punya. * HostName: Merupakan hostname yang dilaporkan oleh kernel node. Dapat diganti melalui parameter `--hostname-override` pada kubelet. -* ExternalIP: Biasanya merupakan alamat IP pada node yang punya route eksternal (bisa diakses dari luar kluster). -* InternalIP: Biasanya merupakan alamat IP pada node yang hanya punya route di dalam kluster. +* ExternalIP: Biasanya merupakan alamat IP pada node yang punya route eksternal (bisa diakses dari luar klaster). +* InternalIP: Biasanya merupakan alamat IP pada node yang hanya punya route di dalam klaster. ### Condition @@ -68,8 +68,8 @@ Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai 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. -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. +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 klaster. +Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster 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. Pada versi 1.12, fitur `TaintNodesByCondition` telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat [taints](/docs/concepts/configuration/taint-and-toleration/) yang merepresentasikan conditions. @@ -93,7 +93,7 @@ Informasi ini dikumpulkan oleh Kubelet di dalam node. ## Manajemen -Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar kluster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya. +Tidak seperti [pod](/docs/concepts/workloads/pods/pod/) dan [service](/docs/concepts/services-networking/service/), sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya. Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat. Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak. Contohnya, jika kamu mencoba untuk membuat node dari konten berikut: @@ -112,7 +112,7 @@ Contohnya, jika kamu mencoba untuk membuat node dari konten berikut: ``` Kubernetes membuat sebuah obyek node secara internal (representasinya), dan melakukan validasi terhadap node. Validasi dilakukan dengan memeriksa kondisi kesehatan node (health checking), berdasarkan field `metadata.name`. Jika node valid -- terjadi saat semua servis yang diperlukan sudah jalan -- maka node diperbolehkan untuk menjalankan sebuah pod. -Namun jika tidak valid, node tersebut akan dihiraukan untuk aktivitas apapun yang berhubungan dengan kluster, sampai telah menjadi valid. +Namun jika tidak valid, node tersebut akan dihiraukan untuk aktivitas apapun yang berhubungan dengan klaster, sampai telah menjadi valid. {{< note >}} Kubernetes tetap menyimpan obyek untuk node yang tidak valid, dan terus memeriksa apakah node telah menjadi valid atau belum. @@ -145,21 +145,21 @@ Semua node lease diperbarui sesering mungkin, sedangkan `NodeStatus` dila Karena node lease jauh lebih ringan daripada `NodeStatus`, fitur ini membuat heartbeat dari node jauh lebih murah secara signifikan dari sudut pandang skalabilitas dan performa. Di Kubernetes 1.4, kami telah memperbarui logic dari kontroler node supaya lebih baik dalam menangani kasus saat banyak sekali node yang tidak bisa terhubung dengan master (contohnya, karena master punya masalah jaringan). -Mulai dari 1.4, kontroler node melihat state dari semua node di dalam kluster, saat memutuskan untuk melakukan eviction pada pod. +Mulai dari 1.4, kontroler node melihat state dari semua node di dalam klaster, saat memutuskan untuk melakukan eviction pada pod. Pada kasus kebanyakan, kontroler node membatasi rate eviction menjadi `--node-eviction-rate` (default-nya 0.1) per detik. Artinya, kontroler node tidak akan melakukan eviction pada pod lebih dari 1 node per 10 detik. Perlakuan eviction pada node berubah ketika sebuah node menjadi tidak sehat (unhealthy) di dalam suatu zona availability. Kontroler node memeriksa berapa persentase node di dalam zona tersebut yang tidak sehat (saat `NodeReady condition` menjadi `ConditionUnknown` atau `ConditionFalse`) pada saat yang bersamaan. -Jika persentase node yang tidak sehat bernilai `--unhealthy-zone-threshold` (default-nya 0.55), maka rate eviction berkurang: untuk ukuran kluster yang kecil (saat jumlahnya lebih kecil atau sama dengan jumlah node `--large-cluster-size-threshold` - default-nya 50), maka eviction akan berhenti dilakukan. +Jika persentase node yang tidak sehat bernilai `--unhealthy-zone-threshold` (default-nya 0.55), maka rate eviction berkurang: untuk ukuran klaster yang kecil (saat jumlahnya lebih kecil atau sama dengan jumlah node `--large-cluster-size-threshold` - default-nya 50), maka eviction akan berhenti dilakukan. Jika masih besar jumlahnya, rate eviction dikurangi menjadi `--secondary-node-eviction-rate` (default-nya 0.01) per detik. Alasan kenapa hal ini diimplementasi untuk setiap zona availability adalah karena satu zona bisa saja terputus dari master, saat yang lainnya masih terhubung. -Jika kluster tidak menjangkau banyak zona availability yang disediakan oleh penyedia cloud, maka hanya ada satu zona (untuk semua node di dalam kluster). +Jika klaster tidak menjangkau banyak zona availability yang disediakan oleh penyedia cloud, maka hanya ada satu zona (untuk semua node di dalam klaster). Alasan utama untuk menyebarkan node pada banyak zona availability adalah supaya workload dapat dipindahkan ke zona sehat (healthy) saat suatu zona mati secara menyeluruh. Kemudian, jika semua node di dalam suatu zona menjadi tidak sehat (unhealthy), maka kontroler node melakukan eviction pada rate normal `--node-eviction-rate`. -Kasus khusus, ketika seluruh zona tidak ada satupun sehat (tidak ada node yang sehat satupun di dalam kluster). +Kasus khusus, ketika seluruh zona tidak ada satupun sehat (tidak ada node yang sehat satupun di dalam klaster). Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan menghentikan semua eviction sampai jaringan terhubung kembali. Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints. @@ -181,14 +181,14 @@ Kubelet memulai registrasi diri (self-registration) dengan opsi-opsi beri - `--register-node` - Registrasi secara otomatis pada API server. - `--register-with-taints` - Registrasi node dengan daftar taints (dipisahkan oleh koma `=:`). No-op jika `register-node` bernilai false. - `--node-ip` - Alamat IP dari node dimana kubelet berjalan. - - `--node-labels` - Label-label untuk ditambahkan saat melakukan registrasi untuk node di dalam kluster (lihat label yang dibatasi secara paksa oleh [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) untuk 1.13+). + - `--node-labels` - Label-label untuk ditambahkan saat melakukan registrasi untuk node di dalam klaster (lihat label yang dibatasi secara paksa oleh [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) untuk 1.13+). - `--node-status-update-frequency` - Menentukan seberapa sering kubelet melaporkan status pada master. Ketika mode [otorisasi Node](/docs/reference/access-authn-authz/node/) dan [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction) diaktifkan, semua kubelet hanya punya otoritas untuk membuat/modifikasi resource Node masing-masing. #### Administrasi Node secara Manual -Seorang admin kluster dapat membuat dan memodifikasi obyek node. +Seorang admin klaster dapat membuat dan memodifikasi obyek node. Jika admin ingin untuk membuat obyek node secara manual, atur argument `--register-node=false` pada kubelet. diff --git a/content/id/docs/concepts/cluster-administration/_index.md b/content/id/docs/concepts/cluster-administration/_index.md index 1b8b355878..a4d07b0159 100644 --- a/content/id/docs/concepts/cluster-administration/_index.md +++ b/content/id/docs/concepts/cluster-administration/_index.md @@ -1,5 +1,5 @@ --- -title: "Administrasi Kluster" +title: "Administrasi Klaster" weight: 100 --- diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md index 532fa0cf49..0121182e3f 100644 --- a/content/id/docs/concepts/cluster-administration/addons.md +++ b/content/id/docs/concepts/cluster-administration/addons.md @@ -25,7 +25,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) menggabungkan Flannel dan Calico, menyediakan jaringan serta *policy* jaringan. * [Cilium](https://github.com/cilium/cilium) merupakan *plugin* jaringan L3 dan *policy* jaringan yang dapat menjalankan *policy* HTTP/API/L7 secara transparan. Mendukung mode *routing* maupun *overlay/encapsulation*. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus. -* [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk kluster dengan kubeadm maupun non-kubeadm. +* [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), yang berbasis dari [Tungsten Fabric](https://tungsten.io), merupakan sebuah proyek *open source* yang menyediakan virtualisasi jaringan *multi-cloud* serta platform manajemen *policy*. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan *bare metal*. * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) merupakan penyedia jaringan *overlay* yang dapat digunakan pada Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes. diff --git a/content/id/docs/concepts/cluster-administration/certificates.md b/content/id/docs/concepts/cluster-administration/certificates.md index 8dc7ee5813..dca5daec7a 100644 --- a/content/id/docs/concepts/cluster-administration/certificates.md +++ b/content/id/docs/concepts/cluster-administration/certificates.md @@ -16,7 +16,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`. ### easyrsa -**easyrsa** dapat digunakan untuk menghasilkan sertifikat kluster kamu secara manual. +**easyrsa** dapat digunakan untuk menghasilkan sertifikat klaster kamu secara manual. 1. Unduh, buka paket, dan inisialisasi versi tambal easyrsa3. @@ -54,7 +54,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`. ### openssl -**openssl** secara manual dapat menghasilkan sertifikat untuk kluster kamu. +**openssl** secara manual dapat menghasilkan sertifikat untuk klaster kamu. 1. Hasilkan ca.key dengan 2048bit: @@ -68,7 +68,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`. 1. Buat _file_ konfigurasi untuk menghasilkan _Certificate Signing Request_ (CSR). Pastikan untuk mengganti nilai yang ditandai dengan kurung sudut (mis. ``) dengan nilai sebenarnya sebelum menyimpan ke _file_ (mis. `csr.conf`). - Perhatikan bahwa nilai `MASTER_CLUSTER_IP` adalah layanan IP kluster untuk + Perhatikan bahwa nilai `MASTER_CLUSTER_IP` adalah layanan IP klaster untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama _domain_ DNS _default_. @@ -184,7 +184,7 @@ Terakhir, tambahkan parameter yang sama ke dalam parameter mulai _server_ API. 1. Buat _file_ konfigurasi JSON untuk menghasilkan kunci dan sertifikat untuk API _server_, misalnya, `server-csr.json`. Pastikan untuk mengganti nilai dalam kurung sudut dengan nilai sebenarnya yang ingin kamu gunakan. `MASTER_CLUSTER_IP` adalah layanan - kluster IP untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. + klaster IP untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya. Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama _domain_ DNS _default_. diff --git a/content/id/docs/concepts/cluster-administration/cloud-providers.md b/content/id/docs/concepts/cluster-administration/cloud-providers.md index c88531af41..a130610fad 100644 --- a/content/id/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/id/docs/concepts/cluster-administration/cloud-providers.md @@ -11,7 +11,7 @@ Laman ini akan menjelaskan bagaimana cara mengelola Kubernetes yang berjalan pad {{% capture body %}} ### Kubeadm -[Kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) merupakan salah satu cara yang banyak digunakan untuk membuat kluster Kubernetes. +[Kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) merupakan salah satu cara yang banyak digunakan untuk membuat klaster Kubernetes. Kubeadm memiliki beragam opsi untuk mengatur konfigurasi spesifik untuk penyedia layanan cloud. Salah satu contoh yang biasa digunakan pada penyedia cloud *in-tree* yang dapat diatur dengan kubeadm adalah sebagai berikut: ```yaml @@ -297,7 +297,7 @@ dan harus berada pada bagian `[Router]` dari *file* `cloud.conf`: * `router-id` (Opsional): Jika Neutron pada *underlying cloud* mendukung ekstensi `extraroutes` maka gunakan `router-id` untuk menentukan router mana yang akan ditambahkan rute di dalamnya. - Router yang dipilih harus menjangkau jaringan privat tempat *node* kluster berada + Router yang dipilih harus menjangkau jaringan privat tempat *node* klaster berada (biasanya hanya ada satu jaringan *node*, dan nilai ini harus nilai dari *default* router pada jaringan *node*). Nilai ini dibutuhkan untuk dapat menggunakan [kubenet] pada OpenStack. @@ -330,14 +330,14 @@ Parameter `--hostname-override` diabaikan oleh penyedia layanan cloud VSphere. ## IBM Cloud Kubernetes Service ### Node Komputasi -Saat menggunakan layanan IBM Cloud Kubernetes Service, kamu dapat membuat kluster yang terdiri dari campuran antara mesin virtual dan fisik (*bare metal*) sebagai *node* di *single zone* atau *multiple zones* pada satu region. Untuk informasi lebih lanjut, lihat [Perencanaan kluster dan pengaturan worker node](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). +Saat menggunakan layanan IBM Cloud Kubernetes Service, kamu dapat membuat klaster yang terdiri dari campuran antara mesin virtual dan fisik (*bare metal*) sebagai *node* di *single zone* atau *multiple zones* pada satu region. Untuk informasi lebih lanjut, lihat [Perencanaan klaster dan pengaturan worker node](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). Nama dari objek Kubernetes Node yaitu alamat IP privat dari IBM Cloud Kubernetes Service *worker node instance*. ### Jaringan -Penyedia layanan IBM Cloud Kubernetes Service menyediakan VLAN untuk membuat jaringan node yang terisolasi dengan kinerja tinggi. Kamu juga dapat membuat *custom firewall* dan *policy* jaringan Calico untuk menambah lapisan perlindungan ekstra bagi kluster kamu, atau hubungkan kluster kamu dengan *on-prem* data center via VPN. Untuk informasi lebih lanjut, lihat [Perencanaan jaringan privat dan in-cluster](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster). +Penyedia layanan IBM Cloud Kubernetes Service menyediakan VLAN untuk membuat jaringan node yang terisolasi dengan kinerja tinggi. Kamu juga dapat membuat *custom firewall* dan *policy* jaringan Calico untuk menambah lapisan perlindungan ekstra bagi klaster kamu, atau hubungkan klaster kamu dengan *on-prem* data center via VPN. Untuk informasi lebih lanjut, lihat [Perencanaan jaringan privat dan in-cluster](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster). -Untuk membuka aplikasi ke publik atau di dalam kluster, kamu dapat menggunakan NodePort, LoadBalancer, atau Ingress. Kamu juga dapat menyesuaikan aplikasi *load balancer* Ingress dengan anotasi. Untuk informasi lebih lanjut, lihat [Perencanaan untuk membuka aplikasi dengan jaringan eksternal](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning). +Untuk membuka aplikasi ke publik atau di dalam klaster, kamu dapat menggunakan NodePort, LoadBalancer, atau Ingress. Kamu juga dapat menyesuaikan aplikasi *load balancer* Ingress dengan anotasi. Untuk informasi lebih lanjut, lihat [Perencanaan untuk membuka aplikasi dengan jaringan eksternal](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning). ### Penyimpanan Penyedia layanan IBM Cloud Kubernetes Service memanfaatkan Kubernetes-native *persistent volumes* agar pengguna dapat melakukan *mount* *file*, block, dan penyimpanan objek cloud ke aplikasi mereka. Kamu juga dapat menggunakan *database-as-a-service* dan *add-ons* pihak ketiga sebagai penyimpanan *persistent* untuk data kamu. Untuk informasi lebih lanjut, lihat [Perencanaan penyimpanan persistent yang selalu tersedia (*highly available*)](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning). diff --git a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md index fed107530e..67a6c36588 100644 --- a/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/id/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -2,43 +2,43 @@ reviewers: - davidopp - lavalamp -title: Ikhtisar Administrasi Kluster +title: Ikhtisar Administrasi Klaster content_template: templates/concept weight: 10 --- {{% capture overview %}} -Ikhtisar administrasi kluster ini ditujukan untuk siapapun yang akan membuat atau mengelola kluster Kubernetes. +Ikhtisar administrasi klaster ini ditujukan untuk siapapun yang akan membuat atau mengelola klaster Kubernetes. Diharapkan untuk memahami beberapa [konsep](/docs/concepts/) dasar Kubernetes sebelumnya. {{% /capture %}} {{% capture body %}} -## Perencanaan Kluster +## Perencanaan Klaster -Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tentang bagaimana merencanakan, mengatur dan mengonfigurasi kluster Kubernetes. Solusi yang akan dipaparkan di bawah ini disebut *distro*. +Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tentang bagaimana merencanakan, mengatur dan mengonfigurasi klaster Kubernetes. Solusi yang akan dipaparkan di bawah ini disebut *distro*. Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan: - - Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah kluster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu. - - **Jika kamu merencanakan kluster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [kluster pada *multiple zone*](/docs/concepts/cluster-administration/federation/). - - Apakah kamu akan menggunakan **Kubernetes kluster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klustermu**? - - Apakah klustermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung kluster hibrid. Sebagai gantinya, kamu dapat membuat beberapa kluster. + - Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu. + - **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/). + - Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**? + - Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster. - **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai. - Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**? - - Apakah kamu **hanya ingin mencoba kluster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan. - - Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah kluster. + - Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan. + - Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster. Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji dengan versi terkini dari Kubernetes. -## Mengelola Kluster +## Mengelola Klaster -* [Mengelola kluster](/docs/tasks/administer-cluster/cluster-management/) akan menjabarkan beberapa topik terkait *lifecycle* dari kluster: membuat kluster baru, melakukan *upgrade* pada *node master* dan *worker*, melakukan pemeliharaan *node* (contoh: *upgrade* kernel), dan melakukan *upgrade* versi Kubernetes API pada kluster yang sedang berjalan. +* [Mengelola klaster](/docs/tasks/administer-cluster/cluster-management/) akan menjabarkan beberapa topik terkait *lifecycle* dari klaster: membuat klaster baru, melakukan *upgrade* pada *node master* dan *worker*, melakukan pemeliharaan *node* (contoh: *upgrade* kernel), dan melakukan *upgrade* versi Kubernetes API pada klaster yang sedang berjalan. * Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/). -* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* kluster. +* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster. -## Mengamankan Kluster +## Mengamankan Klaster * [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*. @@ -52,7 +52,7 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den * [Menggunakan *Admission Controllers*](/docs/reference/access-authn-authz/admission-controllers/) akan menjelaskan *plug-in* yang akan melakukan intersep permintaan sebelum menuju ke server Kubernetes API, setelah autentikasi dan otorisasi dilakukan. -* [Menggunakan Sysctls pada Kluster Kubernetes](/docs/concepts/cluster-administration/sysctl-cluster/) akan menjabarkan tentang cara menggunakan perintah `sysctl` pada *command-line* untuk mengatur parameter kernel. +* [Menggunakan Sysctls pada Klaster Kubernetes](/docs/concepts/cluster-administration/sysctl-cluster/) akan menjabarkan tentang cara menggunakan perintah `sysctl` pada *command-line* untuk mengatur parameter kernel. * [Audit](/docs/tasks/debug-application-cluster/audit/) akan menjelaskan bagaimana cara berinteraksi dengan log audit Kubernetes. @@ -61,11 +61,11 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den * [TLS *bootstrapping*](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) * [Autentikasi/Otorisasi Kubelet](/docs/admin/kubelet-authentication-authorization/) -## Layanan Tambahan Kluster +## Layanan Tambahan Klaster * [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes. -* [*Logging* dan *Monitoring* Aktivitas Kluster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. +* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya. {{% /capture %}} diff --git a/content/id/docs/concepts/cluster-administration/controller-metrics.md b/content/id/docs/concepts/cluster-administration/controller-metrics.md index 621f4afbe1..3afade9907 100644 --- a/content/id/docs/concepts/cluster-administration/controller-metrics.md +++ b/content/id/docs/concepts/cluster-administration/controller-metrics.md @@ -14,7 +14,7 @@ Metrik _controller manager_ memberikan informasi penting tentang kinerja dan kes Metrik _controller manager_ ini berfungsi untuk memberikan informasi penting tentang kinerja dan kesehatan dari _controller manager_. Metrik ini juga berisi tentang metrik umum dari _runtime_ bahasa pemrograman Go seperti jumlah _go_routine_ dan metrik spesifik dari _controller_ seperti -latensi dari etcd _request_ atau latensi API dari penyedia layanan _cloud_ (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan dari kluster. +latensi dari etcd _request_ atau latensi API dari penyedia layanan _cloud_ (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan dari klaster. Mulai dari Kubernetes 1.7, metrik yang lebih mendetil tentang operasi penyimpanan dari penyedia layanan _cloud_ juga telah tersedia. Metrik-metrik ini dapat digunakan untuk memonitor kesehatan dari operasi _persistent volume_. @@ -32,7 +32,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ## Konfigurasi -Pada sebuah kluster, informasi metrik _controller manager_ dapat diakses melalui `http://localhost:10252/metrics` +Pada sebuah klaster, informasi metrik _controller manager_ dapat diakses melalui `http://localhost:10252/metrics` dari _host_ tempat _controller manager_ dijalankan. Metrik ini dikeluarkan dalam bentuk [format prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) serta mudah untuk dibaca manusia. diff --git a/content/id/docs/concepts/cluster-administration/federation.md b/content/id/docs/concepts/cluster-administration/federation.md index b082b76a16..b669501d72 100644 --- a/content/id/docs/concepts/cluster-administration/federation.md +++ b/content/id/docs/concepts/cluster-administration/federation.md @@ -11,44 +11,44 @@ weight: 80 {{< /deprecationfilewarning >}} Laman ini menjelaskan alasan dan cara penggunaan _federation_ untuk melakukan manajemen -kluster Kubernetes. +klaster Kubernetes. {{% /capture %}} {{% capture body %}} ## Kenapa _Federation_ ? -_Federation_ membuat proses manajemen kluster multipel menjadi lebih mudah. +_Federation_ membuat proses manajemen klaster multipel menjadi lebih mudah. _Federation_ mencapai hal ini dengan cara menyediakan 2 buah fondasi: - * Melakukan sinkronisasi _resource_ di seluruh kluster: _Federation_ + * Melakukan sinkronisasi _resource_ di seluruh klaster: _Federation_ menyediakan kemampuan untuk melakukan sinkronisasi _resources_ pada _multiple_ - kluster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama - tersedia pada kluster multipel. + klaster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama + tersedia pada klaster multipel. * _Cross_ _cluster_ _Discovery_: _Federation_ menyediakan kemampuan untuk melakukan - konfigurasi otomatis server DNS dan _load balancer_ dari semua kluster. + konfigurasi otomatis server DNS dan _load balancer_ dari semua klaster. Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan - untuk mengakses _backend_ dari kluster multipel. + untuk mengakses _backend_ dari klaster multipel. Beberapa penggunaan _federation_ adalah sebagai berikut: -* _High Availability_: Melakukan _load balance_ di seluruh kluster serta +* _High Availability_: Melakukan _load balance_ di seluruh klaster serta melakukan konfigurasi otomatis server DNS dan _load balancer_, _federation_ - meminimalisasi dampak yang terjadi apabila terjadi kegagalan kluster. + meminimalisasi dampak yang terjadi apabila terjadi kegagalan klaster. * Mencegah _lock-in_ yang terjadi akibat penyedia layanan: Dengan cara mempermudah - proses migrasi antar kluster. + proses migrasi antar klaster. -Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa kluster. -Beberapa alasan kenapa kamu butuh beberapa kluster adalah: +Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa klaster. +Beberapa alasan kenapa kamu butuh beberapa klaster adalah: -* _Latency_ yang rendah: Memiliki kluster yang berada di _region_ yang berbeda +* _Latency_ yang rendah: Memiliki klaster 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 klaster kecil + dibandingkan sebuah klaster besar untuk melakukan isolasi _fault_ (misalnya saja + klaster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_ yang berbeda). -* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah kluster Kubernetes, +* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah klaster 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)). @@ -62,10 +62,10 @@ 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 biaya jaringan apabila klaster 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 klaster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat + berdampak pada semua klaster. 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. Tidak semua _resource_ yang ada tersedia dan masih banyak feature _alpha_. [_Issue_ @@ -74,18 +74,18 @@ terdapat beberapa kekurangan _federation_ yang dijabarkan sebagai berikut: ### Kemampuan _Hybrid_ Penggunaan Layanan Penyedian _Cloud_ -_Federation_ pada Kubernetes memungkinkan kluster untuk dijalankan +_Federation_ pada Kubernetes memungkinkan klaster 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_ -kluster _federation_. +klaster _federation_. Dengan demikian, [_resources_ API](#resources-api) yang kamu miliki -dapat berada di kluster atau bahkan penyedia layanan _cloud_ yang berbeda. +dapat berada di klaster atau bahkan penyedia layanan _cloud_ yang berbeda. ## Mengaktifkan _Federation_ -Untuk bisa melakukan _federation_ pada kluster yang berbeda, +Untuk bisa melakukan _federation_ pada klaster 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. @@ -117,7 +117,7 @@ _resources_ yang disediakan _apiserver_ _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. +kamu juga akan menghapus segala _resource_ tersebut pada semua klaster yang ada. Mekanisme penghapusan berantai ini tidak diaktifkan secara _default_ ketika menggunakan REST API. Untuk mengaktifkannya, ubah nilai dari opsi @@ -129,64 +129,64 @@ Kamu dapat menonaktifkannya dengan menggunakan `kubectl delete --cascade=false` Catatan: Kubernetes versi 1.5 menyediakan penghapusan berantai untuk sebagian _resource_ _federation_. -## Cakupan dari Sebuah Kluster +## Cakupan dari Sebuah Klaster 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 klaster 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 - kluster yang berada pada satu zona. + - dibandingkan dengan sebuah klaster global Kubernetes, terdapat lebih sedikit _single-points of failure_. + - dibandingkan dengan sebuah klaster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah + klaster yang berada pada satu zona. - 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 klaster dengan lebih banyak VM pada setiap _availability_ zona; +meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan klaster multipel pada setiap _availability_ zona. -Alasan kenapa menjalankan lebih sedikit kluster pada setiap _availability_ zona lebih dianjurkan: +Alasan kenapa menjalankan lebih sedikit klaster pada setiap _availability_ zona lebih dianjurkan: - - meningkatkan _bin packing_ _Pod_ pada beberapa kasus dimana terdapat lebih banyak _node_ dalam sebuah kluster (mengurangi terjadinya _fragmentation_ _resource_). + - meningkatkan _bin packing_ _Pod_ pada beberapa kasus dimana terdapat lebih banyak _node_ dalam sebuah klaster (mengurangi terjadinya _fragmentation_ _resource_). - mengurangi _overhead_ operasional (meskipun keuntungan ini akan berkurang seiring bertambah matangnya proses dan _tooling_ operasional). - - mengurangi biaya _resource_ tetap per kluster, misalnya VM _apiserver_. + - mengurangi biaya _resource_ tetap per klaster, misalnya VM _apiserver_. -Alasan untuk memiliki kluster multipel: +Alasan untuk memiliki klaster multipel: - - _policy_ kemananan yang ketat membutuhkan isolasi antar _work_ _class_ (baca Partisi Kluster di bawah). - - melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu kluster. + - _policy_ kemananan yang ketat membutuhkan isolasi antar _work_ _class_ (baca Partisi Klaster di bawah). + - melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu klaster. -## Memilih jumlah kluster yang tepat +## Memilih jumlah klaster yang tepat -Pemilihan jumlah kluster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu. +Pemilihan jumlah klaster 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 +Untuk memilih jumlah klaster, 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_ +Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih klaster 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 klaster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_. +Misalkan jumlah klaster _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 klaster, +maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` klaster. Jika tidak (misalnya, kamu +ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada klaster) maka kamu membutuhkan `R * (U + 1)` klaster +(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu klaster 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 -mampu menangani hingga 5000 node untuk tiap kluster. Baca [Membangun Kluster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut. +Terakhir, jika klaster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah klaster Kubernetes, +maka kamu membutuhkan lebih banyak klaster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap klaster. Kubernetes v1.8 +mampu menangani hingga 5000 node untuk tiap klaster. Baca [Membangun Klaster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut. {{% /capture %}} {{% capture whatsnext %}} * Pelajari lebih lanjut tentang [proposal _Federation_](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md). -* Baca [petunjuk pengaktifan](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) kluster _federation_. +* Baca [petunjuk pengaktifan](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) klaster _federation_. * Lihat [seminar tentang _federation_ pada Kubecon2016](https://www.youtube.com/watch?v=pq9lbkmxpS8) * Lihat [_update_ _federation_ pada Kubecon2017 Eropa](https://www.youtube.com/watch?v=kwOvOLnFYck) * Lihat [_update_ _sig-multicluster_ pada Kubecon2018 Eropa](https://www.youtube.com/watch?v=vGZo5DaThQU) diff --git a/content/id/docs/concepts/cluster-administration/logging.md b/content/id/docs/concepts/cluster-administration/logging.md index 73872f3d08..6ad7a86957 100644 --- a/content/id/docs/concepts/cluster-administration/logging.md +++ b/content/id/docs/concepts/cluster-administration/logging.md @@ -6,16 +6,16 @@ weight: 60 {{% capture overview %}} -Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam kluster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas kluster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_. +Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam klaster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas klaster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_. -Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level kluster. _Logging_ pada level kluster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam kluster Kubernetes kamu. +Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level klaster. _Logging_ pada level klaster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam klaster Kubernetes kamu. {{% /capture %}} {{% capture body %}} -Arsitektur _logging_ pada level kluster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klustermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level kluster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu. +Arsitektur _logging_ pada level klaster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klastermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level klaster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu. ## Hal dasar _logging_ pada Kubernetes @@ -61,7 +61,7 @@ _Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang te Secara _default_, jika suatu kontainer _restart_, kubelet akan menjaga kontainer yang mati tersebut beserta lognya. Namun jika suatu pod dibuang dari _node_, maka semua hal dari kontainernya juga akan dibuang, termasuk lognya. Hal lain yang perlu diperhatikan dalam _logging_ pada level _node_ adalah implementasi rotasi log, sehingga log tidak menghabiskan semua penyimpanan yang tersedia pada _node._ Kubernetes saat ini tidak bertanggung jawab dalam melakukan rotasi log, namun _deployment tool_ seharusnya memberikan solusi terhadap masalah tersebut. -Contohnya, pada kluster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker. +Contohnya, pada klaster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker. Pada `kube-up.sh`, metode terakhir digunakan untuk COS _image_ pada GCP, sedangkan metode pertama digunakan untuk lingkungan lainnya. Pada kedua metode, secara _default_ akan dilakukan rotasi pada saat berkas log melewati 10MB. Sebagai contoh, kamu dapat melihat informasi lebih rinci tentang bagaimana `kube-up.sh` mengatur _logging_ untuk COS _image_ pada GCP yang terkait dengan [_script_][cosConfigureHelper]. @@ -85,13 +85,13 @@ Pada mesin yang menggunakan systemd, kubelet dan runtime _runtime_ menulis ke jo Komponen sistem di dalam kontainer akan selalu menuliskan ke folder `/var/log`, melewati mekanisme _default logging_. Mereka akan menggunakan _logging library_ [klog][klog]. Kamu dapat menemukan konvensi tentang tingkat kegawatan _logging_ untuk komponen-komponen tersebut pada [dokumentasi _development logging_](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). -Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada kluster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB. +Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada klaster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB. [klog]: https://github.com/kubernetes/klog -## Arsitektur kluster-level _logging_ +## Arsitektur klaster-level _logging_ -Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level kluster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya: +Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level klaster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya: * Menggunakan agen _logging_ pada level _node_ yang berjalan pada setiap _node_. * Menggunakan kontainer _sidecar_ khusus untuk _logging_ aplikasi di dalam pod. @@ -101,11 +101,11 @@ Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level kluste ![Menggunakan agen node-level _logging_](/images/docs/user-guide/logging/logging-with-node-agent.png) -Kamu dapat mengimplementasikan kluster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut. +Kamu dapat mengimplementasikan klaster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut. Karena agen _logging_ harus berjalan pada setiap _node_, umumnya dilakukan dengan menggunakan replika DaemonSet, _manifest_ pod, atau menjalankan proses khusus pada _node_. Namun dua cara terakhir sudah dideprekasi dan sangat tidak disarankan. -Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk kluster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_. +Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk klaster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_. Kubernetes tidak menspesifikasikan khusus suatu agen _logging_, namun ada dua agen _logging_ yang dimasukkan dalam rilis Kubernetes: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) untuk digunakan pada Google Cloud Platform, dan [Elasticsearch](/docs/user-guide/logging/elasticsearch). Kamu dapat melihat informasi dan instruksi pada masing-masing dokumentasi. Keduanya menggunakan [fluentd](http://www.fluentd.org/) dengan konfigurasi kustom sebagai agen pada _node_. @@ -156,7 +156,7 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2 ... ``` -Agen node-level yang terpasang di klustermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya. +Agen node-level yang terpasang di klastermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya. Sedikit catatan, meskipun menggunakan memori dan CPU yang cukup rendah (sekitar beberapa milicore untuk CPU dan beberapa megabytes untuk memori), penulisan log ke _file_ kemudian mengalirkannya ke `stdout` dapat berakibat penggunaan disk yang lebih besar. Jika kamu memiliki aplikasi yang menuliskan ke _file_ tunggal, umumnya lebih baik menggunakan `/dev/stdout` sebagai tujuan daripada menggunakan pendekatan dengan kontainer _sidecar_. @@ -193,6 +193,6 @@ Ingat, ini hanya contoh saja dan kamu dapat mengganti fluentd dengan agen _loggi ![Mengekspos log langsung dari aplikasi](/images/docs/user-guide/logging/logging-from-application.png) -Kamu dapat mengimplementasikan kluster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes. +Kamu dapat mengimplementasikan klaster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes. {{% /capture %}} diff --git a/content/id/docs/concepts/cluster-administration/manage-deployment.md b/content/id/docs/concepts/cluster-administration/manage-deployment.md index 5ec1c8f7be..d53b4106a6 100644 --- a/content/id/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/id/docs/concepts/cluster-administration/manage-deployment.md @@ -352,7 +352,7 @@ Kadang kita perlu membuat pembaruan kecil, yang tidak mengganggu pada _resource_ ### kubectl apply -Disarankan untuk menyimpan berkas-berkas konfigurasi dalam _source control_ (lihat [konfigurasi sebagai kode](http://martinfowler.com/bliki/InfrastructureAsCode.html)). Sehingga berkas dapat dipelihara dan diatur dalam versi bersama dengan kode milik _resource_ yang diatur oleh konfigurasi tersebut. Berikutnya, kamu dapat menggunakan [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) untuk membarui perubahan konfigurasi ke kluster. +Disarankan untuk menyimpan berkas-berkas konfigurasi dalam _source control_ (lihat [konfigurasi sebagai kode](http://martinfowler.com/bliki/InfrastructureAsCode.html)). Sehingga berkas dapat dipelihara dan diatur dalam versi bersama dengan kode milik _resource_ yang diatur oleh konfigurasi tersebut. Berikutnya, kamu dapat menggunakan [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) untuk membarui perubahan konfigurasi ke klaster. Perintah ini akan membandingkan versi konfigurasi yang disuplai dengan versi sebelumnya yang telah berjalan dan memasang perubahan yang kamu buat tanpa mengganti properti yang tidak berubah sama sekali. diff --git a/content/id/docs/concepts/cluster-administration/proxies.md b/content/id/docs/concepts/cluster-administration/proxies.md index 8dfc6ddf6b..50fa737c51 100644 --- a/content/id/docs/concepts/cluster-administration/proxies.md +++ b/content/id/docs/concepts/cluster-administration/proxies.md @@ -26,7 +26,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes 1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services): - merupakan sebuah bastion yang ada di dalam apiserver - - menghubungkan pengguna di luar kluster ke alamat-alamat IP di dalam kluster yang tidak bisa terjangkau + - menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau - dijalankan bersama process-process apiserver - dari klien menuju proxy menggunakan HTTPS (atau http jika dikonfigurasi pada apiserver) - dari proxy menuju target menggunakan HTTP atau HTTPS, tergantung pilihan yang diambil oleh proxy melalui informasi yang ada @@ -43,7 +43,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes 1. Sebuah Proxy/Load-balancer di depan satu atau banyak apiserver: - - keberadaan dan implementasinya bervariasi tergantung pada kluster (contohnya nginx) + - keberadaan dan implementasinya bervariasi tergantung pada klaster (contohnya nginx) - ada di antara seluruh klien dan satu/banyak apiserver - jika ada beberapa apiserver, berfungsi sebagai load balancer @@ -56,7 +56,7 @@ Ada beberapa jenis proxy yang akan kamu temui saat menggunakan Kubernetes - implementasi bervariasi tergantung pada penyedia cloud 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. +Untuk proxy-proxy lain di luar ini, admin klaster 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 c536b13eba..f78bc54b48 100644 --- a/content/id/docs/concepts/configuration/assign-pod-node.md +++ b/content/id/docs/concepts/configuration/assign-pod-node.md @@ -23,11 +23,11 @@ Mari kita telusuri contoh dari penggunaan `nodeSelector`. ### Langkah Nol: Prasyarat -Contoh ini mengasumsikan bahwa kamu memiliki pemahaman dasar tentang pod Kubernetes dan kamu telah [membuat kluster Kubernetes](https://github.com/kubernetes/kubernetes#documentation). +Contoh ini mengasumsikan bahwa kamu memiliki pemahaman dasar tentang pod Kubernetes dan kamu telah [membuat klaster Kubernetes](https://github.com/kubernetes/kubernetes#documentation). ### Langkah Satu: Menyematkan label pada node -Jalankan `kubectl get nodes` untuk mendapatkan nama dari node-node yang ada dalam kluster kamu. Temukan node yang akan kamu tambahkan label, kemudian jalankan perintah `kubectl label nodes =` untuk menambahkan label pada node yang telah kamu pilih. Sebagai contoh, jika nama node yang saya pilih adalah 'kubernetes-foo-node-1.c.a-robinson.internal' dan label yang ingin saya tambahkan adalah 'disktype=ssd', maka saya dapat menjalankan `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`. +Jalankan `kubectl get nodes` untuk mendapatkan nama dari node-node yang ada dalam klaster kamu. Temukan node yang akan kamu tambahkan label, kemudian jalankan perintah `kubectl label nodes =` untuk menambahkan label pada node yang telah kamu pilih. Sebagai contoh, jika nama node yang saya pilih adalah 'kubernetes-foo-node-1.c.a-robinson.internal' dan label yang ingin saya tambahkan adalah 'disktype=ssd', maka saya dapat menjalankan `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`. Jika terjadi kegagalan dengan kesalahan perintah yang tidak _valid_ ("_invalid command_"), kemungkinan besar kamu menggunakan kubectl dengan versi lebih lama yang tidak memiliki perintah `label`. Dalam hal ini, lihat [versi sebelumnya] (https://github.com/kubernetes/kubernetes/blob/a053dbc313572ed60d89dae9821ecab8bfd676dc/examples/node-selection/README.md) dari petunjuk ini untuk instruksi tentang cara menetapkan label pada node. @@ -135,11 +135,11 @@ Afinitas and anti-afinitas antar pod diperkenalkan pada Kubernetes 1.4. Afinitas 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. +Afinitas and anti-afinitas antar pod membutuhkan jumlah pemrosesan yang substansial yang dapat memperlambat penjadwalan pada klaster berukuran besar secara signifikan. Kami tidak merekomendasikan penggunaan mereka pada klaster yang berukuran lebih besar dari beberapa ratus node. {{< /note >}} {{< note >}} -Anti-afinitas pod mengharuskan node untuk diberi label secara konsisten, misalnya setiap node dalam kluster harus memiliki label sesuai yang cocok dengan `topologyKey`. Jika sebagian atau semua node tidak memiliki label `topologyKey` yang dinyatakan, hal ini dapat menyebabkan perilaku yang tidak diinginkan. +Anti-afinitas pod mengharuskan node untuk diberi label secara konsisten, misalnya setiap node dalam klaster harus memiliki label sesuai yang cocok dengan `topologyKey`. Jika sebagian atau semua node tidak memiliki label `topologyKey` yang dinyatakan, hal ini dapat menyebabkan perilaku yang tidak diinginkan. {{< /note >}} Seperti afinitas node, ada dua tipe afinitas dan anti-afinitas pod, yaitu `requiredDuringSchedulingIgnoredDuringExecution` dan @@ -154,7 +154,7 @@ Afinitas antar pod dinyatakan sebagai _field_ `podAffinity` dari _field_ `affini {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} Afinitas pada pod tersebut menetapkan sebuah aturan afinitas pod dan aturan anti-afinitas pod. Pada contoh ini, `podAffinity` adalah `requiredDuringSchedulingIgnoredDuringExecution` -sementara `podAntiAffinity` adalah `preferredDuringSchedulingIgnoredDuringExecution`. Aturan afinitas pod menyatakan bahwa pod dapat dijadwalkan pada node hanya jika node tersebut berada pada zona yang sama dengan minimal satu pod yang sudah berjalan yang memiliki label dengan kunci "security" dan bernilai "S1". (Lebih detail, pod dapat berjalan pada node N jika node N memiliki label dengan kunci `failure-domain.beta.kubernetes.io/zone`dan nilai V sehingga ada minimal satu node dalam kluster dengan kunci `failure-domain.beta.kubernetes.io/zone` dan bernilai V yang menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S1".) Aturan anti-afinitas pod menyatakan bahwa pod memilih untuk tidak dijadwalkan pada sebuah node jika node tersebut sudah menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S2". (Jika `topologyKey` adalah `failure-domain.beta.kubernetes.io/zone` maka dapat diartikan bahwa pod tidak dapat dijadwalkan pada node jika node berada pada zona yang sama dengan pod yang memiliki label dengan kunci "security" dan bernilai "S2".) Lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) untuk lebih banyak contoh afinitas dan anti-afinitas pod, baik `requiredDuringSchedulingIgnoredDuringExecution` +sementara `podAntiAffinity` adalah `preferredDuringSchedulingIgnoredDuringExecution`. Aturan afinitas pod menyatakan bahwa pod dapat dijadwalkan pada node hanya jika node tersebut berada pada zona yang sama dengan minimal satu pod yang sudah berjalan yang memiliki label dengan kunci "security" dan bernilai "S1". (Lebih detail, pod dapat berjalan pada node N jika node N memiliki label dengan kunci `failure-domain.beta.kubernetes.io/zone`dan nilai V sehingga ada minimal satu node dalam klaster dengan kunci `failure-domain.beta.kubernetes.io/zone` dan bernilai V yang menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S1".) Aturan anti-afinitas pod menyatakan bahwa pod memilih untuk tidak dijadwalkan pada sebuah node jika node tersebut sudah menjalankan pod yang memiliki label dengan kunci "security" dan bernilai "S2". (Jika `topologyKey` adalah `failure-domain.beta.kubernetes.io/zone` maka dapat diartikan bahwa pod tidak dapat dijadwalkan pada node jika node berada pada zona yang sama dengan pod yang memiliki label dengan kunci "security" dan bernilai "S2".) Lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) untuk lebih banyak contoh afinitas dan anti-afinitas pod, baik `requiredDuringSchedulingIgnoredDuringExecution` maupun `preferredDuringSchedulingIgnoredDuringExecution`. Operator yang sah untuk afinitas dan anti-afinitas pod adalah `In`, `NotIn`, `Exists`, `DoesNotExist`. @@ -179,7 +179,7 @@ ditempatkan bersama dalam topologi yang didefinisikan sama, misalnya, node yang ##### Selalu ditempatkan bersamaan pada node yang sama -Dalam kluster berisi 3 node, sebuah aplikasi web memiliki in-memory cache seperti redis. Kita menginginkan agar _web-server_ dari aplikasi ini sebisa mungkin ditempatkan bersamaan dengan cache. +Dalam klaster berisi 3 node, sebuah aplikasi web memiliki in-memory cache seperti redis. Kita menginginkan agar _web-server_ dari aplikasi ini sebisa mungkin ditempatkan bersamaan dengan cache. Berikut ini kutipan yaml dari deployment redis sederhana dengan 3 replika dan label selector `app=store`, Deployment memiliki konfigurasi `PodAntiAffinity` untuk memastikan _scheduler_ tidak menempatkan replika bersamaan pada satu node. @@ -254,7 +254,7 @@ spec: image: nginx:1.12-alpine ``` -Jika kita membuat kedua dployment di atas, kluster berisi 3 node kita seharusnya menjadi seperti berikut. +Jika kita membuat kedua dployment di atas, klaster berisi 3 node kita seharusnya menjadi seperti berikut. | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -279,7 +279,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 ##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama -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. +Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster 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. 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/organize-cluster-access-kubeconfig.md b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index ab20d640d6..f9eb8aa3cd 100644 --- a/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -1,18 +1,18 @@ --- -title: Mengatur Akses Kluster Menggunakan Berkas kubeconfig +title: Mengatur Akses Klaster Menggunakan Berkas kubeconfig content_template: templates/concept weight: 60 --- {{% capture overview %}} -Gunakan berkas kubeconfig untuk mengatur informasi mengenai kluster, pengguna, +Gunakan berkas kubeconfig untuk mengatur informasi mengenai klaster, pengguna, _namespace_, dan mekanisme autentikasi. Perintah `kubectl` menggunakan berkas -kubeconfig untuk mencari informasi yang dibutuhkan untuk memilih kluster dan -berkomunikasi dengan API server dari suatu kluster. +kubeconfig untuk mencari informasi yang dibutuhkan untuk memilih klaster dan +berkomunikasi dengan API server dari suatu klaster. {{< note >}} -Sebuah berkas yang digunakan untuk mengatur akses pada kluster disebut dengan +Sebuah berkas yang digunakan untuk mengatur akses pada klaster disebut dengan berkas kubeconfig. Ini cara yang umum digunakan untuk mereferensikan berkas konfigurasi. Ini tidak berarti ada berkas dengan nama `kubeconfig`. {{< /note >}} @@ -23,7 +23,7 @@ nilai `KUBECONFIG` pada variabel _environment_ atau dengan mengatur menggunakan tanda [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/). Instruksi langkah demi langkah untuk membuat dan menentukan berkas kubeconfig, -bisa mengacu pada [Mengatur Akses Pada Beberapa Kluster] +bisa mengacu pada [Mengatur Akses Pada Beberapa Klaster] (/docs/tasks/access-application-cluster/configure-access-multiple-clusters). {{% /capture %}} @@ -31,9 +31,9 @@ bisa mengacu pada [Mengatur Akses Pada Beberapa Kluster] {{% capture body %}} -## Mendukung beberapa kluster, pengguna, dan mekanisme autentikasi +## Mendukung beberapa klaster, pengguna, dan mekanisme autentikasi -Misalkan kamu memiliki beberapa kluster, pengguna serta komponen dapat melakukan +Misalkan kamu memiliki beberapa klaster, pengguna serta komponen dapat melakukan autentikasi dengan berbagai cara. Sebagai contoh: - Kubelet yang berjalan dapat melakukan autentikasi dengan menggunakan sertifikat @@ -41,16 +41,16 @@ autentikasi dengan berbagai cara. Sebagai contoh: - Administrator bisa memiliki beberapa sertifikat yang diberikan kepada pengguna individu. -Dengan berkas kubeconfig, kamu bisa mengatur kluster, pengguna, dan _namespace_. +Dengan berkas kubeconfig, kamu bisa mengatur klaster, pengguna, dan _namespace_. Kamu juga bisa menentukan konteks untuk mempercepat dan mempermudah perpindahan -antara kluster dan _namespace_. +antara klaster dan _namespace_. ## Konteks Sebuah elemen konteks pada berkas kubeconfig digunakan untuk mengelompokkan parameter akses dengan nama yang mudah. Setiap konteks akan memiliki 3 parameter: -kluster, pengguna, dan _namespace_. Secara _default_, perintah `kubectl` menggunakan -parameter dari konteks yang aktif untuk berkomunikasi dengan kluster. +klaster, pengguna, dan _namespace_. Secara _default_, perintah `kubectl` menggunakan +parameter dari konteks yang aktif untuk berkomunikasi dengan klaster. Untuk memilih konteks yang aktif, bisa menggunakan perintah berikut: ``` @@ -115,26 +115,26 @@ kubeconfig: Konteks yang kosong masih diperbolehkan pada tahap ini. -1. Menentukan kluster dan pengguna. Pada tahap ini, mungkin akan ada atau tidak ada konteks. - Menentukan kluster dan pengguna berdasarkan yang pertama sesuai dengan pilihan berikut, - yang mana akan dijalankan dua kali: sekali untuk pengguna dan sekali untuk kluster: +1. Menentukan klaster dan pengguna. Pada tahap ini, mungkin akan ada atau tidak ada konteks. + Menentukan klaster dan pengguna berdasarkan yang pertama sesuai dengan pilihan berikut, + yang mana akan dijalankan dua kali: sekali untuk pengguna dan sekali untuk klaster: 1. Jika ada, maka gunakan tanda pada perintah: `--user` atau `--cluster`. - 1. Jika konteks tidak kosong, maka pengguna dan kluster didapat dari konteks. + 1. Jika konteks tidak kosong, maka pengguna dan klaster didapat dari konteks. - Pengguna dan kluster masih diperbolehkan kosong pada tahap ini. + Pengguna dan klaster masih diperbolehkan kosong pada tahap ini. -1. Menentukan informasi kluster sebenarnya yang akan digunakan. Pada tahap ini, mungkin - akan ada atau tidak ada informasi kluster. Membentuk informasi kluster berdasarkan urutan +1. Menentukan informasi klaster sebenarnya yang akan digunakan. Pada tahap ini, mungkin + akan ada atau tidak ada informasi klaster. Membentuk informasi klaster berdasarkan urutan berikut dan yang pertama sesuai akan digunakan: 1. Jika ada, maka gunakan tanda pada perintah: `--server`, `--certificate-authority`, `--insecure-skip-tls-verify`. - 1. Jika terdapat atribut informasi kluster dari hasil gabungan berkas kubeconfig, + 1. Jika terdapat atribut informasi klaster dari hasil gabungan berkas kubeconfig, maka gunakan itu. 1. Jika tidak terdapat informasi mengenai lokasi server, maka dianggap gagal. 1. Menentukan informasi pengguna sebenarnya yang akan digunakan. Membentuk informasi - pengguna dengan aturan yang sama dengan pembentukan informasi kluster, namun hanya + pengguna dengan aturan yang sama dengan pembentukan informasi klaster, namun hanya diperbolehkan ada satu teknik autentikasi untuk setiap pengguna: 1. Jika ada, gunakan tanda pada perintah: `--client-certificate`, `--client-key`, `--username`, `--password`, `--token`. @@ -157,7 +157,7 @@ _absolute path_ akan disimpan secara mutlak. {{% capture whatsnext %}} -* [Mengatur Akses Pada Beberapa Kluster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [Mengatur Akses Pada Beberapa Klaster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) {{% /capture %}} diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/configuration/taint-and-toleration.md index 8a71c40dbd..03fa777fe2 100644 --- a/content/id/docs/concepts/configuration/taint-and-toleration.md +++ b/content/id/docs/concepts/configuration/taint-and-toleration.md @@ -177,14 +177,14 @@ 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 +_node_ lain yang ada di dalam klaster. 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 +* **Node-Node dengan Perangkat Keras Khusus**: Pada suatu klaster 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 diff --git a/content/id/docs/concepts/containers/container-environment-variables.md b/content/id/docs/concepts/containers/container-environment-variables.md index 102b2b8676..2a44dcbdcd 100644 --- a/content/id/docs/concepts/containers/container-environment-variables.md +++ b/content/id/docs/concepts/containers/container-environment-variables.md @@ -19,7 +19,7 @@ Laman ini menjelaskan berbagai *resource* yang tersedia di dalam Kontainer pada * Sebuah *Filesystem*, yang merupakan kombinasi antara [image](/docs/concepts/containers/images/) dan satu atau banyak [*volumes*](/docs/concepts/storage/volumes/). * Informasi tentang Kontainer tersebut. -* Informasi tentang objek-objek lain di dalam kluster. +* Informasi tentang objek-objek lain di dalam klaster. ### Informasi tentang Kontainer @@ -32,7 +32,7 @@ Nama Pod dan *namespace* tersedia sebagai variabel *environment* melalui [API *d Variabel *environment* yang ditulis pengguna dalam Pod *definition* juga tersedia di dalam Kontainer, seperti halnya variabel *environment* yang ditentukan secara statis di dalam *image* Docker. -### Informasi tentang Kluster +### Informasi tentang Klaster Daftar semua *Service* yang dijalankan ketika suatu Kontainer dibuat, tersedia di dalam Kontainer tersebut sebagai variabel *environment*. Variabel-variabel *environment* tersebut sesuai dengan sintaksis *links* dari Docker. diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md index 4379c1c497..dca24e9b6d 100644 --- a/content/id/docs/concepts/containers/runtime-class.md +++ b/content/id/docs/concepts/containers/runtime-class.md @@ -42,7 +42,7 @@ _Container Runtime Interface_ (CRI). Lihat bagian ([di bawah ini](#konfigurasi-c soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki. {{< note >}} -Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam kluster punya +Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/docs/concepts/configuration/assign-pod-node/)). @@ -69,14 +69,14 @@ handler: myconfiguration # Nama dari konfigurasi CRI terkait ``` {{< note >}} -Sangat disarankan untuk hanya memperbolehkan admin kluster melakukan operasi +Sangat disarankan untuk hanya memperbolehkan admin klaster melakukan operasi _write_ pada RuntimeClass. Biasanya ini sudah jadi _default_. Lihat [Ikhtisar Autorisasi](/docs/reference/access-authn-authz/authorization/) untuk penjelasan lebih jauh. {{< /note >}} ### Penggunaan -Ketika RuntimeClass sudah dikonfigurasi pada kluster, penggunaannya sangatlah mudah. +Ketika RuntimeClass sudah dikonfigurasi pada klaster, penggunaannya sangatlah mudah. Kamu bisa tentukan `runtimeClassName` di dalam `spec` sebuah Pod, sebagai contoh: ```yaml @@ -95,7 +95,7 @@ menjalankan _handler_ yang terkait, maka Pod akan memasuki [tahap](/docs/concept Lihat [_event_](/docs/tasks/debug-application-cluster/debug-application-introspection/) untuk mengetahui pesan error yang terkait. Jika tidak ada `runtimeClassName` yang ditentukan di dalam Pod, maka RuntimeHandler yang _default_ akan digunakan. -Untuk kasus ini, perilaku kluster akan seperti saat fitur RuntimeClass dinonaktifkan. +Untuk kasus ini, perilaku klaster akan seperti saat fitur RuntimeClass dinonaktifkan. ### Konfigurasi CRI diff --git a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md index 8fe0f13ef1..0d979f31d6 100644 --- a/content/id/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/id/docs/concepts/extend-kubernetes/extend-cluster.md @@ -1,5 +1,5 @@ --- -title: Memperluas Kluster Kubernetes Kamu +title: Memperluas Klaster Kubernetes Kamu content_template: templates/concept weight: 10 --- @@ -9,9 +9,9 @@ weight: 10 Kubernetes sangat mudah dikonfigurasi dan diperluas. Sehingga, jarang membutuhkan _fork_ atau menambahkan _patch_ ke kode proyek Kubernetes. -Panduan ini menjelaskan pilihan untuk menyesuaikan kluster Kubernetes. -Dokumen ini ditujukan kepada {{< glossary_tooltip text="operator kluster" term_id="cluster-operator" >}} yang ingin -memahami bagaimana menyesuaikan kluster Kubernetes dengan kebutuhan lingkungan kerja mereka. +Panduan ini menjelaskan pilihan untuk menyesuaikan klaster Kubernetes. +Dokumen ini ditujukan kepada {{< glossary_tooltip text="operator klaster" term_id="cluster-operator" >}} yang ingin +memahami bagaimana menyesuaikan klaster Kubernetes dengan kebutuhan lingkungan kerja mereka. Developer yang prospektif {{< glossary_tooltip text="Developer Platform" term_id="platform-developer" >}} atau {{< glossary_tooltip text="Kontributor" term_id="contributor" >}} Proyek Kubernetes juga mendapatkan manfaat dari dokumen ini sebagai pengantar apa saja poin-poin dan pola-pola perluasan yang ada, untung-rugi, dan batasan-batasannya. @@ -34,26 +34,26 @@ _Flag-flag_ dan _berkas-berkas konfigurasi_ didokumentasikan di bagian Referensi * [kube-controller-manager](/docs/admin/kube-controller-manager/) * [kube-scheduler](/docs/admin/kube-scheduler/). -_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Kluster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain. +_Flag-flag_ dan berkas-berkas konfigurasi mungkin tidak selalu dapat diubah pada layanan Kubernetes yang _hosted_ atau pada distribusi dengan instalasi yang dikelola. Ketika mereka dapat diubah, mereka biasanya hanya dapat diubah oleh Administrator Klaster. Dan juga, mereka dapat sewaktu-waktu diubah dalam versi Kubernetes di masa depan, dan menyetel mereka mungkin memerlukan proses pengulangan kembali. Oleh karena itu, mereka harus digunakan hanya ketika tidak ada pilihan lain. -*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi kluster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan. +*API kebijakan bawaan*, seperti [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) dan Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), adalah API bawaan Kubernetes. API biasanya digunakan oleh layanan Kubernetes yang _hosted_ dan diatur oleh instalasi Kubernetes. Mereka bersifat deklaratif dan menggunakan konvensi yang sama dengan sumber daya Kubernetes lainnya seperti pod-pod, jadi konfigurasi klaster baru dapat diulang-ulang dan dapat diatur dengan cara yang sama dengan aplikasi. Dan, ketika mereka stabil, mereka mendapatkan keuntungan dari [kebijakan pendukung yang jelas](/docs/reference/deprecation-policy/) seperti API Kubernetes lainnya. Oleh karena itu, mereka lebih disukai daripada _berkas konfigurasi_ dan _flag-flag_ saat mereka cocok dengan situasi yang dibutuhkan. ## Perluasan Perluasan adalah komponen perangkat lunak yang memperluas dan berintegrasi secara mendalam dengan Kubernetes. Mereka mengadaptasi Kubernetes untuk mendukung perangkat keras tipe baru dan jenis baru. -Kebanyakan administrator kluster akan menggunakan instansi Kubernetes yang didistribusikan atau yang _hosted_. +Kebanyakan administrator klaster akan menggunakan instansi Kubernetes yang didistribusikan atau yang _hosted_. Sebagai hasilnya, kebanyakan pengguna Kubernetes perlu menginstal perluasan dan lebih sedikit yang perlu untuk membuat perluasan-perluasan yang baru. ## 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. -*Otomasi* dapat berjalan di dalam kluster atau di luar kluster. Dengan mengikuti panduan +*Otomasi* dapat berjalan di dalam klaster atau di luar klaster. Dengan mengikuti panduan di dalam dokumen ini, kamu dapat menulis otomasi yang sangat tersedia dan kuat. -Otomasi pada umumnya dapat bekerja dengan berbagai macam kluster Kubernetes, termasuk -kluster yang _hosted_ dan instalasi yang dikelola. +Otomasi pada umumnya dapat bekerja dengan berbagai macam klaster Kubernetes, termasuk +klaster yang _hosted_ dan instalasi yang dikelola. Ada pola spesifik untuk menulis program klien yang bekerja dengan baik bersama Kubernetes yang disebut pola _Controller_. _Controller-controller_ biasanya membaca kolom `.spec` milik sebuah objek, kemungkinan melakukan sesuatu, dan kemudian memperbarui objek milik `.status`. @@ -86,7 +86,7 @@ Diagram berikut menunjukkan titik-titik perluasan di sebuah Kubernetes. 3. apiserver melayani berbagai macam sumber daya, _tipe-tipe sumber daya bawaan_, seperti `pod`, didefinisikan oleh proyek kubernetes dan tidak dapat diubah. kamu juga dapat menambahkan sumber daya yang kamu definisikan sendiri, atau yang proyek lain definisikan, disebut _Custom Resources_, seperti dijelaskan di bagian [Sumber Daya _Custom_](/docs/concepts/overview/extending#tipe-tipe-yang-ditentukan-pengguna). Sumber daya _Custom_ sering digunakan dengan Perluasan Akses API. 4. Penjadwal Kubernetes memutuskan ke Node mana Pod akan ditempatkan. Ada beberapa cara untuk memperluas penjadwalan. Hal ini dibahas pada bagian [Perluasan-perluasan Penjadwal](/docs/concepts/overview/extending#perluasan-perluasan-penjadwal). 5. Sebagian besar perilaku Kubernetes diimplementasi oleh program yang disebut *Controller-controller* yang merupakan klien dari API-Server. *Controller-controller* sering digunakan bersama dengan Sumber Daya _Custom_. -6. Kubelet berjalan di server, dan membantu Pod-pod terlihat seperti server virtual dengan IP mereka sendiri di jaringan kluster. [_Plugin_ Jaringan](/docs/concepts/overview/extending#plugin-plugin-jaringan) memungkinkan adanya perbedaan implementasi pada jaringan Pod. +6. Kubelet berjalan di server, dan membantu Pod-pod terlihat seperti server virtual dengan IP mereka sendiri di jaringan klaster. [_Plugin_ Jaringan](/docs/concepts/overview/extending#plugin-plugin-jaringan) memungkinkan adanya perbedaan implementasi pada jaringan Pod. 7. Kubelet juga melakukan penambatan dan pelepasan tambatan volume untuk kontainer. Tipe-tipe penyimpanan baru dapat didukung via [_Plugin_ Penyimpanan](/docs/concepts/overview/extending#plugin-plugin-penyimpanan). Jika kamu tidak yakin untuk memulai dari mana, diagram alir di bawah ini dapat membantu kamu. Ingat lah bahwa beberapa solusi mungkin melibatkan beberapa tipe perluasan. diff --git a/content/id/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md b/content/id/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md index 2e1058baf7..a9e49bf4f1 100644 --- a/content/id/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md +++ b/content/id/docs/concepts/extend-kubernetes/poseidon-firmament-alternate-scheduler.md @@ -17,7 +17,7 @@ Penjadwal Poseidon-Firmament adalah penjadwal alternatif yang dapat digunakan be ## Pengenalan -Poseidon adalah sebuah layanan yang berperan sebagai pemersatu antara [Penjadwal Firmament](https://github.com/Huawei-PaaS/firmament) dengan Kubernetes. Penjadwal Poseidon-Firmament menambah kapabilitas penjadwal Kubernetes saat ini. Penjadwal ini menggabungkan kemampuan penjadwalan berbasis grafik jaringan grafis (_flow network graph_) baru bersama penjadwal Kubernetes bawaan. Penjadwal Firmament memodelkan beban-beban kerja dan kluster-kluster sebagai jaringan aliran dan menjalankan optimisasi aliran biaya-minimum kepada jaringan ini untuk membuat keputusan penjadwalan. +Poseidon adalah sebuah layanan yang berperan sebagai pemersatu antara [Penjadwal Firmament](https://github.com/Huawei-PaaS/firmament) dengan Kubernetes. Penjadwal Poseidon-Firmament menambah kapabilitas penjadwal Kubernetes saat ini. Penjadwal ini menggabungkan kemampuan penjadwalan berbasis grafik jaringan grafis (_flow network graph_) baru bersama penjadwal Kubernetes bawaan. Penjadwal Firmament memodelkan beban-beban kerja dan klaster-klaster sebagai jaringan aliran dan menjalankan optimisasi aliran biaya-minimum kepada jaringan ini untuk membuat keputusan penjadwalan. Penjadwal ini memodelkan masalah penjadwalan sebagai optimasi berbasis batasan atas grafik jaringan aliran. Hal ini dicapai dengan mengurangi penjadwalan ke masalah optimisasi biaya-minimum aliran-maksimum. Penjadwal Poseidon-Firmament secara dinamis memperbaiki penempatan beban kerja. @@ -28,8 +28,8 @@ Penjadwal Poseidon-Firmament berjalan bersamaan dengan penjadwal Kubernetes bawa ### Penjadwalan grafik jaringan (_network graph_) berbasis penjadwalan Poseidon-Firmament memberikan beberapa keuntungan utama sebagai berikut: - Beban kerja (Pod) dijadwalkan secara kolektif untuk memungkinkan penjadwalan dalam skala besar. -- Berdasarkan hasil tes kinerja yang ekstensif, skala Poseidon-Firmament jauh lebih baik daripada penjadwal bawaan Kubernetes dilihat dari jumlah node meningkat dalam sebuah kluster. Hal ini disebabkan oleh fakta bahwa Poseidon-Firmament mampu mengamortisasi lebih banyak pekerjaan di seluruh beban kerja. -- Penjadwal Poseidon-Firmament mengungguli penjadwal bawaan Kubernetes dengan margin lebar ketika menyangkut jumlah kinerja _throughput_ untuk skenario di mana kebutuhan sumber daya komputasi agak seragam di seluruh pekerjaan (Replicaset / Deployment / Job). Angka kinerja _throughput_ _end-to-end_ penjadwal Poseidon-Firmament , termasuk waktu _bind_, secara konsisten menjadi lebih baik seiring jumlah Node dalam sebuah kluster meningkat. Misalnya, untuk kluster 2.700 Node (ditampilkan dalam grafik [di sini](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md)), penjadwal Poseidon-Firmament berhasil mencapai 7X atau lebih _throughput_ _end-to-end_ yang lebih besar dibandingkan dengan penjadwal bawaan Kubernetes, yang mencakup waktu _bind_. +- Berdasarkan hasil tes kinerja yang ekstensif, skala Poseidon-Firmament jauh lebih baik daripada penjadwal bawaan Kubernetes dilihat dari jumlah node meningkat dalam sebuah klaster. Hal ini disebabkan oleh fakta bahwa Poseidon-Firmament mampu mengamortisasi lebih banyak pekerjaan di seluruh beban kerja. +- Penjadwal Poseidon-Firmament mengungguli penjadwal bawaan Kubernetes dengan margin lebar ketika menyangkut jumlah kinerja _throughput_ untuk skenario di mana kebutuhan sumber daya komputasi agak seragam di seluruh pekerjaan (Replicaset / Deployment / Job). Angka kinerja _throughput_ _end-to-end_ penjadwal Poseidon-Firmament , termasuk waktu _bind_, secara konsisten menjadi lebih baik seiring jumlah Node dalam sebuah klaster meningkat. Misalnya, untuk klaster 2.700 Node (ditampilkan dalam grafik [di sini](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/benchmark/README.md)), penjadwal Poseidon-Firmament berhasil mencapai 7X atau lebih _throughput_ _end-to-end_ yang lebih besar dibandingkan dengan penjadwal bawaan Kubernetes, yang mencakup waktu _bind_. - Tersedianya pembatasan aturan yang kompleks. - Penjadwalan dalam Poseidon-Firmament bersifat dinamis; ini membuat sumber daya klaster dalam keadaan optimal secara global selama setiap berjalannya penjadwalan. - Pemanfaatan sumber daya yang sangat efisien. @@ -53,7 +53,7 @@ Untuk detail tentang desain proyek ini, lihat [dokumen desain](https://github.co ## Kemungkinan Skenario Kasus Penggunaan - Kapan menggunakannya -Seperti yang disebutkan sebelumnya, penjadwal Poseidon-Firmament memungkinkan lingkungan penjadwalan dengan _throughput_ yang sangat tinggi bahkan pada ukuran kluster dengan beban kerja besar, dikarenakan pendekatan penjadwalannya yang sekaligus dalam jumlah besar, dibandingkan dengan pendekatan bawaan _pod-at-a-time_ Kubernetes. Dalam pengujian ekstensif kami, kami telah mengamati manfaat _throughput_ substansial selama kebutuhan sumber daya (CPU / Memori) untuk Pod yang masuk seragam di seluruh tugas (Replicaset / Deployment / Job), terutama karena amortisasi pekerjaan yang efisien di seluruh tugas. +Seperti yang disebutkan sebelumnya, penjadwal Poseidon-Firmament memungkinkan lingkungan penjadwalan dengan _throughput_ yang sangat tinggi bahkan pada ukuran klaster dengan beban kerja besar, dikarenakan pendekatan penjadwalannya yang sekaligus dalam jumlah besar, dibandingkan dengan pendekatan bawaan _pod-at-a-time_ Kubernetes. Dalam pengujian ekstensif kami, kami telah mengamati manfaat _throughput_ substansial selama kebutuhan sumber daya (CPU / Memori) untuk Pod yang masuk seragam di seluruh tugas (Replicaset / Deployment / Job), terutama karena amortisasi pekerjaan yang efisien di seluruh tugas. Meskipun penjadwal Poseidon-Firmament mampu menjadwalkan berbagai jenis beban kerja, seperti layanan-layanan, _batch_, dll., berikut ini adalah beberapa kasus penggunaan yang paling unggul: @@ -85,14 +85,14 @@ Meskipun penjadwal Poseidon-Firmament mampu menjadwalkan berbagai jenis beban ke | Dukungan untuk Penjadwalan Volume Persisten Pra-terikat | Y | Y || | Dukungan untuk Volume Lokal & Penjadwalan _Binding_ Volume Persisten Dinamis | Y | N** | Direncanakan. | | Ketersediaan Tinggi | Y | N** | Direncanakan. | -| Penjadwalan berbasis metrik _real-time_ | N | Y** | Awalnya didukung menggunakan Heapster (sekarang tidak digunakan lagi) untuk menempatkan Pod menggunakan statistik penggunaan kluster aktual ketimbang reservasi. Rencananya akan dialihkan ke "server metrik". | +| Penjadwalan berbasis metrik _real-time_ | N | Y** | Awalnya didukung menggunakan Heapster (sekarang tidak digunakan lagi) untuk menempatkan Pod menggunakan statistik penggunaan klaster aktual ketimbang reservasi. Rencananya akan dialihkan ke "server metrik". | | Dukungan untuk _Max-Pod_ per Node | Y | Y | Penjadwal Poseidon-Firmament secara mulus berdampingan dengan penjadwal bawaan Kubernetes. | Dukungan untuk Penyimpanan _Ephemeral_, selain CPU / Memori | Y | Y || ## Instalasi -Untuk instalasi Poseidon dalam-kluster, silakan mulai dari [Petunjuk Instalasi](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md). +Untuk instalasi Poseidon dalam-klaster, silakan mulai dari [Petunjuk Instalasi](https://github.com/kubernetes-sigs/poseidon/blob/master/docs/install/README.md). ## Pengembangan diff --git a/content/id/docs/concepts/overview/components.md b/content/id/docs/concepts/overview/components.md index b23e7bd6cf..aac74cf215 100644 --- a/content/id/docs/concepts/overview/components.md +++ b/content/id/docs/concepts/overview/components.md @@ -9,25 +9,25 @@ card: {{% capture overview %}} Dokumen ini merupakan ikhtisar yang mencakup berbagai komponen -yang dibutuhkan agar kluster Kubernetes dapat berjalan secara fungsional. +yang dibutuhkan agar klaster Kubernetes dapat berjalan secara fungsional. {{% /capture %}} {{% capture body %}} ## Komponen Master -Komponen master menyediakan control plane bagi kluster. +Komponen master menyediakan control plane bagi klaster. 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 +pada klaster (contohnya, mekanisme schedule), serta berperan dalam proses +deteksi serta pemberian respons terhadap events yang berlangsung di dalam klaster (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, +Komponen master dapat dijalankan di mesin manapun yang ada di klaster. 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/). +dapat dilihat di modul [Membangun Klaster HA] (/docs/admin/high-availability/). ### kube-apiserver @@ -109,18 +109,18 @@ Kubernetes mendukung beberapa runtime, diantaranya adalah: [Docker](http: ## Addons -Addons merupakan pod dan service yang mengimplementasikan fitur-fitur yang diperlukan kluster. +Addons merupakan pod dan service yang mengimplementasikan fitur-fitur yang diperlukan klaster. Beberapa addons akan dijelaskan selanjutnya. ### DNS -Meskipun tidak semua addons dibutuhkan, semua kluster Kubernetes hendaknya -memiliki DNS kluster. Komponen ini penting karena banyak dibutuhkan oleh komponen +Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendaknya +memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen lainnya. -[Kluster DNS](/en/docs/concepts/cluster-administration/addons/ ) adalah server DNS, selain beberapa server DNS lain yang sudah ada di +[Klaster 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 @@ -129,9 +129,9 @@ 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 -aplikasi yang ada pada kluster itu sendiri. +[Dasbor](/en/docs/tasks/access-application-cluster/web-ui-dashboard/) adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. +Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun +aplikasi yang ada pada klaster itu sendiri. ### Container Resource Monitoring diff --git a/content/id/docs/concepts/overview/kubernetes-api.md b/content/id/docs/concepts/overview/kubernetes-api.md index 03b2a34ba5..304a7e0b5f 100644 --- a/content/id/docs/concepts/overview/kubernetes-api.md +++ b/content/id/docs/concepts/overview/kubernetes-api.md @@ -64,7 +64,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github 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) +intra-klaster, 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 @@ -97,7 +97,7 @@ Kriteria untuk setiap tingkatan dideskripsikan secara lebih detail di dalam - 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 klaster 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. diff --git a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md index 040d11b286..ad7c0dcfcf 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -33,7 +33,7 @@ dalam dokumen ini: - *objek file konfigurasi / file konfigurasi*: Sebuah *file* yang mendefinisikan konfigurasi untuk sebuah objek Kubernetes. Dokumen ini akan memperlihatkan cara menggunakan *file* konfigurasi dengan perintah `kubectl apply`. *File-file* konfigurasi biasanya disimpan di sebuah *source control* seperti Git. -- *konfigurasi objek live / konfigurasi live*: nilai konfigurasi *live* dari sebuah objek, sebagaimana yang tersimpan di kluster Kubernetes. Nilai-nilai ini disimpan di *storage* kluster Kubernetes, biasanya etcd. +- *konfigurasi objek live / konfigurasi live*: nilai konfigurasi *live* dari sebuah objek, sebagaimana yang tersimpan di klaster Kubernetes. Nilai-nilai ini disimpan di *storage* klaster Kubernetes, biasanya etcd. - *writer konfigurasi deklaratif / writer deklaratif*: Seseorang atau sebuah komponen perangkat lunak yang membuat pembaruan ke objek *live*. *Live writer* yang disebut pada dokumen ini adalah *writer* yang membuat perubahan terhadap *file* konfigurasi objek dan menjalankan perintah `kubectl apply` untuk menulis perubahan-perubahan tersebut. ## Cara membuat objek diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md index 54938a1e75..3cf2103122 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-command.md @@ -69,7 +69,7 @@ Perangkat `kubectl` juga mendukung beberapa cara lain untuk memperbarui objek *l ## Cara menghapus objek -Kamu bisa menggunakan perintah `delete` pada sebuah objek dari sebuah kluster: +Kamu bisa menggunakan perintah `delete` pada sebuah objek dari sebuah klaster: - `delete /` diff --git a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md index 7e53d57b00..6390200bde 100644 --- a/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md +++ b/content/id/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -29,7 +29,7 @@ Kamu bisa menggunakan perintah `kubectl create -f` untuk membuat sebuah objek da ## Cara memperbarui objek {{< warning >}} -Memperbarui objek dengan perintah `replace` akan menghilangkan semua bagian dari spesifikasi objek yang tidak dispesifikasikan pada file konfigurasi. Oleh karena itu, perintah ini sebaiknya tidak digunakan terhadap objek-objek yang spesifikasinya sebagian dikelola oleh kluster, misalnya Service dengan tipe `LoadBalancer`, di mana *field* `externalIPs` dikelola secara terpisah dari file konfigurasi. *Field-field* yang dikelola secara terpisah harus disalin ke file konfigurasi untuk mencegah terhapus oleh perintah `replace`. +Memperbarui objek dengan perintah `replace` akan menghilangkan semua bagian dari spesifikasi objek yang tidak dispesifikasikan pada file konfigurasi. Oleh karena itu, perintah ini sebaiknya tidak digunakan terhadap objek-objek yang spesifikasinya sebagian dikelola oleh klaster, misalnya Service dengan tipe `LoadBalancer`, di mana *field* `externalIPs` dikelola secara terpisah dari file konfigurasi. *Field-field* yang dikelola secara terpisah harus disalin ke file konfigurasi untuk mencegah terhapus oleh perintah `replace`. {{< /warning >}} Kamu bisa menggunakan perintah `kubectl replace -f` untuk memperbarui sebuah objek *live* sesuai dengan sebuah file konfigurasi. diff --git a/content/id/docs/concepts/overview/working-with-objects/common-labels.md b/content/id/docs/concepts/overview/working-with-objects/common-labels.md index 5e36aa6ebf..0e1e62c3e1 100644 --- a/content/id/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/id/docs/concepts/overview/working-with-objects/common-labels.md @@ -60,7 +60,7 @@ metadata: ## Aplikasi dan Instans Aplikasi -Sebuah aplikasi dapat diinstal sekali atau beberapa kali di dalam kluster Kubernetes dan, +Sebuah aplikasi dapat diinstal sekali atau beberapa kali di dalam klaster Kubernetes dan, pada beberapa kasus, di dalam sebuah _namespace_ yang sama. Misalnya, wordpress dapat diinstal lebih dari satu kali dimana situs web yang berbeda merupakan hasil instalasi yang berbeda. 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 7cd1fc7fc0..02517e8ef8 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 @@ -17,7 +17,7 @@ dan bagaimana kamu dapat merepresentasikannya di dalam format `.yaml`. 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: +klaster 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 @@ -26,8 +26,8 @@ kluster kamu. Secara spesifik, hal itu dapat dideskripsikan sebagai: 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. +memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu inginkan pada _workload_ klaster yang kamu miliki; +dengan kata lain ini merupakan definisi _state_ klaster 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/). @@ -44,7 +44,7 @@ Status mendeskripsikan _state_ yang sebenarnya dari sebuah objek, dan hal ini di 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. +Sebagai contoh, _Deployment_ merupakan sebuah objek yang merepresentasikan sebuah aplikasi yang dijalankan di klaster 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. 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 5c22adc89e..a2315fd12e 100644 --- a/content/id/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/id/docs/concepts/overview/working-with-objects/namespaces.md @@ -6,7 +6,7 @@ weight: 30 {{% capture overview %}} -Kubernetes mendukung banyak kluster virtual di dalam satu kluster fisik. Kluster virtual tersebut disebut dengan *namespace*. +Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster virtual tersebut disebut dengan *namespace*. {{% /capture %}} @@ -15,11 +15,11 @@ Kubernetes mendukung banyak kluster virtual di dalam satu kluster fisik. Kluster ## Kapan menggunakan banyak Namespace -*Namespace* dibuat untuk digunakan di *environment* dengan banyak pengguna yang berada di dalam banyak tim ataupun proyek. Untuk sebuah kluster dengan beberapa pengguna saja, kamu tidak harus membuat ataupun memikirkan tentang *namespace*. Mulai gunakan *namespace* saat kamu membutuhkan fitur dari *namespace* itu sendiri. +*Namespace* dibuat untuk digunakan di *environment* dengan banyak pengguna yang berada di dalam banyak tim ataupun proyek. Untuk sebuah klaster dengan beberapa pengguna saja, kamu tidak harus membuat ataupun memikirkan tentang *namespace*. Mulai gunakan *namespace* saat kamu membutuhkan fitur dari *namespace* itu sendiri. *Namespace* menyediakan ruang untuk nama objek. Nama dari *resource* atau objek harus berbeda di dalam sebuah *namespace*, tetapi boleh sama jika berbeda *namespace*. *Namespace* tidak bisa dibuat di dalam *namespace* lain dan setiap *resource* atau objek Kubernetes hanya dapat berada di dalam satu *namespace*. -*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* kluster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)). +*Namespace* merupakan cara yang digunakan untuk memisahkan *resource* klaster untuk beberapa pengguna (dengan [*resource quota*](/docs/concepts/policy/resource-quotas/)). Dalam versi Kubernetes yang akan datang, objek di dalam satu *namespace* akan mempunyai *access control policies* yang sama secara *default*. @@ -32,7 +32,7 @@ Pembuatan dan penghapusan *namespace* dijelaskan di [dokumentasi panduan admin u ### Melihat namespace -Kamu dapat melihat daftar *namespace* di dalam kluster menggunakan: +Kamu dapat melihat daftar *namespace* di dalam klaster menggunakan: ```shell kubectl get namespace @@ -48,7 +48,7 @@ Kubernetes berjalan dengan tiga *namespace* awal: * `default`, *namespace default* untuk objek yang dibuat tanpa mencantumkan *namespace* pada spesifikasinya. * `kube-system`, *namespace* yang digunakan untuk objek yang dibuat oleh sistem Kubernetes. -* `kube-public`, *namespace* ini dibuat secara otomatis dan dapat diakses oleh semua pengguna (termasuk yang tidak diautentikasi). *Namespace* ini disediakan untuk penggunaan kluster, jika beberapa *resouce* harus terlihat dan dapat dibaca secara publik di seluruh kluster. Aspek publik dari *namespace* ini hanya sebuah konvensi, bukan persyaratan. +* `kube-public`, *namespace* ini dibuat secara otomatis dan dapat diakses oleh semua pengguna (termasuk yang tidak diautentikasi). *Namespace* ini disediakan untuk penggunaan klaster, jika beberapa *resouce* harus terlihat dan dapat dibaca secara publik di seluruh klaster. Aspek publik dari *namespace* ini hanya sebuah konvensi, bukan persyaratan. ### Mengkonfigurasi namespace untuk request diff --git a/content/id/docs/concepts/overview/working-with-objects/object-management.md b/content/id/docs/concepts/overview/working-with-objects/object-management.md index dd61ebe04a..aa9d8cbc9e 100644 --- a/content/id/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/id/docs/concepts/overview/working-with-objects/object-management.md @@ -28,10 +28,10 @@ beberapa metode untuk objek yang sama dapat menghasilkan perilaku yang tidak dii ## Perintah imperatif Ketika menggunakan perintah-perintah imperatif, seorang pengguna menjalankan operasi secara langsung -pada objek-objek _live_ dalam sebuah kluster. Pengguna menjalankan operasi tersebut melalui +pada objek-objek _live_ dalam sebuah klaster. Pengguna menjalankan operasi tersebut melalui argumen atau _flag_ pada perintah `kubectl`. -Ini merupakan cara yang paling mudah untuk memulai atau menjalankan tugas "sekali jalan" pada sebuah kluster. +Ini merupakan cara yang paling mudah untuk memulai atau menjalankan tugas "sekali jalan" pada sebuah klaster. Karena metode ini dijalankan secara langsung pada objek _live_, tidak ada _history_ yang menjelaskan konfigurasi-konfigurasi terkait sebelumnya. ### Contoh @@ -53,7 +53,7 @@ kubectl create deployment nginx --image nginx Beberapa kelebihan metode ini dibandingkan metode konfigurasi objek: - Sederhana, mudah dipelajari dan diingat. -- Hanya memerlukan satu langkah untuk membuat perubahan pada kluster. +- Hanya memerlukan satu langkah untuk membuat perubahan pada klaster. Beberapa kekurangan metode ini dibandingkan metode konfigurasi objek: @@ -78,7 +78,7 @@ membuang semua perubahan terhadap objek tersebut yang tidak didefinisikan pada b Metode ini sebaiknya tidak dilakukan pada tipe sumber daya yang spek-nya diperbarui secara independen di luar berkas konfigurasi. Service dengan tipe `LoadBalancer`, sebagai contoh, memiliki _field_ `externalIPs` yang diperbarui secara independen di luar konfigurasi, dilakukan -oleh kluster. +oleh klaster. {{< /warning >}} ### Contoh diff --git a/content/id/docs/concepts/policy/pod-security-policy.md b/content/id/docs/concepts/policy/pod-security-policy.md index 9e572c88bd..0337db0f6c 100644 --- a/content/id/docs/concepts/policy/pod-security-policy.md +++ b/content/id/docs/concepts/policy/pod-security-policy.md @@ -16,7 +16,7 @@ Pod Security Policies (kebijakan keamanan Pod) memungkinkan otorisasi secara det ## Apa itu Pod Security Policy? -_Pod Security Policy_ adalah sebuah sumber daya pada tingkat kluster yang mengatur aspek-aspek spesifikasi Pod yang sensitif terhadap keamanan. Objek-objek `PodSecurityPolicy` mendefinisikan sebuah kumpulan kondisi yang harus dijalankan oleh Pod untuk dapat diterima oleh sistem, dan juga sebagai nilai-nilai bawaan untuk kolom-kolom yang bersangkutan. Mereka memungkinkan administrator untuk mengatur hal-hal berikut: +_Pod Security Policy_ adalah sebuah sumber daya pada tingkat klaster yang mengatur aspek-aspek spesifikasi Pod yang sensitif terhadap keamanan. Objek-objek `PodSecurityPolicy` mendefinisikan sebuah kumpulan kondisi yang harus dijalankan oleh Pod untuk dapat diterima oleh sistem, dan juga sebagai nilai-nilai bawaan untuk kolom-kolom yang bersangkutan. Mereka memungkinkan administrator untuk mengatur hal-hal berikut: | Aspek yang diatur | Nama Kolom | | ----------------------------------------------------| ------------------------------------------- | @@ -39,9 +39,9 @@ _Pod Security Policy_ adalah sebuah sumber daya pada tingkat kluster yang mengat ## Mengaktifkan Pod Security Policy -Pengaturan Pod Security Policy diimplementasi sebagai sebuah opsi (tapi direkomendasikan untuk digunakan) dari [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). PodSecurityPolicy dilaksanakan dengan [mengaktifkan _admission controller_-nya](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), tetapi melakukan hal ini tanpa mengizinkan kebijakan apapun **akan menghalangi Pod apapun untuk dibuat** di dalam kluster. +Pengaturan Pod Security Policy diimplementasi sebagai sebuah opsi (tapi direkomendasikan untuk digunakan) dari [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). PodSecurityPolicy dilaksanakan dengan [mengaktifkan _admission controller_-nya](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), tetapi melakukan hal ini tanpa mengizinkan kebijakan apapun **akan menghalangi Pod apapun untuk dibuat** di dalam klaster. -Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifkan secara independen dari _admission controller_, untuk kluster-kluster yang sudah ada direkomendasikan untuk menambahkan dan mengizinkan kebijakan yang bersangkutan sebelum mengaktifkan _admission controller_ tersebut. +Sejak API dari Pod Security Policy (`policy/v1beta1/podsecuritypolicy`) diaktifkan secara independen dari _admission controller_, untuk klaster-klaster yang sudah ada direkomendasikan untuk menambahkan dan mengizinkan kebijakan yang bersangkutan sebelum mengaktifkan _admission controller_ tersebut. ## Mengizinkan Kebijakan @@ -123,7 +123,7 @@ Saat operasi pembaruan (saat ini mutasi terhadap spesifikasi Pod tidak diizinkan ## Contoh -_Contoh ini mengasumsikan kamu telah memiliki kluster yang berjalan dengan _admission controller_ PodSecurityPolicy diaktifkan, dan kamu mempunyai akses admin._ +_Contoh ini mengasumsikan kamu telah memiliki klaster yang berjalan dengan _admission controller_ PodSecurityPolicy diaktifkan, dan kamu mempunyai akses admin._ ### Persiapan 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 174c87067b..7104af5409 100644 --- a/content/id/docs/concepts/services-networking/connect-applications-service.md +++ b/content/id/docs/concepts/services-networking/connect-applications-service.md @@ -13,7 +13,7 @@ Sekarang kamu memiliki aplikasi yang telah direplikasi, kamu dapat mengeksposnya Secara *default*, *Docker* menggunakan jaringan *host*, jadi kontainer dapat berkomunikasi dengan kontainer lainnya jika mereka berada di dalam *node* yang sama. Agar kontainer *Docker* dapat berkomunikasi antar *node*, masing-masing kontainer tersebut harus diberikan *port* yang berbeda di alamat IP *node* tersebut, yang akan diteruskan (*proxied*) ke dalam kontainer. Artinya adalah para kontainer di dalam sebuah *node* harus berkoordinasi *port* mana yang akan digunakan atau dialokasikan secara otomatis. -Akan sulit untuk mengkoordinasikan *port* yang digunakan oleh banyak pengembang. Kubernetes mengasumsikan bahwa *Pod* dapat berkomunikasi dengan *Pod* lain, terlepas di *Node* mana *Pod* tersebut di *deploy*. Kubernetes memberikan setiap *Pod* alamat *ClusterIP* sehingga kamu tidak perlu secara explisit membuat jalur antara *Pod* ataupun memetakan *port* kontainer ke dalam *port* di dalam *Node* tersebut. Ini berarti kontainer di dalam sebuah *Pod* dapat berkomunikasi dengan *localhost* via *port*, dan setiap *Pod* di dalam kluster dapat berkomunikasi tanpa *NAT*. Panduan ini akan membahas bagaimana kamu dapat menjalankan sebuah layanan atau aplikasi di dalam model jaringan di atas. +Akan sulit untuk mengkoordinasikan *port* yang digunakan oleh banyak pengembang. Kubernetes mengasumsikan bahwa *Pod* dapat berkomunikasi dengan *Pod* lain, terlepas di *Node* mana *Pod* tersebut di *deploy*. Kubernetes memberikan setiap *Pod* alamat *ClusterIP* sehingga kamu tidak perlu secara explisit membuat jalur antara *Pod* ataupun memetakan *port* kontainer ke dalam *port* di dalam *Node* tersebut. Ini berarti kontainer di dalam sebuah *Pod* dapat berkomunikasi dengan *localhost* via *port*, dan setiap *Pod* di dalam klaster dapat berkomunikasi tanpa *NAT*. Panduan ini akan membahas bagaimana kamu dapat menjalankan sebuah layanan atau aplikasi di dalam model jaringan di atas. Panduan ini menggunakan server *nginx* sederhana untuk mendemonstrasikan konsepnya. Konsep yang sama juga ditulis lebih lengkap di [Aplikasi Jenkins CI](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes). @@ -21,13 +21,13 @@ Panduan ini menggunakan server *nginx* sederhana untuk mendemonstrasikan konsepn {{% capture body %}} -## Mengekspos Pod ke dalam kluster +## Mengekspos Pod ke dalam klaster Kita melakukan ini di beberapa contoh sebelumnya, tetapi mari kita lakukan sekali lagi dan berfokus pada prespektif jaringannya. Buat sebuah *nginx Pod*, dan perhatikan bahwa templat tersebut mempunyai spesifikasi *port* kontainer: {{< codenew file="service/networking/run-my-nginx.yaml" >}} -Ini membuat aplikasi tersebut dapat diakses dari *node* manapun di dalam kluster kamu. Cek lokasi *node* dimana *Pod* tersebut berjalan: +Ini membuat aplikasi tersebut dapat diakses dari *node* manapun di dalam klaster kamu. Cek lokasi *node* dimana *Pod* tersebut berjalan: ```shell kubectl apply -f ./run-my-nginx.yaml kubectl get pods -l run=my-nginx -o wide @@ -45,15 +45,15 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP podIP: 10.244.2.5 ``` -Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam kluster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam kluster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya. +Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya. Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran. ## Membuat Service -Kita mempunyai *Pod* yang menjalankan *nginx* di dalam kluster. Teorinya, kamu dapat berkomunikasi ke *Pod* tersebut secara langsung, tapi apa yang terjadi jika sebuah *node* mati? *Pod* di dalam *node* tersebut ikut mati, dan *Deployment* akan membuat *Pod* baru, dengan IP yang berbeda. Ini adalah masalah yang *Service* selesaikan. +Kita mempunyai *Pod* yang menjalankan *nginx* di dalam klaster. Teorinya, kamu dapat berkomunikasi ke *Pod* tersebut secara langsung, tapi apa yang terjadi jika sebuah *node* mati? *Pod* di dalam *node* tersebut ikut mati, dan *Deployment* akan membuat *Pod* baru, dengan IP yang berbeda. Ini adalah masalah yang *Service* selesaikan. -*Service* Kubernetes adalah sebuah abstraksi yang mendefinisikan sekumpulan *Pod* yang menyediakan fungsi yang sama dan berjalan di dalam kluster. Saat dibuat, setiap *Service* diberikan sebuah alamat IP (disebut juga *ClusterIP*). Alamat ini akan terus ada, dan tidak akan pernah berubah selama *Service* hidup. *Pod* dapat berkomunikasi dengan *Service* dan trafik yang menuju *Service* tersebut akan otomatis dilakukan mekanisme *load balancing* ke *Pod* yang merupakan anggota dari *Service* tersebut. +*Service* Kubernetes adalah sebuah abstraksi yang mendefinisikan sekumpulan *Pod* yang menyediakan fungsi yang sama dan berjalan di dalam klaster. Saat dibuat, setiap *Service* diberikan sebuah alamat IP (disebut juga *ClusterIP*). Alamat ini akan terus ada, dan tidak akan pernah berubah selama *Service* hidup. *Pod* dapat berkomunikasi dengan *Service* dan trafik yang menuju *Service* tersebut akan otomatis dilakukan mekanisme *load balancing* ke *Pod* yang merupakan anggota dari *Service* tersebut. Kamu dapat membuat *Service* untuk replika 2 *nginx* dengan `kubectl explose`: @@ -107,12 +107,12 @@ NAME ENDPOINTS AGE my-nginx 10.244.2.5:80,10.244.3.4:80 1m ``` -Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di kluster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). +Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `:` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies). ## Mengakses Service 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). +*DNS* membutuhkan [tambahan CoreDNS di dalam klaster](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). ### Variabel Environment @@ -155,7 +155,7 @@ KUBERNETES_SERVICE_PORT_HTTPS=443 ### DNS -Kubernetes menawarkan sebuah layanan *DNS* kluster tambahan yang secara otomatis memberikan sebuah nama *dns* pada *Service*. Kamu dapat mengecek jika *DNS* berjalan di dalam kluster Kubernetes: +Kubernetes menawarkan sebuah layanan *DNS* klaster tambahan yang secara otomatis memberikan sebuah nama *dns* pada *Service*. Kamu dapat mengecek jika *DNS* berjalan di dalam klaster Kubernetes: ```shell kubectl get services kube-dns --namespace=kube-system @@ -167,7 +167,7 @@ kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m Jika *DNS* belum berjalan, kamu dapat [mengaktifkannya](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it). -Sisa panduan ini mengasumsikan kamu mempunyai *Service* dengan IP (my-nginx), dan sebuah server *DNS* yang memberikan nama ke dalam IP tersebut (CoreDNS kluster), jadi kamu dapat berkomunikasi dengan *Service* dari *Pod* lain di dalam kluster menggunakan metode standar (contohnya *gethostbyname*). Jalankan aplikasi *curl* lain untuk melakukan pengujian ini: +Sisa panduan ini mengasumsikan kamu mempunyai *Service* dengan IP (my-nginx), dan sebuah server *DNS* yang memberikan nama ke dalam IP tersebut (CoreDNS klaster), jadi kamu dapat berkomunikasi dengan *Service* dari *Pod* lain di dalam klaster menggunakan metode standar (contohnya *gethostbyname*). Jalankan aplikasi *curl* lain untuk melakukan pengujian ini: ```shell kubectl run curl --image=radial/busyboxplus:curl -i --tty @@ -190,7 +190,7 @@ Address 1: 10.0.162.149 ## Mengamankan Service -Hingga sekarang kita hanya mengakses *nginx* server dari dalam kluster. Sebelum mengekspos *Service* ke internet, kamu harus memastikan bahwa kanal komunikasi aman. Untuk melakukan hal tersebut, kamu membutuhkan: +Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum mengekspos *Service* ke internet, kamu harus memastikan bahwa kanal komunikasi aman. Untuk melakukan hal tersebut, kamu membutuhkan: * *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*) * Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut @@ -346,7 +346,7 @@ curl https:// -k Welcome to nginx! ``` -IP address pada kolom `EXTERNAL-IP` menunjukan IP yang tersedia di internet. Sedangkan kolom `CLUSTER-IP` merupakan IP yang hanya tersedia di dalam kluster kamu (*IP private*). +IP address pada kolom `EXTERNAL-IP` menunjukan IP yang tersedia di internet. Sedangkan kolom `CLUSTER-IP` merupakan IP yang hanya tersedia di dalam klaster kamu (*IP private*). Perhatikan pada *AWS*, tipe `LoadBalancer` membuat sebuah *ELB*, yang menggunakan *hostname* yang panjang, bukan IP. Karena tidak semua keluar pada standar keluaran `kubectl get svc`. Jadi kamu harus menggunakan `kubectl describe service my-nginx` untuk melihatnya. Kamu akan melihat seperti ini: @@ -361,6 +361,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el {{% capture whatsnext %}} -Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak kluster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut. +Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut. {{% /capture %}} diff --git a/content/id/docs/concepts/services-networking/dns-pod-service.md b/content/id/docs/concepts/services-networking/dns-pod-service.md index 79ed200cae..f6b333319e 100644 --- a/content/id/docs/concepts/services-networking/dns-pod-service.md +++ b/content/id/docs/concepts/services-networking/dns-pod-service.md @@ -11,15 +11,15 @@ Laman ini menyediakan ikhtisar dari dukungan DNS oleh Kubernetes. ## Pendahuluan -Kubernetes DNS melakukan _scheduling_ DNS Pod dan Service yang ada pada kluster, serta +Kubernetes DNS melakukan _scheduling_ DNS Pod dan Service yang ada pada klaster, serta melakukan konfigurasi kubelet untuk memberikan informasi bagi setiap Container untuk menggunakan DNS Service IP untuk melakukan resolusi DNS. ### Apa Sajakah yang Mendapatkan Nama DNS? -Setiap Service yang didefinisikan di dalam kluster (termasuk server DNS itu sendiri) +Setiap Service yang didefinisikan di dalam klaster (termasuk server DNS itu sendiri) memiliki nama DNS. Secara default, sebuah _list_ pencarian DNS pada Pod klien -akan mencantumkan _namespace_ Pod itu sendiri serta domain _default_ kluster. Hal ini dapat diilustrasikan +akan mencantumkan _namespace_ Pod itu sendiri serta domain _default_ klaster. Hal ini dapat diilustrasikan dengan contoh berikut: Asumsikan sebuah Service dengan nama `foo` pada Kubernetes dengan _namespace_ `bar`. @@ -39,9 +39,9 @@ terbaru kamu dapat membaca [Service Discovery pada Kubernetes berbasis DNS](http Service "Normal" (bukan _headless_) akan diberikan sebuah A _record_ untuk sebuah nama dalam bentuk `my-svc.my-namespace.svc.cluster-domain.example`. Inilah yang kemudian digunakan untuk melakukan -resolusi IP kluster dari Service tersebut. +resolusi IP klaster dari Service tersebut. -Service "Headless" (tanpa IP kluster) juga memiliki sebuah A _record_ DNS dengan format +Service "Headless" (tanpa IP klaster) juga memiliki sebuah A _record_ DNS dengan format `my-svc.my-namespace.svc.cluster-domain.example`. Tidak seperti halnya Service normal, DNS ini akan melakukan resolusi pada serangkauan IP dari Pod yang dipilih oleh Service tadi. Klien diharapkan untuk mengkonsumsi serangkaian IP ini atau cara lain yang digunakan adalah pemilihan @@ -123,7 +123,7 @@ spec: ``` Jika terdapat sebuah Service _headless_ memiliki nama yang sama dengan -subdomain dari suatu Pod pada _namespace_ yang sama, server KubeDNS kluster akan mengembalikan +subdomain dari suatu Pod pada _namespace_ yang sama, server KubeDNS klaster akan mengembalikan A _record_ untuk FQDN Pod. Sebagai contoh, misalnya terdapat sebuah Pod dengan _hostname_ "`busybox-1`" dan subdomain "`default-subdomain`", serta sebuah Service _headless_ dengan nama "`default-subdomain`" @@ -154,9 +154,9 @@ dispesifikasikan pada _field_ `dnsPolicy` yang ada pada spek Pod. dimana Pod tersebut dijalankan. Silakan baca [diskusi terkait](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) untuk detailnya. -- "`ClusterFirst`": _Query_ DNS apa pun yang tidak sesuai dengan sufiks domain kluster yang sudah dikonfigurasi +- "`ClusterFirst`": _Query_ DNS apa pun yang tidak sesuai dengan sufiks domain klaster yang sudah dikonfigurasi misalnya "`www.kubernetes.io`", akan di-_forward_ ke _nameserver_ _upstream_ yang diwarisi dari Node. - Administrator kluster bisa saja memiliki _stub-domain_ atau DNS _usptream_ lain yang sudah dikonfigurasi. + Administrator klaster bisa saja memiliki _stub-domain_ atau DNS _usptream_ lain yang sudah dikonfigurasi. Silakan lihat [diskusi terkait](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods) untuk detail lebih lanjut mengenai bagaimana _query_ DNS melakukan hal tersebut. - "`ClusterFirstWithHostNet`": Untuk Pod yang dijalankan dengan menggunakan `hostNetwork`, kamu harus diff --git a/content/id/docs/concepts/services-networking/ingress-controllers.md b/content/id/docs/concepts/services-networking/ingress-controllers.md index f5218696f6..c6262ec91f 100644 --- a/content/id/docs/concepts/services-networking/ingress-controllers.md +++ b/content/id/docs/concepts/services-networking/ingress-controllers.md @@ -7,11 +7,11 @@ weight: 40 {{% capture overview %}} Agar Ingress dapat bekerja sebagaimana mestinya, -sebuah kluster harus memiliki paling tidak sebuah kontroler Ingress. +sebuah klaster 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 +tidak secara otomatis dijalankan di dalam klaster. Kamu bisa menggunakan laman ini untuk memilih implementasi kontroler Ingress yang kamu pikir paling sesuai dengan kebutuhan kamu. @@ -52,10 +52,10 @@ Kubernetes sebagai sebuah proyek, saat ini, mendukung dan memaintain kontroler-k ## 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 +dalam sebuah klaster. 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. +klaster kamu. Apabila kamu tidak mendefinisikan `class` yang dipakai, penyedia layanan *cloud* kamu akan menggunakan kontroler Ingress *default* yang mereka miliki. diff --git a/content/id/docs/concepts/services-networking/ingress.md b/content/id/docs/concepts/services-networking/ingress.md index d6ffbc6e06..905f6b03bb 100644 --- a/content/id/docs/concepts/services-networking/ingress.md +++ b/content/id/docs/concepts/services-networking/ingress.md @@ -13,16 +13,16 @@ weight: 40 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*. -* *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. +* Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes. +* Klaster: 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 klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras. +* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster 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 klaster. ## Apakah *Ingress* itu? 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. +{{< link text="services" url="/docs/concepts/services-networking/service/" >}} di dalam klaster. Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pada *Ingress*. ```none @@ -33,7 +33,7 @@ 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 klaster), 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 @@ -450,7 +450,7 @@ Ingress yang ingin diubah. 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) 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 klaster. ## Pengembangan selanjutnya diff --git a/content/id/docs/concepts/services-networking/network-policies.md b/content/id/docs/concepts/services-networking/network-policies.md index 7e5b87d296..644a3c8cc2 100644 --- a/content/id/docs/concepts/services-networking/network-policies.md +++ b/content/id/docs/concepts/services-networking/network-policies.md @@ -151,9 +151,9 @@ 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. +alamat IP eksternal klaster, karena alamat IP Pod bersifat _ephemeral_ dan tidak dapat ditebak. -Mekanisme _ingress_ dan _egress_ kluster seringkali membutuhkan mekanisme _rewrite_ alamat IP _source_ dan destinasi +Mekanisme _ingress_ dan _egress_ klaster 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. @@ -162,7 +162,7 @@ Pada _ingress_, artinya bisa saja kamu melakukan _filter_ paket yang masuk berda 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 klaster atau bahkan tidak termasuk di dalam `ipBlock` _policy_. ## _Policy_ _Default_ @@ -270,7 +270,7 @@ Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` tidak {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -Kubernetes mendukung SCTP sebagai _value_ `protocol` pada definisi `NetworkPolicy` sebagai fitur alpha. Untuk mengaktifkan fitur ini, administrator kluster harus mengaktifkan gerbang fitur `SCTPSupport` pada `apiserver`, contohnya `“--feature-gates=SCTPSupport=true,...”`. Ketika gerbang fitur ini diaktifkan, pengguna dapat menerapkan `value` dari _field_ `protocol` pada `NetworkPolicy` menjadi `SCTP`. Kubernetes akan mengatur jaringan sesuai dengan SCTP, seperti halnya koneksi TCP. +Kubernetes mendukung SCTP sebagai _value_ `protocol` pada definisi `NetworkPolicy` sebagai fitur alpha. Untuk mengaktifkan fitur ini, administrator klaster harus mengaktifkan gerbang fitur `SCTPSupport` pada `apiserver`, contohnya `“--feature-gates=SCTPSupport=true,...”`. Ketika gerbang fitur ini diaktifkan, pengguna dapat menerapkan `value` dari _field_ `protocol` pada `NetworkPolicy` menjadi `SCTP`. Kubernetes akan mengatur jaringan sesuai dengan SCTP, seperti halnya koneksi TCP. _Plugin_ CNI harus mendukung SCTP sebagai _value_ dari `protocol` pada `NetworkPolicy`. diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md index f2d2bf9125..7ae2d39b65 100644 --- a/content/id/docs/concepts/services-networking/service.md +++ b/content/id/docs/concepts/services-networking/service.md @@ -20,7 +20,7 @@ Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat men 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 -kluster Kubernetes, bagaimana cara _frontend_ menemukan _backend_ mana yang digunakan? +klaster Kubernetes, bagaimana cara _frontend_ menemukan _backend_ mana yang digunakan? Inilah alasan kenapa `Service` ada. @@ -95,9 +95,9 @@ 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. + [_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda. * Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih - berada di luar kluster Kubernetes. + berada di luar klaster Kubernetes. Berdasarkan skenario-skenario di atas, kamu dapat membuat sebuah `Service` tanpa _selector_: @@ -145,7 +145,7 @@ informasi lebih lanjut silahkan baca bagian [ExternalName](#externalname). ## IP Virtual dan _proxy_ `Service` -Setiap *node* di kluster Kubernetes menjalankan `kube-proxy`. `kube-proxy` +Setiap *node* di klaster Kubernetes menjalankan `kube-proxy`. `kube-proxy` bertanggung jawab terhadap implementasi IP virtual bagi _Services_ dengan tipe selain [`ExternalName`](#externalname). @@ -322,7 +322,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini. 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 +_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis dapat melakukan resolusi DNS. Sebagai contoh, apabila kamu memiliki sebuah `Service` dengan nama `"my-service"` pada _Namespace_ @@ -376,7 +376,7 @@ sistem DNS tetap melakukan konfigurasi salah satu dari: 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). +ke alamat IP eksternal (di luar klaster Kubernetes). `ServiceTypes` yang ada pada Kubernetes memungkinkan kamu untuk menentukan jenis `Service` apakah yang kamu butuhkan. Secara _default_, jenis `Service` @@ -384,13 +384,13 @@ 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 + * `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam klaster. 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 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 `:`. + dari luar klaster melalui `:`. * [`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. @@ -463,12 +463,12 @@ tetapi penyedia layanan _cloud_ tidak mendukung hal ini, maka _field_ yang ada a **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`. +_resource group_ dari _resource_ yang secara otomatis dibuat oleh klaster. 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). +[_CreatingLoadBalancerFailed_ pada klaster AKS dengan _advanced networking_](https://github.com/Azure/AKS/issues/357). {{< note >}} Dukungan untuk SCTP _load balancer_ dari penyedia layanan _cloud_ bergantung pada @@ -547,7 +547,7 @@ metadata: #### Dukungan untuk SSL di AWS -Dukungan parsial untuk SSL bagi kluster yang dijalankan di AWS mulai diterapkan, +Dukungan parsial untuk SSL bagi klaster yang dijalankan di AWS mulai diterapkan, mulai versi 1.3 terdapat 3 anotasi yang dapat ditambahkan pada `Service` dengan tipe `LoadBalancer`: @@ -616,7 +616,7 @@ _Policy_ ini kemudian dapat dispesifikasikan menggunakan anotasi #### Protokol PROXY pada AWS Untuk mengaktifkan dukungan [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) -untuk kluster yang dijalankan di AWS, kamu dapat menggunakan anotasi di bawah ini: +untuk klaster yang dijalankan di AWS, kamu dapat menggunakan anotasi di bawah ini: ```yaml metadata: @@ -806,11 +806,11 @@ Untuk melakukan _hardcode_ alamat IP, kamu dapat menggunakan _headless_ `Service {{< /note >}} Ketika melakukan pencarian _host_ `my-service.prod.svc.cluster.local`, -servis DNS kluster akan mengembalikan _record_ `CNAME` dengan _value_ `my.database.example.com`. +servis DNS klaster 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 +yang kamu pakai ke dalam klaster, 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. @@ -821,11 +821,11 @@ 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 +Jika terdapat sebuah alamat IP eksternal yang melakukan mekanisme _route_ ke satu atau lebih _node_ yang ada di klaster, `Service` Kubernetes dapat diekspos +dengan menggunakan `externalIP`. Trafik yang diarahkan ke klaster 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. +dari administrator klaster. 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`). @@ -850,13 +850,13 @@ 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`. +meski begitu hal ini tidak _scalable_ untuk klaster 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, +_Proxy_ `iptables` tidak menghilangkan _source IP_ yang berasal dari dalam klaster, meski begitu, hal ini masih berimbas pada klien yang berasal dari `Service` dengan tipe _load-balancer_ atau _node-port_. @@ -924,7 +924,7 @@ perbedaan cara kerja satu sama lainnya. 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. +maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di klaster. 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. @@ -943,7 +943,7 @@ tanpa harus mengetahui `Pod` mana yang sebenarnya diakses. 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. +maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di klaster. 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) @@ -960,7 +960,7 @@ atau _load-balancer_, meskipun pada dua kasus di atas klien IP tidak akan mengal #### _Ipvs_ -Operasi `iptables` berlangsung secara lambat pada kluster dengan skala besar (lebih dari 10.000 `Service`). +Operasi `iptables` berlangsung secara lambat pada klaster 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 @@ -1025,7 +1025,7 @@ yang kemudian diikuti data dari klien. 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 +administrator klaster 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, diff --git a/content/id/docs/concepts/storage/dynamic-provisioning.md b/content/id/docs/concepts/storage/dynamic-provisioning.md index d07b69c2f4..2d346ff80e 100644 --- a/content/id/docs/concepts/storage/dynamic-provisioning.md +++ b/content/id/docs/concepts/storage/dynamic-provisioning.md @@ -7,9 +7,9 @@ weight: 40 {{% capture overview %}} Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (_on-demand_). -Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin kluster secara manual harus +Tanpa adanya penyediaan dinamis (_dynamic provisioning_), untuk membuat volume penyimpanan baru, admin klaster secara manual harus memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat [objek PersistentVolume](/docs/concepts/storage/persistent-volumes/) -sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin kluster untuk menyediakan +sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan penyimpanan sebelumnya (_pre-provision_). Dengan demikian, penyimpanan akan tersedia secara otomatis ketika diminta oleh pengguna. @@ -21,13 +21,13 @@ ketika diminta oleh pengguna. ## Latar Belakang Penyediaan volume dinamis diimplementasi berdasarkan objek API StorageClass dari -grup API `storage.k8s.io`. Seorang admin kluster dapat mendefinisikan berbagai macam +grup API `storage.k8s.io`. Seorang admin klaster dapat mendefinisikan berbagai macam objek StorageClass sesuai kebutuhan, masing-masing menentukan *plugin volume* (disebut juga *provisioner*) yang menyediakan sebuah volume beserta kumpulan parameter untuk diteruskan oleh _provisioner_ ketika proses penyediaan. -Seorang kluster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan -(dari sistem penyimpanan yang sama maupun berbeda) di dalam kluster, masing-masing dengan +Seorang klaster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan +(dari sistem penyimpanan yang sama maupun berbeda) di dalam klaster, masing-masing dengan kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu khawatir betapa rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk memilih berbagai macam pilihan penyimpanan. @@ -36,7 +36,7 @@ Info lebih lanjut mengenai _storage class_ dapat dilihat [di sini](/docs/concept ## Mengaktifkan Penyediaan Dinamis (_Dynamic Provisioning_) -Untuk mengaktifkan penyediaan dinamis, seorang admin kluster perlu untuk +Untuk mengaktifkan penyediaan dinamis, seorang admin klaster perlu untuk terlebih dahulu membuat (_pre-create_) satu atau beberapa objek StorageClass untuk pengguna. Objek StorageClass mendefinisikan _provisioner_ mana yang seharusnya digunakan @@ -100,9 +100,9 @@ Ketika klaim dihilangkan, volume akan musnah. ## Perilaku _Default_ -Penyediaan dinamis dapat diaktifkan pada setiap kluster supaya semua klaim +Penyediaan dinamis dapat diaktifkan pada setiap klaster supaya semua klaim dapat disediakan secara dinamis jika tidak ada StorageClass yang dispesifikasikan. -Seorang kluster admin dapat mengaktifkan perilaku ini dengan cara: +Seorang klaster admin dapat mengaktifkan perilaku ini dengan cara: - Menandai satu objek StorageClass sebagai _default_; - Memastikan bahwa [_admission controller_ `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) @@ -110,17 +110,17 @@ Seorang kluster admin dapat mengaktifkan perilaku ini dengan cara: Seorang admin dapat menandai StorageClass yang spesifik sebagai _default_ dengan menambahkan anotasi `storageclass.kubernetes.io/is-default-class`. -Ketika StorageClass default tersebut ada pada kluster dan pengguna membuat PersistentVolumeClaim +Ketika StorageClass default tersebut ada pada klaster dan pengguna membuat PersistentVolumeClaim tanpa menspesifikasikan `storageClassName`, _admission controller_ `DefaultStorageClass` secara otomatis menambahkan _field_ `storageClassName` dengan StorageClass _default_. -Perhatikan bahwa hanya bisa ada satu _default_ StorageClass pada sebuah kluster, +Perhatikan bahwa hanya bisa ada satu _default_ StorageClass pada sebuah klaster, atau PersistentVolumeClaim tanpa menspesifikasikan `storageClassName` secara eksplisit tidak bisa terbuat. ## Kesadaran (_Awareness_) Topologi -Pada kluster [Multi-Zona](/docs/setup/multiple-zones), Pod dapat tersebar di banyak Zona +Pada klaster [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 [Mode Volume Binding](/docs/concepts/storage/storage-classes/#volume-binding-mode). diff --git a/content/id/docs/concepts/storage/persistent-volumes.md b/content/id/docs/concepts/storage/persistent-volumes.md index e334a4182c..a6cf661653 100644 --- a/content/id/docs/concepts/storage/persistent-volumes.md +++ b/content/id/docs/concepts/storage/persistent-volumes.md @@ -22,13 +22,13 @@ Dokumen ini menjelaskan kondisi terkini dari `PersistentVolumes` pada Kubernetes Mengelola penyimpanan adalah hal yang berbeda dengan mengelola komputasi. Sub-sistem `PersistentVolume` (PV) menyediakan API untuk para pengguna dan administrator yang mengabstraksi detail-detail tentang bagaimana penyimpanan disediakan dari bagaimana penyimpanan dikonsumsi. Untuk melakukan ini, kami mengenalkan dua sumber daya API baru: `PersistentVolume` (PV) dan `PersistentVolumeClaim` (PVC). -Sebuah `PersistentVolume` (PV) adalah suatu bagian dari penyimpanan pada kluster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada kluster sama halnya dengan _node_ yang juga merupakan sumber daya kluster. PV adalah _volume plugin_ seperti _Volumes_, tetapi memiliki siklus hidup yang independen dari _pod_ individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan _cloud_. +Sebuah `PersistentVolume` (PV) adalah suatu bagian dari penyimpanan pada klaster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada klaster sama halnya dengan _node_ yang juga merupakan sumber daya klaster. PV adalah _volume plugin_ seperti _Volumes_, tetapi memiliki siklus hidup yang independen dari _pod_ individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan _cloud_. Sebuah `PersistentVolumeClaim` (PVC) merupakan permintaan penyimpanan oleh pengguna. PVC mirip dengan sebuah _pod_. _Pod_ mengonsumsi sumber daya _node_ dan PVC mengonsumsi sumber daya PV. _Pods_ dapat meminta taraf-taraf spesifik dari sumber daya (CPU dan Memory). Klaim dapat meminta ukuran dan mode akses yang spesifik (seperti, dapat dipasang sekali sebagai _read/write_ atau lain kali sebagai _read-only_). Meskipun `PersistentVolumeClaims` mengizinkan pengguna untuk mengkonsumsi sumber daya penyimpanan abstrak, pada umumnya para pengguna membutuhkan `PersistentVolumes` dengan properti yang -bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator kluster +bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator klaster harus dapat menawarkan berbagai macam `PersistentVolumes` yang berbeda tidak hanya pada ukuran dan mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimplementasikan kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya @@ -39,20 +39,20 @@ Silakan lihat [panduan mendetail dengan contoh-contoh yang sudah berjalan](/docs ## Siklus hidup dari sebuah volume dan klaim -PV adalah sumber daya dalam sebuah kluster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini: +PV adalah sumber daya dalam sebuah klaster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini: ### Penyediaan Ada dua cara untuk menyediakan PV: secara statis atau dinamis. #### Statis -Seorang administrator kluster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna kluster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan. +Seorang administrator klaster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna klaster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan. #### Dinamis -Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan `PersistentVolumeClaim` (PVC) yang dibuat oleh pengguna, kluster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC. +Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan `PersistentVolumeClaim` (PVC) yang dibuat oleh pengguna, klaster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC. Penyediaan dinamis ini berbasis `StorageClass`: artinya PVC harus meminta sebuah _storage class_ dan _storage class_ tersebut harus sudah dibuat dan dikonfigurasi oleh administrator agar penyediaan dinamis bisa terjadi. Klaim yang meminta PV dengan _storage class_ `""` secara efektif telah menonaktifkan penyediaan dinamis. -Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, administrator kluster harus mengaktifkan [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) +Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, administrator klaster harus mengaktifkan [_admission controller_](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` pada API _server_. Hal ini dapat dilakukan, dengan cara memastikan `DefaultStorageClass` ada di antara urutan daftar _value_ yang dibatasi koma untuk _flag_ `--enable-admission-plugins` pada komponen API _server_. Untuk informasi lebih lanjut mengenai _flag_ perintah pada API _server_, silakan cek dokumentasi, [kube-apiserver](/docs/admin/kube-apiserver/). @@ -60,11 +60,11 @@ Untuk mengaktifkan penyediaan _storage_ dinamis berdasarkan _storage class_, adm Seorang pengguna membuat, atau telah membuat (dalam kasus penyediaan dinamis), sebuah `PersistentVolumeClaim` (PVC) dengan jumlah penyimpanan spesifik yang diminta dan dengan mode akses tertentu. Sebuah _control loop_ pada _master_ akan melihat adanya PVC baru, mencari PV yang cocok (jika memungkinkan), dan mengikat PVC dengan PV tersebut. Jika sebuah PV disediakan secara dinamis untuk sebuah PVC baru, _loop_ tersebut akan selalu mengikat PV tersebut pada PVC yang baru dibuat itu. Jika tidak, pengguna akan selalu mendapatkan setidaknya apa yang dimintanya, tetapi volume tersebut mungkin lebih dari apa yang diminta sebelumnya. Setelah terikat, ikatan `PersistentVolumeClaim` (PVC) bersifat eksklusif, terlepas dari bagaimana caranya mereka bisa terikat. Sebuah ikatan PVC ke PV merupakan pemetaan satu ke satu. -Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah kluster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke kluster. +Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah klaster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke klaster. ### Penggunaan -_Pod_ menggunakan klaim sebagai volume. Kluster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada _pod_. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah _pod_. +_Pod_ menggunakan klaim sebagai volume. Klaster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada _pod_. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah _pod_. Ketika pengguna memiliki klaim dan klaim tersebut telah terikat, PV yang terikat menjadi hak penggunanya selama yang dibutuhkan. Pengguna menjadwalkan _pod_ dan mengakses PV yang sudah diklaim dengan menambahkan `persistentVolumeClaim` pada blok volume pada _Pod_ miliknya. [Lihat pranala di bawah untuk detail-detail mengenai sintaks](#claims-as-volumes). @@ -117,7 +117,7 @@ Events: ### 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_). +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 klaster setelah volume dilepaskan dari klaimnya. Saat ini, volume dapat dipertahankan (_Retained_), didaur ulang (_Recycled_), atau dihapus (_Deleted_). #### _Retain_ @@ -266,7 +266,7 @@ Tipe-tipe `PersistentVolume` (PV) diimplementasikan sebagai _plugin_. Kubernete * Glusterfs * VsphereVolume * Quobyte Volumes -* HostPath (Hanya untuk pengujian _single node_ -- penyimpanan lokal tidak didukung dan TIDAK AKAN BEKERJA pada kluster _multi-node_) +* HostPath (Hanya untuk pengujian _single node_ -- penyimpanan lokal tidak didukung dan TIDAK AKAN BEKERJA pada klaster _multi-node_) * Portworx Volumes * ScaleIO Volumes * StorageOS @@ -419,7 +419,7 @@ Sebuah volume akan berada dalam salah satu fase di bawah ini: * Available -- sumber daya bebas yang belum terikat dengan sebuah klaim * Bound -- volume sudah terikat dengan sebuah klaim -* Released -- klaim sudah dihapus, tetapi sumber daya masih belum direklaim oleh kluster +* Released -- klaim sudah dihapus, tetapi sumber daya masih belum direklaim oleh klaster * Failed -- volume gagal menjalankan reklamasi otomatis CLI akan menunjukkan nama dari PVC yang terikat pada PV. @@ -481,7 +481,7 @@ PVC tidak harus meminta sebuah kelas. Sebuah PVC dengan `storageClassName` milik `""` akan selalu diinterpretasikan sebagai meminta PV tanpa kelas, jadi PVC hanya bisa terikat ke PV tanpa kelas (tanpa anotasi atau bernilai `""`). Sebuah PVC tanpa `storageClassName` tidaklah sama dan diperlakukan berbeda -oleh kluster tergantung apakah +oleh klaster tergantung apakah [_admission plugin_ `DefaultStorageClass`](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) dinyalakan. @@ -490,7 +490,7 @@ dinyalakan. PVs standar. Menspesifikasikan `StorageClass` standar dapat dilakukan dengan mengatur anotasi `storageclass.kubernetes.io/is-default-class` menjadi "_true_" pada sebuah objek `StorageClass`. Jika administrator tidak menspesifikasikan standar apapun, - kluster menanggapi pembuatan PVC sekan-akan _admission plugin_ dimatikan. Jika + klaster menanggapi pembuatan PVC sekan-akan _admission plugin_ dimatikan. Jika ada lebih dari satu setelan standar dispesifikasikan, _admission plugin_ melarang pembuatan seluruh PVC. * Jika _admission plugin_ dimatikan, tidak ada pilihan menggunakan @@ -499,7 +499,7 @@ dinyalakan. sama seperti PVC yang memiliki `storageClassName` bernilai `""`. Tergantung metode instalasi, sebuah StorageClass dari setelan standar dapat dibuat -ke kluster Kubernetes oleh _addon manager_ pada saat instalasi. +ke klaster Kubernetes oleh _addon manager_ pada saat instalasi. Ketika sebuah PVC menspesifikasi sebuah `selector` selain meminta `StorageClass`, kebutuhan tersebut akan digabungkan dengan operasi AND bersama: hanya PV dari kelas yang diminta dan dengan @@ -515,7 +515,7 @@ akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang. ## Klaim sebagai Volume -_Pod_ mengakses _storage_ dengan menggunakan klaim sebagai volume. Klaim harus berada pada _namespace_ yang sama dengan _pod_ yang menggunakan klaim tersebut. Kluster menemukan klaim pada _namespace_ yang sama dengan _pod_ dan menggunakannya untuk mendapatkan `PersistentVolume` (PV) yang ada di baliknya. Volume tersebut kemudian dipasangkan ke _host_ dan lalu ke _pod_. +_Pod_ mengakses _storage_ dengan menggunakan klaim sebagai volume. Klaim harus berada pada _namespace_ yang sama dengan _pod_ yang menggunakan klaim tersebut. Klaster menemukan klaim pada _namespace_ yang sama dengan _pod_ dan menggunakannya untuk mendapatkan `PersistentVolume` (PV) yang ada di baliknya. Volume tersebut kemudian dipasangkan ke _host_ dan lalu ke _pod_. ```yaml apiVersion: v1 @@ -669,7 +669,7 @@ spec: ## Menulis Konfigurasi Portabel -Jika kamu menulis templat konfigurasi atau contoh yang dapat berjalan pada berbagai macam kluster +Jika kamu menulis templat konfigurasi atau contoh yang dapat berjalan pada berbagai macam klaster dan membutuhkan _persistent storage_, kami merekomendasikan agar kamu menggunakan pola berikut: - Masukkan objek PersistentVolumeClaim (PVC) pada kumpulan _config_ (bersamaan dengan @@ -681,17 +681,17 @@ dan membutuhkan _persistent storage_, kami merekomendasikan agar kamu menggunaka - Jika pengguna menyediakan nama _storage class_, taruh nilai tersebut pada kolom `persistentVolumeClaim.storageClassName`. Hal ini akan membuat PVC agar sesuai dengan _storage class_ - yang tepat jika kluster memiliki banyak StorageClass yang diaktifkan oleh admin. + yang tepat jika klaster memiliki banyak StorageClass yang diaktifkan oleh admin. - Jika pengguna tidak menyediakan nama _storage class_, biarkan kolom `persistentVolumeClaim.storageClassName` kosong. - Hal ini kakan membuat sebuah PV disediakan secara otomatis untuk pengguna dengan - StorageClass standar pada kluster. Banyak lingkungan kluster memiliki + StorageClass standar pada klaster. Banyak lingkungan klaster memiliki StorageClass standar yang sudah terpasang, atau administrator dapat membuat StorageClass standar sendiri. - Dalam pembuatan, perhatikan PVC yang tidak kunjung terikat setelah beberapa lama - dan beritahukan hal ini pada pengguna, karena hal ini dapat mengindikasikan kluster tidak + dan beritahukan hal ini pada pengguna, karena hal ini dapat mengindikasikan klaster tidak memiliki dukungan penyimpanan dinamis (di mana pengguna harus membuat PV yang sesuai) - atau kluster tidak memiliki sistem penyimpanan (di mana penggun tidak dapat membuat + atau klaster tidak memiliki sistem penyimpanan (di mana penggun tidak dapat membuat PVC yang membutuhkan _config_). {{% /capture %}} diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index 1119f5fe0c..ceeadf2d90 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -21,7 +21,7 @@ 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 +oleh administrator klaster. 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. @@ -138,11 +138,11 @@ 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_ +yang ada di klaster, 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 +Seorang administrator klaster 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_ @@ -176,7 +176,7 @@ beserta contoh penggunaannya. _Feature gate_ `CSINodeInfo` haruslah diaktifkan. ### Topologi yang Diizinkan -Ketika sebuah operator kluster memberikan spesifikasi `WaitForFirstConsumer` pada +Ketika sebuah operator klaster 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. @@ -230,12 +230,12 @@ parameters: 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 + penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada klaster 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 + `round-robin-ed` pada semua zona aktif yang ada pada klaster 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 @@ -271,12 +271,12 @@ 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 + penjadwalan `round-robin-ed` pada semua zona aktif yang ada pada klaster 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 + `round-robin-ed` pada semua zona aktif yang ada pada klaster Kubernetes yang memiliki _node_. * `replication-type`: `none` atau `regional-pd`. Nilai _default_: `none`. @@ -291,7 +291,7 @@ 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. +zona yang diatur oleh klaster Kubernetes. {{< note >}} Parameter `zone` dan `zones` sudah _deprecated_ dan digantikan oleh @@ -351,7 +351,7 @@ parameters: 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 +* `clusterid`: `630372ccdc720a92c681fb928f27b53f` merupakan ID dari klaster yang akan digunakan oleh Heketi ketikan melakukan _provisioning_ volume. ID ini juga dapat berupa serangkaian list, misalnya: `"8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397"`. Parameter ini merupakan parameter opsional. @@ -396,7 +396,7 @@ parameters: * `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. + dimana klaster Kubernetes memiliki sebuah node. {{< note >}} {{< feature-state state="deprecated" for_k8s_version="1.11" >}} @@ -581,9 +581,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, + akun tersebut haruslah berada pada grup sumber daya yang ada dengan klaster, dan `location` akan diabaikan. Jika sebuah akun penyimpanan tidak disediakan, sebuah akun penyimpanan - baru akan dibuat pada grup sumber daya yang ada dengan kluster. + baru akan dibuat pada grup sumber daya yang ada dengan klaster. #### Kelas Penyimpanan Disk Azure yang Baru (mulai versi v1.7.2) @@ -601,10 +601,10 @@ 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 - dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan kluster. + dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan klaster. 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. + baru akan dibuat pada grup sumber daya yang ada dengan klaster. Ketika `kind` yang digunakan adalah + `managed`, semua disk yang dikelola akan dibuat pada grup sumber daya yang ada dengan klaster. - VM premium dapat di-_attach_ baik pada Standard_LRS dan Premium_LRS disks, sementara Standard VM hanya dapat di-_attach_ pada disk Standard_LRS. @@ -631,9 +631,9 @@ parameters: 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. + di dalam grup sumber daya yang sama dengan klaster, 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 klaster 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 diff --git a/content/id/docs/concepts/storage/storage-limits.md b/content/id/docs/concepts/storage/storage-limits.md index f2c4c9de93..45b2ef3b35 100644 --- a/content/id/docs/concepts/storage/storage-limits.md +++ b/content/id/docs/concepts/storage/storage-limits.md @@ -39,7 +39,7 @@ Berhati-hatilah jika kamu menerapkan limit yang lebih besar dari limit _default_ Perhatikan dokumentasi penyedia layanan cloud untuk hal ini, dan pastikan Node benar-benar dapat mendukung nilai limit yang kamu inginkan. -Limit ini diterapkan untuk seluruh kluster, jadi akan berdampak pada semua Node. +Limit ini diterapkan untuk seluruh klaster, jadi akan berdampak pada semua Node. ## Limit volume dinamis diff --git a/content/id/docs/concepts/storage/volume-snapshots.md b/content/id/docs/concepts/storage/volume-snapshots.md index 119342b19d..c5b7c09e73 100644 --- a/content/id/docs/concepts/storage/volume-snapshots.md +++ b/content/id/docs/concepts/storage/volume-snapshots.md @@ -18,11 +18,11 @@ Laman ini menjelaskan tentang fitur VolumeSnapshot pada Kubernetes. Sebelum lanj Seperti halnya sumber daya API PersistentVolume dan PersistentVolumeClaim yang digunakan oleh para pengguna dan administrator untuk menyediakan volume, sumber daya API VolumeSnapshotContent dan VolumeSnapshot digunakan mereka untuk membuat _snapshot_ volume. -VolumeSnapshotContent merupakan suatu _snapshot_ yang diambil dari sebuah volume dari dalam kluster yang telah disediakan oleh administrator. Sepert layaknya PersistentVolume, VolumeSnapshotContent juga merupakan bagian dari sumber daya kluster. +VolumeSnapshotContent merupakan suatu _snapshot_ yang diambil dari sebuah volume dari dalam klaster yang telah disediakan oleh administrator. Sepert layaknya PersistentVolume, VolumeSnapshotContent juga merupakan bagian dari sumber daya klaster. VolumeSnapshot merupakan suatu permintaan _snapshot_ dari volume oleh pengguna. Mirip seperti halnya PersistentVolumeClaim. -Walaupun VolumeSnapshot membuat pengguna bisa mengonsumsi abstraksi dari sumber daya penyimpanan, administrator kluster tetap perlu +Walaupun VolumeSnapshot membuat pengguna bisa mengonsumsi abstraksi dari sumber daya penyimpanan, administrator klaster tetap perlu menawarkan berbagai macam tipe VolumeSnapshotContent, tanpa perlu mengekspos pengguna pada detail bagaimana _snapshot_ volume tersebut harus tersediakan. Bagi yang memerlukan hal ini, ada yang namanya sumber daya VolumeSnapshotClass. @@ -36,17 +36,17 @@ Para pengguna tetap perlu mengetahui beberapa hal di bawah ketika menggunakan fi ## Siklus hidup VolumeSnapshot dan VolumeSnapshotContent -VolumeSnapshotContent merupakan bagian dari sumber daya kluster. VolumeSnapshot merupakan permintaan terhadap sumber daya tersebut. Interaksi antara VolumeSnapshotContent dan VolumeSnapshot mengikuti siklus hidup berikut ini: +VolumeSnapshotContent merupakan bagian dari sumber daya klaster. VolumeSnapshot merupakan permintaan terhadap sumber daya tersebut. Interaksi antara VolumeSnapshotContent dan VolumeSnapshot mengikuti siklus hidup berikut ini: ### Penyediaan VolumeSnapshot Ada dua cara untuk menyediakan _snapshot_: secara statis maupun dinamis. #### Statis -Seorang adminstrator kluster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes. +Seorang adminstrator klaster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes. #### Dinamis -Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, kluster bisa saja +Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot. Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) dan administrator harus membuat serta mengatur _class_ tersebut supaya penyediaan dinamis bisa terjadi. diff --git a/content/id/docs/concepts/storage/volumes.md b/content/id/docs/concepts/storage/volumes.md index 639083e26e..6c179d508c 100644 --- a/content/id/docs/concepts/storage/volumes.md +++ b/content/id/docs/concepts/storage/volumes.md @@ -83,7 +83,7 @@ Sebelum kamu dapat menggunakan sebuah volume EBS pada sebuah Pod, kamu harus mem aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 ``` -Pastikan _availability zone_ yang kamu masukkan sama dengan _availability zone_ kluster kamu. (Dan pastikan juga ukuran dan jenis EBSnya sesuai dengan penggunaan yang kamu butuhkan!) +Pastikan _availability zone_ yang kamu masukkan sama dengan _availability zone_ klaster kamu. (Dan pastikan juga ukuran dan jenis EBSnya sesuai dengan penggunaan yang kamu butuhkan!) #### Contoh Konfigurasi AWS EBS @@ -111,7 +111,7 @@ spec: {{< feature-state for_k8s_version="v1.14" state="alpha" >}} -Pada saat fitur migrasi CSI (Container Storage Interface) untuk `awsElasticBlockStore` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `ebs.csi.aws.com`. Untuk menggunakan fitur ini, [Driver CSI AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationAWS` harus diaktifkan. +Pada saat fitur migrasi CSI (Container Storage Interface) untuk `awsElasticBlockStore` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `ebs.csi.aws.com`. Untuk menggunakan fitur ini, [Driver CSI AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationAWS` harus diaktifkan. ### azureDisk {#azuredisk} @@ -123,7 +123,7 @@ Selengkapnya dapat ditemukan [di sini](https://github.com/kubernetes/examples/tr {{< feature-state for_k8s_version="v1.15" state="alpha" >}} -Pada saat fitur migrasi CSI untuk `azureDisk` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `disk.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureDisk` harus diaktifkan. +Pada saat fitur migrasi CSI untuk `azureDisk` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `disk.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureDisk` harus diaktifkan. ### azureFile {#azurefile} @@ -135,7 +135,7 @@ Selengkapnya dapat ditemukan [di sini](https://github.com/kubernetes/examples/tr {{< feature-state for_k8s_version="v1.15" state="alpha" >}} -Pada saat fitur migrasi CSI untuk `azureFile` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `file.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure File](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureFile` harus diaktifkan. +Pada saat fitur migrasi CSI untuk `azureFile` diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `file.csi.azure.com`. Untuk menggunakan fitur ini, [Driver CSI Azure File](https://github.com/kubernetes-sigs/azuredisk-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationAzureFile` harus diaktifkan. ### cephfs {#cephfs} @@ -181,7 +181,7 @@ spec: {{< feature-state for_k8s_version="v1.14" state="alpha" >}} -Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `cinder.csi.openstack.com`. Untuk menggunakan fitur ini, [Driver CSI Openstack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationOpenStack` harus diaktifkan. +Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `cinder.csi.openstack.com`. Untuk menggunakan fitur ini, [Driver CSI Openstack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationOpenStack` harus diaktifkan. ### configMap {#configmap} @@ -281,7 +281,7 @@ Lihat [Contoh FC](https://github.com/kubernetes/examples/tree/{{< param "githubb ### flocker {#flocker} -[Flocker](https://github.com/ClusterHQ/flocker) adalah sebuah proyek _open-source_ yg berfungsi sebagai pengatur _volume_ data Container yang diklusterkan. Flocker menyediakan pengelolaan dan orkestrasi _volume_ yang disokong oleh banyak jenis media penyimpanan. +[Flocker](https://github.com/ClusterHQ/flocker) adalah sebuah proyek _open-source_ yg berfungsi sebagai pengatur _volume_ data Container yang diklasterkan. Flocker menyediakan pengelolaan dan orkestrasi _volume_ yang disokong oleh banyak jenis media penyimpanan. Sebuah Volume `flockere` memungkinkan sebuah _dataset_ Flocker untuk ditambatkan ke dalam sebuah Pod. Jika _dataset_ tersebut belum ada di dalam Flocker, maka ia harus dibuat terlebih dahulu dengan menggunakan Flocker CLI atau menggunakan Flocker API. Jika _dataset_ tersebut sudah ada, ia akan ditambatkan kembali oleh Flocker ke Node di mana Pod tersebut dijadwalkan. Hal ini berarti data dapat dioper diantara Pod-pod sesuai dengan kebutuhan. @@ -378,7 +378,7 @@ spec: {{< feature-state for_k8s_version="v1.14" state="alpha" >}} -Pada saat fitur migrasi CSI untuk GCE PD diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `pd.csi.storage.gke.io`. Untuk menggunakan fitur ini, [Driver CSI GCE PD](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) harus dinstal di kluster dan fitur Alpha `CSIMigration` serta `CSIMigrationGCE` harus diaktifkan. +Pada saat fitur migrasi CSI untuk GCE PD diaktifkan, fitur ini akan menterjemahkan semua operasi _plugin_ dari _plugin_ yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI `pd.csi.storage.gke.io`. Untuk menggunakan fitur ini, [Driver CSI GCE PD](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) harus dinstal di klaster dan fitur Alpha `CSIMigration` serta `CSIMigrationGCE` harus diaktifkan. ### gitRepo (kedaluwarsa) {#gitrepo} @@ -450,7 +450,7 @@ Nilai yang didukung untuk kolom `type` adalah:` Berhati-hatilah saat menggunakan tipe volume ini, karena: * Pod-pod dengan konfigurasi identik (misalnya dibuat dari podTemplate) mungkin berperilaku berbeda pada Node-node yang berbeda oleh karena berkas-berkas yang berbeda pada Node-node tersebut. -* Saat Kubernetes menambahkan penjadwalan yang sadar terhadap sumber-daya kluster, sesuai yang telah direncanakan, ia tidak dapat melakukan perhitungan terhadap sumber daya yang digunakan oleh sebuah `hostPath` +* Saat Kubernetes menambahkan penjadwalan yang sadar terhadap sumber-daya klaster, sesuai yang telah direncanakan, ia tidak dapat melakukan perhitungan terhadap sumber daya yang digunakan oleh sebuah `hostPath` * Berkas-berkas atau direktori-direktori yang dibuat pada _host-host_ bersangkutan hanya dapat ditulis oleh `root`. Kamu butuh antara menjalankan proses aplikasi kamu sebagai `root` pada sebuah [privileged Container](/docs/user-guide/security-context) atau mengubah _permission_ berkas kamu pada _host_ tersebut agar dapat menulis pada Volume `hostPath` #### Contoh Pod @@ -742,10 +742,10 @@ Lihat [contoh RBD](https://github.com/kubernetes/examples/tree/{{< param "github ### scaleIO {#scaleio} -ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat kluster-kluster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)). +ScaleIO adalah _platform_ penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang _scalable_. _Plugin_ Volume `scaleIO` memungkinkan Pod-pod yang di-_deploy_ untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat [Persistent Volume ScaleIO](/docs/concepts/storage/persistent-volumes/#scaleio)). {{< caution >}} -Kamu harus memiliki kluster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya. +Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya. {{< /caution >}} Berikut contoh konfigurasi sebuah Pod yang menggunakan ScaleIO: @@ -795,7 +795,7 @@ Secret dijelaskan lebih lanjut [di sini](/docs/user-guide/secrets). Sebuah Volume `storageos` memungkinkan volume [StorageOS](https://www.storageos.com) yang sudah tersedia untuk ditambatkan ke dalam Pod kamu. -StorageOS berjalan sebagai sebuah COntainer di dalam lingkungan Kubernetes kamu, membuat penyimpanan yang lokal atau penyimpanan yang sedang dipasang untuk diakses dari Node manapun di dalam kluster Kubernetes. +StorageOS berjalan sebagai sebuah COntainer di dalam lingkungan Kubernetes kamu, membuat penyimpanan yang lokal atau penyimpanan yang sedang dipasang untuk diakses dari Node manapun di dalam klaster Kubernetes. Data dapat direplikasikan untuk melindungi dari kegagalan Node. _Thin provisioning_ dan kompresi dapat meningkatkan utilisasi dan mengurangi biaya. Di dalam intinya, StorageOS menyediakan penyimpanan blok kepada Container-container, yang dapat diakses melalui sebuah _filesystem_. @@ -804,7 +804,7 @@ Container StorageOS membutuhkan Linux 64-bit dan tidak memiliki ketergantungan t Tersedia pula sebuah lisensi gratis untuk _developer_. {{< caution >}} -Kamu harus menjalankan Container StorageOS pada setiap Node yang ingin mengakses volume-volume StorageOS atau yang akan berkontribusi pada kapasitas penyimpanan di kluster StorageOS. Untuk petunjuk instalasi, lihat [dokumentasi StorageOS](https://docs.storageos.com). +Kamu harus menjalankan Container StorageOS pada setiap Node yang ingin mengakses volume-volume StorageOS atau yang akan berkontribusi pada kapasitas penyimpanan di klaster StorageOS. Untuk petunjuk instalasi, lihat [dokumentasi StorageOS](https://docs.storageos.com). {{< /caution >}} ```yaml @@ -972,7 +972,7 @@ spec: Media penyimpanan (Disk, SSD, dll.) dari sebuah Volume `emptyDir` ditentukan oleh medium dari _filesystem_ yang menyimpan direktori _root_ dari Kubelet (biasanya `/var/lib/kubelet`). Tidak ada batasan berapa banyak ruang yang dapat digunakan oleh Volume `emptyDir` dan `hostPath`, dan tidak ada isolasi antara Container-container atau antara Pod-pod. -Ke depannya, kita mengharapkan Volume `emptyDir` dan `hostPath` akan dapat meminta jumlah ruangan penyimpanan tertentu dengan mengunakan spesifikasi [resource][resource](/docs/user-guide/compute-resources), dan memilih tipe media penyimpanan yang akan digunakan, untuk kluster yang memiliki beberapa jenis media penyimpanan. +Ke depannya, kita mengharapkan Volume `emptyDir` dan `hostPath` akan dapat meminta jumlah ruangan penyimpanan tertentu dengan mengunakan spesifikasi [resource][resource](/docs/user-guide/compute-resources), dan memilih tipe media penyimpanan yang akan digunakan, untuk klaster yang memiliki beberapa jenis media penyimpanan. ## _Plugin_ Volume yang Out-of-Tree @@ -980,7 +980,7 @@ _Plugin_ Volume yang Out-of-tree termasuk Container Storage Interface (CSI) dan Sebelum dikenalkannya CSI dan Flexvolume, semua _plugin_ volume (seperti jenis-jenis volume yang terdaftar di atas) berada pada "in-tree", yang berarti bahwa mereka dibangun, di-_link_, di-_compile_, dan didistribusikan bersama-sama dengan kode inti Kubernetes dan mengekstensi inti dari Kubernetes API. Hal ini berarti menambah sistem penyimpanan baru ke dalam Kubernetes (sebuah _plugin_ volume) membutukan penambahan kode tersebut ke dalam _repository_ kode inti Kubernetes. -CSI dan Flexvolume memungkinkan _plugin_ volume untuk dikembangkan secara terpisah dari kode inti Kubernetes, dan diinstal pada kluster Kubernetes sebagai ekstensi. +CSI dan Flexvolume memungkinkan _plugin_ volume untuk dikembangkan secara terpisah dari kode inti Kubernetes, dan diinstal pada klaster Kubernetes sebagai ekstensi. Bagi _vendor-vendor_ penyimpanan yang ingin membuat sebuah _plugin_ volume yang out-of-tree, lihat [FAQ ini](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). @@ -1001,7 +1001,7 @@ _Driver-driver_ CSI mungkin tidak cocok pada semua rilis Kubernetes. Silahkan lihat dokumentasi _driver_ CSI yang bersangkutan untuk petunjuk penggunaan yang didukung untuk setiap rilis Kubernetes, dan untuk melihat matriks kompabilitasnya. {{< /note >}} -Saat sebuah _driver_ volume CSI dipasang pada kluster Kubernetes, pengguna dapat menggunakan tipe Volume `csi` untuk menambatkan volume-volume yang diekspos oleh _driver_ CSI tersebut. +Saat sebuah _driver_ volume CSI dipasang pada klaster Kubernetes, pengguna dapat menggunakan tipe Volume `csi` untuk menambatkan volume-volume yang diekspos oleh _driver_ CSI tersebut. Tipe Volume `csi` tidak mendukung referensi secara langsung dari Pod dan hanya dapat dirujuk di dalam sebuah Pod melalui sebuah objek `PersistentVolumeClaim`. diff --git a/content/id/docs/concepts/workloads/controllers/garbage-collection.md b/content/id/docs/concepts/workloads/controllers/garbage-collection.md index 9f12a12989..63592fbe89 100644 --- a/content/id/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/id/docs/concepts/workloads/controllers/garbage-collection.md @@ -50,8 +50,8 @@ 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. -2) Dependen dengan cakupan kluster hanya bisa menspesifikasikan pemilik yang memiliki cakupan kluster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan kluster. +1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan klaster. +2) Dependen dengan cakupan klaster hanya bisa menspesifikasikan pemilik yang memiliki cakupan klaster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan klaster. {{< /note >}} ## Mengontrol bagaimana _garbage collector_ menghapus dependen diff --git a/content/id/docs/concepts/workloads/controllers/replicaset.md b/content/id/docs/concepts/workloads/controllers/replicaset.md index 9558ae0723..9c62a0fa72 100644 --- a/content/id/docs/concepts/workloads/controllers/replicaset.md +++ b/content/id/docs/concepts/workloads/controllers/replicaset.md @@ -31,7 +31,7 @@ Hal ini berarti kamu boleh jadi tidak akan membutuhkan manipulasi objek ReplicaS {{< codenew file="controllers/frontend.yaml" >}} -Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke kluster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola. +Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola. ```shell kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml @@ -259,7 +259,7 @@ Pengaturan jumlah Pod pada ReplicaSet juga dapat dilakukan mengunakan [Horizonta {{< codenew file="controllers/hpa-rs.yaml" >}} -Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke kluster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi. +Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi. ```shell kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml diff --git a/content/id/docs/concepts/workloads/controllers/statefulset.md b/content/id/docs/concepts/workloads/controllers/statefulset.md index 76a3749457..ad30b831e0 100644 --- a/content/id/docs/concepts/workloads/controllers/statefulset.md +++ b/content/id/docs/concepts/workloads/controllers/statefulset.md @@ -127,7 +127,7 @@ dengan nama `web-0,web-1,web-2`. Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services) untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format: `$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan -domain kluster. +domain klaster. Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendiri, yang memiliki format: `$(podname).$(governing service domain)`, dimana Service yang mengatur didefinisikan oleh _field_ `serviceName` pada StatefulSet. @@ -136,17 +136,17 @@ Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services) yang bertanggung jawab terhadap identitas jaringan pada Pod. -Di sini terdapat beberapa contoh penggunaan Domain Kluster, nama Service, +Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service, nama StatefulSet, dan bagaimana hal tersebut berdampak pada nama DNS dari Pod StatefulSet. -Domain Kluster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet | DNS Pod | Hostname Pod | +Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet | DNS Pod | Hostname Pod | -------------- | ----------------- | ----------------- | -------------- | ------- | ------------ | cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -Domain kluster akan diatur menjadi `cluster.local` kecuali +Domain klaster akan diatur menjadi `cluster.local` kecuali [nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/#how-it-works). {{< /note >}} diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md index 8d4a63ffeb..07abe8e2a7 100644 --- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -28,7 +28,7 @@ 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 +Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster 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 @@ -49,7 +49,7 @@ Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk men * 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 + Administrator klaster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada sumber daya yang telah selesai digunakan. * Gunakan sebuah [mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) @@ -70,7 +70,7 @@ menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah. 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 +terhadap _time skew_ yang ada pada klaster 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_ diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md index c5d1ebdffe..c612405b97 100644 --- a/content/id/docs/concepts/workloads/pods/disruptions.md +++ b/content/id/docs/concepts/workloads/pods/disruptions.md @@ -7,7 +7,7 @@ weight: 60 {{% capture overview %}} Petunjuk ini ditujukan pada pemilik aplikasi yang meninginkan aplikasinya memiliki ketersediaan yang tinggi, sehingga butuh untuk mengerti jenis-jenis Disrupsi yang dapat terjadi pada Pod-pod. -Petunjuk ini juga ditujukan pada administrator kluster yang ingin melakukan berbagai tindakan otomasi pada kluster, seperti pembaruan dan _autoscaling_ kluster. +Petunjuk ini juga ditujukan pada administrator klaster yang ingin melakukan berbagai tindakan otomasi pada klaster, seperti pembaruan dan _autoscaling_ klaster. {{% /capture %}} @@ -20,29 +20,29 @@ Pod-pod tidak akan terhapus sampai sesuatu (orang ataupun _pengendali_) menghanc Kita menyebut kasus-kasus yang tidak dapat dihindari sebagai **disrupsi yang tidak disengaja** terhadap aplikasi. Beberapa contohnya adalah sebagai berikut: - Kesalahan perangkat keras pada mesin yang menjalankan Node -- Administrator kluster menghapus _virtual machine_ secara tidak sengaja +- Administrator klaster menghapus _virtual machine_ secara tidak sengaja - Kesalahan pada penyedia layanan _cloud_ yang mengakibatkan terhapusnya _virtual machine_ - Sebuah _kernel panic_ -- Node menghilang dari kluster karena partisi jaringan kluster +- Node menghilang dari klaster karena partisi jaringan klaster - Pod mengalami _eviction_ karena Node [kehabisan sumber daya](/docs/tasks/administer-cluster/out-of-resource) Dengan pengecualian pada kondisi kehabisan sumber daya, kondisi-kondisi tersebut pada umumnya diketahui oleh kebanyakan pengguna karena kondisi-kondisi tersebut tidak spesifik pada Kubernetes saja. -Kita menyebut kasus-kasus lainnya sebagai **disrupsi yang disengaja**. Hal ini termasuk tindakan yang dilakukan oleh pemilik aplikasi atau yang dilakukan oleh administrator kluster. Pemilik aplikasi umumnya melakukan hal-hal berikut: +Kita menyebut kasus-kasus lainnya sebagai **disrupsi yang disengaja**. Hal ini termasuk tindakan yang dilakukan oleh pemilik aplikasi atau yang dilakukan oleh administrator klaster. Pemilik aplikasi umumnya melakukan hal-hal berikut: - Menghapus Deployment atau pengendali yang mengatur Pod - Memperbarui templat Pod yang menyebabkan pengulangan kembali/_restart_ - Menghapus Pod secara langsung -Administrator kluster umumnya melakukan hal-hal berikut: +Administrator klaster umumnya melakukan hal-hal berikut: - [Melakukan _drain_ terhadap Node](/docs/tasks/administer-cluster/safely-drain-node/) untuk perbaikan atau pembaruan. -- Melakukan _drain_ terhadap sebuah node dari kluster untuk memperkecil ukuran kluster (untuk lebih lanjutnya, pelajari [_Autoscaling_ kluster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)). +- Melakukan _drain_ terhadap sebuah node dari klaster untuk memperkecil ukuran klaster (untuk lebih lanjutnya, pelajari [_Autoscaling_ klaster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)). - Menghapus sebuah Pod dari node untuk memuat Pod lain ke node tersebut. -Tindakan-tindakan tersebut dapat dilakukan secara langsung oleh administrator kluster, atau oleh alat otomasi yang dijalankan oleh administrator kluster, atau oleh penyedia layanan Kubernetes kamu. +Tindakan-tindakan tersebut dapat dilakukan secara langsung oleh administrator klaster, atau oleh alat otomasi yang dijalankan oleh administrator klaster, atau oleh penyedia layanan Kubernetes kamu. -Tanyakan administrator kluster atau penyedia layanan _cloud_ kamu, atau lihatlah dokumentasi penyedia layanan Kubernetes kamu untuk mengetahui bila ada sumber-sumber yang berpotensi mengakibatkan disrupsi yang disengaja yang ada pada klustermu. Jika tidak ada, kamu bisa melewatkan pembuatan _PodDisruptionBudget_ +Tanyakan administrator klaster atau penyedia layanan _cloud_ kamu, atau lihatlah dokumentasi penyedia layanan Kubernetes kamu untuk mengetahui bila ada sumber-sumber yang berpotensi mengakibatkan disrupsi yang disengaja yang ada pada klastermu. Jika tidak ada, kamu bisa melewatkan pembuatan _PodDisruptionBudget_ {{< caution >}} Tidak semua disrupsi yang disengaja dibatasi oleh Pod Disruption Budget. Contohnya, menghapus Deployment atau Pod dapat mengabaikan PodDisruptionBudget. @@ -52,13 +52,13 @@ Tidak semua disrupsi yang disengaja dibatasi oleh Pod Disruption Budget. Contohn Berikut beberapa cara untuk mengatasi disrupsi yang tidak disengaja: -- Pastikan Pod-pod kamu [merinci permintaan sumber daya kluster](/docs/tasks/configure-Pod-container/assign-cpu-ram-container) yang dibutuhkan. +- Pastikan Pod-pod kamu [merinci permintaan sumber daya klaster](/docs/tasks/configure-Pod-container/assign-cpu-ram-container) yang dibutuhkan. - Replikasikan aplikasimu jika membutuhkan ketersediaan yang tinggi. (Pelajari tentang menjalankan aplikasi [_stateless_](/docs/tasks/run-application/run-stateless-application-deployment/) dan [_stateful_](/docs/tasks/run-application/run-replicated-stateful-application/)). -- Untuk mencapai ketersediaan yang bahkan lebih tinggi lagi saat mereplikasikan aplikasi, sebarkanlah Pod-pod kamu di rak-rak pada _data center_ (menggunakan [_anti-affinity_](/docs/user-guide/node-selection/#inter-Pod-affinity-and-anti-affinity-beta-feature)) atau di seluruh zona (jika kamu menggunakan [kluster pada beberapa zona](/docs/setup/multiple-zones)). +- Untuk mencapai ketersediaan yang bahkan lebih tinggi lagi saat mereplikasikan aplikasi, sebarkanlah Pod-pod kamu di rak-rak pada _data center_ (menggunakan [_anti-affinity_](/docs/user-guide/node-selection/#inter-Pod-affinity-and-anti-affinity-beta-feature)) atau di seluruh zona (jika kamu menggunakan [klaster pada beberapa zona](/docs/setup/multiple-zones)). -Frekuensi disrupsi yang disengaja dapat berubah-ubah. Pada kluster Kubernetes yang dasar, tidak ada disrupsi yang disengaja sama sekali. Tetapi, administrator kluster atau penyedia layanan Kubernetes kamu mungkin saja menjalankan beberapa servis tambahan yang dapat mengakibatkan disrupsi yang disengaja. Misalnya, memperbarui perangkat lunak pada node yang dapat mengakibatkan disrupsi yang disengaja. Selain itu, beberapa implementasi _autoscaling_ kluster (atau node) dapat mengakibatkan disrupsi yang disengaja untuk merapikan dan memadatkan node-node pada kluster. -Administrator kluster atau penyedia layanan Kubernetes kamu perlu mendokumentasikan tingkatan disrupsi yang disengaja, jika ada disrupsi yang telah diperkirakan. +Frekuensi disrupsi yang disengaja dapat berubah-ubah. Pada klaster Kubernetes yang dasar, tidak ada disrupsi yang disengaja sama sekali. Tetapi, administrator klaster atau penyedia layanan Kubernetes kamu mungkin saja menjalankan beberapa servis tambahan yang dapat mengakibatkan disrupsi yang disengaja. Misalnya, memperbarui perangkat lunak pada node yang dapat mengakibatkan disrupsi yang disengaja. Selain itu, beberapa implementasi _autoscaling_ klaster (atau node) dapat mengakibatkan disrupsi yang disengaja untuk merapikan dan memadatkan node-node pada klaster. +Administrator klaster atau penyedia layanan Kubernetes kamu perlu mendokumentasikan tingkatan disrupsi yang disengaja, jika ada disrupsi yang telah diperkirakan. Kubernetes menawarkan fitur-fitur untuk membantu menjalankan aplikasi-aplikasi dengan ketersediaan tinggi bersamaan dengan seringnya disrupsi yang disengaja, fitur-fitur tersebut dinamai _Disruption Budget_. @@ -67,9 +67,9 @@ Kubernetes menawarkan fitur-fitur untuk membantu menjalankan aplikasi-aplikasi d Pemilik aplikasi dapat membuat objek `PodDisruptionBudget` (PDB) untuk setiap aplikasi. Sebuah PDB membatasi jumlah Pod yang boleh mati secara bersamaan pada aplikasi yang direplikasi dikarenakan disrupsi yang disengaja. Misalnya, sebuah aplikasi yang bekerja secara _quorum_ mau memastikan bahwa jumlah replika yang berjalan tidak jatuh ke bawah yang dibutuhkan untuk membentuk sebuah _quorum_. Contoh lainnya, sebuah _front-end_ web mungkin perlu memastikan bahwa jumlah replika yang melayani trafik tidak pernah turun ke total persentase yang telah ditentukan. -Administrator kluster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah `kubectl drain` dan skrip pembaruan Kubernets-on-GCE (`cluster/gce/upgrade.sh`) +Administrator klaster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah `kubectl drain` dan skrip pembaruan Kubernets-on-GCE (`cluster/gce/upgrade.sh`) -Saat seorang administrator kluster ingin melakukan _drain_ terhadap sebuah node, ia akan menggunakan perintah `kubectl drain`. Alat tersebut mencoba untuk "mengusir" semua Pod di node tersebut. Permintaan untuk mengusir Pod tersebut mungkin ditolak untuk sementara, dan alat tersebut akan mencoba ulang permintaannya secara periodik hingga semua Pod dihapus, atau hingga batas waktu yang ditentukan telah dicapai. +Saat seorang administrator klaster ingin melakukan _drain_ terhadap sebuah node, ia akan menggunakan perintah `kubectl drain`. Alat tersebut mencoba untuk "mengusir" semua Pod di node tersebut. Permintaan untuk mengusir Pod tersebut mungkin ditolak untuk sementara, dan alat tersebut akan mencoba ulang permintaannya secara periodik hingga semua Pod dihapus, atau hingga batas waktu yang ditentukan telah dicapai. Sebua PDB merinci jumlah replika yang dapat ditoleransi oleh sebuah aplikasi, relatif terhadap berapa banyak yang seharusnya dimiliki oleh aplikasi tersebut. Sebagai contoh, sebuah Deployment yang memiliki rincian `.spec.replicas :5` diharapkan memiliki 5 Pod pada satu waktu. Jika PDB aplikasi tersebut mengizinkan ada 4 replika pada satu waktu, maka Eviction API akan mengizinkan disrupsi yag disengaja sebanyak satu, tapi tidak mengizinkan dua, pada satu waktu. @@ -85,8 +85,8 @@ Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus sec ## Contoh PDB -Kita ambil contoh sebuah kluster dengan 3 node, `node-1` hingga `node-3`. -Kluster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebut awalnya memiliki 3 replika, yang akan kita namai `Pod-a`, `Pod-b`, dan `Pod-c`. Sebuah Pod lain yang tidak bersangkutan dan tidak memiliki PDB, dinamai `Pod-x` juga terlihat. Awalnya, Pod-pod tersebut berada pada node-node sebagai berikut: +Kita ambil contoh sebuah klaster dengan 3 node, `node-1` hingga `node-3`. +Klaster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebut awalnya memiliki 3 replika, yang akan kita namai `Pod-a`, `Pod-b`, dan `Pod-c`. Sebuah Pod lain yang tidak bersangkutan dan tidak memiliki PDB, dinamai `Pod-x` juga terlihat. Awalnya, Pod-pod tersebut berada pada node-node sebagai berikut: | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -95,7 +95,7 @@ Kluster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebu 3 Pod `Pod-a` hingga `Pod-c` adalah bagian dari sebuah Deployment, dan mereka secara kolektif memiliki sebuah PDB yang mengharuskan ada setidaknya 2 dari 3 Pod untuk tersedia sepanjang waktu. -Sebagai contoh, asumsikan administrator kluster ingin me-_reboot_ ke dalam versi kernel baru untuk memperbaiki kesalahan di dalam kernel lama. Administator kluster pertama-tama mencoba untuk melakukan _drain_ terhadap `node-1` menggunakan perintah `kubectl drain`. Perintah tersebut mencoba untuk mengusir `Pod-a` dan `Pod-x`. Hal ini langsung berhasil. Kedua Pod tersebut masuk ke dalam kondisi `terminating` secara bersamaan. Hal ini mengubah kondisi kluster menjadi sebagai berikut: +Sebagai contoh, asumsikan administrator klaster ingin me-_reboot_ ke dalam versi kernel baru untuk memperbaiki kesalahan di dalam kernel lama. Administator klaster pertama-tama mencoba untuk melakukan _drain_ terhadap `node-1` menggunakan perintah `kubectl drain`. Perintah tersebut mencoba untuk mengusir `Pod-a` dan `Pod-x`. Hal ini langsung berhasil. Kedua Pod tersebut masuk ke dalam kondisi `terminating` secara bersamaan. Hal ini mengubah kondisi klaster menjadi sebagai berikut: | node-1 _draining_ | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| @@ -106,41 +106,41 @@ Deployment tersebut melihat bahwa salah satu Pod berada dalam kondisi `terminati (Catatan: untuk sebuah StatefulSet, `Pod-a`, akan dinamai dengan `Pod-1`, harus diterminasi hingga selesai sebelum penggantinya, yang juga dinamai `Pod-1` tetapi memiliki UID yang berbeda, akan dibuat. Selain hal ini, seluruh contoh ini juga berlaku untuk StatefulSet.) -Sekarang, kluster berada pada kondisi berikut: +Sekarang, klaster berada pada kondisi berikut: | node-1 _draining_ | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| | Pod-a _terminating_ | Pod-b _available_ | Pod-c _available_ | | Pod-x _terminating_ | Pod-d _starting_ | Pod-y | -Pada satu waktu, Pod-pod yang diusir pun selesai diterminasi, dan kondisi kluster menjadi seperti berikut: +Pada satu waktu, Pod-pod yang diusir pun selesai diterminasi, dan kondisi klaster menjadi seperti berikut: | node-1 _drained_ | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| | | Pod-b _available_ | Pod-c _available_ | | | Pod-d _starting_ | Pod-y | -Pada titik ini, jika seorang administrator kluster yang tidak sabar mencoba untuk melakukan _drain_ terhadap `node-2` atau `node-3`, perintah untuk melakukan _drain_ terhadap node tersebut akan terhalang, karena hanya ada 2 Pod yang tersedia, dan PDB-nya membutuhkan setidaknya ada 2 Pod tersedia. Setelah beberapa waktu, `Pod-d` menjadi tersedia. +Pada titik ini, jika seorang administrator klaster yang tidak sabar mencoba untuk melakukan _drain_ terhadap `node-2` atau `node-3`, perintah untuk melakukan _drain_ terhadap node tersebut akan terhalang, karena hanya ada 2 Pod yang tersedia, dan PDB-nya membutuhkan setidaknya ada 2 Pod tersedia. Setelah beberapa waktu, `Pod-d` menjadi tersedia. -Kondisi kluster menjadi seperti berikut: +Kondisi klaster menjadi seperti berikut: | node-1 _drained_ | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| | | Pod-b _available_ | Pod-c _available_ | | | Pod-d _available_ | Pod-y | -Sekarang, administrator kluster mencoba untuk melakukan _drain_ terhadap `node-2`. Perintah _drain_ tersebut akan mencoba mengusir Pod-pod tersebut secara berurutan (tidak bersamaan), misalnya `Pod-b` yang pertama dan diikuti dengan `Pod-d`. Perintah tersebut akan berhasil mengusir `Pod-b`. Tetapi, pada saat ia mencoba untuk mengusir `Pod-d`, hal tersebut akan ditolak karena hal tersebut akan mengakibatkan hanya satu Pod yang tersedia untuk Deployment yang bersangkutan. +Sekarang, administrator klaster mencoba untuk melakukan _drain_ terhadap `node-2`. Perintah _drain_ tersebut akan mencoba mengusir Pod-pod tersebut secara berurutan (tidak bersamaan), misalnya `Pod-b` yang pertama dan diikuti dengan `Pod-d`. Perintah tersebut akan berhasil mengusir `Pod-b`. Tetapi, pada saat ia mencoba untuk mengusir `Pod-d`, hal tersebut akan ditolak karena hal tersebut akan mengakibatkan hanya satu Pod yang tersedia untuk Deployment yang bersangkutan. Deployment tersebut membuat pengganti `Pod-b` yang dinamai `Pod-e`. -Karena tidak ada sumber daya kluster yang cukup untuk mengalokasikan `Pod-e`, proses _drain_ akan kembali terhalang. -Kluster mungkin berada pada kondisi berikut: +Karena tidak ada sumber daya klaster yang cukup untuk mengalokasikan `Pod-e`, proses _drain_ akan kembali terhalang. +Klaster mungkin berada pada kondisi berikut: | node-1 _drained_ | node-2 | node-3 | _no node_ | |:--------------------:|:-------------------:|:------------------:|:------------------:| | | Pod-b _available_ | Pod-c _available_ | Pod-e _pending_ | | | Pod-d _available_ | Pod-y | | -Pada titik ini, administrator kluster mesti menambah sebuah node untuk kluster agar bisa melanjutkan pembaruan kluster. +Pada titik ini, administrator klaster mesti menambah sebuah node untuk klaster agar bisa melanjutkan pembaruan klaster. Kamu dapat melihat bagaimana frekuensi disrupsi dapat berubah-ubah pada Kubernetes, tergantung pada: @@ -148,30 +148,30 @@ Kamu dapat melihat bagaimana frekuensi disrupsi dapat berubah-ubah pada Kubernet - Berapa lama waktu yang dibutuhkan untuk mematikan sebuah Pod secara _graceful_ - Berapa lama waktu yang dibutuhkan untuk memulai sebuah Pod - Tipe pengendali -- Kapasitas sumber daya kluster +- Kapasitas sumber daya klaster -## Memisahkan Peran Pemilik Kluster dan Pemilik Aplikasi +## Memisahkan Peran Pemilik Klaster dan Pemilik Aplikasi -Seringkali akan bermanfaat untuk berpikir Administrator Kluster dan Pemilik Aplikasi sebagai peran yang terpisah dan dengan pengetahuan yang terbatas satu sama lainnya. Pemisahan ini dapat dimengerti dalam beberapa skenario berikut: +Seringkali akan bermanfaat untuk berpikir Administrator Klaster dan Pemilik Aplikasi sebagai peran yang terpisah dan dengan pengetahuan yang terbatas satu sama lainnya. Pemisahan ini dapat dimengerti dalam beberapa skenario berikut: -- Saat ada banyak tim aplikasi yang berbagi pakai sebuah kluster Kubernetes, dan ada pembagian peran yang spesifik -- Saat alat atau servis pihak ketiga digunakan untuk melakukan otomasi manajemen kluster. +- Saat ada banyak tim aplikasi yang berbagi pakai sebuah klaster Kubernetes, dan ada pembagian peran yang spesifik +- Saat alat atau servis pihak ketiga digunakan untuk melakukan otomasi manajemen klaster. PDB mendukung pemisahan peran ini dengan cara menyediakan antarmuka bagi peran-peran tersebut. Jika kamu tidak memiliki pemisahan peran seperti ini pada organisasimu, kamu mungkin tidak membutuhkan PDB. -## Bagaimana cara melakukan Tindakan Disruptif terhadap Kluster +## Bagaimana cara melakukan Tindakan Disruptif terhadap Klaster -Jika kamu adalah Administrator Kluster, maka kamu mesti melakukan tindakan disruptif pada setiap node di klustermu, seperti melakukan pembaruan perangkat lunak pada node, berikut beberapa opsinya: +Jika kamu adalah Administrator Klaster, maka kamu mesti melakukan tindakan disruptif pada setiap node di klastermu, seperti melakukan pembaruan perangkat lunak pada node, berikut beberapa opsinya: - Menerima _downtime_ pada saat pembaruan node -- Melakukan _failover_ ke replika lengkap kluster lain. +- Melakukan _failover_ ke replika lengkap klaster lain. - Tanpa _downtime_, tetapi mungkin lebih mahal, baik ongkos duplikasi node-node dan tenaga yang dibutuhkan untuk melakukan _failover_. - Membuat aplikasi yang toleran terhadap disrupsi, dan gunakan PDB. - Tanpa _downtime_. - Duplikasi sumber daya yang minimal. - - Mengizinkan lebih banyak otomasi administrasi kluster. + - Mengizinkan lebih banyak otomasi administrasi klaster. - Membuat aplikasi yang toleran terhadap disrupsi agak rumit, tetapi usaha yang dilakukan untuk menoleransi disrupsi yang disengaja kebanyakan beririsan dengan usaha untuk mendukung _autoscaling_ dan menoleransi disrupsi yang tidak disengaja. {{% /capture %}} diff --git a/content/id/docs/concepts/workloads/pods/init-containers.md b/content/id/docs/concepts/workloads/pods/init-containers.md index 9f61953874..f792e2b1df 100644 --- a/content/id/docs/concepts/workloads/pods/init-containers.md +++ b/content/id/docs/concepts/workloads/pods/init-containers.md @@ -267,7 +267,7 @@ Pod dapat diulang kembali, yang berakibat pada diulangnya eksekusi Init Containe ## Dukungan dan kompatibilitas -Sebuah kluster dengan versi Apiserver 1.6.0 ke atas mendukung Init Container melalui kolom `.spec.initContainers`. Versi-versi sebelumnya mendukung Init Container melalui anotasi _alpha_ atau _beta_. Kolom `.spec.initContainers` juga diduplikasikan dalam bentuk anotasi _alpha_ dan _beta_ agar Kubelet versi 1.3.0 ke atas dapat menjalankan Init Container, dan agar Apiserver versi 1.6 dapat dengan aman dikembalikan ke versi 1.5.x tanpa kehilangan fungsionalitas Pod-pod yang telah dibuat sebelumnya. +Sebuah klaster dengan versi Apiserver 1.6.0 ke atas mendukung Init Container melalui kolom `.spec.initContainers`. Versi-versi sebelumnya mendukung Init Container melalui anotasi _alpha_ atau _beta_. Kolom `.spec.initContainers` juga diduplikasikan dalam bentuk anotasi _alpha_ dan _beta_ agar Kubelet versi 1.3.0 ke atas dapat menjalankan Init Container, dan agar Apiserver versi 1.6 dapat dengan aman dikembalikan ke versi 1.5.x tanpa kehilangan fungsionalitas Pod-pod yang telah dibuat sebelumnya. Pada Apiserver dan Kubelet versi 1.8.0 ke atas, dukungan untuk anotasi _alpha_ dan _beta_ telah dihapus, sehingga dibutuhkan konversi (manual) dari anotasi yang telah kedaluwarsa tersebut ke dalam bentuk kolom `.spec.initContainers`. diff --git a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md index 386e49640c..59bd066a30 100644 --- a/content/id/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/id/docs/concepts/workloads/pods/pod-lifecycle.md @@ -246,7 +246,7 @@ Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk mem 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. -Jika node mati atau sambungannya terputus dari kluster, Kubernetes mengatur +Jika node mati atau sambungannya terputus dari klaster, Kubernetes mengatur `phase` dari semua Pod pada node yang mati untuk menjadi Failed. ## Contoh diff --git a/content/id/docs/concepts/workloads/pods/pod-overview.md b/content/id/docs/concepts/workloads/pods/pod-overview.md index a363a8f87c..e5c6f23c68 100644 --- a/content/id/docs/concepts/workloads/pods/pod-overview.md +++ b/content/id/docs/concepts/workloads/pods/pod-overview.md @@ -15,13 +15,13 @@ Halaman ini menyajikan ikhtisar dari `Pod`, objek terkecil yang dapat di *deploy {{% capture body %}} ## Memahami Pod -Sebuah *Pod* adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana di dalam objek model Kubernetes yang dapat dibuat dan di *deploy*. Sebuah *Pod* merepresentasikan suatu proses yang berjalan di dalam kluster. +Sebuah *Pod* adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana di dalam objek model Kubernetes yang dapat dibuat dan di *deploy*. Sebuah *Pod* merepresentasikan suatu proses yang berjalan di dalam klaster. *Pod* membungkus sebuah kontainer (atau, di beberapa kasus, beberapa kontainer), sumber penyimpanan, alamat jaringan *IP* yang unik, dan opsi yang mengatur bagaimana kontainer harus dijalankan. *Pod* merupakan representasi dari unit *deployment*: sebuah *instance* aplikasi di dalam Kubernetes, yang mungkin terdiri dari satu kontainer atau sekumpulan kontainer yang berbagi *resource*. [Docker](https://www.docker.com) adalah salah satu kontainer *runtime* yang paling umum digunakan di Kubernetes *Pod*, tetapi *Pod* mendukung kontainer *runtime* lainnya. -*Pod* di Kubernetes kluster dapat digunakan dengan dua cara: +*Pod* di Kubernetes klaster dapat digunakan dengan dua cara: * **Pod menjalankan satu kontainer**. Model satu kontainer per *Pod* adalah model yang umum digunakan di Kubernetes; kamu dapat membayangkan sebuah *Pod* sebagai pembungkus kontainer tersebut, dan Kubernetes tidak mengelola kontainer secara langsung tetapi mengelola *Pod* tersebut. * **Pod menjalankan beberapa kontainer yang perlu berjalan bersamaan**. Sebuah *Pod* dapat membungkus sebuah aplikasi yang terdiri dari beberapa kontainer yang perlu berbagi *resource*. Kontainer yang ditempatkan di dalam satu *Pod* ini membentuk sebuah layanan. Sebuah kontainer menyajikan berkas dari sumber penyimpanan ke publik, sedangkan kontainer *sidecar* yang lain melakukan pembaharuan terhadap berkas tersebut. *Pod* membungkus semua kontainer dan *resource* penyimpanan sebagai satu kesatuan yang dapat dikelola. @@ -34,7 +34,7 @@ Sebuah *Pod* adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana Setiap *Pod* dimaksudkan untuk menjalankan satu *instance* aplikasi. Jika kamu ingin mengembangkan aplikasi secara horizontal (contoh, banyak *instance* sekaligus), kamu dapat menggunakan banyak *Pod*, satu untuk setiap *instance*. Di Kubernetes, konsep ini umumnya disebut dengan replikasi. *Pod* yang direplikasi biasanya dibuat dan dikelola sebagai grup oleh objek abstraksi yang disebut kontroler. Lihat [Pod dan Kontroler](#pod-dan-kontroler) untuk informasi selengkapnya. ### 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. +*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 klaster. 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: {{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}} @@ -52,7 +52,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod* ## Bekerja dengan Pod -Kamu akan jarang membuat *Pod* secara langsung di Kubernetes. Ini karena *Pod* dirancang sebagai entitas sesaat. Saat *Pod* dibuat (baik oleh kamu, atau secara tidak langsung oleh kontroler), *Pod* ditempatkan dan dijalankan di sebuah *Node* di dalam kluster. *Pod* akan tetap di *Node* tersebut sampai proses dihentikan, Objek *Pod* dihapus, *Pod* dihentikan karena kekurangan *resource*, atau *Node* tersebut berhenti berjalan. +Kamu akan jarang membuat *Pod* secara langsung di Kubernetes. Ini karena *Pod* dirancang sebagai entitas sesaat. Saat *Pod* dibuat (baik oleh kamu, atau secara tidak langsung oleh kontroler), *Pod* ditempatkan dan dijalankan di sebuah *Node* di dalam klaster. *Pod* akan tetap di *Node* tersebut sampai proses dihentikan, Objek *Pod* dihapus, *Pod* dihentikan karena kekurangan *resource*, atau *Node* tersebut berhenti berjalan. {{< note >}} Tidak perlu bingung untuk membedakan antara menjalankan ulang sebuah kontainer di dalam *Pod* dan menjalankan ulang *Pod*. *Pod* itu sendiri tidak berjalan, tetapi *Pod* adalah *environment* kontainer itu berjalan dan akan tetap ada sampai dihapus. @@ -62,7 +62,7 @@ Tidak perlu bingung untuk membedakan antara menjalankan ulang sebuah kontainer d ### Pod dan Kontroler -Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replikasi dan menyediakan kemampuan penyembuhan diri sendiri pada lingkup kluster. Sebagai contoh, jika sebuah *Node* gagal, kontroler akan otomatis mengganti *Pod* tersebut dengan menempatkan *Pod* yang identik di *Node* yang lain. +Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replikasi dan menyediakan kemampuan penyembuhan diri sendiri pada lingkup klaster. Sebagai contoh, jika sebuah *Node* gagal, kontroler akan otomatis mengganti *Pod* tersebut dengan menempatkan *Pod* yang identik di *Node* yang lain. Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi: diff --git a/content/id/docs/concepts/workloads/pods/pod.md b/content/id/docs/concepts/workloads/pods/pod.md index 52a4488e62..b806480572 100644 --- a/content/id/docs/concepts/workloads/pods/pod.md +++ b/content/id/docs/concepts/workloads/pods/pod.md @@ -161,6 +161,7 @@ bisa memberikan dukungan terhadap Pod yang _stateful_. Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang relatif umum diantara sistem penjadwalan kluster, seperti + [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), dan @@ -172,7 +173,7 @@ Pod diekspose sebagai _primitive_ untuk memfasilitasi hal berikut: * mendukung operasi pada level Pod tanpa perlu melakukan proksi melalui API pengontrol * pemisahan antara umur suatu Pod dan pengontrol, seperti misalnya _bootstrapping_. * pemisahan antara pengontrol dan servis, pengontrol _endpoint_ hanya memperhatikan Pod -* komposisi yang bersih antara fungsionalitas dilevel Kubelet dan kluster. Kubelet +* komposisi yang bersih antara fungsionalitas dilevel Kubelet dan klaster. Kubelet secara efektif adalah pengontrol Pod. * aplikasi dengan ketersediaan tinggi, yang akan mengharapkan Pod akan digantikan sebelum dihentikan dan tentu saja sebelum dihapus, seperti dalam kasus penggusuran @@ -180,7 +181,7 @@ Pod diekspose sebagai _primitive_ untuk memfasilitasi hal berikut: ## Penghentian Pod -Karena Pod merepresentasikan proses yang berjalan pada mesin didalam kluster, sangat +Karena Pod merepresentasikan proses yang berjalan pada mesin didalam klaster, sangat penting untuk memperbolehkan proses ini berhenti secara normal ketika sudah tidak dibutuhkan (dibandingkan dengan dihentikan paksa dengan sinyal KILL dan tidak memiliki waktu untuk dibersihkan). Pengguna seharusnya dapat meminta untuk menghapus dan tahu @@ -229,7 +230,7 @@ untuk melakukan penghapusan paksa. ### Penghapusan paksa sebuah Pod Penghapusan paksa dari sebuah Pod didefinisikan sebagai penghapusan Pod dari _state_ -kluster dan etcd secara langsung. Ketika penghapusan paksa dilakukan, API server tidak +klaster dan etcd secara langsung. Ketika penghapusan paksa dilakukan, API server tidak akan menunggu konfirmasi dari kubelet bahwa Pod sudah dihentikan pada mesin ia berjalan. Ini menghapus Pod secara langsung dari API, sehingga Pod baru bisa dibuat dengan nama yang sama. Dalam mesin, Pod yang dihentikan paksa akan tetap diberikan sedikit masa diff --git a/content/id/docs/concepts/workloads/pods/podpreset.md b/content/id/docs/concepts/workloads/pods/podpreset.md index c9e1a02f3d..d15f3648fb 100644 --- a/content/id/docs/concepts/workloads/pods/podpreset.md +++ b/content/id/docs/concepts/workloads/pods/podpreset.md @@ -40,9 +40,9 @@ Mungkin akan ada keadaan dimana kamu menginginkan sebuah Pod tidak bisa diubah o ## Mengaktifkan Pod Preset --- -Dalam rangka untuk menggunakan Pod Preset di dalam kluster kamu, kamu harus memastikan hal berikut: +Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus memastikan hal berikut: -1. Kamu telah mengaktifkan tipe API `settings.k8s.io/v1alpha1/podpreset`. Sebagai contoh, ini bisa dilakukan dengan menambahkan `settings.k8s.io/v1alpha1=true` di dalam opsi `--runtime-config` untuk API _server_. Dalam _minikube_ tambahkan argumen berikut `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` saat menginisialisasi kluster. +1. Kamu telah mengaktifkan tipe API `settings.k8s.io/v1alpha1/podpreset`. Sebagai contoh, ini bisa dilakukan dengan menambahkan `settings.k8s.io/v1alpha1=true` di dalam opsi `--runtime-config` untuk API _server_. Dalam _minikube_ tambahkan argumen berikut `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` saat menginisialisasi klaster. 1. Kamu telah mengaktifkan _admission controller_ dari `PodPreset`. Salah satu cara untuk melakukannya adalah dengan menambahkan `PodPreset` di dalam nilai opsi `--enable-admission-plugins` yang dispesifikasikan untuk API _server_. Dalam _minikube_ tambahkan argumen berikut @@ -50,7 +50,7 @@ Dalam rangka untuk menggunakan Pod Preset di dalam kluster kamu, kamu harus mema --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset ``` - saat menginisialisasi kluster. + saat menginisialisasi klaster. 1. Kamu telah membuat objek `PodPreset` pada _namespace_ yang kamu gunakan dengan cara mendefinisikan Pod Preset. {{% /capture %}} diff --git a/content/id/docs/home/_index.md b/content/id/docs/home/_index.md index 0cd83c9c22..b24e881cb6 100644 --- a/content/id/docs/home/_index.md +++ b/content/id/docs/home/_index.md @@ -28,8 +28,8 @@ cards: button: "Lihat tutorial" button_path: "/docs/tutorials" - name: setup - title: "Menyiapkan sebuah kluster" - description: "Dapatkan kluster Kubernetes sesuai dengan kapasitas dan kebutuhanmu." + title: "Menyiapkan sebuah klaster" + description: "Dapatkan klaster Kubernetes sesuai dengan kapasitas dan kebutuhanmu." button: "Menyiapkan Kubernetes" button_path: "/docs/setup" - name: tasks diff --git a/content/id/docs/reference/glossary/etcd.md b/content/id/docs/reference/glossary/etcd.md index 5dea98f0af..dc09267a21 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 klaster Kubernetes. aka: tags: - architecture - storage --- - Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data kluster Kubernetes. + Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data klaster 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). +Selalu perhatikan mekanisme untuk mem-backup data etcd pada klaster 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 7b6fb316e9..5789e4c644 100644 --- a/content/id/docs/reference/glossary/ingress.md +++ b/content/id/docs/reference/glossary/ingress.md @@ -4,7 +4,7 @@ id: ingress date: 2019-04-21 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. + Sebuah obyek API yang mengatur akses eksternal terhadap *Service* yang ada di dalam klaster, biasanya dalam bentuk *request* HTTP. aka: tags: @@ -12,7 +12,7 @@ tags: - architecture - extension --- - Sebuah obyek API yang mengatur akses eksternal terhadap *Service* yang ada di dalam kluster, biasanya dalam bentuk *request* HTTP. + Sebuah obyek API yang mengatur akses eksternal terhadap *Service* yang ada di dalam klaster, biasanya dalam bentuk *request* HTTP. diff --git a/content/id/docs/reference/glossary/kube-apiserver.md b/content/id/docs/reference/glossary/kube-apiserver.md index db4442026e..fda5ec39d5 100644 --- a/content/id/docs/reference/glossary/kube-apiserver.md +++ b/content/id/docs/reference/glossary/kube-apiserver.md @@ -15,5 +15,5 @@ tags: -Komponen ini didesain agar dapat di-scale secara horizontal. Lihat [Membangun Kluster HA](/docs/admin/high-availability/). +Komponen ini didesain agar dapat di-scale secara horizontal. Lihat [Membangun Klaster HA](/docs/admin/high-availability/). diff --git a/content/id/docs/reference/glossary/kubelet.md b/content/id/docs/reference/glossary/kubelet.md index 5913aa7837..10cc51ea07 100644 --- a/content/id/docs/reference/glossary/kubelet.md +++ b/content/id/docs/reference/glossary/kubelet.md @@ -4,12 +4,12 @@ id: kubelet date: 2019-04-21 full_link: /docs/reference/generated/kubelet short_description: > - Agen yang dijalankan pada setiap node di kluster dan bertugas memastikan kontainer dijalankan di dalam pod. + Agen yang dijalankan pada setiap node di klaster dan bertugas memastikan kontainer dijalankan di dalam pod. aka: tags: - fundamental - core-object --- - Agen yang dijalankan pada setiap node di kluster dan bertugas memastikan kontainer dijalankan di dalam pod. + Agen yang dijalankan pada setiap node di klaster dan bertugas memastikan kontainer dijalankan di dalam pod. diff --git a/content/id/docs/reference/glossary/uid.md b/content/id/docs/reference/glossary/uid.md index f9da13e36b..61bc71fcee 100755 --- a/content/id/docs/reference/glossary/uid.md +++ b/content/id/docs/reference/glossary/uid.md @@ -14,4 +14,4 @@ tags: -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. +Setiap objek yang ada pada klaster 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 44fcb69673..d170fb24e4 100644 --- a/content/id/docs/setup/_index.md +++ b/content/id/docs/setup/_index.md @@ -10,9 +10,9 @@ 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 klaster 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. +Kamu juga bisa menyiapkan klaster yang diatur sepenuhnya (fully-managed), dengan hanya menjalankan satu perintah, ataupun membuat klaster dengan solusi custom kamu sendiri pada server baremetal. {{% /capture %}} @@ -21,55 +21,55 @@ Kamu juga bisa menyiapkan kluster yang diatur sepenuhnya (fully-managed), ## Solusi pada Mesin Lokal Memulai Kubernetes bisa dilakukan dengan mudah melalui solusi pada mesin lokal. -Kamu bisa membuat dan mengevaluasi kluster Kubernetes tanpa perlu takut menghabiskan resource dan kuota penyedia cloud. +Kamu bisa membuat dan mengevaluasi klaster Kubernetes tanpa perlu takut menghabiskan resource dan kuota penyedia cloud. Sebaiknya kamu memilih solusi lokal jika kamu ingin: * Mulai belajar atau mencoba Kubernetes -* Mengembangkan dan melakukan evaluasi kluster secara lokal +* Mengembangkan dan melakukan evaluasi klaster secara lokal Pilih [solusi lokal](/docs/setup/pick-right-solution/#local-machine-solutions). ## Solusi Tersediakan (Hosted Solution) -Solusi tersediakan adalah cara yang nyaman untuk membuat dan memelihara kluster Kubernetes. Kamu tidak perlu repot, karena para penyedia solusi mengatur dan mengoperasikan kluster milikmu. +Solusi tersediakan adalah cara yang nyaman untuk membuat dan memelihara klaster Kubernetes. Kamu tidak perlu repot, karena para penyedia solusi mengatur dan mengoperasikan klaster milikmu. Sebaiknya kamu memilih solusi tersediakan ini jika kamu: * Ingin punya solusi yang diatur sepenuhnya * Fokus pada pengembangan aplikasi atau servis saja * Tidak mau punya tim SRE (Site Reliability Engineering) yang mendedikasikan waktunya untukmu, tapi ingin HA (High Availability) -* Tidak punya resource untuk menjalankan dan memonitor kluster. +* Tidak punya resource untuk menjalankan dan memonitor klaster. Pilih [solusi tersediakan](/docs/setup/pick-right-solution/#hosted-solutions). ## Turnkey – Solusi Cloud -Solusi-solusi ini memudahkan kamu untuk mempunyai kluster Kubernetes hanya dengan beberapa perintah. Lalu, solusi-solusi ini juga masih terus berkembang dan memiliki pendukung komunitas yang aktif. +Solusi-solusi ini memudahkan kamu untuk mempunyai klaster Kubernetes hanya dengan beberapa perintah. Lalu, solusi-solusi ini juga masih terus berkembang dan memiliki pendukung komunitas yang aktif. Mereka juga bisa berjalan pada berbagai macam penyedia Cloud IaaS, tapi mereka menawarkan kebebasan dan fleksibilitas sebagai pengganti dari usaha. Sebaiknya kamu memilih solusi cloud turnkey, jika kamu: * Ingin punya kontrol yang lebih daripada yang ditawarkan oleh solusi tersediakan (hosted solution) -* Ingin memiliki porsi dalam mengoperasikan kluster +* Ingin memiliki porsi dalam mengoperasikan klaster Pilih [solusi cloud turnkey](/docs/setup/pick-right-solution/#turnkey-cloud-solutions) ## Turnkey – Solusi On-Premise -Solusi-solusi ini menyediakan cara untuk membuat kluster Kubernetes di dalam jaringan cloud internal kamu yang aman, hanya dengan beberapa perintah. +Solusi-solusi ini menyediakan cara untuk membuat klaster Kubernetes di dalam jaringan cloud internal kamu yang aman, hanya dengan beberapa perintah. Sebaiknya kamu memilih solusi cloud on-premise turnkey, jika kamu: -* Ingin membuat kluster di jaringan cloud yang privat (private cloud network) +* Ingin membuat klaster di jaringan cloud yang privat (private cloud network) * Punya tim SRE yang mendedikasikan waktunya -* Punya resource untuk menjalankan dan memonitor kluster +* Punya resource untuk menjalankan dan memonitor klaster Pilih [solusi cloud on-prem turnkey](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions). ## Solusi Custom -Solusi custom adalah solusi yang paling memberikan kebebasan dalam menjalankan kluster kamu, tapi perlu keahlian. +Solusi custom adalah solusi yang paling memberikan kebebasan dalam menjalankan klaster kamu, tapi perlu keahlian. Solusi-solusi ini cukup beragam, mulai dari bare-metal sampai ke penyedia cloud, berjalan pada sistem operasi yang berbeda-beda. Pilih [solusi custom](/docs/setup/pick-right-solution/#custom-solutions). diff --git a/content/id/docs/templates/feature-state-alpha.txt b/content/id/docs/templates/feature-state-alpha.txt index 2c0b53a098..35689778fa 100644 --- a/content/id/docs/templates/feature-state-alpha.txt +++ b/content/id/docs/templates/feature-state-alpha.txt @@ -4,4 +4,4 @@ Fitur ini berada di dalam tingkatan *Alpha*, yang artinya: * 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 klaster yang digunakan untuk tujuan *testing*. diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md index 5e43aea0c4..5645744c39 100644 --- a/content/id/docs/tutorials/_index.md +++ b/content/id/docs/tutorials/_index.md @@ -32,7 +32,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus ## Aplikasi Stateless -* [Memberi Akses Aplikasi di dalam Kluster melalui IP Eksternal](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [Memberi Akses Aplikasi di dalam Klaster melalui IP Eksternal](/docs/tutorials/stateless-application/expose-external-ip-address/) * [Contoh: Deploy aplikasi Guestbook PHP dengan Redis](/docs/tutorials/stateless-application/guestbook/) @@ -56,7 +56,7 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus * [Menyiapkan CI/CD untuk Aplikasi Teka-Teki Terdistribusi pada Kubernetes (Bagian 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) -## Kluster +## Klaster * [AppArmor](/docs/tutorials/clusters/apparmor/) diff --git a/content/id/docs/tutorials/hello-minikube.md b/content/id/docs/tutorials/hello-minikube.md index 387e88d32a..e3e88be104 100644 --- a/content/id/docs/tutorials/hello-minikube.md +++ b/content/id/docs/tutorials/hello-minikube.md @@ -7,7 +7,7 @@ menu: title: "Mulai" weight: 10 post: > -

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

+

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

card: name: tutorials weight: 10 @@ -46,7 +46,7 @@ Untuk info lebih lanjut tentang perintah `docker build`, baca [dokumentasi Docke {{% capture lessoncontent %}} -## Membuat sebuah kluster Minikube +## Membuat sebuah klaster Minikube 1. Tekan **Launch Terminal** @@ -103,7 +103,7 @@ Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m ``` -4. Lihat event kluster: +4. Lihat event klaster: ```shell kubectl get events @@ -119,7 +119,7 @@ Pod menjalankan Kontainer sesuai dengan image Docker yang telah diberikan. ## Membuat sebuah Servis -Secara default, Pod hanya bisa diakses melalui alamat IP internal di dalam kluster Kubernetes. +Secara default, Pod hanya bisa diakses melalui alamat IP internal di dalam klaster Kubernetes. Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes, kamu harus ekspos Pod sebagai [*Servis*](/docs/concepts/services-networking/service/) Kubernetes. 1. Ekspos Pod pada internet publik menggunakan perintah `kubectl expose`: @@ -128,7 +128,7 @@ Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - Tanda `--type=LoadBalancer` menunjukkan bahwa kamu ingin ekspos Servis keluar dari kluster. + Tanda `--type=LoadBalancer` menunjukkan bahwa kamu ingin ekspos Servis keluar dari klaster. 2. Lihat Servis yang baru kamu buat: @@ -240,7 +240,7 @@ Minikube punya beberapa addons yang bisa diaktifkan, dinon-aktifkan, maup ## Bersih-bersih -Sekarang, mari kita bersihkan semua resource yang kamu buat di kluster: +Sekarang, mari kita bersihkan semua resource yang kamu buat di klaster: ```shell kubectl delete service hello-node diff --git a/content/id/docs/tutorials/kubernetes-basics/_index.html b/content/id/docs/tutorials/kubernetes-basics/_index.html index 636a873a63..7abc15c771 100644 --- a/content/id/docs/tutorials/kubernetes-basics/_index.html +++ b/content/id/docs/tutorials/kubernetes-basics/_index.html @@ -23,10 +23,10 @@ card:

Panduan Dasar Kubernetes

-

Tutorial ini menyediakan panduan dasar mekanisme orkestrasi kluster Kubernetes. Setiap modul memliki beberapa informasi mengenai latar belakang bagi konsep mendasar dan feature Kubernetes, termasuk mode interaktif yang dapat digunakan sebagai metode pembelajaran online. Mode tutorial interaktif ini memberikan kesempatan pengguna untuk melakukan manajemen kluster sederhana beserta aplikasi dalam kontainer yang kamu miliki.

+

Tutorial ini menyediakan panduan dasar mekanisme orkestrasi klaster Kubernetes. Setiap modul memliki beberapa informasi mengenai latar belakang bagi konsep mendasar dan feature Kubernetes, termasuk mode interaktif yang dapat digunakan sebagai metode pembelajaran online. Mode tutorial interaktif ini memberikan kesempatan pengguna untuk melakukan manajemen klaster sederhana beserta aplikasi dalam kontainer yang kamu miliki.

Dengan menggunakan mode tutorial interaktif ini, pengguna diharapkan dapat memahami:

    -
  • Deployi> sebuah aplikasi yang sudah dikontainerisasi pada kluster
    • +
  • Deployi> sebuah aplikasi yang sudah dikontainerisasi pada klaster
  • Melakukan scale deployment
  • Meng-update aplikasi yang sudah dikontainerisasi dengan menggunakan versi aplikasi terbaru
  • Men-debug aplikasi yang sudah dikontainerisasi
    • diff --git a/content/id/examples/policy/restricted-psp.yaml b/content/id/examples/policy/restricted-psp.yaml index b848aade0e..49e3960b04 100644 --- a/content/id/examples/policy/restricted-psp.yaml +++ b/content/id/examples/policy/restricted-psp.yaml @@ -22,7 +22,7 @@ spec: - 'projected' - 'secret' - 'downwardAPI' - # Berasumsi bahwa persistentVolumes yang disetel oleh admin kluster aman untuk digunakan. + # Berasumsi bahwa persistentVolumes yang disetel oleh admin klaster aman untuk digunakan. - 'persistentVolumeClaim' hostNetwork: false hostIPC: false