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 mengakhiri SSL/TLS atau merutekan beberapa komponen untuk aplikasi Anda yang lebih kompleks.

Artikel ini memperkenalkan konsep inti yang menyediakan konektivitas jaringan 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 perutean layanan: Tergantung pada bidang data jaringan, simpul menggunakan atau kube-proxy Cilium untuk perutean Layanan Kubernetes. Kluster AKS yang menggunakan Azure CNI Powered by Cilium tidak menggunakan kube-proxy.

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 sangat 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 pada Azure secara bersamaan menyiapkan sumber daya load balancer Azure yang sesuai.
  • Saat Anda membuat Layanan KubernetesLoadBalancer, Azure mengonfigurasi aturan grup keamanan jaringan yang diperlukan untuk lalu lintas layanan pada sumber daya yang dikelola oleh AKS.
  • Azure juga dapat mengelola konfigurasi DNS eksternal untuk perutean aplikasi HTTP saat rute Ingress baru dibuat.

Azure jaringan virtual

Di AKS, Anda dapat menyebarkan kluster yang menggunakan salah satu model jaringan berikut:

  • Model jaringan overlay: Jaringan overlay adalah model jaringan yang paling umum digunakan di Kubernetes. Pod diberi alamat IP dari CIDR privat dan terpisah secara logis dari subnet jaringan virtual Azure tempat simpul AKS disebarkan. Model ini memungkinkan skalabilitas yang lebih sederhana dan ditingkatkan jika dibandingkan dengan model jaringan datar.
  • Model jaringan datar: Model jaringan datar di AKS menetapkan alamat IP ke pod dari subnet dalam jaringan virtual Azure yang sama dengan node AKS. Untuk lalu lintas jaringan privat, alamat IP sumber yang dilihat tujuan tergantung pada opsi manajemen alamat IP (IPAM). Azure CNI Pod Subnet mempertahankan alamat IP pod di seluruh jaringan virtual yang terhubung. Dengan Azure CNI Node Subnet, tujuan dalam jaringan virtual kluster melihat alamat IP pod, tetapi tujuan di luar jaringan virtual kluster melihat alamat IP node. Untuk lalu lintas keluar ke internet, metode outbound yang dikonfigurasi menentukan alamat IP sumber publik yang terlihat oleh tujuan di internet.

Untuk informasi selengkapnya tentang model jaringan di AKS, lihat Jaringan CNI di AKS.

Mengontrol lalu lintas keluar (keluar)

Kluster AKS disebarkan pada jaringan virtual dan memiliki dependensi keluar pada layanan di luar jaringan virtual tersebut, yang hampir sepenuhnya ditentukan dengan nama domain yang sepenuhnya memenuhi syarat (FQDN). AKS menyediakan beberapa opsi konfigurasi keluar yang memungkinkan Anda menyesuaikan cara mengakses sumber daya eksternal ini.

Penting

Mulai March 31, 2026, Azure Kubernetes Service (AKS) tidak lagi mendukung akses keluar default untuk komputer virtual (VM). Kluster AKS baru yang menggunakan opsi jaringan virtual yang dikelola AKS akan menempatkan subnet kluster ke subnet privat secara default (defaultOutboundAccess = false). Pengaturan ini tidak memengaruhi lalu lintas kluster yang dikelola AKS, yang menggunakan jalur keluar yang dikonfigurasi secara eksplisit. Ini mungkin memengaruhi skenario yang tidak didukung, seperti menyebarkan sumber daya lain ke subnet yang sama. Kluster yang menggunakan BYO VNet tidak terpengaruh oleh perubahan ini. Dalam konfigurasi yang didukung, tidak ada tindakan yang diperlukan. Untuk informasi selengkapnya tentang penghentian ini, lihat pengumuman mengenai penghentian Azure Updates. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.

Opsi konfigurasi eksternal

Untuk informasi selengkapnya tentang jenis konfigurasi keluar kluster AKS yang didukung, lihat Kustomisasi keluar kluster dengan jenis keluar di Azure Kubernetes Service (AKS).

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 tentang cara membatasi lalu lintas keluar dari kluster Anda, 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 , platform Azure secara otomatis mengonfigurasi aturan grup keamanan jaringan yang diperlukan untuk lalu lintas layanan pada sumber daya yang LoadBalancerdikelola oleh AKS.

AKS tidak menerapkan grup keamanan jaringan ke subnetnya atau memodifikasi grup keamanan jaringan yang Anda kaitkan dengan subnet yang disediakan pelanggan. Jika Anda mengaitkan grup keamanan jaringan dengan subnet kustom, Anda harus memastikan bahwa aturannya mengizinkan lalu lintas simpul dan pod yang diperlukan. Untuk informasi selengkapnya, lihat Prasyarat jaringan AKS CNI.

Anda juga dapat menggunakan kebijakan jaringan untuk menerapkan aturan filter lalu lintas secara otomatis ke pod.

Untuk informasi selengkapnya, lihat Cara grup keamanan jaringan memfilter lalu lintas jaringan.

Persyaratan jaringan virtual kustom

Saat Anda menggunakan jaringan virtual kustom dengan kluster AKS, jika Anda menambahkan aturan grup keamanan jaringan untuk membatasi lalu lintas antar subnet, pastikan bahwa aturan mengizinkan lalu lintas yang diperlukan oleh konfigurasi kluster Anda.

Integrasi VNet API Server telah dikonfigurasi sebelumnya di AKS Otomatis. Di AKS Standard, fitur ini bersifat opsional dan Anda harus mengaktifkannya secara eksplisit. Saat kluster Anda menggunakan Integrasi VNet API Server, izinkan lalu lintas berikut:

Tujuan Sumber Protokol Pelabuhan Gunakan
APIServer Subnet CIDR Subnet Kluster PKT 443 dan 4443 Diperlukan untuk mengaktifkan komunikasi antara Node dan server API.
APIServer Subnet CIDR Azure Load Balancer PKT 9988 Diperlukan untuk mengaktifkan komunikasi antara Azure Load Balancer dan server API. Anda juga dapat mengaktifkan semua komunikasi antara Azure Load Balancer dan CIDR Subnet API Server.

Untuk informasi selengkapnya, lihat Integrasi VNet API Server.

Untuk komunikasi simpul dan pod, izinkan lalu lintas berikut ketika aturan kelompok keamanan jaringan membatasi rentang CIDR yang sesuai:

Tujuan Sumber Protokol Pelabuhan Gunakan
CIDR Node CIDR Node Semua Protokol Semua Port Diperlukan untuk mengaktifkan komunikasi antara Simpul.
Pod CIDR CIDR Node Semua Protokol Semua Port Diperlukan untuk Perutean lalu lintas layanan.
Pod CIDR Pod CIDR Semua Protokol Semua Port Diperlukan untuk komunikasi antar Pod dan dari Pod ke Service, termasuk komunikasi DNS.

Rentang CIDR simpul dan pod yang berlaku bergantung pada model jaringan kluster Anda. Untuk informasi selengkapnya, lihat Prasyarat jaringan AKS CNI.

Penyelesaian DNS

Resolusi DNS sangat penting untuk penemuan dan komunikasi layanan di AKS. Secara default, AKS menggunakan CoreDNS untuk memberikan resolusi nama internal untuk pod dan layanan.

Untuk meningkatkan performa dan keandalan DNS, AKS menawarkan LocalDNS, yang menyebarkan proksi DNS pada setiap simpul. LocalDNS menyelesaikan kueri secara lokal, mengurangi latensi dan menghilangkan conntrack tekanan tabel dari lalu lintas DNS. Anda dapat mengonfigurasi LocalDNS untuk menyajikan respons yang di-cache selama gangguan pada DNS upstream, tetapi cache respons usang hanya berfungsi atas dasar upaya terbaik. LocalDNS sangat bermanfaat dalam kluster atau lingkungan besar dengan volume kueri DNS tinggi.

LocalDNS telah dikonfigurasi sebelumnya di AKS Otomatis. Di AKS Standard, LocalDNS bersifat opsional dan dikonfigurasi per kumpulan simpul. Sebelum mengaktifkannya di AKS Standard, verifikasi versi Kubernetes, sistem operasi simpul, dan prasyarat SKU VM. Mengaktifkan LocalDNS pada kumpulan node yang sudah ada akan membuat ulang image node-node tersebut. Untuk prasyarat dan perencanaan peluncuran, lihat Mengonfigurasi LocalDNS.

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.
  • Komponen database hanya dapat diakses oleh lapisan aplikasi yang terhubung ke dalamnya.

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 alami di cloud untuk mengontrol arus lalu lintas untuk pod. Kebijakan jaringan yang diperlukan dapat diterapkan secara otomatis karena pod dibuat secara dinamis dalam klaster AKS.

Untuk informasi selengkapnya, lihat mengamankan lalu lintas antar pod menggunakan kebijakan jaringan di Azure Kubernetes Service (AKS).

Langkah berikutnya

Untuk mulai menggunakan jaringan AKS, buat dan konfigurasikan kluster AKS dengan rentang alamat IP Anda sendiri menggunakan Azure CNI Overlay atau Azure 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:

  • Terakhir diperbarui pada