Skip to content

Commit 869fded

Browse files
authored
Merge pull request #22420 from sumodirjo/administer-cluster-namespaces
ID translation of /docs/tasks/administer-cluster/namespaces
2 parents 1a7e81f + d01f716 commit 869fded

File tree

1 file changed

+302
-0
lines changed

1 file changed

+302
-0
lines changed
Lines changed: 302 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,302 @@
1+
---
2+
title: Membagi sebuah Klaster dengan Namespace
3+
content_type: task
4+
---
5+
6+
<!-- overview -->
7+
Laman ini menunjukkan bagaimana cara melihat, menggunakan dan menghapus {{< glossary_tooltip text="namespaces" term_id="namespace" >}}. Laman ini juga menunjukkan bagaimana cara menggunakan Namespace Kubernetes namespaces untuk membagi klaster kamu.
8+
9+
10+
## {{% heading "prerequisites" %}}
11+
12+
* Memiliki [Klaster Kubernetes](/id/docs/setup/).
13+
* Memiliki pemahaman dasar [_Pod_](/id/docs/concepts/workloads/pods/pod/), [_Service_](/id/docs/concepts/services-networking/service/), dan [_Deployment_](/id/docs/concepts/workloads/controllers/deployment/) dalam Kubernetes.
14+
15+
16+
<!-- steps -->
17+
18+
## Melihat Namespace
19+
20+
1. Untuk melihat Namespace yang ada saat ini pada sebuah klaster anda bisa menggunakan:
21+
22+
```shell
23+
kubectl get namespaces
24+
```
25+
```
26+
NAME STATUS AGE
27+
default Active 11d
28+
kube-system Active 11d
29+
kube-public Active 11d
30+
```
31+
32+
Kubernetes mulai dengan tiga Namespace pertama:
33+
34+
* `default` Namespace bawaan untuk objek-objek yang belum terkait dengan Namespace lain
35+
* `kube-system` Namespace untuk objek-objek yang dibuat oleh sistem Kubernetes
36+
* `kube-public` Namespace ini dibuat secara otomatis dan dapat dibaca oleh seluruh pengguna (termasuk yang tidak terotentikasi). Namespace ini sering dicadangkan untuk kepentingan klaster, untuk kasus dimana beberapa sumber daya seharusnya dapat terlihat dan dapat terlihat secara publik di seluruh klaster. Aspek publik pada Namespace ini hanya sebuah konvensi bukan suatu kebutuhan.
37+
38+
Kamu bisa mendapat ringkasan Namespace tertentu dengan menggunakan:
39+
40+
```shell
41+
kubectl get namespaces <name>
42+
```
43+
44+
Atau kamu bisa mendapatkan informasi detail menggunakan:
45+
46+
```shell
47+
kubectl describe namespaces <name>
48+
```
49+
```
50+
Name: default
51+
Labels: <none>
52+
Annotations: <none>
53+
Status: Active
54+
55+
No resource quota.
56+
57+
Resource Limits
58+
Type Resource Min Max Default
59+
---- -------- --- --- ---
60+
Container cpu - - 100m
61+
```
62+
63+
Sebagai catatan, detail diatas menunjukkan baik kuota sumber daya (jika ada) dan juga jangkauan batas sumber daya.
64+
65+
Kuota sumber daya melacak penggunaan total sumber daya didalam Namespace dan mengijinkan operator-operator klaster mendefinisikan batas atas penggunaan sumber daya yang dapat di gunakan sebuah Namespace.
66+
67+
Jangkauan batas mendefinisikan pertimbangan min/maks jumlah sumber daya yang dapat di gunakan oleh sebuah entitas dalam sebuah Namespace.
68+
69+
Lihatlah [Kontrol Admisi: Rentang Batas](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md)
70+
71+
Sebuah Namespace dapat berada dalam salah satu dari dua buah fase:
72+
73+
* `Active` Namespace sedang digunakan
74+
* `Terminating` Namespace sedang dihapus dan tidak dapat digunakan untuk objek-objek baru
75+
76+
Lihat [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) untuk detil lebih lanjut.
77+
78+
## Membuat sebuah Namespace baru
79+
80+
{{< note >}}
81+
Hindari membuat Namespace dengan awalan `kube-`, karena awalan ini dicadangkan untuk Namespace dari sistem Kubernetes.
82+
{{< /note >}}
83+
84+
1. Buat berkas YAML baru dengan nama `my-namespace.yaml` dengan isi berikut ini:
85+
86+
```yaml
87+
apiVersion: v1
88+
kind: Namespace
89+
metadata:
90+
name: <masukkan-nama-namespace-disini>
91+
```
92+
Then run:
93+
94+
```
95+
kubectl create -f ./my-namespace.yaml
96+
```
97+
98+
2. Sebagai alternatif, kamu bisa membuat Namespace menggunakan perintah dibawah ini:
99+
100+
```
101+
kubectl create namespace <masukkan-nama-namespace-disini>
102+
```
103+
104+
Nama Namespace kamu harus merupakan
105+
[Label DNS](/docs/concepts/overview/working-with-objects/names#dns-label-names) yang valid.
106+
107+
Ada kolom opsional `finalizers`, yang memungkinkan _observables_ untuk membersihkan sumber daya ketika Namespace dihapus. Ingat bahwa jika kamu memberikan finalizer yang tidak ada, Namespace akan dibuat tapi akan berhenti pada status `Terminating` jika pengguna mencoba untuk menghapusnya.
108+
109+
Informasi lebih lanjut mengenai `finalizers` bisa dibaca pada [dokumentasi desain](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#finalizers) dari Namespace.
110+
111+
## Menghapus Namespace
112+
113+
Hapus Namespace dengan
114+
115+
```shell
116+
kubectl delete namespaces <insert-some-namespace-name>
117+
```
118+
119+
{{< warning >}}
120+
Ini akan menghapus semua hal yang ada dalam Namespace!
121+
{{< /warning >}}
122+
123+
Proses penghapusan ini asinkron, jadi untuk beberapa waktu kamu akan melihat Namespace dalam status `Terminating`.
124+
125+
## Membagi klaster kamu menggunakan Namespace Kubernetes
126+
127+
1. Pahami Namespace bawaan
128+
129+
Secara bawaan, sebuah klaster Kubernetes akan membuat Namespace bawaan ketika menyediakan klaster untuk menampung Pod, Service, dan Deployment yang digunakan oleh klaster.
130+
131+
Dengan asumsi kamu memiliki klaster baru, kamu bisa mengecek Namespace yang tersedia dengan melakukan hal berikut:
132+
133+
```shell
134+
kubectl get namespaces
135+
```
136+
```
137+
NAME STATUS AGE
138+
default Active 13m
139+
```
140+
141+
2. Membuat Namespace baru
142+
143+
Untuk latihan ini, kita akan membuat dua Namespace Kubernetes tambahan untuk menyimpan konten kita
144+
145+
Dalam sebuah skenario dimana sebuah organisasi menggunakan klaster Kubernetes yang digunakan bersama untuk penggunaan pengembangan dan produksi:
146+
147+
Tim pengembang ingin mengelola ruang di dalam klaster dimana mereka bisa melihat daftar Pod, Service, dan Deployment yang digunakan untuk membangun dan menjalankan apliksi mereka. Di ruang ini sumber daya akan datang dan pergi, dan pembatasan yang tidak ketat mengenai siapa yang bisa atau tidak bisa memodifikasi sumber daya untuk mendukung pengembangan secara gesit (_agile_).
148+
149+
Tim operasi ingin mengelola ruang didalam klaster dimana mereka bisa memaksakan prosedur ketat mengenai siapa yang bisa atau tidak bisa melakukan manipulasi pada kumpulan Pod, Layanan, dan Deployment yang berjalan pada situs produksi.
150+
151+
Satu pola yang bisa diikuti organisasi ini adalah dengan membagi klaster Kubernetes menjadi dua Namespace: `development` dan `production`
152+
153+
Mari kita buat dua Namespace untuk menyimpan hasil kerja kita.
154+
155+
Buat Namespace `development` menggunakan kubectl:
156+
157+
```shell
158+
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
159+
```
160+
161+
Kemudian mari kita buat Namespace `production` menggunakan kubectl:
162+
163+
```shell
164+
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
165+
```
166+
167+
Untuk memastikan apa yang kita lakukan benar, lihat seluruh Namespace dalam klaster.
168+
169+
```shell
170+
kubectl get namespaces --show-labels
171+
```
172+
```
173+
NAME STATUS AGE LABELS
174+
default Active 32m <none>
175+
development Active 29s name=development
176+
production Active 23s name=production
177+
```
178+
179+
3. Buat pod pada setiap Namespace
180+
181+
Sebuah Namespace Kubernetes memberikan batasan untuk Pod, Service, dan Deployment dalam klaster.
182+
183+
Pengguna yang berinteraksi dengan salah satu Namespace tidak melihat konten di dalam Namespace lain
184+
185+
Untuk menunjukkan hal ini, mari kita jalankan Deployment dan Pod sederhana di dalam Namespace `development`.
186+
187+
```shell
188+
kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development
189+
kubectl scale deployment snowflake --replicas=2 -n=development
190+
```
191+
Kita baru aja membuat sebuah Deployment yang memiliki ukuran replika dua yang menjalankan Pod dengan nama `snowflake` dengan sebuah Container dasar yang hanya melayani _hostname_.
192+
193+
194+
```shell
195+
kubectl get deployment -n=development
196+
```
197+
```
198+
NAME READY UP-TO-DATE AVAILABLE AGE
199+
snowflake 2/2 2 2 2m
200+
```
201+
```shell
202+
kubectl get pods -l app=snowflake -n=development
203+
```
204+
```
205+
NAME READY STATUS RESTARTS AGE
206+
snowflake-3968820950-9dgr8 1/1 Running 0 2m
207+
snowflake-3968820950-vgc4n 1/1 Running 0 2m
208+
```
209+
210+
Dan ini merupakan sesuatu yang bagus, dimana pengembang bisa melakukan hal yang ingin mereka lakukan tanpa harus khawatir hal itu akan mempengaruhi konten pada namespace `production`.
211+
212+
Mari kita pindah ke Namespace `production` dan menujukkan bagaimana sumber daya di satu Namespace disembunyikan dari yang lain
213+
214+
Namespace `production` seharusnya kosong, dan perintah berikut ini seharusnya tidak menghasilkan apapun.
215+
216+
```shell
217+
kubectl get deployment -n=production
218+
kubectl get pods -n=production
219+
```
220+
221+
`Production` Namespace ingin menjalankan `cattle`, mari kita buat beberapa Pod `cattle`.
222+
223+
```shell
224+
kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production
225+
kubectl scale deployment cattle --replicas=5 -n=production
226+
227+
kubectl get deployment -n=production
228+
```
229+
```
230+
NAME READY UP-TO-DATE AVAILABLE AGE
231+
cattle 5/5 5 5 10s
232+
```
233+
234+
```shell
235+
kubectl get pods -l app=cattle -n=production
236+
```
237+
```
238+
NAME READY STATUS RESTARTS AGE
239+
cattle-2263376956-41xy6 1/1 Running 0 34s
240+
cattle-2263376956-kw466 1/1 Running 0 34s
241+
cattle-2263376956-n4v97 1/1 Running 0 34s
242+
cattle-2263376956-p5p3i 1/1 Running 0 34s
243+
cattle-2263376956-sxpth 1/1 Running 0 34s
244+
```
245+
246+
Sampai sini, seharusnya sudah jelas bahwa sumber daya yang dibuat pengguna pada sebuah Namespace disembunyikan dari Namespace lainnya.
247+
248+
Seiring dengan evolusi dukungan kebijakan di Kubernetes, kami akan memperluas skenario ini untuk menunjukkan bagaimana kamu bisa menyediakan aturan otorisasi yang berbeda untuk tiap Namespace.
249+
250+
251+
<!-- discussion -->
252+
253+
## Memahami motivasi penggunaan Namespace
254+
255+
Sebuah klaster tunggal umumnya bisa memenuhi kebutuhan pengguna yang berbeda atau kelompok pengguna (itulah sebabnya disebut 'komunitas pengguna').
256+
257+
Namespace Kubernetes membantu proyek-proyek, tim-tim dan pelanggan yang berbeda untuk berbagi klaster Kubernetes.
258+
259+
Ini dilakukan dengan menyediakan hal berikut:
260+
261+
1. Cakupan untuk [Names](/id/docs/concepts/overview/working-with-objects/names/).
262+
2. Sebuah mekanisme untuk memasang otorisasi dan kebijakan untuk bagian dari klaster.
263+
264+
Penggunaan Namespace berbeda merupakan hal opsional.
265+
266+
Tiap komunitas pengguna ingin bisa bekerja secara terisolasi dari komunitas lainnya.
267+
268+
Tiap komunitas pengguna memiliki hal berikut sendiri:
269+
270+
1. sumber daya (Pod, Service, ReplicationController, dll.)
271+
2. kebijakan (siapa yang bisa atau tidak bisa melakukan hal tertentu dalam komunitasnya)
272+
3. batasan (komunitas ini diberi kuota sekian, dll.)
273+
274+
Seorang operator klaster dapat membuat sebuah Namespace untuk tiap komunitas user yang unik.
275+
276+
Namespace tersebut memberikan cakupan yang unik untuk:
277+
278+
1. penamaan sumber daya (untuk menghindari benturan penamaan dasar)
279+
2. pendelegasian otoritas pengelolaan untuk pengguna yang dapat dipercaya
280+
3. kemampuan untuk membatasi konsumsi sumber daya komunitas
281+
282+
Contoh penggunaan mencakup
283+
284+
1. Sebagai operator klaster, aku ingin mendukung beberapa komunitas pengguna dalam sebuah klaster.
285+
2. Sebagai operator klaster, aku ingin mendelegasikan otoritas untuk mempartisi klaster ke pengguna terpercaya di komunitasnya.
286+
3. Sebagai operator klaster, aku ingin membatasi jumlah sumber daya yang bisa dikonsumsi komunitas dalam rangka membatasi dampak ke komunitas lain yang menggunakan klaster yang sama.
287+
4. Sebagai pengguna klaster, aku ingin berinteraksi dengan sumber daya yang berkaitan dengan komunitas pengguna saya secara terisolasi dari apa yang dilakukan komunitas lain di klaster yang sama.
288+
289+
## Memahami Namespace dan DNS
290+
291+
Ketika kamu membuat sebuah [Service](/docs/concepts/services-networking/service/), akan terbentuk [entri DNS](/id/docs/concepts/services-networking/dns-pod-service/) untuk Service tersebut.
292+
Entri DNS ini dalam bentuk `<service-name>.<namespace-name>.svc.cluster.local`, yang berarti jika sebuah Container hanya menggunakan `<service-name>` maka dia akan me-_resolve_ ke layanan yang lokal dalam Namespace yang sama. Ini berguna untuk menggunakan konfigurasi yang sama pada Namespace yang berbeda seperti _Development_, _Staging_ dan _Production_. Jika kami ingin menjangkau antar Namespace, kamu harus menggunakan _fully qualified domain name_ (FQDN).
293+
294+
295+
296+
## {{% heading "whatsnext" %}}
297+
298+
* Pelajari lebih lanjut mengenai [pengaturan preferensi Namespace](/id/docs/concepts/overview/working-with-objects/namespaces/#pengaturan-preferensi-namespace).
299+
* Pelajari lebih lanjut mengenai [pengaturan namespace untuk sebuah permintaan](/id/docs/concepts/overview/working-with-objects/namespaces/#pengaturan-namespace-untuk-sebuah-permintaan)
300+
* Baca [desain Namespace](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md).
301+
302+

0 commit comments

Comments
 (0)