whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)

Browse Source
This commit is contained in:
irvifa
2019-12-16 20:11:37 +07:00
committed by Kubernetes Prow Robot
parent a7f6a78d55
commit 39fe327423
65 changed files with 459 additions and 458 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/id/docs/concepts/configuration/assign-pod-node.md
+8 -8
View File
@@ -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 <node-name> <label-key>=<label-value>` 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 <node-name> <label-key>=<label-value>` 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).
content/id/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+22 -22
View File
@@ -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 %}}
content/id/docs/concepts/configuration/taint-and-toleration.md
+2 -2
View File
@@ -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