Bagikan melalui

Gambaran umum konfigurasi jaringan untuk penyediaan otomatis simpul (NAP) di Azure Kubernetes Service (AKS)

Artikel ini memberikan gambaran umum tentang persyaratan konfigurasi jaringan dan rekomendasi untuk kluster Azure Kubernetes Service (AKS) menggunakan penyediaan otomatis node (NAP). Ini mencakup konfigurasi yang didukung, perilaku subnet default, penyiapan kontrol akses berbasis peran (RBAC), dan pertimbangan classless inter-domain routing (CIDR).

Untuk gambaran umum provisi otomatis simpul di AKS, lihat Gambaran Umum provisi otomatis simpul (NAP) di Azure Kubernetes Service (AKS).

Konfigurasi jaringan yang didukung untuk NAP

NAP mendukung konfigurasi jaringan berikut:

Sebaiknya gunakan Azure CNI dengan Cilium. Cilium menyediakan kemampuan jaringan tingkat lanjut dan dioptimalkan untuk performa dengan NAP.

Konfigurasi jaringan yang tidak didukung untuk NAP

NAP tidak mendukung konfigurasi jaringan berikut:

  • Kebijakan jaringan Calico
  • Alokasi IP dinamis

Konfigurasi subnet untuk NAP

NAP secara otomatis menyebarkan, mengonfigurasi, dan mengelola Karpenter pada kluster AKS Anda dan didasarkan pada proyek penyedia Karpenter dan AKS Karpenter sumber terbuka. Anda dapat menggunakan AKSNodeClass sumber daya untuk menentukan konfigurasi subnet kustom untuk simpul NAP di kumpulan simpul Anda dengan mengatur bidang opsional vnetSubnetID, dan Karpenter menggunakan subnet yang Anda tentukan untuk penyediaan simpul. Jika Anda tidak menentukan subnet, Karpenter menggunakan subnet default yang dikonfigurasi selama penginstalan Karpenter. Subnet default ini biasanya merupakan subnet yang sama yang ditentukan selama pembuatan kluster AKS dengan --vnet-subnet-id parameter dalam az aks create perintah .

Pendekatan ini memungkinkan Anda untuk memiliki campuran kelas node, dengan beberapa menggunakan subnet kustom untuk beban kerja tertentu, dan yang lain menggunakan konfigurasi subnet default kluster.

Perilaku pergeseran subnet

Karpenter memantau perubahan konfigurasi subnet dan mendeteksi penyimpangan saat vnetSubnetID dimodifikasi dalam AKSNodeClass. Memahami perilaku ini sangat penting saat mengelola konfigurasi jaringan kustom.

Memodifikasi vnetSubnetID dari satu subnet yang valid ke subnet lain yang valid bukanlah operasi yang didukung. Jika Anda mengubah vnetSubnetID sehingga menunjuk pada subnet valid yang berbeda, Karpenter mendeteksi ini sebagai drift subnet dan mencegah provisioning node hingga masalah tersebut diselesaikan dengan mengembalikan vnetSubnetID ke subnet asli. Perilaku ini memastikan bahwa simpul hanya disediakan dalam subnet yang dimaksudkan, menjaga integritas dan keamanan jaringan. Namun, ada pengecualian untuk aturan ini. Anda hanya dapat mengubah vnetSubnetID dalam skenario berikut:

  • Mengoreksi ID subnet cacat yang mencegah provisi simpul.
  • Memperbaiki referensi subnet yang tidak valid yang menyebabkan kesalahan konfigurasi.
  • Memperbarui pengidentifikasi subnet yang menunjuk ke subnet yang tidak ada atau tidak dapat diakses.

Memahami rentang Classless Inter-Domain Routing (CIDR) pada kluster AKS

Saat mengonfigurasi jaringan kustom dengan vnetSubnetID, Anda bertanggung jawab untuk memahami dan mengelola rentang CIDR kluster Anda untuk menghindari konflik jaringan. Tidak seperti kumpulan simpul AKS tradisional yang dibuat melalui templat ARM, Karpenter menerapkan definisi sumber daya kustom (CRD) yang menyediakan simpul secara instan tanpa validasi yang diperluas yang disediakan ARM.

Pertimbangan CIDR untuk konfigurasi subnet kustom

Saat mengonfigurasi vnetSubnetID, Anda harus:

  • Verifikasi kompatibilitas CIDR: Pastikan subnet kustom tidak bertentangan dengan rentang CIDR yang ada.
  • Rencanakan kapasitas IP: Hitung alamat IP yang diperlukan untuk skalabilitas yang diharapkan.
  • Memvalidasi konektivitas: Menguji rute jaringan dan aturan grup keamanan.
  • Memantau penggunaan: Melacak pemanfaatan subnet dan merencanakan pertumbuhan.
  • Konfigurasi dokumen: Pertahankan rekaman keputusan desain jaringan.

Konflik CIDR umum

Ketahui skenario konflik CIDR umum berikut saat menggunakan subnet kustom dengan NAP:

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

Penyiapan RBAC untuk konfigurasi subnet kustom

Saat menggunakan konfigurasi subnet kustom dengan NAP, Anda perlu memastikan bahwa Karpenter memiliki izin yang diperlukan untuk membaca informasi subnet dan menggabungkan simpul ke subnet yang ditentukan. Ini memerlukan pengaturan izin RBAC yang sesuai untuk identitas terkelola kluster.

Ada dua pendekatan utama untuk menyiapkan izin ini: Tetapkan izin jaringan virtual luas (VNet) atau Tetapkan izin subnet tercakup.

Pendekatan ini adalah yang paling permisif dan memberikan izin identitas kluster untuk membaca dan menggabungkan subnet apa pun dalam VNet utama dan menyediakan akses kontributor jaringan.

Penting

Selidiki peran "Kontributor Jaringan" sebelum menerapkan pendekatan ini ke kluster produksi Anda.

Manfaat dan pertimbangan

Tabel berikut menguraikan manfaat dan pertimbangan menetapkan izin VNet yang luas:

Keuntungan Pertimbangan
• Menyederhanakan manajemen izin.
• Menghilangkan kebutuhan untuk memperbarui izin saat menambahkan subnet baru.
• Bekerja dengan baik untuk lingkungan tenant tunggal.
• Fungsi ketika langganan mencapai jumlah maksimum peran kustom.		 • Menyediakan izin yang lebih luas daripada yang diperlukan secara ketat.
• Mungkin tidak memenuhi persyaratan keamanan yang ketat.

Memerlukan izin

Untuk menetapkan izin VNet yang luas, berikan identitas terkelola kluster izin berikut di VNet:

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

Untuk contoh lengkap menyiapkan jaringan kustom dan menetapkan izin VNet yang luas, lihat skrip sampel VNET Kustom - Sampel RBAC paling permisif.

Contoh konfigurasi subnet kustom

Contoh berikut menunjukkan cara mengonfigurasi subnet kustom untuk node NAP menggunakan vnetSubnetID kolom di dalam AKSNodeClass sumber daya:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

Contoh berikut menunjukkan cara menggunakan beberapa kelas simpul dengan konfigurasi subnet yang berbeda:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Kebijakan dukungan "Bring Your Own CNI" (BYO CNI)

Karpenter untuk Azure memungkinkan Anda menggunakan konfigurasi Container Network Interface (CNI) sesuai pilihan Anda (BYO CNI), mengikuti kebijakan dukungan yang sama dengan AKS. Ini berarti bahwa saat menggunakan CNI kustom, dukungan pemecahan masalah yang terkait dengan jaringan berada di luar cakupan perjanjian atau jaminan tingkat layanan apa pun.

Detail cakupan dukungan

Berikut menguraikan apa yang didukung dan yang tidak didukung saat menggunakan BYO CNI dengan Karpenter:

  • Didukung: Fungsionalitas khusus Karpenter dan masalah integrasi saat menggunakan konfigurasi CNI bawa-sendiri (BYO).
  • Tidak didukung: Masalah jaringan khusus CNI, masalah konfigurasi, atau pemecahan masalah saat menggunakan plugin CNI pihak ketiga.

Langkah selanjutnya

Untuk informasi selengkapnya tentang node auto-provisioning di AKS, lihat artikel berikut ini:

  • Last updated on