Konsep jaringan untuk aplikasi di Azure Kubernetes Service (AKS)
Dalam pendekatan layanan mikro berbasis kontainer untuk pengembangan aplikasi, komponen aplikasi bekerja sama untuk memproses tugas mereka. Kubernetes menyediakan berbagai sumber daya yang memungkinkan kerja sama ini:
- Anda dapat menyambungkan dan mengekspos aplikasi secara internal atau eksternal.
- Anda dapat membuat aplikasi yang sangat tersedia dengan menyeimbangkan beban aplikasi Anda.
- Anda dapat membatasi arus lalu lintas jaringan ke atau antara pod dan simpul untuk meningkatkan keamanan.
- Anda dapat mengonfigurasi lalu lintas Ingress untuk penghentian SSL/TLS atau perutean beberapa komponen untuk aplikasi Anda yang lebih kompleks.
Artikel ini memperkenalkan konsep inti yang menyediakan penyimpanan untuk aplikasi Anda di AKS:
Dasar-dasar jaringan Kubernetes
Kubernetes menggunakan lapisan jaringan virtual untuk mengelola akses di dalam dan antara aplikasi Anda atau komponennya:
Simpul Kubernetes dan jaringan virtual: Simpul Kubernetes terhubung ke jaringan virtual. Penyiapan ini memungkinkan pod (unit dasar penyebaran di Kubernetes) memiliki konektivitas masuk dan keluar.
Komponen kube-proxy: kube-proxy berjalan pada setiap node dan bertanggung jawab untuk menyediakan fitur jaringan yang diperlukan.
Mengenai fungsionalitas Kubernetes tertentu:
- Load balancer: Anda dapat menggunakan load balancer untuk mendistribusikan lalu lintas jaringan secara merata di berbagai sumber daya.
- Pengontrol Ingress: Ini memfasilitasi perutean Lapisan 7, yang penting untuk mengarahkan lalu lintas aplikasi.
- Kontrol lalu lintas keluar: Kubernetes memungkinkan Anda mengelola dan mengontrol lalu lintas keluar dari node kluster.
- Kebijakan jaringan: Kebijakan ini memungkinkan langkah-langkah keamanan dan pemfilteran untuk lalu lintas jaringan dalam pod.
Dalam konteks platform Azure:
- Azure menyederhanakan jaringan virtual untuk kluster AKS (Azure Kubernetes Service).
- Membuat load balancer Kubernetes di Azure secara bersamaan menyiapkan sumber daya penyeimbang beban Azure yang sesuai.
- Saat Anda membuka port jaringan ke pod, Azure secara otomatis mengonfigurasi aturan grup keamanan jaringan yang diperlukan.
- Azure juga dapat mengelola konfigurasi DNS eksternal untuk perutean aplikasi HTTP saat rute Ingress baru dibuat.
Jaringan virtual Azure
Di AKS, Anda dapat menyebarkan kluster yang menggunakan salah satu model jaringan berikut:
Jaringan Kubenet
Sumber daya jaringan biasanya dibuat dan dikonfigurasi saat klaster AKS disebarkan.
Jaringan Azure Container Networking Interface (CNI)
Klaster AKS terhubung ke sumber daya dan konfigurasi jaringan virtual yang ada.
Jaringan Kubenet (dasar)
Opsi jaringan kubenet adalah konfigurasi default untuk pembuatan klaster AKS. Dengan kubenet:
- Node menerima alamat IP dari subnet jaringan virtual Azure.
- Pod menerima alamat IP dari ruang alamat yang berbeda secara logis ke subnet jaringan virtual Azure dari node.
- Terjemahan alamat jaringan (NAT) kemudian dikonfigurasi sehingga Pod dapat menjangkau sumber daya pada jaringan virtual Azure.
- Alamat IP sumber traffic diterjemahkan ke alamat IP utama node.
Node menggunakan plugin Kubenet Kubernetes. Anda dapat membiarkan platform Azure membuat dan mengonfigurasi jaringan virtual untuk Anda, atau memilih untuk menyebarkan kluster AKS Anda ke subnet jaringan virtual yang ada.
Hanya simpul yang menerima alamat IP yang dapat dirutekan. Pod-pod tersebut menggunakan NAT untuk berkomunikasi dengan sumber daya lain di luar klaster AKS. Pendekatan ini mengurangi jumlah alamat IP yang perlu Anda pesan di ruang jaringan untuk digunakan pod.
Catatan
Meskipun kubenet adalah opsi jaringan default untuk kluster AKS untuk membuat jaringan virtual dan subnet, tidak disarankan untuk penyebaran produksi. Untuk sebagian besar penyebaran produksi, Anda harus merencanakan dan menggunakan jaringan Azure CNI karena skalabilitas dan karakteristik performa yang unggul.
Untuk informasi lebih lanjut, lihat Mengonfigurasi jaringan kubenet untuk klaster AKS.
Jaringan Azure CNI (tingkat lanjut)
Dengan Azure CNI, setiap pod mendapatkan alamat IP dari subnet dan dapat diakses secara langsung. Alamat IP ini harus unik di seluruh ruang jaringan Anda, dan harus direncanakan terlebih dahulu. Setiap node memiliki parameter konfigurasi untuk jumlah maksimum pod yang didukungnya. Jumlah alamat IP yang setara per node kemudian dicadangkan di depan. Pendekatan ini dapat menyebabkan kelelahan alamat IP atau kebutuhan untuk membangun kembali kluster dalam subnet yang lebih besar saat permintaan aplikasi Anda tumbuh, jadi penting untuk merencanakan dengan benar. Untuk menghindari tantangan perencanaan ini, dimungkinkan untuk mengaktifkan fitur jaringan Azure CNI untuk alokasi IP dinamis dan dukungan subnet yang ditingkatkan.
Catatan
Karena keterbatasan Kubernetes, nama Grup Sumber Daya, nama Virtual Network dan nama subnet harus 63 karakter atau kurang.
Tidak seperti kubenet, lalu lintas ke titik akhir di jaringan virtual yang sama tidak diterjemahkan (NAT) ke IP utama simpul. Alamat sumber untuk traffic di dalam jaringan virtual adalah POD IP. traffic yang berada di luar jaringan virtual masih NATs ke IP utama node.
Node menggunakan plugin Azure CNI Kubernetes.
Untuk informasi selengkapnya, lihat Mengonfigurasi Azure CNI untuk klaster AKS.
Jaringan Overlay Azure CNI
Azure CNI Overlay mewakili evolusi Azure CNI, mengatasi tantangan skalabilitas dan perencanaan yang timbul dari penugasan IP jaringan virtual ke pod. Azure CNI Overlay menetapkan IP CIDR privat ke pod. IP privat terpisah dari jaringan virtual dan dapat digunakan kembali di beberapa kluster. Azure CNI Overlay dapat menskalakan melebihi batas 400 simpul yang diberlakukan dalam kluster Kubenet. Azure CNI Overlay adalah opsi yang direkomendasikan untuk sebagian besar kluster.
Azure CNI Didukung oleh Cilium
Azure CNI Powered by Cilium menggunakan Cilium untuk menyediakan jaringan berkinerja tinggi, pengamatan, dan penegakan kebijakan jaringan. Ini terintegrasi secara asli dengan Azure CNI Overlay untuk manajemen alamat IP (IPAM) yang dapat diskalakan.
Selain itu, Cilium memberlakukan kebijakan jaringan secara default, tanpa memerlukan mesin kebijakan jaringan terpisah. Azure CNI Powered by Cilium dapat menskalakan melebihi batas 250 node/20-K Pod Azure Network Policy Manager dengan menggunakan program eBPF dan struktur objek API yang lebih efisien.
Azure CNI Powered by Cilium adalah opsi yang direkomendasikan untuk kluster yang memerlukan penegakan kebijakan jaringan.
Bawa CNI Anda sendiri
Dimungkinkan untuk menginstal di AKS CNI non-Microsoft menggunakan fitur Bring your own CNI .
Bandingkan model jaringan
Baik kubenet maupun Azure CNI menyediakan konektivitas jaringan untuk klaster AKS Anda. Namun, ada kelebihan dan kekurangan masing-masing. Pada tingkat tinggi, pertimbangan berikut berlaku:
kubenet
- Menghemat ruang alamat IP.
- Menggunakan load balancer internal atau eksternal Kubernetes untuk menjangkau pod dari luar kluster.
- Anda mengelola dan memelihara rute (UDR) yang ditentukan pengguna secara manual.
- Maksimum 400 node per klaster.
Azure CNI
- Pod mendapatkan konektivitas jaringan virtual penuh dan dapat langsung dijangkau melalui alamat IP pribadi mereka dari jaringan yang terhubung.
- Membutuhkan lebih banyak ruang alamat IP.
| Model jaringan | Waktu menggunakan |
|---|---|
| Kubenet | • Percakapan ruang alamat IP adalah prioritas. • Konfigurasi sederhana. • Kurang dari 400 simpul per kluster. • Load balancer internal atau eksternal Kubernetes cukup untuk mencapai pod dari luar kluster. • Mengelola dan memelihara rute yang ditentukan pengguna secara manual dapat diterima. |
| Azure CNI | • Konektivitas jaringan virtual penuh diperlukan untuk Pod. • Fitur AKS tingkat lanjut (seperti simpul virtual) diperlukan. • Ruang alamat IP yang cukup tersedia. • Pod ke pod dan pod ke konektivitas komputer virtual diperlukan. • Sumber daya eksternal perlu menjangkau pod secara langsung. • Kebijakan jaringan AKS diperlukan. |
| Overlay Azure CNI | • Kekurangan alamat IP menjadi perhatian. • Menskalakan hingga 1.000 simpul dan 250 pod per simpul sudah cukup. • Ekstra hop untuk konektivitas pod dapat diterima. • Konfigurasi jaringan yang lebih sederhana. • Persyaratan keluar AKS dapat dipenuhi. |
Perbedaan perilaku berikut ada antara kubenet dan Azure CNI:
| Kemampuan | Kubenet | Azure CNI | Overlay Azure CNI | Azure CNI Didukung oleh Cilium |
|---|---|---|---|---|
| Sebarkan klaster di jaringan virtual yang ada atau baru | Didukung - UDR diterapkan secara manual | Didukung | Didukung | Didukung |
| Konektivitas Pod-Pod | Didukung | Didukung | Didukung | Didukung |
| Konektivitas Pod-VM; VM dalam jaringan virtual yang sama | Bekerja ketika diprakarsai oleh Pod | Bekerja dua arah | Bekerja ketika diprakarsai oleh Pod | Bekerja ketika diprakarsai oleh Pod |
| Konektivitas Pod-VM; VM dalam jaringan virtual peered | Bekerja ketika diprakarsai oleh Pod | Bekerja dua arah | Bekerja ketika diprakarsai oleh Pod | Bekerja ketika diprakarsai oleh Pod |
| Akses lokal menggunakan VPN atau Rute Ekspres | Bekerja ketika diprakarsai oleh Pod | Bekerja dua arah | Bekerja ketika diprakarsai oleh Pod | Bekerja ketika diprakarsai oleh Pod |
| Akses ke sumber daya yang diamankan oleh titik akhir layanan | Didukung | Didukung | Didukung | |
| Mengekspos layanan Kubernetes menggunakan layanan load balancer, App Gateway, atau ingress controller | Didukung | Didukung | Didukung | Batasan yang sama saat menggunakan mode Overlay |
| Dukungan untuk kumpulan node Windows | Tidak Didukung | Didukung | Didukung | Hanya tersedia untuk Linux dan bukan untuk Windows. |
| Azure DNS Default dan Zona Privat | Didukung | Didukung | Didukung |
Untuk informasi selengkapnya tentang Azure CNI dan kubenet dan untuk membantu menentukan opsi mana yang terbaik untuk Anda, lihat Mengonfigurasi jaringan Azure CNI di AKS dan Menggunakan jaringan kubenet di AKS.
Lingkup dukungan antara model jaringan
Apapun model jaringan yang Anda gunakan, baik kubenet maupun Azure CNI dapat disebarkan dengan salah satu cara berikut:
- Platform Azure dapat secara otomatis membuat dan mengonfigurasi sumber daya jaringan virtual saat Anda membuat klaster AKS.
- Anda dapat membuat dan mengonfigurasi sumber daya jaringan virtual secara manual dan melampirkan ke sumber daya tersebut saat membuat klaster AKS.
Meskipun kemampuan seperti endpoint layanan atau UDR didukung dengan kubenet dan Azure CNI, kebijakan dukungan untuk AKS menentukan perubahan apa yang dapat Anda lakukan. Contohnya:
- Jika Anda membuat sumber daya jaringan virtual secara manual untuk klaster AKS, Anda didukung saat mengonfigurasi UDR atau titik akhir layanan Anda sendiri.
- Jika platform Azure secara otomatis membuat sumber daya jaringan virtual untuk klaster AKS Anda, Anda tidak dapat mengubah sumber daya yang dikelola AKS tersebut secara manual untuk mengonfigurasi UDR atau titik akhir layanan Anda sendiri.
Pengontrol Ingress
Saat Anda membuat Layanan tipe LoadBalancer, Anda juga membuat sumber daya load balancer Azure yang mendasarinya. Load balancer dikonfigurasi untuk mendistribusikan traffic ke Pod dalam Service pada port tertentu.
LoadBalancer hanya berfungsi pada lapisan 4. Pada lapisan 4, Layanan tidak menyadari aplikasi yang sebenarnya, dan tidak dapat membuat pertimbangan perutean lagi.
Pengontrol Ingress bekerja di lapisan 7 dan dapat menggunakan aturan yang lebih cerdas untuk mendistribusikan lalu lintas aplikasi. Pengontrol Ingress biasanya merutekan traffic HTTP ke aplikasi yang berbeda berdasarkan URL masuk.
Membandingkan opsi masuk
Tabel berikut mencantumkan perbedaan fitur antara berbagai opsi pengontrol ingress:
| Fitur | Addon Perutean Aplikasi | Application Gateway untuk Kontainer | Jala layanan berbasis Azure Service Mesh/Istio |
|---|---|---|---|
| Pengontrol Ingress/Gateway | Pengontrol ingress NGINX | Azure Application Gateway untuk Kontainer | Gateway Masuk Istio |
| API | Ingress API | API Ingress dan API Gateway | Gateway API |
| Hosting | Dalam kluster | Azure yang dihosting | Dalam kluster |
| Penskalaan | Penskalaan otomatis | Penskalaan otomatis | Penskalaan otomatis |
| Penyeimbangan Muatan | Internal/Eksternal | Eksternal | Internal/Eksternal |
| Penghentian SSL | Dalam kluster | Ya: Offloading dan E2E SSL | Dalam kluster |
| mTLS | T/A | Ya untuk backend | T/A |
| Alamat IP Statis | T/A | FQDN | T/A |
| Sertifikat SSL tersimpan Azure Key Vault | Ya | Ya | T/A |
| Integrasi Azure DNS untuk manajemen zona DNS | Ya | Ya | T/A |
Tabel berikut ini mencantumkan berbagai skenario di mana Anda mungkin menggunakan setiap pengontrol ingress:
| Opsi Ingress | Waktu menggunakan |
|---|---|
| NGINX Terkelola - Addon Perutean Aplikasi | • Pengontrol ingress NGINX dalam kluster yang dihosting, dapat disesuaikan, dan dapat diskalakan. • Kemampuan penyeimbangan beban dan perutean dasar. • Konfigurasi load balancer internal dan eksternal. • Konfigurasi alamat IP statis. • Integrasi dengan Azure Key Vault untuk manajemen sertifikat. • Integrasi dengan Zona Azure DNS untuk manajemen DNS publik dan privat. • Mendukung API Ingress. |
| Application Gateway untuk Kontainer | • Gateway masuk yang dihosting Azure. • Strategi penyebaran fleksibel yang dikelola oleh pengontrol atau membawa Application Gateway Anda sendiri untuk Kontainer. • Fitur manajemen lalu lintas tingkat lanjut seperti percobaan ulang otomatis, ketahanan zona ketersediaan, autentikasi timbal balik (mTLS) ke target backend, pemisahan lalu lintas / round robin tertimbang, dan penskalaan otomatis. • Integrasi dengan Azure Key Vault untuk manajemen sertifikat. • Integrasi dengan Zona Azure DNS untuk manajemen DNS publik dan privat. • Mendukung API Ingress dan Gateway. |
| Gateway Masuk Istio | • Berdasarkan Envoy, saat menggunakan dengan Istio untuk jala layanan. • Fitur manajemen lalu lintas tingkat lanjut seperti pembatasan tarif dan pemutusan sirkuit. • Dukungan untuk mTLS • Mendukung API Gateway. |
Membuat sumber daya Ingress
Addon perutean aplikasi adalah cara yang disarankan untuk mengonfigurasi pengontrol Ingress di AKS. Addon perutean aplikasi adalah pengontrol ingress yang dikelola sepenuhnya untuk Azure Kubernetes Service (AKS) yang menyediakan fitur-fitur berikut:
Konfigurasi mudah pengontrol NGINX Ingress terkelola berdasarkan pengontrol Ingress Kubernetes NGINX.
Integrasi dengan Azure DNS untuk manajemen zona publik dan privat.
Penghentian SSL dengan sertifikat yang disimpan di Azure Key Vault.
Untuk informasi selengkapnya tentang addon perutean aplikasi, lihat ingress NGINX terkelola dengan add-on perutean aplikasi.
Pelestarian IP sumber klien
Konfigurasikan pengontrol masuk Anda untuk mempertahankan IP sumber klien pada permintaan ke kontainer di klaster AKS Anda. Ketika pengontrol masuk Anda merutekan permintaan klien ke kontainer di klaster AKS Anda, IP sumber asli permintaan tersebut tidak tersedia untuk kontainer target. Saat Anda mengaktifkan pelestarian IP sumberklien, IP sumber untuk klien tersedia di header permintaan di bawah X-Forwarded-For.
Jika Anda menggunakan pelestarian IP sumber klien pada pengontrol ingress, Anda tidak dapat menggunakan pass-through TLS. Pelestarian IP sumber klien dan pass-through TLS dapat digunakan dengan layanan lain, seperti jenis LoadBalancer.
Untuk mempelajari selengkapnya tentang pelestarian IP sumber klien, lihat Cara kerja pelestarian IP sumber klien untuk LoadBalancer Services di AKS.
Mengontrol lalu lintas keluar (keluar)
Kluster AKS disebarkan pada jaringan virtual dan memiliki dependensi keluar pada layanan di luar jaringan virtual tersebut. Dependensi keluar ini hampir sepenuhnya ditentukan dengan nama domain yang sepenuhnya memenuhi syarat (FQDN). Secara default, kluster AKS memiliki akses Internet keluar (keluar) yang tidak dibatasi, yang memungkinkan simpul dan layanan yang Anda jalankan untuk mengakses sumber daya eksternal sesuai kebutuhan. Jika diinginkan, Anda dapat membatasi lalu lintas keluar.
Untuk informasi selengkapnya, lihat Mengontrol lalu lintas keluar untuk node kluster di AKS.
Grup keamanan jaringan
Grup keamanan jaringan memfilter traffic untuk VM seperti node AKS. Saat Anda membuat Layanan, seperti LoadBalancer, platform Azure secara otomatis mengonfigurasi aturan grup keamanan jaringan yang diperlukan.
Anda tidak perlu mengonfigurasi aturan grup keamanan jaringan secara manual untuk memfilter traffic untuk Pod dalam klaster AKS. Anda dapat menentukan port dan penerusan yang diperlukan sebagai bagian dari manifes Kubernetes Service Anda dan memungkinkan platform Azure membuat atau memperbarui aturan yang sesuai.
Anda juga dapat menggunakan kebijakan jaringan untuk menerapkan aturan filter traffic secara otomatis ke Pod.
Untuk informasi selengkapnya, lihat Cara grup keamanan jaringan memfilter lalu lintas jaringan.
Kebijakan Jaringan
Secara default, semua Pod dalam klaster AKS dapat mengirim dan menerima traffic tanpa batasan. Untuk meningkatkan keamanan, Anda dapat menentukan aturan untuk mengontrol arus atau traffic, seperti:
- Aplikasi back-end hanya diekspos ke layanan frontend yang diperlukan.
- Atau, komponen database hanya dapat diakses oleh tingkat aplikasi yang terhubung ke mereka.
Kebijakan jaringan adalah fitur Kubernetes yang tersedia di AKS yang memungkinkan Anda mengontrol arus traffic antar Pod. Anda dapat mengizinkan atau menolak lalu lintas ke pod berdasarkan pengaturan seperti label yang ditetapkan, namespace, atau port lalu lintas. Meskipun grup keamanan jaringan lebih baik untuk node AKS, kebijakan jaringan adalah cara yang lebih cocok dan cloud-native untuk mengontrol arus traffic untuk Pod. Kebijakan jaringan yang diperlukan dapat diterapkan secara otomatis karena pod dibuat secara dinamis dalam klaster AKS.
Pelajari selengkapnya mengenai ini di Mengamankan traffic antara pod menggunakan kebijakan jaringan di Azure Kubernetes Service (AKS).
Langkah berikutnya
Untuk memulai jaringan AKS, buat dan konfigurasi klaster AKS dengan rentang alamat IP Anda sendiri menggunakan kubenet atauAzure CNI.
Untuk praktik terbaik terkait, lihat Praktik terbaik untuk konektivitas dan keamanan jaringan di AKS.
Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut: