Pertimbangan topologi jaringan dan konektivitas untuk AKS

Pertimbangan Desain

Azure Kubernetes Service (AKS) menyediakan tiga model jaringan yang berbeda untuk jaringan kontainer: Kubenet, CNI Overlay, dan CNI. Masing-masing model ini memiliki serangkaian fitur dan keuntungan yang unik, menawarkan opsi fleksibilitas dan skalabilitas untuk jaringan kontainer di AKS.

Kubenet

Kubenet adalah solusi jaringan dasar yang menghemat ruang alamat IP dan menawarkan konfigurasi sederhana. Ini ideal untuk kluster AKS kecil dengan kurang dari 400 simpul, di mana mengelola dan memelihara rute yang ditentukan pengguna dapat diterima secara manual. Ini cocok untuk skenario di mana load balancer internal atau eksternal cukup untuk menjangkau pod dari luar kluster.

Azure CNI

Azure CNI adalah model jaringan yang dirancang untuk jaringan tingkat lanjut. Ini menyediakan konektivitas jaringan virtual penuh untuk pod, memungkinkan konektivitas pod-ke-pod dan pod-ke-VM. Ini ideal untuk skenario di mana fitur AKS tingkat lanjut, seperti simpul virtual, diperlukan. Ini cocok untuk skenario di mana ruang alamat IP yang memadai tersedia, dan sumber daya eksternal perlu menjangkau pod secara langsung. Kebijakan jaringan AKS juga didukung dengan Azure CNI.

Overlay Azure CNI

Azure CNI Overlay dirancang untuk mengatasi kekurangan alamat IP dan menyederhanakan konfigurasi jaringan. Ini cocok untuk skenario di mana penskalaan hingga 1000 simpul dan 250 pod per simpul sudah cukup, dan hop tambahan untuk konektivitas pod dapat diterima. Persyaratan keluar AKS juga dapat dipenuhi dengan Azure CNI Overlay.

Untuk ringkasan kasus penggunaan yang direkomendasikan per model jaringan, lihat Membandingkan model jaringan di AKS.

Selain itu, saat merancang kluster AKS Anda, penting untuk merencanakan alamat IP dan ukuran subnet jaringan virtual dengan hati-hati untuk mendukung penskalaan. {i>Node

Kluster AKS mendukung SKU Azure Load Balancer Dasar dan Standar, dan layanan dapat diekspos dengan load balancer publik atau internal. AKS menggunakan CoreDNS untuk memberikan resolusi nama ke pod yang berjalan di kluster, dan lalu lintas jaringan keluar (keluar) dapat dikirim melalui Azure Firewall atau kluster appliance virtual jaringan.

Secara default, semua Pod dalam klaster AKS dapat mengirim dan menerima traffic tanpa batasan. Namun, kebijakan jaringan Kubernetes dapat digunakan untuk meningkatkan keamanan dan memfilter lalu lintas jaringan antar pod dalam kluster AKS. Dua model kebijakan jaringan tersedia untuk AKS: Kebijakan jaringan Azure dan Calico.

Terakhir, AKS menyiapkan kelompok keamanan jaringan (NSG) pada subnet tempat kluster disebarkan. Disarankan untuk tidak mengedit NSG ini secara manual, tetapi layanan yang disebarkan di AKS dapat memengaruhinya.

Secara keseluruhan, memilih model jaringan yang sesuai dan merencanakan sumber daya jaringan dengan cermat dapat membantu mengoptimalkan performa, keamanan, dan biaya kluster AKS Anda.

Kluster privat

Visibilitas IP kluster AKS dapat bersifat publik atau privat. Kluster privat mengekspos API Kubernetes melalui alamat IP privat, tetapi tidak melalui alamat publik. Alamat IP privat ini diwakili dalam jaringan virtual AKS melalui titik akhir privat. API Kubernetes tidak boleh diakses melalui alamat IP-nya, melainkan melalui nama domain yang sepenuhnya memenuhi syarat (FQDN). Resolusi dari Kubernetes API FQDN ke alamat IP-nya biasanya akan dilakukan oleh zona DNS Privat Azure. Zona DNS ini dapat dibuat oleh Azure di grup sumber daya simpul AKS, atau Anda bisa menentukan zona DNS yang sudah ada.

Mengikuti praktik skala perusahaan yang terbukti, resolusi DNS untuk beban kerja Azure ditawarkan oleh server DNS terpusat yang diterapkan dalam langganan konektivitas, baik di jaringan virtual hub atau di jaringan virtual layanan bersama yang tersambung ke Azure Virtual WAN. Server ini akan menyelesaikan nama khusus dan publik Azure secara kondisional menggunakan Azure DNS (alamat IP 168.63.129.16), dan nama privat menggunakan server DNS perusahaan. Namun, server DNS terpusat ini tidak akan dapat menyelesaikan FQDN API AKS hingga terhubung dengan zona privat DNS yang dibuat untuk kluster AKS. Setiap AKS memiliki zona privat DNS yang unik, karena GUID acak ditambahkan ke nama zona. Jadi, untuk setiap kluster AKS baru, zona DNS privat yang sesuai harus terhubung ke jaringan virtual tempat server DNS pusat berada.

Semua jaringan virtual harus dikonfigurasi untuk menggunakan server DNS pusat ini untuk resolusi nama. Namun, jika jaringan virtual AKS dikonfigurasi untuk menggunakan server DNS pusat, dan server DNS ini belum tersambung ke zona DNS privat, {i>node

Setelah kluster dibuat, koneksi dibuat di antara zona privat DNS dan jaringan virtual tempat server DNS pusat disebarkan. Jaringan virtual AKS juga telah dikonfigurasi untuk menggunakan server DNS pusat dalam langganan konektivitas, dan akses administrator ke API Kubernetes AKS akan mengikuti alur ini:

Catatan

Gambar-gambar dalam artikel ini mencerminkan desain yang menggunakan hub tradisional dan model konektivitas {i>spoke

1. Administrator menyelesaikan FQDN DARI API Kubernetes. Server DNS lokal meneruskan permintaan ke server otoritatif: penyelesai DNS di Azure. Server ini meneruskan permintaan ke server Azure DNS (168.63.129.16), yang akan mendapatkan alamat IP dari zona DNS Privat Azure.
2. Setelah menyelesaikan alamat IP, lalu lintas ke API Kubernetes dialihkan dari lokal ke {i>gateway
3. Titik akhir privat akan memperkenalkan /32 rute di jaringan virtual hub. Gateway VPN dan ExpressRoute mengirim lalu lintas langsung ke titik akhir privat API Kubernetes yang disebarkan di jaringan virtual AKS.

Lalu lintas dari pengguna aplikasi ke kluster

Pengontrol masuk ({i>ingress

• Pengontrol {i>ingress
• Pengontrol {i>ingress
• Pengontrol Ingress dapat menjalankan off-cluster dan in-cluster:
  • Pengontrol ingress off-cluster membongkar komputasi (seperti perutean lalu lintas HTTP atau penghentian TLS) ke layanan lain di luar AKS, seperti add-on Azure Application Gateway Ingress Controller (AGIC).
  • Solusi di dalam kluster mengonsumsi sumber daya kluster AKS untuk komputasi (seperti perutean lalu lintas HTTP atau penghentian TLS). Pengontrol {i>ingress
• Add-on perutean aplikasi HTTP dasar mudah digunakan, tetapi memiliki beberapa batasan seperti yang didokumenkan dalam perutean aplikasi HTTP.

Pengontrol {i>ingress

• Konfigurasi harus diselaraskan dengan desain pemfilteran {i>egress
• Jika penghentian TLS diperlukan, pengelolaan sertifikat TLS harus dipertimbangkan.

Lalu lintas aplikasi dapat berasal dari lokal atau internet publik. Gambar berikut menjelaskan contoh bahwa Azure Application Gateway dikonfigurasi untuk membalikkan koneksi proksi ke kluster baik dari lokal maupun dari internet publik.

Lalu lintas dari lokal mengikuti alur panggilan biru yang bernomor dalam diagram sebelumnya.

1. Klien menyelesaikan FQDN yang ditetapkan ke aplikasi, baik menggunakan server DNS yang disebarkan di langganan konektivitas atau server DNS lokal.
2. Setelah menyelesaikan aplikasi FQDN ke alamat IP (alamat IP privat pada {i>gatewaygateway
3. Perutean di subnet gateway dikonfigurasi untuk mengirim permintaan ke {i>firewall
4. {i>Firewall

Azure Application Gateway dalam contoh ini dapat disebarkan dalam langganan yang sama seperti kluster AKS, karena konfigurasinya terkait erat dengan beban kerja yang disebarkan di AKS dan karenanya dikelola oleh tim aplikasi yang sama. Akses dari internet mengikuti alur panggilan hijau bernomor dalam diagram sebelumnya.

1. Klien dari internet publik menyelesaikan nama DNS untuk aplikasi yang menggunakan Azure Traffic Manager. Atau, teknologi penyeimbangan beban global lainnya seperti Azure Front Door dapat digunakan.
2. FQDN publik aplikasi akan diselesaikan dengan Traffic Manager ke alamat IP publik {i>gateway
3. Gateway aplikasi mengakses beban kerja yang disebarkan di AKS.

Catatan

Alur ini hanya berlaku untuk aplikasi web. Aplikasi non-web berada di luar cakupan artikel ini, dan mereka dapat dipaparkan melalui Azure Firewall di jaringan virtual hub, atau hub virtual yang aman jika menggunakan model konektivitas Virtual WAN.

Atau, alur lalu lintas untuk aplikasi berbasis web dapat dibuat untuk melintasi Azure Firewall dalam langganan konektivitas dan WAF di jaringan virtual AKS. Pendekatan ini memiliki keuntungan menawarkan beberapa perlindungan lagi, seperti menggunakan pemfilteran berbasis kecerdasan Azure Firewall untuk menghilangkan lalu lintas dari alamat IP berbahaya yang diketahui di internet. Namun, ia juga memiliki beberapa kelemahan. Misalnya, hilangnya alamat IP klien asli, dan koordinasi ekstra yang diperlukan di antara {i>firewall

Lalu lintas dari pod AKS ke layanan {i>backend

Pod yang berjalan di dalam kluster AKS mungkin perlu mengakses layanan {i>backenddatabasedatabase databaseTitik akhir layanan jaringan virtual dan Private Link dapat digunakan untuk mengamankan konektivitas ke layanan terkelola Azure ini.

Jika Anda menggunakan titik akhir privat Azure untuk lalu lintas backend, resolusi DNS untuk layanan Azure dapat dilakukan menggunakan zona DNS Privat Azure. Karena penyelesai DNS untuk seluruh lingkungan berada di jaringan virtual hub (atau jaringan virtual layanan bersama jika menggunakan model konektivitas Virtual WAN), zona privat ini harus dibuat dalam langganan konektivitas. Untuk membuat {i>A-record

Dimungkinkan untuk membuat {i>A-record

Konektivitas backend dari pod AKS ke layanan Azure PaaS yang diekspos melalui titik akhir privat mengikuti urutan ini:

1. Pod AKS menyelesaikan FQDN platform Azure sebagai layanan (PaaS) menggunakan server DNS pusat dalam langganan konektivitas, yang didefinisikan sebagai server DNS kustom di jaringan virtual AKS.
2. IP yang diselesaikan adalah alamat IP privat dari titik akhir privat, yang diakses langsung dari pod AKS.

Lalu lintas antara pod AKS dan titik akhir privat per default tidak akan melalui Azure Firewall di jaringan virtual hub (atau hub virtual yang aman jika menggunakan Virtual WAN), bahkan jika kluster AKS dikonfigurasi untuk pemfilteran keluar dengan Azure Firewall. Alasannya adalah bahwa titik akhir privat membuat /32 rute di subnet jaringan virtual aplikasi, tempat AKS disebarkan.

Rekomendasi desain

• Jika mandat kebijakan keamanan Anda memiliki API Kubernetes dengan alamat IP privat (bukan alamat IP publik), sebarkan kluster AKS pribadi.
  • Gunakan zona DNS privat kustom saat membuat kluster privat, alih-alih membiarkan proses pembuatan menggunakan zona DNS privat sistem.
• Gunakan Azure Container Networking Interface (CNI) sebagai model jaringan, kecuali Anda memiliki rentang alamat IP yang terbatas untuk dapat ditetapkan ke kluster AKS.
  • Ikuti dokumentasi tentang perencanaan alamat IP dengan CNI.
  • Untuk menggunakan kumpulan simpul Windows Server dan simpul virtual untuk memverifikasi batasan akhir, lihat FAQ dukungan Windows AKS.
• Gunakan Azure DDoS Protection untuk melindungi jaringan virtual yang digunakan untuk kluster AKS kecuali Anda menggunakan Azure Firewall atau WAF dalam langganan terpusat.
• Gunakan konfigurasi DNS yang ditautkan ke pengaturan jaringan secara keseluruhan dengan Azure Virtual WAN atau arsitektur hub dan {i>spoke
• Gunakan Private Link untuk mengamankan koneksi jaringan dan gunakan konektivitas berbasis IP privat ke layanan Azure terkelola lainnya yang digunakan yang mendukung Private Link, seperti Azure Storage, Azure Container Registry, Azure SQL Database, dan Azure Key Vault.
• Gunakan pengontrol {i>ingress
• Semua aplikasi web yang dikonfigurasi untuk menggunakan {i>ingressKebijakan yang termasuk implementasi referensi zona pendaratan skala perusahaan.
• Secara opsional, untuk menghemat sumber daya komputasi dan penyimpanan kluster AKS Anda, gunakan pengontrol {i>ingress
• Gunakan add-on Azure Application Gateway Ingress Controller (AGIC), yang merupakan layanan Azure terkelola pihak pertama.
• Dengan AGIC, sebarkan Azure Application Gateway khusus untuk setiap kluster AKS dan jangan berbagi Application Gateway yang sama di beberapa kluster AKS.
• Jika tidak ada batasan sumber daya atau operasional, atau AGIC tidak menyediakan fitur yang diperlukan, gunakan solusi pengontrol ingress dalam kluster seperti NGINX, Traefik, atau solusi lain yang didukung Kubernetes.

Untuk aplikasi web yang menghadap ke internet, sangat aman dan menghadap ke internet, gunakan {i>firewallingress

Azure Application Gateway dan Azure Front Door keduanya mengintegrasikan Azure Web Application Firewall untuk melindungi aplikasi berbasis web.

Jika mandat kebijakan keamanan Anda yang memeriksa semua lalu lintas internet keluar yang dihasilkan di kluster AKS, amankan lalu lintas jaringan keluar menggunakan Azure Firewall atau alat virtual jaringan (NVA) pihak ketiga yang diterapkan di jaringan virtual hub terkelola. Untuk informasi selengkapnya, lihat Membatasi lalu lintas keluar. UDR jenis keluar AKS memerlukan pengaitan tabel rute ke subnet simpul AKS, sehingga tidak dapat digunakan hari ini dengan injeksi rute dinamis yang didukung oleh Azure Virtual WAN atau Azure Route Server.

Untuk kluster non-privat, gunakan rentang IP resmi.

Gunakan tingkat Standar alih-alih tingkat dasar Azure Load Balancer.

Saat merancang kluster Kubernetes di Azure, salah satu pertimbangan utama adalah memilih model jaringan yang sesuai untuk persyaratan spesifik Anda. Azure Kubernetes Service (AKS) menawarkan tiga model jaringan yang berbeda: Kubenet, Azure CNI, dan Azure CNI Overlay. Untuk membuat keputusan berdasarkan informasi, penting untuk memahami kemampuan dan karakteristik setiap model.

Untuk perbandingan fitur antara tiga model jaringan di AKS; Kubenet, Azure CNI, dan Azure CNI Overlay, lihat Membandingkan model jaringan di AKS.