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 dalam dan antara aplikasi Anda atau komponennya. Ini melibatkan aspek-aspek utama berikut:

  • 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: Berjalan pada setiap node, kube-proxy bertanggung jawab untuk menyediakan fitur jaringan yang diperlukan.

Mengenai fungsionalitas Kubernetes tertentu:

  • Layanan: Ini digunakan untuk mengelompokkan pod secara logis, memungkinkan akses langsung ke pod tersebut melalui alamat IP atau nama DNS tertentu pada port yang ditunjuk.
  • Jenis layanan: Fitur ini memungkinkan Anda menentukan jenis Layanan yang ingin Anda buat.
  • 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.

Layanan

Untuk menyederhanakan konfigurasi jaringan untuk beban kerja aplikasi, Kubernetes menggunakan Services untuk mengelompokkan sekumpulan Pod secara logis dan menyediakan konektivitas jaringan. Anda dapat menentukan Kubernetes ServiceType untuk menentukan jenis Layanan apa yang Anda inginkan, misalnya jika Anda ingin mengekspos Layanan ke alamat IP eksternal yang berada di luar kluster Anda. Untuk informasi selengkapnya, lihat dokumentasi Kubernetes untuk Layanan Penerbitan (ServiceTypes).

ServiceTypes berikut ini tersedia:

  • ClusterIP

    ClusterIP membuat alamat IP internal untuk digunakan dalam kluster AKS. Layanan ini baik untuk aplikasi internal saja yang mendukung beban kerja lain dalam kluster. Ini adalah default yang digunakan jika Anda tidak secara eksplisit menentukan jenis untuk Layanan.

    Diagram showing ClusterIP traffic flow in an AKS cluster

  • NodePort

    NodePort membuat pemetaan port pada simpul utama yang memungkinkan aplikasi diakses langsung dengan alamat IP simpul dan port.

    Diagram showing NodePort traffic flow in an AKS cluster

  • LoadBalancer

    LoadBalancer membuat sumber daya penyeimbang beban Azure, mengonfigurasi alamat IP eksternal, dan menghubungkan pod yang diminta ke kumpulan backend penyeimbang beban. Untuk memungkinkan traffic pelanggan mencapai aplikasi, aturan penyeimbangan beban dibuat pada port yang diinginkan.

    Diagram showing Load Balancer traffic flow in an AKS cluster

    Untuk penyeimbangan beban HTTP lalu lintas masuk, opsi lain adalah menggunakan pengontrol Ingress.

  • ExternalName

    Membuat entri DNS tertentu untuk akses aplikasi yang lebih mudah.

Baik load balancer dan alamat IP layanan dapat ditetapkan secara dinamis, atau Anda dapat menentukan alamat IP statis yang ada. Anda dapat menetapkan alamat IP statis internal dan eksternal. Alamat IP statis yang ada sering dikaitkan dengan entri DNS.

Anda dapat membuat load balancer internal dan eksternal. load balancer internal hanya diberi alamat IP pribadi, sehingga tidak dapat diakses dari Internet.

Pelajari selengkapnya tentang Layanan di dokumen Kubernetes.

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:

  1. Node menerima alamat IP dari subnet jaringan virtual Azure.
  2. Pod menerima alamat IP dari ruang alamat yang berbeda secara logis ke subnet jaringan virtual Azure dari node.
  3. Terjemahan alamat jaringan (NAT) kemudian dikonfigurasi sehingga Pod dapat menjangkau sumber daya pada jaringan virtual Azure.
  4. 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, traffic ke endpoint di jaringan virtual yang sama bukan NAT'd ke IP primer node. 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.

Diagram showing two nodes with bridges connecting each to a single Azure VNet

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 VNet ke pod. Ini mencapai ini dengan menetapkan IP CIDR privat ke pod, yang terpisah dari VNet dan dapat digunakan kembali di beberapa kluster. Selain itu, Azure CNI Overlay dapat menskalakan melebihi batas 400 node 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. Menggunakan program eBPF dan struktur objek API yang lebih efisien, Azure CNI Powered by Cilium dapat menskalakan di luar batas Azure Network Policy Manager sebesar 250 simpul/pod 20K.

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 pihak ketiga 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.

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
Mengekspos layanan Kubernetes menggunakan layanan load balancer, App Gateway, atau ingress controller Didukung Didukung Tidak ada dukungan Pengontrol Ingress Application Gateway (AGIC) Batasan yang sama saat menggunakan mode Overlay
Dukungan untuk kumpulan node Windows Tidak Didukung Didukung Didukung Hanya tersedia untuk Linux dan bukan untuk Windows.

Untuk plugin kubenet dan Azure CNI, layanan DNS disediakan oleh CoreDNS, penyebaran yang berjalan di AKS dengan autoscaler sendiri. Untuk informasi lebih lanjut tentang CoreDNS di Kubernetes, lihat Menyesuaikan Layanan DNS. CoreDNS secara default dikonfigurasi untuk meneruskan domain yang tidak dikenal ke fungsionalitas DNS Azure Virtual Network tempat klaster AKS disebarkan. Oleh karena itu, Azure DNS dan Private Zones akan berfungsi untuk Pod yang berjalan di AKS.

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. Misalnya:

  • 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.

Diagram showing Ingress traffic flow in an AKS cluster

Membuat sumber daya Ingress

Di AKS, Anda dapat membuat sumber daya Ingress menggunakan NGINX, alat serupa, atau fitur perutean aplikasi HTTP AKS. Saat Anda mengaktifkan perutean aplikasi HTTP untuk kluster AKS, platform Azure membuat pengontrol ingress dan pengontrol External-DNS . Saat sumber daya Ingress baru dibuat di Kubernetes, rekaman DNS A yang diperlukan dibuat di zona DNS khusus kluster.

Untuk informasi selengkapnya, lihat Menyebarkan perutean aplikasi HTTP.

Application Gateway Ingress Controller (AGIC)

Dengan add-on Application Gateway Ingress Controller (AGIC), Anda dapat menggunakan load-balancer Application Gateway tingkat 7 asli Azure untuk mengekspos perangkat lunak cloud ke Internet. AGIC berjalan sebagai pod dalam kluster AKS. Ini menggunakan Sumber Daya Ingress Kubernetes dan mengonversinya ke konfigurasi Application Gateway, yang memungkinkan gateway untuk menyeimbangkan beban lalu lintas ke pod Kubernetes.

Untuk mempelajari selengkapnya tentang add-on AGIC untuk AKS, lihat Apa itu Application Gateway Ingress Controller?.

Penghentian TLS

Penghentian SSL /TLS adalah fitur umum lain dari Ingress. Pada aplikasi web besar yang diakses melalui HTTPS, sumber daya Ingress menangani penghentian TLS daripada dalam aplikasi itu sendiri. Untuk menyediakan pembuatan dan konfigurasi sertifikasi TLS otomatis, Anda dapat mengonfigurasi sumber daya Ingress untuk menggunakan penyedia seperti "Let's Encrypt".

Untuk informasi selengkapnya tentang mengonfigurasi pengontrol ingress NGINX dengan Let's Encrypt, lihat Ingress dan TLS.

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: