Tanya jawab umum AKS

AKS memberikan jaminan 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 GA terbaru yang didukung) 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.

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

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

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 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 menggunakan penguncian grup sumber daya Node.

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

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

Tidak, operasi skala menggunakan API Set Skala Komputer Virtual tidak didukung. Anda dapat menggunakan API AKS (az aks scale).

Tidak, operasi skala menggunakan API Set Skala Komputer Virtual tidak didukung. Anda dapat menggunakan API AKS untuk menskalakan kumpulan simpul non-sistem ke nol atau menghentikan kluster Anda sebagai gantinya.

Tidak, ini bukan konfigurasi yang didukung. Hentikan kluster Anda sebagai gantinya.

AKS dibangun berdasarkan banyak sumber daya infrastruktur Azure, termasuk Virtual Machine Scale Sets, jaringan virtual, dan disk terkelola. Integrasi ini memungkinkan Anda menerapkan banyak kemampuan inti platform Azure dalam lingkungan Kubernetes terkelola yang disediakan oleh AKS. Misalnya, sebagian besar jenis komputer virtual Azure dapat digunakan langsung dengan AKS dan Azure Reservations dapat digunakan 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. Anda hanya boleh menggunakan grup sumber daya ini untuk sumber daya yang berbagi siklus hidup kluster.

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 menggunakan perintah [az aks create][az-aks-create], 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 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 Anda bekerja dengan grup sumber daya simpul, ingatlah bahwa Anda tidak dapat:

• Menentukan grup sumber daya yang ada untuk grup sumber daya simpul.
• Menentukan langganan yang berbeda untuk grup sumber daya simpul.
• Mengubah nama grup sumber daya simpul setelah kluster dibuat.
• 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 untuk 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 membuat Kebijakan Azure dengan cakupan pada grup sumber daya terkelola.

Tag yang dibuat Azure dibuat untuk Layanan Azure masing-masing dan harus selalu diizinkan. 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).

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

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

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

Ya, Anda dapat menggunakan berbagai ukuran komputer virtual di kluster AKS Anda dengan membuat beberapa kumpulan simpul.

AKS tidak menetapkan batasan pada ukuran gambar kontainer. Namun, penting untuk dipahami bahwa 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.

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

Untuk simpul Windows Server, Windows Update tidak otomatis berjalan dan menerapkan pembaruan terkini. Pada jadwal reguler seputar siklus rilis Pemutakhiran Windows dan proses validasi Anda sendiri, Anda harus melakukan pemutakhiran pada kluster dan kumpulan simpul Windows Server di kluster AKS Anda. Proses pemutakhiran 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 "Jalankan 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 serangkaian 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 secara otomatis diperbarui dalam 30 hari. Sebaiknya terapkan Gambar Node yang diperbarui pada irama reguler untuk memastikan bahwa gambar patch terbaru dan patch OS semuanya diterapkan dan saat ini. Anda dapat melakukan ini menggunakan salah satu metode berikut:

• Secara manual, melalui portal Microsoft Azure atau Azure CLI.
• Dengan memutakhirkan kluster AKS Anda. Kluster ini meningkatkan cordon dan menguras simpul secara otomatis serta kemudian membawa 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 memberikan panduan untuk tindakan lainnya yang dapat Anda ambil untuk mengamankan beban kerja melalui layanan seperti Microsoft Defender untuk Kontainer. Ancaman keamanan berikut terkait dengan AKS dan Kubernetes yang harus Anda ketahui:

• Kampanye skala besar baru menargetkan 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 di dalam konteks keamanan pod sehingga volume dapat dibaca dan ditulis oleh Pod. Persyaratan ini dibahas secara lebih rinci di sini.

Efek samping dari pengaturan fsGroup adalah bahwa setiap kali volume dipasang, Kubernetes harus secara chown() rekursif dan chmod() semua file dan direktori di dalam volume (dengan beberapa pengecualian yang disebutkan di bawah). Skenario ini terjadi bahkan jika kepemilikan grup volume sudah cocok dengan yang diminta fsGroup. Ini bisa mahal untuk volume yang lebih besar dengan banyak file kecil, yang dapat menyebabkan startup pod memakan waktu lama. Skenario ini telah menjadi masalah yang diketahui sebelum v1.20, dan solusinya adalah mengatur eksekusi Pod sebagai root:

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

Masalah ini telah diatasi dengan Kubernetes versi 1.20. Untuk mengetahui informasi selengkapnya, lihat Kubernetes 1.20: Kontrol Terperinci Perubahan Izin Volume.

AKS menggunakan komunikasi terowongan yang aman untuk memungkinkan kubelet node server api dan individu berkomunikasi bahkan pada jaringan virtual terpisah. Terowongan diamankan melalui enkripsi mTLS. Terowongan utama saat ini yang digunakan oleh AKS adalah Konnectivity, yang sebelumnya dikenal sebagai apiserver-network-proxy. Verifikasi semua aturan jaringan mengikuti aturan jaringan dan FQDN yang diperlukan Azure.

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. Ini berguna dalam kasus di mana egress kluster Anda dilakukan melalui firewall lapisan 7, seperti saat menggunakan Azure Firewall dengan Aturan Aplikasi.

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

Simpul AKS menjalankan layanan "chrony", yang menarik waktu dari localhost. Kontainer yang berjalan pada pod mendapatkan waktu dari simpul AKS. Aplikasi yang diluncurkan di dalam kontainer menggunakan waktu dari kontainer pod.

Tidak, AKS adalah layanan terkelola, dan manipulasi sumber daya 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. Anda disarankan untuk mengecualikan namespace layanan internal AKS, yang ditandai dengan label bidang kontrol. Contohnya:

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

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

Untuk melindungi stabilitas sistem dan mencegah pengontrol penerimaan kustom berdampak pada layanan internal pada kube-system, namespace layanan AKS memiliki Admissions Enforcer, yang secara otomatis mengecualikan kube-system dan namespace layanan internal AKS. Layanan ini memastikan kontroler penerimaan kustom tidak memengaruhi layanan yang berjalan dalam kube-system.

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

Label: "admissions.enforcer/disabled": "true" atau 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 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 Anda jika rilis baru tersedia. Anda dapat menemukan kapan rilis baru tersedia dengan mengunjungi catatan rilis AKS.

Ekstensi Linux AKS 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 komputer virtual dan membuatnya tersedia 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 node, mendeteksi masalah node, dan melaporkannya ke server API kluster menggunakan Events dan NodeConditions.
• ig: Kerangka kerja sumber terbuka yang didukung eBPF untuk men-debug dan mengamati sistem Linux dan Kubernetes. Ini menyediakan serangkaian alat (atau gadget) yang dirancang untuk mengumpulkan informasi yang relevan, memungkinkan pengguna 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 node, seperti:

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

Ekstensi ini tidak memerlukan akses keluar tambahan 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 lintas RG, penghapusan dapat memakan lebih banyak waktu atau bahkan gagal. Jika Anda memiliki masalah dengan penghapusan, periksa kembali apakah Anda tidak memiliki kunci pada RG, bahwa sumber daya apa pun di luar RG dibongkar dari RG, dan sebagainya.

Jika Anda memiliki masalah dengan operasi buat dan perbarui kluster, pastikan Anda tidak memiliki kebijakan atau batasan layanan yang ditetapkan yang dapat memblokir kluster AKS Anda agar tidak mengelola sumber daya seperti VM, load balancer, tag, dll.

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

Tidak, hapus/hapus node apa pun dalam status gagal atau sebaliknya dari kluster sebelum meningkatkan.

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

Konfirmasikan bahwa perwakilan layanan Anda belum kedaluwarsa. Lihat perwakilan layanan AKS dan kredensial pembaruan AKS.

Konfirmasikan bahwa perwakilan layanan Anda belum kedaluwarsa. Lihat perwakilan layanan AKS dan kredensial pembaruan AKS.