Tanya jawab umum AKS

Artikel ini memberikan jawaban atas beberapa pertanyaan paling umum tentang Azure Kubernetes Service (AKS).

Dukungan

Apakah AKS menawarkan SLA?

AKS menyediakan jaminan perjanjian tingkat layanan (SLA) di tingkat harga Standar dengan fitur Uptime SLA.

Apa itu dukungan platform, dan apa itu termasuk?

Dukungan platform adalah paket dukungan yang dikurangi untuk kluster versi n-3 yang tidak didukung. Dukungan platform hanya mencakup dukungan infrastruktur Azure.

Untuk informasi selengkapnya, lihat kebijakan dukungan platform.

Apakah AKS secara otomatis meningkatkan kluster saya yang tidak didukung?

Ya, AKS memulai peningkatan otomatis untuk kluster yang tidak didukung. Ketika kluster dalam versi n-3 (di mana n adalah versi minor AKS terbaru yang didukung yang umumnya tersedia) akan turun ke n-4, AKS secara otomatis meningkatkan kluster ke n-2 agar tetap berada dalam kebijakan dukungan AKS.

Untuk informasi selengkapnya, lihat Versi Kubernetes yang didukung, Jendela pemeliharaan terencana, dan Peningkatan otomatis.

Dapatkah saya menerapkan diskon reservasi Azure ke simpul agen AKS saya?

Simpul agen AKS ditagih sebagai komputer virtual (VM) Azure standar. Jika Anda membeli reservasi Azure untuk ukuran VM yang Anda gunakan di AKS, diskon tersebut akan diterapkan secara otomatis.

Operasional

Bisakah saya menjalankan kontainer Windows Server pada AKS?

Ya, AKS mendukung kontainer Windows Server. Untuk informasi selengkapnya, lihat Tanya Jawab Umum Windows Server di AKS.

Sistem operasi (OS) Linux apa yang didukung di AKS?

AKS mendukung empat sistem operasi Linux utama, termasuk Ubuntu Linux, Azure Linux, Azure Linux OS Guard, dan Flatcar Container Linux untuk AKS. Saat menentukan --os-type Linux selama pembuatan kumpulan simpul atau pembuatan kluster, OS defaultnya adalah Ubuntu Linux.

Versi sistem operasi (OS) apa yang didukung pada AKS?

Saat menggunakan --os-sku Ubuntu, AKS secara default menggunakan Ubuntu 22.04 pada Kubernetes versi 1.25-1.34. AKS menggunakan default Ubuntu 24.04 pada Kubernetes versi 1.35+. Saat menggunakan --os-sku AzureLinux, AKS secara default menggunakan Azure Linux 3.0 pada Kubernetes versi 1.32+. Dalam beberapa skenario, seperti kumpulan simpul berkemampuan FIPS, versi OS default mungkin berbeda. Lihat gambar simpul untuk informasi selengkapnya.

Dapatkah saya memindahkan atau memigrasikan kluster saya di antara penyewa Azure?

Tidak. Memindahkan kluster AKS Anda antar penyewa saat ini tidak didukung.

Dapatkah saya memindahkan atau memigrasikan kluster saya di antara langganan?

Tidak. Memindahkan kluster AKS Anda antar langganan saat ini tidak didukung.

Bisakah saya memindahkan kluster AKS atau sumber daya infrastruktur AKS ke grup sumber daya lain atau mengganti namanya?

Tidak. Memindahkan atau mengganti nama kluster AKS Anda dan sumber daya terkait tidak didukung.

Dapatkah saya memulihkan kluster setelah saya menghapusnya?

Tidak. Anda tidak dapat memulihkan kluster setelah menghapusnya. Saat Anda menghapus kluster, grup sumber daya simpul dan semua sumber dayanya juga dihapus.

Jika Anda ingin menyimpan salah satu sumber daya Anda, pindahkan ke grup sumber daya lain sebelum Anda menghapus kluster Anda. Jika Anda ingin melindungi dari penghapusan yang tidak disengaja, Anda dapat mengunci grup sumber daya terkelola AKS yang menghosting sumber daya kluster Anda dengan menggunakan penguncian grup sumber daya Node.

Dapatkah saya menskalakan kluster AKS saya menjadi nol?

Anda dapat sepenuhnya menghentikan kluster AKS yang sedang berjalan atau User simpul tertentu ke nol.

Anda tidak dapat secara langsung menskalakan kumpulan simpul sistem ke nol.

Dapatkah saya menggunakan API set skala komputer virtual untuk menskalakan secara manual?

Tidak. Operasi skala yang menggunakan API set skala komputer virtual tidak didukung. Anda dapat menggunakan API AKS (az aks scale).

Dapatkah saya menggunakan set skala komputer virtual untuk menskalakan secara manual ke nol simpul?

Tidak. Operasi skala yang menggunakan API set skala komputer virtual tidak didukung. Anda dapat menggunakan API AKS untuk menskalakan kumpulan simpul nonsstem ke nol atau menghentikan kluster Anda sebagai gantinya.

Dapatkah saya menghentikan atau membatalkan alokasi semua VM saya?

Tidak. Konfigurasi ini tidak didukung. Hentikan kluster Anda sebagai gantinya.

Mengapa dua grup sumber daya dibuat dengan AKS?

AKS dibangun berdasarkan banyak sumber daya infrastruktur Azure, termasuk set skala komputer virtual, jaringan virtual, dan disk terkelola. Integrasi ini memungkinkan Anda menerapkan banyak kemampuan inti platform Azure dalam lingkungan Kubernetes terkelola yang disediakan oleh AKS. Misalnya, Anda dapat menggunakan sebagian besar jenis Azure VM langsung dengan AKS, dan Anda dapat menggunakan Reservasi Azure untuk menerima diskon pada sumber daya tersebut secara otomatis.

Untuk mengaktifkan arsitektur ini, setiap penyebaran AKS mencakup dua grup sumber daya:

1. Anda membuat grup sumber daya pertama. Grup ini hanya berisi sumber daya layanan Kubernetes. Penyedia sumber daya AKS secara otomatis membuat grup sumber daya kedua selama penyebaran. Contoh grup sumber daya kedua adalah MC_myResourceGroup_myAKSCluster_eastus. Untuk informasi tentang cara menentukan nama grup sumber daya kedua ini, lihat bagian berikutnya.
2. Grup sumber daya kedua, yang dikenal sebagai grup sumber daya simpul, berisi semua sumber daya infrastruktur yang terkait dengan kluster. Sumber daya ini termasuk VM simpul Kubernetes, jaringan virtual, dan penyimpanan. Secara default, grup sumber daya simpul memiliki nama seperti MC_myResourceGroup_myAKSCluster_eastus. AKS secara otomatis menghapus grup sumber daya simpul setiap kali Anda menghapus kluster. Gunakan grup sumber daya ini hanya untuk sumber daya yang berbagi siklus hidup kluster.

Catatan

Memodifikasi sumber daya apa pun di bawah grup sumber daya simpul di kluster AKS adalah tindakan yang tidak didukung dan akan menyebabkan kegagalan operasi kluster. Anda dapat mencegah perubahan dilakukan pada grup sumber daya simpul. Blokir pengguna untuk memodifikasi sumber daya yang dikelola kluster AKS.

Dapatkah saya memberikan nama saya sendiri untuk grup sumber daya simpul AKS?

Secara default, AKS memberi nama grup sumber daya simpul MC_resourcegroupname_clustername_location, tetapi Anda dapat memberikan nama Anda sendiri.

Untuk menentukan nama grup sumber daya Anda sendiri, pasang ekstensi Azure CLI aks-preview versi 0.3.2 atau yang lebih baru. Saat Anda membuat kluster AKS dengan menggunakan az aks create perintah , gunakan --node-resource-group parameter dan tentukan nama untuk grup sumber daya. Jika Anda menggunakan templat Azure Resource Manager untuk menyebarkan kluster AKS, Anda dapat menentukan nama grup sumber daya dengan menggunakan nodeResourceGroup properti .

• Penyedia sumber daya Azure secara otomatis membuat grup sumber daya sekunder.
• Anda hanya dapat menentukan nama grup sumber daya kustom saat membuat kluster.

Saat bekerja dengan grup sumber daya simpul, Anda tidak dapat:

• Menentukan grup sumber daya yang ada untuk grup sumber daya simpul.
• Menentukan langganan yang berbeda untuk grup sumber daya simpul.
• Ubah nama grup sumber daya simpul setelah Anda membuat kluster.
• Menentukan nama untuk sumber daya terkelola dalam grup sumber daya simpul.
• Mengubah atau menghapus tag sumber daya terkelola yang dibuat Azure dalam grup sumber daya simpul.

Bisakah saya memodifikasi tag dan properti lain dari sumber daya AKS di grup sumber daya simpul?

Anda mungkin mendapatkan kesalahan penskalakan dan peningkatan yang tidak terduga jika Anda mengubah atau menghapus tag yang dibuat Azure dan properti sumber daya lainnya di grup sumber daya simpul. AKS memungkinkan Anda membuat dan memodifikasi tag kustom yang dibuat oleh pengguna akhir, dan Anda dapat menambahkan tag tersebut saat membuat kumpulan simpul. Anda mungkin ingin membuat atau memodifikasi tag kustom, misalnya, untuk menetapkan unit bisnis atau pusat biaya. Opsi lain adalah menerapkan kebijakan dan memodifikasi tag melalui sumber daya AKS itu sendiri—khususnya melalui kluster dan kumpulan simpul..

Tag yang dibuat Azure dibuat untuk layanan Azure masing-masing, dan Anda harus selalu mengizinkannya. Untuk AKS, ada aks-managed tag dan k8s-azure . Memodifikasi tag yang dibuat Azure pada sumber daya di bawah grup sumber daya simpul di kluster AKS adalah tindakan yang tidak didukung, yang merusak tujuan tingkat layanan (SLO).

Catatan

Di masa lalu, nama Owner tag dicadangkan untuk AKS untuk mengelola IP publik yang ditetapkan pada IP front-end load balancer. Sekarang, layanan menggunakan awalan aks-managed . Untuk sumber daya warisan, jangan gunakan kebijakan Azure untuk menerapkan Owner nama tag. Jika tidak, semua sumber daya pada operasi penyebaran dan pembaruan kluster AKS Anda akan rusak. Pembatasan ini tidak berlaku untuk sumber daya yang baru dibuat.

Mengapa saya melihat rilis Helm awalan yang dikelola aks pada kluster saya, dan mengapa jumlah revisi mereka terus meningkat?

AKS menggunakan Helm untuk mengirimkan komponen ke kluster Anda. Anda dapat dengan aman mengabaikan aks-managed rilis Helm awalan. Revisi yang terus meningkat pada rilis Helm ini diharapkan dan aman.

Kuota, batas, dan ketersediaan wilayah

Wilayah Azure mana yang saat ini menyediakan AKS?

Untuk daftar lengkap wilayah yang tersedia, lihat Wilayah dan ketersediaan AKS.

Bisakah saya menyebarkan kluster AKS di seluruh wilayah?

Tidak. Kluster AKS adalah sumber daya regional dan tidak dapat menjangkau wilayah. Untuk panduan tentang cara membuat arsitektur yang mencakup beberapa wilayah, lihat praktik terbaik untuk kelangsungan bisnis dan pemulihan bencana.

Bisakah saya menyebarkan kluster AKS di seluruh zona ketersediaan?

Ya, Anda dapat menyebarkan kluster AKS di satu atau beberapa zona ketersediaan di wilayah yang mendukungnya.

Dapatkah saya memiliki ukuran VM yang berbeda dalam satu kluster?

Ya, Anda dapat menggunakan ukuran VM yang berbeda di kluster AKS Anda dengan membuat beberapa kumpulan simpul.

Berapa batas ukuran pada gambar kontainer di AKS?

AKS tidak menetapkan batasan pada ukuran gambar kontainer. Tetapi semakin besar gambar, semakin tinggi permintaan memori. Ukuran yang lebih besar berpotensi melebihi batas sumber daya atau memori simpul pekerja yang tersedia secara keseluruhan. Secara default, memori untuk ukuran VM Standard_DS2_v2 untuk kluster AKS diatur ke 7 GiB.

Ketika gambar kontainer terlalu besar, seperti dalam rentang terabyte (TB), kubelet mungkin tidak dapat menariknya dari registri kontainer Anda ke simpul karena kurangnya ruang disk.

Untuk simpul Windows Server, Windows Update tidak otomatis berjalan dan menerapkan pembaruan terkini. Anda harus melakukan peningkatan pada kluster dan kumpulan simpul Windows Server di kluster AKS Anda. Ikuti jadwal reguler berdasarkan siklus rilis Windows Update dan proses validasi Anda sendiri. Proses peningkatan ini membuat simpul yang menjalankan citra dan patch Windows Server terbaru, lalu menghapus simpul yang lebih lama. Untuk informasi selengkapnya tentang proses ini, lihat Memutakhirkan kumpulan simpul di AKS.

Apakah gambar AKS diperlukan untuk berjalan sebagai root?

Gambar berikut memiliki persyaratan fungsional untuk dijalankan sebagai root, dan pengecualian harus diajukan untuk kebijakan apa pun:

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Keamanan, akses, dan identitas

Dapatkah saya membatasi siapa yang memiliki akses ke server Kubernetes API?

Ya, ada dua opsi untuk membatasi akses ke server API:

• Gunakan rentang IP resmi server API jika Anda ingin mempertahankan titik akhir publik untuk server API tetapi membatasi akses ke sekumpulan rentang IP tepercaya.
• Gunakan kluster privat jika Anda ingin membatasi server API agar hanya dapat diakses dari dalam jaringan virtual Anda.

Apakah pembaruan keamanan diterapkan ke simpul agen AKS?

AKS menambal CVE yang memiliki perbaikan vendor setiap minggu. CVE tanpa perbaikan sedang menunggu perbaikan vendor sebelum dapat diperbaiki. Gambar AKS diperbarui secara otomatis dalam waktu 30 hari. Kami menyarankan agar Anda menerapkan gambar node yang diperbarui pada irama reguler untuk memastikan bahwa gambar patch terbaru dan patch OS semuanya diterapkan dan saat ini. Anda dapat melakukan tugas ini:

• Secara manual, melalui portal Microsoft Azure atau Azure CLI.
• Dengan memutakhirkan kluster AKS Anda. Kluster meningkatkan node cordon dan drain secara otomatis. Kemudian menghadirkan simpul baru secara online dengan gambar Ubuntu terbaru dan versi patch baru atau versi Kubernetes minor. Untuk informasi selengkapnya, lihat Meningkatkan kluster AKS.
• Dengan menggunakan peningkatan gambar simpul.

Apakah ada ancaman keamanan yang menargetkan AKS yang harus saya waspadai?

Microsoft menyediakan panduan untuk tindakan lain yang dapat Anda ambil untuk mengamankan beban kerja Anda melalui layanan seperti Pertahanan Microsoft untuk Kontainer. Untuk informasi tentang ancaman keamanan yang terkait dengan AKS dan Kubernetes, lihat Target kampanye skala besar baru Kubeflow (8 Juni 2021).

Apakah AKS menyimpan data pelanggan di luar wilayah kluster?

Tidak. Semua data disimpan di wilayah kluster.

Bagaimana cara menghindari masalah lambat pengaturan kepemilikan izin saat volume memiliki banyak file?

Secara tradisional, jika pod Anda berjalan sebagai pengguna nonroot (yang seharusnya), Anda harus menentukan fsGroup parameter di dalam konteks keamanan pod sehingga volume dapat dibaca dan ditulis oleh pod. Untuk informasi selengkapnya tentang persyaratan ini, lihat Mengonfigurasi konteks keamanan untuk pod atau kontainer.

Efek samping pengaturan fsGroup adalah bahwa setiap kali volume dipasang, Kubernetes harus menggunakan chown() perintah dan chmod() secara rekursif untuk semua file dan direktori di dalam volume (dengan beberapa pengecualian). Skenario ini terjadi bahkan jika kepemilikan grup volume sudah cocok dengan parameter yang diminta fsGroup . Konfigurasi ini mungkin mahal untuk volume yang lebih besar dengan banyak file kecil, yang dapat menyebabkan startup pod memakan waktu lama. Skenario ini adalah masalah yang diketahui sebelum v1.20. Solusinya adalah mengatur pod untuk dijalankan sebagai root:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Masalah ini diselesaikan dengan Kubernetes versi 1.20. Untuk informasi selengkapnya, lihat Kubernetes 1.20: Kontrol granular perubahan izin volume.

Jaringan

Bagaimana sarana kontrol terkelola berkomunikasi dengan simpul saya?

AKS menggunakan komunikasi terowongan yang aman untuk memungkinkan api-server kubelet simpul individu dan berkomunikasi, bahkan pada jaringan virtual terpisah. Terowongan diamankan melalui enkripsi Keamanan Lapisan Transportasi bersama. Terowongan utama saat ini yang digunakan AKS adalah Konnectivity, yang sebelumnya dikenal sebagai apiserver-network-proxy. Verifikasi bahwa semua aturan jaringan mengikuti aturan jaringan yang diperlukan Azure dan nama domain yang sepenuhnya memenuhi syarat (FQDN).

Dapatkah pod saya menggunakan FQDN server API alih-alih IP kluster?

Ya, Anda dapat menambahkan anotasi kubernetes.azure.com/set-kube-service-host-fqdn ke pod untuk mengatur KUBERNETES_SERVICE_HOST variabel ke nama domain server API alih-alih IP layanan dalam kluster. Modifikasi ini berguna dalam kasus di mana egress kluster Anda dilakukan melalui firewall lapisan 7. Contohnya adalah saat Anda menggunakan Azure Firewall dengan aturan aplikasi.

Dapatkah saya mengonfigurasi NSG dengan AKS?

AKS tidak menerapkan kelompok keamanan jaringan (NSG) ke subnetnya dan tidak memodifikasi NSG apa pun yang terkait dengan subnet tersebut. AKS hanya memodifikasi pengaturan NSG antarmuka jaringan. Jika Anda menggunakan Antarmuka Jaringan Kontainer (CNI), Anda juga harus memastikan bahwa aturan keamanan di NSG memungkinkan lalu lintas antara rentang perutean antardomain tanpa kelas (CIDR) simpul dan pod. Jika menggunakan kubenet, Anda juga harus memastikan bahwa aturan keamanan di NSG memungkinkan lalu lintas antara simpul dan POD CIDR. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Bagaimana cara kerja sinkronisasi waktu di AKS?

Simpul AKS menjalankan layanan kroni, yang menarik waktu dari host lokal. Kontainer yang berjalan pada pod mendapatkan waktu dari simpul AKS. Aplikasi yang terbuka di dalam kontainer menggunakan waktu dari kontainer pod.

Add-on, ekstensi, dan integrasi

Bisakah saya menggunakan ekstensi VM kustom?

Tidak. AKS adalah layanan terkelola. Manipulasi sumber daya infrastruktur sebagai layanan (IaaS) tidak didukung. Untuk menginstal komponen kustom, gunakan API dan mekanisme Kubernetes. Misalnya, gunakan DaemonSets untuk menginstal komponen yang diperlukan.

Pengontrol penerimaan Kubernetes apa yang didukung AKS? Bisakah pengontrol penerimaan ditambahkan atau dihapus?

AKS mendukung pengontrol penerimaan berikut:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Saat ini, Anda tidak dapat mengubah daftar pengontrol penerimaan di AKS.

Dapatkah saya menggunakan webhook pengontrol penerimaan di AKS?

Ya, Anda dapat menggunakan webhook pengontrol penerimaan di AKS. Kami menyarankan agar Anda mengecualikan namespace layanan AKS internal, yang ditandai dengan control-plane label . Contohnya:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS membuat firewall keluar server API sehingga webhook pengontrol penerimaan Anda harus dapat diakses dari dalam kluster.

Dapatkah webhook pengontrol penerimaan memengaruhi namespace layanan kube-system dan AKS internal?

Untuk melindungi stabilitas sistem dan mencegah pengontrol penerimaan kustom memengaruhi layanan internal di kube-system namespace layanan, AKS memiliki penegak penerimaan, yang secara otomatis mengecualikan kube-system dan namespace internal AKS. Layanan ini memastikan bahwa pengontrol penerimaan kustom tidak memengaruhi layanan yang berjalan di kube-system.

Jika Anda memiliki kasus penggunaan penting untuk menyebarkan sesuatu pada (tidak disarankan kube-system ) untuk mendukung webhook penerimaan kustom Anda, Anda dapat menambahkan label atau anotasi berikut sehingga penegak penerimaan mengabaikannya:

• Label: "admissions.enforcer/disabled": "true"
• Anotasi: "admissions.enforcer/disabled": true

Apakah Azure Key Vault terintegrasi dengan AKS?

Penyedia Azure Key Vault untuk Secrets Store CSI Driver menyediakan integrasi asli Azure Key Vault ke AKS.

Dapatkah saya menggunakan pustaka kriptografi FIPS dengan penyebaran di AKS?

Simpul yang diaktifkan dengan Federal Information Processing Standards (FIPS) sekarang didukung pada kumpulan simpul berbasis Linux. Untuk detail selengkapnya, lihat Menambahkan kumpulan node berkemampuan FIPS.

Bagaimana add-on AKS diperbarui?

Patch apa pun, termasuk patch keamanan, secara otomatis diterapkan ke kluster AKS. Apa pun yang lebih besar dari patch, seperti perubahan versi utama atau minor (yang dapat merusak perubahan pada objek yang Disebarkan), diperbarui saat Anda memperbarui kluster Jika rilis baru tersedia. Untuk informasi tentang kapan rilis baru tersedia, lihat catatan rilis AKS.

Apa tujuan ekstensi Linux AKS yang saya lihat diinstal pada instans set skala komputer virtual Linux saya?

Ekstensi AKS Linux adalah ekstensi Azure VM yang menginstal dan mengonfigurasi alat pemantauan pada simpul pekerja Kubernetes. Ekstensi ini diinstal pada semua simpul Linux baru dan yang sudah ada. Ini mengonfigurasi alat pemantauan berikut:

• Pengekspor simpul: Mengumpulkan telemetri perangkat keras dari VM dan membuatnya tersedia dengan menggunakan titik akhir metrik. Kemudian, alat pemantauan, seperti Prometheus, dapat mengikis metrik ini.
• Node-problem-detector: Bertujuan untuk membuat berbagai masalah node terlihat oleh lapisan upstream dalam tumpukan manajemen kluster. Ini adalah unit systemd yang berjalan pada setiap simpul, mendeteksi masalah node, dan melaporkannya ke server API kluster dengan menggunakan Events dan NodeConditions.
• ig: Adalah kerangka kerja sumber terbuka yang didukung eBPF untuk men-debug dan mengamati sistem Linux dan Kubernetes. Ini menyediakan serangkaian alat (atau gadget) yang mengumpulkan informasi relevan yang dapat digunakan pengguna untuk mengidentifikasi penyebab masalah performa, crash, atau anomali lainnya. Terutama, independensinya dari Kubernetes memungkinkan pengguna untuk menggunakannya juga untuk men-debug masalah sarana kontrol.

Alat-alat ini membantu memberikan pengamatan di sekitar banyak masalah terkait kesehatan simpul, seperti:

• Masalah daemon infrastruktur: Layanan NTP tidak berfungsi
• Masalah perangkat keras: CPU, memori, atau disk buruk
• Masalah kernel: Kebuntuan kernel, sistem file rusak
• Masalah runtime kontainer: Daemon runtime tidak responsif

Ekstensi ini tidak memerlukan akses keluar ekstra ke URL, alamat IP, atau port apa pun di luar persyaratan keluar AKS yang didokumenkan. Ini tidak memerlukan izin khusus yang diberikan di Azure. Ini menggunakan kubeconfig untuk terhubung ke server API untuk mengirim data pemantauan yang dikumpulkan.

Memecahkan masalah kluster

Mengapa perlu waktu lama untuk menghapus kluster saya?

Sebagian besar kluster dihapus berdasarkan permintaan pengguna. Dalam beberapa kasus, terutama kasus di mana Anda membawa grup sumber daya Anda sendiri atau melakukan tugas grup lintas sumber daya, penghapusan dapat memakan lebih banyak waktu atau bahkan gagal. Jika Anda mengalami masalah dengan penghapusan, periksa kembali apakah Anda tidak memiliki kunci pada grup sumber daya. Pastikan juga bahwa sumber daya apa pun di luar grup sumber daya dibongkar dari grup sumber daya.

Mengapa perlu waktu begitu lama untuk membuat atau memperbarui kluster saya?

Jika Anda memiliki masalah dalam membuat dan memperbarui kluster, pastikan Anda tidak memiliki kebijakan atau batasan layanan yang ditetapkan yang mungkin memblokir kluster AKS Anda untuk mengelola sumber daya seperti VM, load balancer, atau tag.

Jika saya memiliki pod atau penyebaran di status NodeLost atau Unknown, apakah saya masih dapat meningkatkan kluster saya?

Anda bisa, tetapi kami tidak merekomendasikannya. Lakukan pembaruan ketika status kluster diketahui dan sehat.

Jika saya memiliki kluster dengan satu atau beberapa simpul dalam status Tidak Sehat, atau jika dimatikan, dapatkah saya melakukan peningkatan?

Tidak. Hapus atau hapus simpul apa pun yang dalam keadaan gagal atau sebaliknya dari kluster sebelum Anda meningkatkan.

Saya mencoba menghapus kluster saya, tetapi saya melihat kesalahan "[Errno 11001] getaddrinfo gagal."

Paling umum, kesalahan ini muncul jika Anda memiliki satu atau beberapa NSG yang digunakan yang masih terkait dengan kluster. Hapus dan coba hapus kluster lagi.

Saya menjalankan peningkatan, tetapi sekarang pod saya berada dalam perulangan crash dan pemeriksaan kesiapan gagal.

Konfirmasikan bahwa perwakilan layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat perwakilan layanan AKS dan info masuk pembaruan AKS.

Kluster saya berfungsi, tetapi tiba-tiba saya tidak dapat menyediakan load balancer atau memasang klaim volume persisten.

Konfirmasikan bahwa perwakilan layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat perwakilan layanan AKS dan info masuk pembaruan AKS.

Pensiun dan penghentian

Versi OS Linux mana yang tidak digunakan lagi di AKS?

Mulai 17 Maret 2027, Azure Kubernetes Service (AKS) tidak lagi mendukung atau menyediakan pembaruan keamanan Ubuntu 20.04. Gambar simpul yang ada akan dihapus, dan Anda tidak akan dapat menskalakan kumpulan simpul apa pun yang menjalankan Ubuntu 20.04. Migrasikan ke versi Ubuntu yang didukung dengan memutakhirkan kumpulan simpul Anda ke Kubernetes versi 1.35+. Untuk informasi selengkapnya tentang penghentian ini, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.

Versi OS Windows mana yang tidak digunakan lagi di AKS?

Mulai 01 Maret 2026, Azure Kubernetes Service (AKS) tidak lagi mendukung kumpulan simpul Windows Server 2019. Kumpulan simpul yang menjalankan Kubernetes versi 1.33+ tidak dapat menggunakan Windows Server 2019. Mulai 01 April 2027, AKS akan menghapus semua gambar simpul yang ada untuk Windows Server 2019, yang berarti bahwa operasi penskalaan akan gagal. Untuk informasi selengkapnya tentang penghentian ini, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS. Mulai 15 Maret 2027, Azure Kubernetes Service (AKS) tidak lagi mendukung kumpulan simpul Windows Server 2022. Kumpulan simpul yang menjalankan Kubernetes versi 1.36+ tidak dapat menggunakan Windows Server 2022. Mulai 01 April 2028, AKS akan menghapus semua gambar simpul yang ada untuk Windows Server 2022, yang berarti bahwa operasi penskalaan akan gagal. Untuk informasi selengkapnya tentang penghentian ini, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.

Artikel ini memberikan jawaban atas beberapa pertanyaan paling umum tentang Azure Kubernetes Service (AKS).

AKS menyediakan jaminan perjanjian tingkat layanan (SLA) di tingkat harga Standar dengan fitur Uptime SLA.

Dukungan platform adalah paket dukungan yang dikurangi untuk kluster versi n-3 yang tidak didukung. Dukungan platform hanya mencakup dukungan infrastruktur Azure.

Untuk informasi selengkapnya, lihat kebijakan dukungan platform.

Ya, AKS memulai peningkatan otomatis untuk kluster yang tidak didukung. Ketika kluster dalam versi n-3 (di mana n adalah versi minor AKS terbaru yang didukung yang umumnya tersedia) akan turun ke n-4, AKS secara otomatis meningkatkan kluster ke n-2 agar tetap berada dalam kebijakan dukungan AKS.

Untuk informasi selengkapnya, lihat Versi Kubernetes yang didukung, Jendela pemeliharaan terencana, dan Peningkatan otomatis.

Simpul agen AKS ditagih sebagai komputer virtual (VM) Azure standar. Jika Anda membeli reservasi Azure untuk ukuran VM yang Anda gunakan di AKS, diskon tersebut akan diterapkan secara otomatis.

Ya, AKS mendukung kontainer Windows Server. Untuk informasi selengkapnya, lihat Tanya Jawab Umum Windows Server di AKS.

AKS mendukung empat sistem operasi Linux utama, termasuk Ubuntu Linux, Azure Linux, Azure Linux OS Guard, dan Flatcar Container Linux untuk AKS. Saat menentukan --os-type Linux selama pembuatan kumpulan simpul atau pembuatan kluster, OS defaultnya adalah Ubuntu Linux.

Saat menggunakan --os-sku Ubuntu, AKS secara default menggunakan Ubuntu 22.04 pada Kubernetes versi 1.25-1.34. AKS menggunakan default Ubuntu 24.04 pada Kubernetes versi 1.35+. Saat menggunakan --os-sku AzureLinux, AKS secara default menggunakan Azure Linux 3.0 pada Kubernetes versi 1.32+. Dalam beberapa skenario, seperti kumpulan simpul berkemampuan FIPS, versi OS default mungkin berbeda. Lihat gambar simpul untuk informasi selengkapnya.

Tidak. Memindahkan kluster AKS Anda antar penyewa saat ini tidak didukung.

Tidak. Memindahkan kluster AKS Anda antar langganan saat ini tidak didukung.

Tidak. Memindahkan atau mengganti nama kluster AKS Anda dan sumber daya terkait tidak didukung.

Tidak. Anda tidak dapat memulihkan kluster setelah menghapusnya. Saat Anda menghapus kluster, grup sumber daya simpul dan semua sumber dayanya juga dihapus.

Jika Anda ingin menyimpan salah satu sumber daya Anda, pindahkan ke grup sumber daya lain sebelum Anda menghapus kluster Anda. Jika Anda ingin melindungi dari penghapusan yang tidak disengaja, Anda dapat mengunci grup sumber daya terkelola AKS yang menghosting sumber daya kluster Anda dengan menggunakan penguncian grup sumber daya Node.

Anda dapat sepenuhnya menghentikan kluster AKS yang sedang berjalan atau User simpul tertentu ke nol.

Anda tidak dapat secara langsung menskalakan kumpulan simpul sistem ke nol.

Tidak. Operasi skala yang menggunakan API set skala komputer virtual tidak didukung. Anda dapat menggunakan API AKS (az aks scale).

Tidak. Operasi skala yang menggunakan API set skala komputer virtual tidak didukung. Anda dapat menggunakan API AKS untuk menskalakan kumpulan simpul nonsstem ke nol atau menghentikan kluster Anda sebagai gantinya.

Tidak. Konfigurasi ini tidak didukung. Hentikan kluster Anda sebagai gantinya.

AKS dibangun berdasarkan banyak sumber daya infrastruktur Azure, termasuk set skala komputer virtual, jaringan virtual, dan disk terkelola. Integrasi ini memungkinkan Anda menerapkan banyak kemampuan inti platform Azure dalam lingkungan Kubernetes terkelola yang disediakan oleh AKS. Misalnya, Anda dapat menggunakan sebagian besar jenis Azure VM langsung dengan AKS, dan Anda dapat menggunakan Reservasi Azure untuk menerima diskon pada sumber daya tersebut secara otomatis.

Untuk mengaktifkan arsitektur ini, setiap penyebaran AKS mencakup dua grup sumber daya:

1. Anda membuat grup sumber daya pertama. Grup ini hanya berisi sumber daya layanan Kubernetes. Penyedia sumber daya AKS secara otomatis membuat grup sumber daya kedua selama penyebaran. Contoh grup sumber daya kedua adalah MC_myResourceGroup_myAKSCluster_eastus. Untuk informasi tentang cara menentukan nama grup sumber daya kedua ini, lihat bagian berikutnya.
2. Grup sumber daya kedua, yang dikenal sebagai grup sumber daya simpul, berisi semua sumber daya infrastruktur yang terkait dengan kluster. Sumber daya ini termasuk VM simpul Kubernetes, jaringan virtual, dan penyimpanan. Secara default, grup sumber daya simpul memiliki nama seperti MC_myResourceGroup_myAKSCluster_eastus. AKS secara otomatis menghapus grup sumber daya simpul setiap kali Anda menghapus kluster. Gunakan grup sumber daya ini hanya untuk sumber daya yang berbagi siklus hidup kluster.

Catatan

Memodifikasi sumber daya apa pun di bawah grup sumber daya simpul di kluster AKS adalah tindakan yang tidak didukung dan akan menyebabkan kegagalan operasi kluster. Anda dapat mencegah perubahan dilakukan pada grup sumber daya simpul. Blokir pengguna untuk memodifikasi sumber daya yang dikelola kluster AKS.

Secara default, AKS memberi nama grup sumber daya simpul MC_resourcegroupname_clustername_location, tetapi Anda dapat memberikan nama Anda sendiri.

Untuk menentukan nama grup sumber daya Anda sendiri, pasang ekstensi Azure CLI aks-preview versi 0.3.2 atau yang lebih baru. Saat Anda membuat kluster AKS dengan menggunakan az aks create perintah , gunakan --node-resource-group parameter dan tentukan nama untuk grup sumber daya. Jika Anda menggunakan templat Azure Resource Manager untuk menyebarkan kluster AKS, Anda dapat menentukan nama grup sumber daya dengan menggunakan nodeResourceGroup properti .

• Penyedia sumber daya Azure secara otomatis membuat grup sumber daya sekunder.
• Anda hanya dapat menentukan nama grup sumber daya kustom saat membuat kluster.

Saat bekerja dengan grup sumber daya simpul, Anda tidak dapat:

• Menentukan grup sumber daya yang ada untuk grup sumber daya simpul.
• Menentukan langganan yang berbeda untuk grup sumber daya simpul.
• Ubah nama grup sumber daya simpul setelah Anda membuat kluster.
• Menentukan nama untuk sumber daya terkelola dalam grup sumber daya simpul.
• Mengubah atau menghapus tag sumber daya terkelola yang dibuat Azure dalam grup sumber daya simpul.

Anda mungkin mendapatkan kesalahan penskalakan dan peningkatan yang tidak terduga jika Anda mengubah atau menghapus tag yang dibuat Azure dan properti sumber daya lainnya di grup sumber daya simpul. AKS memungkinkan Anda membuat dan memodifikasi tag kustom yang dibuat oleh pengguna akhir, dan Anda dapat menambahkan tag tersebut saat membuat kumpulan simpul. Anda mungkin ingin membuat atau memodifikasi tag kustom, misalnya, untuk menetapkan unit bisnis atau pusat biaya. Opsi lain adalah menerapkan kebijakan dan memodifikasi tag melalui sumber daya AKS itu sendiri—khususnya melalui kluster dan kumpulan simpul..

Tag yang dibuat Azure dibuat untuk layanan Azure masing-masing, dan Anda harus selalu mengizinkannya. Untuk AKS, ada aks-managed tag dan k8s-azure . Memodifikasi tag yang dibuat Azure pada sumber daya di bawah grup sumber daya simpul di kluster AKS adalah tindakan yang tidak didukung, yang merusak tujuan tingkat layanan (SLO).

Catatan

Di masa lalu, nama Owner tag dicadangkan untuk AKS untuk mengelola IP publik yang ditetapkan pada IP front-end load balancer. Sekarang, layanan menggunakan awalan aks-managed . Untuk sumber daya warisan, jangan gunakan kebijakan Azure untuk menerapkan Owner nama tag. Jika tidak, semua sumber daya pada operasi penyebaran dan pembaruan kluster AKS Anda akan rusak. Pembatasan ini tidak berlaku untuk sumber daya yang baru dibuat.

AKS menggunakan Helm untuk mengirimkan komponen ke kluster Anda. Anda dapat dengan aman mengabaikan aks-managed rilis Helm awalan. Revisi yang terus meningkat pada rilis Helm ini diharapkan dan aman.

Untuk daftar lengkap wilayah yang tersedia, lihat Wilayah dan ketersediaan AKS.

Tidak. Kluster AKS adalah sumber daya regional dan tidak dapat menjangkau wilayah. Untuk panduan tentang cara membuat arsitektur yang mencakup beberapa wilayah, lihat praktik terbaik untuk kelangsungan bisnis dan pemulihan bencana.

Ya, Anda dapat menyebarkan kluster AKS di satu atau beberapa zona ketersediaan di wilayah yang mendukungnya.

Ya, Anda dapat menggunakan ukuran VM yang berbeda di kluster AKS Anda dengan membuat beberapa kumpulan simpul.

AKS tidak menetapkan batasan pada ukuran gambar kontainer. Tetapi semakin besar gambar, semakin tinggi permintaan memori. Ukuran yang lebih besar berpotensi melebihi batas sumber daya atau memori simpul pekerja yang tersedia secara keseluruhan. Secara default, memori untuk ukuran VM Standard_DS2_v2 untuk kluster AKS diatur ke 7 GiB.

Ketika gambar kontainer terlalu besar, seperti dalam rentang terabyte (TB), kubelet mungkin tidak dapat menariknya dari registri kontainer Anda ke simpul karena kurangnya ruang disk.

Untuk simpul Windows Server, Windows Update tidak otomatis berjalan dan menerapkan pembaruan terkini. Anda harus melakukan peningkatan pada kluster dan kumpulan simpul Windows Server di kluster AKS Anda. Ikuti jadwal reguler berdasarkan siklus rilis Windows Update dan proses validasi Anda sendiri. Proses peningkatan ini membuat simpul yang menjalankan citra dan patch Windows Server terbaru, lalu menghapus simpul yang lebih lama. Untuk informasi selengkapnya tentang proses ini, lihat Memutakhirkan kumpulan simpul di AKS.

Gambar berikut memiliki persyaratan fungsional untuk dijalankan sebagai root, dan pengecualian harus diajukan untuk kebijakan apa pun:

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

Ya, ada dua opsi untuk membatasi akses ke server API:

• Gunakan rentang IP resmi server API jika Anda ingin mempertahankan titik akhir publik untuk server API tetapi membatasi akses ke sekumpulan rentang IP tepercaya.
• Gunakan kluster privat jika Anda ingin membatasi server API agar hanya dapat diakses dari dalam jaringan virtual Anda.

AKS menambal CVE yang memiliki perbaikan vendor setiap minggu. CVE tanpa perbaikan sedang menunggu perbaikan vendor sebelum dapat diperbaiki. Gambar AKS diperbarui secara otomatis dalam waktu 30 hari. Kami menyarankan agar Anda menerapkan gambar node yang diperbarui pada irama reguler untuk memastikan bahwa gambar patch terbaru dan patch OS semuanya diterapkan dan saat ini. Anda dapat melakukan tugas ini:

• Secara manual, melalui portal Microsoft Azure atau Azure CLI.
• Dengan memutakhirkan kluster AKS Anda. Kluster meningkatkan node cordon dan drain secara otomatis. Kemudian menghadirkan simpul baru secara online dengan gambar Ubuntu terbaru dan versi patch baru atau versi Kubernetes minor. Untuk informasi selengkapnya, lihat Meningkatkan kluster AKS.
• Dengan menggunakan peningkatan gambar simpul.

Microsoft menyediakan panduan untuk tindakan lain yang dapat Anda ambil untuk mengamankan beban kerja Anda melalui layanan seperti Pertahanan Microsoft untuk Kontainer. Untuk informasi tentang ancaman keamanan yang terkait dengan AKS dan Kubernetes, lihat Target kampanye skala besar baru Kubeflow (8 Juni 2021).

Tidak. Semua data disimpan di wilayah kluster.

Secara tradisional, jika pod Anda berjalan sebagai pengguna nonroot (yang seharusnya), Anda harus menentukan fsGroup parameter di dalam konteks keamanan pod sehingga volume dapat dibaca dan ditulis oleh pod. Untuk informasi selengkapnya tentang persyaratan ini, lihat Mengonfigurasi konteks keamanan untuk pod atau kontainer.

Efek samping pengaturan fsGroup adalah bahwa setiap kali volume dipasang, Kubernetes harus menggunakan chown() perintah dan chmod() secara rekursif untuk semua file dan direktori di dalam volume (dengan beberapa pengecualian). Skenario ini terjadi bahkan jika kepemilikan grup volume sudah cocok dengan parameter yang diminta fsGroup . Konfigurasi ini mungkin mahal untuk volume yang lebih besar dengan banyak file kecil, yang dapat menyebabkan startup pod memakan waktu lama. Skenario ini adalah masalah yang diketahui sebelum v1.20. Solusinya adalah mengatur pod untuk dijalankan sebagai root:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Masalah ini diselesaikan dengan Kubernetes versi 1.20. Untuk informasi selengkapnya, lihat Kubernetes 1.20: Kontrol granular perubahan izin volume.

AKS menggunakan komunikasi terowongan yang aman untuk memungkinkan api-server kubelet simpul individu dan berkomunikasi, bahkan pada jaringan virtual terpisah. Terowongan diamankan melalui enkripsi Keamanan Lapisan Transportasi bersama. Terowongan utama saat ini yang digunakan AKS adalah Konnectivity, yang sebelumnya dikenal sebagai apiserver-network-proxy. Verifikasi bahwa semua aturan jaringan mengikuti aturan jaringan yang diperlukan Azure dan nama domain yang sepenuhnya memenuhi syarat (FQDN).

Ya, Anda dapat menambahkan anotasi kubernetes.azure.com/set-kube-service-host-fqdn ke pod untuk mengatur KUBERNETES_SERVICE_HOST variabel ke nama domain server API alih-alih IP layanan dalam kluster. Modifikasi ini berguna dalam kasus di mana egress kluster Anda dilakukan melalui firewall lapisan 7. Contohnya adalah saat Anda menggunakan Azure Firewall dengan aturan aplikasi.

AKS tidak menerapkan kelompok keamanan jaringan (NSG) ke subnetnya dan tidak memodifikasi NSG apa pun yang terkait dengan subnet tersebut. AKS hanya memodifikasi pengaturan NSG antarmuka jaringan. Jika Anda menggunakan Antarmuka Jaringan Kontainer (CNI), Anda juga harus memastikan bahwa aturan keamanan di NSG memungkinkan lalu lintas antara rentang perutean antardomain tanpa kelas (CIDR) simpul dan pod. Jika menggunakan kubenet, Anda juga harus memastikan bahwa aturan keamanan di NSG memungkinkan lalu lintas antara simpul dan POD CIDR. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Simpul AKS menjalankan layanan kroni, yang menarik waktu dari host lokal. Kontainer yang berjalan pada pod mendapatkan waktu dari simpul AKS. Aplikasi yang terbuka di dalam kontainer menggunakan waktu dari kontainer pod.

Tidak. AKS adalah layanan terkelola. Manipulasi sumber daya infrastruktur sebagai layanan (IaaS) tidak didukung. Untuk menginstal komponen kustom, gunakan API dan mekanisme Kubernetes. Misalnya, gunakan DaemonSets untuk menginstal komponen yang diperlukan.

AKS mendukung pengontrol penerimaan berikut:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Saat ini, Anda tidak dapat mengubah daftar pengontrol penerimaan di AKS.

Ya, Anda dapat menggunakan webhook pengontrol penerimaan di AKS. Kami menyarankan agar Anda mengecualikan namespace layanan AKS internal, yang ditandai dengan control-plane label . Contohnya:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS membuat firewall keluar server API sehingga webhook pengontrol penerimaan Anda harus dapat diakses dari dalam kluster.

Untuk melindungi stabilitas sistem dan mencegah pengontrol penerimaan kustom memengaruhi layanan internal di kube-system namespace layanan, AKS memiliki penegak penerimaan, yang secara otomatis mengecualikan kube-system dan namespace internal AKS. Layanan ini memastikan bahwa pengontrol penerimaan kustom tidak memengaruhi layanan yang berjalan di kube-system.

Jika Anda memiliki kasus penggunaan penting untuk menyebarkan sesuatu pada (tidak disarankan kube-system ) untuk mendukung webhook penerimaan kustom Anda, Anda dapat menambahkan label atau anotasi berikut sehingga penegak penerimaan mengabaikannya:

• Label: "admissions.enforcer/disabled": "true"
• Anotasi: "admissions.enforcer/disabled": true

Penyedia Azure Key Vault untuk Secrets Store CSI Driver menyediakan integrasi asli Azure Key Vault ke AKS.

Simpul yang diaktifkan dengan Federal Information Processing Standards (FIPS) sekarang didukung pada kumpulan simpul berbasis Linux. Untuk detail selengkapnya, lihat Menambahkan kumpulan node berkemampuan FIPS.

Patch apa pun, termasuk patch keamanan, secara otomatis diterapkan ke kluster AKS. Apa pun yang lebih besar dari patch, seperti perubahan versi utama atau minor (yang dapat merusak perubahan pada objek yang Disebarkan), diperbarui saat Anda memperbarui kluster Jika rilis baru tersedia. Untuk informasi tentang kapan rilis baru tersedia, lihat catatan rilis AKS.

Ekstensi AKS Linux adalah ekstensi Azure VM yang menginstal dan mengonfigurasi alat pemantauan pada simpul pekerja Kubernetes. Ekstensi ini diinstal pada semua simpul Linux baru dan yang sudah ada. Ini mengonfigurasi alat pemantauan berikut:

• Pengekspor simpul: Mengumpulkan telemetri perangkat keras dari VM dan membuatnya tersedia dengan menggunakan titik akhir metrik. Kemudian, alat pemantauan, seperti Prometheus, dapat mengikis metrik ini.
• Node-problem-detector: Bertujuan untuk membuat berbagai masalah node terlihat oleh lapisan upstream dalam tumpukan manajemen kluster. Ini adalah unit systemd yang berjalan pada setiap simpul, mendeteksi masalah node, dan melaporkannya ke server API kluster dengan menggunakan Events dan NodeConditions.
• ig: Adalah kerangka kerja sumber terbuka yang didukung eBPF untuk men-debug dan mengamati sistem Linux dan Kubernetes. Ini menyediakan serangkaian alat (atau gadget) yang mengumpulkan informasi relevan yang dapat digunakan pengguna untuk mengidentifikasi penyebab masalah performa, crash, atau anomali lainnya. Terutama, independensinya dari Kubernetes memungkinkan pengguna untuk menggunakannya juga untuk men-debug masalah sarana kontrol.

Alat-alat ini membantu memberikan pengamatan di sekitar banyak masalah terkait kesehatan simpul, seperti:

• Masalah daemon infrastruktur: Layanan NTP tidak berfungsi
• Masalah perangkat keras: CPU, memori, atau disk buruk
• Masalah kernel: Kebuntuan kernel, sistem file rusak
• Masalah runtime kontainer: Daemon runtime tidak responsif

Ekstensi ini tidak memerlukan akses keluar ekstra ke URL, alamat IP, atau port apa pun di luar persyaratan keluar AKS yang didokumenkan. Ini tidak memerlukan izin khusus yang diberikan di Azure. Ini menggunakan kubeconfig untuk terhubung ke server API untuk mengirim data pemantauan yang dikumpulkan.

Sebagian besar kluster dihapus berdasarkan permintaan pengguna. Dalam beberapa kasus, terutama kasus di mana Anda membawa grup sumber daya Anda sendiri atau melakukan tugas grup lintas sumber daya, penghapusan dapat memakan lebih banyak waktu atau bahkan gagal. Jika Anda mengalami masalah dengan penghapusan, periksa kembali apakah Anda tidak memiliki kunci pada grup sumber daya. Pastikan juga bahwa sumber daya apa pun di luar grup sumber daya dibongkar dari grup sumber daya.

Jika Anda memiliki masalah dalam membuat dan memperbarui kluster, pastikan Anda tidak memiliki kebijakan atau batasan layanan yang ditetapkan yang mungkin memblokir kluster AKS Anda untuk mengelola sumber daya seperti VM, load balancer, atau tag.

Anda bisa, tetapi kami tidak merekomendasikannya. Lakukan pembaruan ketika status kluster diketahui dan sehat.

Tidak. Hapus atau hapus simpul apa pun yang dalam keadaan gagal atau sebaliknya dari kluster sebelum Anda meningkatkan.

Paling umum, kesalahan ini muncul jika Anda memiliki satu atau beberapa NSG yang digunakan yang masih terkait dengan kluster. Hapus dan coba hapus kluster lagi.

Konfirmasikan bahwa perwakilan layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat perwakilan layanan AKS dan info masuk pembaruan AKS.

Konfirmasikan bahwa perwakilan layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat perwakilan layanan AKS dan info masuk pembaruan AKS.

Mulai 17 Maret 2027, Azure Kubernetes Service (AKS) tidak lagi mendukung atau menyediakan pembaruan keamanan Ubuntu 20.04. Gambar simpul yang ada akan dihapus, dan Anda tidak akan dapat menskalakan kumpulan simpul apa pun yang menjalankan Ubuntu 20.04. Migrasikan ke versi Ubuntu yang didukung dengan memutakhirkan kumpulan simpul Anda ke Kubernetes versi 1.35+. Untuk informasi selengkapnya tentang penghentian ini, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.

Mulai 01 Maret 2026, Azure Kubernetes Service (AKS) tidak lagi mendukung kumpulan simpul Windows Server 2019. Kumpulan simpul yang menjalankan Kubernetes versi 1.33+ tidak dapat menggunakan Windows Server 2019. Mulai 01 April 2027, AKS akan menghapus semua gambar simpul yang ada untuk Windows Server 2019, yang berarti bahwa operasi penskalaan akan gagal. Untuk informasi selengkapnya tentang penghentian ini, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS. Mulai 15 Maret 2027, Azure Kubernetes Service (AKS) tidak lagi mendukung kumpulan simpul Windows Server 2022. Kumpulan simpul yang menjalankan Kubernetes versi 1.36+ tidak dapat menggunakan Windows Server 2022. Mulai 01 April 2028, AKS akan menghapus semua gambar simpul yang ada untuk Windows Server 2022, yang berarti bahwa operasi penskalaan akan gagal. Untuk informasi selengkapnya tentang penghentian ini, lihat masalah Penghentian GitHub dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.