diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 54d87f0cdf..5f9dc3816d 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -154,6 +154,7 @@ aliases: - hanjiayao - lichuqiang - SataQiu + - tanjunchen - tengqm - xiangpengzhao - xichengliudui diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 5cc52cdbe6..09a02d6afc 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -30,13 +30,23 @@ node4 Ready 2m43s v1.16.0 node=node4,zone=zoneB Then the cluster is logically viewed as below: -``` -+---------------+---------------+ -| zoneA | zoneB | -+-------+-------+-------+-------+ -| node1 | node2 | node3 | node4 | -+-------+-------+-------+-------+ -``` +{{}} +graph TB + subgraph "zoneB" + n3(Node3) + n4(Node4) + end + subgraph "zoneA" + n1(Node1) + n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4 k8s; + class zoneA,zoneB cluster; +{{< /mermaid >}} Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/kubernetes-api/labels-annotations-taints/) that are created and populated automatically on most clusters. @@ -80,17 +90,25 @@ You can read more about this field by running `kubectl explain Pod.spec.topology ### Example: One TopologySpreadConstraint -Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod): +Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively: -``` -+---------------+---------------+ -| zoneA | zoneB | -+-------+-------+-------+-------+ -| node1 | node2 | node3 | node4 | -+-------+-------+-------+-------+ -| P | P | P | | -+-------+-------+-------+-------+ -``` +{{}} +graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4,p1,p2,p3 k8s; + class zoneA,zoneB cluster; +{{< /mermaid >}} If we want an incoming Pod to be evenly spread with existing Pods across zones, the spec can be given as: @@ -100,15 +118,46 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones, If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB": -``` -+---------------+---------------+ +---------------+---------------+ -| zoneA | zoneB | | zoneA | zoneB | -+-------+-------+-------+-------+ +-------+-------+-------+-------+ -| node1 | node2 | node3 | node4 | OR | node1 | node2 | node3 | node4 | -+-------+-------+-------+-------+ +-------+-------+-------+-------+ -| P | P | P | P | | P | P | P P | | -+-------+-------+-------+-------+ +-------+-------+-------+-------+ -``` +{{}} +graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + p4(mypod) --> n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4,p1,p2,p3 k8s; + class p4 plain; + class zoneA,zoneB cluster; +{{< /mermaid >}} + +OR + +{{}} +graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + p4(mypod) --> n3 + n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4,p1,p2,p3 k8s; + class p4 plain; + class zoneA,zoneB cluster; +{{< /mermaid >}} You can tweak the Pod spec to meet various kinds of requirements: @@ -118,17 +167,26 @@ You can tweak the Pod spec to meet various kinds of requirements: ### Example: Multiple TopologySpreadConstraints -This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively (`P` represents Pod): +This builds upon the previous example. Suppose you have a 4-node cluster where 3 Pods labeled `foo:bar` are located in node1, node2 and node3 respectively: -``` -+---------------+---------------+ -| zoneA | zoneB | -+-------+-------+-------+-------+ -| node1 | node2 | node3 | node4 | -+-------+-------+-------+-------+ -| P | P | P | | -+-------+-------+-------+-------+ -``` +{{}} +graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4,p1,p2,p3 k8s; + class p4 plain; + class zoneA,zoneB cluster; +{{< /mermaid >}} You can use 2 TopologySpreadConstraints to control the Pods spreading on both zone and node: @@ -138,15 +196,24 @@ In this case, to match the first constraint, the incoming Pod can only be placed Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones: -``` -+---------------+-------+ -| zoneA | zoneB | -+-------+-------+-------+ -| node1 | node2 | node3 | -+-------+-------+-------+ -| P P | P | P P | -+-------+-------+-------+ -``` +{{}} +graph BT + subgraph "zoneB" + p4(Pod) --> n3(Node3) + p5(Pod) --> n3 + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n1 + p3(Pod) --> n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4,p1,p2,p3,p4,p5 k8s; + class zoneA,zoneB cluster; +{{< /mermaid >}} If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing. @@ -169,15 +236,37 @@ There are some implicit conventions worth noting here: Suppose you have a 5-node cluster ranging from zoneA to zoneC: - ``` - +---------------+---------------+-------+ - | zoneA | zoneB | zoneC | - +-------+-------+-------+-------+-------+ - | node1 | node2 | node3 | node4 | node5 | - +-------+-------+-------+-------+-------+ - | P | P | P | | | - +-------+-------+-------+-------+-------+ - ``` + {{}} + graph BT + subgraph "zoneB" + p3(Pod) --> n3(Node3) + n4(Node4) + end + subgraph "zoneA" + p1(Pod) --> n1(Node1) + p2(Pod) --> n2(Node2) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n1,n2,n3,n4,p1,p2,p3 k8s; + class p4 plain; + class zoneA,zoneB cluster; + {{< /mermaid >}} + + {{}} + graph BT + subgraph "zoneC" + n5(Node5) + end + + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class n5 k8s; + class zoneC cluster; + {{< /mermaid >}} and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected. diff --git a/content/id/_index.html b/content/id/_index.html index e95d661b76..10c0775866 100644 --- a/content/id/_index.html +++ b/content/id/_index.html @@ -43,7 +43,6 @@ Kubernetes sebagai open source memberikan kamu kebebasan untuk menggunaka

-
Hadiri KubeCon di Barcelona tanggal 20-23 Mei 2019

diff --git a/content/id/docs/reference/_index.md b/content/id/docs/reference/_index.md new file mode 100644 index 0000000000..2191ab6df8 --- /dev/null +++ b/content/id/docs/reference/_index.md @@ -0,0 +1,13 @@ +--- +title: Referensi +linkTitle: "Referensi" +main_menu: true +weight: 70 +content_type: concept +--- + + + +Bagian dari dokumentasi Kubernetes ini berisi referensi-referensi. + + \ No newline at end of file diff --git a/content/id/docs/reference/access-authn-authz/_index.md b/content/id/docs/reference/access-authn-authz/_index.md new file mode 100644 index 0000000000..5571044289 --- /dev/null +++ b/content/id/docs/reference/access-authn-authz/_index.md @@ -0,0 +1,4 @@ +--- +title: Mengakses API +weight: 20 +--- diff --git a/content/id/docs/reference/access-authn-authz/rbac.md b/content/id/docs/reference/access-authn-authz/rbac.md index 8a058b6710..03e7d2e076 100644 --- a/content/id/docs/reference/access-authn-authz/rbac.md +++ b/content/id/docs/reference/access-authn-authz/rbac.md @@ -6,39 +6,40 @@ weight: 70 --- -Kontrol akses berbasis peran (RBAC) adalah metode pengaturan akses ke sumber daya komputer -atau jaringan berdasarkan peran pengguna individu dalam organisasi kamu. +_Role-based access control_ (RBAC) atau kontrol akses berbasis rol adalah metode pengaturan akses ke sumber daya komputer +atau jaringan berdasarkan rol pengguna individu dalam organisasimu. -Otorisasi RBAC menggunakan `rbac.authorization.k8s.io` kelompok API untuk mengendalikan keputusan -otorisasi, memungkinkan kamu untuk mengkonfigurasi kebijakan secara dinamis melalui API Kubernetes. +Otorisasi RBAC menggunakan {{< glossary_tooltip text="grup API" term_id="api-group" >}} `rbac.authorization.k8s.io` untuk mengendalikan keputusan +otorisasi. Hal ini memungkinkanmu untuk mengonfigurasi kebijakan secara dinamis melalui +API Kubernetes. -Untuk mengaktifkan RBAC, jalankan Kubernetes dengan _flag_ `--authorization-mode` atur -dengan daftar yang dipisahkan koma dengan menyertakan `RBAC`; +Untuk mengaktifkan RBAC, jalankan {{< glossary_tooltip text="server API" term_id="kube-apiserver" >}} dengan _flag_ `--authorization-mode` diatur +dengan daftar yang dipisahkan koma yang menyertakan `RBAC`; sebagai contoh: ```shell kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options ``` -## Objek API {#api-overview} +## Objek API {#api-overview} API RBAC mendeklarasikan empat jenis objek Kubernetes: Role, ClusterRole, -RoleBinding and ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. +RoleBinding dan ClusterRoleBinding. kamu bisa [mendeskripsikan beberapa objek](/id/docs/concepts/overview/working-with-objects/kubernetes-objects/#understanding-kubernetes-objects), atau mengubahnya menggunakan alat seperti `kubectl`, seperti objek Kubernetes lain. {{< caution >}} Objek-objek ini, dengan disengaja, memaksakan pembatasan akses. Jika kamu melakukan perubahan ke klaster saat kamu belajar, lihat -[pencegahan eskalasi hak istimewa dan _bootstrap_](#privilege-eskalasi-pencegahan-dan-bootstrap) +[pencegahan eskalasi privilese dan _bootstrapping_](#pencegahan-eskalasi-privilese-dan-bootstrapping) untuk memahami bagaimana pembatasan tersebut dapat mencegah kamu melakukan beberapa perubahan. {{< /caution >}} ### Role dan ClusterRole -Sebuah RBAC Role atau ClusterRole berisi aturan yang mewakili sekumpulan izin. +Sebuah Role RBAC atau ClusterRole memuat aturan yang mewakili sekumpulan izin. Izin bersifat aditif (tidak ada aturan "tolak"). -Sebuah Role selalu mengatur izin dalam Namespace tertentu; +Sebuah Role selalu mengatur izin dalam {{< glossary_tooltip text="Namespace" term_id="namespace" >}} tertentu; ketika kamu membuat Role, kamu harus menentukan Namespace tempat Role tersebut berada. ClusterRole, sebaliknya, adalah sumber daya tanpa Namespace. Sumber daya tersebut memiliki nama yang berbeda (Role @@ -48,16 +49,16 @@ tidak mungkin keduanya. ClusterRole memiliki beberapa kegunaan. Kamu bisa menggunakan ClusterRole untuk: 1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam sebuah Namespace atau lebih -1. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace -1. mendefinisikan izin pada sumber daya yang dicakup klaster +2. mendefinisikan izin pada sumber daya dalam Namespace dan diberikan dalam seluruh Namespace +3. mendefinisikan izin pada sumber daya dalam lingkup klaster -Jika kamu ingin mendefinisikan sebuah peran dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan -peran di level klaster, gunakan ClusterRole. +Jika kamu ingin mendefinisikan sebuah rol dalam Namespace, gunakan Role; jika kamu ingin mendefinisikan +rol di level klaster, gunakan ClusterRole. #### Contoh Role Berikut adalah contoh Role dalam Namespace bawaan yang dapat digunakan -untuk memberikan akses baca pada Pod: +untuk memberikan akses baca pada {{< glossary_tooltip text="Pod" term_id="pod" >}}: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -66,7 +67,7 @@ metadata: Namespace: default name: pod-reader rules: -- apiGroups: [""] # "" mengindikasikan core API group +- apiGroups: [""] # "" mengindikasikan grup API inti resources: ["pods"] verbs: ["get", "watch", "list"] ``` @@ -74,16 +75,16 @@ rules: #### Contoh ClusterRole ClusterRole dapat digunakan untuk memberikan izin yang sama dengan Role. -Karena ClusterRole memiliki lingkup-klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: +Karena ClusterRole memiliki lingkup klaster, kamu juga dapat menggunakannya untuk memberikan akses ke: -* sumber daya lingkup-klaster (seperti Nodes) +* sumber daya lingkup klaster (seperti {{< glossary_tooltip text="Node" term_id="node" >}}) * berbagai _endpoint_ non-sumber daya (seperti `/healthz`) * sumber daya Namespace (seperti Pod), di semua Namespace Sebagai contoh: kamu bisa menggunakan ClusterRole untuk memungkinkan pengguna tertentu untuk menjalankan `kubectl get pods --all-namespaces`. Berikut adalah contoh ClusterRole yang dapat digunakan untuk memberikan akses baca pada -Secret di Namespace tertentu, atau di semua Namespace (tergantung bagaimana itu [terikat](#rolebinding-dan-clusterrolebinding)): +{{< glossary_tooltip text="Secret" term_id="secret" >}} di Namespace tertentu, atau di semua Namespace (tergantung bagaimana [keterikatannya](#rolebinding-dan-clusterrolebinding)): ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -112,7 +113,7 @@ memberikan akses tersebut pada lingkup klaster. RoleBinding dapat merujuk Role apa pun di Namespace yang sama. Atau, RoleBinding dapat mereferensikan ClusterRole dan memasangkan ClusterRole tersebut ke Namespace dari RoleBinding. -Jika kamu ingin memasangkan ClusterRole ke semua Namespace di klaster kamu, kamu dapat menggunakan +Jika kamu ingin memasangkan ClusterRole ke semua Namespace di dalam klastermu, kamu dapat menggunakan ClusterRoleBinding. Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan @@ -121,12 +122,12 @@ Nama objek RoleBinding atau ClusterRoleBinding harus valid menggunakan #### Contoh RoleBinding Berikut adalah contoh dari RoleBinding yang memberikan Role "pod-reader" kepada pengguna "jane" -pada Namespace bawaan. -Ini memungkinkan "jane" untuk membaca Pod di Namespace bawaan. +pada Namespace "default". +Ini memungkinkan "jane" untuk membaca Pod di Namespace "default". ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# Role binding memungkinkan "jane" untuk membaca Pod di Namespace bawaan +# RoleBinding memungkinkan "jane" untuk membaca Pod di Namespace "default" # Kamu harus sudah memiliki Role bernama "pod-reader" di Namespace tersebut. kind: RoleBinding metadata: @@ -138,7 +139,7 @@ subjects: name: jane # "name" peka huruf besar-kecil apiGroup: rbac.authorization.k8s.io roleRef: - # "roleRef" menentukan pengikatan ke Role / ClusterRole + # "roleRef" menentukan pengikatan (binding) ke Role / ClusterRole kind: Role # ini harus Role atau ClusterRole name: pod-reader # ini harus sesuai dengan nama Role atau ClusterRole yang ingin kamu gunakan apiGroup: rbac.authorization.k8s.io @@ -146,22 +147,22 @@ roleRef: RoleBinding juga bisa mereferensikan ClusterRole untuk memberikan izin yang didefinisikan di dalam ClusterRole ke sumber daya di dalam Namespace RoleBinding. Referensi semacam ini -memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klaster kamu, lalu menggunakannya kembali di dalam +memungkinkan kamu menentukan sekumpulan Role yang umum di seluruh klastermu, lalu menggunakannya kembali di dalam beberapa Namespace. Sebagai contoh, meskipun RoleBinding berikut merujuk ke ClusterRole, -"dave" (subjek, peka huruf besar-kecil) hanya akan dapat membaca Secret di dalam Namespace "development", -karena Namespace RoleBinding (di dalam metadata-nya) adalah "development". +"dave" (subjek, peka kapital) hanya akan dapat membaca Secret di dalam Namespace "development", +karena Namespace RoleBinding (di dalam metadatanya) adalah "development". ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# role binding memungkinkan "dave" untuk membaca Secret di Namespace "development". +# RoleBinding memungkinkan "dave" untuk membaca Secret di Namespace "development". # Kamu sudah harus memiliki ClusterRole bernama "secret-reader". kind: RoleBinding metadata: name: read-secrets # - # Namespace dari RoleBinding menentukan dimana izin akan diberikan. + # Namespace dari RoleBinding menentukan di mana izin akan diberikan. # Ini hanya memberikan izin di dalam Namespace "development". namespace: development subjects: @@ -182,37 +183,37 @@ membaca Secret di berbagai Namespace. ```yaml apiVersion: rbac.authorization.k8s.io/v1 -# Cluster role binding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace. +# ClusterRoleBinding ini memungkinkan siapapun di dalam kelompok "manager" untuk membaca Secret di berbagai Namespace. kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group - name: manager # Nama peka huruf besar-kecil + name: manager # Nama peka kapital apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io ``` -Setelah kamu membuat sebuat ikatan, kamu tidak dapat mengganti Role atau ClusterRole dirujuk. -Jika kamu mencoba mengganti sebuah ikatan `roleRef`, kamu mendapatkan kesalahan validasi. Jika kamu -tidak ingin mengganti `roleRef` untuk sebuah ikatan, kamu harus menghapus objek ikatan tersebut dan membuat +Setelah kamu membuat ClusterRoleBinding, kamu tidak dapat mengganti Role atau ClusterRole yang dirujuk. +Jika kamu mencoba mengganti `roleRef` dari sebuah ClusterRoleBinding, kamu akan mendapatkan galat validasi. Jika kamu +tidak ingin mengganti `roleRef` untuk sebuah ClusterRoleBinding, kamu harus menghapus objek ClusterRoleBinding tersebut dan membuat sebuah pengganti. Ada dua alasan untuk pembatasan tersebut: -1. Membuat `roleRef` tidak dapat diubah memungkinkan seseorang untuk melakukan `update` pada objek ikatan yang ada, -sehingga mereka dapat mengelola daftar subyek, tanpa bisa berubah -Role yang diberikan kepada subyek tersebut. +1. Membuat `roleRef` menjadi tidak dapat diubah (_immutable_) memungkinkan pemberian izin `update` kepada seseorang pada objek ClusterRoleBinding yang ada, +sehingga mereka dapat mengelola daftar subjek, tanpa bisa berubah +Role yang diberikan kepada subjek tersebut. -1. Ikatan pada Role yang berbeda adalah ikatan yang berbeda secara fundamental. -Mengharuskan sebuah ikatan untuk dihapus/diciptakan kembali untuk dalam upaya mengubah `roleRef` akan -memastikan daftar lengkap subyek dalam ikatan akan diberikan diberikan -Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada roleRef -tanpa memverifikasi semua subyek yang seharusnya diberikan izin pada Role baru). +2. ClusterRoleBinding dengan Role yang berbeda adalah ClusterRoleBinding yang berbeda secara fundamental. +Mengharuskan sebuah ClusterRoleBinding untuk dihapus/diciptakan kembali untuk mengubah `roleRef` akan +memastikan daftar lengkap subjek dalam ClusterRoleBinding akan diberikan +Role baru (sebagai langkah untuk mencegah modifikasi secara tidak sengaja hanya pada `roleRef` +tanpa memastikan semua subjek yang seharusnya diberikan izin pada Role baru). -Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbaharui berkas manifes yang mengandung objek RBAC, +Utilitas baris perintah `kubectl auth reconcile` membuat atau memperbarui berkas manifes yang mengandung objek RBAC, dan menangani penghapusan dan pembuatan objek ikatan jika dibutuhkan untuk mengganti Role yang dirujuk. Lihat [penggunaan perintah dan contoh](#kubectl-auth-reconcile) untuk informasi tambahan. @@ -222,7 +223,7 @@ Pada API Kubernetes, sebagian besar sumber daya diwakili dan diakses menggunakan nama objek, seperti `pods` untuk Pod. RBAC mengacu pada sumber daya yang menggunakan nama yang persis sama dengan yang muncul di URL untuk berbagai _endpoint_ API yang relevan. Beberapa Kubernetes APIs melibatkan -_subresource_, seperti catatan untuk Pod. Permintaan untuk catatan Pod terlihat seperti: +_subresource_, seperti log untuk Pod. Permintaan untuk log Pod terlihat seperti: ```http GET /api/v1/namespaces/{namespace}/pods/{name}/log @@ -248,7 +249,7 @@ rules: Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`. Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya. Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah -ConfigMap bernama `my-configmap`: +{{< glossary_tooltip term_id="ConfigMap" >}} bernama `my-configmap`: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -268,18 +269,18 @@ rules: {{< note >}} Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`, -Keterbatasan ini dikarenakan nama objek yang tidak dikenal pada waktu otorisasi. +keterbatasan ini dikarenakan nama objek tidak diketahui pada waktu otorisasi. {{< /note >}} -### Agregat ClusterRole +### ClusterRole gabungan Kamu dapat mengumpulkan beberapa ClusterRole menjadi satu ClusterRole gabungan. -_Controller_, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole -dengan `aggregationRule`. `AggregationRule` mendefinisikan label -Selector yang digunakan oleh _Controller_ untuk mencocokkan objek ClusterRole lain +Pengontrol, yang berjalan sebagai bagian dari _control plane_ klaster, mengamati objek ClusterRole +dengan `aggregationRule`. `AggregationRule` mendefinisikan +{{< glossary_tooltip text="Selector" term_id="selector" >}} label yang digunakan oleh pengontrol untuk mencocokkan objek ClusterRole lain yang harus digabungkan ke dalam `rules`. -Berikut adalah contoh ClusterRole agregat: +Berikut adalah contoh ClusterRole gabungan: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -290,12 +291,12 @@ aggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-monitoring: "true" -rules: [] # _Control plane_ secara otomatis mengisi rules +rules: [] # Control plane secara otomatis mengisi rules ``` -Jika kamu membuat ClusterRole baru yang cocok dengan _selector_ label dari ClusterRole agregat yang ada, -perubahan itu memicu penambahan aturan baru ke dalam ClusterRole agregat. -Berikut adalah contoh yang menambahkan aturan ke "monitoring" ClusterRole, dengan membuat sebuah +Jika kamu membuat ClusterRole baru yang cocok dengan label Selector dari ClusterRole gabungan yang ada, +maka perubahan itu akan memicu penambahan aturan baru ke dalam ClusterRole gabungan. +Berikut adalah contoh yang menambahkan aturan ke ClusterRole "monitoring", dengan membuat sebuah ClusterRole lain berlabel `rbac.example.com/aggregate-to-monitoring: true`. ```yaml @@ -313,12 +314,12 @@ rules: verbs: ["get", "list", "watch"] ``` -[Role bawaan pengguna](#role-dan-role-binding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, -sebagai administrator klaster, menambahkan aturan untuk sumber daya kustom, seperti yang dilayani oleh CustomResourceDefinition -atau _aggregated_ server API, untuk memperluas Role bawaan. +[Role bawaan pengguna](#role-dan-rolebinding-bawaan) menggunakan agregasi ClusterRole. Ini memungkinkan kamu, +sebagai administrator klaster, menambahkan aturan untuk sumber daya ubah suai, seperti yang dilayani oleh {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} +atau server API gabungan, untuk memperluas Role bawaan. -Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya kustom -bernama CronTab, sedangkan Role "view" hanya dapat melakukan tindakan membaca sumber daya CronTab. +Sebagai contoh: ClusterRole berikut mengizinkan Role bawaan "admin" dan "edit" mengelola sumber daya ubah suai +bernama CronTab, sedangkan Role "view" hanya dapat membaca sumber daya CronTab. Kamu dapat mengasumsikan bahwa objek CronTab dinamai `"crontab"` dalam URL yang terlihat oleh server API. ```yaml @@ -350,10 +351,10 @@ rules: #### Contoh Role -Contoh berikut adalah potongan dari objek Role atau ClusterRole, yang hanya menampilkan +Contoh berikut adalah potongan dari objek Role atau ClusterRole yang hanya menampilkan bagian `rules`. -Mengizinkan pembacaan sumber daya `"pods`` pada kumpulan API inti: +Mengizinkan pembacaan sumber daya `"pods"` pada {{< glossary_tooltip text="grup API" term_id="api-group" >}} inti: ```yaml rules: @@ -366,7 +367,7 @@ rules: ``` Mengizinkan pembacaan/penulisan Deployment (pada tingkat HTTP: objek dengan `"deployments"` -di bagian sumber daya dari URL) pada masing-masing kumpulan API `"extensions"` dan `"apps"`: +di bagian sumber daya dari URL) pada masing-masing grup API `"extensions"` dan `"apps"`: ```yaml rules: @@ -378,8 +379,8 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -Mengizinkan pembacaan pada Pods pada kumpulan API inti, dan juga serta pembacaan atau penulisan Job -di kumpulan API `"batch"` atau `"extensions"`: +Mengizinkan pembacaan pada Pods pada grup API inti, dan juga serta pembacaan atau penulisan Job +di grup API `"batch"` atau `"extensions"`: ```yaml rules: @@ -397,8 +398,8 @@ rules: verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` -Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan -RoleBinding untuk membatasi pada sebuah ConfigMap di sebuah Namespace): +Mengizinkan pembacaan ConfigMap bernama "my-config" (harus terikat dengan suatu +RoleBinding untuk membatasi ke satu ConfigMap di satu Namespace): ```yaml rules: @@ -411,7 +412,7 @@ rules: verbs: ["get"] ``` -Mengizinkan pembacaan sumber daya `"nodes"` pada kumpulan API inti (karena sebuah node +Mengizinkan pembacaan sumber daya `"nodes"` pada grup API inti (karena sebuah node ada pada lingkup-klaster, ini harus berupa ClusterRole yang terikat dengan ClusterRoleBinding agar efektif): @@ -434,33 +435,33 @@ rules: verbs: ["get", "post"] ``` -### Mengacu Pada Subjek +### Mengacu pada subjek RoleBinding atau ClusterRoleBinding mengikat sebuah Role ke subjek. -Subjek dapat berupa kelompok, pengguna atau ServiceAccount. +Subjek dapat berupa kelompok, pengguna atau {{< glossary_tooltip text="ServiceAccounts" term_id="service-account" >}}. -Kubernetes merepresentasikan _username_ sebagai string. +Kubernetes merepresentasikan _username_ sebagai _string_. Ini bisa berupa: nama sederhana, seperti "alice"; email, seperti "bob@example.com"; -atau ID pengguna numerik yang direpresentasikan sebagai string. Terserah kamu sebagai administrator klaster -untuk mengkonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/) +atau ID pengguna numerik yang direpresentasikan sebagai _string_. Terserah kamu sebagai administrator klaster +untuk mengonfigurasi [modul otentikasi](/docs/reference/access-authn-authz/authentication/) sehingga otentikasi menghasilkan _username_ dalam format yang kamu inginkan. {{< caution >}} Awalan `system:` direservasi untuk sistem Kubernetes, jadi kamu harus memastikan bahwa kamu tidak memiliki pengguna atau grup dengan nama yang dimulai dengan `system:` secara tidak sengaja. -Selain awalan khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun +Selain prefiks khusus ini, sistem otorisasi RBAC tidak memerlukan format apa pun untuk nama pengguna. {{< /caution >}} Di Kubernetes, modul otentikasi menyediakan informasi grup. Grup, seperti halnya pengguna, direpresentasikan sebagai string, dan string tersebut tidak memiliki format tertentu, -selain awalan `system:` yang sudah direservasi. +selain prefiks `system:` yang sudah direservasi. [ServiceAccount](/id/docs/tasks/configure-pod-container/configure-service-account/) memiliki nama yang diawali dengan `system:serviceaccount:`, dan menjadi milik grup yang diawali dengan nama `system:serviceaccounts:`. {{< note >}} -- `system:serviceaccount:` (tunggal) adalah awalan untuk ServiceAccount _username_. -- `system:serviceaccounts:` (jamak) adalah awalan untuk ServiceAccount grup. +- `system:serviceaccount:` (tunggal) adalah prefiks untuk _username_ ServiceAccount. +- `system:serviceaccounts:` (jamak) adalah prefiks untuk grup ServiceAccount. {{< /note >}} #### Contoh RoleBinding {#role-binding-examples} @@ -543,33 +544,33 @@ subjects: apiGroup: rbac.authorization.k8s.io ``` -## Role dan RoleBinding Bawaan +## Role dan RoleBinding bawaan API membuat satu set objek ClusterRole dan ClusterRoleBinding bawaan. -Sebagian besar dari objek berawalan `system:`, menunjukkan bahwa sumber daya tersebut -secara langsung dikelolah oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan +Sebagian besar dari objek dengan prefiks `system:` menunjukkan bahwa sumber daya tersebut +secara langsung dikelola oleh _control plane_ klaster. Seluruh ClusterRole dan ClusterRoleBinding dilabeli dengan `kubernetes.io/bootstrapping=rbac-defaults`. {{< caution >}} Berhati-hatilah saat memodifikasi CLusterRole dan ClusterRoleBinding dengan nama yang -memiliki awalan `system:`. -Modifikasi sumber daya ini dapat mengakibatkan klaster yang malfungsi. +memiliki prefiks `system:`. +Modifikasi sumber daya ini dapat mengakibatkan malfungsi klaster. {{< /caution >}} -### Rekonsiliasi Otomatis +### Rekonsiliasi otomatis -Pada setiap _start-up-_, server API memperbaharui ClusterRole bawaan dengan berbagai izin yang hilang, -dan memperbaharui ikatan ClusterRole bawaan dengan subjek yang hilang. +Pada setiap penyalaan (_start-up_), server API memperbarui ClusterRole bawaan dengan berbagai izin yang hilang, +dan memperbarui ClusterRoleBinding bawaan dengan subjek yang hilang. Ini memungkinkan klaster untuk memperbaiki modifikasi yang tidak disengaja, dan membantu menjaga Role dan RoleBinding selalu terkini karena izin dan subjek berubah pada rilis terbaru Kubernetes. -Untuk menon-aktifkan rekonsiliasi ini, setel anotasi `rbac.authorization.kubernetes.io/autoupdate` +Untuk menonaktifkan rekonsiliasi ini, atur anotasi `rbac.authorization.kubernetes.io/autoupdate` pada ClusterRole bawaan atau RoleBinding bawaan menjadi `false`. -Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan klaster tidak berfungsi. +Ingat bahwa hilangnya izin dan subjek bawaan dapat mengakibatkan malfungsi klaster. -Rekonsiliasi otomatis diaktifkan secara bawaan jika otorizer RBAC aktif. +Rekonsiliasi otomatis diaktifkan secara bawaan jika pemberi otorisasi RBAC aktif. -### Role API discovery {#discovery-roles} +### Role diskoveri API {#discovery-roles} RoleBinding bawaan memberi otorisasi kepada pengguna yang tidak terotentikasi untuk membaca informasi API yang dianggap aman untuk diakses publik (termasuk CustomResourceDefinitions). Untuk menonaktifkan akses anonim, tambahkan `--anonymous-auth=false` ke konfigurasi server API. @@ -581,13 +582,13 @@ kubectl get clusterroles system:discovery -o yaml ``` {{< note >}} -Jika kamu mengubah ClusterRole tersebut, perubahan kamu akan ditimpa pada penyalaan ulang server API melalui +Jika kamu mengubah ClusterRole tersebut, maka perubahanmu akan ditimpa pada penyalaan ulang server API melalui [rekonsiliasi-otomatis](#auto-reconciliation). Untuk menghindari penulisan ulang tersebut, hindari mengubah Role secara manual, atau nonaktifkan rekonsiliasi otomatis {{< /note >}} - + @@ -596,29 +597,29 @@ atau nonaktifkan rekonsiliasi otomatis - - + + - - + + - +
Kubernetes RBAC API discovery rolesRole diskoveri API Kubernetes RBAC
ClusterRole Bawaan
system:basic-usersystem:authenticated groupMengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan.Grup system:authenticatedMengizinkan pengguna hanya dengan akses baca untuk mengakses informasi dasar tentang diri mereka sendiri. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan.
system:discoverysystem:authenticated groupMengizinkan akses baca pada berbagai _API discovery endpoint_ yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan.Grup system:authenticatedMengizinkan akses baca pada berbagai endpoint diskoveri API yang dibutuhkan untuk menemukan dan melakukan negosiasi pada tingkat API. Sebelum v1.14, Role ini juga terikat pada system:unauthenticated secara bawaan.
system:public-info-viewersystem:authenticated and system:unauthenticated groupsGrup system:authenticated dan system:unauthenticated Mengizinkan akses baca pada informasi yang tidak sensitif tentang klaster. Diperkenalkan pada Kubernetes v1.14.
-### Role Pengguna +### Role pengguna Beberapa ClusterRole bawaan tidak diawali dengan `system:`. Ini dimaksudkan untuk Role pengguna. -Ini termasuk Role super-user (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan +Ini termasuk Role _super-user_ (`cluster-admin`), Role yang dimaksudkan untuk diberikan akses seluruh klaster dengan menggunakan ClusterRoleBinding, dan Role yang dimaksudkan untuk diberikan pada Namespace tertentu dengan menggunakan RoleBinding (`admin`, `edit`, `view`). -ClusterRole menggunakan [aggregasi ClusterRole](#aggregated-clusterroles) untuk mengizinkan admin untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buat sebuah CLusterRole +ClusterRole menggunakan [ClusterRole gabungan](#clusterrole-gabungan) untuk mengizinkan administrator untuk memasukan peraturan untuk sumber daya khusus pada ClusterRole ini. Untuk menambahkan aturan kepada Role `admin`, `edit`, atau `view`, buatlah sebuah CLusterRole dengan satu atau lebih label berikut: ```yaml @@ -638,149 +639,156 @@ metadata: cluster-admin -system:masters group -Mengizinkan akses super-user access untuk melakukan berbagai aksi pada berbagai sumber daya. -Ketika digunakan pada ClusterRoleBinding, ini memberikan kendali penuh terhadap seluruh sumber daya pada klaster dan seluruh Namespace. -Ketika digunakan pada RoleBinding, ini memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri. +Grup system:masters +Mengizinkan akses super-user untuk melakukan berbagai aksi pada berbagai sumber daya. +Ketika digunakan pada ClusterRoleBinding, Role ini akan memberikan kendali penuh terhadap semua sumber daya pada klaster dan seluruh Namespace. +Ketika digunakan pada RoleBinding, Role ini akan memberikan kendali penuh terhadap setiap sumber daya pada Namespace RoleBinding, termasuk Namespace itu sendiri. admin -None -mengizinkan akses admin, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan RoleBinding. +Tidak ada +mengizinkan akses administrator, yang dimaksudkan untuk diberikan dalam sebuah Namespace menggunakan RoleBinding. Jika digunakan dalam RoleBinding, ini memungkikan akses baca/tulis ke sebagian besar sumber daya di sebuah Namespace, termasuk kemampuan untuk membuat Role dan RoleBinding dalam Namespace. Role ini tidak memungkinkan akses tulis pada kuota sumber daya atau ke Namespace itu sendiri. edit -None +Tidak ada Mengizinkan akses baca/tulis pada seluruh objek dalam Namespace. -Role ini tidak memungkinkan untuk melihat dan merubah Role dan RoleBinding. +Role ini tidak memungkinkan untuk melihat dan mengubah Role dan RoleBinding. Namun, Role ini memungkinkan untuk mengakses Secret dan menjalankan Pod seperti ServiceAccount dalam Namespace, sehingga dapat digunakan untuk mendapatkan tingkat akses API dari setiap ServiceAccount di Namespace. view -None +Tidak ada Mengizinkan akses baca untuk melihat hampir seluruh objek dalam Namespace. Ini tidak memungkinkan untuk melihat Role dan RoleBinding. Role ini tidak memungkikan melihat Secret, karena pembacaan konten Secret memungkinkan akses ke kredensial ServiceAccount dalam Namespace, yang akan memungkinkan akses API sebagai -ServiceAccount apapun di Namespace (bentuk eskalasi hak istimewa). +ServiceAccount apapun di Namespace (bentuk eskalasi privilese). -### Core component roles +### Role komponen inti - + + - - - + + + + + - - + + - - + + - - + + - - + - - + + +
Default ClusterRoleDefault ClusterRoleBindingDescriptionClusterRole BawaanClusterRoleBinding BawaanDeskripsi
system:kube-schedulersystem:kube-scheduler userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} component.Pengguna system:kube-schedulerMengizinkan akses ke sumber daya yang dibutuhkan oleh komponen {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}}.
system:volume-schedulersystem:kube-scheduler userAllows access to the volume resources required by the kube-scheduler component.Pengguna system:kube-schedulerMengizinkan akses ke sumber daya volume yang dibutuhkan oleh komponen kube-scheduler.
system:kube-controller-managersystem:kube-controller-manager userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} component. -The permissions required by individual controllers are detailed in the controller roles.Pengguna system:kube-controller-managerMengizinkan akses ke sumber daya yang dibutuhkan oleh komponen {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}. +Izin yang diperlukan oleh masing-masing pengontrol dirincikan di Role pengontrol.
system:nodeNoneAllows access to resources required by the kubelet, including read access to all secrets, and write access to all pod status objects. +Tidak adaMengizinkan akses ke sumber daya yang dibutuhkan oleh kubelet, termasuk akses baca ke semua Secret, dan akses rulis ke semua objek status Pod. -You should use the Node authorizer and NodeRestriction admission plugin instead of the system:node role, and allow granting API access to kubelets based on the Pods scheduled to run on them. +Kamu dapat menggunakan pemberi otorisasi Node dan pugasan admisi NodeRestriction daripada Role system:node, dan mengizinkan pemberian akses API ke kubelet berdasarkan Pod yang dijadwalkan untuk berjalan di atasnya. -The system:node role only exists for compatibility with Kubernetes clusters upgraded from versions prior to v1.8. +Role system:node hanya ada untuk kompatibilitas dengan klaster Kubernetes yang ditingkatkan dari versi sebelum v1.8.
system:node-proxiersystem:kube-proxy userAllows access to the resources required by the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} component.Pengguna system:kube-proxyMengizinkan akses ke sumber daya yang dibutuhkan oleh komponen {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}.
-### Other component roles +### Role komponen lainnya - + + - - - + + + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + +
Default ClusterRoleDefault ClusterRoleBindingDescriptionClusterRole BawaanClusterRoleBinding BawaanDeskripsi
system:auth-delegatorNoneAllows delegated authentication and authorization checks. -This is commonly used by add-on API servers for unified authentication and authorization.Tidak adaMengizinkan pemeriksaan otentikasi dan otorisasi yang didelegasikan. +Hal ini umumnya digunakan oleh pugasan server API untuk otentikasi dan otorisasi terpadu.
system:heapsterNoneRole for the Heapster component (deprecated).Tidak adaRole untuk komponen Heapster (usang).
system:kube-aggregatorNoneRole for the kube-aggregator component.Tidak adaRole untuk komponen kube-aggregator.
system:kube-dnskube-dns service account in the kube-system namespaceRole for the kube-dns component.ServiceAccount kube-dns dalam Namespace kube-systemRole untuk komponen kube-dns.
system:kubelet-api-adminNoneAllows full access to the kubelet API.Tidak adaMengizinkan akses penuh ke API kubelet.
system:node-bootstrapperNoneAllows access to the resources required to perform -kubelet TLS bootstrapping.Tidak adaMengizinkan akses ke sumber daya yang dibutuhkan untuk melakukan bootstrapping TLS kubelet.
system:node-problem-detectorNoneRole for the node-problem-detector component.Tidak adaRole untuk komponen node-problem-detector.
system:persistent-volume-provisionerNoneAllows access to the resources required by most dynamic volume provisioners.Tidak adaMengizinkan akses ke sumber daya yang dibutuhkan oleh kebanyakan penyedia volume dinamis.
-### Roles for built-in controllers {#controller-roles} +### Role untuk pengontrol bawaan {#controller-roles} -The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs -{{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes -control plane. -When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller -using a separate service account. -Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. -If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops -using its own credential, which must be granted all the relevant roles. -These roles include: +{{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +pada Kubernetes menjalankan {{< glossary_tooltip term_id="controller" text="pengontrol" >}} +yang merupakan bawaan dari _control plane_ Kubernetes. Ketika dijalankan dengan +`--use-service-account-credentials`, kube-controller-manager memulai setiap pengontrol +menggunakan ServiceAccount yang terpisah. Role yang sesuai tersedia untuk setiap +pengontrol bawaan, dengan prefiks `system:controller:`. Jika manajer pengontrol tidak +dimulai dengan `--use-service-account-credentials`, maka manajer pengontrol akan menjalankan +semua kontrol tertutup (_control loop_) menggunakan kredensialnya sendiri, yang harus +diberikan semua Role yang relevan. Role yang dimaksud termasuk: * `system:controller:attachdetach-controller` * `system:controller:certificate-controller` @@ -810,40 +818,48 @@ These roles include: * `system:controller:statefulset-controller` * `system:controller:ttl-controller` -## Privilege escalation prevention and bootstrapping +## Pencegahan eskalasi privilese dan _bootstrapping_ -The RBAC API prevents users from escalating privileges by editing roles or role bindings. -Because this is enforced at the API level, it applies even when the RBAC authorizer is not in use. +API RBAC mencegah pengguna dari mengeskalasikan privilese dengan mengubah Role atau RoleBinding. +Karena hal ini diberlakukan pada level API, maka hal ini berlaku bahkan ketika pemberi otorisasi +RBAC tidak digunakan. -### Restrictions on role creation or update +### Pembatasan pada pembuatan dan pembaruan Role -You can only create/update a role if at least one of the following things is true: +Kamu hanya bisa membuat/memperbaru suatu Role jika setidaknya satu dari beberapa +hal di bawah ini terpenuhi: -1. You already have all the permissions contained in the role, at the same scope as the object being modified -(cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). -2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. +1. Kamu telah mempunyai semua izin yang termuat dalam Role tersebut, pada lingkup yang sama +dengan objek yang diubah +(di seluruh klaster untuk sebuah ClusterRole, di dalam Namespace yang sama atau keseluruhan +klaster untuk sebuah Role). +2. Kamu diberikan izin eksplisit untuk melakukan `escalate` pada sumber daya `roles` atau +`clusterroles` di dalam grup API `rbac.authorization.k8s.io`. -For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRole -containing that permission. To allow a user to create/update roles: +Sebagai contoh, jika `user-1` tidak memiliki kemampuan untuk mendaftar Secret di seluruh klaster, +maka `user-1` tidak akan bisa membuat suatu ClusterRole yang memuat izin tersebut. Agar pengguna +bisa membuat/memperbaru Role: -1. Grant them a role that allows them to create/update Role or ClusterRole objects, as desired. -2. Grant them permission to include specific permissions in the roles they create/update: - * implicitly, by giving them those permissions (if they attempt to create or modify a Role or ClusterRole with permissions they themselves have not been granted, the API request will be forbidden) - * or explicitly allow specifying any permission in a `Role` or `ClusterRole` by giving them permission to perform the `escalate` verb on `roles` or `clusterroles` resources in the `rbac.authorization.k8s.io` API group +1. Berikan sebuah Role yang memungkinkan mereka untuk membuat/memperbarui objek Role atau CLusterRole, sesuai keinginan. +2. Berikan mereka izin untuk menyertakan izin tertentu dalam Role yang mereka buat/perbarui: + * secara implisit, dengan memberikan mereka izin tersebut (jika mereka mencoba untuk membuat atau mengubah sebuah Role atau ClusterRole dengan izin yang tidak mereka miliki, permintaan API akan dilarang) + * atau secara eksplisit mengizinkan penentuan izin apa pun dalam sebuah `Role` atau `ClusterRole` dengan memberikan mereka izin untuk melakukan `escalate` pada sumber daya `roles` atau `clusterroles` di dalam grup API `rbac.authorization.k8s.io` -### Restrictions on role binding creation or update +### Pembatasan pada pembuatan dan pembaruan RoleBinding -You can only create/update a role binding if you already have all the permissions contained in the referenced role -(at the same scope as the role binding) *or* if you have been authorized to perform the `bind` verb on the referenced role. -For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding -to a role that grants that permission. To allow a user to create/update role bindings: +Kamu hanya bisa membuat/memperbarui suatu RoleBinding jika kamu telah mempunyai semua izin yang +terdapat pada Role yang diacu (di dalam lingkup yang sama dengan RoleBinding) *atau* jika +kamu telah terotorisasi untuk melakukan `bind` pada role yang diacu. +Sebagai contoh, jika `user-1` tidak mempunyai kemampuan untuk mendaftar Secret di seluruh klaster, +maka `user-1` tidak akan bisa membuat sebuah ClusterRoleBinding dengan Role yang memberikan +izin tersebut. Agar pengguna bisa membuat/memperbarui RoleBinding: -1. Grant them a role that allows them to create/update RoleBinding or ClusterRoleBinding objects, as desired. -2. Grant them permissions needed to bind a particular role: - * implicitly, by giving them the permissions contained in the role. - * explicitly, by giving them permission to perform the `bind` verb on the particular Role (or ClusterRole). +1. Berikan sebuah Role yang mengizinkan mereka untuk membuat/memperbarui objek RoleBinding atau ClusterRoleBinding, sesuai keinginan. +2. Berikan mereka izin yang dibutuhkan untuk RoleBinding tertentu: + * secara implisit, dengan memberikan mereka izin yang yang termuat pada Role yang dimaksud + * secara eksplisit, dengan memberikan mereka izin untuk melakukan `bind` pada Role (atau ClusterRole) tertentu -For example, this ClusterRole and RoleBinding would allow `user-1` to grant other users the `admin`, `edit`, and `view` roles in the namespace `user-1-namespace`: +Sebagai contoh, ClusterRole dan RoleBinding berikut akan memungkinkan `user-1` untuk memberikan Role `admin`, `edit`, dan `view` kepada pengguna lain di dalam Namespace `user-1-namespace`: ```yaml apiVersion: rbac.authorization.k8s.io/v1 @@ -874,43 +890,44 @@ subjects: name: user-1 ``` -When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. -To bootstrap initial roles and role bindings: +Ketika melakukan _bootstrapping_ Role dan RoleBinding yang pertama, pengguna awal perlu memberikan +izin yang belum mereka miliki. +Untuk melakukan _bootstrapping_ Role dan RoleBinding awal: -* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. -* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. +* Gunakan kredensial dengan grup "system:masters" yang terikat ke Role _super-user_ "cluster-admin" oleh RoleBinding bawaan. +* Jika server API dijalankan dengan porta tidak aman diaktifkan (`--insecure-port`), kamu juga bisa membuat panggilan API via porta tersebut, yang tidak memberlakukan otentikasi atau otorisasi. -## Command-line utilities +## Utilitas baris perintah ### `kubectl create role` -Creates a Role object defining permissions within a single namespace. Examples: +Membuat sebuah objek Role yang mendefinisikan izin di dalam sebuah Namespace. Contoh: -* Create a Role named "pod-reader" that allows users to perform `get`, `watch` and `list` on pods: +* Membuat sebuah Role bernama "pod-reader" yang memungkinkan pengguna untuk melakukan `get`, `watch` dan `list` pada Pod: ```shell kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods ``` -* Create a Role named "pod-reader" with resourceNames specified: +* Membuat sebuah Role bernama "pod-reader" dengan resourceNames yang ditentukan: ```shell kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a Role named "foo" with apiGroups specified: +* Membuat sebuah Role bernama "foo" dengan apiGroups yang ditentukan: ```shell kubectl create role foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a Role named "foo" with subresource permissions: +* Membuat sebuah Role bernama "foo" dengan izin sub-sumber daya: ```shell kubectl create role foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a Role named "my-component-lease-holder" with permissions to get/update a resource with a specific name: +* Membuat sebuah Role bernama "my-component-lease-holder" dengan izin untuk mendapatkan/memperbarui suatu sumber daya dengan nama tertentu: ```shell kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component @@ -918,39 +935,39 @@ Creates a Role object defining permissions within a single namespace. Examples: ### `kubectl create clusterrole` -Creates a ClusterRole. Examples: +Membuat sebuah ClusterRole. Contoh: -* Create a ClusterRole named "pod-reader" that allows user to perform `get`, `watch` and `list` on pods: +* Membuat sebuah ClusterRole bernama "pod-reader" yang memungkinkan pengguna untuk merlakukan `get`, `watch` dan `list` pada Pod: ```shell kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods ``` -* Create a ClusterRole named "pod-reader" with resourceNames specified: +* Membuat sebuah ClusterRole bernama "pod-reader" dengan recourceNames yang ditentukan: ```shell kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* Create a ClusterRole named "foo" with apiGroups specified: +* Membuat sebuah ClusterRole bernama "foo" dengan apiGroups yang ditentukan: ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps ``` -* Create a ClusterRole named "foo" with subresource permissions: +* Membuat sebuah ClusterRole bernama "foo" dengan izin sub-sumber daya: ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status ``` -* Create a ClusterRole named "foo" with nonResourceURL specified: +* Membuat sebuah ClusterRole bernama "foo" dengan nonResourceURL yang ditentukan: ```shell kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* ``` -* Create a ClusterRole named "monitoring" with an aggregationRule specified: +* Membuat sebuah ClusterRole bernama "monitoring" dengan aggregationRule yang ditentukan: ```shell kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" @@ -958,21 +975,21 @@ Creates a ClusterRole. Examples: ### `kubectl create rolebinding` -Grants a Role or ClusterRole within a specific namespace. Examples: +Memberikan sebuah Role atau ClusterRole di dalam Namespace tertentu. Contoh: -* Within the namespace "acme", grant the permissions in the "admin" ClusterRole to a user named "bob": +* Di dalam Namespace "acme", memberikan izin dalam ClusterRole "admin" kepada pengguna bernama "bob": ```shell kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the "view" ClusterRole to the service account in the namespace "acme" named "myapp": +* Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "acme" yang bernama "myapp": ```shell kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme ``` -* Within the namespace "acme", grant the permissions in the "view" ClusterRole to a service account in the namespace "myappnamespace" named "myapp": +* Di dalam Namespace "acme", memberikan izin dalam ClusterRole "view" ke ServiceAccount di dalam Namespace "myappnamespace" yang bernama "myapp": ```shell kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme @@ -980,21 +997,21 @@ Grants a Role or ClusterRole within a specific namespace. Examples: ### `kubectl create clusterrolebinding` -Grants a ClusterRole across the entire cluster (all namespaces). Examples: +Memberikan sebuah ClusterRole di seluruh klaster (semua Namespace). Contoh: -* Across the entire cluster, grant the permissions in the "cluster-admin" ClusterRole to a user named "root": +* Di seluruh klaster, memberikan izin dalam ClusterRole "cluster-admin" kepada pengguna bernama "root": ```shell kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root ``` -* Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": +* Di seluruh klaster, memberikan izin dalam ClusterRole "system:node-proxier" kepada user bernama "system:kube-proxy": ```shell kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy ``` -* Across the entire cluster, grant the permissions in the "view" ClusterRole to a service account named "myapp" in the namespace "acme": +* Di seluruh klaster, memberikan izin dalam ClusterRole "view" ke ServiceAccount bernama "myapp" di dalam Namespace "acme": ```shell kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp @@ -1002,55 +1019,58 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples: ### `kubectl auth reconcile` {#kubectl-auth-reconcile} -Creates or updates `rbac.authorization.k8s.io/v1` API objects from a manifest file. +Membuat atau memperbarui objek API `rbac.authorization.k8s.io/v1` dari suatu berkas manifes. -Missing objects are created, and the containing namespace is created for namespaced objects, if required. +Objek yang hilang dibuat, dan Namespace dibuat untuk objek dengan Namespace jika diperlukan. -Existing roles are updated to include the permissions in the input objects, -and remove extra permissions if `--remove-extra-permissions` is specified. +Role yang sudah ada diperbarui untuk menyertakan izin pada objek masukan, +dan menghilangkan izin tambahan jika `--remove-extra-permissions` ditetapkan. -Existing bindings are updated to include the subjects in the input objects, -and remove extra subjects if `--remove-extra-subjects` is specified. +RoleBinding yang sudah ada diperbarui untuk menyertakan subjek pada objek masukan, +dan menghapus subjek tambahan jika `--remove-extra-subjects` ditetapkan. -Examples: +Contoh: -* Test applying a manifest file of RBAC objects, displaying changes that would be made: +* Mencoba menerapkan sebuah berkas manifes dari objek RBAC, menampilkan perubahan yang akan dibuat: ``` kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client ``` -* Apply a manifest file of RBAC objects, preserving any extra permissions (in roles) and any extra subjects (in bindings): +* Menerapkan sebuah berkas manifes dari objek RBAC, mempertahankan izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding): ```shell kubectl auth reconcile -f my-rbac-rules.yaml ``` -* Apply a manifest file of RBAC objects, removing any extra permissions (in roles) and any extra subjects (in bindings): +* Menerapkan sebuah berkas manifes dari objek RBAC, menghapus izin tambahan (dalam Role) dan subjek tambahan (dalam RoleBinding): ```shell kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions ``` -## ServiceAccount permissions {#service-account-permissions} +## Izin ServiceAccount {#service-account-permissions} -Default RBAC policies grant scoped permissions to control-plane components, nodes, -and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace -(beyond discovery permissions given to all authenticated users). +Kebijakan RBAC bawaan memberikan izin terbatas ke komponen _control plane_, Node, dan pengontrol, +akan tetapi *tidak memberikan izin* ke ServiceAccount di luar Namespace `kube-system` +(di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi). -This allows you to grant particular roles to particular ServiceAccounts as needed. -Fine-grained role bindings provide greater security, but require more effort to administrate. -Broader grants can give unnecessary (and potentially escalating) API access to -ServiceAccounts, but are easier to administrate. +Hal ini memungkinkan kamu untuk memberika Role tertentu ke ServiceAccount tertentu sesuai +kebutuhan. RoleBinding yang sangat detail memberikan keamanan yang lebih baik, +akan tetapi membutuhkan lebih banyak usaha untuk pengaturannya. Pemberian izin +yang lebih luas dapat memberikan akses API yang tidak perlu (dan berpotensi tereskalasi) +ke ServiceAccount, akan tetapi pengaturannya lebih mudah. -In order from most secure to least secure, the approaches are: +Dalam urutan dari yang paling aman ke yang paling tidak aman, pendekatannya adalah: -1. Grant a role to an application-specific service account (best practice) +1. Memberikan sebuah Role ke ServiceAccount aplikasi tertentu (praktik terbaik) - This requires the application to specify a `serviceAccountName` in its pod spec, - and for the service account to be created (via the API, application manifest, `kubectl create serviceaccount`, etc.). + Hal ini membutuhkan aplikasi untuk menentukan sebuah `serviceAccountName` + di dalam spesifikasi Pod-nya, dan untuk ServiceAccount yang akan dibuat (via + API, manifes aplikasi, `kubectl create serviceaccount`, dan lain-lain). - For example, grant read-only permission within "my-namespace" to the "my-sa" service account: + Sebagai contoh, untuk memberikan izin hanya baca (_read-only_) di dalam "my-namespace" + ke ServiceAccount "my-sa": ```shell kubectl create rolebinding my-sa-view \ @@ -1059,16 +1079,18 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` -2. Grant a role to the "default" service account in a namespace +2. Memberikan sebuah Role ke ServiceAccount "default" di dalam suatu Namespace - If an application does not specify a `serviceAccountName`, it uses the "default" service account. + Jika sebuah aplikasi tidak menetapkan `serviceAccountName`, aplikasi + tersebut akan menggunakan ServiceAccount "default". {{< note >}} - Permissions given to the "default" service account are available to any pod - in the namespace that does not specify a `serviceAccountName`. + Izin yang diberikan ke ServiceAccount "default" tersedia ke Pod apa pun di dalam + Namespace yang tidak menetapkan `serviceAccountName`. {{< /note >}} - For example, grant read-only permission within "my-namespace" to the "default" service account: + Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke ServiceAccount + "default": ```shell kubectl create rolebinding default-view \ @@ -1077,14 +1099,14 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` - Many [add-ons](/id/docs/concepts/cluster-administration/addons/) run as the - "default" service account in the `kube-system` namespace. - To allow those add-ons to run with super-user access, grant cluster-admin - permissions to the "default" service account in the `kube-system` namespace. + Banyak [pugasan](/id/docs/concepts/cluster-administration/addons/) berjalan sebagai + ServiceAccount "default" di dalam Namespace `kube-system`. Untuk mengizinkan pugasan + tersebut berjalan dengan akses _super-user_, berikan izin `cluster-admin` kepada + ServiceAccount "default" di dalam Namespace `kube-system`. {{< caution >}} - Enabling this means the `kube-system` namespace contains Secrets - that grant super-user access to your cluster's API. + Mengaktifkan ini berarti Namespace `kube-system` memuat Secret yang + memberikan akses _super-user_ ke API klastermu. {{< /caution >}} ```shell @@ -1093,12 +1115,14 @@ In order from most secure to least secure, the approaches are: --serviceaccount=kube-system:default ``` -3. Grant a role to all service accounts in a namespace +3. Memberikan Role ke semua ServiceAccount dalam suatu Namespace - If you want all applications in a namespace to have a role, no matter what service account they use, - you can grant a role to the service account group for that namespace. + Jika kamu ingin semua aplikasi di dalam satu Namespace untuk memiliki Role, apa pun + ServiceAccount yang digunakan, maka kamu dapat memberikan Role ke grup ServiceAccount + untuk Namespace tersebut. - For example, grant read-only permission within "my-namespace" to all service accounts in that namespace: + Sebagai contoh, untuk memberikan izin hanya baca di dalam "my-namespace" ke semua + ServiceAccount di dalam Namespace tersebut: ```shell kubectl create rolebinding serviceaccounts-view \ @@ -1107,11 +1131,13 @@ In order from most secure to least secure, the approaches are: --namespace=my-namespace ``` -4. Grant a limited role to all service accounts cluster-wide (discouraged) +4. Memberikan Role terbatas ke semua ServiceAccount di seluruh klaster (tidak disarankan) + + Jika kamu tidak ingin untuk mengelola izin per Namespace, kamu bisa memberikan + Role yang berlaku di seluruh klaster kepada semua ServiceAccount. - If you don't want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts. - - For example, grant read-only permission across all namespaces to all service accounts in the cluster: + Sebagai contoh, untuk memberikan akses hanya baca di semua Namespace untuk + semua ServiceAccount yang ada di klaster: ```shell kubectl create clusterrolebinding serviceaccounts-view \ @@ -1119,14 +1145,15 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` -5. Grant super-user access to all service accounts cluster-wide (strongly discouraged) - - If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts. +5. Memberikan akses _super-user_ ke semua ServiceAccount di seluruh klaster (sangat tidak disarankan) + + Jika kamu tidak peduli untuk melakukan partisi terhadap izin sama sekali, maka kamu bisa + memberikan akses _super-user_ ke semua ServiceAccount. {{< warning >}} - This allows any application full access to your cluster, and also grants - any user with read access to Secrets (or the ability to create any pod) - full access to your cluster. + Hal ini akan memberikan akses penuh untuk aplikasi apapun ke klastermu, dan juga + memberikan pengguna manapun dengan akses baca ke Secret (atau kemampuan untuk membuat + Pod apa pun) akses penuh ke klastermu. {{< /warning >}} ```shell @@ -1135,50 +1162,55 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` -## Upgrading from ABAC +## Melakukan peningkatan dari ABAC -Clusters that originally ran older Kubernetes versions often used -permissive ABAC policies, including granting full API access to all -service accounts. +Klaster yang awalnya menjalankan versi Kubernetes lawas sering kali menggunakan +kebijakan ABAC yang permisif, termasuk memberikan akses API penuh ke semua +ServiceAccount. -Default RBAC policies grant scoped permissions to control-plane components, nodes, -and controllers, but grant *no permissions* to service accounts outside the `kube-system` namespace -(beyond discovery permissions given to all authenticated users). +Kebijakan RBAC bawaan memberikan izin yang terbatas ke komponen _control plane_, Node, +dan pengontrol, akan tetapi *tidak memberikan izin* ke ServiceAccount di luar Namespace +`kube-system` (di luar izin diskoveri yang diberikan kepada semua pengguna terotentikasi). -While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. -Here are two approaches for managing this transition: +Meskipun jauh lebih aman, hal ini dapat mengganggu beban kerja yang sudah ada yang +mengharapkan untuk menerima izin API secara otomatis. +Berikut adalah dua pendekatan untuk mengelola transisi ini: -### Parallel authorizers +### Pemberi otorisasi paralel -Run both the RBAC and ABAC authorizers, and specify a policy file that contains -the [legacy ABAC policy](/docs/reference/access-authn-authz/abac/#policy-file-format): +Jalankan pemberi otorisasi RBAC dan ABAC bersamaan, dan tentukan berkas kebijakan yang +memuat [kebijakan ABAC lama](/docs/reference/access-authn-authz/abac/#policy-file-format): ``` --authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -To explain that first command line option in detail: if earlier authorizers, such as Node, -deny a request, then the RBAC authorizer attempts to authorize the API request. If RBAC -also denies that API request, the ABAC authorizer is then run. This means that any request -allowed by *either* the RBAC or ABAC policies is allowed. +Untuk menjelaskan opsi baris perintah yang pertama secara detail: jika pemberi otorisasi +sebelumnya, seperti Node, menolak permintaan, maka pemberi otorisasi RBAC mencoba untuk +mengotorisasi permintaan API tersebut. Jika RBAC juga menolak permintaan API tersebut, +maka pemberi otorisasi ABAC akan dijalankan. Hal ini berarti permintaan apa pun yang +diizinkan oleh *salah satu* kebijakan RBAC atau ABAC akan diizinkan. -When the kube-apiserver is run with a log level of 5 or higher for the RBAC component -(`--vmodule=rbac*=5` or `--v=5`), you can see RBAC denials in the API server log -(prefixed with `RBAC`). -You can use that information to determine which roles need to be granted to which users, groups, or service accounts. +Ketika kube-apiserver dijalankan dengan level log 5 atau lebih tinggi untuk komponen +RBAC (`--vmodule=rbac*=5` atau `--v=5`), kamu dapat melihat penolakan RBAC di log +server API (dengan prefiks `RBAC`). Kamu dapat menggunakan informasi tersebut untuk +menentukan Role mana yang perlu diberikan ke pengguna, grup, atau ServiceAccount yang mana. -Once you have [granted roles to service accounts](#service-account-permissions) and workloads -are running with no RBAC denial messages in the server logs, you can remove the ABAC authorizer. +Jika kamu telah [memberikan Role ke ServiceAccount](#service-account-permissions) dan +beban kerja sedang berjalan tanpa pesan penolakan RBAC dalam log server, maka kamu +dapat menghapus pemberi otorisasi ABAC. -### Permissive RBAC permissions +### Izin RBAC permisif -You can replicate a permissive ABAC policy using RBAC role bindings. +Kamu dapat mereplikasi kebijakan ABAC yang permisif dengan menggunakan RoleBinding +RBAC. {{< warning >}} -The following policy allows **ALL** service accounts to act as cluster administrators. -Any application running in a container receives service account credentials automatically, -and could perform any action against the API, including viewing secrets and modifying permissions. -This is not a recommended policy. +Kebijakan berikut mengizinkan **SEMUA** ServiceAccount bentindak sebagai administrator +klaster. Aplikasi apa pun yang berjalan di dalam Container akan menerima kredensial +ServiceAccount secara otomatis, dan dapat melakukan tindakan apa pun terhadap API, +termasuk menampilkan Secret dan mengubah izin. Hal ini bukan kebijakan +yang direkomendasikan. ```shell kubectl create clusterrolebinding permissive-binding \ @@ -1189,7 +1221,6 @@ kubectl create clusterrolebinding permissive-binding \ ``` {{< /warning >}} -After you have transitioned to use RBAC, you should adjust the access controls -for your cluster to ensure that these meet your information security needs. - - +Setelah kamu beralih menggunakan RBAC, kamu harus menyesuaikan kontrol akses untuk +klastermu untuk memastikan bahwa kesemuanya memenuhi kebutuhanmu terkait keamanan +informasi. diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index a3401b30f5..2964583c13 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -379,7 +379,7 @@ There are a few reasons for using proxying for Services: ### 为什么不使用 DNS 轮询？ -时不时会有人问道，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？ +时不时会有人问到，就是为什么 Kubernetes 依赖代理将入站流量转发到后端。 那其他方法呢？ 例如，是否可以配置具有多个A值（或IPv6为AAAA）的DNS记录，并依靠轮询名称解析？ 使用服务代理有以下几个原因： diff --git a/content/zh/docs/tasks/job/parallel-processing-expansion.md b/content/zh/docs/tasks/job/parallel-processing-expansion.md index b010ae6848..b4b4cc255b 100644 --- a/content/zh/docs/tasks/job/parallel-processing-expansion.md +++ b/content/zh/docs/tasks/job/parallel-processing-expansion.md @@ -1,341 +1,474 @@ ---- -title: 使用扩展进行并行处理 -content_type: concept -min-kubernetes-server-version: v1.8 -weight: 20 ---- - - - - - - -在这个示例中，我们将运行从一个公共模板创建的多个 Kubernetes Job。您可能需要先熟悉 [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) 的基本概念、非并行以及如何使用它。 - - - - - - - - -## 基本模板扩展 - - -首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。 - -{{< codenew file="application/job/job-tmpl.yaml" >}} - - -与 *pod 模板*不同，我们的 *job 模板*不是 Kubernetes API 类型。它只是 Job 对象的 yaml 表示， -YAML 文件有一些占位符，在使用它之前需要填充这些占位符。`$ITEM` 语法对 Kubernetes 没有意义。 - - -在这个例子中，容器所做的唯一处理是 `echo` 一个字符串并睡眠一段时间。 -在真实的用例中，处理将是一些重要的计算，例如渲染电影的一帧，或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。 - - -这个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。这个标签在系统中没有什么特别之处。 -这个标签使得我们可以方便地同时操作组中的所有作业。 -我们还将相同的标签放在 pod 模板上，这样我们就可以用一个命令检查这些 Job 的所有 pod。 -创建作业之后，系统将添加更多的标签来区分一个 Job 的 pod 和另一个 Job 的 pod。 -注意，标签键 `jobgroup` 对 Kubernetes 并无特殊含义。您可以选择自己的标签方案。 - - -下一步，将模板展开到多个文件中，每个文件对应要处理的项。 - -```shell -# 下载 job-templ.yaml -curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml - -# 创建临时目录，并且在目录中创建 job yaml 文件 -mkdir ./jobs -for i in apple banana cherry -do - cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml -done -``` - - -检查是否工作正常： - -```shell -ls jobs/ -``` - - -输出类似以下内容： - -``` -job-apple.yaml -job-banana.yaml -job-cherry.yaml -``` - - -在这里，我们使用 `sed` 将字符串 `$ITEM` 替换为循环变量。 -您可以使用任何类型的模板语言(jinja2, erb) 或编写程序来生成 Job 对象。 - - -接下来，使用 kubectl 命令创建所有作业： - -```shell -kubectl create -f ./jobs -``` - - -输出类似以下内容： - -``` -job.batch/process-item-apple created -job.batch/process-item-banana created -job.batch/process-item-cherry created -``` - - -现在，检查这些作业： - -```shell -kubectl get jobs -l jobgroup=jobexample -``` - - -输出类似以下内容： - -``` -NAME COMPLETIONS DURATION AGE -process-item-apple 1/1 14s 20s -process-item-banana 1/1 12s 20s -process-item-cherry 1/1 12s 20s -``` - - -在这里，我们使用 `-l` 选项选择属于这组作业的所有作业。(系统中可能还有其他不相关的工作，我们不想看到。) - - -使用同样的标签选择器，我们还可以检查 pods： - -```shell -kubectl get pods -l jobgroup=jobexample -``` - - -输出类似以下内容： - -``` -NAME READY STATUS RESTARTS AGE -process-item-apple-kixwv 0/1 Completed 0 4m -process-item-banana-wrsf7 0/1 Completed 0 4m -process-item-cherry-dnfu9 0/1 Completed 0 4m -``` - - -我们可以使用以下操作命令一次性地检查所有作业的输出： - -```shell -kubectl logs -f -l jobgroup=jobexample -``` - - -输出内容为： - -``` -Processing item apple -Processing item banana -Processing item cherry -``` - - - -## 多个模板参数 - - -在第一个示例中，模板的每个实例都有一个参数，该参数也用作标签。 -但是标签的键名在[可包含的字符](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)方面有一定的约束。 - - -这个稍微复杂一点的示例使用 jinja2 模板语言来生成我们的对象。 -我们将使用一行 python 脚本将模板转换为文件。 - - -首先，粘贴 Job 对象的以下模板到一个名为 `job.yaml.jinja2` 的文件中： - -```liquid -{%- set params = [{ "name": "apple", "url": "https://www.orangepippin.com/varieties/apples", }, - { "name": "banana", "url": "https://en.wikipedia.org/wiki/Banana", }, - { "name": "raspberry", "url": "https://www.raspberrypi.org/" }] -%} -{%- for p in params %} -{%- set name = p["name"] %} -{%- set url = p["url"] %} -apiVersion: batch/v1 -kind: Job -metadata: - name: jobexample-{{ name }} - labels: - jobgroup: jobexample -spec: - template: - metadata: - name: jobexample - labels: - jobgroup: jobexample - spec: - containers: - - name: c - image: busybox - command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] - restartPolicy: Never ---- -{%- endfor %} - -``` - - -上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。 -然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。 -我们利用了多个 yaml 文档可以与 `---` 分隔符连接的事实（倒数第二行）。 -我们可以将输出直接传递给 kubectl 来创建对象。 - - -如果您还没有 jinja2 包则需要安装它: `pip install --user jinja2`。 -现在，使用这个一行 python 程序来展开模板: - -```shell -alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' -``` - - - -输出可以保存到一个文件，像这样： - -```shell -cat job.yaml.jinja2 | render_template > jobs.yaml -``` - - -或直接发送到 kubectl，如下所示： - -```shell -cat job.yaml.jinja2 | render_template | kubectl apply -f - -``` - - -## 替代方案 - - -如果您有大量作业对象，您可能会发现： - - - -- 即使使用标签，管理这么多 Job 对象也很麻烦。 -- 在一次创建所有作业时，您超过了资源配额，可是您也不希望以递增方式创建 Job 并等待其完成。 -- 同时创建大量作业会使 Kubernetes apiserver、控制器或者调度器负压过大。 - - - -在这种情况下，您可以考虑其他的[作业模式](/docs/concepts/jobs/run-to-completion-finite-workloads/#job-patterns)。 - - +--- +title: 使用展开的方式进行并行处理 +content_type: concept +min-kubernetes-server-version: v1.8 +weight: 20 +--- + + + + + + +本任务展示基于一个公共的模板运行多个{{< glossary_tooltip text="Jobs" term_id="job" >}}。 +你可以用这种方法来并行执行批处理任务。 + +在本任务示例中，只有三个工作条目：_apple_、_banana_ 和 _cherry_。 +示例任务处理每个条目时仅仅是打印一个字符串之后结束。 +参考[在真实负载中使用 Job](#using-jobs-in-real-workloads)了解更适用于真实使用场景的模式。 + +## {{% heading "prerequisites" %}} + + +你应先熟悉基本的、非并行的 [Job](/zh/docs/concepts/workloads/controllers/job/) +的用法。 + +{{< include "task-tutorial-prereqs.md" >}} + + +任务中的基本模板示例要求安装命令行工具 `sed`。 +要使用较高级的模板示例，你需要安装 [Python](https://www.python.org/)， +并且要安装 Jinja2 模板库。 + +一旦 Python 已经安装好，你可以运行下面的命令安装 Jinja2： + +```shell +pip install --user jinja2 +``` + + + + + +## 基于模板创建 Job {#create-jobs-based-on-a-template} + + +首先，将以下作业模板下载到名为 `job-tmpl.yaml` 的文件中。 + +{{< codenew file="application/job/job-tmpl.yaml" >}} + +```shell +# 使用 curl 下载 job-tmpl.yaml +curl -L -s -O https://k8s.io/examples/application/job/job-tmpl.yaml +``` + + +你所下载的文件不是一个合法的 Kubernetes {{< glossary_tooltip text="清单" term_id="manifest" >}}。 +这里的模板只是 Job 对象的 yaml 表示，其中包含一些占位符，在使用它之前需要被填充。 +`$ITEM` 语法对 Kubernetes 没有意义。 + + +### 基于模板创建清单 + +下面的 Shell 代码片段使用 `sed` 将字符串 `$ITEM` 替换为循环变量，并将结果 +写入到一个名为 `jobs` 的临时目录。 + +```shell +# 展开模板文件到多个文件中，每个文件对应一个要处理的条目 +mkdir ./jobs +for i in apple banana cherry +do + cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml +done +``` + + +检查上述脚本的输出： + +```shell +ls jobs/ +``` + + +输出类似于： + +``` +job-apple.yaml +job-banana.yaml +job-cherry.yaml +``` + + +你可以使用任何一种模板语言（例如：Jinja2、ERB），或者编写一个程序来 +生成 Job 清单。 + + +### 基于清单创建 Job + +接下来用一个 kubectl 命令创建所有的 Job： + +```shell +kubectl create -f ./jobs +``` + + + +输出类似于： + +``` +job.batch/process-item-apple created +job.batch/process-item-banana created +job.batch/process-item-cherry created +``` + + +现在检查 Job： + +```shell +kubectl get jobs -l jobgroup=jobexample +``` + + +输出类似于： + +``` +NAME COMPLETIONS DURATION AGE +process-item-apple 1/1 14s 22s +process-item-banana 1/1 12s 21s +process-item-cherry 1/1 12s 20s +``` + + +使用 kubectl 的 `-l` 选项可以仅选择属于当前 Job 组的对象 +（系统中可能存在其他不相关的 Job）。 + +你可以使用相同的 {{< glossary_tooltip text="标签选择算符" term_id="selector" >}} +来过滤 Pods： + +```shell +kubectl get pods -l jobgroup=jobexample +``` + + +输出类似于： + +``` +NAME READY STATUS RESTARTS AGE +process-item-apple-kixwv 0/1 Completed 0 4m +process-item-banana-wrsf7 0/1 Completed 0 4m +process-item-cherry-dnfu9 0/1 Completed 0 4m +``` + + +我们可以用下面的命令查看所有 Job 的输出： + +```shell +kubectl logs -f -l jobgroup=jobexample +``` + + +输出类似于： + +``` +Processing item apple +Processing item banana +Processing item cherry +``` + + +### 清理 {#cleanup-1} + +```shell +# 删除所创建的 Job +# 集群会自动清理 Job 对应的 Pod +kubectl delete job -l jobgroup=jobexample +``` + + +## 使用高级模板参数 + +在[第一个例子](#create-jobs-based-on-a-template)中，模板的每个示例都有一个参数 +而该参数也用在 Job 名称中。不过，对象 +[名称](/zh/docs/concepts/overview/working-with-objects/names/#names) +被限制只能使用某些字符。 + + +这里的略微复杂的例子使用 [Jinja 模板语言](https://palletsprojects.com/p/jinja/) +来生成清单，并基于清单来生成对象，每个 Job 都有多个参数。 + +在本任务中，你将会使用一个一行的 Python 脚本，将模板转换为一组清单文件。 + +首先，复制下面的 Job 对象模板到一个名为 `job.yaml.jinja2` 的文件。 + +```liquid +{%- set params = [{ "name": "apple", "url": "http://dbpedia.org/resource/Apple", }, + { "name": "banana", "url": "http://dbpedia.org/resource/Banana", }, + { "name": "cherry", "url": "http://dbpedia.org/resource/Cherry" }] +%} +{%- for p in params %} +{%- set name = p["name"] %} +{%- set url = p["url"] %} +--- +apiVersion: batch/v1 +kind: Job +metadata: + name: jobexample-{{ name }} + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox + command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"] + restartPolicy: Never +{%- endfor %} +``` + + +上面的模板使用 python 字典列表（第 1-4 行）定义每个作业对象的参数。 +然后使用 for 循环为每组参数（剩余行）生成一个作业 yaml 对象。 +我们利用了多个 YAML 文档（这里的 Kubernetes 清单）可以用 `---` 分隔符连接的事实。 +我们可以将输出直接传递给 kubectl 来创建对象。 + +接下来我们用单行的 Python 程序将模板展开。 + +```shell +alias render_template='python -c "from jinja2 import Template; import sys; print(Template(sys.stdin.read()).render());"' +``` + + +使用 `render_template` 将参数和模板转换成一个 YAML 文件，其中包含 Kubernetes +资源清单： + +```shell +# 此命令需要之前定义的别名 +cat job.yaml.jinja2 | render_template > jobs.yaml +``` + + +你可以查看 `jobs.yaml` 以验证 `render_template` 脚本是否正常工作。 + +当你对输出结果比较满意时，可以用管道将其输出发送给 kubectl，如下所示： + +```shell +cat job.yaml.jinja2 | render_template | kubectl apply -f - +``` + + +Kubernets 接收清单文件并执行你所创建的 Job。 + + + + +## 在真实负载中使用 Job + +在真实的负载中，每个 Job 都会执行一些重要的计算，例如渲染电影的一帧， +或者处理数据库中的若干行。这时，`$ITEM` 参数将指定帧号或行范围。 + +在此任务中，你运行一个命令通过取回 Pod 的日志来收集其输出。 +在真实应用场景中，Job 的每个 Pod 都会在结束之前将其输出写入到某持久性存储中。 +你可以为每个 Job 指定 PersistentVolume 卷，或者使用其他外部存储服务。 +例如，如果你在渲染视频帧，你可能会使用 HTTP 协议将渲染完的帧数据 +用 'PUT' 请求发送到某 URL，每个帧使用不同的 URl。 + + +## Job 和 Pod 上的标签 + +你创建了 Job 之后，Kubernetes 自动为 Job 的 Pod 添加 +{{< glossary_tooltip text="标签" term_id="label" >}}，以便能够将一个 Job +的 Pod 与另一个 Job 的 Pod 区分开来。 + +在本例中，每个 Job 及其 Pod 模板有一个标签: `jobgroup=jobexample`。 + +Kubernetes 自身对标签名 `jobgroup` 没有什么要求。 +为创建自同一模板的所有 Job 使用同一标签使得我们可以方便地同时操作组中的所有作业。 +在[第一个例子](#create-jobs-based-on-a-template)中，你使用模板来创建了若干 Job。 +模板确保每个 Pod 都能够获得相同的标签，这样你可以用一条命令检查这些模板化 +Job 所生成的全部 Pod。 + + +{{< note >}} +标签键 `jobgroup` 没什么特殊的，也不是保留字。 你可以选择你自己的标签方案。 +如果愿意，有一些[建议的标签](/zh/docs/concepts/overview/working-with-objects/common-labels/#labels) +可供使用。 +{{< /note >}} + + +## 替代方案 + +如果你有计划创建大量 Job 对象，你可能会发现： + + +- 即使使用标签，管理这么多 Job 对象也很麻烦。 +- 如果你一次性创建很多 Job，很可能会给 Kubernetes 控制面带来很大压力。 + 一种替代方案是，Kubernetes API 可能对请求施加速率限制，通过 429 返回 + 状态值临时拒绝你的请求。 +- 你可能会受到 Job 相关的{{< glossary_tooltip text="资源配额" term_id="resource-quota" >}} + 限制：如果你在一个批量请求中触发了太多的任务，API 服务器会永久性地拒绝你的某些请求。 + + +还有一些其他[作业模式](/zh/docs/concepts/workloads/controllers/job/#job-patterns) +可供选择，这些模式都能用来处理大量任务而又不会创建过多的 Job 对象。 + +你也可以考虑编写自己的[控制器](/zh/docs/concepts/architecture/controller/) +来自动管理 Job 对象。 + diff --git a/layouts/404.html b/layouts/404.html index 962894ee29..beef5c7999 100644 --- a/layouts/404.html +++ b/layouts/404.html @@ -7,7 +7,7 @@
    {{ $sections := slice "docs" "blog" "training" "partners" "community" "case-studies" }} {{ range $sections }} - {{ with site.GetPage "section" . }}
  • {{ .Title }}
    • {{ end }} + {{ with site.GetPage "section" . }}
  • {{ .Title }}
    • {{ end }} {{ end }}