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

Secara default, kluster AKS menggunakan kubenet, dan jaringan virtual serta subnet Azure dibuat untuk Anda. 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 simpul. Terjemahan alamat jaringan (NAT) kemudian dikonfigurasi sehingga pod dapat menjangkau sumber daya pada 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 pesan di ruang jaringan Anda agar pod dapat digunakan.

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 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. Anda dapat mengonfigurasi pod maksimum yang dapat disebarkan ke sebuah simpul pada waktu pembuatan kluster atau saat membuat kumpulan simpul baru. Jika Anda tidak menentukan maxPod saat membuat kumpulan simpul baru, Anda akan 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 boleh menggunakan 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16, atau 192.0.2.0/24 untuk rentang alamat layanan Kube, rentang alamat pod, atau rentang alamat jaringan virtual kluster.
  • Identitas kluster yang digunakan oleh kluster AKS harus memiliki setidaknya peran Kontributor Jaringan pada subnet dalam jaringan virtual Anda. Anda juga harus memiliki izin yang sesuai, seperti pemilik langganan, untuk membuat identitas kluster dan menetapkan izinnya. Jika Anda ingin menentukan peran kustom daripada menggunakan peran Kontributor Jaringan bawaan, diperlukan 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. Penggunaan kubenet sebagai model jaringan 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. Sumber daya jaringan virtual ini digunakan 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, User Defined Routing (UDR) dan penerusan IP digunakan untuk konektivitas antar pod di seluruh simpul. Secara default, UDR dan konfigurasi penerusan IP dibuat dan dikelola oleh layanan AKS, tetapi Anda memiliki opsi untuk membawa tabel rute Anda sendiri untuk manajemen rute kustom. Anda juga dapat menerapkan pod di belakang layanan yang menerima alamat IP yang ditetapkan dan lalu lintas load balancing untuk aplikasi tersebut. 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 maksimal 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. Anda dapat menggunakan Kebijakan Jaringan Calico, karena didukung dengan kubenet.

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

Batasan & pertimbangan untuk kubenet

  • Hop tambahan diperlukan dalam desain kubenet, yang menambahkan latensi minor pada komunikasi pod.
  • Tabel rute dan rute yang ditentukan pengguna diperlukan untuk menggunakan kubenet, yang menambah kompleksitas operasi.
  • Pengalamatan pod langsung tidak didukung untuk kubenet karena desain kubenet.
  • Tidak seperti kluster Azure CNI, beberapa kluster kubenet tidak dapat membagikan subnet.
  • AKS tidak menerapkan Kelompok Keamanan Jaringan (NSG) ke subnetnya dan tidak akan mengubah salah satu NSG yang terkait dengan subnet tersebut. Jika Anda menyediakan subnet Anda sendiri dan menambahkan NSG yang dikaitkan dengan subnet tersebut, Anda harus memastikan aturan keamanan di NSG mengizinkan lalu lintas antara simpul dan CIDR pod. Untuk detail selengkapnya, lihat Kelompok keamanan jaringan.
  • Fitur yang tidak didukung pada kubenet meliputi:

Ketersediaan dan kelelahan alamat IP

Dengan Azure CNI, masalah umumnya adalah rentang alamat IP yang ditetapkan terlalu kecil untuk kemudian menambahkan simpul tambahan saat Anda menskalakan atau memutakhirkan kluster. Tim jaringan mungkin juga tidak dapat mengeluarkan rentang alamat IP yang cukup besar untuk mendukung permintaan aplikasi yang Anda harapkan.

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 alamat IP dalam jumlah besar terlebih dahulu untuk semua pod potensial yang dapat berjalan di kluster.

Dengan kubenet, Anda dapat menggunakan rentang alamat IP yang jauh lebih kecil dan mampu mendukung kluster besar dan permintaan aplikasi. Misalnya, bahkan dengan rentang alamat IP /27 di subnet, Anda dapat menjalankan kluster simpul 20-25 dengan ruang yang cukup untuk menskalakan atau meningkatkan. Ukuran kluster ini akan 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 110.

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 menyimpan tiga alamat IP pertama untuk manajemen operasi)
    • Jumlah simpul ini dapat mendukung hingga 27.610 pod (dengan maksimum default 110 pod per simpul dengan kubenet)
  • Azure CNI - rentang subnet dasar /24 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 dengan Azure CNI)

Catatan

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

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 Anda membuat kluster AKS ke subnet jaringan virtual Azure di luar rentang alamat ini, seperti 172.16.0.0/16.

Memilih model jaringan yang akan digunakan

Pilihan plugin jaringan mana yang akan digunakan untuk kluster AKS Anda biasanya merupakan keseimbangan antara fleksibilitas dan kebutuhan konfigurasi lanjutan. Pertimbangan berikut membantu menjelaskan kapan setiap model jaringan mungkin yang paling sesuai.

Gunakan kubenet saat:

  • Anda memiliki ruang alamat IP terbatas.
  • Sebagian besar komunikasi pod ada di dalam kluster.
  • Anda tidak memerlukan fitur AKS lanjutan seperti simpul virtual atau Kebijakan Jaringan Azure. Gunakan kebijakan jaringan Calico.

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 Kebijakan Jaringan Azure. Gunakan kebijakan jaringan Calico.

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

Membuat jaringan virtual dan subnet

Untuk mulai menggunakan kubenet dan subnet jaringan virtual Anda sendiri, pertama-tama buat grup sumber daya menggunakan perintah az group create. Contoh berikut menampilkan cara membuat grup sumber daya bernama myResourceGroup di lokasi eastus:

az group create --name myResourceGroup --location eastus

Jika Anda tidak memiliki jaringan virtual dan subnet untuk digunakan, buat sumber daya jaringan ini menggunakan perintah az network vnet create. Pada contoh berikut, jaringan virtual dinamai myVnet dengan awalan alamat 192.168.0.0/16. Subnet dibuat dengan nama 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

Membuat perwakilan layanan dan menetapkan izin

Untuk memungkinkan kluster AKS berinteraksi dengan sumber daya Azure lainnya, perwakilan layanan Azure Active Directory digunakan. Perwakilan layanan perlu memiliki izin untuk mengelola jaringan virtual dan subnet yang digunakan simpul AKS. Untuk membuat perwakilan layanan, gunakan perintah az ad sp create-for-rbac:

az ad sp create-for-rbac --skip-assignment

Contoh output berikut menunjukkan ID aplikasi dan kata sandi untuk perwakilan layanan Anda. Nilai-nilai ini digunakan dalam langkah-langkah tambahan untuk menetapkan peran ke perwakilan layanan lalu membuat kluster AKS:

{
  "appId": "476b3636-5eda-4c0e-9751-849e70b5cfad",
  "displayName": "azure-cli-2019-01-09-22-29-24",
  "name": "http://azure-cli-2019-01-09-22-29-24",
  "password": "a1024cd7-af7b-469f-8fd7-b293ecbb174e",
  "tenant": "72f998bf-85f1-41cf-92ab-2e7cd014db46"
}

Untuk menetapkan delegasi yang benar di langkah-langkah selanjutnya, gunakan perintah az network vnet show dan az network vnet subnet show untuk mendapatkan ID sumber daya yang diperlukan. ID sumber daya ini disimpan sebagai variabel dan direferensikan di langkah-langkah selanjutnya:

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

Sekarang, tetapkan perwakilan layanan untuk izin Kontributor Jaringan kluster AKS Anda di jaringan virtual menggunakan perintah az role assignment create. Berikan <appId> Anda sendiri seperti yang ditunjukkan pada output dari perintah sebelumnya untuk membuat perwakilan layanan:

az role assignment create --assignee <appId> --scope $VNET_ID --role "Network Contributor"

Membuat kluster AKS di jaringan virtual

Anda sekarang telah membuat jaringan virtual dan subnet, serta membuat dan menetapkan izin untuk perwakilan layanan untuk menggunakan sumber daya jaringan tersebut. Kini buat kluster AKS di jaringan virtual dan subnet Anda menggunakan perintah az aks create. Tentukan perwakilan layanan Anda sendiri <appId> dan <password> , seperti yang ditunjukkan dalam output dari perintah sebelumnya untuk membuat perwakilan layanan.

Rentang alamat IP berikut juga ditentukan sebagai bagian dari proses pembuatan kluster:

  • --service-cidr digunakan untuk menetapkan alamat IP pada layanan internal di kluster AKS. 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.

  • Alamat --dns-service-ip harus berupa alamat .10 dari rentang alamat IP layanan Anda.

  • --pod-cidr harus menjadi 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.

    • 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 jika Anda memerlukan lebih banyak alamat untuk simpul tambahan.
    • 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.
  • --docker-bridge-address memungkinkan simpul AKS berkomunikasi dengan platform manajemen yang mendasarinya. Alamat IP ini tidak boleh berada dalam rentang alamat IP jaringan virtual kluster Anda, dan tidak boleh tumpang tindih dengan rentang alamat lain yang digunakan pada jaringan Anda.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal <appId> \
    --client-secret <password>

Catatan

Jika Anda ingin mengaktifkan kluster AKS untuk menyertakan kebijakan jaringan Calico, Anda dapat menggunakan perintah berikut.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet --network-policy calico \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --pod-cidr 10.244.0.0/16 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal <appId> \
    --client-secret <password>

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 ke dalamnya sepanjang 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

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

Pelajari selengkapnya tentang menyiapkan tabel rute kustom.

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

Keterbatasan:

  • Izin harus ditetapkan sebelum pembuatan kluster, pastikan Anda menggunakan perwakilan layanan dengan izin tulis ke subnet kustom dan tabel rute kustom Anda.
  • Tabel rute kustom harus dikaitkan dengan subnet sebelum Anda membuat kluster AKS.
  • Sumber daya tabel rute terkait tidak dapat diperbarui setelah pembuatan kluster. Meskipun sumber daya tabel rute tidak dapat diperbarui, aturan kustom dapat diubah 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.
  • Anda tidak dapat menyediakan tabel subnet dan rute Anda sendiri dengan identitas terkelola yang ditetapkan sistem. Untuk menyediakan subnet dan tabel rute Anda sendiri, Anda harus menggunakan identitas terkelola yang ditetapkan pengguna, menetapkan izin sebelum pembuatan kluster, dan memastikan identitas yang ditetapkan pengguna telah menulis izin ke subnet kustom dan tabel rute kustom Anda.
  • Menggunakan tabel rute yang sama dengan beberapa kluster AKS tidak didukung.

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

# Find your subnet ID
az network vnet subnet list --resource-group
                            --vnet-name
                            [--subscription]
# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g MyResourceGroup -n MyManagedCluster --vnet-subnet-id MySubnetID

Langkah berikutnya

Dengan kluster AKS yang disebarkan ke subnet jaringan virtual yang ada, Anda sekarang dapat menggunakan kluster seperti biasa. Mulailah dengan membuat aplikasi baru menggunakan Helm atau menyebarkan aplikasi yang sudah ada menggunakan Helm.