Change kluster to klaster mentioned in https://github.com/jk8s/sig-docs-id/issues/20 (#18130)
This commit is contained in:
irvifa
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
a7f6a78d55
commit
39fe327423
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Administrasi Kluster"
|
||||
title: "Administrasi Klaster"
|
||||
weight: 100
|
||||
---
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk
|
||||
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) menggabungkan Flannel dan Calico, menyediakan jaringan serta *policy* jaringan.
|
||||
* [Cilium](https://github.com/cilium/cilium) merupakan *plugin* jaringan L3 dan *policy* jaringan yang dapat menjalankan *policy* HTTP/API/L7 secara transparan. Mendukung mode *routing* maupun *overlay/encapsulation*.
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus.
|
||||
* [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk kluster dengan kubeadm maupun non-kubeadm.
|
||||
* [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm.
|
||||
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), yang berbasis dari [Tungsten Fabric](https://tungsten.io), merupakan sebuah proyek *open source* yang menyediakan virtualisasi jaringan *multi-cloud* serta platform manajemen *policy*. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan *bare metal*.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) merupakan penyedia jaringan *overlay* yang dapat digunakan pada Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes.
|
||||
|
||||
@@ -16,7 +16,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
|
||||
|
||||
### easyrsa
|
||||
|
||||
**easyrsa** dapat digunakan untuk menghasilkan sertifikat kluster kamu secara manual.
|
||||
**easyrsa** dapat digunakan untuk menghasilkan sertifikat klaster kamu secara manual.
|
||||
|
||||
1. Unduh, buka paket, dan inisialisasi versi tambal easyrsa3.
|
||||
|
||||
@@ -54,7 +54,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
|
||||
|
||||
### openssl
|
||||
|
||||
**openssl** secara manual dapat menghasilkan sertifikat untuk kluster kamu.
|
||||
**openssl** secara manual dapat menghasilkan sertifikat untuk klaster kamu.
|
||||
|
||||
1. Hasilkan ca.key dengan 2048bit:
|
||||
|
||||
@@ -68,7 +68,7 @@ secara manual melalui `easyrsa`, `openssl` atau `cfssl`.
|
||||
1. Buat _file_ konfigurasi untuk menghasilkan _Certificate Signing Request_ (CSR).
|
||||
Pastikan untuk mengganti nilai yang ditandai dengan kurung sudut (mis. `<MASTER_IP>`)
|
||||
dengan nilai sebenarnya sebelum menyimpan ke _file_ (mis. `csr.conf`).
|
||||
Perhatikan bahwa nilai `MASTER_CLUSTER_IP` adalah layanan IP kluster untuk
|
||||
Perhatikan bahwa nilai `MASTER_CLUSTER_IP` adalah layanan IP klaster untuk
|
||||
_server_ API seperti yang dijelaskan dalam subbagian sebelumnya.
|
||||
Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local`
|
||||
sebagai nama _domain_ DNS _default_.
|
||||
@@ -184,7 +184,7 @@ Terakhir, tambahkan parameter yang sama ke dalam parameter mulai _server_ API.
|
||||
1. Buat _file_ konfigurasi JSON untuk menghasilkan kunci dan sertifikat untuk API
|
||||
_server_, misalnya, `server-csr.json`. Pastikan untuk mengganti nilai dalam kurung sudut
|
||||
dengan nilai sebenarnya yang ingin kamu gunakan. `MASTER_CLUSTER_IP` adalah layanan
|
||||
kluster IP untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya.
|
||||
klaster IP untuk _server_ API seperti yang dijelaskan dalam subbagian sebelumnya.
|
||||
Sampel di bawah ini juga mengasumsikan bahwa kamu menggunakan `cluster.local` sebagai
|
||||
nama _domain_ DNS _default_.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Laman ini akan menjelaskan bagaimana cara mengelola Kubernetes yang berjalan pad
|
||||
|
||||
{{% capture body %}}
|
||||
### Kubeadm
|
||||
[Kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) merupakan salah satu cara yang banyak digunakan untuk membuat kluster Kubernetes.
|
||||
[Kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) merupakan salah satu cara yang banyak digunakan untuk membuat klaster Kubernetes.
|
||||
Kubeadm memiliki beragam opsi untuk mengatur konfigurasi spesifik untuk penyedia layanan cloud. Salah satu contoh yang biasa digunakan pada penyedia cloud *in-tree* yang dapat diatur dengan kubeadm adalah sebagai berikut:
|
||||
|
||||
```yaml
|
||||
@@ -297,7 +297,7 @@ dan harus berada pada bagian `[Router]` dari *file* `cloud.conf`:
|
||||
|
||||
* `router-id` (Opsional): Jika Neutron pada *underlying cloud* mendukung ekstensi
|
||||
`extraroutes` maka gunakan `router-id` untuk menentukan router mana yang akan ditambahkan rute di dalamnya.
|
||||
Router yang dipilih harus menjangkau jaringan privat tempat *node* kluster berada
|
||||
Router yang dipilih harus menjangkau jaringan privat tempat *node* klaster berada
|
||||
(biasanya hanya ada satu jaringan *node*, dan nilai ini harus nilai dari *default* router
|
||||
pada jaringan *node*). Nilai ini dibutuhkan untuk dapat menggunakan [kubenet] pada OpenStack.
|
||||
|
||||
@@ -330,14 +330,14 @@ Parameter `--hostname-override` diabaikan oleh penyedia layanan cloud VSphere.
|
||||
## IBM Cloud Kubernetes Service
|
||||
|
||||
### Node Komputasi
|
||||
Saat menggunakan layanan IBM Cloud Kubernetes Service, kamu dapat membuat kluster yang terdiri dari campuran antara mesin virtual dan fisik (*bare metal*) sebagai *node* di *single zone* atau *multiple zones* pada satu region. Untuk informasi lebih lanjut, lihat [Perencanaan kluster dan pengaturan worker node](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters).
|
||||
Saat menggunakan layanan IBM Cloud Kubernetes Service, kamu dapat membuat klaster yang terdiri dari campuran antara mesin virtual dan fisik (*bare metal*) sebagai *node* di *single zone* atau *multiple zones* pada satu region. Untuk informasi lebih lanjut, lihat [Perencanaan klaster dan pengaturan worker node](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters).
|
||||
|
||||
Nama dari objek Kubernetes Node yaitu alamat IP privat dari IBM Cloud Kubernetes Service *worker node instance*.
|
||||
|
||||
### Jaringan
|
||||
Penyedia layanan IBM Cloud Kubernetes Service menyediakan VLAN untuk membuat jaringan node yang terisolasi dengan kinerja tinggi. Kamu juga dapat membuat *custom firewall* dan *policy* jaringan Calico untuk menambah lapisan perlindungan ekstra bagi kluster kamu, atau hubungkan kluster kamu dengan *on-prem* data center via VPN. Untuk informasi lebih lanjut, lihat [Perencanaan jaringan privat dan in-cluster](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster).
|
||||
Penyedia layanan IBM Cloud Kubernetes Service menyediakan VLAN untuk membuat jaringan node yang terisolasi dengan kinerja tinggi. Kamu juga dapat membuat *custom firewall* dan *policy* jaringan Calico untuk menambah lapisan perlindungan ekstra bagi klaster kamu, atau hubungkan klaster kamu dengan *on-prem* data center via VPN. Untuk informasi lebih lanjut, lihat [Perencanaan jaringan privat dan in-cluster](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster).
|
||||
|
||||
Untuk membuka aplikasi ke publik atau di dalam kluster, kamu dapat menggunakan NodePort, LoadBalancer, atau Ingress. Kamu juga dapat menyesuaikan aplikasi *load balancer* Ingress dengan anotasi. Untuk informasi lebih lanjut, lihat [Perencanaan untuk membuka aplikasi dengan jaringan eksternal](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
|
||||
Untuk membuka aplikasi ke publik atau di dalam klaster, kamu dapat menggunakan NodePort, LoadBalancer, atau Ingress. Kamu juga dapat menyesuaikan aplikasi *load balancer* Ingress dengan anotasi. Untuk informasi lebih lanjut, lihat [Perencanaan untuk membuka aplikasi dengan jaringan eksternal](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).
|
||||
|
||||
### Penyimpanan
|
||||
Penyedia layanan IBM Cloud Kubernetes Service memanfaatkan Kubernetes-native *persistent volumes* agar pengguna dapat melakukan *mount* *file*, block, dan penyimpanan objek cloud ke aplikasi mereka. Kamu juga dapat menggunakan *database-as-a-service* dan *add-ons* pihak ketiga sebagai penyimpanan *persistent* untuk data kamu. Untuk informasi lebih lanjut, lihat [Perencanaan penyimpanan persistent yang selalu tersedia (*highly available*)](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).
|
||||
|
||||
+17
-17
@@ -2,43 +2,43 @@
|
||||
reviewers:
|
||||
- davidopp
|
||||
- lavalamp
|
||||
title: Ikhtisar Administrasi Kluster
|
||||
title: Ikhtisar Administrasi Klaster
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
---
|
||||
|
||||
{{% capture overview %}}
|
||||
Ikhtisar administrasi kluster ini ditujukan untuk siapapun yang akan membuat atau mengelola kluster Kubernetes.
|
||||
Ikhtisar administrasi klaster ini ditujukan untuk siapapun yang akan membuat atau mengelola klaster Kubernetes.
|
||||
Diharapkan untuk memahami beberapa [konsep](/docs/concepts/) dasar Kubernetes sebelumnya.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Perencanaan Kluster
|
||||
## Perencanaan Klaster
|
||||
|
||||
Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tentang bagaimana merencanakan, mengatur dan mengonfigurasi kluster Kubernetes. Solusi yang akan dipaparkan di bawah ini disebut *distro*.
|
||||
Lihat panduan di [Persiapan](/docs/setup) untuk mempelajari beberapa contoh tentang bagaimana merencanakan, mengatur dan mengonfigurasi klaster Kubernetes. Solusi yang akan dipaparkan di bawah ini disebut *distro*.
|
||||
|
||||
Sebelum memilih panduan, berikut adalah beberapa hal yang perlu dipertimbangkan:
|
||||
|
||||
- Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah kluster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu.
|
||||
- **Jika kamu merencanakan kluster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [kluster pada *multiple zone*](/docs/concepts/cluster-administration/federation/).
|
||||
- Apakah kamu akan menggunakan **Kubernetes kluster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klustermu**?
|
||||
- Apakah klustermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung kluster hibrid. Sebagai gantinya, kamu dapat membuat beberapa kluster.
|
||||
- Apakah kamu hanya ingin mencoba Kubernetes pada komputermu, atau kamu ingin membuat sebuah klaster dengan *high-availability*, *multi-node*? Pilihlah distro yang paling sesuai dengan kebutuhanmu.
|
||||
- **Jika kamu merencanakan klaster dengan _high-availability_**, pelajari bagaimana cara mengonfigurasi [klaster pada *multiple zone*](/docs/concepts/cluster-administration/federation/).
|
||||
- Apakah kamu akan menggunakan **Kubernetes klaster di _hosting_**, seperti [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), atau **_hosting_ sendiri klastermu**?
|
||||
- Apakah klastermu berada pada **_on-premises_**, atau **di cloud (IaaS)**? Kubernetes belum mendukung secara langsung klaster hibrid. Sebagai gantinya, kamu dapat membuat beberapa klaster.
|
||||
- **Jika kamu ingin mengonfigurasi Kubernetes _on-premises_**, pertimbangkan [model jaringan](/docs/concepts/cluster-administration/networking/) yang paling sesuai.
|
||||
- Apakah kamu ingin menjalankan Kubernetes pada **"bare metal" _hardware_** atau pada **_virtual machines_ (VM)**?
|
||||
- Apakah kamu **hanya ingin mencoba kluster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan.
|
||||
- Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah kluster.
|
||||
- Apakah kamu **hanya ingin mencoba klaster Kubernetes**, atau kamu ingin ikut aktif melakukan **pengembangan kode dari proyek Kubernetes**? Jika jawabannya yang terakhir, pilihlah distro yang aktif dikembangkan. Beberapa distro hanya menggunakan rilis *binary*, namun menawarkan lebih banyak variasi pilihan.
|
||||
- Pastikan kamu paham dan terbiasa dengan beberapa [komponen](/docs/admin/cluster-components/) yang dibutuhkan untuk menjalankan sebuah klaster.
|
||||
|
||||
Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji dengan versi terkini dari Kubernetes.
|
||||
|
||||
## Mengelola Kluster
|
||||
## Mengelola Klaster
|
||||
|
||||
* [Mengelola kluster](/docs/tasks/administer-cluster/cluster-management/) akan menjabarkan beberapa topik terkait *lifecycle* dari kluster: membuat kluster baru, melakukan *upgrade* pada *node master* dan *worker*, melakukan pemeliharaan *node* (contoh: *upgrade* kernel), dan melakukan *upgrade* versi Kubernetes API pada kluster yang sedang berjalan.
|
||||
* [Mengelola klaster](/docs/tasks/administer-cluster/cluster-management/) akan menjabarkan beberapa topik terkait *lifecycle* dari klaster: membuat klaster baru, melakukan *upgrade* pada *node master* dan *worker*, melakukan pemeliharaan *node* (contoh: *upgrade* kernel), dan melakukan *upgrade* versi Kubernetes API pada klaster yang sedang berjalan.
|
||||
|
||||
* Pelajari bagaimana cara [mengatur *node*](/docs/concepts/nodes/node/).
|
||||
|
||||
* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* kluster.
|
||||
* Pelajari bagaimana cara membuat dan mengatur kuota resource [(*resource quota*)](/docs/concepts/policy/resource-quotas/) untuk *shared* klaster.
|
||||
|
||||
## Mengamankan Kluster
|
||||
## Mengamankan Klaster
|
||||
|
||||
* [Sertifikat (*certificate*)](/docs/concepts/cluster-administration/certificates/) akan menjabarkan langkah-langkah untuk membuat sertifikat menggunakan beberapa *tool chains*.
|
||||
|
||||
@@ -52,7 +52,7 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
|
||||
|
||||
* [Menggunakan *Admission Controllers*](/docs/reference/access-authn-authz/admission-controllers/) akan menjelaskan *plug-in* yang akan melakukan intersep permintaan sebelum menuju ke server Kubernetes API, setelah autentikasi dan otorisasi dilakukan.
|
||||
|
||||
* [Menggunakan Sysctls pada Kluster Kubernetes](/docs/concepts/cluster-administration/sysctl-cluster/) akan menjabarkan tentang cara menggunakan perintah `sysctl` pada *command-line* untuk mengatur parameter kernel.
|
||||
* [Menggunakan Sysctls pada Klaster Kubernetes](/docs/concepts/cluster-administration/sysctl-cluster/) akan menjabarkan tentang cara menggunakan perintah `sysctl` pada *command-line* untuk mengatur parameter kernel.
|
||||
|
||||
* [Audit](/docs/tasks/debug-application-cluster/audit/) akan menjelaskan bagaimana cara berinteraksi dengan log audit Kubernetes.
|
||||
|
||||
@@ -61,11 +61,11 @@ Catatan: Tidak semua distro aktif dikelola. Pilihlah distro yang telah diuji den
|
||||
* [TLS *bootstrapping*](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
|
||||
* [Autentikasi/Otorisasi Kubelet](/docs/admin/kubelet-authentication-authorization/)
|
||||
|
||||
## Layanan Tambahan Kluster
|
||||
## Layanan Tambahan Klaster
|
||||
|
||||
* [Integrasi DNS](/docs/concepts/services-networking/dns-pod-service/) akan menjelaskan bagaimana cara *resolve* suatu nama DNS langsung pada *service* Kubernetes.
|
||||
|
||||
* [*Logging* dan *Monitoring* Aktivitas Kluster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
|
||||
* [*Logging* dan *Monitoring* Aktivitas Klaster](/docs/concepts/cluster-administration/logging/) akan menjelaskan bagaimana cara *logging* bekerja di Kubernetes serta bagaimana cara mengimplementasikannya.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Metrik _controller manager_ memberikan informasi penting tentang kinerja dan kes
|
||||
|
||||
Metrik _controller manager_ ini berfungsi untuk memberikan informasi penting tentang kinerja dan kesehatan dari _controller manager_.
|
||||
Metrik ini juga berisi tentang metrik umum dari _runtime_ bahasa pemrograman Go seperti jumlah _go_routine_ dan metrik spesifik dari _controller_ seperti
|
||||
latensi dari etcd _request_ atau latensi API dari penyedia layanan _cloud_ (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan dari kluster.
|
||||
latensi dari etcd _request_ atau latensi API dari penyedia layanan _cloud_ (AWS, GCE, OpenStack) yang dapat digunakan untuk mengukur kesehatan dari klaster.
|
||||
|
||||
Mulai dari Kubernetes 1.7, metrik yang lebih mendetil tentang operasi penyimpanan dari penyedia layanan _cloud_ juga telah tersedia.
|
||||
Metrik-metrik ini dapat digunakan untuk memonitor kesehatan dari operasi _persistent volume_.
|
||||
@@ -32,7 +32,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
|
||||
|
||||
## Konfigurasi
|
||||
|
||||
Pada sebuah kluster, informasi metrik _controller manager_ dapat diakses melalui `http://localhost:10252/metrics`
|
||||
Pada sebuah klaster, informasi metrik _controller manager_ dapat diakses melalui `http://localhost:10252/metrics`
|
||||
dari _host_ tempat _controller manager_ dijalankan.
|
||||
|
||||
Metrik ini dikeluarkan dalam bentuk [format prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) serta mudah untuk dibaca manusia.
|
||||
|
||||
@@ -11,44 +11,44 @@ weight: 80
|
||||
{{< /deprecationfilewarning >}}
|
||||
|
||||
Laman ini menjelaskan alasan dan cara penggunaan _federation_ untuk melakukan manajemen
|
||||
kluster Kubernetes.
|
||||
klaster Kubernetes.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Kenapa _Federation_ ?
|
||||
|
||||
_Federation_ membuat proses manajemen kluster multipel menjadi lebih mudah.
|
||||
_Federation_ membuat proses manajemen klaster multipel menjadi lebih mudah.
|
||||
_Federation_ mencapai hal ini dengan cara menyediakan 2 buah fondasi:
|
||||
|
||||
* Melakukan sinkronisasi _resource_ di seluruh kluster: _Federation_
|
||||
* Melakukan sinkronisasi _resource_ di seluruh klaster: _Federation_
|
||||
menyediakan kemampuan untuk melakukan sinkronisasi _resources_ pada _multiple_
|
||||
kluster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama
|
||||
tersedia pada kluster multipel.
|
||||
klaster. Sebagai contoh, kamu dapat memastikan _Deployment_ yang sama
|
||||
tersedia pada klaster multipel.
|
||||
* _Cross_ _cluster_ _Discovery_: _Federation_ menyediakan kemampuan untuk melakukan
|
||||
konfigurasi otomatis server DNS dan _load balancer_ dari semua kluster.
|
||||
konfigurasi otomatis server DNS dan _load balancer_ dari semua klaster.
|
||||
Misalnya, kamu dapat memastikan bahwa sebuah VIP atau DNS global dapat digunakan
|
||||
untuk mengakses _backend_ dari kluster multipel.
|
||||
untuk mengakses _backend_ dari klaster multipel.
|
||||
|
||||
Beberapa penggunaan _federation_ adalah sebagai berikut:
|
||||
|
||||
* _High Availability_: Melakukan _load balance_ di seluruh kluster serta
|
||||
* _High Availability_: Melakukan _load balance_ di seluruh klaster serta
|
||||
melakukan konfigurasi otomatis server DNS dan _load balancer_, _federation_
|
||||
meminimalisasi dampak yang terjadi apabila terjadi kegagalan kluster.
|
||||
meminimalisasi dampak yang terjadi apabila terjadi kegagalan klaster.
|
||||
* Mencegah _lock-in_ yang terjadi akibat penyedia layanan: Dengan cara mempermudah
|
||||
proses migrasi antar kluster.
|
||||
proses migrasi antar klaster.
|
||||
|
||||
|
||||
Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa kluster.
|
||||
Beberapa alasan kenapa kamu butuh beberapa kluster adalah:
|
||||
Manfaat _federation_ tidak akan terlalu kelihatan kecuali kamu memiliki beberapa klaster.
|
||||
Beberapa alasan kenapa kamu butuh beberapa klaster adalah:
|
||||
|
||||
* _Latency_ yang rendah: Memiliki kluster yang berada di _region_ yang berbeda
|
||||
* _Latency_ yang rendah: Memiliki klaster yang berada di _region_ yang berbeda
|
||||
meminimalisasi _latency_ dengan cara menyajikan konten ke pengguna
|
||||
berdasarkan _region_ yang paling dekat dengan pengguna tersebut.
|
||||
* Isolasi _fault_: Akan lebih baik apabila kita memiliki beberapa kluster kecil
|
||||
dibandingkan sebuah kluster besar untuk melakukan isolasi _fault_ (misalnya saja
|
||||
kluster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_
|
||||
* Isolasi _fault_: Akan lebih baik apabila kita memiliki beberapa klaster kecil
|
||||
dibandingkan sebuah klaster besar untuk melakukan isolasi _fault_ (misalnya saja
|
||||
klaster ini bisa saja berada di _availability_ zona dan penyedia layanan _cloud_
|
||||
yang berbeda).
|
||||
* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah kluster Kubernetes,
|
||||
* Skalabilitas: Terdapat batasan skalabilitas untuk sebuah klaster Kubernetes,
|
||||
hal ini sebenarnya tidak menjadi masalah bagi sebagian besar pengguna. Untuk informasi
|
||||
lebih lanjut kamu bisa membaca
|
||||
[_Kubernetes Scaling_ dan Perencanaan Performa](https://git.k8s.io/community/sig-scalability/goals.md)).
|
||||
@@ -62,10 +62,10 @@ terdapat beberapa kekurangan _federation_ yang dijabarkan sebagai berikut:
|
||||
|
||||
* Peningkatan _bandwidth_ dan biaya untuk jaringan: _control plane_ _federation_ bertugas mengawasi semua
|
||||
kulster yang ada untuk menjamin _state_ yang ada saat ini sesuai dengan _state_ yang diinginkan. Hal ini dapat menyebabkan
|
||||
peningkatan biaya jaringan apabila kluster yang ada dijalankan pada _region_ yang berbeda baik pada penyedia
|
||||
peningkatan biaya jaringan apabila klaster yang ada dijalankan pada _region_ yang berbeda baik pada penyedia
|
||||
layanan _cloud_ yang sama maupun berbeda.
|
||||
* Berkurangnya isolasi antar kluster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat
|
||||
berdampak pada semua kluster. Hal ini dapat dihindari dengan cara mejaga logika yang ada pada _control plane_ _federation_
|
||||
* Berkurangnya isolasi antar klaster: Sebuah _bug_ yang ada pada _control plane_ _federation_ dapat
|
||||
berdampak pada semua klaster. Hal ini dapat dihindari dengan cara mejaga logika yang ada pada _control plane_ _federation_
|
||||
seminimum mungkin.
|
||||
* Kematangan: Proyek _federation_ ini tergolong baru dan belum cukup matang.
|
||||
Tidak semua _resource_ yang ada tersedia dan masih banyak feature _alpha_. [_Issue_
|
||||
@@ -74,18 +74,18 @@ terdapat beberapa kekurangan _federation_ yang dijabarkan sebagai berikut:
|
||||
|
||||
### Kemampuan _Hybrid_ Penggunaan Layanan Penyedian _Cloud_
|
||||
|
||||
_Federation_ pada Kubernetes memungkinkan kluster untuk dijalankan
|
||||
_Federation_ pada Kubernetes memungkinkan klaster untuk dijalankan
|
||||
pada penyedia layanan _cloud_ yang berbeda (misalnya Google Cloud, AWS), dan _on-premise_
|
||||
(misalnya OpenStack). [Kubefed](/docs/tasks/federation/set-up-cluster-federation-kubefed/)
|
||||
adalah salah satu cara yang direkomendasikan untuk melakukan proses _deploy_
|
||||
kluster _federation_.
|
||||
klaster _federation_.
|
||||
|
||||
Dengan demikian, [_resources_ API](#resources-api) yang kamu miliki
|
||||
dapat berada di kluster atau bahkan penyedia layanan _cloud_ yang berbeda.
|
||||
dapat berada di klaster atau bahkan penyedia layanan _cloud_ yang berbeda.
|
||||
|
||||
## Mengaktifkan _Federation_
|
||||
|
||||
Untuk bisa melakukan _federation_ pada kluster yang berbeda,
|
||||
Untuk bisa melakukan _federation_ pada klaster yang berbeda,
|
||||
pertama kamu harus mengaktifkan _control plane_ _federation_.
|
||||
Ikuti [petunjuk mengaktifkan _control plane_ _federation_](/docs/tutorials/federation/set-up-cluster-federation-kubefed/)
|
||||
untuk informasi lebih lanjut.
|
||||
@@ -117,7 +117,7 @@ _resources_ yang disediakan _apiserver_ _federation_.
|
||||
Kubernetes versi 1.6 menyediakan mekanisme penghapusan berantai
|
||||
untuk _resource_ yang ada pada _federation_. Dengan penghapusan berantai,
|
||||
ketika kamu menghapus sebuah _resource_ dari _control plane_ _federation_,
|
||||
kamu juga akan menghapus segala _resource_ tersebut pada semua kluster yang ada.
|
||||
kamu juga akan menghapus segala _resource_ tersebut pada semua klaster yang ada.
|
||||
|
||||
Mekanisme penghapusan berantai ini tidak diaktifkan secara _default_
|
||||
ketika menggunakan REST API. Untuk mengaktifkannya, ubah nilai dari opsi
|
||||
@@ -129,64 +129,64 @@ Kamu dapat menonaktifkannya dengan menggunakan `kubectl delete --cascade=false`
|
||||
Catatan: Kubernetes versi 1.5 menyediakan penghapusan berantai
|
||||
untuk sebagian _resource_ _federation_.
|
||||
|
||||
## Cakupan dari Sebuah Kluster
|
||||
## Cakupan dari Sebuah Klaster
|
||||
|
||||
Pada penyedia IaaS seperti Google Compute Engine atau Amazon Web Services, sebuah VM ada di dalam
|
||||
[zona](https://cloud.google.com/compute/docs/zones) atau [_availability
|
||||
zone_](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html).
|
||||
Kami menyarankan agar semua VM pada kluster Kubernetes berada pada _availability_ zona yang sama, karena:
|
||||
Kami menyarankan agar semua VM pada klaster Kubernetes berada pada _availability_ zona yang sama, karena:
|
||||
|
||||
- dibandingkan dengan sebuah kluster global Kubernetes, terdapat lebih sedikit _single-points of failure_.
|
||||
- dibandingkan dengan sebuah kluster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah
|
||||
kluster yang berada pada satu zona.
|
||||
- dibandingkan dengan sebuah klaster global Kubernetes, terdapat lebih sedikit _single-points of failure_.
|
||||
- dibandingkan dengan sebuah klaster yang tersebar pada _availability zone_ yang mungkin berbeda, akan lebih mudah untuk merencanakan properti _availability_ dari sebuah
|
||||
klaster yang berada pada satu zona.
|
||||
- ketika pengembang Kubernetes mendesain sistem (misalnya, memperkirakan _latency_, _bandwidth_, atau
|
||||
_failure_ yang mungkin terjadi) pengembang tersebut memperkirakan semua mesin akan berada pada sebuah _data center_ yang sama, atau setidaknya masih terdapat pada satu wilayah.
|
||||
|
||||
Sangat direkomendasikan untuk menjalankan sedikit kluster dengan lebih banyak VM pada setiap _availability_ zona;
|
||||
meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan kluster multipel
|
||||
Sangat direkomendasikan untuk menjalankan sedikit klaster dengan lebih banyak VM pada setiap _availability_ zona;
|
||||
meskipun begitu hal ini tidak menutup kemungkinan untuk menjalankan klaster multipel
|
||||
pada setiap _availability_ zona.
|
||||
|
||||
Alasan kenapa menjalankan lebih sedikit kluster pada setiap _availability_ zona lebih dianjurkan:
|
||||
Alasan kenapa menjalankan lebih sedikit klaster pada setiap _availability_ zona lebih dianjurkan:
|
||||
|
||||
- meningkatkan _bin packing_ _Pod_ pada beberapa kasus dimana terdapat lebih banyak _node_ dalam sebuah kluster (mengurangi terjadinya _fragmentation_ _resource_).
|
||||
- meningkatkan _bin packing_ _Pod_ pada beberapa kasus dimana terdapat lebih banyak _node_ dalam sebuah klaster (mengurangi terjadinya _fragmentation_ _resource_).
|
||||
- mengurangi _overhead_ operasional (meskipun keuntungan ini akan berkurang seiring bertambah matangnya proses dan _tooling_ operasional).
|
||||
- mengurangi biaya _resource_ tetap per kluster, misalnya VM _apiserver_.
|
||||
- mengurangi biaya _resource_ tetap per klaster, misalnya VM _apiserver_.
|
||||
|
||||
Alasan untuk memiliki kluster multipel:
|
||||
Alasan untuk memiliki klaster multipel:
|
||||
|
||||
- _policy_ kemananan yang ketat membutuhkan isolasi antar _work_ _class_ (baca Partisi Kluster di bawah).
|
||||
- melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu kluster.
|
||||
- _policy_ kemananan yang ketat membutuhkan isolasi antar _work_ _class_ (baca Partisi Klaster di bawah).
|
||||
- melakukan penerapan Kubernetes dan/atau perangkat lunak lain yang versi baru ke salah satu klaster.
|
||||
|
||||
## Memilih jumlah kluster yang tepat
|
||||
## Memilih jumlah klaster yang tepat
|
||||
|
||||
Pemilihan jumlah kluster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu.
|
||||
Pemilihan jumlah klaster yang tepat merupakan pilihan yang relatif statis, dan hanya akan ditinjau kembali sewaktu-waktu.
|
||||
Sebaliknya, jumlah _node_ dan _pod_ dalam suatu _service_ dapat berubah secara cepat seiring bertambahnya _workload_.
|
||||
|
||||
Untuk memilih jumlah kluster, pertama, pilih _region_ yang memiliki _latency_ yang masih dapat dimaklumi untuk semua pengguna aplikasi kamu
|
||||
Untuk memilih jumlah klaster, pertama, pilih _region_ yang memiliki _latency_ yang masih dapat dimaklumi untuk semua pengguna aplikasi kamu
|
||||
(jika kamu menggunakan _Content Distribution Network_, kebutuhan informasi nilai _latency_ CDN tidak perlu diperhatikan).
|
||||
Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih kluster di _region_
|
||||
Masalah legal juga perlu diperhitungkan. Misalnya sebuah perusahaan dengan pelanggan global bisa jadi memilih klaster di _region_
|
||||
US, EU, AP, dan SA. Jumlah _region_ ini dimisalkan dengan `R`.
|
||||
|
||||
Kedua, pilih berapa banyak kluster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_.
|
||||
Misalkan jumlah kluster _unavailable_ ini sebagai `U`. Jika kamu tidak yakin, maka 1 merupakan pilihan yang tergolong
|
||||
Kedua, pilih berapa banyak klaster yang bisa jadi _unavailable_ secara bersamaan tanpa membuat _service_ menjadi _unavailable_.
|
||||
Misalkan jumlah klaster _unavailable_ ini sebagai `U`. Jika kamu tidak yakin, maka 1 merupakan pilihan yang tergolong
|
||||
dapat diterima.
|
||||
|
||||
Jika aplikasimu memungkinkan trafik untuk di-_load balance_ ke _region_ mana saja ketika terjadi _failure_ pada kluster,
|
||||
maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` kluster. Jika tidak (misalnya, kamu
|
||||
ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada kluster) maka kamu membutuhkan `R * (U + 1)` kluster
|
||||
(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu kluster
|
||||
Jika aplikasimu memungkinkan trafik untuk di-_load balance_ ke _region_ mana saja ketika terjadi _failure_ pada klaster,
|
||||
maka kamu setidaknya membutuhkan nilai yang lebih banyak dari jumlah `R` atau `U + 1` klaster. Jika tidak (misalnya, kamu
|
||||
ingin menjamin stabilnya _latency_ ketika terjadi _failure_ pada klaster) maka kamu membutuhkan `R * (U + 1)` klaster
|
||||
(`U + 1` di setiap _region_ yang ada pada `R`). Pada kasus lain, cobalah untuk menerapkan satu klaster
|
||||
pada zona yang berbeda.
|
||||
|
||||
Terakhir, jika kluster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah kluster Kubernetes,
|
||||
maka kamu membutuhkan lebih banyak kluster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap kluster. Kubernetes v1.8
|
||||
mampu menangani hingga 5000 node untuk tiap kluster. Baca [Membangun Kluster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut.
|
||||
Terakhir, jika klaster yang kamu miliki membutuhkan jumlah _node_ yang melebihi nilai yang direkomendasikan untuk sebuah klaster Kubernetes,
|
||||
maka kamu membutuhkan lebih banyak klaster. Kubernetes v1.3 mampu menangani hingga 1000 node untuk setiap klaster. Kubernetes v1.8
|
||||
mampu menangani hingga 5000 node untuk tiap klaster. Baca [Membangun Klaster Besar](/docs/setup/cluster-large/) untuk petunjuk lebih lanjut.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
* Pelajari lebih lanjut tentang [proposal
|
||||
_Federation_](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/multicluster/federation.md).
|
||||
* Baca [petunjuk pengaktifan](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) kluster _federation_.
|
||||
* Baca [petunjuk pengaktifan](/docs/tutorials/federation/set-up-cluster-federation-kubefed/) klaster _federation_.
|
||||
* Lihat [seminar tentang _federation_ pada Kubecon2016](https://www.youtube.com/watch?v=pq9lbkmxpS8)
|
||||
* Lihat [_update_ _federation_ pada Kubecon2017 Eropa](https://www.youtube.com/watch?v=kwOvOLnFYck)
|
||||
* Lihat [_update_ _sig-multicluster_ pada Kubecon2018 Eropa](https://www.youtube.com/watch?v=vGZo5DaThQU)
|
||||
|
||||
@@ -6,16 +6,16 @@ weight: 60
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam kluster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas kluster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_.
|
||||
Log aplikasi dan sistem dapat membantu kamu untuk memahami apa yang terjadi di dalam klaster kamu. Log berguna untuk mengidentifikasi dan menyelesaikan masalah serta memonitor aktivitas klaster. Hampir semua aplikasi modern mempunyai sejenis mekanisme log sehingga hampir semua mesin kontainer didesain untuk mendukung suatu mekanisme _logging_. Metode _logging_ yang paling mudah untuk aplikasi dalam bentuk kontainer adalah menggunakan _standard output_ dan _standard error_.
|
||||
|
||||
Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level kluster. _Logging_ pada level kluster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam kluster Kubernetes kamu.
|
||||
Namun, fungsionalitas bawaan dari mesin kontainer atau _runtime_ biasanya tidak cukup memadai sebagai solusi log. Contohnya, jika sebuah kontainer gagal, sebuah pod dihapus, atau suatu _node_ mati, kamu biasanya tetap menginginkan untuk mengakses log dari aplikasimu. Oleh sebab itu, log sebaiknya berada pada penyimpanan dan _lifecyle_ yang terpisah dari node, pod, atau kontainer. Konsep ini dinamakan sebagai _logging_ pada level klaster. _Logging_ pada level klaster ini membutuhkan _backend_ yang terpisah untuk menyimpan, menganalisis, dan mengkueri log. Kubernetes tidak menyediakan solusi bawaan untuk penyimpanan data log, namun kamu dapat mengintegrasikan beragam solusi _logging_ yang telah ada ke dalam klaster Kubernetes kamu.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
Arsitektur _logging_ pada level kluster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klustermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level kluster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu.
|
||||
Arsitektur _logging_ pada level klaster yang akan dijelaskan berikut mengasumsikan bahwa sebuah _logging backend_ telah tersedia baik di dalam maupun di luar klastermu. Meskipun kamu tidak tertarik menggunakan _logging_ pada level klaster, penjelasan tentang bagaimana log disimpan dan ditangani pada node di bawah ini mungkin dapat berguna untukmu.
|
||||
|
||||
## Hal dasar _logging_ pada Kubernetes
|
||||
|
||||
@@ -61,7 +61,7 @@ _Logging driver_ json dari Docker memperlakukan tiap baris sebagai pesan yang te
|
||||
Secara _default_, jika suatu kontainer _restart_, kubelet akan menjaga kontainer yang mati tersebut beserta lognya. Namun jika suatu pod dibuang dari _node_, maka semua hal dari kontainernya juga akan dibuang, termasuk lognya.
|
||||
|
||||
Hal lain yang perlu diperhatikan dalam _logging_ pada level _node_ adalah implementasi rotasi log, sehingga log tidak menghabiskan semua penyimpanan yang tersedia pada _node._ Kubernetes saat ini tidak bertanggung jawab dalam melakukan rotasi log, namun _deployment tool_ seharusnya memberikan solusi terhadap masalah tersebut.
|
||||
Contohnya, pada kluster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker.
|
||||
Contohnya, pada klaster Kubernetes, yang di _deployed_ menggunakan `kube-up.sh`, terdapat alat bernama [`logrotate`](https://linux.die.net/man/8/logrotate) yang dikonfigurasi untuk berjalan tiap jamnya. Kamu juga dapat menggunakan _runtime_ kontainer untuk melakukan rotasi log otomatis, misalnya menggunakan `log-opt` Docker.
|
||||
Pada `kube-up.sh`, metode terakhir digunakan untuk COS _image_ pada GCP, sedangkan metode pertama digunakan untuk lingkungan lainnya. Pada kedua metode, secara _default_ akan dilakukan rotasi pada saat berkas log melewati 10MB.
|
||||
|
||||
Sebagai contoh, kamu dapat melihat informasi lebih rinci tentang bagaimana `kube-up.sh` mengatur _logging_ untuk COS _image_ pada GCP yang terkait dengan [_script_][cosConfigureHelper].
|
||||
@@ -85,13 +85,13 @@ Pada mesin yang menggunakan systemd, kubelet dan runtime _runtime_ menulis ke jo
|
||||
Komponen sistem di dalam kontainer akan selalu menuliskan ke folder `/var/log`, melewati mekanisme _default logging_. Mereka akan menggunakan _logging library_ [klog][klog].
|
||||
Kamu dapat menemukan konvensi tentang tingkat kegawatan _logging_ untuk komponen-komponen tersebut pada [dokumentasi _development logging_](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
|
||||
|
||||
Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada kluster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB.
|
||||
Seperti halnya pada log kontainer, komponen sistem yang menuliskan log pada folder `/var/log` juga harus melakukan rotasi log. Pada klaster Kubernetes yang menggunakan `kube-up.sh`, log tersebut telah dikonfigurasi dan akan dirotasi oleh `logrotate` secara harian atau saat ukuran log melebihi 100MB.
|
||||
|
||||
[klog]: https://github.com/kubernetes/klog
|
||||
|
||||
## Arsitektur kluster-level _logging_
|
||||
## Arsitektur klaster-level _logging_
|
||||
|
||||
Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level kluster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya:
|
||||
Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level klaster, ada beberapa pendekatan yang dapat kamu pertimbangkan. Berikut beberapa diantaranya:
|
||||
|
||||
* Menggunakan agen _logging_ pada level _node_ yang berjalan pada setiap _node_.
|
||||
* Menggunakan kontainer _sidecar_ khusus untuk _logging_ aplikasi di dalam pod.
|
||||
@@ -101,11 +101,11 @@ Meskipun Kubernetes tidak menyediakan solusi bawaan untuk _logging_ level kluste
|
||||
|
||||
|
||||
|
||||
Kamu dapat mengimplementasikan kluster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut.
|
||||
Kamu dapat mengimplementasikan klaster-level _logging_ dengan menggunakan agen yang berjalan pada setiap _node_. Agen _logging_ merupakan perangkat khusus yang akan mengekspos log atau mengeluarkan log ke _backend_. Umumnya agen _logging_ merupakan kontainer yang memiliki akses langsung ke direktori tempat berkas log berada dari semua kontainer aplikasi yang berjalan pada _node_ tersebut.
|
||||
|
||||
Karena agen _logging_ harus berjalan pada setiap _node_, umumnya dilakukan dengan menggunakan replika DaemonSet, _manifest_ pod, atau menjalankan proses khusus pada _node_. Namun dua cara terakhir sudah dideprekasi dan sangat tidak disarankan.
|
||||
|
||||
Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk kluster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_.
|
||||
Menggunakan agen _logging_ pada level _node_ merupakan cara yang paling umum dan disarankan untuk klaster Kubernetes. Hal ini karena hanya dibutuhkan satu agen tiap node dan tidak membutuhkan perubahan apapun dari sisi aplikasi yang berjalan pada _node_. Namun, node-level _logging_ hanya dapat dilakukan untuk aplikasi yang menggunakan _standard output_ dan _standard error_.
|
||||
|
||||
Kubernetes tidak menspesifikasikan khusus suatu agen _logging_, namun ada dua agen _logging_ yang dimasukkan dalam rilis Kubernetes: [Stackdriver Logging](/docs/user-guide/logging/stackdriver) untuk digunakan pada Google Cloud Platform, dan [Elasticsearch](/docs/user-guide/logging/elasticsearch). Kamu dapat melihat informasi dan instruksi pada masing-masing dokumentasi. Keduanya menggunakan [fluentd](http://www.fluentd.org/) dengan konfigurasi kustom sebagai agen pada _node_.
|
||||
|
||||
@@ -156,7 +156,7 @@ Mon Jan 1 00:00:02 UTC 2001 INFO 2
|
||||
...
|
||||
```
|
||||
|
||||
Agen node-level yang terpasang di klustermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya.
|
||||
Agen node-level yang terpasang di klastermu akan mengambil aliran log tersebut secara otomatis tanpa perlu melakukan konfigurasi tambahan. Bahkan jika kamu mau, kamu dapat mengonfigurasi agen untuk melakukan _parse_ baris log tergantung dari kontainer sumber awalnya.
|
||||
|
||||
Sedikit catatan, meskipun menggunakan memori dan CPU yang cukup rendah (sekitar beberapa milicore untuk CPU dan beberapa megabytes untuk memori), penulisan log ke _file_ kemudian mengalirkannya ke `stdout` dapat berakibat penggunaan disk yang lebih besar. Jika kamu memiliki aplikasi yang menuliskan ke _file_ tunggal, umumnya lebih baik menggunakan `/dev/stdout` sebagai tujuan daripada menggunakan pendekatan dengan kontainer _sidecar_.
|
||||
|
||||
@@ -193,6 +193,6 @@ Ingat, ini hanya contoh saja dan kamu dapat mengganti fluentd dengan agen _loggi
|
||||
|
||||
|
||||
|
||||
Kamu dapat mengimplementasikan kluster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes.
|
||||
Kamu dapat mengimplementasikan klaster-level _logging_ dengan mengekspos atau mengeluarkan log langsung dari tiap aplikasi; namun cara implementasi mekanisme _logging_ tersebut diluar cakupan dari Kubernetes.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -352,7 +352,7 @@ Kadang kita perlu membuat pembaruan kecil, yang tidak mengganggu pada _resource_
|
||||
|
||||
### kubectl apply
|
||||
|
||||
Disarankan untuk menyimpan berkas-berkas konfigurasi dalam _source control_ (lihat [konfigurasi sebagai kode](http://martinfowler.com/bliki/InfrastructureAsCode.html)). Sehingga berkas dapat dipelihara dan diatur dalam versi bersama dengan kode milik _resource_ yang diatur oleh konfigurasi tersebut. Berikutnya, kamu dapat menggunakan [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) untuk membarui perubahan konfigurasi ke kluster.
|
||||
Disarankan untuk menyimpan berkas-berkas konfigurasi dalam _source control_ (lihat [konfigurasi sebagai kode](http://martinfowler.com/bliki/InfrastructureAsCode.html)). Sehingga berkas dapat dipelihara dan diatur dalam versi bersama dengan kode milik _resource_ yang diatur oleh konfigurasi tersebut. Berikutnya, kamu dapat menggunakan [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply) untuk membarui perubahan konfigurasi ke klaster.
|
||||
|
||||
Perintah ini akan membandingkan versi konfigurasi yang disuplai dengan versi sebelumnya yang telah berjalan dan memasang perubahan yang kamu buat tanpa mengganti properti yang tidak berubah sama sekali.
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ Ada beberapa jenis <i>proxy</i> yang akan kamu temui saat menggunakan Kubernetes
|
||||
1. [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services):
|
||||
|
||||
- merupakan sebuah <i>bastion</i> yang ada di dalam apiserver
|
||||
- menghubungkan pengguna di luar kluster ke alamat-alamat IP di dalam kluster yang tidak bisa terjangkau
|
||||
- menghubungkan pengguna di luar klaster ke alamat-alamat IP di dalam klaster yang tidak bisa terjangkau
|
||||
- dijalankan bersama <i>process-process</i> apiserver
|
||||
- dari klien menuju <i>proxy</i> menggunakan HTTPS (atau http jika dikonfigurasi pada apiserver)
|
||||
- dari <i>proxy</i> menuju target menggunakan HTTP atau HTTPS, tergantung pilihan yang diambil oleh <i>proxy</i> melalui informasi yang ada
|
||||
@@ -43,7 +43,7 @@ Ada beberapa jenis <i>proxy</i> yang akan kamu temui saat menggunakan Kubernetes
|
||||
|
||||
1. Sebuah <i>Proxy/Load-balancer</i> di depan satu atau banyak apiserver:
|
||||
|
||||
- keberadaan dan implementasinya bervariasi tergantung pada kluster (contohnya nginx)
|
||||
- keberadaan dan implementasinya bervariasi tergantung pada klaster (contohnya nginx)
|
||||
- ada di antara seluruh klien dan satu/banyak apiserver
|
||||
- jika ada beberapa apiserver, berfungsi sebagai <i>load balancer</i>
|
||||
|
||||
@@ -56,7 +56,7 @@ Ada beberapa jenis <i>proxy</i> yang akan kamu temui saat menggunakan Kubernetes
|
||||
- implementasi bervariasi tergantung pada penyedia cloud
|
||||
|
||||
Pengguna Kubernetes biasanya hanya cukup perlu tahu tentang kubectl <i>proxy</i> dan apiserver <i>proxy</i>.
|
||||
Untuk <i>proxy-proxy</i> lain di luar ini, admin kluster biasanya akan memastikan konfigurasinya dengan benar.
|
||||
Untuk <i>proxy-proxy</i> lain di luar ini, admin klaster biasanya akan memastikan konfigurasinya dengan benar.
|
||||
|
||||
## Melakukan <i>request redirect</i>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user