Pertanyaan yang sering diajukan tentang Azure Kubernetes Service (AKS)

Artikel
11/08/2023

Artikel ini sering membahas pertanyaan seputar Azure Kubernetes Service (AKS).

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 daerah dan tidak dapat menjangkau wilayah. Lihat praktik terbaik untuk kelangsungan bisnis dan pemulihan bencana untuk panduan tentang cara membuat arsitektur yang mencakup beberapa wilayah.

Bisakah saya menyebarkan kluster AKS di seluruh zona ketersediaan?

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

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

Ya. Ada dua opsi untuk membatasi akses ke API server:

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.

Dapatkah saya memiliki ukuran VM yang berbeda dalam satu kluster?

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

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 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.

Berapa batas ukuran pada gambar kontainer di AKS?

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.

Simpul Windows Server

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.

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

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).

Bagaimana Sarana Kontrol terkelola berkomunikasi dengan Node saya?

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.

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

Mengapa dua grup sumber daya dibuat dengan AKS?

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:

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.
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 kluster ini 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 dengan memblokir pengguna untuk memodifikasi sumber daya yang dikelola oleh kluster AKS.

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

Ya. Secara default, AKS memberi nama grup sumber daya simpul MC_resourcegroupname_clustername_location, tetapi Anda juga 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 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 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. Lihat informasi tambahan di bagian berikutnya.

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 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 informasi selengkapnya, lihat Apakah AKS menawarkan SLA?

Catatan

Di masa lalu, nama tag "Pemilik" dicadangkan untuk AKS untuk mengelola IP publik yang ditetapkan pada IP ujung depan loadbalancer. Sekarang, layanan mengikuti menggunakan awalan aks-managed . Untuk sumber daya warisan, jangan gunakan kebijakan Azure untuk menerapkan nama tag "Pemilik". Jika tidak, semua sumber daya pada operasi penyebaran dan pembaruan kluster AKS Anda akan rusak. Ini tidak berlaku untuk sumber daya yang baru dibuat.

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. Disarankan agar Anda mengecualikan namespace layanan AKS internal, yang ditandai dengan label sarana kontrol. Misalnya:

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

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

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

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

Apakah Azure Key Vault terintegrasi dengan AKS?

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

Bisakah saya menjalankan kontainer Windows Server pada AKS?

Ya, kontainer Windows Server tersedia di AKS. Untuk menjalankan kontainer Windows Server di AKS, Anda membuat kumpulan simpul yang menjalankan Windows Server sebagai OS tamu. Kontainer Windows Server hanya bisa menggunakan Windows Server 2019. Untuk memulai, lihat Membuat kluster AKS dengan kumpulan simpul Windows Server.

Dukungan Windows Server untuk kumpulan simpul mencakup beberapa batasan yang merupakan bagian dari Windows server hulu dalam proyek Kubernetes. Untuk informasi selengkapnya tentang batasan ini, lihat Kontainer Windows Server dalam batasan AKS.

Apakah AKS menawarkan SLA?

AKS memberikan jaminan SLA di tingkat harga Standar dengan fitur Uptime SLA.

Tingkat harga Gratis tidak memiliki Perjanjian Tingkat Layanan terkait, tetapi memiliki Tujuan Tingkat Layanan sebesar 99,5%. Masalah konektivitas sementara diamati jika ada peningkatan, simpul underlay yang tidak sehat, pemeliharaan platform, aplikasi membanjiri API Server dengan permintaan, dll. Untuk beban kerja misi penting dan produksi, atau jika beban kerja Anda tidak mentolerir hidupkan ulang API Server, sebaiknya gunakan tingkat Standar, yang mencakup SLA Waktu Aktif.

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

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.

Bisakah saya memindahkan/memigrasikan kluster saya antar penyewa Azure?

Memindahkan kluster AKS antar penyewa saat ini tidak didukung.

Bisakah saya memindahkan/memigrasikan kluster saya antar langganan?

Pergerakan kluster antar langganan saat ini tidak didukung.

Bisakah saya memindahkan kluster AKS saya dari langganan Azure saat ini ke yang lain?

Memindahkan kluster AKS dan sumber daya terkait antara langganan Azure tidak didukung.

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

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

Mengapa penghapusan kluster saya begitu lama?

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.

Mengapa pembuatan/pembaruan kluster saya memakan waktu begitu lama?

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.

Dapatkah saya memulihkan kluster setelah menghapusnya?

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

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.

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. Dukungan platform tidak menyertakan apa pun yang terkait dengan hal berikut:

Fungsionalitas dan komponen Kubernetes
Pembuatan kumpulan kluster atau simpul
Perbaikan
Perbaikan bug
Penambal keamanan
Komponen yang dihentikan

Untuk informasi selengkapnya tentang pembatasan, lihat kebijakan dukungan platform.

AKS mengandalkan rilis dan patch dari Kubernetes, yang merupakan proyek Open Source yang hanya mendukung jendela geser tiga versi minor. AKS hanya dapat menjamin dukungan penuh saat versi tersebut sedang dilayankan di hulu. Karena tidak ada lagi patch yang diproduksi di hulu, AKS dapat membiarkan versi tersebut tidak dikirim atau fork. Karena keterbatasan ini, dukungan platform tidak mendukung apa pun dari mengandalkan kubernetes upstream.

Apakah AKS secara otomatis meningkatkan kluster saya yang tidak didukung?

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. Secara otomatis meningkatkan kluster yang didukung platform ke versi yang didukung diaktifkan secara default.

Misalnya, kubernetes v1.25 meningkatkan ke v1.26 selama rilis GA v1.29. Untuk meminimalkan gangguan, siapkan jendela pemeliharaan. Lihat peningkatan otomatis untuk detail tentang saluran peningkatan otomatis.

Jika saya memiliki pod/deployment dalam state 'NodeLost' atau 'Unknown' apakah saya masih dapat memutakhirkan kluster saya?

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

Jika saya memiliki kluster dengan satu atau beberapa simpul dalam keadaan Tidak Sehat atau dimatikan, bisakah saya melakukan peningkatan?

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

Saya menjalankan penghapusan kluster, tetapi melihat kesalahan `[Errno 11001] getaddrinfo failed`

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.

Saya menjalankan peningkatan, tetapi sekarang pod saya mengalami perulangan crash, dan pemeriksaan kesiapan gagal?

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

Kluster saya berfungsi, tetapi tiba-tiba tidak dapat menyediakan LoadBalancers, mount PVC, dll.?

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

Dapatkah saya menskalakan kluster AKS saya menjadi nol?

Anda dapat sepenuhnya menghentikan kluster AKS yang sedang berjalan, menghemat biaya komputasi masing-masing. Selain itu, Anda juga dapat memilih untuk menskalakan atau mengskalakan otomatis semua atau beberapa User kumpulan simpul ke 0, hanya mempertahankan konfigurasi kluster yang diperlukan.

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

Dapatkah saya menggunakan API Virtual Machine Scale Set untuk menskalakan secara manual?

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

Dapatkah saya menggunakan Virtual Machine Scale Sets untuk menskalakan secara manual ke nol simpul?

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

Dapatkah saya menghentikan atau batal mengalokasikan semua VM saya?

Meskipun AKS memiliki mekanisme ketahanan untuk menahan konfigurasi seperti itu dan memulihkannya, itu bukan konfigurasi yang didukung. Hentikan kluster Anda sebagai gantinya.

Bisakah saya menggunakan ekstensi VM kustom?

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.

Apakah AKS menyimpan data pelanggan di luar wilayah kluster?

Tidak, semua data disimpan di wilayah kluster.

Apakah gambar AKS diperlukan untuk berjalan sebagai root?

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

Apa itu Mode Transparan Azure CNI vs. Mode Jembatan?

Dimulai dengan versi 1.2.0, Azure CNI menetapkan mode Transparan sebagai default untuk penyebaran CNI Linux penyewaan tunggal. Mode transparan adalah mengganti mode jembatan. Di bagian Mode jembatan dan mode Transparan berikut, kami membahas selengkapnya tentang perbedaan antara mode dan manfaat dan batasan untuk mode Transparan di Azure CNI.

Mode jembatan

Mode Azure CNI Bridge membuat jembatan L2 bernama "azure0" dengan cara "just in time". Semua antarmuka pasangan pod veth sisi host terhubung ke jembatan ini. Komunikasi Pod-Pod intra VM dan lalu lintas yang tersisa melewati jembatan ini. Jembatan adalah perangkat virtual lapisan 2 yang sendiri tidak dapat menerima atau mengirimkan apa pun kecuali Anda mengikat satu atau beberapa perangkat nyata ke dalamnya. Untuk alasan ini, eth0 VM Linux harus dikonversi menjadi jembatan bawahan menjadi "azure0", yang menciptakan topologi jaringan yang kompleks dalam VM Linux. Sebagai gejala, CNI harus menangani fungsi jaringan lain, seperti pembaruan server DNS.

Bridge mode topology

Contoh berikut menunjukkan seperti apa penyiapan rute ip dalam mode Bridge. Terlepas dari berapa banyak pod yang dimiliki simpul, hanya ada dua rute. Rute pertama mengatakan lalu lintas (tidak termasuk lokal di azure0) masuk ke gateway default subnet melalui antarmuka dengan ip "src 10.240.0.4", yang merupakan IP utama Node. Yang kedua mengatakan ruang Pod "10.20.x.x" ke kernel untuk diputuskan kernel.

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

Mode transparan

Mode transparan mengambil pendekatan mudah untuk menyiapkan jaringan Linux. Dalam mode ini, Azure CNI tidak mengubah properti antarmuka eth0 apa pun di VM Linux. Pendekatan mengubah properti jaringan Linux ini membantu mengurangi masalah kasus sudut kompleks yang mungkin dihadapi kluster dengan mode Bridge. Dalam mode Transparan, Azure CNI membuat dan menambahkan antarmuka pasangan pod veth sisi host yang ditambahkan ke jaringan host. Komunikasi Pod-ke-Pod Intra VM melalui rute ip yang ditambahkan oleh CNI. Pada dasarnya, komunikasi Pod-ke-Pod lebih dari lapisan 3 dan aturan perutean L3 merutekan lalu lintas pod.

Transparent mode topology

Contoh berikut menunjukkan penyiapan rute ip mode Transparan. Setiap antarmuka Pod mendapatkan rute statis yang terpasang sehingga lalu lintas dengan IP dest saat Pod dikirim langsung ke antarmuka pasangan sisi veth host Pod.

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Manfaat mode Transparan

Menyediakan mitigasi untuk conntrack kondisi balapan paralel DNS dan menghindari masalah latensi DNS 5-detik tanpa perlu mengatur DNS lokal simpul (Anda mungkin masih menggunakan DNS lokal simpul karena alasan kinerja).
Menghilangkan latensi DNS 5-detik awal yang diperkenalkan mode jembatan CNI hari ini karena pengaturan jembatan "tepat waktu".
Salah satu kasus sudut dalam mode Bridge adalah bahwa Azure CNI tidak dapat terus memperbarui daftar server DNS kustom yang ditambahkan pengguna ke VNET atau NIC. Skenario ini menghasilkan CNI hanya mengambil instans pertama dari daftar server DNS. Masalah ini diselesaikan dalam mode Transparan, karena CNI tidak mengubah properti eth0 apa pun. Selengkapnya di sini.
Memberikan penanganan lalu lintas dan mitigasi UDP yang lebih baik untuk badai banjir UDP ketika ARP kehabisan waktu. Dalam mode Bridge, ketika bridge tidak mengetahui alamat MAC pod tujuan dalam komunikasi Intra-VM Pod-to-Pod, secara desain, itu menghasilkan badai paket ke semua port. Masalah ini diselesaikan dalam mode Transparan, karena tidak ada perangkat L2 di jalur. Selengkapnya di sini.
Mode transparan berkinerja lebih baik dalam komunikasi Pod-ke-Pod Intra VM dalam hal throughput dan latensi jika dibandingkan dengan mode Bridge.

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 di dalam konteks keamanan pod sehingga volume dapat dibaca dan ditulis oleh Pod. Persyaratan ini tercakup dalam detail lebih lanjut 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.

Dapatkah saya menggunakan pustaka kriptografi FIPS dengan penyebaran di AKS?

Simpul yang diaktifkan FIPS sekarang didukung pada kumpulan simpul berbasis Linux. Untuk detail selengkapnya, lihat Menambahkan kumpulan node berkemampuan FIPS.

Dapatkah saya mengonfigurasi NSG dengan AKS?

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.

Bagaimana cara kerja sinkronisasi Waktu di AKS?

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.

Bagaimana addon 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 Anda jika rilis baru tersedia. Anda dapat menemukan kapan rilis baru tersedia dengan mengunjungi catatan rilis AKS.

Apa tujuan Ekstensi Linux AKS yang saya lihat diinstal pada instans Linux Virtual Machine Scale Sets saya?

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.