Bagikan melalui

Menggunakan jaringan kubenet dengan rentang alamat IP Anda sendiri di Azure Kubernetes Service (AKS)

  • Artikel

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.

Dengan Azure Container Networking Interface/Jaringan Kontainer Antarmuka (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 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. 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.

Artikel ini menunjukkan kepada Anda cara menggunakan jaringan kubenet untuk membuat dan menggunakan subnet jaringan virtual untuk kluster AKS. Untuk informasi selengkapnya tentang opsi dan pertimbangan jaringan, lihat Konsep jaringan untuk Kube dan AKS.

Prasyarat

  • Jaringan virtual untuk kluster AKS harus memungkinkan konektivitas internet keluar.
  • Jangan membuat lebih dari satu kluster AKS di subnet yang sama.
  • 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. Rentang tidak dapat diperbarui setelah Anda membuat kluster.
  • Identitas kluster yang digunakan oleh kluster AKS setidaknya harus memiliki peran Kontributor Jaringan pada subnet dalam jaringan virtual Anda. CLI membantu mengatur penetapan peran secara otomatis. Jika Anda menggunakan templat ARM atau klien lain, Anda perlu mengatur penetapan peran secara manual. Anda juga harus memiliki izin yang sesuai, seperti pemilik langganan, untuk membuat identitas kluster dan menetapkan izinnya. Jika Anda ingin menentukan peran kustom alih-alih menggunakan peran Kontributor Jaringan bawaan, Anda memerlukan izin berikut:
    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/virtualNetworks/subnets/read

Peringatan

Untuk menggunakan kumpulan simpul Windows Server, Anda harus menggunakan Azure CNI. Model jaringan kubenet tidak tersedia untuk kontainer Windows Server.

Sebelum Anda mulai

Anda memerlukan Azure CLI versi 2.0.65 atau yang lebih baru yang sudah terpasang dan terkonfigurasi. Jalankan az --version untuk menemukan versinya. Jika Anda perlu memasang atau meningkatkan, lihat Memasang Azure CLI.

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:

Model jaringan kubenet dengan kluster AKS

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.

Dengan Azure CNI, 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.

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 dasar /24 yang sama hanya dapat mendukung maksimum delapan 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

Untuk menyediakan konektivitas lokal, pendekatan jaringan kubenet dan Azure-CNI dapat menggunakan peering jaringan virtual Azure atau koneksi ExpressRoute. Rencanakan rentang alamat IP Anda 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.

Memilih model jaringan yang akan digunakan

Pertimbangan berikut membantu menguraikan kapan setiap model jaringan mungkin yang paling tepat:

Gunakan kubenet saat:

  • Anda memiliki ruang alamat IP terbatas.
  • Sebagian besar komunikasi pod ada di dalam kluster.
  • Anda tidak memerlukan fitur AKS tingkat lanjut, seperti simpul virtual atau Azure Network Policy.

Gunakan Azure CNI saat:

  • Anda memiliki ruang alamat IP yang tersedia.
  • Sebagian besar komunikasi pod adalah ke sumber daya di luar kluster.
  • Anda tidak ingin mengelola rute yang ditentukan pengguna untuk konektivitas pod.
  • Anda memerlukan fitur lanjutan AKS, seperti simpul virtual atau Azure Network Policy.

Untuk informasi selengkapnya guna membantu Anda memutuskan model jaringan yang akan digunakan, lihat Membandingkan model jaringan dan cakupan dukungannya.

Membuat jaringan virtual dan subnet

  1. Buat grup sumber daya menggunakan az group create perintah .

    az group create --name myResourceGroup --location eastus

  2. Jika Anda tidak memiliki jaringan virtual dan subnet yang sudah ada untuk digunakan, buat sumber daya jaringan ini menggunakan az network vnet create perintah . Contoh perintah berikut membuat jaringan virtual bernama myAKSVnet dengan awalan alamat 192.168.0.0/16 dan subnet bernama myAKSSubnet dengan awalan alamat 192.168.1.0/24:

    az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24 \
    --location eastus

  3. Dapatkan ID sumber daya subnet menggunakan az network vnet subnet show perintah dan simpan sebagai variabel bernama SUBNET_ID untuk digunakan nanti.

    SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

Membuat kluster AKS di jaringan virtual

Membuat kluster AKS dengan identitas terkelola yang ditetapkan sistem

Catatan

Saat menggunakan identitas yang ditetapkan sistem, Azure CLI memberikan peran Kontributor Jaringan ke identitas yang ditetapkan sistem setelah kluster dibuat. Jika Anda menggunakan templat ARM atau klien lain, Anda perlu menggunakan identitas terkelola yang ditetapkan pengguna sebagai gantinya.

  • Buat kluster AKS dengan identitas terkelola yang ditetapkan sistem menggunakan az aks create perintah .

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --vnet-subnet-id $SUBNET_ID \
    --generate-ssh-keys

    Parameter penyebaran:

    • --service-cidr bersifat opsional. Alamat ini digunakan untuk menetapkan layanan internal di kluster AKS alamat IP. Rentang alamat IP ini harus berupa ruang alamat yang tidak digunakan di tempat lain di lingkungan jaringan Anda, termasuk rentang jaringan lokal apa pun jika Anda tersambung, atau berencana menyambungkan, jaringan virtual Azure Anda menggunakan Rute Ekspres atau koneksi VPN Situs-ke-Situs. Nilai defaultnya adalah 10.0.0.0/16.
    • --dns-service-ip bersifat opsional. Alamat harus menjadi alamat .10 dari rentang alamat IP layanan Anda. Nilai defaultnya adalah 10.0.0.10.
    • --pod-cidr bersifat opsional. Alamat ini harus berupa ruang alamat besar yang tidak digunakan di tempat lain di lingkungan jaringan Anda. Rentang ini mencakup rentang jaringan lokal jika Anda tersambung, atau berencana menyambungkan, jaringan virtual Azure Anda menggunakan Rute Ekspres atau koneksi VPN Situs-ke-Situs. Nilai defaultnya adalah 10.244.0.0/16.
      • Rentang alamat ini harus cukup besar untuk mengakomodasi jumlah simpul yang ingin Anda tingkatkan skalanya. Anda tidak dapat mengubah rentang alamat ini setelah kluster disebarkan.
      • Rentang alamat IP pod digunakan untuk menetapkan ruang alamat /24 ke setiap simpul dalam kluster. Pada contoh berikut, --pod-cidr dari 10.244.0.0/16 menetapkan simpul pertama 10.244.0.0/24, simpul kedua 10.244.1.0/24, dan simpul ketiga 10.244.2.0/24.
      • Saat kluster menskalakan atau meningkatkan, platform Azure terus menetapkan rentang alamat IP pod ke setiap simpul baru.

Membuat kluster AKS dengan identitas terkelola yang ditetapkan pengguna

Buat identitas terkelola

  • Buat identitas terkelola menggunakan az identity perintah . Jika Anda memiliki identitas terkelola yang sudah ada, temukan ID utama menggunakan perintah sebagai gantinya az identity show --ids <identity-resource-id> .

    az identity create --name myIdentity --resource-group myResourceGroup

    Output Anda harus menyerupai contoh output berikut:

    {                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Menambahkan penetapan peran untuk identitas terkelola

Jika Anda menggunakan Azure CLI, peran ditambahkan secara otomatis dan Anda dapat melewati langkah ini. Jika Anda menggunakan templat ARM atau klien lain, Anda perlu menggunakan ID Utama identitas terkelola kluster untuk melakukan penetapan peran.

  • Dapatkan ID sumber daya jaringan virtual menggunakan az network vnet show perintah dan simpan sebagai variabel bernama VNET_ID.

    VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

  • Tetapkan identitas terkelola untuk izin Kontributor Jaringan kluster AKS Anda di jaringan virtual menggunakan az role assignment create perintah dan berikan <principalId>.

    az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

# Example command
az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Catatan

Izin yang diberikan untuk identitas terkelola kluster Anda yang digunakan oleh Azure mungkin perlu waktu hingga 60 menit untuk dicatat dalam database.

Membuat kluster AKS

  • Buat kluster AKS menggunakan az aks create perintah dan berikan ID sumber daya identitas terkelola sarana kontrol untuk assign-identity argumen untuk menetapkan identitas terkelola yang ditetapkan pengguna.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --assign-identity <identity-resource-id> \
    --generate-ssh-keys

Saat Anda membuat kluster AKS, grup keamanan jaringan dan tabel rute akan dibuat secara otomatis. Sumber daya jaringan ini dikelola oleh sarana kontrol AKS. Grup keamanan jaringan secara otomatis dikaitkan dengan NIC virtual pada simpul Anda. Tabel rute secara otomatis dikaitkan dengan subnet jaringan virtual. Aturan grup keamanan jaringan dan tabel rute diperbarui secara otomatis saat Anda membuat dan mengekspos layanan.

Membawa subnet dan tabel rute Anda sendiri dengan kubenet

Dengan kubenet, tabel rute harus ada di subnet kluster Anda. AKS mendukung menghadirkan subnet dan tabel rute Anda sendiri yang sudah ada. Jika subnet kustom Anda tidak berisi tabel rute, AKS membuatnya untuk Anda dan menambahkan aturan di seluruh siklus hidup kluster. Jika subnet kustom Anda berisi tabel rute saat Anda membuat kluster, AKS mengakui tabel rute yang ada selama operasi kluster dan menambahkan/memperbarui aturan yang sesuai untuk operasi penyedia cloud.

Peringatan

Anda dapat menambahkan/memperbarui aturan kustom pada tabel rute kustom. Namun, aturan ditambahkan oleh penyedia cloud Kubernetes yang tidak dapat diperbarui atau dihapus. Aturan seperti 0.0.0.0/0 harus selalu ada pada tabel rute tertentu dan memetakan ke target gateway internet Anda, seperti NVA atau gateway keluar lainnya. Berhati-hatilah saat memperbarui aturan.

Pelajari selengkapnya tentang menyiapkan tabel rute kustom.

Jaringan kubenet memerlukan aturan tabel rute terorganisir untuk berhasil merutekan permintaan. Karena desain ini, tabel rute harus dipertahankan dengan hati-hati untuk setiap kluster yang bergantung padanya. Beberapa kluster tidak dapat berbagi tabel rute karena CIDR pod dari kluster yang berbeda mungkin tumpang tindih yang menyebabkan skenario perutean yang tidak terduga dan rusak. Saat mengonfigurasi beberapa kluster pada jaringan virtual yang sama atau mendedikasikan jaringan virtual ke setiap kluster, pertimbangkan batasan berikut:

  • Tabel rute kustom harus dikaitkan dengan subnet sebelum Anda membuat kluster AKS.
  • Sumber daya tabel rute terkait tidak dapat diperbarui setelah pembuatan kluster. Namun, aturan kustom dapat dimodifikasi pada tabel rute.
  • Setiap kluster AKS harus menggunakan tabel rute tunggal yang unik untuk semua subnet yang terkait dengan kluster. Anda tidak dapat menggunakan kembali tabel rute dengan beberapa kluster karena potensi CIDR pod yang tumpang tindih dan aturan perutean yang bertentangan.
  • Untuk identitas terkelola yang ditetapkan sistem, hanya didukung untuk menyediakan subnet dan tabel rute Anda sendiri melalui Azure CLI karena Azure CLI secara otomatis menambahkan penetapan peran. Jika Anda menggunakan templat ARM atau klien lain, Anda harus menggunakan identitas terkelola yang ditetapkan pengguna, menetapkan izin sebelum pembuatan kluster, dan memastikan identitas yang ditetapkan pengguna memiliki izin tulis ke subnet kustom dan tabel rute kustom Anda.
  • Menggunakan tabel rute yang sama dengan beberapa kluster AKS tidak didukung.

Catatan

Saat membuat dan menggunakan VNet sendiri dan tabel rute dengan plugin jaringan kubenet, Anda harus mengonfigurasi identitas terkelola yang ditetapkan pengguna untuk kluster. Dengan identitas terkelola yang ditetapkan sistem, Anda tidak dapat mengambil ID identitas sebelum membuat kluster, yang menyebabkan penundaan selama penetapan peran.

Identitas terkelola yang ditetapkan sistem dan ditetapkan pengguna didukung saat Anda membuat dan menggunakan VNet Anda sendiri dan tabel rute dengan plugin jaringan Azure. Sebaiknya gunakan identitas terkelola yang ditetapkan pengguna untuk skenario BYO.

Menambahkan tabel rute dengan identitas terkelola yang ditetapkan pengguna ke kluster AKS Anda

Setelah membuat tabel rute kustom dan mengaitkannya dengan subnet di jaringan virtual, Anda dapat membuat kluster AKS baru yang menentukan tabel rute Anda dengan identitas terkelola yang ditetapkan pengguna. Anda perlu menggunakan ID subnet tempat Anda berencana untuk menyebarkan kluster AKS. Subnet ini juga harus dikaitkan dengan tabel rute kustom Anda.

  1. Dapatkan ID subnet menggunakan az network vnet subnet list perintah .

    az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]

  2. Buat kluster AKS dengan subnet kustom yang telah dikonfigurasi sebelumnya dengan tabel rute menggunakan az aks create perintah dan menyediakan nilai Anda untuk --vnet-subnet-id parameter dan --assign-identity .

    az aks create \
    --resource-group myResourceGroup \
    --name myManagedCluster \
    --vnet-subnet-id mySubnetIDResourceID \
    --assign-identity controlPlaneIdentityResourceID \
    --generate-ssh-keys

Langkah berikutnya

Artikel ini menunjukkan kepada Anda cara menyebarkan kluster AKS ke subnet jaringan virtual yang ada. Sekarang, Anda dapat mulai membuat aplikasi baru menggunakan Helm atau menyebarkan aplikasi yang ada menggunakan Helm.