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 rencana dukungan terbatas 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.

Operasi

Dapatkah saya menjalankan kontainer Windows Server di AKS?

Ya, AKS mendukung kontainer Windows Server. Untuk informasi selengkapnya, lihat Windows Server pada FAQ 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 tenant 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.

Dapatkah saya memindahkan atau memigrasikan kluster saya ke jaringan virtual lain?

Tidak. Memindahkan kluster AKS Anda ke jaringan virtual lain 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 menskalakan atau menskalakan otomatis semua atau kolam 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. Pengoperasian skala yang menggunakan API kumpulan skala mesin 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 mesin 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 VM Azure 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, instal aks-preview Azure CLI versi ekstensi 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 properti nodeResourceGroup.

• 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.
• Ubah atau hapus 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 penskalan 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 tag Owner dialokasikan 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 nama tag Owner. 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 dengan awalan "aks-managed" pada kluster saya, dan mengapa jumlah revisinya terus meningkat?

AKS menggunakan Helm untuk mengirimkan komponen ke kluster Anda. Anda dapat dengan aman mengabaikan rilis Helm yang diawali dengan aks-managed. Peningkatan revisi yang berkelanjutan 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 secara otomatis menjalankan dan menerapkan pembaruan terbaru. 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 gambar dan patch Windows Server terbaru, lalu menghapus simpul yang lebih lama. Untuk informasi selengkapnya tentang proses ini, lihat Memutakhirkan kumpulan simpul di AKS.

Apakah citra AKS diperlukan untuk berjalan dengan hak akses 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 yang belum ada solusinya sedang menunggu perbaikan dari vendor sebelum dapat diperbaiki. Gambar AKS diperbarui secara otomatis dalam waktu 30 hari. Kami menyarankan agar Anda menerapkan citra node yang diperbarui pada jadwal teratur untuk memastikan bahwa citra patch terbaru dan patch OS semuanya diterapkan agar tetap mutakhir. Anda dapat melakukan tugas ini:

• Secara manual, melalui portal Azure atau Azure CLI.
• Dengan memutakhirkan kluster AKS Anda. Kluster memutakhirkan 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 Microsoft Defender 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 dan kubelet pada simpul individu untuk 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 Azure aturan jaringan yang diperlukan 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 menetapkan variabel KUBERNETES_SERVICE_HOST ke nama domain dari server API, daripada IP layanan di dalam kluster. Modifikasi ini berguna dalam kasus di mana egress kluster Anda dilakukan melalui firewall lapisan 7. Contohnya adalah ketika 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 antarmuka jaringan NSG. 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 Anda menggunakan kubenet, Anda juga harus memastikan bahwa aturan keamanan di NSG memungkinkan lalu lintas antara node dan pod CIDR. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Bagaimana cara kerja sinkronisasi waktu di AKS?

Node AKS menjalankan layanan chrony, yang mengambil waktu dari host lokal. Container yang berjalan pada pod mendapatkan waktu dari node 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 pengendali penerimaan di AKS?

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

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

AKS membatasi lalu lintas keluar server API dengan firewall agar kontroler penerimaan Anda perlu 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, AKS memiliki pengontrol 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 Azure Kubernetes Service (AKS)?

Node yang diaktifkan dengan Federal Information Processing Standards (FIPS) sekarang didukung pada kumpulan node 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, diperbarui saat Anda memperbarui kluster jika rilis baru tersedia, yang dapat menyebabkan perubahan yang merusak pada objek yang dideploy. Untuk informasi tentang kapan rilis baru tersedia, lihat catatan rilis AKS.

Apa tujuan ekstensi Linux AKS yang terpasang pada instans set penskalaan mesin virtual Linux saya?

Ekstensi AKS Linux adalah ekstensi VM Azure 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:

• Node-exporter: 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 dalam 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 singkirkan simpul apa pun yang dalam keadaan gagal atau dalam kondisi lain dari kluster sebelum Anda melakukan peningkatan.

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 mereka dan coba hapus kluster lagi.

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

Konfirmasikan bahwa prinsipal layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat prinsipal layanan AKS dan kredensial pembaruan AKS.

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

Pastikan bahwa prinsipal layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat prinsipal layanan AKS dan memperbarui kredensial 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 isu GitHub Retirement 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 Server Windows 2019. Kumpulan simpul yang menjalankan Kubernetes versi 1.33+ tidak dapat menggunakan Server Windows 2019. Mulai 01 April 2027, AKS akan menghapus semua gambar simpul yang ada untuk Server Windows 2019, yang berarti bahwa operasi penskalaan akan gagal. Untuk informasi selengkapnya tentang penghentian ini, lihat isu GitHub Retirement 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 isu GitHub Retirement 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 rencana dukungan terbatas 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 Windows Server pada FAQ 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 tenant saat ini tidak didukung.

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

Tidak. Memindahkan kluster AKS Anda ke jaringan virtual lain 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 menskalakan atau menskalakan otomatis semua atau kolam simpul tertentu ke nol.

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

Tidak. Pengoperasian skala yang menggunakan API kumpulan skala mesin 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 mesin 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 VM Azure 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, instal aks-preview Azure CLI versi ekstensi 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 properti nodeResourceGroup.

• 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.
• Ubah atau hapus tag sumber daya terkelola yang dibuat Azure dalam grup sumber daya simpul.

Anda mungkin mendapatkan kesalahan penskalan 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 tag Owner dialokasikan 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 nama tag Owner. 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 rilis Helm yang diawali dengan aks-managed. Peningkatan revisi yang berkelanjutan 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 secara otomatis menjalankan dan menerapkan pembaruan terbaru. 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 gambar 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 yang belum ada solusinya sedang menunggu perbaikan dari vendor sebelum dapat diperbaiki. Gambar AKS diperbarui secara otomatis dalam waktu 30 hari. Kami menyarankan agar Anda menerapkan citra node yang diperbarui pada jadwal teratur untuk memastikan bahwa citra patch terbaru dan patch OS semuanya diterapkan agar tetap mutakhir. Anda dapat melakukan tugas ini:

• Secara manual, melalui portal Azure atau Azure CLI.
• Dengan memutakhirkan kluster AKS Anda. Kluster memutakhirkan 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 Microsoft Defender 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 dan kubelet pada simpul individu untuk 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 Azure aturan jaringan yang diperlukan dan nama domain yang sepenuhnya memenuhi syarat (FQDN).

Ya, Anda dapat menambahkan anotasi kubernetes.azure.com/set-kube-service-host-fqdn ke pod untuk menetapkan variabel KUBERNETES_SERVICE_HOST ke nama domain dari server API, daripada IP layanan di dalam kluster. Modifikasi ini berguna dalam kasus di mana egress kluster Anda dilakukan melalui firewall lapisan 7. Contohnya adalah ketika 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 antarmuka jaringan NSG. 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 Anda menggunakan kubenet, Anda juga harus memastikan bahwa aturan keamanan di NSG memungkinkan lalu lintas antara node dan pod CIDR. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan.

Node AKS menjalankan layanan chrony, yang mengambil waktu dari host lokal. Container yang berjalan pada pod mendapatkan waktu dari node 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 AKS internal, yang diberi label control-plane. Contohnya:

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

AKS membatasi lalu lintas keluar server API dengan firewall agar kontroler penerimaan Anda perlu dapat diakses dari dalam kluster.

Untuk melindungi stabilitas sistem dan mencegah pengontrol penerimaan kustom memengaruhi layanan internal di kube-system namespace, AKS memiliki pengontrol 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.

Node yang diaktifkan dengan Federal Information Processing Standards (FIPS) sekarang didukung pada kumpulan node 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, diperbarui saat Anda memperbarui kluster jika rilis baru tersedia, yang dapat menyebabkan perubahan yang merusak pada objek yang dideploy. Untuk informasi tentang kapan rilis baru tersedia, lihat catatan rilis AKS.

Ekstensi AKS Linux adalah ekstensi VM Azure 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:

• Node-exporter: 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 dalam 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 singkirkan simpul apa pun yang dalam keadaan gagal atau dalam kondisi lain dari kluster sebelum Anda melakukan peningkatan.

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

Konfirmasikan bahwa prinsipal layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat prinsipal layanan AKS dan kredensial pembaruan AKS.

Pastikan bahwa prinsipal layanan Anda tidak kedaluwarsa. Untuk informasi selengkapnya, lihat prinsipal layanan AKS dan memperbarui kredensial 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 isu GitHub Retirement 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 Server Windows 2019. Kumpulan simpul yang menjalankan Kubernetes versi 1.33+ tidak dapat menggunakan Server Windows 2019. Mulai 01 April 2027, AKS akan menghapus semua gambar simpul yang ada untuk Server Windows 2019, yang berarti bahwa operasi penskalaan akan gagal. Untuk informasi selengkapnya tentang penghentian ini, lihat isu GitHub Retirement 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 isu GitHub Retirement dan pengumuman penghentian Pembaruan Azure. Untuk tetap mendapatkan informasi tentang pengumuman dan pembaruan, ikuti catatan rilis AKS.