Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history 
Rephrase after review.

Co-Authored-By: Giri Kuncoro <[email protected]>
  • Loading branch information
@irvifa @girikuncoro
irvifa and girikuncoro authored Nov 4, 2019
1 parent dd630c5 commit 56e577b
Showing 1 changed file with 51 additions and 51 deletions.
102 changes: 51 additions & 51 deletions content/id/docs/concepts/workloads/controllers/statefulset.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: StatefulSets
title: StatefulSet
content_template: templates/concept
weight: 40
---
Expand All @@ -9,50 +9,50 @@ weight: 40
StatefulSet merupakan salah satu objek API _workload_ yang digunakan untuk aplikasi _stateful_.

{{< note >}}
StatefulSets merupakan fitur _stable_ (GA) sejak versi 1.9.
StatefulSet merupakan fitur stabil (GA) sejak versi 1.9.
{{< /note >}}

{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}

{{% capture body %}}

## Using StatefulSets
## Menggunakan StatefulSet

StatefulSets akan sangat bermanfaat apabila digunakan untuk aplikasi
yang membutuhkan salah satu atau lebih fungsionalitas sebagai berikut.
StatefulSet akan sangat bermanfaat apabila digunakan untuk aplikasi
yang membutuhkan salah satu atau beberapa fungsi berikut.

* Memiliki indentitas jaringan unik yang stabil.
* Memiliki identitas jaringan unik yang stabil.
* Penyimpanan persisten yang stabil.
* Mekanisme _scaling_ dan _deployment_ yang _graceful_ tertara secara _ordering_.
* Mekanisme _rolling updates_ yang otomatis berdasarkan _ordering_.

Berdasarkan hal di atas, stable memiliki arti yang sama dengan persistence pada
Pod ketika di dalam face _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan
identitas yang stabil atau deployment yang memiliki _ordering_, penghapusan, atau
mekanisme _scaling_, kamu harus men-deploy aplikasi dengan kontroler yang menyediakan
replika _stateless_. Kontroler seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau
* Mekanisme _scaling_ dan _deployment_ yang _graceful_ tertara berdasarkan urutan.
* Mekanisme _rolling update_ yang otomatis berdasarkan urutan.

Stabil dalam poin-poin di atas memiliki arti yang sama dengan persisten pada
Pod saat dilakukan _(re)scheduling_. Jika suatu aplikasi tidak membutuhkan
identitas yang stabil atau _deployment_ yang memiliki urutan, penghapusan, atau
mekanisme _scaling_, kamu harus melakukan _deploy_ aplikasi dengan _controller_ yang menyediakan
replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads/controllers/deployment/) atau
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.

## Keterbatasan

* StatefulSet merupakan sumber daya beta sebelum 1.9 dan tidak tersedia
pada Kubernetes rilis sebelum versi 1.5.
* Storage untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh admin.
* Penyimpanan untuk sebuah Pod harus terlebih dahulu di-_provision_ dengan menggunakan sebuah [Provisioner PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) berdasarkan `storage class` yang dispesifikasikan, atau sudah ditentukan sebelumnya oleh administrator.
* Menghapus dan/atau _scaling_ sebuah StatefulSet *tidak akan* menghapus volume yang berkaitan dengan StatefulSet tersebut. Hal ini dilakukan untuk menjamin data yang disimpan, yang secara umum dinilai lebih berhaga dibandingkan dengan mekanisme penghapusan data secara otomatis pada sumber daya terkait.
* StatefulSets saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
* StatefulSets tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ pod ke 0 sebelum penghapusan.
* Ketika menggunakan [Rolling Updates](#rolling-updates) dengan
[Pod Management Policy](#pod-management-policies) (`OrderedReady`) secara default,
* StatefulSet saat ini membutuhkan sebuah [Headless Service](/docs/concepts/services-networking/service/#headless-services) yang nantinya akan bertanggung jawab terhadap pada identitas jaringan pada Pod. Kamulah yang bertanggung jawab untuk membuat Service tersebut.
* StatefulSet tidak menjamin terminasi Pod ketika sebuah StatefulSet dihapus. Untuk mendapatkan terminasi Pod yang terurut dan _graceful_ pada StatefulSet, kita dapat melakukan _scale down_ Pod ke 0 sebelum penghapusan.
* Ketika menggunakan [Rolling Update](#mekanisme-strategi-update-rolling-update) dengan
[Kebijakan Manajemen Pod](#kebijakan-manajemen-pod) (`OrderedReady`) secara default,
hal ini memungkinkan untuk mendapatkan _state_ yang lebih terperinci yang membutuhkan
[mekanisme intervensi manual untuk perbaikan](#forced-rollback).

## Komponen-Komponen
Contoh di bawah ini akna menunjukkan komponen-komponen penyusun StatefulSet.

* Sebuah Service Headless, dengan nama nginx, digunakan untuk mengontrol domain jaringan.
* StatefulSet, dengan nama web, memiliki Spec yang mengindikasikan terdapat 3 replika container yang akan di-_launch_ pada Pod yang unik.
* Sumber daya volumeClaimTemplates akan menyediakan penyimpanan _stable_ menggunakan [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
* StatefulSet, dengan nama web, memiliki Spek yang mengindikasikan terdapat 3 replika Container yang akan dihidupkan pada Pod yang unik.
* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.

```yaml
apiVersion: v1
Expand Down Expand Up @@ -105,38 +105,38 @@ spec:
storage: 1Gi
```
## Selector Pod
Kamu harus menspesifikasikan _field_ `.spec.selector` dari sebuah StatefulSet untuk menyesuaikan dengan label yang ada pada `.spec.template.metadata.labels`. Sebelum Kubernetes 1.8, _field_ `.spec.selector` dapat diabaikan. Sejak versi 1.8 dan versi selanjutnya, apabila tidak terdapat Pod Selector yang sesuai maka akan menghasilkan eror pada validasi pembuatan StatefulSet.
## _Selector_ Pod
Kamu harus menspesifikasikan _field_ `.spec.selector` dari sebuah StatefulSet untuk menyesuaikan dengan label yang ada pada `.spec.template.metadata.labels`. Sebelum Kubernetes 1.8, _field_ `.spec.selector` dapat diabaikan. Sejak versi 1.8 dan versi selanjutnya, apabila tidak terdapat _selector_ Pod yang sesuai maka akan menghasilkan eror pada validasi pembuatan StatefulSet.

## Identitas Pod
Pod pada StatefulSet memiliki identitas unik yang terseusun berdasarkan skala ordinal, sebuah
identitas jaringan yang _stable_, serta _storage_ yang _stable_. Identitas yang ada pada Pod
ini akan tetap melekat, meskipun Pod tersebut di _(re)scheduled_ pada node yang berbeda.
Pod pada StatefulSet memiliki identitas unik yang tersusun berdasarkan skala ordinal, sebuah
identitas jaringan yang stabil, serta penyimpanan yang stabil. Identitas yang ada pada Pod
ini akan tetap melekat, meskipun Pod tersebut dilakukan _(re)schedule_ pada Node yang berbeda.

### Index Ordinal
### Indeks Ordinal

Untuk sebuah StatefulSet dengan N buah replika, setiap Pod di dalam StatefulSet akan
diberi nama pada suatu index ordinal tertentu, dari 0 hingga N-1, yang unik pada Set ini.
diberi nama pada suatu indeks ordinal tertentu, dari 0 hingga N-1, yang unik pada Set ini.

### ID Jaringan yang _Stable_
### ID Jaringan yang Stabil

Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama SatetulSets tersebut
Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama SatetulSet tersebut
serta ordinal Pod tersebut. Pola pada _hostname_ yang terbentuk adalah
`$(statefulset name)-$(ordinal)`. Contoh di atas akan menghasilkan tiga Pod
dengan nama `web-0,web-1,web-2`.
Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/docs/concepts/services-networking/service/#headless-services)
untuk mengontrol domain dari Pod yang ada. Domain yang di-_manage_ oleh Service ini memiliki format:
untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
domain kluster.
Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendiri, yang memiliki format:
`$(podname).$(governing service domain)`, dimana service yang mengatur didefinisikan oleh
`$(podname).$(governing service domain)`, dimana Service yang mengatur didefinisikan oleh
_field_ `serviceName` pada StatefulSet.

Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah yang bertanggung jawab
untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
yang bertanggung jawab terhadap identitas jaringan pada Pod.

Disini terdapat beberapa contoh penggunakan Domain Kluster, nama Service,
Di sini terdapat beberapa contoh penggunaan Domain Kluster, nama Service,
nama StatefulSet, dan bagaimana hal tersebut berdampak pada nama DNS dari Pod StatefulSet.

Domain Kluster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet | DNS Pod | Hostname Pod |
Expand All @@ -146,39 +146,39 @@ Domain Kluster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |

{{< note >}}
Domain kluster akan di-_set_ menjadi `cluster.local` kecuali
Domain kluster akan diatur menjadi `cluster.local` kecuali
[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
{{< /note >}}

### Storage _Stable_
### Penyimpanan Stabil

Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap
VolumeClaimTemplate. Pada contoh nginx di atas, setiap Pod akan menerima sebuah PersistentVolume
dengan StorageClass `my-storage-class` dan _storage_ senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass
yang dispesifikasikan, maka StorageClass default akan digunakan. Ketika sebuah Pod di-_(re)scheduled_
pada sebuah node, `volumeMounts` akan me-_mount_ PersistentVolumes yang terkait dengan
PersistentVolume Claims-nya. Pertatihan bahwa, PersistentVolumes yang terkait dengan
PersistentVolume Claims Pod tidak akan dihapus ketika Pod, atau StatefulSet dihapus.
dengan StorageClass `my-storage-class` dan penyimpanan senilai 1 Gib yang sudah di-_provisioning_. Jika tidak ada StorageClass
yang dispesifikasikan, maka StorageClass _default_ akan digunakan. Ketika sebuah Pod dilakukan _(re)schedule_
pada sebuah Node, `volumeMounts` akan me-_mount_ PersistentVolumes yang terkait dengan
PersistentVolume Claim-nya. Perhatikan bahwa, PersistentVolume yang terkait dengan
PersistentVolumeClaim dari Pod tidak akan dihapus ketika Pod, atau StatefulSet dihapus.
Penghapusan ini harus dilakukan secara manual.

### _Pod Name Label_
### Label _Pod Name_

Ketika sebuah kontroler StatefulSet membuat sebuah Pod, kontroler ini akan menambahkan label, `statefulset.kubernetes.io/pod-name`,
Ketika sebuah _controller_ StatefulSet membuat sebuah Pod, _controller_ ini akan menambahkan label, `statefulset.kubernetes.io/pod-name`,
yang akan diaktifkan pada nama Pod. Label ini akan mengizinkan kamu untuk meng-_attach_ sebuah Service pada Pod spesifik tertentu.
di StatefulSet.

## Jaminan Deployment dan Mekanisme _Scaling_

* Untuk sebuah StatefulSet dengan N buah replika, ketika Pod di-deploy, Pod tersebut akan dibuat secara sekuensial dengan urutan nilai {0..N-1}.
* Untuk sebuah StatefulSet dengan N buah replika, ketika Pod di-_deploy_, Pod tersebut akan dibuat secara berurutan dengan urutan nilai {0..N-1}.
* Ketika Pod dihapus, Pod tersebut akan dihentikan dengan urutan terbalik, yaitu {N-1..0}.
* Sebelum operasi _scaling_ diaplikasikan pada sebuah Pod, semua Pod sebelum Pod tersebut haruslah sudah dalam status Running dan Ready.
* Sebelum sebuah Pod dihentikan, semua Pod setelah Pod tersebut haruslah sudah terlebih dahulu dihentikan.

StatefulSet tidak boleh menspesifikasikan nilai dari `pod.Spec.TerminationGracePeriodSeconds` menjadi 0. Hal ini tidaklah aman dan tidak disarankan. Untuk penjelasan lebih lanjut, silakan lihat [penghapusan paksa Pod pada StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).

Ketika contoh nginx di atas dibuat, tiga Pod akan di-deploy dengan urutan
web-0, web-1, web-2. web-1 tidak akan di-deploy sebelum web-0 berada dalam status
[Running dan Ready](/docs/user-guide/pod-states/), dan web-2 tidak akan di-deploy sebelum
Ketika contoh nginx di atas dibuat, tiga Pod akan di-_deploy_ dengan urutan
web-0, web-1, web-2. web-1 tidak akan di-_deploy_ sebelum web-0 berada dalam status
[Running dan Ready](/docs/user-guide/pod-states/), dan web-2 tidak akan di-_deploy_ sebelum
web-1 berada dalam status Running dan Ready. Jika web-0 gagal, setelah web-1 berada dalam status Running and Ready,
tapi sebelum web-2 dibuat, maka web-2 tidak akan dibuat hingga web-0 sukses dibuat ulang dan
berada dalam status Running dan Ready.
Expand All @@ -193,21 +193,21 @@ web-0 berada dalam status Running dan Ready.
### Kebijakan Manajemen Pod

Pada Kubernetes versi 1.7 dan setelahnya, StatefulSet mengizinkan kamu untuk
melakukan mekanisme _ordering_ tadi menjadi lebih fleksibel dengan tetap
melakukan mekanisme urutan tadi menjadi lebih fleksibel dengan tetap
menjamin keunikan dan identitas yang ada melalui _field_ `.spec.podManagementPolicy`.

#### Manajemen OrderedReady pada Pod

Manajemen `OrderedReady` pada Pod merupakan nilai default dari StatefulSets.
Hal ini akan mengimplementasikan perilaku yang dijelasikan [diatas](#jaminan-deployment-dan-mekanisme-scaling).
Manajemen `OrderedReady` pada Pod merupakan nilai default dari StatefulSet.
Hal ini akan mengimplementasikan perilaku yang dijelaskan [di atas](#jaminan-deployment-dan-mekanisme-scaling).

#### Manajemen Pod secara Paralel

Manajemen Pod secara `Parallel` akan menyebabkan kontroler StatefulSet untuk
me-_launch_ atau menghentikan semua Pod yang ada secara paralel, dan tidak
memulai atau menghentikan semua Pod yang ada secara paralel, dan tidak
menunggu Pod berada dalam status Running dan Ready atau sudah dihentikan secara menyeluruh
sebelum me-_launch_ atau menghentikan Pod yang lain. Opsi ini hanya akan memengaruhi operasi
_scaling_. Operasi update tidak akan terpengaruh.
_scaling_. Operasi pembaruan tidak akan terpengaruh.

## Strategi Update

Expand Down

0 comments on commit 56e577b

Please sign in to comment.