Replace EN links to ID links
This commit is contained in:
Gede Wahyu
@@ -6,7 +6,7 @@ weight: 80
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Suatu CronJob menciptakan [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
|
||||
Suatu CronJob menciptakan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) yang dijadwalkan berdasarkan waktu tertentu.
|
||||
|
||||
Satu objek CronJob sepadan dengan satu baris pada _file_ _crontab_ (_cron table_). CronJob tersebut menjalankan suatu pekerjaan secara berkala
|
||||
pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wiki/Cron).
|
||||
@@ -15,7 +15,7 @@ pada waktu tertentu, dituliskan dalam format [Cron](https://en.wikipedia.org/wik
|
||||
Seluruh waktu `schedule:` pada _**CronJob**_ mengikuti zona waktu dari _master_ di mana Job diinisiasi.
|
||||
{{< /note >}}
|
||||
|
||||
Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
Untuk panduan dalam berkreasi dengan _cron job_, dan contoh _spec file_ untuk suatu _cron job_, lihat [Menjalankan otomasi _task_ dengan _cron job_](/id/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
|
||||
|
||||
Seperti semua konfigurasi Kubernetes lainnya, DaemonSet membutuhkan _field_
|
||||
`apiVersion`, `kind`, dan `metadata`. Untuk informasi umum tentang berkas konfigurasi, lihat dokumen [men-_deploy_ aplikasi](/docs/user-guide/deploying-applications/),
|
||||
[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/docs/concepts/overview/working-with-objects/object-management/).
|
||||
[pengaturan kontainer](/docs/tasks/), dan [pengelolaan objek dengan kubectl](/id/docs/concepts/overview/working-with-objects/object-management/).
|
||||
|
||||
DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
||||
@@ -61,7 +61,7 @@ DaemonSet juga membutuhkan bagian [`.spec`](https://git.k8s.io/community/contrib
|
||||
Selain _field_ wajib untuk Pod, templat Pod di DaemonSet harus
|
||||
menspesifikasikan label yang sesuai (lihat [selektor Pod](#selektor-pod)).
|
||||
|
||||
Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
|
||||
Templat Pod di DaemonSet harus memiliki [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
|
||||
yang bernilai `Always`, atau tidak dispesifikasikan, sehingga _default_ menjadi `Always`.
|
||||
DaemonSet dengan nilai `Always` membuat Pod akan selalu di-_restart_ saat kontainer
|
||||
keluar/berhenti atau terjadi _crash_.
|
||||
@@ -77,7 +77,7 @@ Mengubah selektor Pod dapat menyebabkan Pod _orphan_ yang tidak disengaja, dan m
|
||||
|
||||
Objek `.spec.selector` memiliki dua _field_:
|
||||
|
||||
* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
|
||||
* `matchLabels` - bekerja seperti `.spec.selector` pada [ReplicationController](/id/docs/concepts/workloads/controllers/replicationcontroller/).
|
||||
* `matchExpressions` - bisa digunakan untuk membuat selektor yang lebih canggih
|
||||
dengan mendefinisikan _key_, daftar _value_ dan operator yang menyatakan
|
||||
hubungan antara _key_ dan _value_.
|
||||
@@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_.
|
||||
|
||||
Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan
|
||||
membuat Pod pada Node yang cocok dengan [selektor
|
||||
Node](/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
|
||||
maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/docs/concepts/configuration/assign-pod-node/).
|
||||
Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`,
|
||||
maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/).
|
||||
Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan
|
||||
membuat Pod pada semua Node.
|
||||
|
||||
@@ -116,7 +116,7 @@ mendatangkan masalah-masalah berikut:
|
||||
* Inkonsistensi perilaku Pod: Pod normal yang menunggu dijadwalkan akan dibuat
|
||||
dalam keadaan `Pending`, tapi Pod DaemonSet tidak seperti itu. Ini
|
||||
membingungkan untuk pengguna.
|
||||
* [Pod preemption](/docs/concepts/configuration/pod-priority-preemption/)
|
||||
* [Pod preemption](/id/docs/concepts/configuration/pod-priority-preemption/)
|
||||
ditangani oleh _default scheduler_. Ketika _preemption_ dinyalakan,
|
||||
_controller_ DaemonSet akan membuat keputusan penjadwalan tanpa
|
||||
memperhitungkan prioritas Pod dan _preemption_.
|
||||
@@ -148,7 +148,7 @@ mengabaikan Node `unschedulable` ketika menjadwalkan Pod DaemonSet.
|
||||
### _Taint_ dan _Toleration_
|
||||
|
||||
Meskipun Pod Daemon menghormati
|
||||
[taint dan toleration](/docs/concepts/configuration/taint-and-toleration),
|
||||
[taint dan toleration](/id/docs/concepts/configuration/taint-and-toleration),
|
||||
_toleration_ berikut ini akan otomatis ditambahkan ke Pod DaemonSet sesuai
|
||||
dengan fitur yang bersangkutan.
|
||||
|
||||
@@ -170,7 +170,7 @@ Beberapa pola yang mungkin digunakan untuk berkomunikasi dengan Pod dalam Daemon
|
||||
- **Push**: Pod dalam DaemonSet diatur untuk mengirim pembaruan status ke servis lain,
|
||||
contohnya _stats database_. Pod ini tidak memiliki klien.
|
||||
- **IP Node dan Konvensi Port**: Pod dalam DaemonSet dapat menggunakan `hostPort`, sehingga Pod dapat diakses menggunakan IP Node. Klien tahu daftar IP Node dengan suatu cara, dan tahu port berdasarkan konvensi.
|
||||
- **DNS**: Buat [headless service](/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
|
||||
- **DNS**: Buat [headless service](/id/docs/concepts/services-networking/service/#headless-services) dengan Pod selektor yang sama,
|
||||
dan temukan DaemonSet menggunakan _resource_ `endpoints` atau mengambil beberapa A _record_ dari DNS.
|
||||
- **Service**: Buat Servis dengan Pod selektor yang sama, dan gunakan Servis untuk mengakses _daemon_ pada
|
||||
Node random. (Tidak ada cara mengakses spesifik Node)
|
||||
@@ -223,7 +223,7 @@ _bootstrapping_ klaster.
|
||||
|
||||
### Deployment
|
||||
|
||||
DaemonSet mirip dengan [Deployment](/docs/concepts/workloads/controllers/deployment/) sebab mereka
|
||||
DaemonSet mirip dengan [Deployment](/id/docs/concepts/workloads/controllers/deployment/) sebab mereka
|
||||
sama-sama membuat Pod, dan Pod yang mereka buat punya proses yang seharusnya tidak berhenti (e.g. peladen web,
|
||||
peladen penyimpanan)
|
||||
|
||||
|
||||
@@ -119,14 +119,14 @@ Sebuah Job juga membutuhkan sebuah [bagian `.spec`](https://git.k8s.io/community
|
||||
|
||||
_Field_ `.spec.template` merupakan satu-satunya _field_ wajib pada `.spec`.
|
||||
|
||||
_Field_ `.spec.template` merupakan sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
|
||||
_Field_ `.spec.template` merupakan sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). _Field_ ini memiliki skema yang sama dengan yang ada pada [Pod](/docs/user-guide/pods),
|
||||
kecuali _field_ ini bersifat _nested_ dan tidak memiliki _field_ `apiVersion` atau _field_ `kind`.
|
||||
|
||||
Sebagai tambahan dari _field_ wajib pada sebuah Job, sebuah tempat pod pada Job
|
||||
haruslah menspesifikasikan label yang sesuai (perhatikan [selektor pod](#pod-selektor))
|
||||
dan sebuah mekanisme _restart_ yang sesuai.
|
||||
|
||||
Hanya sebuah [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
|
||||
Hanya sebuah [`RestartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) yang sesuai dengan `Never` atau `OnFailure` yang bersifat valid.
|
||||
|
||||
### Selektor Pod
|
||||
|
||||
@@ -194,7 +194,7 @@ Jika hal ini terjadi, dan `.spec.template.spec.restartPolicy = "OnFailure"`, mak
|
||||
akan tetap ada di dalam node, tetapi Container tersebut akan dijalankan kembali. Dengan demikian,
|
||||
program kamu harus dapat mengatasi kasus dimana program tersebut di-_restart_ secara lokal, atau jika
|
||||
tidak maka spesifikasikan `.spec.template.spec.restartPolicy = "Never"`. Perhatikan
|
||||
[_lifecycle_ pod](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
|
||||
[_lifecycle_ pod](/id/docs/concepts/workloads/pods/pod-lifecycle/#example-states) untuk informasi lebih lanjut mengenai `restartPolicy`.
|
||||
|
||||
Sebuah Pod juga dapat gagal secara menyeluruh, untuk beberapa alasan yang mungkin, misalnya saja,
|
||||
ketika Pod tersebut dipindahkan dari Node (ketika Node diperbarui, di-_restart_, dihapus, dsb.), atau
|
||||
@@ -288,7 +288,7 @@ Pastikan kamu telah menspesifikasikan nilai tersebut pada level yang dibutuhkan.
|
||||
Job yang sudah selesai biasanya tidak lagi dibutuhkan di dalam sistem. Tetap menjaga keberadaan
|
||||
objek-objek tersebut di dalam sistem akan memberikan tekanan tambahan pada API server. Jika sebuah Job
|
||||
yang diatur secara langsung oleh _controller_ dengan level yang lebih tinggi, seperti
|
||||
[CronJob](/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
|
||||
[CronJob](/id/docs/concepts/workloads/controllers/cron-jobs/), maka Job ini dapat
|
||||
di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesifikasikan.
|
||||
|
||||
### Mekanisme TTL untuk Job yang Telah Selesai Dijalankan
|
||||
@@ -298,7 +298,7 @@ di-_clean up_ oleh CronJob berdasarkan _policy_ berbasis kapasitas yang dispesif
|
||||
Salah satu cara untuk melakukan _clean up_ Job yang telah selesai dijalankan
|
||||
(baik dengan status `Complete` atau `Failed`) secara otomatis adalah dengan
|
||||
menerapkan mekanisme TTL yang disediakan oleh
|
||||
[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
|
||||
[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
|
||||
sumber daya yang telah selesai digunakan, dengan cara menspesifikasikan
|
||||
_field_ `.spec.ttlSecondsAfterFinished` dari Job tersebut.
|
||||
|
||||
@@ -334,7 +334,7 @@ maka Job ini tidak akan dihapus oleh _controller_ TTL setelah Job ini selesai di
|
||||
|
||||
Perhatikan bahwa mekanisme TTL ini merupakan fitur alpha, dengan gerbang fitur `TTLAfterFinished`.
|
||||
Untuk informasi lebih lanjut, kamu dapat membaca dokumentasi untuk
|
||||
[_controller_ TTL](/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
|
||||
[_controller_ TTL](/id/docs/concepts/workloads/controllers/ttlafterfinished/) untuk
|
||||
sumber daya yang telah selesai dijalankan.
|
||||
|
||||
## Pola Job
|
||||
@@ -478,7 +478,7 @@ Job merupakan komplemen dari [Replication Controller](/docs/user-guide/replicati
|
||||
Sebuah Replication Controller mengatur Pod yang diharapkan untuk tidak dihentikan (misalnya, _web server_), dan sebuah Job
|
||||
mengatur Pod yang diharapkan untuk berhenti (misalnya, _batch task_).
|
||||
|
||||
Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
|
||||
Seperti yang sudah dibahas pada [_Lifecycle_ Pod](/id/docs/concepts/workloads/pods/pod-lifecycle/), `Job` *hanya* pantas
|
||||
digunakan untuk Pod dengan `RestartPolicy` yang sama dengan `OnFailure` atau `Never`.
|
||||
(Perhatikan bahwa: Jika `RestartPolicy` tidak dispesifikasikan, nilai defaultnya adalah `Always`.)
|
||||
|
||||
@@ -499,7 +499,7 @@ dari sebuah Job, tetapi kontrol secara mutlak atas Pod yang dibuat serta tugas y
|
||||
|
||||
## CronJob {#cron-jobs}
|
||||
|
||||
Kamu dapat menggunakan [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
|
||||
Kamu dapat menggunakan [`CronJob`](/id/docs/concepts/workloads/controllers/cron-jobs/) untuk membuat Job yang akan
|
||||
dijalankan pada waktu/tanggal yang spesifik, mirip dengan perangkat lunak `cron` yang ada pada Unix.
|
||||
|
||||
|
||||
|
||||
@@ -197,7 +197,7 @@ Untuk _field_ [_restart policy_](/docs/concepts/workloads/Pods/pod-lifecycle/#re
|
||||
|
||||
### Selektor Pod
|
||||
|
||||
_Field_ `.spec.selector` adalah sebuah [selektor labe](/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
|
||||
_Field_ `.spec.selector` adalah sebuah [selektor labe](/id/docs/concepts/overview/working-with-objects/labels/). Seperti yang telah dibahas [sebelumnya](#how-a-replicaset-works), _field_ ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh `frontend.yaml`, selektornya adalah:
|
||||
```shell
|
||||
matchLabels:
|
||||
tier: frontend
|
||||
@@ -219,7 +219,7 @@ Jika nilai `.spec.replicas` tidak ditentukan maka akan diatur ke nilai _default_
|
||||
|
||||
### Menghapus ReplicaSet dan Pod-nya
|
||||
|
||||
Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
|
||||
Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). [_Garbage collector_](/id/docs/concepts/workloads/controllers/garbage-collection/) secara otomatis akan menghapus semua Pod dependen secara _default_.
|
||||
|
||||
Ketika menggunakan REST API atau _library_ `client-go`, kamu harus mengatur nilai `propagationPolicy` menjadi `Background` atau `Foreground` pada opsi -d.
|
||||
Sebagai contoh:
|
||||
@@ -243,7 +243,7 @@ curl -X DELETE 'localhost:8080/apis/extensions/v1beta1/namespaces/default/repli
|
||||
```
|
||||
|
||||
Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama _field_ `.spec.selector` yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru.
|
||||
Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
|
||||
Untuk memperbarui Pod dengan _spec_ baru dapat menggunakan [Deployment](/id/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) karena ReplicaSet tidak mendukung pembaruan secara langsung.
|
||||
|
||||
### Mengisolasi Pod dari ReplicaSet
|
||||
|
||||
@@ -275,7 +275,7 @@ kubectl autoscale rs frontend --max=10
|
||||
|
||||
### Deployment (direkomendasikan)
|
||||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
|
||||
[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui _rolling update_ deklaratif dan _server-side_.
|
||||
Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri.
|
||||
Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet.
|
||||
|
||||
@@ -289,9 +289,9 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) alih-al
|
||||
|
||||
### DaemonSet
|
||||
|
||||
Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
|
||||
Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti _monitoring_ mesin atau _logging_ mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-_reboot_ atau dimatikan.
|
||||
|
||||
### ReplicationController
|
||||
|
||||
ReplicaSet adalah suksesor dari [_ReplicationControllers_](/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
|
||||
ReplicaSet adalah suksesor dari [_ReplicationControllers_](/id/docs/concepts/workloads/controllers/replicationcontroller/). Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor _set-based_ seperti yang dijelaskan pada [panduan penggunaan label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ weight: 20
|
||||
<!-- overview -->
|
||||
|
||||
{{< note >}}
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
|
||||
[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) yang mengonfigurasi [`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.
|
||||
{{< /note >}}
|
||||
|
||||
Sebuah _ReplicationController_ memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.
|
||||
@@ -101,7 +101,7 @@ Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan y
|
||||
|
||||
Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan _field_ `apiVersion`, `kind`, dan `metadata`.
|
||||
|
||||
Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/docs/concepts/overview/working-with-objects/object-management/).
|
||||
Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat [pengaturan objek](/id/docs/concepts/overview/working-with-objects/object-management/).
|
||||
|
||||
Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
|
||||
|
||||
@@ -109,11 +109,11 @@ Sebuah ReplicationController juga membutuhkan [bagian `.spec`](https://git.k8s.i
|
||||
|
||||
`.spec.template` adalah satu-satunya _field_ yang diwajibkan pada `.spec`.
|
||||
|
||||
`.spec.template` adalah sebuah [templat Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
|
||||
`.spec.template` adalah sebuah [templat Pod](/id/docs/concepts/workloads/pods/pod-overview/#pod-templates). Ia memiliki skema yang sama persis dengan sebuah [Pod](/id/docs/concepts/workloads/pods/pod/), namun dapat berbentuk _nested_ dan tidak memiliki _field_ `apiVersion` ataupun `kind`.
|
||||
|
||||
Selain _field-field_ yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat [selektor pod](#selektor-pod).
|
||||
|
||||
Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
|
||||
Nilai yang diperbolehkan untuk [`.spec.template.spec.restartPolicy`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) hanyalah `Always`, yaitu nilai bawaan jika tidak ditentukan.
|
||||
|
||||
Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya [Kubelet](/docs/admin/kubelet/) atau Docker.
|
||||
|
||||
@@ -123,7 +123,7 @@ ReplicationController itu sendiri dapat memiliki label (`.metadata.labels`). Bia
|
||||
|
||||
### Selektor Pod
|
||||
|
||||
_Field_ `.spec.selector` adalah sebuah [selektor label](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
|
||||
_Field_ `.spec.selector` adalah sebuah [selektor label](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors). Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.
|
||||
|
||||
Jika ditentukan, `.spec.template.metadata.labels` harus memiliki nilai yang sama dengan `.spec.selector`, atau akan ditolak oleh API. Jika `.spec.selector` tidak ditentukan, maka akan menggunakan nilai bawaan yaitu `.spec.template.metadata.labels`.
|
||||
|
||||
@@ -216,13 +216,13 @@ ReplicationController adalah sebuah sumber daya _top-level_ pada REST API Kubern
|
||||
|
||||
### ReplicaSet
|
||||
|
||||
[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
|
||||
[`ReplicaSet`](/id/docs/concepts/workloads/controllers/replicaset/) adalah kelanjutan dari ReplicationController yang mendukung selektor [selektor label _set-based_](/id/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) yang baru. Umumnya digunakan oleh [`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod.
|
||||
Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.
|
||||
|
||||
|
||||
### Deployment (Direkomendasikan)
|
||||
|
||||
[`Deployment`](/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
|
||||
[`Deployment`](/id/docs/concepts/workloads/controllers/deployment/) adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja `kubectl rolling-update`. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti `kubectl rolling-update`, Deployment memiliki sifat deklaratif, _server-side_, dan memiliki beberapa fitur tambahan lainnya.
|
||||
|
||||
### Pod sederhana
|
||||
|
||||
@@ -234,7 +234,7 @@ Gunakan [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) sebagai
|
||||
|
||||
### DaemonSet
|
||||
|
||||
Gunakan [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
|
||||
Gunakan [`DaemonSet`](/id/docs/concepts/workloads/controllers/daemonset/) sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.
|
||||
|
||||
## Informasi lanjutan
|
||||
|
||||
|
||||
@@ -31,8 +31,8 @@ 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.
|
||||
replika _stateless_. _Controller_ seperti [Deployment](/id/docs/concepts/workloads/controllers/deployment/) atau
|
||||
[ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) akan lebih sesuai dengan kebutuhan kamu.
|
||||
|
||||
## Keterbatasan
|
||||
|
||||
@@ -40,7 +40,7 @@ replika _stateless_. _Controller_ seperti [Deployment](/docs/concepts/workloads
|
||||
pada Kubernetes rilis sebelum versi 1.5.
|
||||
* 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.
|
||||
* 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 saat ini membutuhkan sebuah [Headless Service](/id/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,
|
||||
@@ -52,7 +52,7 @@ 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 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.
|
||||
* _Field_ `volumeClaimTemplates` akan menyediakan penyimpanan stabil menggunakan [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) yang di-_provision_ oleh sebuah Provisioner PersistentVolume.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -124,7 +124,7 @@ Setiap Pod di dalam StatefulSet memiliki _hostname_ diturunkan dari nama Satetul
|
||||
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)
|
||||
Sebuah StatefulSet dapat menggunakan sebuah [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
|
||||
untuk mengontrol domain dari Pod yang ada. Domain yang diatur oleh Service ini memiliki format:
|
||||
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
|
||||
domain klaster.
|
||||
@@ -133,7 +133,7 @@ Seiring dibuatnya setiap Pod, Pod tersebut akan memiliki subdomain DNS-nya sendi
|
||||
_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)
|
||||
untuk membuat [Service Headless](/id/docs/concepts/services-networking/service/#headless-services)
|
||||
yang bertanggung jawab terhadap identitas jaringan pada Pod.
|
||||
|
||||
Di sini terdapat beberapa contoh penggunaan Domain Klaster, nama Service,
|
||||
@@ -147,12 +147,12 @@ Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet
|
||||
|
||||
{{< note >}}
|
||||
Domain klaster akan diatur menjadi `cluster.local` kecuali
|
||||
[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/).
|
||||
[nilainya dikonfigurasi](/id/docs/concepts/services-networking/dns-pod-service/).
|
||||
{{< /note >}}
|
||||
|
||||
### Penyimpanan Stabil
|
||||
|
||||
Kubernetes membuat sebuah [PersistentVolume](/docs/concepts/storage/persistent-volumes/) untuk setiap
|
||||
Kubernetes membuat sebuah [PersistentVolume](/id/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 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_
|
||||
|
||||
@@ -10,7 +10,7 @@ weight: 65
|
||||
|
||||
Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu
|
||||
objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani
|
||||
[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/),
|
||||
[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/),
|
||||
dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan
|
||||
misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya.
|
||||
|
||||
@@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster
|
||||
dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik
|
||||
`Complete` atau `Failed`) secara otomatis dengan menentukan _field_
|
||||
`.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di
|
||||
[contoh](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
|
||||
[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
|
||||
Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila
|
||||
TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini
|
||||
dilakukan secara berantai, dimana sumber daya lain yang
|
||||
@@ -83,7 +83,7 @@ Perhatikan bahwa hal ini dapat terjadi apabila TTL diaktifkan dengan nilai selai
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[Membersikan Job secara Otomatis](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
|
||||
[Membersikan Job secara Otomatis](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
|
||||
|
||||
[Dokumentasi Rancangan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user