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

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

Browse Source
This commit is contained in:
irvifa
2019-12-16 20:11:37 +07:00
committed by Kubernetes Prow Robot
parent a7f6a78d55
commit 39fe327423
65 changed files with 459 additions and 458 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/id/docs/concepts/workloads/controllers/garbage-collection.md
+2 -2
View File
@@ -50,8 +50,8 @@ metadata:
```
{{< note >}}
Referensi pemilik lintas _namespace_ tidak diperbolehkan oleh desain. Artinya:
1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan kluster.
2) Dependen dengan cakupan kluster hanya bisa menspesifikasikan pemilik yang memiliki cakupan kluster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan kluster.
1) Dependen dengan cakupan _namespace_ hanya bisa menspesifikasikan pemilik jika berada di _namespace_ yang sama, dan pemilik memiliki cakupan klaster.
2) Dependen dengan cakupan klaster hanya bisa menspesifikasikan pemilik yang memiliki cakupan klaster, tetapi tidak berlaku untuk pemilik yang memiliki cakupan klaster.
{{< /note >}}
## Mengontrol bagaimana _garbage collector_ menghapus dependen
content/id/docs/concepts/workloads/controllers/replicaset.md
+2 -2
View File
@@ -31,7 +31,7 @@ Hal ini berarti kamu boleh jadi tidak akan membutuhkan manipulasi objek ReplicaS
{{< codenew file="controllers/frontend.yaml" >}}
Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke kluster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola.
Menyimpan _manifest_ ini dalam `frontend.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola.
```shell
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml
@@ -259,7 +259,7 @@ Pengaturan jumlah Pod pada ReplicaSet juga dapat dilakukan mengunakan [Horizonta
{{< codenew file="controllers/hpa-rs.yaml" >}}
Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke kluster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi.
Menyimpan _manifest_ ini dalam `hpa-rs.yaml` dan mengirimkannya ke klaster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi.
```shell
kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
content/id/docs/concepts/workloads/controllers/statefulset.md
+4 -4
View File
@@ -127,7 +127,7 @@ 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 diatur oleh Service ini memiliki format:
`$(service name).$(namespace).svc.cluster.local`, dimana "cluster.local" merupakan
domain kluster.
domain klaster.
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
_field_ `serviceName` pada StatefulSet.
@@ -136,17 +136,17 @@ Seperti sudah disebutkan di dalam bagian [keterbatasan](#keterbatasan), kamulah
untuk membuat [Service Headless](/docs/concepts/services-networking/service/#headless-services)
yang bertanggung jawab terhadap identitas jaringan pada Pod.
Di sini terdapat beberapa contoh penggunaan Domain Kluster, nama Service,
Di sini terdapat beberapa contoh penggunaan Domain Klaster, 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 |
Domain Klaster | Service (ns/nama) | StatefulSet (ns/nama) | Domain StatefulSet | DNS Pod | Hostname Pod |
-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
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 diatur menjadi `cluster.local` kecuali
Domain klaster akan diatur menjadi `cluster.local` kecuali
[nilainya dikonfigurasi](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
{{< /note >}}
content/id/docs/concepts/workloads/controllers/ttlafterfinished.md
+3 -3
View File
@@ -28,7 +28,7 @@ Peringatan Fitur Alpha: fitur ini tergolong datam fitur alpha dan dapat diaktifk
## Pengendali TTL
Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator kluster
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
@@ -49,7 +49,7 @@ Waktu TTL dalam detik dapat diatur kapan pun. Terdapat beberapa contoh untuk men
* Gunakan sebuah
[mengubah (_mutating_) _admission)](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
untuk mengaktifkan _field_ ini secara dinamis pada saat pembuatan sumber daya.
Administrator kluster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada
Administrator klaster dapat menggunakan hal ini untuk menjamin kebijakan (_policy_) TTL pada
sumber daya yang telah selesai digunakan.
* Gunakan sebuah
[mengubah (_mutating_) _admission](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
@@ -70,7 +70,7 @@ menjamin Job tersebut akan tetap ada, meskipun nilai TTL berhasil diubah.
Karena pengendali TTL menggunakan cap waktu (_timestamp_) yang disimpan di sumber daya
Kubernetes untuk menentukan apakah TTL sudah habis atau belum, fitur ini tidak sensitif
terhadap _time skew_ yang ada pada kluster dan bisa saja menghapus objek pada waktu yang salah
terhadap _time skew_ yang ada pada klaster dan bisa saja menghapus objek pada waktu yang salah
bagi objek tersebut akibat adanya _time skew_.
Pada Kubernetes, NTP haruslah dilakukan pada semua node untuk mecegah adanya _time skew_
content/id/docs/concepts/workloads/pods/disruptions.md
+34 -34
View File
@@ -7,7 +7,7 @@ weight: 60
{{% capture overview %}}
Petunjuk ini ditujukan pada pemilik aplikasi yang meninginkan aplikasinya memiliki ketersediaan yang tinggi, sehingga butuh untuk mengerti jenis-jenis Disrupsi yang dapat terjadi pada Pod-pod.
Petunjuk ini juga ditujukan pada administrator kluster yang ingin melakukan berbagai tindakan otomasi pada kluster, seperti pembaruan dan _autoscaling_ kluster.
Petunjuk ini juga ditujukan pada administrator klaster yang ingin melakukan berbagai tindakan otomasi pada klaster, seperti pembaruan dan _autoscaling_ klaster.
{{% /capture %}}
@@ -20,29 +20,29 @@ Pod-pod tidak akan terhapus sampai sesuatu (orang ataupun _pengendali_) menghanc
Kita menyebut kasus-kasus yang tidak dapat dihindari sebagai **disrupsi yang tidak disengaja** terhadap aplikasi. Beberapa contohnya adalah sebagai berikut:
- Kesalahan perangkat keras pada mesin yang menjalankan Node
- Administrator kluster menghapus _virtual machine_ secara tidak sengaja
- Administrator klaster menghapus _virtual machine_ secara tidak sengaja
- Kesalahan pada penyedia layanan _cloud_ yang mengakibatkan terhapusnya _virtual machine_
- Sebuah _kernel panic_
- Node menghilang dari kluster karena partisi jaringan kluster
- Node menghilang dari klaster karena partisi jaringan klaster
- Pod mengalami _eviction_ karena Node [kehabisan sumber daya](/docs/tasks/administer-cluster/out-of-resource)
Dengan pengecualian pada kondisi kehabisan sumber daya, kondisi-kondisi tersebut pada umumnya diketahui oleh kebanyakan pengguna karena kondisi-kondisi tersebut tidak spesifik pada Kubernetes saja.
Kita menyebut kasus-kasus lainnya sebagai **disrupsi yang disengaja**. Hal ini termasuk tindakan yang dilakukan oleh pemilik aplikasi atau yang dilakukan oleh administrator kluster. Pemilik aplikasi umumnya melakukan hal-hal berikut:
Kita menyebut kasus-kasus lainnya sebagai **disrupsi yang disengaja**. Hal ini termasuk tindakan yang dilakukan oleh pemilik aplikasi atau yang dilakukan oleh administrator klaster. Pemilik aplikasi umumnya melakukan hal-hal berikut:
- Menghapus Deployment atau pengendali yang mengatur Pod
- Memperbarui templat Pod yang menyebabkan pengulangan kembali/_restart_
- Menghapus Pod secara langsung
Administrator kluster umumnya melakukan hal-hal berikut:
Administrator klaster umumnya melakukan hal-hal berikut:
- [Melakukan _drain_ terhadap Node](/docs/tasks/administer-cluster/safely-drain-node/) untuk perbaikan atau pembaruan.
- Melakukan _drain_ terhadap sebuah node dari kluster untuk memperkecil ukuran kluster (untuk lebih lanjutnya, pelajari [_Autoscaling_ kluster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)).
- Melakukan _drain_ terhadap sebuah node dari klaster untuk memperkecil ukuran klaster (untuk lebih lanjutnya, pelajari [_Autoscaling_ klaster](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)).
- Menghapus sebuah Pod dari node untuk memuat Pod lain ke node tersebut.
Tindakan-tindakan tersebut dapat dilakukan secara langsung oleh administrator kluster, atau oleh alat otomasi yang dijalankan oleh administrator kluster, atau oleh penyedia layanan Kubernetes kamu.
Tindakan-tindakan tersebut dapat dilakukan secara langsung oleh administrator klaster, atau oleh alat otomasi yang dijalankan oleh administrator klaster, atau oleh penyedia layanan Kubernetes kamu.
Tanyakan administrator kluster atau penyedia layanan _cloud_ kamu, atau lihatlah dokumentasi penyedia layanan Kubernetes kamu untuk mengetahui bila ada sumber-sumber yang berpotensi mengakibatkan disrupsi yang disengaja yang ada pada klustermu. Jika tidak ada, kamu bisa melewatkan pembuatan _PodDisruptionBudget_
Tanyakan administrator klaster atau penyedia layanan _cloud_ kamu, atau lihatlah dokumentasi penyedia layanan Kubernetes kamu untuk mengetahui bila ada sumber-sumber yang berpotensi mengakibatkan disrupsi yang disengaja yang ada pada klastermu. Jika tidak ada, kamu bisa melewatkan pembuatan _PodDisruptionBudget_
{{< caution >}}
Tidak semua disrupsi yang disengaja dibatasi oleh Pod Disruption Budget. Contohnya, menghapus Deployment atau Pod dapat mengabaikan PodDisruptionBudget.
@@ -52,13 +52,13 @@ Tidak semua disrupsi yang disengaja dibatasi oleh Pod Disruption Budget. Contohn
Berikut beberapa cara untuk mengatasi disrupsi yang tidak disengaja:
- Pastikan Pod-pod kamu [merinci permintaan sumber daya kluster](/docs/tasks/configure-Pod-container/assign-cpu-ram-container) yang dibutuhkan.
- Pastikan Pod-pod kamu [merinci permintaan sumber daya klaster](/docs/tasks/configure-Pod-container/assign-cpu-ram-container) yang dibutuhkan.
- Replikasikan aplikasimu jika membutuhkan ketersediaan yang tinggi. (Pelajari tentang menjalankan aplikasi
[_stateless_](/docs/tasks/run-application/run-stateless-application-deployment/) dan [_stateful_](/docs/tasks/run-application/run-replicated-stateful-application/)).
- Untuk mencapai ketersediaan yang bahkan lebih tinggi lagi saat mereplikasikan aplikasi, sebarkanlah Pod-pod kamu di rak-rak pada _data center_ (menggunakan [_anti-affinity_](/docs/user-guide/node-selection/#inter-Pod-affinity-and-anti-affinity-beta-feature)) atau di seluruh zona (jika kamu menggunakan [kluster pada beberapa zona](/docs/setup/multiple-zones)).
- Untuk mencapai ketersediaan yang bahkan lebih tinggi lagi saat mereplikasikan aplikasi, sebarkanlah Pod-pod kamu di rak-rak pada _data center_ (menggunakan [_anti-affinity_](/docs/user-guide/node-selection/#inter-Pod-affinity-and-anti-affinity-beta-feature)) atau di seluruh zona (jika kamu menggunakan [klaster pada beberapa zona](/docs/setup/multiple-zones)).
Frekuensi disrupsi yang disengaja dapat berubah-ubah. Pada kluster Kubernetes yang dasar, tidak ada disrupsi yang disengaja sama sekali. Tetapi, administrator kluster atau penyedia layanan Kubernetes kamu mungkin saja menjalankan beberapa servis tambahan yang dapat mengakibatkan disrupsi yang disengaja. Misalnya, memperbarui perangkat lunak pada node yang dapat mengakibatkan disrupsi yang disengaja. Selain itu, beberapa implementasi _autoscaling_ kluster (atau node) dapat mengakibatkan disrupsi yang disengaja untuk merapikan dan memadatkan node-node pada kluster.
Administrator kluster atau penyedia layanan Kubernetes kamu perlu mendokumentasikan tingkatan disrupsi yang disengaja, jika ada disrupsi yang telah diperkirakan.
Frekuensi disrupsi yang disengaja dapat berubah-ubah. Pada klaster Kubernetes yang dasar, tidak ada disrupsi yang disengaja sama sekali. Tetapi, administrator klaster atau penyedia layanan Kubernetes kamu mungkin saja menjalankan beberapa servis tambahan yang dapat mengakibatkan disrupsi yang disengaja. Misalnya, memperbarui perangkat lunak pada node yang dapat mengakibatkan disrupsi yang disengaja. Selain itu, beberapa implementasi _autoscaling_ klaster (atau node) dapat mengakibatkan disrupsi yang disengaja untuk merapikan dan memadatkan node-node pada klaster.
Administrator klaster atau penyedia layanan Kubernetes kamu perlu mendokumentasikan tingkatan disrupsi yang disengaja, jika ada disrupsi yang telah diperkirakan.
Kubernetes menawarkan fitur-fitur untuk membantu menjalankan aplikasi-aplikasi dengan ketersediaan tinggi bersamaan dengan seringnya disrupsi yang disengaja, fitur-fitur tersebut dinamai _Disruption Budget_.
@@ -67,9 +67,9 @@ Kubernetes menawarkan fitur-fitur untuk membantu menjalankan aplikasi-aplikasi d
Pemilik aplikasi dapat membuat objek `PodDisruptionBudget` (PDB) untuk setiap aplikasi. Sebuah PDB membatasi jumlah Pod yang boleh mati secara bersamaan pada aplikasi yang direplikasi dikarenakan disrupsi yang disengaja.
Misalnya, sebuah aplikasi yang bekerja secara _quorum_ mau memastikan bahwa jumlah replika yang berjalan tidak jatuh ke bawah yang dibutuhkan untuk membentuk sebuah _quorum_. Contoh lainnya, sebuah _front-end_ web mungkin perlu memastikan bahwa jumlah replika yang melayani trafik tidak pernah turun ke total persentase yang telah ditentukan.
Administrator kluster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah `kubectl drain` dan skrip pembaruan Kubernets-on-GCE (`cluster/gce/upgrade.sh`)
Administrator klaster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah `kubectl drain` dan skrip pembaruan Kubernets-on-GCE (`cluster/gce/upgrade.sh`)
Saat seorang administrator kluster ingin melakukan _drain_ terhadap sebuah node, ia akan menggunakan perintah `kubectl drain`. Alat tersebut mencoba untuk "mengusir" semua Pod di node tersebut. Permintaan untuk mengusir Pod tersebut mungkin ditolak untuk sementara, dan alat tersebut akan mencoba ulang permintaannya secara periodik hingga semua Pod dihapus, atau hingga batas waktu yang ditentukan telah dicapai.
Saat seorang administrator klaster ingin melakukan _drain_ terhadap sebuah node, ia akan menggunakan perintah `kubectl drain`. Alat tersebut mencoba untuk "mengusir" semua Pod di node tersebut. Permintaan untuk mengusir Pod tersebut mungkin ditolak untuk sementara, dan alat tersebut akan mencoba ulang permintaannya secara periodik hingga semua Pod dihapus, atau hingga batas waktu yang ditentukan telah dicapai.
Sebua PDB merinci jumlah replika yang dapat ditoleransi oleh sebuah aplikasi, relatif terhadap berapa banyak yang seharusnya dimiliki oleh aplikasi tersebut. Sebagai contoh, sebuah Deployment yang memiliki rincian `.spec.replicas :5` diharapkan memiliki 5 Pod pada satu waktu. Jika PDB aplikasi tersebut mengizinkan ada 4 replika pada satu waktu, maka Eviction API akan mengizinkan disrupsi yag disengaja sebanyak satu, tapi tidak mengizinkan dua, pada satu waktu.
@@ -85,8 +85,8 @@ Saat sebuah Pod diusir menggunakan _eviction API_, Pod tersebut akan dihapus sec
## Contoh PDB
Kita ambil contoh sebuah kluster dengan 3 node, `node-1` hingga `node-3`.
Kluster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebut awalnya memiliki 3 replika, yang akan kita namai `Pod-a`, `Pod-b`, dan `Pod-c`. Sebuah Pod lain yang tidak bersangkutan dan tidak memiliki PDB, dinamai `Pod-x` juga terlihat. Awalnya, Pod-pod tersebut berada pada node-node sebagai berikut:
Kita ambil contoh sebuah klaster dengan 3 node, `node-1` hingga `node-3`.
Klaster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebut awalnya memiliki 3 replika, yang akan kita namai `Pod-a`, `Pod-b`, dan `Pod-c`. Sebuah Pod lain yang tidak bersangkutan dan tidak memiliki PDB, dinamai `Pod-x` juga terlihat. Awalnya, Pod-pod tersebut berada pada node-node sebagai berikut:
| node-1 | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
@@ -95,7 +95,7 @@ Kluster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebu
3 Pod `Pod-a` hingga `Pod-c` adalah bagian dari sebuah Deployment, dan mereka secara kolektif memiliki sebuah PDB yang mengharuskan ada setidaknya 2 dari 3 Pod untuk tersedia sepanjang waktu.
Sebagai contoh, asumsikan administrator kluster ingin me-_reboot_ ke dalam versi kernel baru untuk memperbaiki kesalahan di dalam kernel lama. Administator kluster pertama-tama mencoba untuk melakukan _drain_ terhadap `node-1` menggunakan perintah `kubectl drain`. Perintah tersebut mencoba untuk mengusir `Pod-a` dan `Pod-x`. Hal ini langsung berhasil. Kedua Pod tersebut masuk ke dalam kondisi `terminating` secara bersamaan. Hal ini mengubah kondisi kluster menjadi sebagai berikut:
Sebagai contoh, asumsikan administrator klaster ingin me-_reboot_ ke dalam versi kernel baru untuk memperbaiki kesalahan di dalam kernel lama. Administator klaster pertama-tama mencoba untuk melakukan _drain_ terhadap `node-1` menggunakan perintah `kubectl drain`. Perintah tersebut mencoba untuk mengusir `Pod-a` dan `Pod-x`. Hal ini langsung berhasil. Kedua Pod tersebut masuk ke dalam kondisi `terminating` secara bersamaan. Hal ini mengubah kondisi klaster menjadi sebagai berikut:
| node-1 _draining_ | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
@@ -106,41 +106,41 @@ Deployment tersebut melihat bahwa salah satu Pod berada dalam kondisi `terminati
(Catatan: untuk sebuah StatefulSet, `Pod-a`, akan dinamai dengan `Pod-1`, harus diterminasi hingga selesai sebelum penggantinya, yang juga dinamai `Pod-1` tetapi memiliki UID yang berbeda, akan dibuat. Selain hal ini, seluruh contoh ini juga berlaku untuk StatefulSet.)
Sekarang, kluster berada pada kondisi berikut:
Sekarang, klaster berada pada kondisi berikut:
| node-1 _draining_ | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| Pod-a _terminating_ | Pod-b _available_ | Pod-c _available_ |
| Pod-x _terminating_ | Pod-d _starting_ | Pod-y |
Pada satu waktu, Pod-pod yang diusir pun selesai diterminasi, dan kondisi kluster menjadi seperti berikut:
Pada satu waktu, Pod-pod yang diusir pun selesai diterminasi, dan kondisi klaster menjadi seperti berikut:
| node-1 _drained_ | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| | Pod-b _available_ | Pod-c _available_ |
| | Pod-d _starting_ | Pod-y |
Pada titik ini, jika seorang administrator kluster yang tidak sabar mencoba untuk melakukan _drain_ terhadap `node-2` atau `node-3`, perintah untuk melakukan _drain_ terhadap node tersebut akan terhalang, karena hanya ada 2 Pod yang tersedia, dan PDB-nya membutuhkan setidaknya ada 2 Pod tersedia. Setelah beberapa waktu, `Pod-d` menjadi tersedia.
Pada titik ini, jika seorang administrator klaster yang tidak sabar mencoba untuk melakukan _drain_ terhadap `node-2` atau `node-3`, perintah untuk melakukan _drain_ terhadap node tersebut akan terhalang, karena hanya ada 2 Pod yang tersedia, dan PDB-nya membutuhkan setidaknya ada 2 Pod tersedia. Setelah beberapa waktu, `Pod-d` menjadi tersedia.
Kondisi kluster menjadi seperti berikut:
Kondisi klaster menjadi seperti berikut:
| node-1 _drained_ | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| | Pod-b _available_ | Pod-c _available_ |
| | Pod-d _available_ | Pod-y |
Sekarang, administrator kluster mencoba untuk melakukan _drain_ terhadap `node-2`. Perintah _drain_ tersebut akan mencoba mengusir Pod-pod tersebut secara berurutan (tidak bersamaan), misalnya `Pod-b` yang pertama dan diikuti dengan `Pod-d`. Perintah tersebut akan berhasil mengusir `Pod-b`. Tetapi, pada saat ia mencoba untuk mengusir `Pod-d`, hal tersebut akan ditolak karena hal tersebut akan mengakibatkan hanya satu Pod yang tersedia untuk Deployment yang bersangkutan.
Sekarang, administrator klaster mencoba untuk melakukan _drain_ terhadap `node-2`. Perintah _drain_ tersebut akan mencoba mengusir Pod-pod tersebut secara berurutan (tidak bersamaan), misalnya `Pod-b` yang pertama dan diikuti dengan `Pod-d`. Perintah tersebut akan berhasil mengusir `Pod-b`. Tetapi, pada saat ia mencoba untuk mengusir `Pod-d`, hal tersebut akan ditolak karena hal tersebut akan mengakibatkan hanya satu Pod yang tersedia untuk Deployment yang bersangkutan.
Deployment tersebut membuat pengganti `Pod-b` yang dinamai `Pod-e`.
Karena tidak ada sumber daya kluster yang cukup untuk mengalokasikan `Pod-e`, proses _drain_ akan kembali terhalang.
Kluster mungkin berada pada kondisi berikut:
Karena tidak ada sumber daya klaster yang cukup untuk mengalokasikan `Pod-e`, proses _drain_ akan kembali terhalang.
Klaster mungkin berada pada kondisi berikut:
| node-1 _drained_ | node-2 | node-3 | _no node_ |
|:--------------------:|:-------------------:|:------------------:|:------------------:|
| | Pod-b _available_ | Pod-c _available_ | Pod-e _pending_ |
| | Pod-d _available_ | Pod-y | |
Pada titik ini, administrator kluster mesti menambah sebuah node untuk kluster agar bisa melanjutkan pembaruan kluster.
Pada titik ini, administrator klaster mesti menambah sebuah node untuk klaster agar bisa melanjutkan pembaruan klaster.
Kamu dapat melihat bagaimana frekuensi disrupsi dapat berubah-ubah pada Kubernetes, tergantung pada:
@@ -148,30 +148,30 @@ Kamu dapat melihat bagaimana frekuensi disrupsi dapat berubah-ubah pada Kubernet
- Berapa lama waktu yang dibutuhkan untuk mematikan sebuah Pod secara _graceful_
- Berapa lama waktu yang dibutuhkan untuk memulai sebuah Pod
- Tipe pengendali
- Kapasitas sumber daya kluster
- Kapasitas sumber daya klaster
## Memisahkan Peran Pemilik Kluster dan Pemilik Aplikasi
## Memisahkan Peran Pemilik Klaster dan Pemilik Aplikasi
Seringkali akan bermanfaat untuk berpikir Administrator Kluster dan Pemilik Aplikasi sebagai peran yang terpisah dan dengan pengetahuan yang terbatas satu sama lainnya. Pemisahan ini dapat dimengerti dalam beberapa skenario berikut:
Seringkali akan bermanfaat untuk berpikir Administrator Klaster dan Pemilik Aplikasi sebagai peran yang terpisah dan dengan pengetahuan yang terbatas satu sama lainnya. Pemisahan ini dapat dimengerti dalam beberapa skenario berikut:
- Saat ada banyak tim aplikasi yang berbagi pakai sebuah kluster Kubernetes, dan ada pembagian peran yang spesifik
- Saat alat atau servis pihak ketiga digunakan untuk melakukan otomasi manajemen kluster.
- Saat ada banyak tim aplikasi yang berbagi pakai sebuah klaster Kubernetes, dan ada pembagian peran yang spesifik
- Saat alat atau servis pihak ketiga digunakan untuk melakukan otomasi manajemen klaster.
PDB mendukung pemisahan peran ini dengan cara menyediakan antarmuka bagi peran-peran tersebut.
Jika kamu tidak memiliki pemisahan peran seperti ini pada organisasimu, kamu mungkin tidak membutuhkan PDB.
## Bagaimana cara melakukan Tindakan Disruptif terhadap Kluster
## Bagaimana cara melakukan Tindakan Disruptif terhadap Klaster
Jika kamu adalah Administrator Kluster, maka kamu mesti melakukan tindakan disruptif pada setiap node di klustermu, seperti melakukan pembaruan perangkat lunak pada node, berikut beberapa opsinya:
Jika kamu adalah Administrator Klaster, maka kamu mesti melakukan tindakan disruptif pada setiap node di klastermu, seperti melakukan pembaruan perangkat lunak pada node, berikut beberapa opsinya:
- Menerima _downtime_ pada saat pembaruan node
- Melakukan _failover_ ke replika lengkap kluster lain.
- Melakukan _failover_ ke replika lengkap klaster lain.
- Tanpa _downtime_, tetapi mungkin lebih mahal, baik ongkos duplikasi node-node dan tenaga yang dibutuhkan untuk melakukan _failover_.
- Membuat aplikasi yang toleran terhadap disrupsi, dan gunakan PDB.
- Tanpa _downtime_.
- Duplikasi sumber daya yang minimal.
- Mengizinkan lebih banyak otomasi administrasi kluster.
- Mengizinkan lebih banyak otomasi administrasi klaster.
- Membuat aplikasi yang toleran terhadap disrupsi agak rumit, tetapi usaha yang dilakukan untuk menoleransi disrupsi yang disengaja kebanyakan beririsan dengan usaha untuk mendukung _autoscaling_ dan menoleransi disrupsi yang tidak disengaja.
{{% /capture %}}
content/id/docs/concepts/workloads/pods/init-containers.md
+1 -1
View File
@@ -267,7 +267,7 @@ Pod dapat diulang kembali, yang berakibat pada diulangnya eksekusi Init Containe
## Dukungan dan kompatibilitas
Sebuah kluster dengan versi Apiserver 1.6.0 ke atas mendukung Init Container melalui kolom `.spec.initContainers`. Versi-versi sebelumnya mendukung Init Container melalui anotasi _alpha_ atau _beta_. Kolom `.spec.initContainers` juga diduplikasikan dalam bentuk anotasi _alpha_ dan _beta_ agar Kubelet versi 1.3.0 ke atas dapat menjalankan Init Container, dan agar Apiserver versi 1.6 dapat dengan aman dikembalikan ke versi 1.5.x tanpa kehilangan fungsionalitas Pod-pod yang telah dibuat sebelumnya.
Sebuah klaster dengan versi Apiserver 1.6.0 ke atas mendukung Init Container melalui kolom `.spec.initContainers`. Versi-versi sebelumnya mendukung Init Container melalui anotasi _alpha_ atau _beta_. Kolom `.spec.initContainers` juga diduplikasikan dalam bentuk anotasi _alpha_ dan _beta_ agar Kubelet versi 1.3.0 ke atas dapat menjalankan Init Container, dan agar Apiserver versi 1.6 dapat dengan aman dikembalikan ke versi 1.5.x tanpa kehilangan fungsionalitas Pod-pod yang telah dibuat sebelumnya.
Pada Apiserver dan Kubelet versi 1.8.0 ke atas, dukungan untuk anotasi _alpha_ dan _beta_ telah dihapus, sehingga dibutuhkan konversi (manual) dari anotasi yang telah kedaluwarsa tersebut ke dalam bentuk kolom `.spec.initContainers`.
content/id/docs/concepts/workloads/pods/pod-lifecycle.md
+1 -1
View File
@@ -246,7 +246,7 @@ Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk mem
pengontrol yang sesuai dan membiarkan ini membuat Pod, daripada membuat Pod sendiri secara langsung.
Karena Pod itu sendiri tidak tahan terhadap gagalnya suatu mesin, namun pengontrol tahan.
Jika node mati atau sambungannya terputus dari kluster, Kubernetes mengatur
Jika node mati atau sambungannya terputus dari klaster, Kubernetes mengatur
`phase` dari semua Pod pada node yang mati untuk menjadi Failed.
## Contoh
content/id/docs/concepts/workloads/pods/pod-overview.md
+5 -5
View File
@@ -15,13 +15,13 @@ Halaman ini menyajikan ikhtisar dari `Pod`, objek terkecil yang dapat di *deploy
{{% capture body %}}
## Memahami Pod
Sebuah *Pod* adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana di dalam objek model Kubernetes yang dapat dibuat dan di *deploy*. Sebuah *Pod* merepresentasikan suatu proses yang berjalan di dalam kluster.
Sebuah *Pod* adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana di dalam objek model Kubernetes yang dapat dibuat dan di *deploy*. Sebuah *Pod* merepresentasikan suatu proses yang berjalan di dalam klaster.
*Pod* membungkus sebuah kontainer (atau, di beberapa kasus, beberapa kontainer), sumber penyimpanan, alamat jaringan *IP* yang unik, dan opsi yang mengatur bagaimana kontainer harus dijalankan. *Pod* merupakan representasi dari unit *deployment*: sebuah *instance* aplikasi di dalam Kubernetes, yang mungkin terdiri dari satu kontainer atau sekumpulan kontainer yang berbagi *resource*.
[Docker](https://www.docker.com) adalah salah satu kontainer *runtime* yang paling umum digunakan di Kubernetes *Pod*, tetapi *Pod* mendukung kontainer *runtime* lainnya.
*Pod* di Kubernetes kluster dapat digunakan dengan dua cara:
*Pod* di Kubernetes klaster dapat digunakan dengan dua cara:
* **Pod menjalankan satu kontainer**. Model satu kontainer per *Pod* adalah model yang umum digunakan di Kubernetes; kamu dapat membayangkan sebuah *Pod* sebagai pembungkus kontainer tersebut, dan Kubernetes tidak mengelola kontainer secara langsung tetapi mengelola *Pod* tersebut.
* **Pod menjalankan beberapa kontainer yang perlu berjalan bersamaan**. Sebuah *Pod* dapat membungkus sebuah aplikasi yang terdiri dari beberapa kontainer yang perlu berbagi *resource*. Kontainer yang ditempatkan di dalam satu *Pod* ini membentuk sebuah layanan. Sebuah kontainer menyajikan berkas dari sumber penyimpanan ke publik, sedangkan kontainer *sidecar* yang lain melakukan pembaharuan terhadap berkas tersebut. *Pod* membungkus semua kontainer dan *resource* penyimpanan sebagai satu kesatuan yang dapat dikelola.
@@ -34,7 +34,7 @@ Sebuah *Pod* adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana
Setiap *Pod* dimaksudkan untuk menjalankan satu *instance* aplikasi. Jika kamu ingin mengembangkan aplikasi secara horizontal (contoh, banyak *instance* sekaligus), kamu dapat menggunakan banyak *Pod*, satu untuk setiap *instance*. Di Kubernetes, konsep ini umumnya disebut dengan replikasi. *Pod* yang direplikasi biasanya dibuat dan dikelola sebagai grup oleh objek abstraksi yang disebut kontroler. Lihat [Pod dan Kontroler](#pod-dan-kontroler) untuk informasi selengkapnya.
### Bagaimana *Pod* mengelola beberapa Kontainer
*Pod* didesain untuk mendukung banyak proses (sebagai kontainer) yang membentuk sebuah layanan. Kontainer di dalam sebuah *Pod* akan otomatis ditempatkan bersama di dalam satu mesin fisik atau mesin *virtual* di dalam kluster. Kontainer tersebut dapat berbagi *resource* dan dependensi, berkomunikasi satu sama lain, dan berkoordinasi kapan dan bagaimana mereka diterminasi.
*Pod* didesain untuk mendukung banyak proses (sebagai kontainer) yang membentuk sebuah layanan. Kontainer di dalam sebuah *Pod* akan otomatis ditempatkan bersama di dalam satu mesin fisik atau mesin *virtual* di dalam klaster. Kontainer tersebut dapat berbagi *resource* dan dependensi, berkomunikasi satu sama lain, dan berkoordinasi kapan dan bagaimana mereka diterminasi.
Perhatikan bahwa mengelompokan kontainer di dalam satu *Pod* merupakan kasus lanjutan. Kamu dapat menggunakan pola ini hanya dalam kasus tertentu. Sebagai contoh, kamu memiliki kontainer yang bertindak sebagai *web server* yang menyajikan berkas dari *resource* penyimpanan bersama, dan kontainer *sidecar* melakukan pembaharuan terhadap berkas tersebut dari sumber lain, seperti dalam diagram *Pod* berikut:
{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
@@ -52,7 +52,7 @@ Setiap *Pod* diberikan sebuah alamat *IP* unik. Setiap kontainer di dalam *Pod*
## Bekerja dengan Pod
Kamu akan jarang membuat *Pod* secara langsung di Kubernetes. Ini karena *Pod* dirancang sebagai entitas sesaat. Saat *Pod* dibuat (baik oleh kamu, atau secara tidak langsung oleh kontroler), *Pod* ditempatkan dan dijalankan di sebuah *Node* di dalam kluster. *Pod* akan tetap di *Node* tersebut sampai proses dihentikan, Objek *Pod* dihapus, *Pod* dihentikan karena kekurangan *resource*, atau *Node* tersebut berhenti berjalan.
Kamu akan jarang membuat *Pod* secara langsung di Kubernetes. Ini karena *Pod* dirancang sebagai entitas sesaat. Saat *Pod* dibuat (baik oleh kamu, atau secara tidak langsung oleh kontroler), *Pod* ditempatkan dan dijalankan di sebuah *Node* di dalam klaster. *Pod* akan tetap di *Node* tersebut sampai proses dihentikan, Objek *Pod* dihapus, *Pod* dihentikan karena kekurangan *resource*, atau *Node* tersebut berhenti berjalan.
{{< note >}}
Tidak perlu bingung untuk membedakan antara menjalankan ulang sebuah kontainer di dalam *Pod* dan menjalankan ulang *Pod*. *Pod* itu sendiri tidak berjalan, tetapi *Pod* adalah *environment* kontainer itu berjalan dan akan tetap ada sampai dihapus.
@@ -62,7 +62,7 @@ Tidak perlu bingung untuk membedakan antara menjalankan ulang sebuah kontainer d
### Pod dan Kontroler
Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replikasi dan menyediakan kemampuan penyembuhan diri sendiri pada lingkup kluster. Sebagai contoh, jika sebuah *Node* gagal, kontroler akan otomatis mengganti *Pod* tersebut dengan menempatkan *Pod* yang identik di *Node* yang lain.
Kontroler dapat membuat dan mengelola banyak *Pod* untuk kamu, menangani replikasi dan menyediakan kemampuan penyembuhan diri sendiri pada lingkup klaster. Sebagai contoh, jika sebuah *Node* gagal, kontroler akan otomatis mengganti *Pod* tersebut dengan menempatkan *Pod* yang identik di *Node* yang lain.
Beberapa contoh kontroler yang berisi satu atau lebih *Pod* meliputi:
content/id/docs/concepts/workloads/pods/pod.md
+4 -3
View File
@@ -161,6 +161,7 @@ bisa memberikan dukungan terhadap Pod yang _stateful_.
Penggunaan API kolektif sebagai _user-facing primitive_ utama adalah hal yang
relatif umum diantara sistem penjadwalan kluster, seperti
[Borg](https://research.google.com/pubs/pub43438.html),
[Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html),
[Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), dan
@@ -172,7 +173,7 @@ Pod diekspose sebagai _primitive_ untuk memfasilitasi hal berikut:
* mendukung operasi pada level Pod tanpa perlu melakukan proksi melalui API pengontrol
* pemisahan antara umur suatu Pod dan pengontrol, seperti misalnya _bootstrapping_.
* pemisahan antara pengontrol dan servis, pengontrol _endpoint_ hanya memperhatikan Pod
* komposisi yang bersih antara fungsionalitas dilevel Kubelet dan kluster. Kubelet
* komposisi yang bersih antara fungsionalitas dilevel Kubelet dan klaster. Kubelet
secara efektif adalah pengontrol Pod.
* aplikasi dengan ketersediaan tinggi, yang akan mengharapkan Pod akan digantikan
sebelum dihentikan dan tentu saja sebelum dihapus, seperti dalam kasus penggusuran
@@ -180,7 +181,7 @@ Pod diekspose sebagai _primitive_ untuk memfasilitasi hal berikut:
## Penghentian Pod
Karena Pod merepresentasikan proses yang berjalan pada mesin didalam kluster, sangat
Karena Pod merepresentasikan proses yang berjalan pada mesin didalam klaster, sangat
penting untuk memperbolehkan proses ini berhenti secara normal ketika sudah tidak
dibutuhkan (dibandingkan dengan dihentikan paksa dengan sinyal KILL dan tidak memiliki
waktu untuk dibersihkan). Pengguna seharusnya dapat meminta untuk menghapus dan tahu
@@ -229,7 +230,7 @@ untuk melakukan penghapusan paksa.
### Penghapusan paksa sebuah Pod
Penghapusan paksa dari sebuah Pod didefinisikan sebagai penghapusan Pod dari _state_
kluster dan etcd secara langsung. Ketika penghapusan paksa dilakukan, API server tidak
klaster dan etcd secara langsung. Ketika penghapusan paksa dilakukan, API server tidak
akan menunggu konfirmasi dari kubelet bahwa Pod sudah dihentikan pada mesin ia berjalan.
Ini menghapus Pod secara langsung dari API, sehingga Pod baru bisa dibuat dengan nama
yang sama. Dalam mesin, Pod yang dihentikan paksa akan tetap diberikan sedikit masa
content/id/docs/concepts/workloads/pods/podpreset.md
+3 -3
View File
@@ -40,9 +40,9 @@ Mungkin akan ada keadaan dimana kamu menginginkan sebuah Pod tidak bisa diubah o
## Mengaktifkan Pod Preset
---
Dalam rangka untuk menggunakan Pod Preset di dalam kluster kamu, kamu harus memastikan hal berikut:
Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus memastikan hal berikut:
1. Kamu telah mengaktifkan tipe API `settings.k8s.io/v1alpha1/podpreset`. Sebagai contoh, ini bisa dilakukan dengan menambahkan `settings.k8s.io/v1alpha1=true` di dalam opsi `--runtime-config` untuk API _server_. Dalam _minikube_ tambahkan argumen berikut `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` saat menginisialisasi kluster.
1. Kamu telah mengaktifkan tipe API `settings.k8s.io/v1alpha1/podpreset`. Sebagai contoh, ini bisa dilakukan dengan menambahkan `settings.k8s.io/v1alpha1=true` di dalam opsi `--runtime-config` untuk API _server_. Dalam _minikube_ tambahkan argumen berikut `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` saat menginisialisasi klaster.
1. Kamu telah mengaktifkan _admission controller_ dari `PodPreset`. Salah satu cara untuk melakukannya adalah dengan menambahkan `PodPreset` di dalam nilai opsi `--enable-admission-plugins` yang dispesifikasikan untuk API _server_. Dalam _minikube_ tambahkan argumen berikut
@@ -50,7 +50,7 @@ Dalam rangka untuk menggunakan Pod Preset di dalam kluster kamu, kamu harus mema
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
saat menginisialisasi kluster.
saat menginisialisasi klaster.
1. Kamu telah membuat objek `PodPreset` pada _namespace_ yang kamu gunakan dengan cara mendefinisikan Pod Preset.
{{% /capture %}}