Edit

Bagikan melalui

Node Kubernetes dan manajemen kumpulan simpul

Azure Kubernetes Service (AKS)
Azure Virtual Machines

Arsitektur Kubernetes didasarkan pada dua lapisan: Sarana kontrol dan satu atau beberapa simpul dalam kumpulan simpul. Artikel ini menjelaskan dan membandingkan cara Amazon Elastic Kubernetes Service (Amazon EKS) dan Azure Kubernetes Service (AKS) mengelola simpul agen atau pekerja.

Catatan

Artikel ini adalah bagian dari serangkaian artikel yang membantu para profesional yang terbiasa dengan Amazon EKS untuk memahami AKS.

Di Amazon EKS dan AKS, platform cloud menyediakan dan mengelola lapisan sarana kontrol, dan pelanggan mengelola lapisan node. Diagram berikut menunjukkan hubungan antara sarana kontrol dan simpul dalam arsitektur AKS Kubernetes.

Diagram yang menunjukkan sarana kontrol dan simpul dalam arsitektur AKS.

Grup simpul terkelola Amazon EKS

Grup simpul terkelola Amazon EKS mengotomatiskan provisi dan manajemen siklus hidup simpul pekerja Amazon Elastic Compute Cloud (EC2) untuk kluster Amazon EKS. Pengguna Amazon Web Services (AWS) dapat menggunakan utilitas baris perintah eksctl untuk membuat, memperbarui, atau mengakhiri simpul untuk kluster EKS mereka. Pembaruan dan penghentian node secara otomatis menghubungkan dan menguras node untuk memastikan bahwa aplikasi tetap tersedia.

Setiap simpul terkelola disediakan sebagai bagian dari grup Penskalaan Otomatis Amazon EC2 yang dioperasikan dan dikontrol Amazon EKS. Autoscaler kluster Kubernetes secara otomatis menyesuaikan jumlah simpul pekerja dalam kluster ketika pod gagal atau dijadwalkan ulang ke simpul lain. Setiap grup simpul dapat dikonfigurasi untuk berjalan di beberapa Zona Ketersediaan dalam suatu wilayah.

Untuk informasi selengkapnya tentang simpul terkelola Amazon EKS, lihat Membuat grup simpul terkelola dan Memperbarui grup simpul terkelola.

Anda juga dapat menjalankan pod Kubernetes di AWS Fargate. Fargate menyediakan kapasitas komputasi sesuai permintaan dan berukuran tepat untuk kontainer. Untuk informasi selengkapnya tentang cara menggunakan Fargate dengan Amazon EKS, lihat AWS Fargate.

Simpul AKS dan kumpulan simpul

Membuat kluster AKS secara otomatis membuat dan mengonfigurasi sarana kontrol, yang menyediakan layanan Kubernetes inti dan orkestrasi beban kerja aplikasi. Platform Azure menyediakan sarana kontrol AKS tanpa biaya sebagai sumber daya Azure terkelola. Sarana kontrol dan sumber dayanya hanya ada di wilayah tempat Anda membuat kluster.

Simpul, juga disebut simpul agen atau simpul pekerja, menghosting beban kerja dan aplikasi. Di AKS, pelanggan sepenuhnya mengelola dan membayar node agen yang dilampirkan ke kluster AKS.

Untuk menjalankan aplikasi dan layanan pendukung, kluster AKS membutuhkan setidaknya satu node: Komputer virtual (VM) Azure untuk menjalankan komponen node Kubernetes dan runtime kontainer. Setiap kluster AKS harus berisi setidaknya satu kumpulan simpul sistem dengan setidaknya satu simpul.

AKS mengelompokkan node dengan konfigurasi yang sama ke dalam kumpulan simpul VM yang menjalankan beban kerja AKS. Kumpulan simpul sistem melayani tujuan utama untuk menghosting pod sistem penting seperti CoreDNS. Kumpulan simpul pengguna melayani tujuan utama untuk menghosting pod beban kerja. Jika Anda hanya ingin memiliki satu kumpulan simpul di kluster AKS Anda, misalnya di lingkungan pengembangan, Anda dapat menjadwalkan pod aplikasi pada kumpulan simpul sistem.

Diagram memperlihatkan satu simpul Kubernetes.

Anda juga dapat membuat beberapa kumpulan simpul pengguna untuk memisahkan beban kerja yang berbeda pada simpul yang berbeda untuk menghindari masalah tetangga yang bising, atau untuk mendukung aplikasi dengan permintaan komputasi atau penyimpanan yang berbeda.

Setiap simpul agen dari sistem atau kumpulan simpul pengguna adalah VM yang disediakan sebagai bagian dari Azure Virtual Machine Scale Sets dan dikelola oleh kluster AKS. Untuk informasi selengkapnya, lihat Simpul dan kumpulan simpul.

Anda dapat menentukan jumlah dan ukuran awal untuk simpul pekerja saat membuat kluster AKS, atau saat Anda menambahkan simpul dan kumpulan simpul baru ke kluster AKS yang ada. Jika Anda tidak menentukan ukuran VM, ukuran defaultnya adalah Standard_D2s_v3 untuk kumpulan simpul Windows dan Standard_DS2_v2 untuk kumpulan simpul Linux.

Penting

Untuk memberikan latensi yang lebih baik untuk panggilan intra-node dan komunikasi dengan layanan platform, pilih seri VM yang mendukung Accelerated Networking.

Pembuatan kumpulan simpul

Anda dapat menambahkan kumpulan simpul ke kluster AKS baru atau yang sudah ada dengan menggunakan alat portal Azure, Azure CLI, AKS REST API, atau infrastruktur sebagai kode (IaC) seperti Bicep, templat Azure Resource Manager (ARM), atau Terraform. Untuk informasi selengkapnya tentang cara menambahkan kumpulan simpul ke kluster AKS yang ada, lihat Membuat dan mengelola beberapa kumpulan simpul untuk kluster di Azure Kubernetes Service (AKS).

Saat Anda membuat kumpulan simpul baru, set skala komputer virtual terkait dibuat di grup sumber daya simpul, grup sumber daya Azure yang berisi semua sumber daya infrastruktur untuk kluster AKS. Sumber daya ini termasuk simpul Kubernetes, sumber daya jaringan virtual, identitas terkelola, dan penyimpanan.

Secara default, grup sumber daya simpul memiliki nama seperti MC_<resourcegroupname>_<clustername>_<location>. AKS secara otomatis menghapus grup sumber daya simpul saat menghapus kluster, jadi Anda harus menggunakan grup sumber daya ini hanya untuk sumber daya yang berbagi siklus hidup kluster.

Menambahkan kumpulan simpul

Contoh kode berikut menggunakan perintah az aks nodepool add Azure CLI untuk menambahkan kumpulan simpul bernama mynodepool dengan tiga node ke kluster AKS yang ada yang disebut myAKSCluster dalam myResourceGroup grup sumber daya.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Kumpulan simpul spot

Kumpulan simpul spot adalah kumpulan simpul yang didukung oleh set skala spot. Menggunakan komputer virtual spot untuk simpul dengan kluster AKS Anda memanfaatkan kapasitas Azure yang tidak digunakan dengan penghematan biaya yang signifikan. Jumlah kapasitas yang tidak dimanfaatkan yang tersedia bervariasi berdasarkan banyak faktor, termasuk ukuran simpul, wilayah, dan waktu hari.

Saat menyebarkan kumpulan simpul spot, Azure mengalokasikan simpul spot jika ada kapasitas yang tersedia. Tetapi tidak ada perjanjian tingkat layanan (SLA) untuk simpul spot. Set skala spot yang mendukung kumpulan simpul spot disebarkan dalam satu domain kesalahan dan tidak menawarkan jaminan ketersediaan tinggi. Ketika Azure membutuhkan kapasitas kembali, infrastruktur Azure mengeluarkan simpul spot, dan Anda mendapatkan pemberitahuan paling banyak 30 detik sebelum pengeluaran. Ketahuilah bahwa kumpulan simpul spot tidak dapat menjadi kumpulan simpul default kluster. Kumpulan simpul spot hanya dapat digunakan untuk kumpulan sekunder.

Simpul spot adalah untuk beban kerja yang dapat menangani gangguan, penghentian dini, atau pengeluaran. Misalnya, pekerjaan pemrosesan batch, lingkungan pengembangan dan pengujian, dan beban kerja komputasi besar adalah kandidat yang baik untuk penjadwalan pada kumpulan simpul spot. Untuk detail selengkapnya, lihat batasan instans spot.

Perintah berikut az aks nodepool add menambahkan kumpulan simpul spot ke kluster yang ada dengan autoscaling diaktifkan.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Untuk informasi selengkapnya tentang kumpulan simpul spot, lihat Menambahkan kumpulan simpul spot ke kluster Azure Kubernetes Service (AKS).

Disk OS sementara

Secara default, Azure secara otomatis mereplikasi disk sistem operasi (OS) VM ke Azure Storage untuk menghindari kehilangan data jika VM perlu direlokasi ke host lain. Tetapi karena kontainer tidak dirancang untuk mempertahankan status lokal, menjaga disk OS dalam penyimpanan menawarkan nilai terbatas untuk AKS. Ada beberapa kelemahan, seperti provisi simpul yang lebih lambat dan latensi baca/tulis yang lebih tinggi.

Sebaliknya, disk OS sementara hanya disimpan di komputer host, seperti disk sementara, dan memberikan latensi baca/tulis yang lebih rendah dan penskalaan node yang lebih cepat dan peningkatan kluster. Seperti disk sementara, disk OS sementara disertakan dalam harga VM, sehingga Anda tidak dikenakan biaya penyimpanan tambahan.

Penting

Jika Anda tidak secara eksplisit meminta disk terkelola untuk OS, AKS default ke OS sementara jika memungkinkan untuk konfigurasi kumpulan simpul tertentu.

Untuk menggunakan OS ephemeral, disk OS harus pas di cache VM. Dokumentasi Azure VM memperlihatkan ukuran cache VM dalam tanda kurung di samping throughput IO sebagai ukuran cache dalam gibibyte (GiB).

Misalnya, ukuran VM Standard_DS2_v2 default AKS dengan ukuran disk OS 100 GB default mendukung OS ephemeral, tetapi hanya memiliki ukuran cache 86 GB. Konfigurasi ini default ke disk terkelola jika Anda tidak secara eksplisit menentukan sebaliknya. Jika Anda secara eksplisit meminta OS sementara untuk ukuran ini, Anda mendapatkan kesalahan validasi.

Jika Anda meminta VM Standard_DS2_v2 yang sama dengan disk OS 60 GB, Anda mendapatkan OS ephemeral secara default. Ukuran OS 60 GB yang diminta lebih kecil dari ukuran cache maksimum 86 GB.

Standard_D8s_v3 dengan disk OS 100 GB mendukung OS ephemeral dan memiliki ruang cache 200 GB. Jika pengguna tidak menentukan jenis disk OS, kumpulan simpul akan mendapatkan OS ephemeral secara default.

Perintah berikut az aks nodepool add menunjukkan cara menambahkan kumpulan simpul baru ke kluster yang ada dengan disk OS ephemeral. Parameter --node-osdisk-type mengatur jenis disk OS ke Ephemeral, dan --node-osdisk-size parameter menentukan ukuran disk OS.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Untuk informasi selengkapnya tentang disk OS ephemeral, lihat OS Ephemeral.

Node virtual

Anda dapat menggunakan simpul virtual untuk menskalakan beban kerja aplikasi dengan cepat dalam kluster AKS. Simpul virtual memberi Anda provisi pod cepat, dan Anda hanya membayar per detik untuk waktu eksekusi. Anda tidak perlu menunggu autoscaler kluster menyebarkan simpul pekerja baru untuk menjalankan lebih banyak replika pod. Simpul virtual hanya didukung dengan pod dan simpul Linux. Add-on simpul virtual untuk AKS didasarkan pada proyek Kubelet Virtual sumber terbuka.

Fungsionalitas simpul virtual tergantung pada Azure Container Instances. Untuk informasi selengkapnya tentang simpul virtual, lihat Membuat dan mengonfigurasi kluster Azure Kubernetes Services (AKS) untuk menggunakan simpul virtual.

Taint, label, dan tag

Saat membuat kumpulan simpul, Anda dapat menambahkan taint dan label Kubernetes, dan tag Azure, ke kumpulan simpul tersebut. Saat Anda menambahkan taint, label, atau tag, semua simpul dalam kumpulan simpul tersebut mendapatkan taint, label, atau tag tersebut.

Untuk membuat kumpulan simpul dengan taint, Anda dapat menggunakan az aks nodepool add perintah dengan --node-taints parameter . Untuk memberi label simpul dalam kumpulan simpul, Anda dapat menggunakan --labels parameter dan menentukan daftar label, seperti yang ditunjukkan dalam kode berikut:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Untuk informasi selengkapnya, lihat Menentukan taint, label, atau tag untuk kumpulan node.

Label sistem yang dicadangkan

Amazon EKS menambahkan label Kubernetes otomatis ke semua simpul dalam grup simpul terkelola seperti eks.amazonaws.com/capacityType, yang menentukan jenis kapasitas. AKS juga secara otomatis menambahkan label sistem ke simpul agen.

Awalan berikut dicadangkan untuk penggunaan AKS dan tidak dapat digunakan untuk simpul apa pun:

  • kubernetes.azure.com/
  • kubernetes.io/

Untuk awalan cadangan lainnya, lihat label, anotasi, dan taint terkenal Kubernetes.

Tabel berikut mencantumkan label yang dicadangkan untuk penggunaan AKS dan tidak dapat digunakan untuk simpul apa pun. Dalam tabel, kolom Penggunaan simpul virtual menentukan apakah label didukung pada simpul virtual.

Di kolom Penggunaan simpul virtual:

  • N/A berarti properti tidak berlaku untuk simpul virtual karena akan memerlukan modifikasi host.
  • Sama berarti nilai yang diharapkan sama untuk kumpulan simpul virtual seperti untuk kumpulan simpul standar.
  • Virtual menggantikan nilai SKU VM, karena pod simpul virtual tidak mengekspos VM yang mendasar.
  • Versi node virtual mengacu pada versi saat ini dari rilis konektor Kubelet-ACI virtual.
  • Nama subnet simpul virtual adalah subnet yang menyebarkan pod simpul virtual ke Azure Container Instances.
  • Jaringan virtual simpul virtual adalah jaringan virtual yang berisi subnet simpul virtual.
Label Nilai Contoh, opsi Penggunaan node virtual
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Sama
kubernetes.io/arch amd64 runtime.GOARCH T/A
kubernetes.io/os <OS Type> Linux atau Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Sama
topology.kubernetes.io/zone <Azure zone> 0 Sama
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Sama
kubernetes.azure.com/mode <mode> User atau System User
kubernetes.azure.com/role agent Agent Sama
kubernetes.azure.com/scalesetpriority <scale set priority> Spot atau Regular T/A
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Sama
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed T/A
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS T/A
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Versi node virtual
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Nama subnet node virtual
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Jaringan virtual node virtual
kubernetes.azure.com/ppg <nodepool ppg name> ppgName T/A
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name T/A
kubernetes.azure.com/accelerator <accelerator> Nvidia T/A
kubernetes.azure.com/fips_enabled <fips enabled> True T/A
kubernetes.azure.com/os-sku <os/sku> Lihat Membuat atau memperbarui OS SKU Linux SKU

Kumpulan simpul Windows

AKS mendukung pembuatan dan penggunaan kumpulan simpul kontainer Windows Server melalui plugin jaringan antarmuka jaringan kontainer (CNI) Azure. Untuk merencanakan rentang subnet dan pertimbangan jaringan yang diperlukan, lihat mengonfigurasi jaringan Azure CNI.

Perintah berikut az aks nodepool add menambahkan kumpulan simpul yang menjalankan kontainer Windows Server.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

Perintah sebelumnya menggunakan subnet default di jaringan virtual kluster AKS. Untuk informasi selengkapnya tentang cara membangun kluster AKS dengan kumpulan simpul Windows, lihat Membuat kontainer Windows Server di AKS.

Pertimbangan kumpulan simpul

Pertimbangan dan batasan berikut berlaku saat Anda membuat dan mengelola kumpulan simpul dan beberapa kumpulan simpul:

  • Kuota, pembatasan ukuran VM, dan ketersediaan wilayah berlaku untuk kumpulan simpul AKS.

  • Kumpulan sistem harus berisi setidaknya satu simpul. Anda dapat menghapus kumpulan simpul sistem jika Anda memiliki kumpulan simpul sistem lain untuk menggantikannya di kluster AKS. Kumpulan simpul pengguna dapat berisi nol atau lebih simpul.

  • Anda tidak dapat mengubah ukuran VM dari kumpulan node setelah membuatnya.

  • Untuk beberapa kumpulan simpul, kluster AKS harus menggunakan load balancer SKU Standar. Load balancer SKU dasar tidak mendukung beberapa kumpulan simpul.

  • Semua kumpulan simpul kluster harus berada di jaringan virtual yang sama, dan semua subnet yang ditetapkan ke kumpulan simpul apa pun harus berada di jaringan virtual yang sama.

  • Jika Anda membuat beberapa kumpulan simpul pada waktu pembuatan kluster, versi Kubernetes untuk semua kumpulan simpul harus cocok dengan versi sarana kontrol. Anda dapat memperbarui versi setelah kluster disediakan dengan menggunakan operasi per kumpulan simpul.

Penskalakan kumpulan simpul

Saat beban kerja aplikasi Berubah, Anda mungkin perlu mengubah jumlah simpul dalam kumpulan simpul. Anda dapat menskalakan jumlah simpul ke atas atau ke bawah secara manual dengan menggunakan perintah az aks nodepool scale . Contoh berikut menskalakan jumlah simpul menjadi mynodepool lima:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Menskalakan kumpulan simpul secara otomatis dengan menggunakan autoscaler kluster

AKS mendukung penskalakan kumpulan simpul secara otomatis dengan autoscaler kluster. Anda mengaktifkan fitur ini pada setiap kumpulan simpul, dan menentukan jumlah node minimum dan maksimum.

Perintah berikut az aks nodepool add menambahkan kumpulan simpul baru yang dipanggil mynodepool ke kluster yang sudah ada. Parameter --enable-cluster-autoscaler memungkinkan autoscaler kluster pada kumpulan simpul baru, dan --min-count parameter dan --max-count menentukan jumlah minimum dan maksimum simpul dalam kumpulan.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

Perintah az aks nodepool update berikut memperbarui jumlah minimum simpul dari satu menjadi tiga untuk kumpulan simpulmynewnodepool.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Anda dapat menonaktifkan autoscaler kluster dengan az aks nodepool update dengan meneruskan --disable-cluster-autoscaler parameter .

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Untuk mengaktifkan kembali autoscaler kluster pada kluster yang ada, gunakan az aks nodepool update, yang menentukan --enable-cluster-autoscalerparameter , --min-count, dan --max-count .

Untuk informasi selengkapnya tentang cara menggunakan autoscaler kluster untuk kumpulan simpul individual, lihat Menskalakan kluster secara otomatis untuk memenuhi permintaan aplikasi di Azure Kubernetes Service (AKS).

Pembaruan dan peningkatan

Azure secara berkala memperbarui platform hosting VM-nya untuk meningkatkan keandalan, performa, dan keamanan. Pembaruan ini berkisar dari patching komponen perangkat lunak di lingkungan hosting hingga meningkatkan komponen jaringan atau menonaktifkan perangkat keras. Untuk informasi selengkapnya tentang cara Azure memperbarui VM, lihat Pemeliharaan untuk komputer virtual di Azure.

Pembaruan infrastruktur hosting VM biasanya tidak memengaruhi VM yang dihosting, seperti simpul agen dari kluster AKS yang ada. Untuk pembaruan yang memengaruhi VM yang dihosting, Azure meminimalkan kasus yang memerlukan boot ulang dengan menjeda VM saat memperbarui host, atau memigrasikan VM secara langsung ke host yang sudah diperbarui.

Jika pembaruan memerlukan boot ulang, Azure menyediakan pemberitahuan dan jendela waktu sehingga Anda dapat memulai pembaruan saat berfungsi untuk Anda. Jendela pemeliharaan mandiri untuk komputer host biasanya 35 hari, kecuali pembaruan mendesak.

Anda dapat menggunakan Pemeliharaan Terencana untuk memperbarui VM, dan mengelola pemberitahuan pemeliharaan terencana dengan Azure CLI, PowerShell, atau portal Azure. Pemeliharaan Terencana mendeteksi apakah Anda menggunakan Peningkatan Otomatis Kluster, dan menjadwalkan peningkatan selama jendela pemeliharaan Anda secara otomatis. Untuk informasi selengkapnya tentang Pemeliharaan Terencana, lihat perintah az aks maintenanceconfiguration dan Gunakan Pemeliharaan Terencana untuk menjadwalkan jendela pemeliharaan untuk kluster Azure Kubernetes Service (AKS).

Peningkatan Kubernetes

Bagian dari siklus hidup kluster AKS secara berkala meningkatkan ke versi Kubernetes terbaru. Penting untuk menerapkan peningkatan untuk mendapatkan rilis dan fitur keamanan terbaru. Untuk meningkatkan versi Kubernetes dari VM kumpulan simpul yang ada, Anda harus menghubungkan dan menguras simpul dan menggantinya dengan simpul baru yang didasarkan pada citra disk Kubernetes yang diperbarui.

Secara default, Azure Kubernetes Service mengonfigurasi peningkatan ke lonjakan dengan satu node tambahan. Nilai default untuk max-surge pengaturan meminimalkan gangguan beban kerja dengan membuat simpul tambahan untuk mengganti node versi lama sebelum menguras atau menguras aplikasi yang ada. Anda dapat menyesuaikan max-surge nilai per kumpulan simpul untuk memungkinkan tradeoff antara kecepatan peningkatan dan gangguan peningkatan. max-surge Meningkatkan nilai menyelesaikan proses peningkatan lebih cepat, tetapi nilai besar untuk max-surge dapat menyebabkan gangguan selama proses peningkatan.

Misalnya, max-surge nilai 100% memberikan proses peningkatan tercepat dengan menggandakan jumlah simpul, tetapi juga menyebabkan semua simpul di kumpulan simpul dikosongkan secara bersamaan. Anda mungkin ingin menggunakan nilai tinggi ini untuk pengujian, tetapi untuk kumpulan simpul produksi, max-surge pengaturan 33% lebih baik.

AKS menerima nilai bilangan bulat dan persentase untuk max-surge. Bilangan bulat seperti 5 menunjukkan lima simpul tambahan untuk melonjak. Nilai persen untuk max-surge bisa minimal 1% dan maksimum 100%, dibulatkan ke atas ke jumlah simpul terdekat. Nilai 50% menunjukkan nilai lonjakan setengah dari jumlah simpul saat ini dalam kumpulan.

Selama peningkatan, max-surge nilainya bisa minimum 1 dan nilai maksimum yang sama dengan jumlah simpul dalam kumpulan simpul. Anda dapat mengatur nilai yang lebih besar, tetapi jumlah maksimum simpul yang digunakan max-surge tidak akan lebih tinggi dari jumlah simpul dalam kumpulan.

Penting

Untuk operasi peningkatan, lonjakan node membutuhkan kuota langganan yang cukup untuk jumlah yang diminta max-surge . Misalnya, kluster yang memiliki lima kumpulan simpul, masing-masing dengan empat simpul, memiliki total 20 simpul. Jika setiap kumpulan simpul memiliki max-surge nilai 50%, Anda memerlukan komputasi tambahan dan kuota IP 10 simpul, atau dua simpul kali lima kumpulan, untuk menyelesaikan peningkatan.

Jika Anda menggunakan Azure Container Networking Interface (CNI), pastikan juga Anda memiliki CUKUP IP di subnet untuk memenuhi persyaratan CNI untuk AKS.

Meningkatkan kumpulan simpul

Untuk melihat peningkatan yang tersedia, gunakan az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Untuk melihat status kumpulan simpul, gunakan az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

Perintah berikut menggunakan peningkatan az aks nodepool untuk meningkatkan kumpulan simpul tunggal.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Untuk informasi selengkapnya tentang cara meningkatkan versi Kubernetes untuk sarana kontrol kluster dan kumpulan simpul, lihat:

Meningkatkan pertimbangan

Perhatikan praktik dan pertimbangan terbaik ini untuk meningkatkan versi Kubernetes dalam kluster AKS.

  • Yang terbaik adalah meningkatkan semua kumpulan simpul dalam kluster AKS ke versi Kubernetes yang sama. Perilaku az aks upgrade default meningkatkan semua kumpulan simpul dan sarana kontrol.

  • Tingkatkan secara manual, atau atur saluran peningkatan otomatis di kluster Anda. Jika Anda menggunakan Pemeliharaan Terencana untuk menambal VM, peningkatan otomatis juga dimulai selama jendela pemeliharaan yang Ditentukan. Untuk informasi selengkapnya, lihat Meningkatkan kluster Azure Kubernetes Service (AKS).

  • az aks upgrade Perintah dengan --control-plane-only bendera hanya meningkatkan sarana kontrol kluster dan tidak mengubah salah satu kumpulan simpul terkait dalam kluster. Untuk meningkatkan kumpulan simpul individual, tentukan kumpulan simpul target dan versi Kubernetes dalam az aks nodepool upgrade perintah ,

  • Peningkatan kluster AKS memicu cordon dan pengosongan simpul Anda. Jika Anda memiliki kuota komputasi rendah yang tersedia, peningkatan dapat gagal. Untuk informasi selengkapnya tentang meningkatkan kuota Anda, lihat Meningkatkan kuota vCPU regional.

  • Konfigurasikan max-surge parameter berdasarkan kebutuhan Anda, menggunakan bilangan bulat atau nilai persentase. Untuk kumpulan simpul produksi, gunakan max-surge pengaturan 33%. Untuk informasi selengkapnya, lihat Menyesuaikan peningkatan lonjakan simpul.

  • Saat Anda meningkatkan kluster AKS yang menggunakan jaringan CNI, pastikan subnet memiliki alamat IP privat yang cukup tersedia untuk simpul tambahan yang max-surge dibuat pengaturan. Untuk informasi selengkapnya, lihat Mengonfigurasi jaringan Azure CNI di Azure Kubernetes Service (AKS).

  • Jika kumpulan simpul kluster Anda mencakup beberapa Zona Ketersediaan dalam suatu wilayah, proses peningkatan dapat menyebabkan konfigurasi zona yang tidak seimbang untuk sementara waktu. Untuk informasi selengkapnya, lihat Pertimbangan khusus untuk kumpulan simpul yang mencakup beberapa Zona Ketersediaan.

Jaringan virtual simpul

Saat Anda membuat kluster baru atau menambahkan kumpulan simpul baru ke kluster yang ada, Anda menentukan ID sumber daya subnet dalam jaringan virtual kluster tempat Anda menyebarkan simpul agen. Beban kerja mungkin memerlukan pemisahan node kluster menjadi kumpulan simpul terpisah untuk isolasi logis. Anda dapat mencapai isolasi ini dengan subnet terpisah, masing-masing didedikasikan untuk kumpulan simpul terpisah. Kumpulan simpul VM masing-masing mendapatkan alamat IP privat dari subnet terkait.

AKS mendukung dua plugin jaringan:

  • Kubenet adalah plugin jaringan dasar dan sederhana untuk Linux. Dengan kubenet, simpul mendapatkan alamat IP privat dari subnet jaringan virtual Azure. Pod mendapatkan alamat IP dari ruang alamat yang berbeda secara logis. Network address translation (NAT) memungkinkan pod menjangkau sumber daya di jaringan virtual Azure dengan menerjemahkan alamat IP lalu lintas sumber ke alamat IP utama node. Pendekatan ini mengurangi jumlah alamat IP yang perlu Anda cadangkan di ruang jaringan untuk Pod.

  • Azure Container Networking Interface (CNI) memberi setiap pod alamat IP untuk memanggil dan mengakses secara langsung. Alamat IP ini harus unik di seluruh ruang jaringan Anda. Setiap simpul memiliki parameter konfigurasi untuk jumlah maksimum pod yang didukungnya. Jumlah alamat IP yang setara per simpul kemudian dicadangkan untuk simpul tersebut. Pendekatan ini memerlukan perencanaan terlebih dahulu, dan dapat menyebabkan kelelahan alamat IP atau kebutuhan untuk membangun kembali kluster dalam subnet yang lebih besar saat permintaan aplikasi tumbuh.

    Saat Anda membuat kluster baru atau menambahkan kumpulan simpul baru ke kluster yang menggunakan Azure CNI, Anda dapat menentukan ID sumber daya dari dua subnet terpisah, satu untuk simpul dan satu untuk pod. Untuk informasi selengkapnya, lihat Alokasi IP dinamis dan dukungan subnet yang ditingkatkan.

Alokasi IP dinamis

Pod yang menggunakan Azure CNI mendapatkan alamat IP privat dari subnet kumpulan simpul hosting. Alokasi IP dinamis Azure CNI dapat mengalokasikan alamat IP privat ke pod dari subnet yang terpisah dari subnet hosting kumpulan simpul. Fitur ini memberikan keuntungan berikut:

  • Subnet pod secara dinamis mengalokasikan IP ke pod. Alokasi dinamis memberikan pemanfaatan IP yang lebih baik dibandingkan dengan solusi CNI tradisional, yang melakukan alokasi IP statis untuk setiap simpul.

  • Anda dapat menskalakan dan berbagi subnet simpul dan pod secara independen. Anda dapat berbagi satu subnet pod di beberapa kumpulan simpul atau kluster yang disebarkan di jaringan virtual yang sama. Anda juga dapat mengonfigurasi subnet pod terpisah untuk kumpulan simpul.

  • Karena pod memiliki IP privat jaringan virtual, pod tersebut memiliki konektivitas langsung ke pod dan sumber daya kluster lain di jaringan virtual. Kemampuan ini mendukung performa yang lebih baik untuk kluster yang sangat besar.

  • Jika pod memiliki subnet terpisah, Anda dapat mengonfigurasi kebijakan jaringan virtual untuk pod yang berbeda dari kebijakan simpul. Kebijakan terpisah memungkinkan banyak skenario yang berguna, seperti mengizinkan konektivitas internet hanya untuk pod dan bukan untuk simpul, memperbaiki IP sumber untuk pod di kumpulan simpul dengan menggunakan NAT Gateway, dan menggunakan Kelompok Keamanan Jaringan (NSG) untuk memfilter lalu lintas antar kumpulan simpul.

  • Kebijakan Jaringan dan kebijakan jaringan Calico Kubernetes berfungsi dengan alokasi IP dinamis.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya