Mengonfigurasi jaringan Azure CNI Overlay di Azure Kubernetes Service (AKS)

  • Artikel

Azure Container Networking Interface (CNI) tradisional menetapkan alamat IP VNet ke setiap pod. Ini menetapkan alamat IP ini dari sekumpulan IP yang dipertahankan pada setiap simpul atau subnet terpisah yang dicadangkan untuk pod. Pendekatan ini memerlukan perencanaan alamat IP dan dapat menyebabkan kelelahan alamat, yang memperkenalkan kesulitan penskalaan kluster Anda saat permintaan aplikasi Anda tumbuh.

Dengan Azure CNI Overlay, node kluster disebarkan ke subnet Azure Virtual Network (VNet). Pod diberi alamat IP dari CIDR privat yang secara logis berbeda dari VNet yang menghosting simpul. Lalu lintas pod dan node dalam kluster menggunakan jaringan Overlay. Network Address Translation (NAT) menggunakan alamat IP simpul untuk menjangkau sumber daya di luar kluster. Solusi ini menghemat sejumlah besar alamat IP VNet dan memungkinkan Anda untuk menskalakan kluster Anda ke ukuran besar. Keuntungan tambahan adalah Anda dapat menggunakan kembali CIDR privat di kluster AKS yang berbeda, yang memperluas ruang IP yang tersedia untuk aplikasi kontainer di Azure Kubernetes Service (AKS).

Gambaran umum jaringan Overlay

Dalam jaringan Overlay, hanya node kluster Kubernetes yang diberi IP dari subnet. Pod menerima IP dari CIDR privat yang disediakan pada saat pembuatan kluster. Setiap node diberi ruang alamat /24 yang dihasilkan dari CIDR yang sama. Simpul tambahan yang dibuat saat Anda menskalakan kluster secara otomatis menerima /24 ruang alamat dari CIDR yang sama. Azure CNI menetapkan IP ke pod dari ruang /24 ini.

Domain perutean terpisah dibuat di tumpukan Azure Networking untuk ruang CIDR privat pod, yang membuat jaringan Overlay untuk komunikasi langsung antar pod. Tidak perlu menyediakan rute kustom pada subnet kluster atau menggunakan metode enkapsulasi untuk tunnel lalu lintas antar pod, yang memberikan performa konektivitas antara pod setara dengan VM di VNet. Beban kerja yang berjalan dalam pod bahkan tidak menyadari bahwa manipulasi alamat jaringan sedang terjadi.

Diagram yang menunjukkan dua simpul dengan tiga pod yang masing-masing berjalan dalam jaringan Overlay. Lalu lintas pod ke titik akhir di luar kluster dirutekan melalui NAT.

Komunikasi dengan titik akhir di luar kluster, seperti VNet lokal dan peering, terjadi menggunakan IP simpul melalui NAT. Azure CNI menerjemahkan IP sumber (IP Overlay pod) lalu lintas ke alamat IP utama VM, yang memungkinkan tumpukan Jaringan Azure untuk merutekan lalu lintas ke tujuan. Titik akhir di luar kluster tidak dapat terhubung ke pod secara langsung. Anda harus menerbitkan aplikasi pod sebagai layanan Kubernetes Load Balancer agar dapat dijangkau di VNet.

Anda dapat menyediakan konektivitas keluar (keluar) ke internet untuk Pod Overlay menggunakan Load Balancer SKU Standar atau Nat Gateway Terkelola. Anda juga dapat mengontrol lalu lintas keluar dengan mengarahkannya ke firewall menggunakan Rute yang Ditentukan Pengguna pada subnet kluster.

Anda dapat mengonfigurasi konektivitas ingress ke kluster menggunakan pengontrol ingress, seperti perutean aplikasi Nginx atau HTTP. Anda tidak dapat mengonfigurasi konektivitas ingress menggunakan Azure App Gateway. Untuk detailnya, lihat Batasan dengan Azure CNI Overlay.

Perbedaan antara Kubenet dan Azure CNI Overlay

Seperti Azure CNI Overlay, Kubenet menetapkan alamat IP ke pod dari ruang alamat yang secara logis berbeda dari VNet, tetapi memiliki penskalaan dan batasan lainnya. Tabel di bawah ini menyediakan perbandingan terperinci antara Overlay Azure CNI dan Kubenet. Jika Anda tidak ingin menetapkan alamat IP VNet ke pod karena kekurangan IP, sebaiknya gunakan Azure CNI Overlay.

Luas Overlay Azure CNI Kubenet
Skala kluster 5000 simpul dan 250 pod/node 400 node dan 250 pod/node
Konfigurasi jaringan Sederhana - tidak ada konfigurasi tambahan yang diperlukan untuk jaringan pod Kompleks - memerlukan tabel rute dan UDR pada subnet kluster untuk jaringan pod
Performa konektivitas pod Performa setara dengan VM di VNet Lompatan tambahan menambahkan latensi
Kebijakan Jaringan Kubernetes Kebijakan Jaringan Azure, Calico, Cilium Calico
Platform OS yang didukung Linux dan Windows Server 2022, 2019 Hanya Linux

Perencanaan alamat IP

  • Node Kluster: Saat menyiapkan kluster AKS Anda, pastikan subnet VNet Anda memiliki cukup ruang untuk tumbuh untuk penskalaan di masa mendatang. Anda dapat menetapkan setiap kumpulan simpul ke subnet khusus. /24Subnet dapat memuat hingga 251 simpul karena tiga alamat IP pertama dicadangkan untuk tugas manajemen.
  • Pod: Solusi Overlay menetapkan /24 ruang alamat untuk pod pada setiap simpul dari CIDR privat yang Anda tentukan selama pembuatan kluster. Ukuran /24 tetap dan tidak dapat ditingkatkan atau dikurangi. Anda dapat menjalankan hingga 250 pod pada sebuah node. Saat merencanakan ruang alamat pod, pastikan CIDR privat cukup besar untuk menyediakan /24 ruang alamat bagi simpul baru untuk mendukung ekspansi kluster di masa mendatang.
    • Saat merencanakan ruang alamat IP untuk pod, pertimbangkan faktor-faktor berikut:
      • Ruang CIDR pod yang sama dapat digunakan pada beberapa kluster AKS independen di VNet yang sama.
      • Ruang CIDR pod tidak boleh tumpang tindih dengan rentang subnet kluster.
      • Ruang CIDR Pod tidak boleh tumpang tindih dengan jaringan yang terhubung langsung (seperti peering VNet, ExpressRoute, atau VPN). Jika lalu lintas eksternal memiliki IP sumber dalam rentang podCIDR, lalu lintas tersebut memerlukan terjemahan ke IP yang tidak tumpang tindih melalui SNAT untuk berkomunikasi dengan kluster.
  • Rentang alamat layanan Kubernetes: Ukuran alamat layanan CIDR tergantung pada jumlah layanan kluster yang ingin Anda buat. Ukurannya harus lebih kecil dari /12. Rentang ini tidak boleh tumpang tindih dengan rentang POD CIDR, rentang subnet kluster, dan rentang IP yang digunakan dalam VNet yang di-peering dan jaringan lokal.
  • Alamat IP layanan DNS Kubernetes: Alamat IP ini berada dalam rentang alamat layanan Kubernetes yang digunakan oleh penemuan layanan kluster. Jangan gunakan alamat IP pertama dalam rentang alamat Anda, karena alamat ini digunakan untuk alamat tersebut kubernetes.default.svc.cluster.local .

Grup keamanan jaringan

Lalu lintas Pod ke pod dengan Azure CNI Overlay tidak dienkapsulasi, dan aturan grup keamanan jaringan subnet diterapkan. Jika NSG subnet berisi aturan tolak yang akan memengaruhi lalu lintas CIDR pod, pastikan aturan berikut berlaku untuk memastikan fungsionalitas kluster yang tepat (selain semua persyaratan keluar AKS):

  • Lalu lintas dari CIDR simpul ke CIDR simpul pada semua port dan protokol
  • Lalu lintas dari CIDR simpul ke CIDR pod pada semua port dan protokol (diperlukan untuk perutean lalu lintas layanan)
  • Lalu lintas dari CIDR pod ke CIDR pod pada semua port dan protokol (diperlukan untuk pod ke pod dan pod ke lalu lintas layanan, termasuk DNS)

Lalu lintas dari pod ke tujuan mana pun di luar blok CIDR pod menggunakan SNAT untuk mengatur IP sumber ke IP simpul tempat pod berjalan.

Jika Anda ingin membatasi lalu lintas antar beban kerja di kluster, sebaiknya gunakan kebijakan jaringan.

Pod maksimum per simpul

Anda dapat mengonfigurasi jumlah maksimum pod per node pada saat pembuatan kluster atau saat Anda menambahkan kumpulan node baru. Default untuk Azure CNI Overlay adalah 250. Nilai maksimum yang dapat Anda tentukan di Azure CNI Overlay adalah 250, dan nilai minimumnya adalah 10. Pod maksimum per nilai node yang dikonfigurasi selama pembuatan kumpulan node berlaku untuk node dalam kumpulan node tersebut saja.

Memilih model jaringan yang akan digunakan

Azure CNI menawarkan dua opsi alamat IP untuk pod: Konfigurasi tradisional yang menetapkan IP VNet ke pod dan jaringan Overlay. Pilihan opsi yang akan digunakan untuk kluster AKS Anda adalah fleksibilitas dan kebutuhan konfigurasi lanjutan. Pertimbangan berikut membantu menguraikan kapan setiap model jaringan mungkin yang paling tepat.

Gunakan jaringan Overlay saat:

  • Anda ingin menskalakan ke sejumlah besar pod, tetapi memiliki ruang alamat IP terbatas di VNet Anda.
  • Sebagian besar komunikasi pod ada di dalam kluster.
  • Anda tidak memerlukan fitur AKS lanjutan seperti node virtual.

Gunakan opsi VNet tradisional saat:

  • Anda memiliki ruang alamat IP yang tersedia.
  • Sebagian besar komunikasi pod adalah ke sumber daya di luar kluster.
  • Sumber daya di luar kluster perlu menjangkau pod secara langsung.
  • Anda memerlukan fitur lanjutan AKS seperti node virtual.

Batasan dengan Overlay Azure CNI

Azure CNI Overlay memiliki batasan berikut:

  • Anda tidak dapat menggunakan Application Gateway sebagai Pengontrol Ingress (AGIC) untuk kluster Overlay.
  • Virtual Machine Availability Sets (VMAS) tidak didukung untuk Overlay.
  • Anda tidak dapat menggunakan komputer virtual seri DCsv2 di kumpulan simpul. Untuk memenuhi persyaratan Komputasi Rahasia, pertimbangkan untuk menggunakan VM rahasia seri DCasv5 atau DCadsv5 sebagai gantinya.
  • Jika Anda menggunakan subnet Anda sendiri untuk menyebarkan kluster, nama subnet, VNET, dan grup sumber daya yang berisi VNET, harus 63 karakter atau kurang. Ini berasal dari fakta bahwa nama-nama ini akan digunakan sebagai label dalam simpul pekerja AKS, dan karenanya tunduk pada aturan sintaks label Kubernetes.

Menyiapkan kluster Overlay

Catatan

Anda harus memiliki CLI versi 2.48.0 atau yang lebih baru untuk menggunakan --network-plugin-mode argumen . Untuk Windows, Anda harus menginstal ekstensi Azure CLI pratinjau aks terbaru dan dapat mengikuti instruksi di bawah ini.

Buat kluster dengan Azure CNI Overlay menggunakan az aks create perintah . Pastikan untuk menggunakan argumen --network-plugin-mode untuk menentukan kluster overlay. Jika CIDR pod tidak ditentukan, maka AKS menetapkan ruang default: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

Menambahkan nodepool baru ke subnet khusus

Setelah membuat kluster dengan Azure CNI Overlay, Anda dapat membuat nodepool lain dan menetapkan simpul ke subnet baru dari VNet yang sama. Pendekatan ini dapat berguna jika Anda ingin mengontrol IP masuk atau keluar host dari/menuju target di VNET yang sama atau VNet yang di-peering.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Meningkatkan kluster yang ada ke Overlay CNI

Catatan

Anda dapat memperbarui kluster Azure CNI yang ada ke Overlay jika kluster memenuhi kriteria berikut:

  • Kluster ini ada di Kubernetes versi 1.22+.
  • Tidak menggunakan fitur alokasi IP pod dinamis.
  • Tidak mengaktifkan kebijakan jaringan. Mesin Kebijakan Jaringan dapat dihapus instalasinya sebelum peningkatan, lihat Menghapus instalan Azure Network Policy Manager atau Calico
  • Tidak menggunakan kumpulan simpul Windows apa pun dengan docker sebagai runtime kontainer.

Catatan

Karena domain Perutean belum didukung untuk ARM, CNI Overlay belum didukung pada simpul prosesor berbasis ARM (ARM64).

Catatan

Memutakhirkan kluster yang ada ke CNI Overlay adalah proses yang tidak dapat dibalik.

Peringatan

Sebelum Windows OS Build 20348.1668, ada keterbatasan di sekitar pod Windows Overlay yang salah melakukan SNATing paket dari pod jaringan host, yang memiliki efek yang lebih merugikan untuk kluster yang ditingkatkan ke Overlay. Untuk menghindari masalah ini, gunakan Windows OS Build lebih besar dari atau sama dengan 20348.1668.

Peringatan

Jika menggunakan konfigurasi azure-ip-masq-agent kustom untuk menyertakan rentang IP tambahan yang seharusnya bukan paket SNAT dari pod, peningkatan ke Azure CNI Overlay dapat merusak konektivitas ke rentang ini. IP Pod dari ruang overlay tidak akan dapat dijangkau oleh apa pun di luar node kluster. Selain itu, untuk kluster yang cukup lama mungkin ada ConfigMap yang tersisa dari versi azure-ip-masq-agent sebelumnya. Jika ConfigMap ini, bernama azure-ip-masq-agent-config, ada dan tidak sengaja di tempat, ConfigMap ini harus dihapus sebelum menjalankan perintah pembaruan. Jika tidak menggunakan konfigurasi ip-masq-agent kustom, hanya azure-ip-masq-agent-config-reconciled ConfigMap yang harus ada sehubungan dengan Azure ip-masq-agent Config Peta dan ini akan diperbarui secara otomatis selama proses peningkatan.

Proses peningkatan memicu setiap kumpulan simpul untuk di-image ulang secara bersamaan. Meningkatkan setiap kumpulan simpul secara terpisah ke Overlay tidak didukung. Gangguan apa pun pada jaringan kluster mirip dengan peningkatan gambar simpul atau peningkatan versi Kubernetes di mana setiap simpul dalam kumpulan simpul di-image ulang.

Peningkatan Kluster Azure CNI

Perbarui kluster Azure CNI yang ada untuk menggunakan Overlay menggunakan az aks update perintah .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Parameter --pod-cidr diperlukan saat meningkatkan dari CNI warisan karena pod perlu mendapatkan IP dari ruang overlay baru, yang tidak tumpang tindih dengan subnet simpul yang ada. CIDR pod juga tidak dapat tumpang tindih dengan alamat VNet dari kumpulan simpul. Misalnya, jika alamat VNet Anda adalah 10.0.0.0/8, dan simpul Anda berada di subnet 10.240.0.0/16, --pod-cidr tidak dapat tumpang tindih dengan 10.0.0.0/8 atau CIDR layanan yang ada pada kluster.

Peningkatan Kluster Kubenet

Perbarui kluster Kubenet yang ada untuk menggunakan Azure CNI Overlay menggunakan az aks update perintah .

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Karena kluster sudah menggunakan CIDR privat untuk pod yang tidak tumpang tindih dengan ruang IP VNet, Anda tidak perlu menentukan --pod-cidr parameter dan Pod CIDR akan tetap sama.

Catatan

Saat meningkatkan dari Kubenet ke Overlay CNI, tabel rute tidak akan lagi diperlukan untuk perutean pod. Jika kluster menggunakan tabel rute yang disediakan pelanggan, rute yang digunakan untuk mengarahkan lalu lintas pod ke node yang benar akan secara otomatis dihapus selama operasi migrasi. Jika kluster menggunakan tabel rute terkelola (tabel rute dibuat oleh AKS dan berada di grup sumber daya simpul) maka tabel rute tersebut akan dihapus sebagai bagian dari migrasi.

Jaringan tumpukan ganda

Anda dapat menyebarkan kluster AKS dalam mode tumpukan ganda saat menggunakan jaringan Overlay dan jaringan virtual Azure tumpukan ganda. Dalam konfigurasi ini, node menerima alamat IPv4 dan IPv6 dari subnet jaringan virtual Azure. Pod menerima alamat IPv4 dan IPv6 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 lalu lintas adalah NAT ke alamat IP utama node dari keluarga yang sama (IPv4 ke IPv4 dan IPv6 ke IPv6).

Prasyarat

  • Anda harus menginstal Azure CLI 2.48.0 atau yang lebih baru.
  • Kubernetes versi 1.26.3 atau lebih tinggi.

Batasan

Fitur berikut tidak didukung dengan jaringan tumpukan ganda:

  • Windows Nodepools
  • Kebijakan jaringan Azure
  • Kebijakan jaringan Calico
  • NAT Gateway
  • Add-on simpul virtual

Menyebarkan kluster AKS tumpukan ganda

Atribut berikut disediakan untuk mendukung kluster tumpukan ganda:

  • --ip-families: Mengambil daftar keluarga IP yang dipisahkan koma untuk diaktifkan pada kluster.
    • Hanya ipv4 atau ipv4,ipv6 didukung.
  • --pod-cidrs: Mengambil daftar rentang IP notasi CIDR yang dipisahkan koma untuk menetapkan IP pod.
    • Jumlah dan urutan rentang dalam daftar ini harus sesuai dengan nilai yang diberikan pada --ip-families.
    • Jika tidak ada nilai yang disediakan, nilai 10.244.0.0/16,fd12:3456:789a::/64 default akan digunakan.
  • --service-cidrs: Mengambil daftar rentang IP notasi CIDR yang dipisahkan koma untuk menetapkan IP layanan.
    • Jumlah dan urutan rentang dalam daftar ini harus sesuai dengan nilai yang diberikan pada --ip-families.
    • Jika tidak ada nilai yang disediakan, nilai 10.0.0.0/16,fd12:3456:789a:1::/108 default akan digunakan.
    • Subnet IPv6 yang ditetapkan ke --service-cidrs tidak boleh lebih besar dari /108.

Membuat kluster AKS tumpukan ganda

  1. Buat grup sumber daya Azure untuk kluster menggunakan perintah [az group create][az-group-create].

    az group create -l <region> -n <resourceGroupName>

  2. Buat kluster AKS tumpukan ganda menggunakan az aks create perintah dengan parameter yang --ip-families diatur ke ipv4,ipv6.

    az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

Buat contoh beban kerja

Setelah kluster dibuat, Anda dapat menyebarkan beban kerja Anda. Artikel ini memancarkan Anda melalui contoh penyebaran beban kerja server web NGINX.

Menyebarkan server web NGINX

Addon perutean aplikasi adalah cara yang direkomendasikan untuk masuk dalam kluster AKS. Untuk informasi selengkapnya tentang addon perutean aplikasi dan contoh cara menyebarkan aplikasi dengan addon, lihat ingress NGINX terkelola dengan add-on perutean aplikasi.

Mengekspos beban kerja melalui LoadBalancer layanan jenis

Penting

Saat ini ada dua batasan yang berkaitan dengan layanan IPv6 di AKS.

  • Azure Load Balancer mengirimkan pemeriksaan kesehatan ke tujuan IPv6 dari alamat link-local. Di kumpulan simpul Azure Linux, lalu lintas ini tidak dapat dirutekan ke pod, sehingga lalu lintas yang mengalir ke layanan IPv6 yang disebarkan dengan externalTrafficPolicy: Cluster gagal. Layanan IPv6 harus disebarkan dengan externalTrafficPolicy: Local, yang menyebabkan kube-proxy menanggapi pemeriksaan pada node.
  • Sebelum Kubernetes versi 1.27, hanya alamat IP pertama untuk layanan yang akan diprovisikan ke load balancer, sehingga layanan tumpukan ganda hanya menerima IP publik untuk keluarga IP pertamanya yang terdaftar. Untuk menyediakan layanan tumpukan ganda untuk satu penyebaran, buat dua layanan yang menargetkan pemilih yang sama, satu untuk IPv4 dan satu untuk IPv6. Ini bukan lagi batasan dalam kubernetes 1.27 atau yang lebih baru.

  1. Mengekspos penyebaran NGINX menggunakan kubectl expose deployment nginx perintah .

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Anda menerima output yang menunjukkan layanan telah diekspos.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. Setelah penyebaran diekspos dan LoadBalancer layanan diprovisikan sepenuhnya, dapatkan alamat IP layanan menggunakan kubectl get services perintah .

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Verifikasi fungsionalitas melalui permintaan web baris perintah dari host berkemampuan IPv6. Azure Cloud Shell tidak mampu IPv6.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

Langkah berikutnya

Untuk mempelajari cara menggunakan AKS dengan plugin Container Network Interface (CNI) Anda sendiri, lihat Bawa plugin Container Network Interface (CNI) Anda sendiri.