Mengelola simpul Kubernetes dan kumpulan simpul

Arsitektur Kubernetes terdiri dari dua lapisan: sarana kontrol dan setidaknya satu simpul dalam kumpulan simpul. Artikel ini menjelaskan dan membandingkan bagaimana Amazon Elastic Kubernetes Service (EKS) dan Azure Kubernetes Service (AKS) mengelola simpul agen dan simpul pekerja.

Nota

Artikel ini adalah bagian dari serangkaian artikel yang membantu para profesional yang terbiasa dengan Amazon EKS memahami Azure Kubernetes Service (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 dibagi menjadi dua bagian: Dikelola Azure dan Dikelola pelanggan. Bagian yang dikelola Azure mencakup control plane, yang memiliki komponen: API server, scheduler, etcd, dan controller manager. Server API terhubung ke tiga komponen lainnya. Bagian yang dikelola Pelanggan mencakup simpul yang memiliki komponen: kubelet, container runtime, kube-proxy, dan container. Penjadwal di sarana kontrol terhubung ke kubelet. Kubelet terhubung ke container runtime, yang terhubung ke kontainer.

Grup node 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 pengakhiran node secara otomatis memblokir dan mengosongkan node untuk membantu memastikan bahwa aplikasi tetap tersedia.

Setiap simpul terkelola disediakan sebagai bagian dari grup penskalaan otomatis Amazon EC2 yang dioperasikan dan dikontrol Amazon EKS. Pengatur skala otomatis kluster Kubernetes secara otomatis menyesuaikan jumlah node pekerja dalam kluster ketika pod gagal atau dipindahkan ke node lain. Anda dapat mengonfigurasi setiap grup simpul untuk berjalan di beberapa zona ketersediaan dalam suatu wilayah.

Untuk informasi selengkapnya, 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, lihat Menyederhanakan manajemen komputasi.

Karpenter

Karpenter adalah proyek sumber terbuka yang membantu meningkatkan manajemen siklus hidup simpul dalam kluster Kubernetes. Ini mengotomatiskan penyediaan dan penghapusan node berdasarkan kebutuhan penjadwalan spesifik dari pod, sehingga meningkatkan skala dan mengoptimalkan biaya. Gunakan Karpenter untuk fungsi utama berikut:

• Memantau pod yang tidak dapat dijadwalkan oleh penjadwal Kubernetes karena kendala sumber daya.

• Evaluasi persyaratan penjadwalan, seperti permintaan sumber daya, pemilih node, afinitas, dan toleransi, dari pod yang tidak dapat dijadwalkan.

• Konfigurasikan node baru yang memenuhi persyaratan pod yang tidak dapat dijadwalkan.

• Hapus simpul saat Anda tidak lagi membutuhkannya.

Anda dapat menggunakan Karpenter untuk menentukan kumpulan simpul yang memiliki pembatasan dalam penyediaan simpul, seperti taint, label, persyaratan (jenis instans dan zona), serta batasan pada total sumber daya yang disediakan. Saat Anda menyebarkan beban kerja, tentukan berbagai batasan penjadwalan dalam spesifikasi pod. Misalnya, Anda dapat menentukan permintaan atau batasan sumber daya, pemilih simpul, afinitas node atau pod, tolerasi, dan batasan penyebaran topologi. Karpenter kemudian mengonfigurasi simpul yang berukuran tepat berdasarkan spesifikasi ini.

Sebelum peluncuran Karpenter, pengguna Amazon EKS terutama mengandalkan grup penskalaan otomatis Amazon EC2 dan autoscaler kluster Kubernetes untuk menyesuaikan kapasitas komputasi kluster mereka secara dinamis. Anda tidak perlu membuat puluhan grup simpul untuk mencapai fleksibilitas dan keragaman yang disediakan Karpenter. Tidak seperti autoscaler kluster Kubernetes, Karpenter kurang bergantung pada versi Kubernetes dan tidak memerlukan transisi antara API AWS dan Kubernetes.

Karpenter mengonsolidasikan tanggung jawab orkestrasi instans dalam satu sistem, yang lebih sederhana, lebih stabil, dan lebih sadar kluster. Karpenter membantu mengatasi tantangan kluster autoscaler dengan menyediakan cara yang lebih sederhana untuk:

• Konfigurasikan simpul berdasarkan persyaratan beban kerja.

• Buat konfigurasi simpul yang beragam berdasarkan jenis instans dengan menggunakan opsi kumpulan simpul fleksibel. Alih-alih mengelola beberapa grup simpul kustom tertentu, gunakan Karpenter untuk mengelola beragam kapasitas beban kerja dengan menggunakan satu kumpulan simpul fleksibel.

• Untuk mencapai penjadwalan pod yang lebih baik dalam skala besar, luncurkan node dan jadwalkan pod dengan cepat.

Dibandingkan dengan grup penskalaan otomatis dan grup simpul terkelola, Karpenter mengintegrasikan manajemen penskalaan lebih dekat dengan API asli Kubernetes. Grup penskalaan otomatis dan grup simpul terkelola adalah abstraksi asli AWS yang memicu penskalaan berdasarkan metrik tingkat AWS, seperti beban CPU EC2. Meskipun autoscaler kluster menghubungkan abstraksi Kubernetes dengan abstraksi AWS, fitur ini mengorbankan beberapa fleksibilitas, seperti kemampuan penjadwalan untuk zona ketersediaan tertentu.

Karpenter menyederhanakan manajemen simpul dengan menghilangkan komponen khusus AWS, yang memberikan fleksibilitas yang lebih besar langsung dalam Kubernetes. Gunakan Karpenter untuk kluster yang menjalankan beban kerja yang mengalami periode permintaan lonjakan tinggi atau memiliki persyaratan komputasi yang beragam. Gunakan grup simpul terkelola dan grup penskalaan otomatis untuk kluster yang menjalankan beban kerja yang lebih statis dan konsisten. Tergantung pada kebutuhan Anda, Anda dapat menggunakan kombinasi node yang dikelola secara dinamis dan statis.

Kontainer Kata

Kontainer Kata adalah proyek sumber terbuka yang menyediakan runtime kontainer yang sangat aman. Ini menggabungkan sifat kontainer yang ringan dengan manfaat keamanan komputer virtual (VM). Kontainer Kata meningkatkan isolasi dan keamanan beban kerja dengan meluncurkan setiap kontainer dengan sistem operasi tamu yang berbeda, tidak seperti kontainer tradisional yang memiliki Kernel Linux yang sama di antara beban kerja. Kontainer Kata menjalankan kontainer dalam VM yang mematuhi Open Container Initiative (OCI), yang menyediakan isolasi ketat antara kontainer pada komputer host yang sama. Kontainer Kata menyediakan fitur-fitur berikut:

• Isolasi beban kerja yang ditingkatkan: Setiap kontainer berjalan di VM ringannya sendiri untuk membantu memastikan isolasi di tingkat perangkat keras.

• Keamanan yang ditingkatkan: Penggunaan teknologi VM memberikan lapisan keamanan ekstra, yang mengurangi risiko breakout kontainer.

• Kompatibilitas dengan standar industri: Kontainer Kata terintegrasi dengan alat standar industri, seperti format kontainer OCI dan Antarmuka Runtime Kontainer Kubernetes.

• Dukungan untuk beberapa arsitektur dan hypervisor: Kontainer Kata mendukung arsitektur AMD64 dan ARM, dan Anda dapat menggunakannya dengan hypervisor seperti Cloud Hypervisor dan Firecracker.

• Penyebaran dan manajemen yang mudah: Kontainer Kata menyederhanakan orkestrasi beban kerja karena menggunakan sistem orkestrasi Kubernetes.

Untuk menyiapkan dan menjalankan Kata Containers di AWS, konfigurasikan kluster Amazon EKS untuk menggunakan Firecracker. Firecracker adalah teknologi virtualisasi sumber terbuka dari Amazon yang membantu Anda membuat dan mengelola layanan berbasis kontainer dan berbasis fungsi yang aman dan multipenyewa. Gunakan Firecracker untuk menyebarkan beban kerja di VM ringan, yang disebut microVM, yang memberikan keamanan yang ditingkatkan dan isolasi beban kerja dibandingkan dengan VM tradisional. MicroVM juga meningkatkan kecepatan dan efisiensi sumber daya kontainer. Ikuti langkah-langkah untuk menjalankan Kata Containers di AWS EKS.

Host Terdedikasi

Saat Anda menggunakan Amazon EKS untuk menyebarkan dan menjalankan kontainer, Anda dapat menjalankan kontainer di host khusus Amazon EC2. Namun, fitur ini hanya tersedia untuk grup simpul yang dikelola sendiri. Jadi Anda harus membuat templat peluncuran dan grup penskalakan otomatis secara manual. Kemudian daftarkan host khusus, luncurkan templat, dan grup penskalakan otomatis dengan kluster EKS. Untuk membuat sumber daya ini, gunakan metode yang sama dengan penskalakan otomatis EC2 umum.

Untuk informasi selengkapnya tentang cara menggunakan AWS EKS untuk menjalankan kontainer pada host khusus EC2, lihat sumber daya berikut:

• node Amazon EKS
• Pembatasan host khusus
• Mengalokasikan host khusus
• Membeli reservasi host khusus
• Penempatan otomatis

Simpul AKS dan kelompok simpul

Ketika Anda membuat kluster AKS secara otomatis, kluster ini 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, Anda mengelola dan membayar sepenuhnya node agen yang terkait dengan kluster AKS.

Untuk menjalankan aplikasi dan layanan pendukung, kluster AKS membutuhkan setidaknya satu simpul, yang merupakan Azure VM yang menjalankan komponen node Kube dan runtime kontainer. Setiap kluster AKS harus berisi setidaknya satu kumpulan simpul sistem yang memiliki setidaknya satu node.

AKS menggabungkan simpul konfigurasi yang sama ke dalam kumpulan simpul VM yang menjalankan beban kerja AKS. Gunakan node pool sistem untuk meng-host pod sistem penting seperti CoreDNS. Gunakan kumpulan node pengguna untuk menampung pod untuk beban kerja. Jika Anda hanya menginginkan satu kumpulan simpul di kluster AKS, misalnya di lingkungan pengembangan, Anda dapat menjadwalkan pod aplikasi pada kumpulan simpul sistem.

Azure VM berisi empat komponen: kubelet, runtime kontainer, kube-proxy, dan kontainer. Jaringan virtual Azure terhubung ke antarmuka jaringan virtual Azure, yang terhubung ke komponen kube-proxy. Kubelet terhubung ke runtime kontainer, serta runtime kontainer terhubung ke kontainer. Penyimpanan disk Azure dan Azure Files menunjuk ke kontainer.

Anda juga dapat membuat beberapa kumpulan simpul pengguna untuk memisahkan beban kerja yang berbeda pada simpul yang berbeda. Pendekatan ini membantu mencegah masalah tetangga yang bising dan mendukung aplikasi yang memiliki tuntutan komputasi atau penyimpanan yang berbeda.

Setiap simpul agen dalam sistem atau kumpulan simpul pengguna pada dasarnya adalah VM. Azure Virtual Machine Scale Sets mengonfigurasi VM, dan kluster AKS mengelolanya. Untuk informasi selengkapnya, lihat 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 dan komunikasi simpul internal dengan layanan platform, pilih seri VM yang mendukung Jaringan Terakselerasi.

Membuat kumpulan simpul

Saat Anda membuat kumpulan simpul baru, skala mesin virtual terkait dibuat di grup sumber daya simpul. Grup sumber daya Azure ini 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. Anda harus menggunakan grup sumber daya ini hanya untuk sumber daya yang berbagi siklus hidup kluster.

Untuk informasi selengkapnya, lihat Membuat kumpulan simpul untuk kluster di AKS.

Menambahkan kumpulan simpul

Untuk menambahkan kumpulan simpul ke kluster AKS baru atau yang sudah ada, gunakan portal Microsoft Azure, Azure CLI, atau AKS REST API. Anda juga dapat menggunakan alat infrastruktur sebagai kode (IaC), seperti Bicep, templat Azure Resource Manager, atau Terraform.

Contoh kode berikut menggunakan perintah az aks nodepool add Azure CLI untuk menambahkan kumpulan simpul bernama mynodepool yang memiliki tiga simpul. Ini menambahkan kumpulan simpul ke kluster AKS yang sudah ada bernama myAKSCluster di grup sumber daya myResourceGroup.

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 node spot adalah kumpulan node yang didukung oleh set skala mesin virtual spot. Gunakan VM spot untuk simpul di kluster AKS Anda untuk memanfaatkan kapasitas Azure yang tidak digunakan dengan biaya yang berkurang. Jumlah kapasitas yang tidak digunakan yang tersedia bervariasi berdasarkan faktor-faktor, seperti ukuran simpul, wilayah, dan waktu hari.

Saat Anda mengaktifkan kumpulan simpul spot, Azure mengalokasikan simpul spot jika kapasitas tersedia. Tetapi node spot tidak memiliki perjanjian tingkat layanan (SLA). Set skala titik yang mendukung kumpulan node titik disebarkan dalam satu domain kesalahan dan tidak memberikan jaminan availabilitas tinggi. Saat Azure membutuhkan kapasitas, infrastruktur Azure mengusir node spot. Anda menerima pemberitahuan hingga 30 detik sebelum pengeluaran. Anda tidak dapat menggunakan kumpulan simpul spot sebagai kumpulan simpul default kluster. Gunakan kumpulan simpul spot hanya sebagai kumpulan sekunder.

Gunakan simpul spot untuk beban kerja yang dapat menangani gangguan, penghentian dini, atau pengusiran. Misalnya, gunakan kumpulan simpul spot untuk menjadwalkan pekerjaan pemrosesan batch, lingkungan pengembangan dan pengujian, dan beban kerja komputasi besar. Untuk informasi selengkapnya, lihat Batasan instans spot.

Perintah berikut az aks nodepool add menambahkan kumpulan simpul spot ke kluster yang sudah ada yang mengaktifkan penskalan otomatis.

  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, lihat Menambahkan kumpulan simpul spot ke kluster AKS.

Disk OS sementara

Secara default, Azure secara otomatis mereplikasi disk OS VM ke Azure Storage. Pendekatan ini mencegah kehilangan data jika VM perlu dipindahkan ke host lain. Tetapi kontainer tidak dirancang untuk mempertahankan status lokal, sehingga menyimpan disk OS di Azure Storage memberikan manfaat terbatas untuk AKS. Pendekatan ini dapat menyebabkan provisi simpul yang lebih lambat dan peningkatan latensi baca dan tulis.

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

Penting

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

Untuk menggunakan OS ephemeral, disk OS harus pas di cache VM. Dokumentasi Azure VM menunjukkan ukuran cache VM dalam tanda kurung di samping throughput input/output (I/O) 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 secara bawaan menggunakan disk terkelola jika Anda tidak menetapkan lain. 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 ukuran cache 200 GB. Jika Anda 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, lihat Disk OS Ephemeral.

Kumpulan simpul Azure Virtual Machines di AKS

Setiap grup simpul terkelola di EKS didukung oleh grup auto scaling Amazon EC2 yang dikelola Amazon EKS. Integrasi ini memungkinkan EKS untuk mengonfigurasi dan menskalakan instans EC2 secara otomatis dalam grup simpul.

Anda dapat mengonfigurasi grup penskalaan otomatis untuk mendukung beberapa jenis instans EC2, tetapi Anda tidak dapat menentukan berapa banyak simpul yang akan dibuat atau diskalakan untuk setiap jenis instans. Sebagai gantinya, EKS mengelola penskalaan grup simpul berdasarkan konfigurasi dan kebijakan yang Anda inginkan. Pendekatan ini menyederhanakan dan mengotomatiskan proses manajemen untuk grup simpul sehingga Anda dapat memilih jenis instans EC2 yang sesuai dengan persyaratan beban kerja Anda. Anda juga dapat meluncurkan simpul Amazon Linux yang dikelola sendiri dengan menggunakan eksctl alat baris perintah atau AWS Management Console.

Untuk kumpulan node Azure Virtual Machines, AKS mengonfigurasi dan memulai setiap node agen. Untuk kumpulan simpul Azure Virtual Machine Scale Sets, AKS mengelola model Virtual Machine Scale Sets dan menggunakannya untuk mencapai konsistensi di semua simpul agen di kumpulan simpul. Anda dapat menggunakan kumpulan simpul Virtual Machines untuk mengatur kluster Anda dengan VM yang paling sesuai dengan beban kerja individual Anda. Anda juga dapat menentukan berapa banyak simpul yang akan dibuat atau diskalakan untuk setiap ukuran VM.

Kumpulan simpul terdiri dari sekumpulan VM yang memiliki ukuran berbeda. Setiap VM mendukung jenis beban kerja yang berbeda. Ukuran VM ini, disebut sebagai SKU, dikategorikan ke dalam berbagai keluarga yang dioptimalkan untuk tujuan tertentu. Untuk informasi selengkapnya, lihat Ukuran VM di Azure.

Untuk mengaktifkan penskalaan beberapa ukuran VM, jenis kumpulan simpul Komputer Virtual menggunakan ScaleProfile. Profil ini mengonfigurasi bagaimana kumpulan simpul diskalakan dengan menentukan ukuran dan jumlah VM yang diinginkan. adalah ManualScaleProfile profil skala yang menentukan ukuran dan jumlah VM yang diinginkan. Hanya satu ukuran VM yang diperbolehkan dalam ManualScaleProfile. Anda perlu membuat ManualScaleProfile yang terpisah untuk setiap ukuran VM di node pool Anda.

Ketika Anda membuat node pool Virtual Machines baru, Anda memerlukan setidaknya satu ManualScaleProfile di ScaleProfile. Anda dapat membuat beberapa profil skala manual untuk satu kumpulan simpul Komputer Virtual.

Keuntungan dari kumpulan simpul Komputer Virtual meliputi:

• Keleluasaan: Anda dapat memperbarui spesifikasi node agar sesuai dengan beban kerja dan kebutuhan Anda.

• Kontrol yang disempurnakan: Kontrol tingkat node tunggal membantu menentukan dan menggabungkan simpul dari spesifikasi yang berbeda untuk meningkatkan konsistensi.

• Efisiensi: Anda dapat mengurangi jejak node kluster Anda guna menyederhanakan persyaratan operasional.

Kumpulan simpul Komputer Virtual memberikan pengalaman yang lebih baik untuk beban kerja dinamis dan persyaratan ketersediaan tinggi. Anda dapat menggunakannya untuk menyiapkan beberapa VM dari keluarga yang sama dalam satu kumpulan simpul, dan beban kerja Anda secara otomatis dijadwalkan pada sumber daya yang tersedia yang Anda konfigurasi.

Tabel berikut membandingkan kumpulan simpul Virtual Machines dengan kumpulan simpul Virtual Machine Scale Sets standar.

Jenis kumpulan simpul	Kemampuan
Kumpulan simpul Komputer Virtual	Anda dapat menambahkan, menghapus, atau memperbarui simpul di kumpulan simpul. Jenis VM dapat berupa VM dengan jenis keluarga yang sama, seperti seri D atau seri A.
Kumpulan simpul Virtual Machine Scale Sets	Anda dapat menambahkan atau menghapus simpul dengan ukuran yang sama dan mengetikkan kumpulan simpul. Jika Anda menambahkan ukuran VM baru ke kluster, Anda perlu membuat kumpulan simpul baru.

Kumpulan simpul Komputer Virtual memiliki batasan berikut:

• Kluster autoscaler tidak didukung.
• InfiniBand tidak tersedia.
• Kluster simpul Windows tidak didukung.
• Fitur ini tidak tersedia di portal Microsoft Azure. Gunakan Azure CLI atau REST API untuk melakukan operasi buat, baca, perbarui, dan hapus (CRUD) atau kelola kumpulan.
• Snapshot kumpulan node tidak didukung.
• Semua ukuran VM dalam kumpulan simpul harus berasal dari keluarga VM yang sama. Misalnya, Anda tidak dapat menggabungkan jenis VM seri N dengan jenis VM seri D di kumpulan simpul yang sama.
• Kumpulan simpul Komputer Virtual memungkinkan hingga lima ukuran VM yang berbeda per kumpulan simpul.

Node virtual

Anda dapat menggunakan simpul virtual untuk menskalakan beban kerja aplikasi dengan cepat dalam kluster AKS. Node virtual menyediakan penyediaan pod yang cepat, dan Anda hanya membayar per detik untuk waktu operasi. Anda tidak perlu menunggu cluster autoscaler menyebarkan node baru untuk menjalankan replika pod lebih banyak. Hanya pod dan simpul Linux yang mendukung simpul virtual. Add-on node virtual untuk AKS didasarkan pada proyek open-source Virtual Kubelet.

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

Taint, label, dan tag

Saat membuat kumpulan simpul, Anda dapat menambahkan taint dan label Kubernetes, dan tag Azure. Setiap taint, label, atau tag berlaku untuk semua simpul dalam kumpulan simpul tersebut.

Untuk membuat kumpulan simpul yang memiliki taint, Anda dapat menggunakan az aks nodepool add perintah dengan --node-taints parameter . Untuk memberi label simpul dalam kumpulan simpul, gunakan --labels parameter dan tentukan 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 khusus untuk penggunaan AKS dan tidak dapat digunakan untuk node:

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

Untuk prefiks yang dicadangkan lainnya, lihat label, anotasi, dan taint terkenal Kubernetes.

Tabel berikut mencantumkan label yang dicadangkan untuk penggunaan AKS dan tidak dapat digunakan untuk node. Dalam tabel, kolom Penggunaan simpul virtual menentukan apakah simpul virtual mendukung label.

Di kolom Penggunaan simpul virtual:

• N/A berarti bahwa properti tidak berlaku untuk simpul virtual karena memerlukan modifikasi host.
• Sama berarti bahwa nilai yang diharapkan sama untuk kumpulan simpul virtual dan kumpulan simpul standar.
• Virtual menggantikan nilai SKU dari VM, karena pod node virtual tidak mengekspos VM yang mendasari.
• 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 dalam Container Instances.
• Jaringan virtual simpul virtual adalah jaringan virtual yang berisi subnet simpul virtual.

Etiket	Nilai	Contoh atau opsi	Penggunaan node virtual
kubernetes.azure.com/agentpool	<agent pool name>	nodepool1	Sama
kubernetes.io/arch	amd64	runtime.GOARCH	Tidak tersedia
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	Tidak tersedia
kubernetes.io/hostname	<hostname>	aks-nodepool-00000000-vmss000000	Sama
kubernetes.azure.com/storageprofile	<OS disk storage profile>	Managed	Tidak tersedia
kubernetes.azure.com/storagetier	<OS disk storage tier>	Premium_LRS	Tidak tersedia
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 simpul virtual
kubernetes.azure.com/ppg	<nodepool ppg name>	ppgName	Tidak tersedia
kubernetes.azure.com/encrypted-set	<nodepool encrypted-set name>	encrypted-set-name	Tidak tersedia
kubernetes.azure.com/accelerator	<accelerator>	nvidia	Tidak tersedia
kubernetes.azure.com/fips_enabled	<fips enabled>	True	Tidak tersedia
kubernetes.azure.com/os-sku	<os/sku>	Lihat Membuat atau memperbarui OS SKU	Linux SKU

Kumpulan simpul Windows

Anda dapat menggunakan AKS untuk membuat dan menggunakan kumpulan simpul kontainer Windows Server melalui plugin jaringan Antarmuka Jaringan Kontainer Azure . Untuk merencanakan rentang subnet dan pertimbangan jaringan yang diperlukan, lihat Mengonfigurasi Antarmuka Jaringan Kontainer Azure.

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 yang memiliki kumpulan simpul Windows, lihat Membuat kontainer Windows Server di AKS.

Pertimbangan kumpulan simpul

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

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

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

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

• Untuk beberapa kumpulan node, kluster AKS harus menggunakan penyeimbang beban SKU Standar. SKU load balancer dasar tidak mendukung kumpulan simpul yang banyak.

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

• Jika Anda membuat beberapa kumpulan simpul saat membuat kluster, versi Kubernetes untuk semua kumpulan simpul harus cocok dengan versi sarana kontrol. Untuk memperbarui versi setelah Anda mengonfigurasi kluster, gunakan operasi per kumpulan simpul.

Menskalakan kumpulan simpul

Saat beban kerja aplikasi Berubah, Anda mungkin perlu mengubah jumlah simpul dalam kumpulan simpul. Untuk menskalakan jumlah simpul secara manual ke atas atau ke bawah, gunakan 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

AKS mendukung penskalakan kumpulan simpul secara otomatis dengan menggunakan autoscaler kluster. Aktifkan fitur ini pada setiap kumpulan simpul, dan tentukan 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 mengaktifkan kluster autoscaler pada node pool baru. Parameter --min-count 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

Untuk menonaktifkan kluster autoscaler, gunakan perintah az aks nodepool update dengan parameter --disable-cluster-autoscaler.

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

Untuk mengaktifkan kembali pengatur skala otomatis pada kluster yang sudah ada, gunakan perintah az aks nodepool update dan tentukan parameter --enable-cluster-autoscaler, --min-count, dan --max-count.

Untuk informasi selengkapnya tentang cara menggunakan autoscaler kluster untuk kumpulan simpul individual, lihat Menggunakan autoscaler kluster di AKS.

Pod Sandboxing

Untuk menyiapkan dan menjalankan Kontainer Kata dengan mudah di AKS sebagai solusi yang dikelola sepenuhnya, gunakan Pod Sandboxing. Pod Sandboxing adalah fitur AKS yang membuat batas isolasi antara aplikasi kontainer dan kernel bersama dan sumber daya komputasi host kontainer, seperti CPU, memori, dan jaringan.

Pod Sandboxing melengkapi langkah-langkah keamanan atau kontrol perlindungan data lainnya untuk membantu beban kerja penyewa mengamankan informasi sensitif dan memenuhi persyaratan kepatuhan peraturan, industri, atau tata kelola. Persyaratan ini termasuk Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), International Organization for Standardization (ISO) 27001, dan Health Insurance Portability and Accountability Act (HIPAA).

Sebarkan aplikasi pada kluster atau kumpulan simpul terpisah untuk membantu mengisolasi beban kerja penyewa dari tim atau pelanggan yang berbeda. Anda dapat menggunakan beberapa kluster dan kumpulan simpul jika organisasi atau solusi perangkat lunak sebagai layanan (SaaS) Anda memerlukannya. Tetapi beberapa skenario mendapat manfaat dari satu kluster yang telah berbagi kumpulan simpul VM. Misalnya, Anda dapat menggunakan satu kluster untuk menjalankan pod yang tidak tepercaya dan tepercaya pada simpul yang sama atau mengalokasikan DaemonSets dan kontainer istimewa pada simpul yang sama untuk komunikasi lokal dan pengelompokan fungsional yang lebih cepat.

Pod Sandboxing dapat membantu Anda mengisolasi aplikasi penyewa pada node kluster yang sama tanpa perlu menjalankan beban kerja ini di kluster atau kumpulan simpul terpisah. Metode lain mungkin mengharuskan Anda mengkompilasi ulang kode Anda, atau mungkin membuat masalah kompatibilitas lainnya. Pod Sandboxing di AKS dapat menjalankan kontainer yang tidak dimodifikasi di dalam batas VM keamanan yang ditingkatkan.

Pod Sandboxing didasarkan pada Kata Containers yang beroperasi pada host kontainer Azure Linux untuk stack AKS untuk menyediakan isolasi yang ditegakkan oleh perangkat keras. Kontainer Kata di AKS dibangun di atas hypervisor Azure yang diperkuat keamanan. Ini mencapai isolasi untuk setiap pod melalui VM Kata yang tertumpuk dan ringan yang menggunakan sumber daya dari simpul VM induk. Dalam model ini, setiap Pod Kata mendapatkan kernelnya sendiri dalam VM tamu Kata berlapis. Gunakan model ini untuk menempatkan beberapa kontainer Kata dalam satu VM tamu sambil terus menjalankan kontainer di VM induk. Model ini menyediakan batas isolasi yang kuat dalam kluster AKS bersama.

Untuk informasi selengkapnya, lihat Dukungan untuk kontainer terisolasi Kata VM di AKS untuk Pod Sandboxing.

Azure Dedicated Host (Layanan Tuan Rumah Khusus Azure)

Azure Dedicated Host adalah layanan yang menyediakan server fisik yang didedikasikan untuk satu langganan Azure untuk membantu memastikan isolasi perangkat keras di tingkat server fisik. Anda dapat menyediakan host khusus ini dalam wilayah, zona ketersediaan, dan domain kesalahan. Anda dapat menempatkan VM langsung ke host yang disediakan.

Gunakan Dedicated Host dengan AKS untuk memberikan manfaat berikut:

• Isolasi perangkat keras memastikan bahwa tidak ada VM lain yang ditempatkan pada host khusus, yang menyediakan lapisan isolasi tambahan untuk beban kerja penyewa. Host khusus disebarkan di pusat data yang sama dan berbagi jaringan yang sama dan infrastruktur penyimpanan yang mendasar dengan host lain yang tidak terisolasi.

• Dedicated Host memberikan Anda kendali atas peristiwa pemeliharaan yang diprakarsai oleh platform Azure. Anda dapat memilih jendela pemeliharaan untuk mengurangi dampak pada layanan dan membantu memastikan ketersediaan dan privasi beban kerja penyewa.

Dedicated Host dapat membantu penyedia SaaS memastikan bahwa aplikasi penyewa memenuhi persyaratan kepatuhan peraturan, industri, dan tata kelola untuk mengamankan informasi sensitif. Untuk informasi selengkapnya, lihat Menambahkan Host Khusus ke kluster AKS.

Karpenter

Karpenter adalah proyek manajemen siklus hidup simpul sumber terbuka yang dibangun untuk Kubernetes. Tambahkan Karpenter ke kluster Kubernetes untuk meningkatkan efisiensi dan biaya menjalankan beban kerja pada kluster tersebut. Karpenter mengawasi pod yang ditandai oleh penjadwal Kubernetes sebagai tidak dapat dijadwalkan. Ini juga secara dinamis menyediakan dan mengelola simpul yang dapat memenuhi kebutuhan pod.

Karpenter memberikan pengendalian terperinci atas penyediaan node dan penempatan beban kerja di kluster terkelola. Kontrol ini mengoptimalkan alokasi sumber daya, membantu memastikan isolasi antara aplikasi setiap penyewa, dan mengurangi biaya operasional sehingga meningkatkan multitenancy. Saat Anda membangun solusi multipenyewa di AKS, Karpenter menyediakan kemampuan yang berguna untuk membantu mengelola berbagai persyaratan aplikasi untuk mendukung penyewa yang berbeda.

Misalnya, Anda mungkin memerlukan beberapa aplikasi penyewa untuk berjalan pada kumpulan simpul yang dioptimalkan GPU dan yang lain untuk berjalan pada kumpulan simpul yang dioptimalkan memori. Jika aplikasi Anda memerlukan latensi rendah untuk penyimpanan, Anda dapat menggunakan Karpenter untuk menunjukkan bahwa pod memerlukan simpul yang berjalan di zona ketersediaan tertentu. Kemudian Anda dapat mengkolokasikan tingkat penyimpanan dan aplikasi Anda.

AKS memungkinkan penyediaan otomatis node pada kluster AKS melalui Karpenter. Sebagian besar pengguna sebaiknya menggunakan mode penyediaan otomatis node untuk mengaktifkan Karpenter sebagai tambahan terkelola. Untuk informasi selengkapnya, lihat provisi otomatis Simpul. Jika Anda membutuhkan penyesuaian yang lebih canggih, Anda dapat menghost sendiri Karpenter. Untuk informasi selengkapnya, lihat Penyedia Karpenter AKS.

Mesin Virtual Konfidensial

Komputasi rahasia adalah langkah keamanan yang membantu melindungi data saat digunakan melalui isolasi dan enkripsi yang dibantu perangkat lunak atau yang dibantu perangkat keras. Teknologi ini menambahkan lapisan keamanan ekstra ke pendekatan tradisional, yang membantu melindungi data yang tersimpan dan data yang sedang dikirim.

Platform AWS mendukung komputasi rahasia melalui Nitro Enclaves, yang tersedia pada instans EC2 dan Amazon EKS. Instans Amazon EC2 juga mendukung AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP). Repositori GitHub Pengesahan Runtime menyediakan artefak untuk membangun dan menyebarkan Gambar Mesin Amazon untuk EKS dengan dukungan AMD SEV-SNP.

Azure memberi pelanggan VM rahasia untuk membantu memenuhi persyaratan isolasi, privasi, dan keamanan yang ketat dalam kluster AKS. VM rahasia ini menggunakan lingkungan eksekusi tepercaya berbasis perangkat keras. Secara khusus, VM rahasia Azure menggunakan teknologi AMD SEV-SNP. Teknologi ini menolak hypervisor dan akses kode manajemen host lainnya ke memori dan status VM. Gunakan pendekatan ini untuk menambahkan lapisan pertahanan dan perlindungan tambahan terhadap akses operator. Untuk informasi selengkapnya, lihat Menggunakan VM rahasia dalam kluster AKS dan Gambaran Umum VM rahasia di Azure.

Standar Proses Informasi Federal

Federal Information Process Standards (FIPS) 140-3 adalah standar pemerintah AS yang mendefinisikan persyaratan keamanan minimum untuk modul kriptografi dalam produk dan sistem teknologi informasi. Untuk meningkatkan isolasi, privasi, dan keamanan beban kerja penyewa Anda, aktifkan kepatuhan FIPS untuk kumpulan simpul AKS. Kepatuhan FIPS membantu memastikan penggunaan modul kriptografi yang divalidasi untuk enkripsi, hashing, dan operasi terkait keamanan lainnya. Gunakan kumpulan simpul AKS berkemampuan FIPS untuk menggunakan algoritma dan mekanisme kriptografi yang kuat, yang membantu memenuhi persyaratan peraturan dan kepatuhan industri. Untuk informasi selengkapnya tentang cara memperkuat postur keamanan lingkungan AKS multipenyewa Anda, lihat Mengaktifkan FIPS untuk kumpulan simpul AKS.

Enkripsi berbasis host

Di EKS, arsitektur Anda mungkin menggunakan fitur berikut untuk meningkatkan keamanan data:

• Enkripsi Amazon Elastic Block Store (EBS): Anda dapat mengenkripsi data yang tersimpan pada volume Amazon EBS yang dilampirkan ke node pekerja EKS Anda.

• AWS Key Management Service (KMS): Anda dapat menggunakan AWS KMS untuk mengelola kunci enkripsi dan membantu memberlakukan enkripsi data Anda saat tidak aktif. Jika mengaktifkan enkripsi rahasia, Anda dapat mengenkripsi rahasia Kubernetes dengan menggunakan kunci AWS KMS Anda sendiri. Untuk informasi selengkapnya, lihat Mengenkripsi rahasia Kubernetes dengan AWS KMS pada kluster yang ada.

• Enkripsi sisi server Amazon S3: Jika aplikasi EKS Berinteraksi dengan Amazon S3, Anda dapat mengaktifkan enkripsi sisi server untuk wadah S3 Anda untuk membantu melindungi data tidak aktif.

enkripsi berbasis Host pada AKS semakin memperkuat isolasi, privasi, dan keamanan beban kerja penyewa. Saat Anda mengaktifkan enkripsi berbasis host, AKS mengenkripsi data yang disimpan pada komputer host dasar. Pendekatan ini membantu melindungi informasi penyewa sensitif dari akses yang tidak sah. Saat Anda mengaktifkan enkripsi end-to-end, disk sementara dan disk OS bersifat sementara dienkripsi saat tidak digunakan melalui kunci yang dikelola platform.

Di AKS, disk OS dan disk data menggunakan enkripsi sisi server melalui kunci yang dikelola platform secara default. Cache untuk disk ini dienkripsi saat tidak aktif melalui kunci yang dikelola platform. Anda dapat menggunakan kunci enkripsi kunci Anda sendiri untuk mengenkripsi kunci perlindungan data. Metode ini disebut enkripsi amplop, atau pembungkusan. Kunci enkripsi yang Anda tentukan juga mengenkripsi cache untuk disk OS dan disk data.

Enkripsi berbasis host menambahkan lapisan keamanan untuk lingkungan multipenyewa. Setiap data penyewa dalam disk OS dan cache disk data dienkripsi saat tidak aktif melalui kunci yang dikelola pelanggan atau yang dikelola platform, tergantung pada jenis enkripsi disk yang dipilih. Untuk informasi selengkapnya, lihat sumber daya berikut ini:

• Enkripsi berbasis Host pada AKS
• BYOK dengan disk Azure di AKS
• Enkripsi penyimpanan disk Azure di sisi server

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, lihat Pemeliharaan untuk VM 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 saat Anda dapat memulai pembaruan. Jendela pemeliharaan mandiri untuk komputer host biasanya 35 hari, kecuali pembaruan mendesak.

Anda dapat menggunakan pemeliharaan terencana untuk memperbarui VM. Kelola pemberitahuan pemeliharaan terencana dengan menggunakan Azure CLI, Azure PowerShell, atau portal Microsoft Azure. Pemeliharaan terencana mendeteksi apakah Anda menggunakan fitur peningkatan otomatis kluster dan menjadwalkan peningkatan selama jendela pemeliharaan Anda secara otomatis. Untuk informasi selengkapnya, lihat Menggunakan pemeliharaan terencana untuk menjadwalkan jendela pemeliharaan untuk kluster AKS Anda dan perintah konfigurasi pemeliharaan az aks.

Pemutakhiran Kubernetes

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

Sebagai default, AKS mengonfigurasi peningkatan untuk melonjak dengan satu node ekstra. Nilai default satu untuk pengaturan max-surge meminimalkan disrupsi beban kerja. Konfigurasi ini membuat simpul tambahan untuk menggantikan simpul versi lama sebelum mengisolasi atau menghentikan aplikasi yang ada. Anda dapat menyesuaikan max-surge nilai untuk setiap kumpulan node untuk mengoptimalkan kompromi antara kecepatan pembaruan dan gangguan pembaruan. Nilai yang lebih tinggi max-surge meningkatkan kecepatan proses peningkatan, tetapi nilai besar untuk max-surge dapat menyebabkan gangguan selama proses peningkatan.

Misalnya, max-surge nilai 100% menyediakan proses peningkatan tercepat dengan menggandakan jumlah simpul. Tetapi nilai ini juga mengosongkan semua simpul di kumpulan simpul secara simultan. Anda mungkin ingin menggunakan nilai tinggi ini untuk pengujian, tetapi untuk simpul produksi, gunakanlah pengaturan max-surge 33%.

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

Selama peningkatan, Anda dapat mengatur nilai max-surge ke nilai minimum 1 dan nilai maksimum yang setara dengan jumlah simpul dalam kumpulan tersebut. Anda dapat mengatur nilai yang lebih besar, tetapi jumlah maksimum simpul untuk max-surge tidak dapat melebihi 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 "node pool" memiliki max-surge nilai 50%, Anda memerlukan komputasi tambahan dan kuota IP untuk 10 simpul, yaitu dua simpul dikalikan lima pool, untuk menyelesaikan peningkatan.

Jika Anda menggunakan Antarmuka Jaringan Kontainer Azure, pastikan Anda memiliki CUKUP IP di subnet untuk memenuhi persyaratan 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>

Untuk memperbarui kumpulan node tunggal, gunakan az aks nodepool upgrade.

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

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

• Peningkatan gambar simpul AKS
• Meningkatkan sarana kontrol kluster dengan beberapa kumpulan simpul

Pertimbangan peningkatan

Pertimbangkan praktik terbaik berikut saat Anda meningkatkan versi Kubernetes di kluster AKS:

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

• Lakukan peningkatan secara manual, atau atur saluran peningkatan otomatis pada 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 AKS.

• az aks upgrade Perintah dengan --control-plane-only bendera meningkatkan sarana kontrol kluster dan tidak mengubah 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 pembatasan akses dan pengosongan beban dari simpul Anda. Jika Anda memiliki kuota komputasi rendah yang tersedia, peningkatan dapat gagal. Untuk informasi selengkapnya, lihat Meningkatkan kuota vCPU regional.

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

• Saat Anda meningkatkan kluster AKS yang menggunakan Antarmuka Jaringan Kontainer Azure, pastikan subnet memiliki cukup alamat IP privat yang tersedia untuk simpul tambahan yang dibuat oleh pengaturan max-surge. Untuk informasi selengkapnya, lihat Mengonfigurasi jaringan Antarmuka Jaringan Kontainer Azure di AKS.

• Jika kumpulan simpul kluster Anda mencakup beberapa zona ketersediaan dalam suatu wilayah, proses peningkatan dapat membuat konfigurasi zona yang tidak seimbang untuk sementara waktu. Untuk informasi selengkapnya, lihat Kumpulan simpul yang mencakup beberapa zona ketersediaan.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• Paolo Salvatori | Insinyur Sistem Utama

Kontributor lain:

• Laura Nicolas | Insinyur Perangkat Lunak Senior
• Chad Kittel | Insinyur Perangkat Lunak Utama - Pola & Praktik Azure
• Ed Price | Manajer Program Konten Senior
• Theano Petersen | Penulis Teknis

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

• Praktik terbaik kluster AKS
• Membuat kluster AKS privat dengan zona DNS publik
• Membuat kluster AKS privat dengan menggunakan Terraform dan Azure DevOps
• Membuat kluster AKS publik atau privat dengan Azure NAT Gateway dan Azure Application Gateway
• Gunakan titik akhir privat dengan kluster AKS privat
• Buat kluster AKS dengan Pengontrol Ingress dari Application Gateway
• Pelatihan: Pengantar Kubernetes
• Pelatihan: Pengantar Kubernetes di Azure
• Pelatihan: Mengembangkan dan menyebarkan aplikasi di Kubernetes
• Pelatihan: Optimalkan biaya komputasi di AKS

Sumber daya terkait

• AKS untuk para profesional yang berkecimpung di Amazon EKS
• Manajemen identitas dan akses Kubernetes
• Pemantauan dan pengelogan Kubernetes
• Mengamankan akses jaringan ke Kubernetes
• Opsi penyimpanan untuk kluster Kubernetes
• Manajemen biaya untuk Kubernetes
• Tata kelola kelompok
• Perjalanan solusi AKS
• Panduan operasi hari-2 AKS
• Pilih opsi Kubernetes pada komputasi edge
• GitOps untuk AKS