Kubernetes Prow Robot
GitHub
commit
13a928bef5
|
|
@ -30,7 +30,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
|
|||
1. Hasilkan sertifikat dan kunci _server_.
|
||||
Argumen `--subject-alt-name` digunakan untuk mengatur alamat IP dan nama DNS yang dapat diakses
|
||||
oleh _server_ API. `MASTER_CLUSTER_IP` biasanya merupakan IP pertama dari CIDR _service cluster_
|
||||
yang diset dengan argumen` --service-cluster-ip-range` untuk _server_ API dan
|
||||
yang diset dengan argumen `--service-cluster-ip-range` untuk _server_ API dan
|
||||
komponen manajer pengontrol. Argumen `--days` digunakan untuk mengatur jumlah hari
|
||||
masa berlaku sertifikat.
|
||||
Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai nama
|
||||
|
|
|
|||
|
|
@ -263,7 +263,7 @@ perlu memastikan bahwa tidak ada dua FlowSchema yang memiliki `matchingPrecedenc
|
|||
|
||||
Sebuah FlowSchema dianggap cocok dengan sebuah permintaan yang diberikan jika setidaknya salah satu dari `rules` nya
|
||||
ada yang cocok. Sebuah aturan (_rule_) cocok jika setidaknya satu dari `subject` *dan*
|
||||
ada salah satu dari `resourceRules` atau` nonResourceRules` (tergantung dari apakah permintaan
|
||||
ada salah satu dari `resourceRules` atau `nonResourceRules` (tergantung dari apakah permintaan
|
||||
yang masuk adalah untuk URL sumber daya atau non-sumber daya) yang cocok dengan permintaan tersebut.
|
||||
|
||||
Untuk bagian `name` dalam subjek, dan bagian `verbs`, `apiGroups`, `resources`,
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
|||
|
||||
Jembatan ini dibuat oleh Kubelet (dikontrol oleh _flag_ `--network-plugin=kubenet`) sesuai dengan `.spec.podCIDR` yang dimiliki oleh Node.
|
||||
|
||||
Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan` cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
|
||||
Docker sekarang akan mengalokasikan IP dari blok `cbr-cidr`. Kontainer dapat menjangkau satu sama lain dan Node di atas jembatan `cbr0`. IP-IP tersebut semuanya dapat dirutekan dalam jaringan proyek GCE.
|
||||
|
||||
GCE sendiri tidak tahu apa-apa tentang IP ini, jadi tidak akan NAT untuk lalu lintas internet keluar. Untuk mencapai itu aturan iptables digunakan untuk menyamar (alias SNAT - untuk membuatnya seolah-olah paket berasal dari lalu lintas `Node` itu sendiri) yang terikat untuk IP di luar jaringan proyek GCE (10.0.0.0/8).
|
||||
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ Opsi `show-hidden-metrics-for-version` menerima input versi yang kamu inginkan u
|
|||
|
||||
Opsi tersebut hanya dapat menerima input versi minor sebelumnya sebagai nilai. Semua metrik yang disembunyikan di versi sebelumnya akan dikeluarkan jika admin mengatur versi sebelumnya ke `show-hidden-metrics-for-version`. Versi yang terlalu lama tidak diperbolehkan karena melanggar kebijakan untuk metrik usang.
|
||||
|
||||
Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa` A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:
|
||||
Ambil metrik `A` sebagai contoh, di sini diasumsikan bahwa `A` sudah menjadi usang di versi 1.n. Berdasarkan kebijakan metrik usang, kita dapat mencapai kesimpulan berikut:
|
||||
|
||||
* Pada rilis `1.n`, metrik menjadi usang, dan dapat dikeluarkan secara bawaan.
|
||||
* Pada rilis `1.n+1`, metrik disembunyikan secara bawaan dan dapat dikeluarkan dengan baris perintah `show-hidden-metrics-for-version=1.n`.
|
||||
|
|
@ -155,7 +155,7 @@ kube-scheduler mengidentifikasi [permintaan dan limit](/docs/concepts/configurat
|
|||
- nama dari sumber daya (misalnya, `cpu`)
|
||||
- satuan dari sumber daya jika diketahui (misalnya, `cores`)
|
||||
|
||||
Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan` kube_pod_resource_limit`.
|
||||
Setelah pod selesai (memiliki `restartPolicy` `Never` atau `OnFailure` dan berada dalam fase pod `Succeeded` atau `Failed`, atau telah dihapus dan semua kontainer dalam keadaan Terminated) deret metrik tidak lagi dilaporkan karena penjadwal sekarang sudah dibebaskan untuk menjadwalkan pod lain untuk dijalankan. Metrik yang dibahas pada bagian ini dikenal sebagai `kube_pod_resource_request` dan `kube_pod_resource_limit`.
|
||||
|
||||
Metrik diekspos melalui _endpoint_ HTTP `/metrics/resources` dan memerlukan otorisasi yang sama seperti endpoint `/metrics`
|
||||
pada penjadwal. Kamu harus menggunakan opsi `--show-hidden-metrics-for-version=1.20` untuk mengekspos metrik-metrik stabilitas alfa ini.
|
||||
|
|
|
|||
|
|
@ -46,25 +46,25 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar
|
|||
FOO_SERVICE_PORT=<the port the Service is running on>
|
||||
```
|
||||
|
||||
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh` Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
|
||||
*Ini menunjukan persyaratan pemesanan * - `Service` apa pun yang ingin diakses oleh `Pod` harus dibuat sebelum `Pod` itu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini.
|
||||
|
||||
- Opsional (meskipun sangat disarankan) [cluster add-on](/id/docs/concepts/cluster-administration/addons/) adalah server DNS.
|
||||
Server DNS melihat API Kubernetes untuk `Service` baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semua `Pods` harus dapat melakukan resolusi nama`Service` secara otomatis.
|
||||
|
||||
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <` hostIP`, `hostPort`,` protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan` protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai` hostIP` dan `TCP` sebagai default` protokol`.
|
||||
- Jangan tentukan `hostPort` untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke `hostPort`, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <`hostIP`, `hostPort`, `protokol`> harus unik. Jika Anda tidak menentukan `hostIP` dan `protokol` secara eksplisit, Kubernetes akan menggunakan `0.0.0.0` sebagai `hostIP` dan `TCP` sebagai default `protokol`.
|
||||
|
||||
Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan [apiserver proxy](/id/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) atau [`kubectl port-forward`](/id/docs/tasks/access-application-cluster/port-forward-access-application-cluster/).
|
||||
|
||||
Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan [NodePort](/id/docs/concepts/services-networking/service/#nodeport) Service sebelum beralih ke `hostPort`.
|
||||
|
||||
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti` hostPort`.
|
||||
- Hindari menggunakan `hostNetwork`, untuk alasan yang sama seperti `hostPort`.
|
||||
|
||||
- Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless-
|
||||
services) (yang memiliki `ClusterIP` dari` None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
|
||||
services) (yang memiliki `ClusterIP` dari `None`) untuk Service discovery yang mudah ketika Anda tidak membutuhkan `kube-proxy` load balancing.
|
||||
|
||||
## Menggunakan label
|
||||
|
||||
- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen` phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
|
||||
- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi __semantic attributes__ aplikasi atau Deployment kamu, seperti `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semua `tier: frontend` Pods, atau semua komponen `phase: test` dari `app: myapp`. Lihat [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) aplikasi untuk contoh-contoh pendekatan ini.
|
||||
|
||||
|
||||
Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. [Deployments](/id/docs/concepts/workloads/controllers/deployment/) membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
|
||||
|
|
@ -103,11 +103,11 @@ Semantik caching dari penyedia gambar yang mendasarinya membuat bahkan `imagePul
|
|||
## Menggunakan kubectl
|
||||
|
||||
|
||||
- Gunakan `kubectl apply -f <directory>`. Ini mencari konfigurasi Kubernetes di semua file `.yaml`,` .yml`, dan `.json` di` <directory> `dan meneruskannya ke` apply`.
|
||||
- Gunakan `kubectl apply -f <directory>`. Ini mencari konfigurasi Kubernetes di semua file `.yaml`, `.yml`, dan `.json` di `<directory>` dan meneruskannya ke `apply`.
|
||||
|
||||
- Gunakan label selector untuk operasi `get` dan` delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
- Gunakan label selector untuk operasi `get` dan `delete` alih-alih nama objek tertentu. Lihat bagian di [label selectors](/id/docs/concepts/overview/working-with-objects/labels/#label-selectors) dan [using labels effectively](/id/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively).
|
||||
|
||||
- Gunakan `kubectl run` dan` kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
|
||||
- Gunakan `kubectl run` dan `kubectl expose` untuk dengan cepat membuat Deployment dan Service single-container. Lihat [Use a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) untuk Contoh.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Kubelet memiliki _plugin_ jaringan bawaan tunggal, dan jaringan bawaan umum untu
|
|||
|
||||
## Persyaratan _Plugin_ Jaringan
|
||||
|
||||
Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi ` 1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.
|
||||
Selain menyediakan [antarmuka `NetworkPlugin`](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) untuk mengonfigurasi dan membersihkan jaringan Pod, _plugin_ ini mungkin juga memerlukan dukungan khusus untuk kube-proxy. Proksi _iptables_ jelas tergantung pada _iptables_, dan _plugin_ ini mungkin perlu memastikan bahwa lalu lintas kontainer tersedia untuk _iptables_. Misalnya, jika plugin menghubungkan kontainer ke _bridge_ Linux, _plugin_ harus mengatur nilai sysctl `net/bridge/bridge-nf-call-iptables` menjadi `1` untuk memastikan bahwa proksi _iptables_ berfungsi dengan benar. Jika _plugin_ ini tidak menggunakan _bridge_ Linux (melainkan sesuatu seperti Open vSwitch atau mekanisme lainnya), _plugin_ ini harus memastikan lalu lintas kontainer dialihkan secara tepat untuk proksi.
|
||||
|
||||
Secara bawaan jika tidak ada _plugin_ jaringan Kubelet yang ditentukan, _plugin_ `noop` digunakan, yang menetapkan `net/bridge/bridge-nf-call-iptables=1` untuk memastikan konfigurasi sederhana (seperti Docker dengan sebuah _bridge_) bekerja dengan benar dengan proksi _iptables_.
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ Opsi ini disediakan untuk _plugin_ jaringan; Saat ini **hanya kubenet yang mendu
|
|||
## Ringkasan Penggunaan
|
||||
|
||||
* `--network-plugin=cni` menetapkan bahwa kita menggunakan _plugin_ jaringan `cni` dengan _binary-binary plugin_ CNI aktual yang terletak di `--cni-bin-dir` (nilai bawaannya `/opt/cni/bin`) dan konfigurasi _plugin_ CNI yang terletak di `--cni-conf-dir` (nilai bawaannya `/etc/cni/net.d`).
|
||||
* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan` kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`.
|
||||
* `--network-plugin=kubenet` menentukan bahwa kita menggunakan _plugin_ jaringan `kubenet` dengan `bridge` CNI dan _plugin-plugin_ `host-local` yang terletak di `/opt/cni/bin` atau `cni-bin-dir`.
|
||||
* `--network-plugin-mtu=9001` menentukan MTU yang akan digunakan, saat ini hanya digunakan oleh _plugin_ jaringan `kubenet`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -279,7 +279,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3
|
|||
##### Tidak akan pernah ditempatkan bersamaan dalam node yang sama
|
||||
|
||||
|
||||
Contoh di atas menggunakan aturan `PodAntiAffinity` dengan` topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster redis sehingga tidak ada dua instance terletak pada hos yang sama.
|
||||
Contoh di atas menggunakan aturan `PodAntiAffinity` dengan `topologyKey: "kubernetes.io/hostname"` untuk melakukan deploy klaster redis sehingga tidak ada dua instance terletak pada hos yang sama.
|
||||
Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) untuk contoh dari konfigurasi StatefulSet dengan anti-afinitas untuk ketersediaan tinggi, menggunakan teknik yang sama.
|
||||
|
||||
Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ permintaan terhadap kapasitas. Hal ini memungkinkan pengguna untuk _bin pack_
|
|||
sumber daya tambahan dengan menggunakan parameter yang sesuai untuk meningkatkan
|
||||
pemanfaatan sumber daya yang langka dalam klaster yang besar. Perilaku
|
||||
`RequestedToCapacityRatioResourceAllocation` dari fungsi prioritas dapat
|
||||
dikontrol melalui pilihan konfigurasi yang disebut ` RequestToCapacityRatioArguments`.
|
||||
dikontrol melalui pilihan konfigurasi yang disebut `RequestToCapacityRatioArguments`.
|
||||
Argumen ini terdiri dari dua parameter yaitu `shape` dan `resources`. Shape
|
||||
memungkinkan pengguna untuk menyempurnakan fungsi menjadi yang paling tidak
|
||||
diminta atau paling banyak diminta berdasarkan nilai `utilization` dan `score`.
|
||||
|
|
@ -36,7 +36,7 @@ Sumber daya terdiri dari `name` yang menentukan sumber daya mana yang dipertimba
|
|||
selama penilaian dan `weight` yang menentukan bobot masing-masing sumber daya.
|
||||
|
||||
Di bawah ini adalah contoh konfigurasi yang menetapkan `requestedToCapacityRatioArguments`
|
||||
pada perilaku _bin packing_ untuk sumber daya tambahan` intel.com/foo` dan `intel.com/bar`
|
||||
pada perilaku _bin packing_ untuk sumber daya tambahan `intel.com/foo` dan `intel.com/bar`
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ yang dikonfigurasi untuk Service ini.
|
|||
### Tipe _LoadBalancer_
|
||||
|
||||
Penyedia layanan _cloud_ yang mendukung IPv6 untuk pengaturan beban eksternal,
|
||||
Mengatur bagian `type` menjadi` LoadBalancer` sebagai tambahan terhadap mengatur bagian
|
||||
Mengatur bagian `type` menjadi `LoadBalancer` sebagai tambahan terhadap mengatur bagian
|
||||
`ipFamily` menjadi `IPv6` menyediakan sebuah _cloud load balancer_ untuk Service kamu.
|
||||
|
||||
## Lalu lintas _egress_
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ _availability zone_ yang sama.
|
|||
|
||||
## Pengantar
|
||||
|
||||
Secara bawaan lalu lintas jaringan yang dikirim ke `ClusterIP` atau` NodePort` dari Service
|
||||
Secara bawaan lalu lintas jaringan yang dikirim ke `ClusterIP` atau `NodePort` dari Service
|
||||
dapat dialihkan ke alamat _backend_ untuk Service tersebut. Sejak Kubernetes 1.7
|
||||
dimungkinkan untuk merutekan lalu lintas jaringan "eksternal" ke Pod yang berjalan di
|
||||
Node yang menerima lalu lintas jaringan, tetapi fitur ini tidak didukung untuk `ClusterIP` dari
|
||||
|
|
|
|||
|
|
@ -248,7 +248,7 @@ rules:
|
|||
|
||||
Kamu juga dapat merujuk ke sumber daya dengan nama untuk permintaan tertentu melalui daftar `resourceNames`.
|
||||
Ketika nama dicantumkan, permintaan dapat dibatasi untuk setiap objek sumber daya.
|
||||
Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau` update` pada sebuah
|
||||
Berikut adalah contoh yang membatasi subjeknya hanya untuk melakukan `get` atau `update` pada sebuah
|
||||
{{< glossary_tooltip term_id="ConfigMap" >}} bernama `my-configmap`:
|
||||
|
||||
```yaml
|
||||
|
|
@ -268,7 +268,7 @@ rules:
|
|||
```
|
||||
|
||||
{{< note >}}
|
||||
Kamu tidak dapat membatasi permintaan `create` atau` deletecollection` dengan nama sumber daya. Untuk `create`,
|
||||
Kamu tidak dapat membatasi permintaan `create` atau `deletecollection` dengan nama sumber daya. Untuk `create`,
|
||||
keterbatasan ini dikarenakan nama objek tidak diketahui pada waktu otorisasi.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Representasi bilangan bulat dari bilangan kecil atau besar menggunakan sufiks SI
|
|||
|
||||
Kuantitas adalah representasi dari bilangan kecil atau besar menggunakan notasi bilangan bulat kompak dengan sufiks SI. Bilangan pecahan direpresentasikan dengan satuan mili, sedangkan bilangan besar direpresentasikan dengan satuan kilo, mega, atau giga.
|
||||
|
||||
Misalnya, angka `1,5` direpresentasikan sebagai` 1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
|
||||
Misalnya, angka `1,5` direpresentasikan sebagai `1500m`, sedangkan angka `1000` dapat direpresentasikan sebagai `1k`, dan `1000000` sebagai `1M`. Kamu juga dapat menentukan sufiks notasi biner; angka 2048 dapat ditulis sebagai `2Ki`.
|
||||
|
||||
Satuan desimal yang diterima (pangkat 10) adalah `m` (mili), `k` (kilo, sengaja huruf kecil), `M` (mega), `G` (giga), `T` (tera), `P` (peta), `E` (exa).
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ card:
|
|||
weight: 40
|
||||
---
|
||||
|
||||
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan` kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.
|
||||
<img src="/images/kubeadm-stacked-color.png" align="right" width="150px">Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan `kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes.
|
||||
|
||||
kubeadm melakukan tindakan yang diperlukan untuk membuat klaster minimum yang layak untuk aktif dan berjalan. Secara desain, ini hanya memperdulikan tentang *bootstrap*, bukan tentang mesin *provisioning*. Demikian pula, dengan instalasi berbagai *addon* atau tambahan yang bagus untuk dimiliki, seperti Dasbor Kubernetes, solusi pemantauan, dan tambahan khusus cloud, tidak termasuk dalam cakupan.
|
||||
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ Dalam banyak kasus, IP Node, IP Pod, dan beberapa IP Service pada sebuah klaster
|
|||
Kamu memiliki beberapa opsi untuk menghubungi Node, Pod, dan Service dari luar klaster:
|
||||
|
||||
- Mengakses Service melalui IP publik.
|
||||
- Gunakan Service dengan tipe `NodePort` atau` LoadBalancer` untuk membuat Service dapat dijangkau di luar klaster. Lihat dokumentasi [Service](/docs/user-guide/services) dan perintah [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose).
|
||||
- Gunakan Service dengan tipe `NodePort` atau `LoadBalancer` untuk membuat Service dapat dijangkau di luar klaster. Lihat dokumentasi [Service](/docs/user-guide/services) dan perintah [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose).
|
||||
- Bergantung pada lingkungan klaster kamu, hal ini mungkin hanya mengekspos Service ke jaringan perusahaan kamu, atau mungkin mengeksposnya ke internet. Pikirkan apakah Service yang diekspos aman atau tidak. Apakah layanan di balik Service tersebut melakukan autentikasinya sendiri?
|
||||
- Tempatkan Pod di belakang Service. Untuk mengakses satu Pod tertentu dari sekumpulan replika, misalnya untuk pengawakutuan (_debugging_), letakkan label unik di Pod dan buat Service baru yang memilih label ini.
|
||||
- Pada kebanyakan kasus, pengembang aplikasi tidak perlu langsung mengakses Node melalui IP Node mereka.
|
||||
|
|
|
|||
|
|
@ -268,7 +268,7 @@ status:
|
|||
|
||||
## Contoh: Men-_debug_ Node yang mati/tidak terjangkau (_down/unreachable_)
|
||||
|
||||
Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan` kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
|
||||
Terkadang saat men-_debug_ melihat status sebuah Node akan sangat berguna - misalnya, karena kamu telah melihat perilaku aneh dari sebuah Pod yang sedang berjalan pada Node tersebut, atau untuk mencari tahu mengapa sebuah Pod tidak dapat dijadwalkan ke dalam Node tersebut. Seperti pada Pod, kamu dapat menggunakan perintah `kubectl description node` dan `kubectl get node -o yaml` untuk mengambil informasi mendetil tentang Node. Misalnya, disini kamu akan melihat jika sebuah Node sedang mati (terputus dari jaringan, atau kubelet mati dan tidak mau restart, dll.). Perhatikan peristiwa yang menunjukkan Node tersebut NotReady, dan juga perhatikan bahwa Pod tidak lagi berjalan (mereka akan dikeluarkan setelah lima menit berstatus NotReady).
|
||||
|
||||
```shell
|
||||
kubectl get nodes
|
||||
|
|
|
|||
|
|
@ -426,7 +426,7 @@ pengambilan metrik. Terakhir, kondisi terakhir, `ScalingLimited`, menunjukkan ba
|
|||
|
||||
## Lampiran: Kuantitas
|
||||
|
||||
Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan` 1,5` ketika ditulis dalam notasi desimal.
|
||||
Semua metrik di HorizontalPodAutoscaler dan metrik API ditentukan menggunakan notasi bilangan bulat khusus yang dikenal di Kubernetes sebagai {{< glossary_tooltip term_id="quantity" text="kuantitas">}}. Misalnya, kuantitas `10500m` akan ditulis sebagai `10.5` dalam notasi desimal. Metrik API akan menampilkan bilangan bulat tanpa sufiks jika memungkinkan, dan secara umum akan mengembalikan kuantitas dalam satuan mili. Ini berarti kamu mungkin melihat nilai metrik berfluktuasi antara `1` dan `1500m`, atau `1` dan `1,5` ketika ditulis dalam notasi desimal.
|
||||
|
||||
## Lampiran: Skenario lain yang memungkinkan
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue