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
@@ -13,7 +13,7 @@ Sekarang kamu memiliki aplikasi yang telah direplikasi, kamu dapat mengeksposnya
|
||||
|
||||
Secara *default*, *Docker* menggunakan jaringan *host*, jadi kontainer dapat berkomunikasi dengan kontainer lainnya jika mereka berada di dalam *node* yang sama. Agar kontainer *Docker* dapat berkomunikasi antar *node*, masing-masing kontainer tersebut harus diberikan *port* yang berbeda di alamat IP *node* tersebut, yang akan diteruskan (*proxied*) ke dalam kontainer. Artinya adalah para kontainer di dalam sebuah *node* harus berkoordinasi *port* mana yang akan digunakan atau dialokasikan secara otomatis.
|
||||
|
||||
Akan sulit untuk mengkoordinasikan *port* yang digunakan oleh banyak pengembang. Kubernetes mengasumsikan bahwa *Pod* dapat berkomunikasi dengan *Pod* lain, terlepas di *Node* mana *Pod* tersebut di *deploy*. Kubernetes memberikan setiap *Pod* alamat *ClusterIP* sehingga kamu tidak perlu secara explisit membuat jalur antara *Pod* ataupun memetakan *port* kontainer ke dalam *port* di dalam *Node* tersebut. Ini berarti kontainer di dalam sebuah *Pod* dapat berkomunikasi dengan *localhost* via *port*, dan setiap *Pod* di dalam kluster dapat berkomunikasi tanpa *NAT*. Panduan ini akan membahas bagaimana kamu dapat menjalankan sebuah layanan atau aplikasi di dalam model jaringan di atas.
|
||||
Akan sulit untuk mengkoordinasikan *port* yang digunakan oleh banyak pengembang. Kubernetes mengasumsikan bahwa *Pod* dapat berkomunikasi dengan *Pod* lain, terlepas di *Node* mana *Pod* tersebut di *deploy*. Kubernetes memberikan setiap *Pod* alamat *ClusterIP* sehingga kamu tidak perlu secara explisit membuat jalur antara *Pod* ataupun memetakan *port* kontainer ke dalam *port* di dalam *Node* tersebut. Ini berarti kontainer di dalam sebuah *Pod* dapat berkomunikasi dengan *localhost* via *port*, dan setiap *Pod* di dalam klaster dapat berkomunikasi tanpa *NAT*. Panduan ini akan membahas bagaimana kamu dapat menjalankan sebuah layanan atau aplikasi di dalam model jaringan di atas.
|
||||
|
||||
Panduan ini menggunakan server *nginx* sederhana untuk mendemonstrasikan konsepnya. Konsep yang sama juga ditulis lebih lengkap di [Aplikasi Jenkins CI](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes).
|
||||
|
||||
@@ -21,13 +21,13 @@ Panduan ini menggunakan server *nginx* sederhana untuk mendemonstrasikan konsepn
|
||||
|
||||
{{% capture body %}}
|
||||
|
||||
## Mengekspos Pod ke dalam kluster
|
||||
## Mengekspos Pod ke dalam klaster
|
||||
|
||||
Kita melakukan ini di beberapa contoh sebelumnya, tetapi mari kita lakukan sekali lagi dan berfokus pada prespektif jaringannya. Buat sebuah *nginx Pod*, dan perhatikan bahwa templat tersebut mempunyai spesifikasi *port* kontainer:
|
||||
|
||||
{{< codenew file="service/networking/run-my-nginx.yaml" >}}
|
||||
|
||||
Ini membuat aplikasi tersebut dapat diakses dari *node* manapun di dalam kluster kamu. Cek lokasi *node* dimana *Pod* tersebut berjalan:
|
||||
Ini membuat aplikasi tersebut dapat diakses dari *node* manapun di dalam klaster kamu. Cek lokasi *node* dimana *Pod* tersebut berjalan:
|
||||
```shell
|
||||
kubectl apply -f ./run-my-nginx.yaml
|
||||
kubectl get pods -l run=my-nginx -o wide
|
||||
@@ -45,15 +45,15 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
||||
podIP: 10.244.2.5
|
||||
```
|
||||
|
||||
Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam kluster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam kluster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya.
|
||||
Kamu dapat melakukan akses dengan *ssh* ke dalam *node* di dalam klaster dan mengakses IP *Pod* tersebut menggunakan *curl*. Perlu dicatat bahwa kontainer tersebut tidak menggunakan *port* 80 di dalam *node*, atau aturan *NAT* khusus untuk merutekan trafik ke dalam *Pod*. Ini berarti kamu dapat menjalankan banyak *nginx Pod* di *node* yang sama dimana setiap *Pod* dapat menggunakan *containerPort* yang sama, kamu dapat mengakses semua itu dari *Pod* lain ataupun dari *node* di dalam klaster menggunakan IP. Seperti *Docker*, *port* masih dapat di publikasi ke dalam * interface node*, tetapi kebutuhan seperti ini sudah berkurang karena model jaringannya.
|
||||
|
||||
Kamu dapat membaca lebih detail [bagaimana kita melakukan ini](/docs/concepts/cluster-administration/networking/#how-to-achieve-this) jika kamu penasaran.
|
||||
|
||||
## Membuat Service
|
||||
|
||||
Kita mempunyai *Pod* yang menjalankan *nginx* di dalam kluster. Teorinya, kamu dapat berkomunikasi ke *Pod* tersebut secara langsung, tapi apa yang terjadi jika sebuah *node* mati? *Pod* di dalam *node* tersebut ikut mati, dan *Deployment* akan membuat *Pod* baru, dengan IP yang berbeda. Ini adalah masalah yang *Service* selesaikan.
|
||||
Kita mempunyai *Pod* yang menjalankan *nginx* di dalam klaster. Teorinya, kamu dapat berkomunikasi ke *Pod* tersebut secara langsung, tapi apa yang terjadi jika sebuah *node* mati? *Pod* di dalam *node* tersebut ikut mati, dan *Deployment* akan membuat *Pod* baru, dengan IP yang berbeda. Ini adalah masalah yang *Service* selesaikan.
|
||||
|
||||
*Service* Kubernetes adalah sebuah abstraksi yang mendefinisikan sekumpulan *Pod* yang menyediakan fungsi yang sama dan berjalan di dalam kluster. Saat dibuat, setiap *Service* diberikan sebuah alamat IP (disebut juga *ClusterIP*). Alamat ini akan terus ada, dan tidak akan pernah berubah selama *Service* hidup. *Pod* dapat berkomunikasi dengan *Service* dan trafik yang menuju *Service* tersebut akan otomatis dilakukan mekanisme *load balancing* ke *Pod* yang merupakan anggota dari *Service* tersebut.
|
||||
*Service* Kubernetes adalah sebuah abstraksi yang mendefinisikan sekumpulan *Pod* yang menyediakan fungsi yang sama dan berjalan di dalam klaster. Saat dibuat, setiap *Service* diberikan sebuah alamat IP (disebut juga *ClusterIP*). Alamat ini akan terus ada, dan tidak akan pernah berubah selama *Service* hidup. *Pod* dapat berkomunikasi dengan *Service* dan trafik yang menuju *Service* tersebut akan otomatis dilakukan mekanisme *load balancing* ke *Pod* yang merupakan anggota dari *Service* tersebut.
|
||||
|
||||
Kamu dapat membuat *Service* untuk replika 2 *nginx* dengan `kubectl explose`:
|
||||
|
||||
@@ -107,12 +107,12 @@ NAME ENDPOINTS AGE
|
||||
my-nginx 10.244.2.5:80,10.244.3.4:80 1m
|
||||
```
|
||||
|
||||
Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `<CLUSTER-IP>:<PORT>` dari *node* manapun di kluster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
|
||||
Kamu sekarang dapat melakukan *curl* ke dalam *nginx Service* di `<CLUSTER-IP>:<PORT>` dari *node* manapun di klaster. Perlu dicatat bahwa *Service IP* adalah IP virtual, IP tersebut tidak pernah ada di *interface node* manapun. Jika kamu penasaran bagaimana konsep ini bekerja, kamu dapat membaca lebih lanjut tentang [service proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies).
|
||||
|
||||
## Mengakses Service
|
||||
|
||||
Kubernetes mendukung 2 mode utama untuk menemukan sebuah *Service* - variabel *environment* dan *DNS*.
|
||||
*DNS* membutuhkan [tambahan CoreDNS di dalam kluster](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
|
||||
*DNS* membutuhkan [tambahan CoreDNS di dalam klaster](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns).
|
||||
|
||||
### Variabel Environment
|
||||
|
||||
@@ -155,7 +155,7 @@ KUBERNETES_SERVICE_PORT_HTTPS=443
|
||||
|
||||
### DNS
|
||||
|
||||
Kubernetes menawarkan sebuah layanan *DNS* kluster tambahan yang secara otomatis memberikan sebuah nama *dns* pada *Service*. Kamu dapat mengecek jika *DNS* berjalan di dalam kluster Kubernetes:
|
||||
Kubernetes menawarkan sebuah layanan *DNS* klaster tambahan yang secara otomatis memberikan sebuah nama *dns* pada *Service*. Kamu dapat mengecek jika *DNS* berjalan di dalam klaster Kubernetes:
|
||||
|
||||
```shell
|
||||
kubectl get services kube-dns --namespace=kube-system
|
||||
@@ -167,7 +167,7 @@ kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
|
||||
|
||||
Jika *DNS* belum berjalan, kamu dapat [mengaktifkannya](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md#how-do-i-configure-it).
|
||||
|
||||
Sisa panduan ini mengasumsikan kamu mempunyai *Service* dengan IP (my-nginx), dan sebuah server *DNS* yang memberikan nama ke dalam IP tersebut (CoreDNS kluster), jadi kamu dapat berkomunikasi dengan *Service* dari *Pod* lain di dalam kluster menggunakan metode standar (contohnya *gethostbyname*). Jalankan aplikasi *curl* lain untuk melakukan pengujian ini:
|
||||
Sisa panduan ini mengasumsikan kamu mempunyai *Service* dengan IP (my-nginx), dan sebuah server *DNS* yang memberikan nama ke dalam IP tersebut (CoreDNS klaster), jadi kamu dapat berkomunikasi dengan *Service* dari *Pod* lain di dalam klaster menggunakan metode standar (contohnya *gethostbyname*). Jalankan aplikasi *curl* lain untuk melakukan pengujian ini:
|
||||
|
||||
```shell
|
||||
kubectl run curl --image=radial/busyboxplus:curl -i --tty
|
||||
@@ -190,7 +190,7 @@ Address 1: 10.0.162.149
|
||||
|
||||
## Mengamankan Service
|
||||
|
||||
Hingga sekarang kita hanya mengakses *nginx* server dari dalam kluster. Sebelum mengekspos *Service* ke internet, kamu harus memastikan bahwa kanal komunikasi aman. Untuk melakukan hal tersebut, kamu membutuhkan:
|
||||
Hingga sekarang kita hanya mengakses *nginx* server dari dalam klaster. Sebelum mengekspos *Service* ke internet, kamu harus memastikan bahwa kanal komunikasi aman. Untuk melakukan hal tersebut, kamu membutuhkan:
|
||||
|
||||
* *Self signed certificates* untuk *https* (kecuali jika kamu sudah mempunyai *identity certificate*)
|
||||
* Sebuah server *nginx* yang terkonfigurasi untuk menggunakan *certificate* tersebut
|
||||
@@ -346,7 +346,7 @@ curl https://<EXTERNAL-IP> -k
|
||||
<title>Welcome to nginx!</title>
|
||||
```
|
||||
|
||||
IP address pada kolom `EXTERNAL-IP` menunjukan IP yang tersedia di internet. Sedangkan kolom `CLUSTER-IP` merupakan IP yang hanya tersedia di dalam kluster kamu (*IP private*).
|
||||
IP address pada kolom `EXTERNAL-IP` menunjukan IP yang tersedia di internet. Sedangkan kolom `CLUSTER-IP` merupakan IP yang hanya tersedia di dalam klaster kamu (*IP private*).
|
||||
|
||||
Perhatikan pada *AWS*, tipe `LoadBalancer` membuat sebuah *ELB*, yang menggunakan *hostname* yang panjang, bukan IP. Karena tidak semua keluar pada standar keluaran `kubectl get svc`. Jadi kamu harus menggunakan `kubectl describe service my-nginx` untuk melihatnya. Kamu akan melihat seperti ini:
|
||||
|
||||
@@ -361,6 +361,6 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak kluster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
|
||||
Kubernetes juga mendukung *Federated Service*, yang bisa mempengaruhi banyak klaster dan penyedia layanan *cloud*, untuk meningkatkan ketersediaan, peningkatan toleransi kesalahan, dan pengembangan dari *Service* kamu. Lihat [Panduan Federated Service](/docs/concepts/cluster-administration/federation-service-discovery/) untuk informasi lebih lanjut.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -11,15 +11,15 @@ Laman ini menyediakan ikhtisar dari dukungan DNS oleh Kubernetes.
|
||||
|
||||
## Pendahuluan
|
||||
|
||||
Kubernetes DNS melakukan _scheduling_ DNS Pod dan Service yang ada pada kluster, serta
|
||||
Kubernetes DNS melakukan _scheduling_ DNS Pod dan Service yang ada pada klaster, serta
|
||||
melakukan konfigurasi kubelet untuk memberikan informasi bagi setiap Container
|
||||
untuk menggunakan DNS Service IP untuk melakukan resolusi DNS.
|
||||
|
||||
### Apa Sajakah yang Mendapatkan Nama DNS?
|
||||
|
||||
Setiap Service yang didefinisikan di dalam kluster (termasuk server DNS itu sendiri)
|
||||
Setiap Service yang didefinisikan di dalam klaster (termasuk server DNS itu sendiri)
|
||||
memiliki nama DNS. Secara default, sebuah _list_ pencarian DNS pada Pod klien
|
||||
akan mencantumkan _namespace_ Pod itu sendiri serta domain _default_ kluster. Hal ini dapat diilustrasikan
|
||||
akan mencantumkan _namespace_ Pod itu sendiri serta domain _default_ klaster. Hal ini dapat diilustrasikan
|
||||
dengan contoh berikut:
|
||||
|
||||
Asumsikan sebuah Service dengan nama `foo` pada Kubernetes dengan _namespace_ `bar`.
|
||||
@@ -39,9 +39,9 @@ terbaru kamu dapat membaca [Service Discovery pada Kubernetes berbasis DNS](http
|
||||
|
||||
Service "Normal" (bukan _headless_) akan diberikan sebuah A _record_ untuk sebuah nama dalam bentuk
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`. Inilah yang kemudian digunakan untuk melakukan
|
||||
resolusi IP kluster dari Service tersebut.
|
||||
resolusi IP klaster dari Service tersebut.
|
||||
|
||||
Service "Headless" (tanpa IP kluster) juga memiliki sebuah A _record_ DNS dengan format
|
||||
Service "Headless" (tanpa IP klaster) juga memiliki sebuah A _record_ DNS dengan format
|
||||
`my-svc.my-namespace.svc.cluster-domain.example`. Tidak seperti halnya Service normal,
|
||||
DNS ini akan melakukan resolusi pada serangkauan IP dari Pod yang dipilih oleh Service tadi.
|
||||
Klien diharapkan untuk mengkonsumsi serangkaian IP ini atau cara lain yang digunakan adalah pemilihan
|
||||
@@ -123,7 +123,7 @@ spec:
|
||||
```
|
||||
|
||||
Jika terdapat sebuah Service _headless_ memiliki nama yang sama dengan
|
||||
subdomain dari suatu Pod pada _namespace_ yang sama, server KubeDNS kluster akan mengembalikan
|
||||
subdomain dari suatu Pod pada _namespace_ yang sama, server KubeDNS klaster akan mengembalikan
|
||||
A _record_ untuk FQDN Pod.
|
||||
Sebagai contoh, misalnya terdapat sebuah Pod dengan _hostname_ "`busybox-1`" dan
|
||||
subdomain "`default-subdomain`", serta sebuah Service _headless_ dengan nama "`default-subdomain`"
|
||||
@@ -154,9 +154,9 @@ dispesifikasikan pada _field_ `dnsPolicy` yang ada pada spek Pod.
|
||||
dimana Pod tersebut dijalankan.
|
||||
Silakan baca [diskusi terkait](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
|
||||
untuk detailnya.
|
||||
- "`ClusterFirst`": _Query_ DNS apa pun yang tidak sesuai dengan sufiks domain kluster yang sudah dikonfigurasi
|
||||
- "`ClusterFirst`": _Query_ DNS apa pun yang tidak sesuai dengan sufiks domain klaster yang sudah dikonfigurasi
|
||||
misalnya "`www.kubernetes.io`", akan di-_forward_ ke _nameserver_ _upstream_ yang diwarisi dari Node.
|
||||
Administrator kluster bisa saja memiliki _stub-domain_ atau DNS _usptream_ lain yang sudah dikonfigurasi.
|
||||
Administrator klaster bisa saja memiliki _stub-domain_ atau DNS _usptream_ lain yang sudah dikonfigurasi.
|
||||
Silakan lihat [diskusi terkait](/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)
|
||||
untuk detail lebih lanjut mengenai bagaimana _query_ DNS melakukan hal tersebut.
|
||||
- "`ClusterFirstWithHostNet`": Untuk Pod yang dijalankan dengan menggunakan `hostNetwork`, kamu harus
|
||||
|
||||
@@ -7,11 +7,11 @@ weight: 40
|
||||
{{% capture overview %}}
|
||||
|
||||
Agar Ingress dapat bekerja sebagaimana mestinya,
|
||||
sebuah kluster harus memiliki paling tidak sebuah kontroler Ingress.
|
||||
sebuah klaster harus memiliki paling tidak sebuah kontroler Ingress.
|
||||
|
||||
Berbeda dengan kontroler-kontroler lainnya yang dijalankan
|
||||
sebagai bagian dari *binary* `kube-controller-manager`, kontroler Ingress
|
||||
tidak secara otomatis dijalankan di dalam kluster. Kamu bisa menggunakan
|
||||
tidak secara otomatis dijalankan di dalam klaster. Kamu bisa menggunakan
|
||||
laman ini untuk memilih implementasi kontroler Ingress yang kamu pikir
|
||||
paling sesuai dengan kebutuhan kamu.
|
||||
|
||||
@@ -52,10 +52,10 @@ Kubernetes sebagai sebuah proyek, saat ini, mendukung dan memaintain kontroler-k
|
||||
## Menggunakan beberapa jenis kontroler Ingress sekaligus
|
||||
|
||||
Kamu dapat melakukan *deploy* [berapa pun banyaknya kontroler Ingress](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)
|
||||
dalam sebuah kluster. Jika kamu ingin membuat Ingress, kamu tinggal memberikan anotasi setiap Ingress sesuai dengan
|
||||
dalam sebuah klaster. Jika kamu ingin membuat Ingress, kamu tinggal memberikan anotasi setiap Ingress sesuai dengan
|
||||
[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)
|
||||
yang sesuai untuk menandai kontroler Ingress mana yang digunakan jika terdapat lebih dari satu kontroler Ingress yang ada di
|
||||
kluster kamu.
|
||||
klaster kamu.
|
||||
|
||||
Apabila kamu tidak mendefinisikan `class` yang dipakai, penyedia layanan *cloud* kamu akan menggunakan kontroler Ingress *default* yang mereka miliki.
|
||||
|
||||
|
||||
@@ -13,16 +13,16 @@ weight: 40
|
||||
|
||||
Untuk memudahkan, di awal akan dijelaskan beberapa terminologi yang sering dipakai:
|
||||
|
||||
* Node: Sebuah mesin fisik atau virtual yang berada di dalam kluster Kubernetes.
|
||||
* Kluster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*.
|
||||
* *Edge router*: Sebuah *router* mengatur *policy firewall* pada kluster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras.
|
||||
* Jaringan kluster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam kluster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/).
|
||||
* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan kluster.
|
||||
* Node: Sebuah mesin fisik atau virtual yang berada di dalam klaster Kubernetes.
|
||||
* Klaster: Sekelompok node yang merupakan *resource* komputasi primer yang diatur oleh Kubernetes, biasanya diproteksi dari internet dengan menggunakan *firewall*.
|
||||
* *Edge router*: Sebuah *router* mengatur *policy firewall* pada klaster kamu. *Router* ini bisa saja berupa *gateway* yang diatur oleh penyedia layanan *cloud* maupun perangkat keras.
|
||||
* Jaringan klaster: Seperangkat *links* baik logis maupus fisik, yang memfasilitasi komunikasi di dalam klaster berdasarkan [model jaringan Kubernetes](/docs/concepts/cluster-administration/networking/).
|
||||
* *Service*: Sebuah [*Service*](/docs/concepts/services-networking/service/) yang mengidentifikasi beberapa *Pod* dengan menggunakan *selector label*. Secara umum, semua *Service* diasumsikan hanya memiliki IP virtual yang hanya dapat diakses dari dalam jaringan klaster.
|
||||
|
||||
## Apakah *Ingress* itu?
|
||||
|
||||
Ingress ditambahkan sejak Kubernetes v1.1, mengekspos rute HTTP dan HTTPS ke berbagai
|
||||
{{< link text="services" url="/docs/concepts/services-networking/service/" >}} di dalam kluster.
|
||||
{{< link text="services" url="/docs/concepts/services-networking/service/" >}} di dalam klaster.
|
||||
Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pada *Ingress*.
|
||||
|
||||
```none
|
||||
@@ -33,7 +33,7 @@ Mekanisme *routing* trafik dikendalikan oleh aturan-aturan yang didefinisikan pa
|
||||
[ Services ]
|
||||
```
|
||||
|
||||
Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar kluster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama.
|
||||
Sebuah *Ingress* dapat dikonfigurasi agar berbagai *Service* memiliki URL yang dapat diakses dari eksternal (luar klaster), melakukan *load balance* pada trafik, terminasi SSL, serta Virtual Host berbasis Nama.
|
||||
Sebuah [kontroler Ingress](/docs/concepts/services-networking/ingress-controllers) bertanggung jawab untuk menjalankan fungsi Ingress yaitu sebagai *loadbalancer*, meskipun dapat juga digunakan untuk mengatur *edge router* atau *frontend* tambahan untuk menerima trafik.
|
||||
|
||||
Sebuah *Ingress* tidak mengekspos sembarang *port* atau protokol. Mengekspos *Service* untuk protokol selain HTTP ke HTTPS internet biasanya dilakukan dengan menggunakan
|
||||
@@ -450,7 +450,7 @@ Ingress yang ingin diubah.
|
||||
Teknik untuk menyeimbangkan persebaran trafik pada *failure domain* berbeda antar penyedia layanan *cloud*.
|
||||
Kamu dapat mempelajari dokumentasi yang relevan bagi [kontoler Ingress](/docs/concepts/services-networking/ingress-controllers)
|
||||
untuk informasi yang lebih detail. Kamu juga dapat mempelajari [dokumentasi federasi](/docs/concepts/cluster-administration/federation/)
|
||||
untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi kluster.
|
||||
untuk informasi lebih detail soal bagaimana melakukan *deploy* untuk federasi klaster.
|
||||
|
||||
## Pengembangan selanjutnya
|
||||
|
||||
|
||||
@@ -151,9 +151,9 @@ menginterpretasikan _policy_ tersebut.
|
||||
|
||||
**ipBlock**: Ini digunakan untuk memilih _range_ IP CIDR tertentu untuk berperan sebagai
|
||||
_source_ _ingress_ atau destinasi _egress_. Alamat yang digunakan harus merupakan
|
||||
alamat IP eksternal kluster, karena alamat IP Pod bersifat _ephemeral_ dan tidak dapat ditebak.
|
||||
alamat IP eksternal klaster, karena alamat IP Pod bersifat _ephemeral_ dan tidak dapat ditebak.
|
||||
|
||||
Mekanisme _ingress_ dan _egress_ kluster seringkali membutuhkan mekanisme _rewrite_ alamat IP _source_ dan destinasi
|
||||
Mekanisme _ingress_ dan _egress_ klaster seringkali membutuhkan mekanisme _rewrite_ alamat IP _source_ dan destinasi
|
||||
paket. Pada kasus-kasus dimana hal ini, tidak dapat dipastikan bahwa apakah hal ini
|
||||
terjadi sebelum atau setelah pemrosesan `NetworkPolicy`, dan perilaku yang ada mungkin saja berbeda
|
||||
untuk kombinasi _plugin_ jaringan, penyedia layanan _cloud_, serta implementasi `Service` yang berbeda.
|
||||
@@ -162,7 +162,7 @@ Pada _ingress_, artinya bisa saja kamu melakukan _filter_ paket yang masuk berda
|
||||
sementara di kasus lain "source IP" yang digunakan oleh Network Policy adalah alamat IP `LoadBalancer`,
|
||||
_node_ dimana Pod berada, dsb.
|
||||
|
||||
Pada _egress_, bisa saja sebuah koneksi dari Pod ke IP `Service` di-_rewrite_ ke IP eksternal kluster
|
||||
Pada _egress_, bisa saja sebuah koneksi dari Pod ke IP `Service` di-_rewrite_ ke IP eksternal klaster
|
||||
atau bahkan tidak termasuk di dalam `ipBlock` _policy_.
|
||||
|
||||
## _Policy_ _Default_
|
||||
@@ -270,7 +270,7 @@ Hal ini menjamin bahwa bahkan Pod yang tidak dipilih oleh `NetworkPolicy` tidak
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
|
||||
|
||||
Kubernetes mendukung SCTP sebagai _value_ `protocol` pada definisi `NetworkPolicy` sebagai fitur alpha. Untuk mengaktifkan fitur ini, administrator kluster harus mengaktifkan gerbang fitur `SCTPSupport` pada `apiserver`, contohnya `“--feature-gates=SCTPSupport=true,...”`. Ketika gerbang fitur ini diaktifkan, pengguna dapat menerapkan `value` dari _field_ `protocol` pada `NetworkPolicy` menjadi `SCTP`. Kubernetes akan mengatur jaringan sesuai dengan SCTP, seperti halnya koneksi TCP.
|
||||
Kubernetes mendukung SCTP sebagai _value_ `protocol` pada definisi `NetworkPolicy` sebagai fitur alpha. Untuk mengaktifkan fitur ini, administrator klaster harus mengaktifkan gerbang fitur `SCTPSupport` pada `apiserver`, contohnya `“--feature-gates=SCTPSupport=true,...”`. Ketika gerbang fitur ini diaktifkan, pengguna dapat menerapkan `value` dari _field_ `protocol` pada `NetworkPolicy` menjadi `SCTP`. Kubernetes akan mengatur jaringan sesuai dengan SCTP, seperti halnya koneksi TCP.
|
||||
|
||||
_Plugin_ CNI harus mendukung SCTP sebagai _value_ dari `protocol` pada `NetworkPolicy`.
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ Meskipun setiap `Pod` memiliki alamat IP-nya masing-masing, kamu tidak dapat men
|
||||
yang diberikan pada _pod-pod_ tersebut, karena alamat IP yang diberikan tidak stabil.
|
||||
Hal ini kemudian menimbulkan pertanyaan baru: apabila sebuah sekumpulan `Pod` (yang selanjutnya kita sebut _backend_)
|
||||
menyediakan _service_ bagi sebuah sekumpulan `Pod` lain (yang selanjutnya kita sebut _frontend_) di dalam
|
||||
kluster Kubernetes, bagaimana cara _frontend_ menemukan _backend_ mana yang digunakan?
|
||||
klaster Kubernetes, bagaimana cara _frontend_ menemukan _backend_ mana yang digunakan?
|
||||
|
||||
Inilah alasan kenapa `Service` ada.
|
||||
|
||||
@@ -95,9 +95,9 @@ mereka juga melakukan abstraksi bagi _backend_ lainnya. Misalnya saja:
|
||||
* Kamu ingin memiliki sebuah basis data eksternal di _environment_ _production_ tapi pada tahap _test_,
|
||||
kamu ingin menggunakan basis datamu sendiri.
|
||||
* Kamu ingin merujuk _service_ kamu pada _service_ lainnya yang berada pada
|
||||
[_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan kluster yang berbeda.
|
||||
[_Namespace_](/docs/concepts/overview/working-with-objects/namespaces/) yang berbeda atau bahkan klaster yang berbeda.
|
||||
* Kamu melakukan migrasi _workloads_ ke Kubernetes dan beberapa _backend_ yang kamu miliki masih
|
||||
berada di luar kluster Kubernetes.
|
||||
berada di luar klaster Kubernetes.
|
||||
|
||||
Berdasarkan skenario-skenario di atas, kamu dapat membuat sebuah `Service` tanpa _selector_:
|
||||
|
||||
@@ -145,7 +145,7 @@ informasi lebih lanjut silahkan baca bagian [ExternalName](#externalname).
|
||||
|
||||
## IP Virtual dan _proxy_ `Service`
|
||||
|
||||
Setiap *node* di kluster Kubernetes menjalankan `kube-proxy`. `kube-proxy`
|
||||
Setiap *node* di klaster Kubernetes menjalankan `kube-proxy`. `kube-proxy`
|
||||
bertanggung jawab terhadap implementasi IP virtual bagi _Services_ dengan tipe
|
||||
selain [`ExternalName`](#externalname).
|
||||
|
||||
@@ -322,7 +322,7 @@ Meskipun begitu, DNS tidak memiliki keterbatasan ini.
|
||||
Salah satu [_add-on_](/docs/concepts/cluster-administration/addons/) opsional
|
||||
(meskipun sangat dianjurkan) adalah server DNS. Server DNS bertugas untuk mengamati apakah
|
||||
terdapat objek `Service` baru yang dibuat dan kemudian bertugas menyediakan DNS baru untuk
|
||||
_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh kluster, maka semua `Pod` akan secara otomatis
|
||||
_Service_ tersebut. Jika DNS ini diaktifkan untuk seluruh klaster, maka semua `Pod` akan secara otomatis
|
||||
dapat melakukan resolusi DNS.
|
||||
|
||||
Sebagai contoh, apabila kamu memiliki sebuah `Service` dengan nama `"my-service"` pada _Namespace_
|
||||
@@ -376,7 +376,7 @@ sistem DNS tetap melakukan konfigurasi salah satu dari:
|
||||
|
||||
Untuk beberapa bagian dari aplikasi yang kamu miliki (misalnya saja, _frontend_),
|
||||
bisa saja kamu memiliki kebutuhan untuk mengekspos `Service` yang kamu miliki
|
||||
ke alamat IP eksternal (di luar kluster Kubernetes).
|
||||
ke alamat IP eksternal (di luar klaster Kubernetes).
|
||||
|
||||
`ServiceTypes` yang ada pada Kubernetes memungkinkan kamu untuk menentukan
|
||||
jenis `Service` apakah yang kamu butuhkan. Secara _default_, jenis `Service`
|
||||
@@ -384,13 +384,13 @@ yang diberikan adalah `ClusterIP`.
|
||||
|
||||
_Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut:
|
||||
|
||||
* `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam kluster. Apabila kamu memilih _value_ ini
|
||||
* `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam klaster. Apabila kamu memilih _value_ ini
|
||||
`Service` yang kamu miliki hanya dapat diakses secara internal. tipe ini adalah
|
||||
_default_ _value_ dari _ServiceType_.
|
||||
* [`NodePort`](#nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis
|
||||
atau _port_ yang sama. Sebuah `Service` `ClusterIP`, yang mana `Service` `NodePort` akan di-_route_
|
||||
, dibuat secara otomatis. Kamu dapat mengakses `Service` dengan tipe ini,
|
||||
dari luar kluster melalui `<NodeIP>:<NodePort>`.
|
||||
dari luar klaster melalui `<NodeIP>:<NodePort>`.
|
||||
* [`LoadBalancer`](#loadbalancer): Mengekspos `Service` secara eksternal dengan menggunakan `LoadBalancer`
|
||||
yang disediakan oleh penyedia layanan _cloud_. `Service` dengan tipe `NodePort` dan `ClusterIP`,
|
||||
dimana trafik akan di-_route_, akan dibuat secara otomatis.
|
||||
@@ -463,12 +463,12 @@ tetapi penyedia layanan _cloud_ tidak mendukung hal ini, maka _field_ yang ada a
|
||||
|
||||
**Catatan Khusus untuk Azure**: Untuk spesifikasi `loadBalancerIP` publik yang didefinisikan oleh pengguna,
|
||||
sebuah alamat IP statis publik akan disediakan terlebih dahulu, dan alamat IP tersebut harus berada di
|
||||
_resource group_ dari _resource_ yang secara otomatis dibuat oleh kluster. Misalnya saja, `MC_myResourceGroup_myAKSCluster_eastus`.
|
||||
_resource group_ dari _resource_ yang secara otomatis dibuat oleh klaster. Misalnya saja, `MC_myResourceGroup_myAKSCluster_eastus`.
|
||||
Berikan spesifikasi alamat IP sebagai `loadBalancerIP`. Pastikan kamu sudah melakukan _update_ pada
|
||||
_securityGroupName_ pada _file_ konfigurasi penyedia layanan _cloud_.
|
||||
Untuk informasi lebih lanjut mengenai _permission_ untuk `CreatingLoadBalancerFailed` kamu dapat membaca _troubleshooting_ untuk
|
||||
[Penggunaan alamat IP statis pada _load balancer_ Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/static-ip) atau
|
||||
[_CreatingLoadBalancerFailed_ pada kluster AKS dengan _advanced networking_](https://github.com/Azure/AKS/issues/357).
|
||||
[_CreatingLoadBalancerFailed_ pada klaster AKS dengan _advanced networking_](https://github.com/Azure/AKS/issues/357).
|
||||
|
||||
{{< note >}}
|
||||
Dukungan untuk SCTP _load balancer_ dari penyedia layanan _cloud_ bergantung pada
|
||||
@@ -547,7 +547,7 @@ metadata:
|
||||
|
||||
|
||||
#### Dukungan untuk SSL di AWS
|
||||
Dukungan parsial untuk SSL bagi kluster yang dijalankan di AWS mulai diterapkan,
|
||||
Dukungan parsial untuk SSL bagi klaster yang dijalankan di AWS mulai diterapkan,
|
||||
mulai versi 1.3 terdapat 3 anotasi yang dapat ditambahkan pada `Service` dengan tipe
|
||||
`LoadBalancer`:
|
||||
|
||||
@@ -616,7 +616,7 @@ _Policy_ ini kemudian dapat dispesifikasikan menggunakan anotasi
|
||||
#### Protokol PROXY pada AWS
|
||||
|
||||
Untuk mengaktifkan dukungan [protokol PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)
|
||||
untuk kluster yang dijalankan di AWS, kamu dapat menggunakan anotasi di bawah ini:
|
||||
untuk klaster yang dijalankan di AWS, kamu dapat menggunakan anotasi di bawah ini:
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
@@ -806,11 +806,11 @@ Untuk melakukan _hardcode_ alamat IP, kamu dapat menggunakan _headless_ `Service
|
||||
{{< /note >}}
|
||||
|
||||
Ketika melakukan pencarian _host_ `my-service.prod.svc.cluster.local`,
|
||||
servis DNS kluster akan mengembalikan _record_ `CNAME` dengan _value_ `my.database.example.com`.
|
||||
servis DNS klaster akan mengembalikan _record_ `CNAME` dengan _value_ `my.database.example.com`.
|
||||
Mekanisme akses pada `my-service` bekerja dengan cara yang sama dengan
|
||||
`Service` pada umumnya, perbedaan yang krusial untuk hal ini adalah mekanisme _redirection_
|
||||
terjadi pada tingkatan DNS dan bukan melalui _proxy forward_. Apabila kamu berniat memindahkan basis data
|
||||
yang kamu pakai ke dalam kluster, kamu hanya perlu mengganti instans basis data kamu dan menjalankannya
|
||||
yang kamu pakai ke dalam klaster, kamu hanya perlu mengganti instans basis data kamu dan menjalankannya
|
||||
di dalam `Pod`, menambahkan _selector_ atau _endpoint_ yang sesuai, serta mengupah _type_ dari
|
||||
_Service_ yang kamu gunakan.
|
||||
|
||||
@@ -821,11 +821,11 @@ Bagian ini berasal dari tulisan [Tips Kubernetes - Bagian
|
||||
|
||||
### IP Eksternal
|
||||
|
||||
Jika terdapat sebuah alamat IP eksternal yang melakukan mekanisme _route_ ke satu atau lebih _node_ yang ada di kluster, `Service` Kubernetes dapat diekspos
|
||||
dengan menggunakan `externalIP`. Trafik yang diarahkan ke kluster dengan IP eksternal
|
||||
Jika terdapat sebuah alamat IP eksternal yang melakukan mekanisme _route_ ke satu atau lebih _node_ yang ada di klaster, `Service` Kubernetes dapat diekspos
|
||||
dengan menggunakan `externalIP`. Trafik yang diarahkan ke klaster dengan IP eksternal
|
||||
(sebagai destinasi IP), pada _port_ `Service` akan di-_route_ ke salah satu _endpoint_ `Service`.
|
||||
_Value_ dari `externalIP` tidak diatur oleh Kubernetes dan merupakan tanggung jawab
|
||||
dari administrator kluster.
|
||||
dari administrator klaster.
|
||||
|
||||
Pada _ServiceSpec_, kamu dapat memberikan spesifikasi `externalIP` dan `ServiceTypes`.
|
||||
Pada contoh di bawah ini. `"my-service"` dapat diakses oleh klien pada "`80.11.12.10:80`" (`externalIP:port`).
|
||||
@@ -850,13 +850,13 @@ spec:
|
||||
## Kekurangan
|
||||
|
||||
Penggunaan _proxy_ _userspace_ untuk VIP dapat digunakan untuk skala kecil hingga menengah,
|
||||
meski begitu hal ini tidak _scalable_ untuk kluster yang sangat besar dan memiliki ribuan `Service`.
|
||||
meski begitu hal ini tidak _scalable_ untuk klaster yang sangat besar dan memiliki ribuan `Service`.
|
||||
Perhatikan [Desain proposal orisinil untuk _portal_](http://issue.k8s.io/1107) untuk informasi
|
||||
lebih lanjut.
|
||||
|
||||
Penggunaan _proxy_ _userspace_ menghilangkan _source-IP_ dari _packet_ yang mengakses
|
||||
sebuah `Service`. Hal ini membuat mekanisme _firewall_ menjadi sulit untuk diterapkan.
|
||||
_Proxy_ `iptables` tidak menghilangkan _source IP_ yang berasal dari dalam kluster,
|
||||
_Proxy_ `iptables` tidak menghilangkan _source IP_ yang berasal dari dalam klaster,
|
||||
meski begitu, hal ini masih berimbas pada klien yang berasal dari `Service` dengan tipe
|
||||
_load-balancer_ atau _node-port_.
|
||||
|
||||
@@ -924,7 +924,7 @@ perbedaan cara kerja satu sama lainnya.
|
||||
Sebagai contoh, anggaplah kita memiliki aplikasi _image processing_ seperti yang sudah
|
||||
disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan
|
||||
sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_,
|
||||
maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di kluster.
|
||||
maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di klaster.
|
||||
Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan membuka sebuah _port_
|
||||
_acak_, menyediakan `iptables` yang mengarahkan VIP pada _port_ yang baru saja dibuat, dan mulai
|
||||
koneksi pada _port_ tersebut.
|
||||
@@ -943,7 +943,7 @@ tanpa harus mengetahui `Pod` mana yang sebenarnya diakses.
|
||||
Kembali, bayangkan apabila kita memiliki aplikasi _image processing_ seperti yang sudah
|
||||
disebutkan di atas. Ketika `Service` _backend_ dibuat, _master_ Kubernetes akan mengalokasikan
|
||||
sebuah alamat IP virtual, misalnya 10.0.0.1. Dengan asumsi _port_ dari `Service` tersebut adalah _1234_,
|
||||
maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di kluster.
|
||||
maka `Service` tersebut akan diamati oleh semua _instance_ `kube-proxy` yang ada di klaster.
|
||||
Ketika sebuah _proxy_ mendapati sebuah `Service` baru, _proxy_ tersebut akan melakukan instalasi
|
||||
serangkaian _rules_ `iptables` yang akan melakukan _redirect_ VIP ke _rules_ tiap `Service`. _Rules_
|
||||
untuk tiap `Service` ini terkait dengan _rules_ tiap `Endpoints` yang mengarahkan (destinasi NAT)
|
||||
@@ -960,7 +960,7 @@ atau _load-balancer_, meskipun pada dua kasus di atas klien IP tidak akan mengal
|
||||
|
||||
#### _Ipvs_
|
||||
|
||||
Operasi `iptables` berlangsung secara lambat pada kluster dengan skala besar (lebih dari 10.000 `Service`).
|
||||
Operasi `iptables` berlangsung secara lambat pada klaster dengan skala besar (lebih dari 10.000 `Service`).
|
||||
_IPVS_ didesain untuk mekanisme _load balance_ dan berbasis pada _hash tables_ yang berada di dalam _kernel_.
|
||||
Dengan demikian kita dapat mendapatkan performa yang konsisten pada jumlah `Service` yang cukup besar dengan
|
||||
menggunakan `kube-proxy` berbasis _ipvs_. Sementara itu, `kube-proxy` berbasis _ipvs_ memiliki algoritma
|
||||
@@ -1025,7 +1025,7 @@ yang kemudian diikuti data dari klien.
|
||||
|
||||
Kubernetes memberikan dukungan bagi SCTP sebagai _value_ dari _definition_ yang ada pada
|
||||
_Service_, `Endpoints`, `NetworkPolicy` dan `Pod` sebagai fitur _alpha_. Untuk mengaktifkan fitur ini,
|
||||
administrator kluster harus mengaktifkan _feature gate_ _SCTPSupport_ pada _apiserver_, contohnya
|
||||
administrator klaster harus mengaktifkan _feature gate_ _SCTPSupport_ pada _apiserver_, contohnya
|
||||
`“--feature-gates=SCTPSupport=true,...”`. Ketika _fature gate_ ini diaktifkan, pengguna dapat
|
||||
memberikan _value_ SCTP pada _field_ _protocol_ `Service`, `Endpoints`, `NetworkPolicy` dan `Pod`.
|
||||
Kubernetes kemudian akan melakukan pengaturan agar jaringan yang digunakan agar jaringan tersebut menggunakan SCTP,
|
||||
|
||||
Reference in New Issue
Block a user