Phenquestions
- Aplikasi yang di-deploy di Cluster Kubernetes berjalan sebagai pod koleksi.
- Pod pada dasarnya adalah container yang dijadwalkan di beberapa node.
- Node dapat berupa server fisik atau VM yang ditawarkan oleh penyedia hosting Anda. Jelas, Anda juga dapat Kubernetes di server lokal, jika Anda menginginkannya.
- Setiap Pod memiliki alamat IP yang unik.
- Aplikasi Anda dibagi menjadi banyak subkomponen, sering disebut sebagai layanan mikro.
- Untuk setiap layanan mikro aplikasi Anda, memiliki Layanan yang sesuai di Kubernetes.
- Dalam konteks Kubernetes, a Layanan mengekspos koleksi pod ke seluruh cluster sebagai abstraksi tunggal. Satu IP virtual.
- Ini membantu satu layanan aplikasi Anda berkomunikasi dengan layanan lain. Ini adalah abstraksi yang memungkinkan Anda untuk menangani kumpulan pod, daripada menentukan alamat IP pod, setiap kali Anda ingin berbicara dengannya.
- Layanan Kubernetes juga bertindak sebagai penyeimbang beban untuk semua pod yang diwakilinya. Lalu lintas didistribusikan secara merata di semua node.
Sejauh ini bagus. Setiap Layanan dapat berbicara dengan layanan lain. Komunikasi ini dimungkinkan di seluruh cluster Kubernetes
Mengekspos Layanan
“Jika pohon tumbang di hutan dan tidak ada orang di sekitar untuk mendengarnya, apakah itu mengeluarkan suara??”
Demikian pula, jika aplikasi Anda tidak melayani tujuan di luar cluster Kubernetes, apakah penting apakah cluster Anda dibangun dengan baik atau tidak? Mungkin tidak.
Untuk memberikan contoh konkret, katakanlah kita memiliki aplikasi web klasik yang terdiri dari frontend yang ditulis dalam Nodejs dan backend yang ditulis dengan Python yang menggunakan database MySQL. Anda menerapkan dua layanan yang sesuai di cluster Kubernetes Anda.
Anda membuat Dockerfile yang menentukan cara mengemas perangkat lunak frontend ke dalam wadah, dan Anda juga mengemas backend Anda your. Selanjutnya di cluster Kubernetes Anda, Anda akan menerapkan dua layanan yang masing-masing menjalankan satu set pod di belakangnya. Layanan web dapat berbicara dengan cluster database dan sebaliknya.
Namun, Kubernetes tidak mengekspos layanan ini (yang merupakan titik akhir HTTP penting) ke seluruh dunia. Seperti yang dinyatakan dalam dokumen resmi:
“Layanan diasumsikan memiliki IP virtual yang hanya dapat dirutekan dalam jaringan cluster cluster”
Ini sangat masuk akal dari sudut pandang keamanan, layanan Anda dapat berbicara satu sama lain, tetapi cluster tidak akan mengizinkan entitas luar untuk berbicara dengan layanan secara langsung. Misalnya, hanya frontend web Anda yang dapat berbicara dengan layanan database, dan tidak ada orang lain yang bahkan dapat mengirim permintaan ke layanan database.
Masalah muncul ketika kita melihat kasus penggunaan layanan frontend. Itu perlu diekspos ke Publik lainnya sehingga pengguna akhir dapat menggunakan aplikasi Anda. Kami mengekspos Layanan tersebut menggunakan Kubernetes Ingress.
Masuknya Kubernetes
Ingress mengekspos rute HTTP dan HTTPS dari luar cluster ke layanan di dalam cluster. Anda dapat mengontrol aturan perutean dengan mendefinisikan sumber daya Kubernetes Ingress. Tapi itu lebih dari itu. Mengekspos Layanan tunggal dapat dicapai dengan menggunakan berbagai alternatif lain seperti NodePort atau Load Balancers tetapi fasilitas ini tidak memiliki fitur yang cukup canggih untuk aplikasi web modern.
Fitur seperti, mengekspos beberapa aplikasi pada satu IP, menentukan rute, dll.
Jadi mari kita pahami fitur-fitur ini untuk sisa artikel:
Masuknya Layanan Tunggal
Ini adalah versi paling sederhana untuk mengekspos satu layanan seperti antarmuka web dengan IP (atau nama domain) dan port HTTP dan HTTPS default (mis.e, 80 dan 443).
Fanout Tunggal
Ini adalah pengaturan masuk yang memungkinkan Anda mengizinkan lalu lintas masuk ke satu IP dan merutekannya ke beberapa layanan.
Terdiri dari:
- Sumber daya masuk terdiri dari nama host foo.batang.com
- Daftar jalur di mana lalu lintas akan diarahkan seperti foo.batang.com/admin foo.batang.com/home foo.batang.com/sso
Fanout tunggal adalah kasus di mana satu IP digunakan untuk beberapa layanan. Layanan dapat berada di jalur yang berbeda di URI seperti foo.batang.com/admin dapat menjadi layanan untuk administrator dan foo.batang.com/home dapat menjadi layanan yang menghasilkan halaman beranda setiap pengguna.
Port masuk akan selalu 80 atau 443, tetapi port tempat layanan berjalan (di dalam cluster) mungkin sedikit berbeda.
Ingress semacam ini membantu kami meminimalkan jumlah load balancer di cluster, karena pada dasarnya bertindak seperti satu.
Hosting Virtual Berbasis Nama
Alamat IP publik terbatas. Mereka juga cukup mahal. Ide hosting virtual berbasis nama lebih tua dari Kubernetes. Intinya adalah, Anda mengarahkan catatan DNS untuk situs web yang berbeda seperti ww1.contoh.com dan ww2.contoh.com ke alamat IP yang sama. Server yang berjalan pada alamat IP tersebut akan melihat permintaan yang masuk, dan jika nama host yang disebutkan dalam permintaan adalah untuk ww1.contoh.com maka itu melayani situs web itu untuk Anda, dan jika ww2.contoh.com diminta, lalu dilayani.
Dalam konteks Kubernetes, kita dapat menjalankan dua layanan yang berjalan pada, katakanlah, port 80 dan mengekspos keduanya pada satu alamat IP menggunakan ingress juga dari port 80. Di titik masuk lalu lintas ww1.contoh.com akan dipisahkan dari lalu lintas untuk ww2.contoh.com. Karenanya istilah hosting virtual berbasis nama name.
Kesimpulan
Ingress di Kubernetes cukup canggih untuk dibahas dalam satu postingan. Ada berbagai kasus penggunaan untuk itu, dan berbagai Pengontrol Ingress yang akan menambahkan fungsionalitas Ingress ke cluster Anda. Saya akan merekomendasikan memulai dengan Nginx Ingress Controller.
Untuk detail dan spesifikasi lebih lanjut, Anda juga dapat mengikuti dokumentasi resmi.
