Bagikan melalui

Antarmuka Jaringan Kontainer Warisan AKS (CNI)

  • Artikel

Di Azure Kubernetes Service (AKS), sementara Azure CNI Overlay dan Azure CNI Pod Subnet direkomendasikan untuk sebagian besar skenario, model jaringan warisan seperti Azure CNI Node Subnet dan kubenet masih tersedia dan didukung. Model warisan ini menawarkan pendekatan yang berbeda untuk manajemen dan jaringan alamat IP Pod, masing-masing dengan serangkaian kemampuan dan pertimbangannya sendiri. Artikel ini memberikan gambaran umum tentang opsi jaringan warisan ini, merinci prasyarat, parameter penyebaran, dan karakteristik utamanya untuk membantu Anda memahami peran mereka dan bagaimana mereka dapat digunakan secara efektif dalam kluster AKS Anda.

Prasyarat

Prasyarat berikut diperlukan untuk Azure CNI Node Subnet dan kubenet:

  • Jaringan virtual untuk kluster AKS harus memungkinkan konektivitas internet keluar.

  • Kluster AKS tidak dapat menggunakan 169.254.0.0/16, , 172.31.0.0/16172.30.0.0/16, atau 192.0.2.0/24 untuk rentang alamat layanan Kubernetes, rentang alamat pod, atau rentang alamat jaringan virtual kluster.

  • Identitas kluster yang digunakan oleh kluster AKS harus memiliki setidaknya izin Kontributor Jaringan pada subnet dalam jaringan virtual. Jika Anda ingin menentukan peran kustom alih-alih menggunakan peran Kontributor Jaringan bawaan, izin berikut diperlukan:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read
    • Microsoft.Authorization/roleAssignments/write

  • Subnet yang ditetapkan ke kumpulan simpul AKS tidak dapat menjadi subnet yang didelegasikan.

  • AKS tidak menerapkan Kelompok Keamanan Jaringan (NSG) ke subnetnya dan tidak mengubah NSG apa pun yang terkait dengan subnet tersebut. Jika Anda menyediakan subnet Anda sendiri dan menambahkan NSG yang terkait dengan subnet tersebut, pastikan aturan keamanan di NSG mengizinkan lalu lintas dalam rentang CIDR simpul. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Catatan

Kubenet tidak tersedia untuk kontainer Windows Server. Untuk menggunakan kumpulan simpul Windows Server, Anda perlu menggunakan Azure CNI.

Subnet Simpul Azure CNI

Dengan Azure Container Networking Interface/Jaringan Kontainer Antarmuka (CNI), setiap pod mendapatkan alamat IP dari subnet dan dapat diakses secara langsung. Sistem dalam jaringan virtual yang sama dengan kluster AKS melihat pod IP sebagai alamat sumber untuk setiap lalu lintas dari pod. Sistem di luar jaringan virtual kluster AKS melihat IP simpul sebagai alamat sumber untuk setiap lalu lintas dari pod. Alamat IP ini harus unik di seluruh ruang jaringan Anda dan harus direncanakan terlebih dahulu. Setiap simpul memiliki parameter konfigurasi untuk jumlah maksimum pod yang didukungnya. Jumlah alamat IP yang setara per simpul kemudian dicadangkan di depan untuk simpul tersebut. Pendekatan ini membutuhkan lebih banyak perencanaan, dan sering menyebabkan kelelahan alamat IP atau kebutuhan untuk membangun kembali kluster dalam subnet yang lebih besar seiring dengan meningkatnya permintaan aplikasi Anda.

Dengan Azure CNI Node Subnet, setiap pod menerima alamat IP di subnet IP dan dapat berkomunikasi langsung dengan pod dan layanan lain. Kluster Anda bisa sebesar rentang alamat IP yang Anda tentukan. Namun, Anda harus merencanakan rentang alamat IP terlebih dahulu, dan semua alamat IP digunakan oleh simpul AKS berdasarkan jumlah maksimum pod yang dapat mereka dukung. Fitur dan skenario jaringan tingkat lanjut seperti simpul virtual atau Kebijakan Jaringan (baik Azure atau Calico) didukung dengan Azure CNI.

Parameter penyebaran

Saat Anda membuat kluster AKS, parameter berikut dapat dikonfigurasi untuk jaringan Azure CNI:

Jaringan virtual: Jaringan virtual tempat Anda ingin menyebarkan kluster Kubernetes. Anda dapat membuat jaringan virtual baru atau menggunakan jaringan virtual yang sudah ada. Jika Anda ingin menggunakan jaringan virtual yang ada, pastikan jaringan tersebut berada di lokasi yang sama dan langganan Azure dengan kluster Kubernetes Anda. Untuk informasi tentang batasan dan kuota untuk jaringan virtual Azure, lihat Batas langganan dan layanan Azure, kuota, dan batasan.

Subnet: Subnet dalam jaringan virtual tempat Anda ingin menyebarkan kluster. Anda dapat menambahkan subnet baru ke jaringan virtual selama proses pembuatan kluster. Untuk konektivitas hibrida, rentang alamat tidak boleh tumpang tindih dengan jaringan virtual lainnya di lingkungan Anda.

Plugin Jaringan Azure: Saat plugin jaringan Azure digunakan, layanan LoadBalancer internal dengan "externalTrafficPolicy=Local" tidak dapat diakses dari VM dengan IP di clusterCIDR yang bukan milik kluster AKS.

Rentang alamat layanan Kubernetes: Parameter ini adalah set IP virtual yang ditetapkan Kubernetes ke layanan internal kluster Anda. Rentang ini tidak dapat diperbarui setelah Anda membuat kluster. Anda dapat menggunakan rentang alamat privat apa pun yang memenuhi persyaratan berikut:

  • Tidak boleh berada dalam rentang alamat IP jaringan virtual kluster Anda.
  • Tidak boleh tumpang tindih dengan jaringan virtual lain yang rekan-rekan jaringan virtual klusternya.
  • Tidak boleh tumpang tindih dengan IP lokal apa pun.
  • Tidak boleh berada dalam rentang 169.254.0.0/16, , 172.30.0.0/16, 172.31.0.0/16atau 192.0.2.0/24.

Meskipun dimungkinkan untuk menentukan rentang alamat layanan dalam jaringan virtual yang sama dengan kluster Anda, kami tidak merekomendasikannya. Rentang IP yang tumpang tindih dapat mengakibatkan perilaku yang tidak dapat diprediksi. Untuk informasi selengkapnya, lihat Tanya Jawab Umum. Untuk informasi selengkapnya tentang layanan Kubernetes, lihat Layanan dalam dokumentasi Kubernetes.

Alamat IP layanan DNS Kubernetes: Alamat IP untuk layanan DNS kluster. Alamat ini harus berada dalam rentang alamat layanan Kubernetes. Jangan gunakan alamat IP pertama di rentang alamat Anda. Alamat pertama dalam rentang subnet digunakan untuk alamat kubernetes.default.svc.cluster.local.

Kubenet

Kluster AKS menggunakan kubenet dan membuat jaringan virtual Azure dan subnet untuk Anda secara default. Dengan kubenet, simpul mendapatkan 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 di jaringan virtual Azure. Alamat IP sumber lalu lintas adalah NAT'd ke alamat IP utama simpul. Pendekatan ini sangat mengurangi jumlah alamat IP yang perlu Anda cadangkan di ruang jaringan untuk digunakan pod.

Anda dapat mengonfigurasi pod maksimum yang dapat disebarkan ke node pada waktu pembuatan kluster atau saat membuat kumpulan simpul baru. Jika Anda tidak menentukan maxPods saat membuat kumpulan simpul baru, Anda menerima nilai default 110 untuk kubenet.

Ringkasan jaringan kubenet dengan subnet Anda sendiri

Di banyak lingkungan, Anda telah menentukan jaringan virtual dan subnet dengan rentang alamat IP yang dialokasikan, dan Anda menggunakan sumber daya ini untuk mendukung beberapa layanan dan aplikasi. Untuk menyediakan konektivitas jaringan, kluster AKS dapat menggunakan kubenet (jaringan dasar) atau Azure CNI (jaringan lanjutan).

Dengan kubenet, hanya simpul yang menerima alamat IP di subnet jaringan virtual. Pod tidak dapat berkomunikasi langsung satu sama lain. Sebagai gantinya, Perutean yang Ditentukan Pengguna (UDR) dan penerusan IP menangani konektivitas antar pod di seluruh simpul. UDR dan konfigurasi penerusan IP dibuat dan dikelola oleh layanan AKS secara default, tetapi Anda dapat membawa tabel rute Anda sendiri untuk manajemen rute kustom jika Anda mau. Anda juga dapat menyebarkan pod di belakang layanan yang menerima alamat IP yang ditetapkan dan menyeimbangkan beban lalu lintas untuk aplikasi. Diagram berikut menunjukkan bagaimana simpul AKS menerima alamat IP di subnet jaringan virtual, tetapi tidak di podnya:

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.

Azure mendukung maksimum 400 rute dalam UDR, sehingga Anda tidak dapat memiliki kluster AKS yang lebih besar dari 400 simpul. Simpul virtual AKS dan Kebijakan Jaringan Azure tidak didukung dengan kubenet. Kebijakan Jaringan Calico didukung.

Batasan & pertimbangan untuk kubenet

Catatan

Beberapa pod sistem seperti konektivitas dalam kluster menggunakan alamat IP node host daripada IP dari ruang alamat overlay. Pod sistem hanya akan menggunakan IP simpul dan bukan alamat IP dari jaringan virtual.

Ketersediaan dan kelelahan alamat IP

Masalah umum dengan Azure CNI adalah bahwa rentang alamat IP yang ditetapkan terlalu kecil untuk kemudian menambahkan lebih banyak simpul saat Anda menskalakan atau meningkatkan kluster. Tim jaringan juga mungkin tidak dapat mengeluarkan rentang alamat IP yang cukup besar untuk mendukung permintaan aplikasi yang diharapkan. Sebagai gantinya, Anda dapat membuat kluster AKS yang menggunakan kubenet dan tersambung ke subnet jaringan virtual yang ada. Pendekatan ini memungkinkan simpul menerima alamat IP yang ditentukan tanpa perlu memesan sejumlah besar alamat IP di muka untuk setiap pod potensial yang dapat berjalan di kluster.

Dengan kubenet, Anda dapat menggunakan rentang alamat IP yang jauh lebih kecil dan mendukung kluster besar dan permintaan aplikasi. Misalnya, dengan rentang alamat IP /27 pada subnet Anda, Anda dapat menjalankan kluster node 20-25 dengan ruang yang cukup untuk diskalakan atau ditingkatkan. Ukuran kluster ini dapat mendukung hingga 2.200-2.750 pod (dengan maksimum default 110 pod per simpul). Jumlah maksimum pod per simpul yang dapat Anda konfigurasi dengan kubenet di AKS adalah 250.

Perhitungan dasar berikut membandingkan perbedaan dalam model jaringan:

  • kubenet: Rentang alamat IP /24 sederhana dapat mendukung hingga 251 simpul dalam kluster. Setiap subnet jaringan virtual Azure mencadangkan tiga alamat IP pertama untuk operasi manajemen. Jumlah simpul ini dapat mendukung hingga 27.610 pod, dengan maksimum default 110 pod per simpul.
  • Azure CNI: Rentang subnet /24 dasar yang sama hanya dapat mendukung maksimum 8 simpul dalam kluster. Jumlah simpul ini hanya dapat mendukung hingga 240 pod, dengan maksimum default 30 pod per simpul.

Catatan

Maksimum ini tidak memperhitungkan peningkatan atau skala operasi. Dalam praktiknya, Anda tidak dapat menjalankan jumlah maksimum simpul yang didukung rentang alamat IP subnet. Anda harus membiarkan beberapa alamat IP tersedia untuk operasi penskalaan atau peningkatan.

Peering jaringan virtual dan koneksi ExpressRoute

Anda dapat menggunakan peering jaringan virtual Azure atau koneksi ExpressRoute dengan Azure CNI dan kubenet untuk menyediakan konektivitas lokal. Pastikan Anda merencanakan alamat IP dengan hati-hati untuk mencegah tumpang tindih dan perutean lalu lintas yang salah. Misalnya, banyak jaringan lokal menggunakan rentang alamat 10.0.0.0/8 yang diiklankan melalui koneksi ExpressRoute. Sebaiknya buat kluster AKS Anda di subnet jaringan virtual Azure di luar rentang alamat ini, seperti 172.16.0.0/16.

Untuk informasi selengkapnya, lihat Membandingkan model jaringan dan cakupan dukungannya.

Tanya jawab umum Tentang Subnet Pod Azure CNI

  • Dapatkah saya menyebarkan VM di subnet kluster saya?

    Ya untuk Azure CNI Node Subnet, VM dapat disebarkan di subnet yang sama dengan kluster AKS.

  • IP sumber apa yang dilihat sistem eksternal untuk lalu lintas yang berasal dari pod berkemampuan Azure CNI?

    Sistem dalam jaringan virtual yang sama dengan kluster AKS melihat pod IP sebagai alamat sumber untuk setiap lalu lintas dari pod. Sistem di luar jaringan virtual kluster AKS melihat IP simpul sebagai alamat sumber untuk setiap lalu lintas dari pod. Tetapi untuk alokasi IP dinamis Azure CNI, tidak peduli koneksi berada di dalam jaringan virtual yang sama atau lintas jaringan virtual, IP pod selalu menjadi alamat sumber untuk lalu lintas apa pun dari pod. Ini karena Azure CNI untuk alokasi IP dinamis mengimplementasikan infrastruktur Microsoft Azure Container Networking , yang memberikan pengalaman end-to-end. Oleh karena itu, menghilangkan penggunaan ip-masq-agent, yang masih digunakan oleh Azure CNI tradisional.

  • Dapatkah saya mengonfigurasi kebijakan jaringan per pod?

    Ya, kebijakan jaringan Kubernetes tersedia dalam AKS. Untuk memulai, lihat Amankan lalu lintas antar pod dengan menggunakan kebijakan jaringan di AKS.

  • Apakah jumlah maksimum pod dapat disebarkan ke simpul yang dapat dikonfigurasi?

    Secara default, kluster AKS menggunakan kubenet dan membuat jaringan virtual dan subnet. Dengan kubenet, simpul mendapatkan alamat IP dari subnet jaringan virtual. Network address translation/Penafsiran alamat jaringan (NAT) kemudian dikonfigurasi pada simpul, dan pod menerima alamat IP "tersembunyi" di belakang IP simpul. Pendekatan ini mengurangi jumlah alamat IP yang perlu Anda pesan di ruang jaringan untuk digunakan pod.

    Dengan Azure Container Networking Interface/Jaringan Kontainer Antarmuka (CNI), setiap pod mendapatkan alamat IP dari subnet dan dapat diakses secara langsung. Sistem dalam jaringan virtual yang sama dengan kluster AKS melihat pod IP sebagai alamat sumber untuk setiap lalu lintas dari pod. Sistem di luar jaringan virtual kluster AKS melihat IP simpul sebagai alamat sumber untuk setiap lalu lintas dari pod. Alamat IP ini harus unik di seluruh ruang jaringan Anda dan harus direncanakan terlebih dahulu. Setiap simpul memiliki parameter konfigurasi untuk jumlah maksimum pod yang didukungnya. Jumlah alamat IP yang setara per simpul kemudian dicadangkan di depan untuk simpul tersebut. Pendekatan ini membutuhkan lebih banyak perencanaan, dan sering menyebabkan kelelahan alamat IP atau kebutuhan untuk membangun kembali kluster dalam subnet yang lebih besar seiring dengan meningkatnya permintaan aplikasi Anda.

  • Dapatkah saya menyebarkan VM di subnet kluster saya?

    Ya. Tetapi untuk Azure CNI untuk alokasi IP dinamis, VM tidak dapat disebarkan di subnet pod.

  • IP sumber apa yang dilihat sistem eksternal untuk lalu lintas yang berasal dari pod berkemampuan Azure CNI?

    Sistem dalam jaringan virtual yang sama dengan kluster AKS melihat pod IP sebagai alamat sumber untuk setiap lalu lintas dari pod. Sistem di luar jaringan virtual kluster AKS melihat IP simpul sebagai alamat sumber untuk setiap lalu lintas dari pod.

    Tetapi untuk Azure CNI untuk alokasi IP dinamis, tidak peduli koneksi berada di dalam jaringan virtual yang sama atau lintas jaringan virtual, IP pod selalu menjadi alamat sumber untuk lalu lintas apa pun dari pod. Ini karena Azure CNI untuk alokasi IP dinamis mengimplementasikan infrastruktur Microsoft Azure Container Networking , yang memberikan pengalaman end-to-end. Oleh karena itu, menghilangkan penggunaan ip-masq-agent, yang masih digunakan oleh Azure CNI tradisional.

  • Dapatkah saya menggunakan subnet yang berbeda dalam jaringan virtual kluster saya untuk rentang alamat layanan Kubernetes?

    Ini tidak disarankan, tetapi konfigurasi ini dimungkinkan. Rentang alamat layanan adalah sekumpulan IP virtual (VIP) yang ditetapkan Kubernetes ke layanan internal di kluster Anda. Penjaringan Azure tidak memiliki visibilitas ke dalam rentang IP layanan dari kluster Kubernetes. Kurangnya visibilitas ke dalam rentang alamat layanan kluster dapat menyebabkan masalah. Dimungkinkan untuk kemudian membuat subnet baru di jaringan virtual kluster yang tumpang tindih dengan rentang alamat layanan. Jika tumpang tindih seperti itu terjadi, Kubernetes dapat menetapkan suatu layanan IP yang sudah digunakan oleh sumber daya lain di subnet, menyebabkan perilaku atau kegagalan yang tidak dapat diprediksi. Dengan memastikan Anda menggunakan rentang alamat di luar jaringan virtual kluster, Anda dapat menghindari risiko tumpang tindih ini. Ya, saat Anda menyebarkan kluster dengan Azure CLI atau templat Resource Manager. Lihat Pod maksimum per simpul.

  • Dapatkah saya menggunakan subnet yang berbeda dalam jaringan virtual kluster saya untuk rentang alamat layanan Kubernetes?

    Ini tidak disarankan, tetapi konfigurasi ini dimungkinkan. Rentang alamat layanan adalah sekumpulan IP virtual (VIP) yang ditetapkan Kubernetes ke layanan internal di kluster Anda. Penjaringan Azure tidak memiliki visibilitas ke dalam rentang IP layanan dari kluster Kubernetes. Kurangnya visibilitas ke dalam rentang alamat layanan kluster dapat menyebabkan masalah. Dimungkinkan untuk kemudian membuat subnet baru di jaringan virtual kluster yang tumpang tindih dengan rentang alamat layanan. Jika tumpang tindih seperti itu terjadi, Kubernetes dapat menetapkan suatu layanan IP yang sudah digunakan oleh sumber daya lain di subnet, menyebabkan perilaku atau kegagalan yang tidak dapat diprediksi. Dengan memastikan Anda menggunakan rentang alamat di luar jaringan virtual kluster, Anda dapat menghindari risiko tumpang tindih ini.