Arsitektur garis besar untuk kluster Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Firewall

Azure Kubernetes Service (AKS)

Kontrol akses berbasis Peran Azure

Artikel ini menyediakan arsitektur infrastruktur garis besar yang direkomendasikan untuk menyebarkan kluster Azure Kubernetes Service (AKS). Ini mengikuti prinsip desain kami dan selaras dengan praktik terbaik arsitektural AKS dari Azure Well-Architected Framework. Artikel ini membimbing beberapa kelompok interdisipliner yang berbeda, seperti tim jaringan, keamanan, dan identitas, dalam menyebarkan infrastruktur serbaguna ini.

Arsitektur ini tidak berfokus pada beban kerja. Ini berkonsentrasi pada kluster AKS itu sendiri. Informasi ini adalah garis besar minimum yang direkomendasikan untuk sebagian besar kluster AKS. Ini terintegrasi dengan layanan Azure yang memberikan pengamatan, menyediakan topologi jaringan yang mendukung pertumbuhan multi-regional, dan mengamankan lalu lintas dalam kluster.

Persyaratan bisnis Anda memengaruhi arsitektur target dan dapat bervariasi di antara konteks aplikasi. Pertimbangkan arsitektur sebagai titik awal Anda untuk tahap praproduksi dan produksi.

Tip

Artikel ini membahas pertimbangan desain yang luas untuk kluster AKS. AKS Otomatis menerapkan banyak keputusan desain untuk mengurangi jumlah pertimbangan yang perlu Anda evaluasi dan untuk mengoptimalkan kasus penggunaan umum. Bahkan jika beban kerja Anda akan dihosting di lingkungan Otomatis AKS, mengetahui fondasi untuk kluster AKS yang dikelola sendiri dapat membantu Anda membuat pilihan yang tepat saat beban kerja Anda berubah.

Kubernetes adalah ekosistem luas yang melampaui teknologi Azure dan Microsoft. Saat Anda menyebarkan kluster AKS, Anda bertanggung jawab atas banyak keputusan tentang cara merancang dan mengoperasikan kluster. Menjalankan kluster AKS melibatkan komponen sumber tertutup dari berbagai vendor, termasuk Microsoft, bersama dengan komponen sumber terbuka dari ekosistem Kubernetes. Lanskap sering berubah, jadi tinjau kembali keputusan secara teratur. Ketika mengadopsi Kubernetes, Anda mengakui bahwa beban kerja Anda membutuhkan kemampuannya dan bahwa tim beban kerja Anda siap untuk berinvestasi secara berkelanjutan.

Anda dapat menggunakan implementasi arsitektur ini pada GitHub: Implementasi referensi garis besar AKS sebagai titik awal alternatif dan mengonfigurasinya untuk memenuhi kebutuhan Anda.

Note

Arsitektur referensi membutuhkan pengetahuan tentang Kubernetes dan konsepnya. Jika Anda memerlukan penyegaran, lihat Intro ke Kubernetes dan Develop dan sebarkan aplikasi di jalur pelatihan Kubernetes.

Architecture

Unduh file Visio untuk arsitektur ini.

Untuk informasi selengkapnya, lihat topologi jaringan Hub-spoke dalam Azure.

Topologi jaringan

Arsitektur ini menggunakan topologi jaringan hub-and-spoke. Sebarkan hub dan spoke di jaringan virtual terpisah yang terhubung melalui virtual network peering. Topologi ini memiliki beberapa keuntungan:

Aktifkan manajemen yang dipisahkan. Anda dapat menerapkan tata kelola dan mematuhi prinsip hak istimewa paling sedikit (PoLP). Ini juga mendukung konsep zona pendaratan Azure dengan pemisahan tugas.
Minimalkan paparan langsung sumber daya Azure ke internet publik.
Menyediakan topologi hub dan spoke regional. Anda dapat memperluas topologi jaringan hub-and-spoke di masa mendatang dan menyediakan isolasi beban kerja.
Gunakan layanan web application firewall untuk membantu memeriksa arus lalu lintas HTTP untuk semua aplikasi web.
Berikan dukungan untuk beban kerja yang mencakup beberapa langganan.
Buat arsitektur dapat diperluas. Untuk mengakomodasi fitur atau beban kerja baru, Anda dapat menambahkan spoke baru alih-alih mendesain ulang topologi jaringan.
Mendukung berbagi sumber daya, seperti firewall dan zona Sistem Nama Domain (DNS), di seluruh jaringan.
Sejajarkan dengan zona pendaratan skala perusahaan Azure.

Hub jaringan virtual

Hub virtual network adalah titik pusat konektivitas dan pengamatan. Dalam arsitektur ini, hub berisi komponen berikut:

Azure Firewall dengan kebijakan firewall global yang ditentukan tim TI pusat Anda untuk menerapkan aturan di seluruh organisasi
Azure Bastion, yang menetapkan terowongan aman ke perimeter jaringan privat sehingga Anda dapat melakukan operasi manajemen kluster
Subnet untuk gateway konektivitas VPN
Azure Monitor untuk pengamatan jaringan

Dalam jaringan, arsitektur memiliki tiga subnet.

Subnet untuk menghosting Azure Firewall

Azure Firewall adalah layanan firewall terkelola. Instans Azure Firewall mengamankan lalu lintas jaringan keluar. Tanpa lapisan keamanan ini, lalu lintas mungkin berkomunikasi dengan layanan berbahaya dan tidak Microsoft yang dapat menyelundupkan data beban kerja sensitif. Gunakan Azure Firewall Manager untuk menyebarkan dan mengonfigurasi beberapa instans Azure Firewall secara terpusat dan mengelola kebijakan Azure Firewall untuk jaringan virtual hub ini jenis arsitektur.

Jaringan lokal untuk menempatkan gateway

Subnet ini adalah tempat penampung untuk gateway VPN atau gateway Azure ExpressRoute. Gateway menyediakan konektivitas antara router di jaringan lokal Anda dan virtual network.

Subnet untuk menghosting Azure Bastion

Subnet ini digunakan untuk Azure Bastion. Anda dapat menggunakan Azure Bastion untuk mengakses sumber daya Azure dengan aman tanpa mengekspos sumber daya ke internet. Arsitektur ini menggunakan Azure Bastion untuk terhubung dengan aman ke server API kluster AKS untuk operasi manajemen. Subnet hanya untuk manajemen dan operasi.

Jaringan virtual Spoke

Spoke virtual network berisi kluster AKS dan sumber daya terkait lainnya. Spoke memiliki subnet berikut.

Subnet untuk hosting Azure Application Gateway

Azure Application Gateway adalah penyeimbang beban lalu lintas web yang beroperasi di Lapisan 7. Implementasi referensi menggunakan SKU Application Gateway v2 yang memungkinkan Azure Web Application Firewall. Web Application Firewall mengamankan lalu lintas masuk dari serangan lalu lintas web umum, termasuk bot. Instans memiliki konfigurasi IP front-end publik yang menerima permintaan pengguna. Secara desain, Application Gateway memerlukan subnet khusus.

Subnet untuk menampung sumber daya ingress

Untuk merutekan dan mendistribusikan lalu lintas, Traefik adalah pengontrol ingress yang memenuhi sumber daya ingress Kubernetes. Load balancer internal Azure ada di subnet ini. Untuk informasi selengkapnya, lihat Gunakan load balancer internal dengan AKS.

Subnet untuk menghosting node kluster

AKS mempertahankan dua kumpulan simpul, yang merupakan grup simpul terpisah. Kumpulan node sistem menghosting pod yang menjalankan layanan kluster inti. Kumpulan simpul pengguna menjalankan beban kerja Anda dan pengontrol ingress untuk mengaktifkan komunikasi masuk ke beban kerja.

Subnet untuk menghosting titik akhir Azure Private Link

Buat koneksi Azure Private Link untuk Azure Container Registry dan Azure Key Vault sehingga pengguna dapat mengakses layanan ini melalui titik akhir private dalam jaringan virtual spoke. Titik akhir privat tidak memerlukan subnet khusus. Anda juga dapat menempatkan titik akhir privat di virtual network hub. Dalam implementasi dasar, titik akhir disebarkan ke subnet khusus dalam jaringan virtual spoke. Pendekatan ini mengurangi lalu lintas yang melewati koneksi jaringan yang di-peering. Ini menyimpan sumber daya yang termasuk dalam kluster dalam virtual network yang sama. Anda juga dapat menerapkan aturan keamanan terperinci di tingkat subnet dengan menggunakan kelompok keamanan jaringan (NSG).

Untuk informasi selengkapnya, lihat opsi penyebaran Private Link.

Subnet untuk server API AKS

Anda dapat mengonfigurasi kluster AKS untuk menggunakan integrasi API server virtual network, yang memproyeksikan titik akhir server API kluster ke dalam subnet yang didelegasikan di virtual network Anda. Konfigurasi ini disebut kluster privat karena memastikan bahwa semua lalu lintas antara server API, kumpulan simpul, dan klien yang terhubung tetap sepenuhnya dalam jaringan privat Anda.

Semua komunikasi antara server API Kubernetes yang dikelola AKS dan klien (klien internal kluster dan eksternal) dibatasi untuk jaringan tepercaya.

Dengan kluster privat, Anda dapat menggunakan NSG dan kontrol jaringan bawaan lainnya untuk mengamankan lingkungan Anda. Konfigurasi ini melarang access publik yang tidak sah antara internet dan lingkungan. Untuk informasi selengkapnya, lihat Buat kluster AKS privat.

Merencanakan alamat IP

Unduh file Visio untuk arsitektur ini.

Arsitektur referensi ini menggunakan beberapa pendekatan jaringan, yang masing-masing memerlukan ruang alamat IP:

Jaringan virtual Azure yang Anda gunakan untuk sumber daya seperti node kluster, server API kluster, titik akhir privat untuk layanan Azure, dan Application Gateway.
Kluster ini menggunakan Azure Container Networking Interface (CNI) Overlay, yang mengalokasikan alamat IP ke pod dari ruang alamat terpisah ke jaringan virtual Azure Anda.

Ruang alamat IP jaringan virtual

Ruang alamat jaringan virtual Azure Anda harus cukup besar untuk menyimpan semua subnet Anda. Memperhitungkan semua entitas yang menerima lalu lintas. Kubernetes mengalokasikan alamat IP untuk entitas dari ruang alamat subnet. Pertimbangkan poin-poin berikut saat Anda merencanakan alamat IP jaringan virtual Azure Anda:

Pembaruan: AKS memperbarui simpul secara teratur untuk memastikan bahwa VM yang mendasarinya selalu terkini dalam fitur keamanan dan patch sistem lainnya. Selama proses upgrade, AKS membuat node yang menyediakan pod sementara, sedangkan node yang di-upgrade akan dinonaktifkan dan dikosongkan. Simpul sementara tersebut menerima alamat IP dari subnet kluster. Pastikan Anda memiliki ruang alamat yang memadai untuk alamat IP simpul sementara.

Dalam arsitektur ini, pod diberikan alamat IP dari dalam ruang alamat pod Azure CNI Overlay, termasuk selama pembaruan bergulir. Pendekatan ini mengurangi jumlah keseluruhan alamat IP yang digunakan dari jaringan virtual Azure Anda dibandingkan dengan pendekatan jaringan Kubernetes lainnya.
Skalabilitas: Pertimbangkan jumlah total simpul sistem dan pengguna serta batas skalabilitas maksimumnya. Misalnya, jika Anda ingin memperbanyak sebesar 400%, Anda memerlukan empat kali jumlah alamat untuk semua simpul yang diperbanyak.

Karena arsitektur ini menggunakan Azure CNI Overlay, skalabilitas pod Anda tidak memengaruhi ruang alamat jaringan virtual Anda.
Alamat-alamat Private Link: Pertimbangkan alamat-alamat yang diperlukan untuk komunikasi dengan layanan Azure lain melalui Private Link. Arsitektur ini memiliki dua alamat yang ditetapkan untuk tautan ke Container Registry dan Key Vault.
Alamat server API kluster privat: Integrasi API server dengan Jaringan Virtual membantu Anda memproyeksikan server API AKS sebagai titik akhir di dalam jaringan virtual Anda. Fitur ini memerlukan ukuran subnet minimum, jadi pastikan Anda memenuhi prasyarat ini selama perencanaan jaringan Anda.
Alamat IP yang dicadangkan: Azure mencadangkan alamat-alamat khusus untuk penggunaannya. Mereka tidak dapat ditugaskan.

Daftar sebelumnya tidak lengkap. Jika desain Anda memiliki sumber daya lain yang memengaruhi jumlah alamat IP yang tersedia, akomodasi alamat tersebut.

Arsitektur ini dirancang untuk satu beban kerja. Dalam kluster AKS produksi, selalu pisahkan kumpulan simpul sistem dari kumpulan simpul pengguna. Saat menjalankan beberapa beban kerja pada kluster, Anda mungkin ingin mengisolasi node pool pengguna satu sama lain. Isolasi ini menghasilkan lebih banyak subnet yang berukuran lebih kecil. Sumber daya Ingress bisa jadi lebih kompleks. Akibatnya, Anda mungkin memerlukan beberapa pengontrol ingress yang masing-masing memerlukan alamat IP tambahan.

Ruang alamat IP Pod

Azure CNI Overlay menetapkan alamat IP ke pod dengan menggunakan ruang alamat khusus, yang terpisah dari ruang alamat yang Anda gunakan di jaringan virtual Anda. Gunakan ruang alamat IP yang tidak tumpang tindih dengan virtual network atau jaringan virtual yang di-peering. Tetapi jika Anda membuat beberapa kluster AKS, Anda dapat dengan aman menggunakan ruang alamat pod yang sama pada setiap kluster.

Azure CNI Overlay menetapkan setiap node ruang alamat /24 untuk pod-nya. Penting untuk memastikan bahwa ruang alamat pod cukup memadai. Izinkan blok /24 sebanyak yang Anda butuhkan untuk jumlah simpul di kluster Anda. Ingatlah untuk menyertakan simpul sementara yang dibuat selama peningkatan atau operasi peluasan skala. Misalnya, jika Anda menggunakan ruang alamat /16 untuk rentang CIDR (Classless Inter-Domain Routing) tanpa kelas, kluster Anda dapat tumbuh hingga maksimum sekitar 250 node.

Setiap simpul mendukung hingga 250 pod, dan batas ini mencakup pod apa pun yang dibuat sementara selama peningkatan.

Untuk informasi selengkapnya, lihat panduan tentang perencanaan alamat IP untuk Azure CNI Overlay.

Pertimbangan ruang alamat IP lainnya

Untuk serangkaian pertimbangan jaringan lengkap untuk arsitektur ini, lihat topologi jaringan garis besar AKS. Untuk informasi selengkapnya tentang cara merencanakan alamat IP untuk kluster AKS, lihat Konfigurasi jaringan CNI Azure di AKS.

Fitur add-in dan fitur pratinjau

Kubernetes dan AKS terus berkembang, dengan siklus rilis yang lebih cepat daripada perangkat lunak untuk lingkungan lokal. Arsitektur garis besar ini tergantung pada fitur pratinjau AKS tertentu dan add-on AKS. Pertimbangkan perbedaan berikut antara fitur pratinjau dan add-on:

Tim AKS menjelaskan fitur pratinjau sebagai dikirim dan disempurnakan karena banyak fitur pratinjau tetap berada dalam status tersebut hanya selama beberapa bulan sebelum mereka pindah ke fase ketersediaan umum (GA).
AKS add-ons dan ekstensi menyediakan fungsionalitas tambahan yang didukung. AKS mengelola instalasi, konfigurasi, dan siklus hidup mereka.

Arsitektur garis besar tidak menyertakan setiap fitur pratinjau atau add-on. Sebaliknya, hanya mencakup yang memiliki nilai signifikan untuk kluster tujuan umum. Karena fitur-fitur ini keluar dari tahap pratinjau, arsitektur dasar ini direvisi dengan sesuai. Ada beberapa fitur pratinjau lain atau add-on AKS yang mungkin ingin Anda evaluasi di kluster praproduksi. Fitur-fitur ini dapat meningkatkan keamanan, pengelolaan, atau persyaratan lainnya. Dengan add-on non-Microsoft, Anda harus menginstal dan memeliharanya, yang mencakup pelacakan versi yang tersedia dan menginstal pembaruan setelah Anda meningkatkan versi Kubernetes dari kluster tersebut.

Referensi gambar kontainer

Kluster mungkin berisi beban kerja dan beberapa image lainnya, seperti ingress controller. Beberapa gambar tersebut mungkin berada di registri publik. Pertimbangkan poin-poin berikut saat Anda menarik gambar ke kluster Anda:

Autentikasi kluster untuk menarik gambar.
Jika Anda menggunakan gambar publik, impor gambar ke dalam registri kontainer yang selaras dengan tujuan tingkat layanan (SLO) Anda. Jika tidak, gambar mungkin mengalami masalah ketersediaan yang tidak terduga. Jika gambar tidak tersedia saat Anda membutuhkannya, masalah operasional dapat terjadi. Pertimbangkan manfaat berikut menggunakan registri kontainer privat, seperti Azure Container Registry, alih-alih registri publik:
- Anda dapat memblokir access yang tidak sah ke gambar Anda.
- Anda tidak memiliki dependensi yang terekspos ke publik.
- Anda dapat mengakses log penarikan gambar untuk memantau aktivitas dan mengatasi masalah konektivitas.
- Anda dapat memanfaatkan pemindaian kontainer terintegrasi dan kepatuhan gambar.
Tarik gambar dari registri resmi. Anda dapat memberlakukan pembatasan ini melalui Azure Policy. Dalam implementasi referensi ini, kluster hanya mengambil image dari instans Azure Container Registry khusus yang dikerahkan bersamaan dengan kluster.

Mengonfigurasi komputasi untuk kluster dasar

Di AKS, setiap kumpulan simpul biasanya memetakan ke set skala komputer virtual. Simpul mesin virtual (VM) di setiap kolam simpul.

Pertimbangkan untuk menggunakan ukuran VM yang lebih kecil untuk kumpulan node sistem agar meminimalkan biaya. Implementasi referensi ini mengimplementasikan kumpulan simpul sistem dengan tiga node D2dv5. Ukuran itu cukup untuk memenuhi beban pod sistem yang diharapkan. Disk sementara sistem operasi berkapasitas 64 GB.

Saat Anda merencanakan kapasitas untuk kumpulan simpul pengguna, pertimbangkan rekomendasi berikut:

Pilih ukuran node yang lebih besar untuk menampung jumlah maksimum pod yang ditetapkan pada node. Simpul besar meminimalkan jejak layanan yang berjalan pada semua simpul, seperti pemantauan dan pencatatan log.
Pilih jenis VM yang sesuai jika Anda memiliki persyaratan beban kerja tertentu. Misalnya, Anda mungkin memerlukan produk yang dioptimalkan memori untuk beberapa beban kerja, atau produk yang dipercepat GPU untuk yang lain. Untuk informasi selengkapnya, lihat Ukuran untuk VM di Azure.
Sebarkan setidaknya dua simpul sehingga beban kerja dapat mengikuti pola ketersediaan tinggi dengan dua replika. Dengan AKS, Anda dapat mengubah jumlah node tanpa membuat ulang kluster.
Rencanakan ukuran node aktual untuk beban kerja Anda berdasarkan persyaratan yang ditentukan tim desain Anda. Berdasarkan persyaratan bisnis, arsitektur ini menggunakan SKU D4dv5 untuk beban kerja produksi.
Asumsikan bahwa beban kerja Anda mengonsumsi hingga 80% dari setiap simpul saat Anda merencanakan kapasitas untuk kluster Anda. Sisanya 20% dicadangkan untuk layanan AKS.
Atur pod maksimum untuk setiap simpul berdasarkan perencanaan kapasitas Anda. Jika Anda mencoba membuat garis besar kapasitas, mulailah dengan nilai 30. Sesuaikan nilai tersebut berdasarkan persyaratan beban kerja, ukuran simpul, dan batasan alamat IP Anda.

Pilih sistem operasi

Sebagian besar kluster AKS menggunakan Linux sebagai sistem operasi untuk kumpulan simpul mereka. Dalam implementasi referensi ini, kami menggunakan Azure Linux, yang merupakan distribusi Linux ringan dan diperkeras yang disetel untuk Azure. Anda dapat memilih distribusi Linux lain seperti Ubuntu jika mau atau jika Azure Linux tidak memenuhi kebutuhan Anda. Jika Anda memilih sistem operasi yang berbeda, pastikan disk OS berukuran tepat untuk gambar tersebut. Beberapa distribusi membutuhkan lebih banyak ruang daripada Azure Linux, jadi Anda mungkin perlu meningkatkan ukuran disk untuk menghindari masalah penyebaran atau runtime.

Jika beban kerja Anda terdiri dari teknologi campuran, Anda dapat menggunakan sistem operasi yang berbeda di kumpulan simpul yang berbeda. Tetapi jika Anda tidak memerlukan sistem operasi yang berbeda, kami sarankan Anda menggunakan sistem operasi tunggal untuk semua kumpulan simpul beban kerja untuk mengurangi kompleksitas operasional.

Mengintegrasikan Microsoft Entra ID untuk kluster

Mengamankan access ke dan dari kluster sangat penting. Gunakan perspektif kluster untuk memahami perbedaan antara lalu lintas dalam dan luar dalam:

Akses Inside-out: Pertimbangkan akses AKS ke komponen Azure seperti infrastruktur jaringan, Container Registry, dan Key Vault. Otorisasi hanya sumber daya yang diizinkan untuk diakses oleh kluster.
Outside-in access: Berikan identitas akses ke kluster Kubernetes. Otorisasi hanya entitas eksternal yang diizinkan akses ke server API Kubernetes dan Azure Resource Manager.

Akses AKS ke komponen Azure

Ada dua cara untuk mengelola akses AKS ke Azure melalui Microsoft Entra ID: prinsipal layanan atau identitas terkelola untuk sumber daya Azure.

Dari dua metode untuk mengelola akses AKS ke Azure, kami merekomendasikan identitas terkelola. Dengan perwakilan layanan, Anda harus mengelola dan memutar rahasia, baik secara manual atau terprogram. Dengan identitas terkelola, Microsoft Entra ID mengelola dan melakukan autentikasi dan rotasi rahasia tepat waktu untuk Anda.

Sebaiknya Aktifkan dan gunakan identitas managed di AKS sehingga kluster dapat berinteraksi dengan sumber daya Azure eksternal melalui Microsoft Entra ID. Jika Anda tidak segera menggunakan integrasi Microsoft Entra ID, Anda dapat menambahkannya nanti.

Secara default, kluster menggunakan dua identitas utama: identitas kluster dan identitas kubelet. Komponen sarana kontrol AKS menggunakan identitas kluster untuk mengelola sumber daya kluster, termasuk penyeimbang muatan ingress, dan alamat IP publik terkelola AKS. Identitas kubelet mengautentikasi dengan Container Registry. Beberapa add-on juga mendukung autentikasi dengan menggunakan identitas terkelola.

Anda harus menggunakan identitas terkelola ketika kluster perlu menarik gambar dari registri kontainer. Tindakan ini memerlukan kluster untuk mendapatkan kredensial registri, yang dilakukan dengan memberikan akses AcrPull ke kubelet managed identity dari kluster ke registri Anda. Jika tidak menggunakan identitas terkelola, Anda dapat menyimpan informasi tersebut dalam rahasia Kubernetes dan menggunakannya imagePullSecrets untuk mengambilnya. Kami tidak merekomendasikan pendekatan ini karena memperkenalkan kompleksitas keamanan, termasuk kebutuhan untuk mengetahui rahasia terlebih dahulu dan untuk menyimpannya di alur DevOps. Ini juga menambahkan overhead operasional karena Anda harus mengubah rahasia.

Dalam arsitektur ini, kluster mengakses sumber daya Azure yang diamankan oleh Microsoft Entra ID dan kluster melakukan operasi yang mendukung identitas terkelola. Tetapkan kontrol akses berbasis peran Azure (Azure RBAC) dan izin pada identitas terkelola kluster, bergantung pada operasi yang dilakukan oleh kluster. Kluster mengautentikasi dirinya sendiri ke Microsoft Entra ID dan kemudian diizinkan atau ditolak akses berdasarkan peran yang ditetapkan kepadanya. Berikut adalah beberapa contoh dari implementasi referensi ini di mana peran bawaan Azure ditetapkan ke kluster:

Peran Kontributor Jaringan mengelola kemampuan kluster untuk mengontrol jaringan virtual spoke. Dengan penetapan peran ini, identitas yang ditetapkan sistem kluster AKS dapat bekerja dengan subnet khusus untuk layanan pengontrol ingress internal dan server API privat AKS.
Peran Private DNS Zone Contributor mengelola kemampuan kluster untuk menautkan zona secara langsung ke jaringan virtual spoke yang menghosting kluster. Kluster privat menyimpan catatan DNS dari internet publik dengan menggunakan zona private DNS. Tetapi masih mungkin untuk membuat kluster AKS privat dengan alamat DNS publik. Kami menyarankan agar Anda secara eksplisit melarang fitur ini dengan mengatur enablePrivateClusterPublicFQDN untuk false mencegah pengungkapan alamat IP privat sarana kontrol Anda. Pertimbangkan untuk menggunakan Azure Policy untuk memberlakukan penggunaan kluster privat tanpa catatan DNS publik.
Peran Monitoring Metrics Publisher mengelola kemampuan kluster untuk mengirim metrik ke Azure Monitor.
Peran AcrPull mengelola kemampuan kluster untuk menarik gambar dari instans Container Registry yang ditentukan.

Akses kluster

integrasi Microsoft Entra juga menyederhanakan keamanan untuk akses luar masuk. Misalnya, Anda mungkin ingin menggunakan kubectl. Sebagai langkah awal, Anda dapat menjalankan az aks get-credentials perintah untuk mendapatkan kredensial kluster. Microsoft Entra ID mengautentikasi identitas Anda terhadap peran Azure yang diizinkan untuk mendapatkan kredensial kluster. Untuk informasi selengkapnya, lihat perizinan peran kluster yang tersedia.

AKS mendukung akses Kubernetes melalui Microsoft Entra ID dengan menggunakan Microsoft Entra ID sebagai penyedia identitas yang terintegrasi dengan RBAC Kubernetes asli atau dengan menggunakan RBAC Azure asli untuk mengontrol akses kluster. Bagian berikut merinci kedua pendekatan.

Kaitkan RBAC Kubernetes dengan Microsoft Entra ID

Kubernetes mendukung RBAC melalui objek API berikut:

Sekumpulan izin yang Anda tentukan dengan menggunakan Role objek atau ClusterRole untuk izin di seluruh kluster.
Pengaitan yang menetapkan pengguna dan grup yang memiliki izin untuk melakukan tindakan. Tentukan pengikatan dengan menggunakan RoleBinding objek atau ClusterRoleBinding .

Kubernetes memiliki beberapa peran bawaan seperti cluster-admin, edit, dan view. Ikatkan peran tersebut kepada pengguna dan grup Microsoft Entra untuk memanfaatkan direktori perusahaan dalam mengatur akses. Untuk informasi selengkapnya, lihat Menggunakan RBAC Kubernetes dengan integrasi Microsoft Entra.

Pastikan Anda menambahkan grup Microsoft Entra untuk akses kluster dan namespace dalam tinjauan akses Microsoft Entra.

Gunakan RBAC Azure untuk otorisasi Kubernetes

Kami menyarankan agar Anda menggunakan Azure RBAC dan Azure penetapan peran untuk memberlakukan pemeriksaan otorisasi pada kluster. Pendekatan otorisasi ini terintegrasi dengan autentikasi Microsoft Entra. Anda dapat menetapkan peran di berbagai cakupan, seperti grup manajemen, langganan, atau grup sumber daya. Semua kluster di bawah cakupan kemudian mewarisi serangkaian penetapan peran yang konsisten sehubungan dengan siapa yang memiliki izin untuk mengakses objek pada kluster Kubernetes.

Sebaiknya jangan gunakan RBAC asli Kubernetes dengan ClusterRoleBindings dan RoleBindings.

Untuk informasi selengkapnya, lihat Azure RBAC untuk otorisasi Kubernetes.

Akun lokal

AKS mendukung autentikasi pengguna Kubernetes asli. Kami tidak menyarankan Anda menggunakan metode ini untuk menyediakan access pengguna ke kluster. Metode ini berbasis sertifikat dan dilakukan secara eksternal dari penyedia identitas utama Anda, yang membuat pengendalian akses pengguna terpusat dan tata kelola Anda menjadi sulit. Selalu kelola akses ke kluster Anda dengan menggunakan Microsoft Entra ID, dan konfigurasikan kluster Anda untuk secara eksplisit melarang akses akun lokal.

Dalam implementasi referensi ini, akses akun kluster lokal dilarang secara eksplisit ketika sistem menerapkan kluster.

Mengintegrasikan Microsoft Entra ID untuk beban kerja

Mirip dengan memiliki identitas terkelola yang ditetapkan sistem Azure untuk seluruh kluster, Anda dapat menetapkan identitas terkelola di tingkat pod. Identitas beban kerja memungkinkan beban kerja yang dihosting untuk mengakses sumber daya melalui Microsoft Entra ID. Misalnya, beban kerja menyimpan file dalam Azure Storage. Ketika perlu mengakses file-file tersebut, pod mengautentikasi dirinya sendiri terhadap sumber daya sebagai identitas terkelola Azure.

Dalam implementasi referensi ini, Microsoft Entra Workload ID pada AKS menyediakan identitas terkelola untuk pod. Pendekatan ini terintegrasi dengan kemampuan asli Kubernetes untuk bergabung dengan penyedia identitas eksternal. Untuk informasi selengkapnya, lihat Federasi Identitas Beban Kerja.

Pilih model jaringan

AKS menyediakan plugin Container Networking Interface (CNI) dalam dua model jaringan: overlay dan flat. Kedua model mendukung kebijakan jaringan untuk kontrol lalu lintas dalam kluster.

Dengan plugin jaringan datar, seperti Azure CNI Pod Subnet, setiap pod mendapatkan alamat IP dari subnet jaringan virtual. Sumber daya dalam jaringan yang sama atau jaringan yang dipeering dapat mengakses pod secara langsung melalui alamat IP mereka tanpa penerjemahan alamat jaringan (NAT). Gunakan model jaringan datar saat beban kerja Anda mengharuskan pod dapat dirutekan secara langsung dari jaringan virtual.

Implementasi referensi ini menggunakan Azure CNI Overlay, yang merupakan plugin jaringan overlay. Ini mengalokasikan alamat IP jaringan virtual hanya untuk simpul dan menetapkan IP pod dari rentang CIDR terpisah. Karena Azure CNI Overlay menggunakan alamat IP jaringan virtual yang jauh lebih sedikit daripada model datar, kami merekomendasikannya untuk sebagian besar penyebaran.

Untuk informasi selengkapnya tentang model, lihat Gambaran umum jaringan AKS CNI dan Praktik terbaik untuk konektivitas dan keamanan jaringan di AKS.

Menyebarkan sumber daya ingress

Sumber daya ingress Kubernetes menangani perutean dan distribusi untuk lalu lintas masuk ke kluster. Ada dua bagian sumber daya ingress:

Penyeimbang beban internal yang dikelola AKS: Penyeimbang beban mengekspos pengontrol ingress melalui alamat IP statis privat. Ini berfungsi sebagai titik kontak tunggal yang menerima aliran masuk.

Arsitektur ini menggunakan Azure Load Balancer. Load Balancer berada di luar kluster dalam subnet yang didedikasikan untuk sumber daya ingress. Ini menerima lalu lintas dari Application Gateway dan komunikasi tersebut menggunakan Transport Layer Security (TLS). Untuk informasi selengkapnya tentang enkripsi TLS untuk lalu lintas masuk, lihat bagian Arus lalu lintas Ingress .
Pengontrol ingress: Contoh ini menggunakan Traefik. Ini berjalan di kumpulan node pengguna di kluster. Ini menerima lalu lintas dari load balancer internal, menghentikan TLS, dan meneruskannya ke pod beban kerja melalui HTTP.

Pengontrol ingress adalah komponen penting dari kluster. Pertimbangkan poin-poin berikut saat Anda mengonfigurasi komponen ini.

Batasi pengontrol ingress ke cakupan operasi tertentu sebagai bagian dari keputusan desain Anda. Misalnya, Anda mungkin mengizinkan pengontrol hanya berinteraksi dengan pod yang menjalankan beban kerja tertentu.
Hindari menempatkan replika pada node yang sama untuk menyebarkan beban dan membantu memastikan kelangsungan bisnis jika node gagal. Gunakan podAntiAffinity untuk tujuan ini.
Batasi pod yang akan dijadwalkan hanya pada kumpulan node pengguna dengan menggunakan nodeSelectors. Pengaturan ini mengisolasi beban kerja dan pod sistem.
Buka port dan protokol yang memungkinkan entitas tertentu mengirim lalu lintas ke pengontrol ingress. Dalam arsitektur ini, Traefik hanya menerima lalu lintas dari Application Gateway.
Konfigurasikan setelan readinessProbe dan livenessProbe yang memantau kesehatan pod pada interval yang ditentukan. Pengontrol ingress harus mengirim sinyal yang menunjukkan kesehatan pod.
Pertimbangkan untuk membatasi access pengontrol ingress ke sumber daya tertentu dan membatasi tindakan yang dapat dilakukannya. Anda dapat menerapkan pembatasan tersebut melalui izin RBAC Kubernetes. Misalnya, dalam arsitektur ini, Traefik diberikan izin untuk menonton, mendapatkan, dan mencantumkan layanan dan titik akhir dengan menggunakan aturan di objek Kubernetes ClusterRole .

Note

Pilih pengontrol ingress yang sesuai berdasarkan kebutuhan Anda, beban kerja, set keterampilan tim, dan dukungan opsi teknologi. Hal yang paling penting, pengontrol ingress Anda harus memenuhi harapan SLO Anda.

Traefik adalah opsi sumber terbuka untuk kluster Kubernetes dan berada dalam arsitektur ini untuk tujuan ilustrasi. Ini menunjukkan integrasi produk non-Microsoft dengan layanan Azure. Misalnya, implementasi menunjukkan cara mengintegrasikan Traefik dengan Microsoft Entra Workload ID dan Key Vault.

Anda juga dapat menggunakan Application Gateway Ingress Controller, yang terintegrasi dengan baik dengan AKS. Application Gateway memberikan manfaat di luar perannya sebagai pengontrol ingress. Ini berfungsi sebagai titik masuk virtual network untuk kluster Anda dan dapat mengamati lalu lintas yang memasuki kluster. Gunakan Application Gateway jika aplikasi Anda memerlukan web application firewall. Ini juga memungkinkan penghentian TLS.

Pengaturan router

Pengontrol ingress menggunakan rute untuk menentukan ke mana harus mengirim lalu lintas. Rute menentukan port sumber di mana lalu lintas diterima dan informasi tentang port tujuan dan protokol.

Berikut adalah contoh dari arsitektur ini:

Traefik menggunakan penyedia Kubernetes untuk mengonfigurasi rute. Opsi annotations, tls, dan entrypoints menunjukkan bahwa rute dilayani melalui HTTPS. Opsi middlewares menentukan bahwa hanya lalu lintas dari subnet Application Gateway yang diizinkan. Respons menggunakan pengodean gzip jika klien menerima. Karena Traefik melakukan penghentian TLS, komunikasi dengan layanan back-end melalui HTTP.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port:
              number: 80

Mengamankan alur jaringan

Dalam arsitektur ini, alur jaringan mencakup jenis lalu lintas berikut:

Lalu lintas masuk dari klien ke beban kerja yang berjalan di kluster.
Lalu lintas keluar dari pod atau node di kluster ke layanan eksternal.
Lalu lintas pod-ke-pod antar pod. Lalu lintas ini mencakup komunikasi antara pengontrol ingress dan beban kerja. Jika beban kerja Anda terdiri dari beberapa aplikasi yang disebarkan ke kluster, komunikasi antara aplikasi tersebut juga termasuk dalam kategori ini.
Lalu lintas manajemen antara klien dan server API Kubernetes.

Unduh file Visio untuk arsitektur ini.

Arsitektur ini memiliki beberapa lapisan keamanan untuk mengamankan semua jenis lalu lintas.

Arus lalu lintas masuk

Arsitektur hanya menerima permintaan terenkripsi TLS dari klien. TLS v1.2 adalah versi minimum yang diizinkan dengan sekumpulan cipher terbatas. Pencocokan ketat Indikasi Nama Server (SNI) diaktifkan. TLS end-to-end disiapkan melalui Application Gateway dengan menggunakan dua sertifikat TLS yang berbeda, seperti yang ditunjukkan pada diagram berikut.

Unduh file Visio untuk arsitektur ini.

Klien mengirimkan permintaan HTTPS ke nama domain: bicycle.contoso.com. Nama tersebut dikaitkan dengan catatan DNS A ke alamat IP publik Application Gateway. Lalu lintas ini dienkripsi untuk membantu memastikan bahwa lalu lintas antara browser klien dan gateway tidak dapat diperiksa atau diubah.
Application Gateway memiliki web application firewall terintegrasi dan menegosiasikan jabat tangan TLS untuk bicycle.contoso.com, yang hanya memungkinkan sandi yang aman. Application Gateway adalah titik penghentian TLS, yang penting karena web application firewall Application Gateway perlu memeriksa permintaan dan respons teks biasa. Key Vault menyimpan sertifikat TLS. Kluster mengaksesnya dengan identitas terkelola yang ditetapkan pengguna yang terintegrasi dengan Application Gateway. Untuk informasi selengkapnya, lihat penghentian TLS dengan sertifikat Key Vault.

Application Gateway memproses aturan inspeksi pada firewall aplikasi web dan menjalankan aturan perutean yang meneruskan lalu lintas ke back end yang sudah dikonfigurasi.
Saat lalu lintas berpindah dari Application Gateway ke back end, lalu lintas dienkripsi lagi dengan sertifikat TLS lain, yang merupakan kartubebas untuk *.aks-ingress.contoso.com, karena diteruskan ke load balancer internal. Enkripsi ulang ini membantu memastikan bahwa lalu lintas yang tidak aman tidak mengalir ke subnet kluster.
Pengontrol ingress menerima lalu lintas terenkripsi melalui load balancer. Pengontrol adalah titik penghentian TLS lain untuk *.aks-ingress.contoso.com dan meneruskan lalu lintas ke pod beban kerja melalui HTTP. Sertifikat disimpan dalam Key Vault, dan driver Antarmuka Penyimpanan Kontainer (CSI) memasangnya ke dalam kluster. Untuk informasi selengkapnya, lihat Menambahkan manajemen rahasia.

Anda dapat menerapkan lalu lintas TLS end-to-end pada setiap titik lompatan melalui pod pemuatan kerja. Pastikan untuk mengukur performa, latensi, dan efek operasional saat membuat keputusan untuk mengamankan lalu lintas antar-pod. Untuk sebagian besar kluster penyewa tunggal, dengan RBAC sarana kontrol yang tepat dan praktik siklus hidup pengembangan perangkat lunak yang matang, cukup untuk mengenkripsi TLS hingga pengontrol ingress dan melindungi dengan Web Application Firewall. Pendekatan ini meminimalkan overhead dalam manajemen beban kerja dan overhead karena performa jaringan yang buruk. Persyaratan beban kerja dan kepatuhan Anda menentukan tempat Anda melakukan penghentian TLS.

Arus lalu lintas keluar

Dalam arsitektur ini, kami sarankan semua lalu lintas keluar dari kluster melewati Azure Firewall. Anda juga dapat menggunakan perangkat virtual jaringan serupa Anda sendiri. Kami tidak merekomendasikan opsi keluar lainnya, seperti Azure NAT Gateway atau proksi HTTP karena tidak menyediakan inspeksi lalu lintas jaringan. Untuk kontrol Zero Trust dan kemampuan untuk memeriksa lalu lintas, kirim semua lalu lintas keluar melalui Azure Firewall. Terapkan konfigurasi ini dengan rute yang ditentukan pengguna (UDR). Lompatan berikutnya dari rute adalah alamat IP pribadi Azure Firewall. Azure Firewall memutuskan apakah akan memblokir atau mengizinkan lalu lintas keluar berdasarkan aturan yang Anda tentukan atau aturan inteligensi ancaman bawaan.

Alternatif untuk Azure Firewall adalah menggunakan fitur proksi HTTP AKS. Semua lalu lintas yang keluar dari kluster menuju alamat IP proksi HTTP, yang meneruskan lalu lintas atau menghentikannya.

Untuk salah satu metode, tinjau aturan lalu lintas jaringan egress yang diperlukan untuk AKS.

Note

Jika Anda menggunakan load balancer publik sebagai titik publik untuk lalu lintas masuk dan lalu lintas keluar melalui Azure Firewall menggunakan UDR (User Defined Routes), Anda mungkin melihat skenario perutean asimetris. Arsitektur ini menggunakan load balancer internal dalam subnet ingress khusus di belakang Application Gateway. Pilihan desain ini meningkatkan keamanan dan juga menghilangkan masalah perutean asimetris. Atau Anda dapat merutekan lalu lintas masuk melalui Firewall sebelum atau sesudah Application Gateway, tetapi pendekatan ini tidak diperlukan untuk sebagian besar situasi, dan kami tidak merekomendasikannya. Untuk informasi selengkapnya tentang perutean asimetris, lihat Mengintegrasikan Firewall dengan load balancer standar Azure.

Pengecualian untuk kontrol Zero Trust adalah ketika kluster perlu berkomunikasi dengan sumber daya Azure lainnya. Misalnya, kluster mungkin perlu menarik gambar yang diperbarui dari registri kontainer atau rahasia dari Key Vault. Dalam skenario ini, kami sarankan Anda menggunakan Private Link.

Keuntungan menggunakan Private Link adalah bahwa subnet tertentu mencapai layanan secara langsung, dan lalu lintas antara kluster dan layanan tidak melalui internet. Kelemahannya adalah bahwa Private Link membutuhkan konfigurasi tambahan alih-alih menggunakan layanan target melalui titik akhir publiknya. Selain itu, tidak semua layanan atau produk Azure mendukung Private Link. Untuk kasus tersebut, pertimbangkan untuk mengaktifkan titik akhir layanan jaringan virtual pada subnet untuk mengakses layanan.

Untuk Container Registry secara khusus, gunakan titik akhir data khusus. Tanpa itu, pengunduhan lapisan image akan dialihkan ke endpoint *.blob.core.windows.net, alih-alih ke endpoint privat registri, dan aturan firewall egress Anda perlu mengizinkan wildcard berbahaya untuk penyimpanan Blob. Aturan ini mengizinkan lalu lintas keluar node ke akun Azure Storage apa pun. Endpoint data khusus mengganti wildcard dengan FQDN spesifik registri (<registry>.<region>.data.azurecr.io) yang diresolusikan melalui Private Link ke endpoint privat Anda, sehingga lalu lintas lapisan image tetap berada di jalur privat dan memungkinkan Anda membatasi aturan egress ke registri klaster Anda.

Jika Private Link atau titik akhir layanan bukan pilihan, Anda dapat menjangkau layanan lain melalui titik akhir publik mereka dan mengontrol akses melalui aturan Azure Firewall dan firewall yang dibangun ke dalam layanan target. Firewall menerapkan terjemahan alamat jaringan sumber (SNAT) ke alur keluar, menggantikan IP Pod dengan salah satu alamat IP publik yang terpasang pada setiap alur, dan pemilihannya tidak deterministik. Tambahkan seluruh kumpulan IP publik yang terlampir ke daftar yang diizinkan layanan target, atau gunakan awalan alamat IP publik untuk mengekspresikan kumpulan tersebut sebagai rentang bersebelahan.

Salah satu kelemahan menyambungkan ke layanan Azure melalui titik akhir publik adalah bahwa Azure Firewall kemudian membutuhkan lebih banyak aturan untuk memastikan hanya mengizinkan lalu lintas dari subnet tertentu. Jumlah IP publik yang terpasang juga membatasi kumpulan port SNAT dan sehingga batas maksimum koneksi keluar bersamaan kluster. Rencanakan beberapa alamat IP pada Azure Firewall sebelum Anda mengalami kehabisan port. Untuk kluster yang membuka sejumlah besar koneksi keluar bersamaan, pasangkan Azure NAT Gateway ke AzureFirewallSubnet untuk memperluas kumpulan port SNAT secara signifikan sambil memastikan semua lalu lintas keluar diawasi oleh firewall.

Lalu lintas Pod-ke-Pod

Secara default, pod dapat menerima lalu lintas dari pod lain di kluster. Gunakan Kubernetes NetworkPolicy untuk membatasi lalu lintas jaringan antar pod. Terapkan kebijakan dengan hati-hati, atau Anda mungkin memiliki situasi di mana aliran jaringan penting diblokir. Hanya izinkan jalur komunikasi tertentu, sesuai kebutuhan, seperti lalu lintas antara pengontrol ingress dan beban kerja. Untuk informasi selengkapnya, lihat kebijakan Network.

Aktifkan kebijakan jaringan saat Anda menyiapkan kluster karena Anda tidak dapat menambahkannya nanti. Anda memiliki beberapa pilihan untuk teknologi yang mengimplementasikan NetworkPolicy. Kami merekomendasikan kebijakan jaringan Azure, yang memerlukan CNI Azure. Opsi lain termasuk kebijakan jaringan Calico, opsi sumber terbuka terkenal. Pertimbangkan Calico jika Anda perlu mengelola kebijakan jaringan di seluruh kluster. Calico tidak tercakup dalam Azure support standar.

Untuk informasi selengkapnya, lihat Perbedaan antara mesin kebijakan jaringan Azure.

Lalu lintas manajemen

Sebagai bagian dari menjalankan kluster, server API Kubernetes menerima lalu lintas dari sumber daya yang ingin melakukan operasi manajemen di kluster, seperti permintaan untuk menciptakan sumber daya guna menskalakan kluster. Contoh sumber daya tersebut termasuk "agent pool build" dalam pipeline DevOps, instans Azure Bastion dalam subnet Azure Bastion, dan "pool node" itu sendiri. Alih-alih menerima lalu lintas manajemen ini dari semua alamat IP, kami sarankan Anda menyiapkan kluster AKS privat.

Untuk informasi selengkapnya, lihat Tentukan rentang IP yang diotorisasi server API.

Kami menyarankan agar Anda menyebarkan kluster AKS sebagai kluster privat. Semua sarana kontrol dan lalu lintas kumpulan simpul tetap berada di jaringan privat Anda dan tidak terekspos ke internet publik. Implementasi referensi ini menyiapkan kluster privat dengan menggunakan integrasi jaringan virtual peladen API. Lingkungan yang lebih rendah mungkin mempertimbangkan untuk melonggarkan rekomendasi kluster privat ini untuk kenyamanan. Tetapi kluster AKS produksi harus selalu disebarkan sebagai kluster pribadi untuk dasar penyebaran yang aman.

Lalu lintas privat ke kluster AKS privat mungkin berasal dari jaringan virtual spoke, dari jaringan yang telah di-peering, atau dari titik akhir privat di jaringan yang berada jauh. Meskipun simpul AKS secara alami hidup di spoke, operator yang melakukan tugas administratif memerlukan jalur jaringan khusus untuk menjangkau server API AKS secara privat. Anda dapat membangun konektivitas ini dengan cara berikut:

Tunnelling: Gunakan Azure Bastion untuk buka terowongan langsung ke server API kluster.
Jump-box: Provisikan VM jump-box, dan gunakan Azure Bastion untuk menyambungkannya melalui SSH atau RDP. Dari sana, operator membuat permintaan terhadap server API kluster melalui alamat IP privatnya.

Dalam implementasi referensi, kami menggunakan Azure Bastion untuk terowongan ke server API AKS saat melakukan operasi manajemen kluster. Secara umum, pendekatan ini lebih mudah dikelola, lebih murah daripada menyebarkan dan mengelola VM jump-box, dan kurang kompleks untuk berkoordinasi di antara beberapa operator. Namun, Anda dapat memilih untuk menggunakan VM jump-box jika Anda memiliki salah satu persyaratan berikut:

Operator menggunakan perangkat yang tidak aman. VM jump-box dapat memberikan penguatan keamanan yang lebih kuat jika perangkat klien Anda tidak tepercaya.
Operator terhubung melalui jaringan yang tidak stabil. VM jump-box dapat memberikan koneksi yang lebih stabil ke kluster, terutama untuk operasi manajemen yang berjalan lama atau batch.
Operator menggunakan alat diagnostik tingkat lanjut. Beberapa jenis alat diagnostik, seperti penangkapan paket, mungkin tidak berfungsi dengan baik dengan pendekatan penerowongan.

Menambahkan manajemen rahasia

Simpan rahasia di penyimpanan kunci terkelola, seperti Key Vault. Keuntungannya adalah bahwa penyimpanan kunci terkelola menangani rotasi rahasia. Ini menyediakan enkripsi yang kuat dan log audit akses. Ini juga menjaga rahasia inti tetap aman dari alur penyebaran. Dalam arsitektur ini, firewall Key Vault diaktifkan dan dikonfigurasi, dan Private Link digunakan untuk terhubung ke sumber daya Azure, seperti Key Vault untuk mengakses rahasia dan sertifikat.

Key Vault terintegrasi dengan baik dengan layanan Azure lainnya. Gunakan fitur bawaan layanan tersebut untuk mengakses data rahasia. Untuk informasi selengkapnya tentang bagaimana Application Gateway mengakses sertifikat TLS untuk alur masuk, lihat bagian Alur lalu lintas.

Model izin RBAC Azure untuk Key Vault memungkinkan Anda menetapkan identitas beban kerja kepada penetapan peran Key Vault Secrets User atau Key Vault Reader, serta mengakses rahasia. Untuk informasi selengkapnya, lihat Mengakses Key Vault dengan menggunakan Azure RBAC.

Akses data rahasia kluster

Anda harus menggunakan identitas beban kerja untuk memungkinkan pod mengakses rahasia dari penyimpanan tertentu. Untuk memfasilitasi proses pengambilan, gunakan driver CSI penyimpanan rahasia. Ketika pod membutuhkan rahasia, driver terhubung dengan penyimpanan yang ditentukan, mengambil rahasia pada volume, dan memasang volume tersebut di kluster. Pod kemudian bisa mendapatkan kunci rahasia dari sistem file volume.

Driver CSI memiliki banyak penyedia untuk mendukung berbagai toko terkelola. Implementasi ini menggunakan Key Vault serta driver CSI untuk penyimpanan rahasia. Ekstensi mengambil sertifikat TLS dari Key Vault dan memuat driver di dalam pod yang menjalankan pengontrol ingress. Operasi ini terjadi selama pembuatan pod, dan volume menyimpan kunci publik dan privat.

penyimpanan beban kerja

Beban kerja dalam arsitektur ini tidak memiliki status. Jika Anda harus menyimpan status, kami sarankan Anda mempertahankannya di luar kluster. Panduan untuk status beban kerja berada di luar cakupan artikel ini.

Untuk informasi selengkapnya, lihat opsi Storage untuk aplikasi di AKS.

Manajemen kebijakan

Cara efektif untuk mengelola kluster AKS adalah dengan menegakkan tata kelola melalui kebijakan. Kubernetes menerapkan kebijakan melalui Open Policy Agent (OPA) Gatekeeper. Untuk AKS, berikan kebijakan melalui Azure Policy. Setiap kebijakan berlaku untuk semua kluster dalam cakupannya. OPA Gatekeeper menangani penegakan kebijakan di kluster dan mencatat semua pemeriksaan kebijakan. Perubahan kebijakan tidak segera tercermin dalam kluster Anda, jadi harapkan beberapa penundaan.

Untuk mengelola kluster AKS, Anda dapat menggunakan Azure Policy dengan beberapa cara:

Mencegah atau membatasi penyebaran kluster AKS dalam grup sumber daya atau langganan. Menerapkan standar untuk organisasi Anda. Misalnya, Anda dapat mengikuti konvensi penamaan atau menentukan tag.
Amankan kluster AKS Anda melalui Azure Policy untuk Kubernetes.

Contoh umum di mana kebijakan dapat berguna adalah dalam tata kelola dan validasi citra kontainer. Gambar kontainer dapat menjadi sumber kerentanan, dan beberapa organisasi mengharuskan gambar kontainer yang tidak tepercaya divalidasi dengan menggunakan alat pemindaian gambar kontainer, lalu disetujui, sebelum dapat digunakan dalam kluster produksi. Anda dapat menerapkan proses ini dengan menggunakan Azure Policy, dan memblokir gambar kontainer yang tidak tepercaya agar tidak disebarkan ke kluster. Untuk informasi selengkapnya, lihat pola Quarantine.

Saat Anda menetapkan kebijakan, terapkan berdasarkan persyaratan beban kerja. Pertimbangkan faktor-faktor ini:

Putuskan apakah akan menetapkan kumpulan kebijakan, yang dikenal sebagai inisiatif, atau memilih kebijakan individual. Azure Policy menyediakan dua inisiatif bawaan: dasar dan terbatas. Setiap inisiatif adalah kumpulan kebijakan bawaan yang berlaku untuk kluster AKS. Kami menyarankan agar Anda memilih inisiatif dan memilih kebijakan lain untuk kluster dan sumber daya, seperti Container Registry, Application Gateway, atau Key Vault, yang berinteraksi dengan kluster. Pilih kebijakan berdasarkan persyaratan organisasi Anda.
Putuskan apakah Anda ingin Mengaudit atau Menolak tindakan. Dalam mode Audit , tindakan diizinkan tetapi ditandai sebagai Tidak Patuh. Memiliki proses untuk memeriksa kondisi yang tidak sesuai pada jadwal rutin dan mengambil tindakan yang diperlukan. Dalam mode Tolak , tindakan diblokir karena melanggar kebijakan. Berhati-hatilah saat Anda memilih mode Tolak karena bisa terlalu ketat untuk beban kerja agar dapat berfungsi.
Tentukan apakah Anda memiliki area dalam beban kerja yang seharusnya tidak sesuai dengan desain. Azure Policy dapat menentukan namespace Kubernetes yang dikecualikan dari penegakan kebijakan. Kami merekomendasikan agar Anda tetap menerapkan kebijakan dalam mode Audit sehingga Anda sadar akan kejadian tersebut.
Tentukan apakah Anda memiliki persyaratan yang tidak tercakup oleh kebijakan bawaan. Anda dapat membuat definisi Azure Policy kustom yang menerapkan kebijakan OPA Gatekeeper kustom Anda. Jangan terapkan kebijakan kustom langsung ke kluster. Untuk informasi selengkapnya, lihat Buat dan tetapkan definisi kebijakan kustom.
Tentukan apakah Anda memiliki persyaratan di seluruh organisasi. Jika demikian, tambahkan kebijakan tersebut di tingkat grup manajemen. Kluster Anda juga harus menetapkan kebijakan khusus beban kerjanya sendiri, bahkan jika organisasi Anda memiliki kebijakan umum.
Tentukan apakah Anda harus menetapkan kebijakan Azure ke cakupan tertentu. Pastikan kebijakan produksi juga divalidasi terhadap lingkungan praproduksi Anda. Jika tidak, saat Anda menyebarkan ke lingkungan produksi, Anda mungkin mengalami pembatasan tambahan tak terduga yang tidak Anda perhitungkan dalam praproduksi.

Implementasi referensi ini memungkinkan Azure Policy saat kluster AKS dibuat. Inisiatif pembatasan ditetapkan dalam mode Audit untuk memantau ketidakpatuhan.

Implementasi ini juga menetapkan kebijakan tambahan yang bukan bagian dari inisiatif bawaan apa pun. Kebijakan tersebut diatur dalam mode Tolak . Misalnya, ada kebijakan untuk memastikan gambar hanya ditarik dari instans Container Registry yang disebarkan.

Pertimbangkan untuk membuat inisiatif khusus Anda sendiri. Gabungkan kebijakan beban kerja Anda menjadi satu tugas.

Untuk mengamati bagaimana fungsi Azure Policy dari dalam kluster, Anda dapat mengakses log pod untuk semua pod di namespace gatekeeper-system dan log untuk azure-policy dan pod azure-policy-webhook di namespace kube-system.

Skalabilitas node dan pod

Dengan meningkatnya permintaan, Kubernetes dapat memperluas skala dengan menambahkan lebih banyak pod ke nod yang ada, melalui penskalaan otomatis pod secara horizontal. Ketika Kubernetes tidak dapat lagi menjadwalkan lebih banyak pod, jumlah simpul harus ditingkatkan melalui penskalaan otomatis kluster AKS. Solusi penskalaan yang lengkap harus memiliki cara untuk menskalakan replika pod dan jumlah node dalam kluster.

Ada dua pendekatan: penskalaan otomatis atau penskalaan manual.

Pendekatan penskalaan otomatis dan manual mengharuskan Anda untuk memantau dan mengatur pemberitahuan tentang penggunaan CPU atau metrik kustom. Untuk penskalaan pod, operator aplikasi Anda dapat menambah atau mengurangi jumlah replika pod dengan menyesuaikan ReplicaSet melalui API Kubernetes. Untuk penskalaan kluster, salah satu metodenya adalah diberi tahu ketika penjadwal Kubernetes gagal. Cara lain adalah dengan mengawasi pod yang tertunda dari waktu ke waktu. Anda dapat menyesuaikan jumlah simpul melalui Azure CLI atau portal Azure.

Kami menyarankan agar Anda menggunakan pendekatan penskalaan otomatis karena beberapa mekanisme manual dibangun ke dalam autoscaler.

Sebagai metode umum, mulailah dengan pengujian performa dengan jumlah minimum pod dan node. Gunakan nilai-nilai tersebut untuk menetapkan ekspektasi dasar. Kemudian, gunakan kombinasi metrik performa dan penskalaan manual untuk menemukan hambatan dan memahami respons aplikasi terhadap penskalaan. Terakhir, gunakan data ini untuk mengatur parameter penskalaan otomatis.

Horizontal Pod Autoscaler

Penskala Pod Horizontal (HPA) adalah sumber daya Kubernetes yang menskalakan jumlah pod.

Di sumber daya HPA, kami sarankan Anda menetapkan jumlah replika minimum dan maksimum. Nilai membatasi batas autoscaling.

HPA dapat menskalakan berdasarkan penggunaan CPU, penggunaan memori, dan metrik kustom. Hanya penggunaan CPU yang disediakan secara bawaan. Definisi HorizontalPodAutoscaler menentukan nilai target untuk metrik. Misalnya, spesifikasi menetapkan penggunaan CPU target. Saat pod berjalan, pengontrol HPA menggunakan API Metrik Kubernetes untuk memeriksa penggunaan CPU setiap pod. Ini membandingkan nilai tersebut dengan penggunaan target dan menghitung rasio. Kemudian menggunakan rasio untuk menentukan apakah pod terlalu dialokasikan atau kurang dialokasikan. Ini bergantung pada penjadwal Kubernetes untuk menetapkan pod baru ke node atau menghapus pod dari node.

Kondisi balapan mungkin terjadi, seperti ketika HPA memeriksa sebelum operasi penskalakan selesai. Jadi, hasilnya bisa menjadi perhitungan rasio yang salah. Untuk informasi selengkapnya, lihat Waktu jeda peristiwa penskalaan.

Jika beban kerja Anda digerakkan oleh peristiwa, opsi sumber terbuka yang populer adalah penskalaan otomatis berbasis peristiwa (KEDA) Kubernetes. Pertimbangkan KEDA jika sumber peristiwa, seperti antrean pesan, mendorong beban kerja Anda, daripada beban kerja Anda terikat CPU atau terikat memori. KEDA mendukung banyak sumber peristiwa atau scaler. Gunakan daftar sumber peristiwa yang dapat diskalakan KEDA di scaler KEDA. Daftar ini mencakup Azure Monitor scaler, yang merupakan cara mudah untuk menskalakan beban kerja KEDA berdasarkan metrik Azure Monitor.

Pengatur skala otomatis kluster

Cluster Autoscaler adalah komponen tambahan AKS yang meningkatkan skala jumlah simpul dalam kumpulan node. Tambahkan selama provisi kluster. Anda memerlukan penskala otomatis kluster terpisah untuk setiap kumpulan node pengguna.

Penjadwal Kubernetes memulai autoscaler untuk kluster. Ketika penjadwal Kubernetes gagal menjadwalkan pod karena kendala sumber daya, autoscaler secara otomatis menyiapkan simpul baru di kumpulan simpul. Sebaliknya, penskala otomatis kluster memeriksa kapasitas node yang tidak terpakai. Jika simpul tidak berjalan pada kapasitas yang diharapkan, pod dipindahkan ke simpul lain, dan simpul yang tidak digunakan akan dihapus.

Saat Anda mengaktifkan autoscaler, atur jumlah simpul maksimum dan minimum. Nilai yang disarankan tergantung pada ekspektasi kinerja beban kerja, seberapa besar Anda ingin kluster tumbuh, dan implikasi biaya. Nomor minimum adalah kapasitas yang disediakan untuk kumpulan node tersebut. Dalam implementasi referensi ini, nilai minimum diatur ke dua karena kesederhanaan beban kerja.

Untuk kumpulan simpul sistem, nilai minimum yang disarankan adalah tiga.

Keputusan kelangsungan bisnis

Untuk menjaga kelangsungan bisnis, tentukan SLO untuk infrastruktur dan aplikasi Anda. Untuk informasi selengkapnya, lihat Recommendations untuk menentukan target keandalan. Tinjau ketentuan perjanjian tingkat layanan (SLA) untuk AKS dalam artikel SLA terbaru untuk layanan daring.

Simpul-simpul kluster

Untuk memenuhi tingkat ketersediaan minimum untuk beban kerja, Anda memerlukan beberapa simpul dalam kumpulan simpul. Jika node gagal, simpul lain di kumpulan simpul dan kluster yang sama dapat terus menjalankan aplikasi. Untuk keandalan, kami merekomendasikan tiga simpul untuk kumpulan simpul sistem. Untuk kumpulan simpul pengguna, mulailah dengan tidak kurang dari dua simpul. Jika Anda memerlukan ketersediaan atau kapasitas yang lebih tinggi, tingkatkan jumlah node untuk menambahkan lebih banyak simpul.

Isolasi aplikasi Anda dari layanan sistem dengan menempatkannya di kumpulan simpul terpisah, yang disebut sebagai kumpulan simpul pengguna. Dengan cara ini, layanan Kubernetes berjalan pada node khusus dan tidak bersaing dengan layanan lain. Kami menyarankan agar Anda menggunakan tag, label, dan taint untuk mengidentifikasi kumpulan simpul dan menjadwalkan beban kerja Anda. Pastikan bahwa kumpulan simpul sistem Anda diberi taint CriticalAddonsOnly untuk mencegah pod aplikasi dijadwalkan pada kumpulan simpul sistem.

Tugas upkeep reguler pada kluster Anda, seperti pembaruan tepat waktu, sangat penting untuk keandalan. Selain itu, kami sarankan Anda memantau kesehatan pod melalui pemeriksaan.

Ketersediaan pod

Tentukan persyaratan sumber daya pod: Kami menyarankan agar Anda menentukan persyaratan sumber daya pod dalam penyebaran Anda. Penjadwal kemudian dapat menjadwalkan pod dengan tepat. Keandalan akan berkurang drastis jika pod Anda tidak bisa dijadwalkan.
Atur anggaran gangguan pod: Pengaturan ini menentukan berapa banyak replika dalam penyebaran yang dapat turun selama peristiwa pembaruan atau peningkatan. Untuk informasi selengkapnya, lihat anggaran gangguan untuk Pod.

Konfigurasikan beberapa replika dalam penyebaran untuk menangani gangguan seperti kegagalan perangkat keras. Untuk peristiwa yang direncanakan seperti pembaruan dan peningkatan, anggaran gangguan dapat membantu memastikan jumlah replika pod yang diperlukan ada untuk menangani beban aplikasi yang diharapkan.
Atur kuota sumber daya pada namespace beban kerja: Kuota sumber daya pada namespace membantu memastikan bahwa permintaan dan batas pod diatur dengan benar pada penyebaran. Untuk informasi selengkapnya, lihat Berlakukan kuota sumber daya.

Note

Jika Anda mengatur kuota sumber daya di tingkat kluster, masalah dapat terjadi jika Anda menyebarkan beban kerja eksternal yang tidak memiliki permintaan dan batas yang tepat. Saat Anda mengatur kuota di tingkat namespace, ini memastikan bahwa kuota hanya berlaku untuk komponen beban kerja Anda.
Atur permintaan dan batasan pod: Atur permintaan dan batasan untuk memungkinkan Kubernetes mengalokasikan sumber daya CPU dan memori secara efisien ke pod. Ini memberi Anda kepadatan kontainer yang lebih tinggi pada simpul. Permintaan dan batasan juga dapat meningkatkan keandalan Anda sekaligus mengurangi biaya Anda karena penggunaan perangkat keras yang lebih baik.

Untuk memperkirakan batas beban kerja, uji dan buat garis besar. Mulailah dengan nilai yang sama untuk permintaan dan batas. Kemudian secara bertahap sesuaikan nilai-nilai tersebut sampai Anda menetapkan ambang batas yang menyebabkan ketidakstabilan dalam kluster.

Anda dapat menentukan permintaan dan batasan dalam manifes penyebaran Anda. Untuk informasi selengkapnya, lihat Set permintaan dan batas pod.

Zona Ketersediaan

Untuk melindungi dari beberapa jenis pemadaman, gunakan availability zones jika wilayah mendukungnya. Komponen sarana kontrol dan simpul di kumpulan simpul kemudian redundan zona, yang berarti tersebar di beberapa zona. Jika seluruh zona tidak tersedia, node di zona lain di dalam wilayah masih tersedia. Setiap pool node dipetakan ke dalam set skala mesin virtual yang terpisah, yang mengelola instans node dan skalabilitas. Layanan AKS mengelola operasi dan konfigurasi himpunan skala. Berikut adalah beberapa pertimbangan saat Anda mengaktifkan beberapa zona:

Entire infrastructure: Pilih wilayah yang mendukung zona ketersediaan. Untuk informasi selengkapnya, lihat Limitations. Untuk memiliki SLA uptime, Anda perlu memilih level Standar atau Premium. Waktu aktif SLA lebih besar saat Anda menggunakan availability zones.
Cluster: Anda hanya dapat mengatur zona ketersediaan saat membuat node pool. Mereka tidak bisa diubah nanti. Ukuran node harus didukung di semua zona sehingga memungkinkan distribusi yang diharapkan. Set skala mesin virtual yang mendasari menyediakan konfigurasi perangkat keras yang sama di seluruh zona.

Redundansi zona tidak hanya diterapkan pada kumpulan simpul, tetapi juga pesawat kontrol. Bidang kendali AKS mencakup zona yang diminta, seperti halnya kumpulan simpul. Jika Anda tidak menggunakan dukungan zona di kluster Anda, komponen sarana kontrol tidak dijamin tersebar di zona ketersediaan.
Sumber daya yang bergantung: Untuk mencapai manfaat ketahanan dengan menggunakan zona ketersediaan, semua dependensi layanan juga harus mendukung zona tersebut. Jika layanan dependen tidak mendukung zona, ada kemungkinan bahwa kegagalan zona dapat menyebabkan layanan tersebut gagal.

Misalnya, beban kerja Anda menggunakan database yang tidak tahan zona. Jika kegagalan terjadi, simpul AKS mungkin berpindah ke zona lain, tetapi database tidak berpindah dengan simpul ke zona tersebut, sehingga beban kerja Anda terganggu.

Untuk kesederhanaan dalam arsitektur ini, AKS disebarkan ke satu wilayah dan kumpulan simpul yang mencakup tiga zona ketersediaan. Sumber daya infrastruktur lainnya, seperti Azure Firewall dan Application Gateway, juga disebarkan ke wilayah yang sama dengan dukungan beberapa zona. Replikasi geografis diaktifkan untuk Container Registry.

Beberapa wilayah

Ketika Anda mengaktifkan availability zones, cakupan ini tidak cukup memadai jika seluruh wilayah mengalami kegagalan. Untuk mendapatkan ketersediaan yang lebih tinggi, jalankan beberapa kluster AKS di berbagai wilayah.

Lebih memilih wilayah berpasangan saat tersedia. Manfaat menggunakan wilayah berpasangan adalah keandalan selama pembaruan platform. Azure memastikan bahwa hanya satu wilayah dalam pasangan yang diperbarui pada satu saat. Beberapa wilayah tidak memiliki pasangan. Jika wilayah Anda tidak dipasangkan, Anda masih dapat menyebarkan solusi multi-wilayah dengan memilih wilayah lain untuk digunakan. Pertimbangkan untuk menggunakan alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD), yang Anda konfigurasi untuk mengatur pemulihan dari kegagalan wilayah. Alat DevOps tertentu seperti Flux dapat mempermudah penyebaran multi-wilayah.
Berikan lokasi di mana layanan redundan memiliki instans sekunder jika sumber daya Azure mendukung geo-redundansi. Misalnya, dengan mengaktifkan replikasi geografis untuk Container Registry, replikasi gambar secara otomatis ke wilayah Azure yang dipilih. Ini juga menyediakan akses berkelanjutan ke gambar, bahkan jika wilayah utama mengalami pemadaman.
Pilih router lalu lintas yang dapat mendistribusikan lalu lintas melintasi zona atau wilayah, tergantung pada kebutuhan Anda. Arsitektur ini menyebarkan Load Balancer karena dapat mendistribusikan lalu lintas nonweb di seluruh zona. Jika Anda perlu mendistribusikan lalu lintas di seluruh wilayah, pertimbangkan Azure Front Door. Untuk opsi lain, lihat Pilih Load Balancer.

Note

Garis besar AKS untuk skenario contoh kluster multiregion memperluas arsitektur dalam artikel ini untuk menyertakan beberapa wilayah dalam konfigurasi aktif-aktif dan sangat tersedia.

Pemulihan bencana

Idealnya, jika kegagalan terjadi di wilayah utama, Anda dapat dengan cepat beralih ke instans di wilayah lain. Anda mungkin membuat kluster terlebih dahulu atau menunggu untuk membuatnya hingga diperlukan. Pertimbangkan rekomendasi berikut:

Gunakan beberapa wilayah. Jika wilayah utama Anda memiliki wilayah berpasangan, gunakan wilayah berpasangan tersebut. Jika tidak, pilih wilayah berdasarkan persyaratan residensi dan latensi data Anda.
Gunakan beban kerja nonstateful yang dapat Anda replikasi secara efisien. Jika Anda harus menyimpan status di dalam kluster, yang tidak kami rekomendasikan, pastikan Anda sering mencadangkan data di wilayah lain.
Integrasikan strategi pemulihan, seperti mereplikasi ke wilayah lain, sebagai bagian dari alur DevOps untuk memenuhi SLO Anda.
Siapkan setiap layanan Azure dengan menggunakan fitur yang mendukung pemulihan bencana. Misalnya, dalam arsitektur ini, Container Registry diaktifkan untuk replikasi geografis. Jika suatu wilayah mengalami kegagalan, failover berbasis kesehatan ACR secara otomatis mengarahkan ulang permintaan pull ke replika yang sehat melalui endpoint global tanpa memerlukan perubahan pada konfigurasi kluster Anda.
Sebarkan infrastruktur Anda sebagai kode, termasuk kluster AKS Anda dan komponen lain yang Anda butuhkan. Jika Anda perlu menyebarkan ke wilayah lain, Anda dapat menggunakan kembali skrip atau templat untuk membuat instans yang identik.

Pencadangan kluster

Untuk banyak arsitektur, Anda dapat menyiapkan kluster baru dan mengembalikannya ke status operasi melalui bootstrapping kluster berbasis GitOps, diikuti oleh penyebaran aplikasi. Tetapi jika ada status sumber daya penting, seperti peta konfigurasi, pekerjaan, dan rahasia yang tidak dapat ditangkap dalam proses bootstrapping Anda, pertimbangkan strategi pemulihan Anda. Kami menyarankan agar Anda menjalankan beban kerja stateless di Kubernetes. Jika arsitektur Anda melibatkan status berbasis disk, Anda juga harus mempertimbangkan strategi pemulihan Anda untuk konten tersebut.

Ketika pencadangan kluster harus menjadi bagian dari strategi pemulihan Anda, Anda harus menginstal solusi yang sesuai dengan persyaratan bisnis Anda dalam kluster. Agen ini bertanggung jawab untuk mendorong status sumber daya kluster ke tujuan pilihan Anda dan mengoordinasikan cuplikan volume persisten berbasis disk Azure.

VMware Velero adalah contoh solusi cadangan Kubernetes umum yang dapat Anda instal dan kelola secara langsung. Atau Anda dapat menggunakan ekstensi pencadangan AKS untuk menyediakan implementasi Velero terkelola. Ekstensi cadangan AKS mendukung pencadangan sumber daya Kubernetes dan volume persisten, dengan jadwal dan cakupan cadangan yang diekstersterisasi sebagai konfigurasi vault di Azure Backup.

Implementasi referensi tidak menerapkan pencadangan, yang melibatkan sumber daya Azure tambahan untuk mengelola, memantau, membeli, dan mengamankan. Sumber daya ini mungkin mencakup akun Azure Storage, brankas dan konfigurasi Azure Backup, dan fitur akses percaya. Sebagai gantinya, GitOps dikombinasikan dengan niat untuk menjalankan beban kerja tanpa status adalah solusi pemulihan.

Pilih dan validasi solusi cadangan yang memenuhi tujuan bisnis Anda, yang mencakup tujuan titik pemulihan dan tujuan waktu pemulihan yang ditentukan. Tentukan prosedur pemulihan Anda dalam panduan operasi tim dan praktikkan untuk semua beban kerja yang kritis bagi bisnis.

Jika Anda harus mendukung beban kerja stateful dan mengadopsi AKS Backup, gunakan Azure Policy untuk memastikan pencadangan dikonfigurasi pada kluster Anda. Azure Monitor menyajikan status kesehatan tugas pencadangan melalui tumpukan observabilitas yang sama yang telah diterapkan dalam arsitektur ini. Di luar tata kelola tersebut, perhitungkan pertimbangan arsitektur berikut dalam desain Anda:

Cakupan cadangan. Tentukan apakah Anda mencadangkan seluruh kluster atau namespace tertentu. AKS Backup menyimpan data di kontainer blob dan sebagai snapshot disk atau file. Tentukan cakupan ini lebih awal karena menentukan ukuran akun penyimpanan, kebijakan retensi, dan granularitas pemulihan Anda untuk skenario seperti pemulihan operasional, kloning lingkungan, dan peningkatan kluster.
Akses tepercaya. Cadangan AKS memerlukan akses tepercaya antara vault Backup dan kluster AKS, terlepas dari apakah kluster tersebut publik, privat, atau dibatasi IP.
Hak akses RBAC. Identitas terkelola brankas Backup memerlukan serangkaian izin pada kluster AKS untuk mengonfigurasi dan menjalankan pencadangan. Ekstensi cadangan juga membuat identitas pengguna dengan izin pada akun penyimpanan tempat cadangan disimpan.
Keluar jaringan. Ekstensi cadangan berkomunikasi dengan layanan Azure Backup dari dalam kluster. Perhitungkan endpoint keluar yang diperlukan dalam aturan Azure Firewall dan NSG Anda.
Jejak dalam kluster. Ekstensi menempatkan pod pada node Anda. Rencanakan penggunaan komputasi dan memori tambahan dalam anggaran sumber daya simpul Anda, dan sertakan namespace ekstensi dalam tata kelola kebijakan jaringan Anda.

Kubernetes API server Perjanjian Tingkat Layanan (SLA)

Anda dapat menggunakan AKS sebagai layanan gratis, tetapi tingkat tersebut tidak menyediakan SLA yang didukung secara finansial. Untuk mendapatkan SLA, Anda harus memilih tingkat Standard. Kami menyarankan agar semua kluster produksi menggunakan tingkat Standar. Pesan lapisan Gratis untuk kluster praproduksi, dan lapisan Premium untuk beban kerja yang sangat penting saja. Saat Anda menggunakan zona ketersediaan Azure, SLA server API Kubernetes lebih tinggi. Kumpulan simpul Anda dan sumber daya lainnya tercakup dalam SLA mereka masing-masing.

Untuk informasi selengkapnya tentang SLA tertentu untuk setiap layanan, lihat SLA untuk layanan online.

Kompromi

Ada trade-off antara biaya dan ketersediaan untuk menerapkan arsitektur di berbagai zona dan terutama di berbagai wilayah. Beberapa fitur replikasi, seperti replikasi geografis di Container Registry, tersedia dalam SKU premium, yang lebih mahal. Untuk penyebaran multi-wilayah, biaya juga meningkat karena biaya bandwidth berlaku saat lalu lintas berpindah lintas wilayah.

Selain itu, harapkan sedikit latensi jaringan tambahan dalam komunikasi simpul antar zona, dan latensi komunikasi yang lebih signifikan di antar wilayah. Ukur efek keputusan arsitektur ini pada beban kerja Anda.

Uji dengan simulasi dan failover paksa

Uji keandalan solusi Anda melalui pengujian failover paksa dengan pemadaman yang disimulasikan. Simulasi dapat mencakup menghentikan simpul, menurunkan semua sumber daya AKS di zona tertentu untuk mensimulasikan kegagalan zona, atau memanggil kegagalan dependensi eksternal. Anda juga dapat menggunakan Azure Chaos Studio untuk mensimulasikan berbagai jenis pemadaman di Azure dan pada kluster.

Untuk informasi selengkapnya, lihat Chaos Studio.

Memantau dan mengumpulkan log dan metrik

Kami merekomendasikan layanan pemantauan Azure Monitor Kubernetes untuk memantau performa beban kerja kontainer karena Anda dapat melihat peristiwa secara real time. Azure Monitor mengambil log kontainer dari pod yang sedang berjalan dan menggabungkannya untuk dilihat. Ini juga mengumpulkan informasi dari API metrik tentang memori dan penggunaan CPU untuk memantau kesehatan sumber daya dan beban kerja yang berjalan. Anda juga dapat menggunakan Azure Monitor untuk memantau kinerja saat pod diskalakan. Ini termasuk telemetri yang penting untuk pemantauan, analisis, dan visualisasi data yang dikumpulkan.

Mengaktifkan pengumpulan log dari pod

Skema log ContainerLogV2 dirancang untuk mengambil log kontainer dari pod Kubernetes dalam pendekatan yang disederhanakan. Entri log dikonsolidasikan ke dalam tabel ContainerLogV2 di ruang kerja Azure Log Analytics.

Dalam kluster AKS, ada dua metode utama untuk mengonfigurasi pengumpulan log pod. Kedua pendekatan memungkinkan Anda menyesuaikan pengaturan. Anda dapat memfilter namespace, menyesuaikan interval koleksi, mengaktifkan atau melarang fitur tertentu (seperti ContainerLogV2 atau ContainerLogV2-HighScale), dan menentukan aliran data mana yang akan dikumpulkan.

Jika Anda memerlukan konfigurasi pemantauan terpusat dan dapat digunakan kembali di beberapa kluster atau lebih memilih konfigurasi kluster untuk diekstersterisasi dalam sumber daya asli Azure, gunakan aturan pengumpulan data (DCR). DCR adalah sumber daya Azure yang dikelola sarana kontrol Azure Resource Manager secara asli, dan Anda dapat menyertakannya dalam file Bicep. Implementasi referensi menggunakan DCR.
Atau, Anda dapat menentukan pemantauan dengan menggunakan ConfigMaps, yang merupakan objek YAML Kubernetes nonkonfidensial yang dikonfigurasi melalui sarana kontrol API Kubernetes. Agen Azure Monitor yang berjalan pada monitor kluster untuk objek ConfigMap. Ini menggunakan pengaturan yang telah ditentukan sebelumnya untuk menentukan data mana yang akan dikumpulkan.

Ketika kedua metode diaktifkan, pengaturan ConfigMap lebih diutamakan daripada DCR. Hindari mencampur konfigurasi ConfigMap dan DCR untuk pengumpulan log kontainer, karena dapat mengakibatkan masalah pengelogan yang sulit di memecahkan masalah.

Pemberitahuan dan metrik Prometheus

Pemadaman dan kerusakan menimbulkan risiko signifikan terhadap aplikasi beban kerja, yang membuatnya penting untuk secara proaktif mengidentifikasi masalah yang terkait dengan kesehatan dan performa infrastruktur Anda. Saat memantau lingkungan dan bertindak berdasarkan apa yang Anda pelajari, Anda mengurangi gangguan dan meningkatkan keandalan solusi Anda. Untuk mengantisipasi potensi kondisi kegagalan di kluster Anda, aktifkan tetapan pemberitahuan Prometheus yang direkomendasikan untuk Kubernetes.

Sebagian besar beban kerja yang dihosting dalam pod memancarkan metrik Prometheus. Azure Monitor dapat berintegrasi dengan Prometheus. Anda dapat melihat metrik aplikasi dan beban kerja yang dikumpulkan dari kontainer, pod, simpul, dan kluster.

Beberapa solusi non-Microsoft terintegrasi dengan Kubernetes, seperti Datadog, Grafana, atau New Relic. Jadi, jika organisasi Anda sudah menggunakan solusi ini, Anda dapat memanfaatkannya.

Azure infrastruktur dan log sarana kontrol Kube

Dengan AKS, Azure mengelola beberapa layanan inti Kubernetes. Azure mengimplementasikan log untuk komponen sarana kontrol AKS sebagai log resource. Opsi ini dapat membantu Anda memecahkan masalah kluster, dan memiliki kepadatan log yang relatif rendah. Kami menyarankan agar Anda mengaktifkan opsi berikut pada sebagian besar kluster:

ClusterAutoscaler: Dapatkan observabilitas ke dalam operasi penskalaan melalui pencatatan log. Untuk informasi selengkapnya, lihat Mengambil catatan dan status kluster autoscaler.
KubeControllerManager: Peroleh visibilitas terhadap interaksi antara Kubernetes dan control plane Azure.
kube-audit-admin: Dapatkan penglihatan terhadap aktivitas yang memodifikasi kluster Anda. Tidak perlu mengaktifkan baik kube-audit maupun kube-audit-admin karena kube-audit adalah superset yang juga mencakup operasi nonmodifikasi (baca).
guard: Mencatat audit Microsoft Entra ID dan RBAC Azure.

Mungkin berguna bagi Anda untuk mengaktifkan kategori log lain, seperti KubeScheduler atau kube-audit, selama kluster awal atau pengembangan siklus hidup beban kerja. Penambahan penskalaan otomatis kluster, penempatan dan penjadwalan pod, serta data terkait dapat membantu Anda mengatasi kekhawatiran operasi kluster atau beban kerja. Tetapi jika Anda menyimpan log pemecahan masalah yang diperluas pada waktu penuh setelah kebutuhan pemecahan masalah berakhir, Anda mungkin dikenakan biaya yang tidak perlu untuk menyerap dan menyimpan data dalam Azure Monitor.

Azure Monitor menyertakan sekumpulan kueri log yang ada untuk memulai, tetapi Anda juga dapat menggunakannya sebagai fondasi untuk membantu membangun kueri Anda sendiri. Seiring bertambahnya pustaka, Anda dapat menyimpan dan menggunakan kembali kueri log dengan menggunakan satu atau beberapa paket query. Pustaka kueri kustom Anda memberikan pengamatan yang lebih besar ke dalam kesehatan dan performa kluster AKS Anda. Ini mendukung pencapaian SLA Anda.

Untuk informasi selengkapnya tentang memantau praktik terbaik untuk AKS, lihat Monitor AKS dengan Azure Monitor.

Metrik jaringan

Metrik jaringan tingkat kluster dasar tersedia melalui metrik platform dan Prometheus asli. Anda selanjutnya dapat menggunakan metrik jaringan AKS node untuk mengekspos metrik jaringan di tingkat simpul dengan menggunakan metrik Prometheus. Sebagian besar kluster harus mencakup pengamatan jaringan untuk menyediakan kemampuan pemecahan masalah jaringan tambahan dan untuk mendeteksi penggunaan atau masalah jaringan yang tidak terduga di tingkat node.

Implementasi referensi menggunakan Azure Monitor, yang juga mengumpulkan beberapa metrik terkait jaringan. Implementasi referensi melarang secara langsung mengumpulkan beberapa metrik jaringan dari Azure Monitor, dan sebaliknya mengumpulkan metrik observabilitas jaringan dengan menggunakan ruang kerja Azure Monitor dengan managed Prometheus.

Untuk beban kerja yang sangat sensitif terhadap kehilangan paket Protokol Kontrol Transmisi (TCP) atau Protokol Datagram Pengguna (UDP), latensi, atau tekanan DNS, beberapa metrik jaringan pada tingkat pod sangat penting. Di AKS, Anda dapat mengakses metrik terperinci ini melalui fitur Advanced Container Networking Services. Sebagian besar beban kerja tidak memerlukan kedalaman pengamatan jaringan ini. Anda tidak boleh mengaktifkan observabilitas jaringan tingkat lanjut kecuali pod Anda memerlukan jaringan yang sangat dioptimalkan, dengan sensitivitas hingga tingkat paket.

Pengoptimalan biaya untuk pengelogan

Implementasi referensi mengonfigurasi tabel ContainerLogV2 untuk menggunakan paket Dasar sebagai titik awal. Microsoft Defender untuk Kontainer dan peringatan yang dibuat untuk implementasi referensi tidak mengkueri tabel ini, oleh karena itu, paket Dasar kemungkinan besar lebih hemat biaya karena mengurangi biaya pengambilan data.

Seiring berkembangnya volume log dan persyaratan kueri Anda, pilih paket tabel yang paling hemat biaya untuk kebutuhan Anda. Jika solusi menjadi baca intensif, di mana kueri sering memindai data tabel, paket Analitik default mungkin lebih cocok. Rencana Analitik menghilangkan biaya kueri, yang mengoptimalkan skenario di mana aktivitas kueri melebihi biaya pengolahan data. Saat Anda memantau pola penggunaan dan menyesuaikan rencana tabel sesuai kebutuhan, Anda dapat mencapai keseimbangan antara biaya dan fungsionalitas untuk solusi pemantauan Anda.

Untuk informasi selengkapnya, lihat Pilih paket tabel berdasarkan penggunaan data di ruang kerja Log Analytics.

Mengaktifkan penyembuhan diri

Pantau kesehatan pod dengan mengatur pemeriksaan keaktifan dan kesiapan. Jika Kubernetes mendeteksi pod yang tidak responsif, Kubernetes akan memulai ulang pod. Pemeriksaan keaktifan menentukan apakah pod sehat. Jika Kubernetes mendeteksi pod yang tidak responsif, Kubernetes akan memulai ulang pod. Pemeriksaan kesiapan menentukan apakah pod siap menerima permintaan dan lalu lintas.

Note

AKS memiliki fitur perbaikan simpul automatik yang menyediakan penyembuhan mandiri bawaan untuk simpul infrastruktur.

Pembaruan rutin untuk kluster AKS

Bagian dari operasi hari ke-2 untuk kluster Kube adalah melakukan pembaruan platform dan sistem operasi rutin. Ada tiga lapisan pembaruan untuk ditangani pada setiap kluster AKS:

Versi Kubernetes (seperti Kubernetes 1.32.3 hingga 1.32.7 atau Kubernetes 1.32.7 hingga 1.33.1), yang mungkin mencakup perubahan dan penghentian penggunaan API Kubernetes. Perubahan versi pada lapisan ini memengaruhi seluruh kluster.
Gambar hard disk virtual (VHD) pada setiap simpul, yang menggabungkan pembaruan sistem operasi dan pembaruan komponen AKS. Pembaruan ini diuji terhadap versi Kubernetes kluster. Perubahan versi pada lapisan ini diterapkan pada tingkat kumpulan simpul dan tidak memengaruhi versi Kubernetes.
Proses pembaruan asli sistem operasi sendiri, seperti Windows Update atau apt. Vendor sistem operasi menyediakan pembaruan ini secara langsung dan tidak diuji terhadap versi Kubernetes kluster. Perubahan versi pada lapisan ini memengaruhi satu simpul dan tidak memengaruhi versi Kubernetes.

Masing-masing lapisan ini dikontrol secara independen. Anda memutuskan bagaimana setiap lapisan ditangani untuk kluster beban kerja Anda. Pilih seberapa sering setiap kluster AKS, kumpulan simpulnya, atau nodenya diperbarui ( iramanya). Selain itu, pilih hari atau waktu apa untuk menerapkan pembaruan ( jendela pemeliharaan Anda). Pilih apakah pembaruan diinstal secara manual atau otomatis atau tidak sama sekali. Sama seperti beban kerja yang berjalan pada kluster Anda memerlukan praktik penyebaran yang aman, jadi lakukan pembaruan pada kluster Anda.

Untuk perspektif yang lebih menyeluruh tentang panduan pembaruan dan peningkatan, lihat panduan patch dan peningkatan AKS dalam panduan operasi hari-2 AKS. Gunakan informasi berikut untuk rekomendasi garis besar karena berkaitan dengan arsitektur ini.

Infrastruktur yang tidak dapat diubah

Beban kerja yang mengoperasikan kluster AKS sebagai infrastruktur yang tidak dapat diubah tidak secara otomatis atau manual memperbarui kluster mereka. Atur peningkatan citra node ke none dan peningkatan otomatis kluster ke none. Dalam konfigurasi ini, Anda bertanggung jawab sepenuhnya atas semua peningkatan di semua lapisan.

Saat pembaruan yang Anda inginkan tersedia, Anda harus melakukan langkah-langkah berikut:

Uji pembaruan di lingkungan praproduksi dan evaluasi kompatibilitasnya pada kluster baru.
Sebarkan stempel replika produksi yang menyertakan versi AKS dan VHD kumpulan simpul yang diperbarui.
Ketika kluster produksi baru siap, kosongkan kluster lama dan akhirnya nonaktifkan.

Infrastruktur yang tidak dapat diubah dengan penyebaran reguler infrastruktur baru adalah satu-satunya situasi di mana kluster produksi tidak boleh memiliki strategi peningkatan di tempat yang diterapkan padanya. Semua kluster lain harus memiliki strategi peningkatan di tempat.

Peningkatan in-situ

Beban kerja yang tidak mengoperasikan kluster AKS sebagai infrastruktur yang tidak dapat diubah harus memperbarui kluster yang sedang berjalan secara teratur untuk mengatasi ketiga lapisan tersebut. Menyelaraskan proses pembaruan Anda dengan persyaratan beban kerja Anda. Gunakan rekomendasi berikut sebagai titik awal untuk merancang proses pembaruan rutin Anda.

Jadwalkan fitur pemeliharaan yang direncanakan AKS sehingga Anda dapat mengontrol peningkatan pada kluster Anda. Fitur ini memungkinkan Anda melakukan pembaruan, operasi yang berisiko secara inheren, pada waktu yang dikontrol untuk mengurangi efek kegagalan yang tidak terduga.
Konfigurasikan kuota gangguan pod sehingga aplikasi Anda tetap stabil selama upgrade bergulir. Tetapi jangan mengonfigurasi anggaran agar terlalu agresif sehingga memblokir peningkatan node dari pelaksanaan, karena sebagian besar peningkatan memerlukan proses cordon dan draining pada setiap simpul.
Konfirmasi kuota sumber daya Azure dan ketersediaan sumber daya. Peningkatan langsung menerapkan instans baru dari node, yang dikenal sebagai node tambahan, sebelum node lama dihapus. Ini berarti kuota Azure dan ruang alamat IP harus tersedia untuk node baru. Nilai lonjakan 33% merupakan titik awal yang baik untuk kebanyakan beban kerja.
Uji kompatibilitas dengan perangkat, seperti service mesh atau agen keamanan yang Anda tambahkan ke kluster Anda. Selain itu, uji komponen beban kerja Anda, seperti pengontrol ingress, jala layanan, dan pod beban kerja Anda. Jalankan pengujian di lingkungan praproduksi.

Peningkatan langsung untuk node

Gunakan saluran peningkatan otomatis NodeImage untuk peningkatan citra OS node. Saluran ini mengonfigurasi kluster Anda untuk memperbarui VHD di setiap simpul dengan pembaruan di tingkat simpul. Microsoft menguji pembaruan terhadap versi AKS Anda. Untuk simpul Windows, pembaruan terjadi sekitar sekali per bulan. Untuk simpul Linux, pembaruan terjadi sekitar sekali per minggu.

Peningkatan tidak pernah mengubah versi AKS atau Kubernetes Anda, sehingga kompatibilitas API Kubernetes tidak menjadi perhatian.
Ketika Anda menggunakan NodeImage sebagai saluran peningkatan, itu menghormati jendela pemeliharaan terencana Anda, yang harus Anda tetapkan setidaknya sekali per minggu. Atur tidak peduli sistem operasi citra node yang Anda gunakan untuk membantu memastikan pembaruan diterapkan tepat waktu.
Pembaruan ini termasuk keamanan tingkat sistem operasi, kompatibilitas, dan pembaruan fungsi, pengaturan konfigurasi sistem operasi, dan pembaruan komponen AKS.
Rilis gambar dan nomor versi komponen yang disertakan dilacak dengan menggunakan pelacak rilis AKS.

Jika persyaratan keamanan untuk kluster Anda menuntut jadwal pemutakhiran yang lebih agresif dan kluster Anda dapat mentolerir potensi gangguan, disarankan untuk menggunakan saja SecurityPatch saluran peningkatan. Microsoft juga menguji pembaruan ini. Pembaruan hanya diterbitkan jika ada peningkatan keamanan yang Microsoft anggap cukup penting untuk dirilis sebelum peningkatan gambar simpul terjadwal berikutnya. Saat Anda menggunakan saluran SecurityPatch, Anda juga mendapatkan pembaruan yang diterima saluran NodeImage. Opsi SecurityPatch saluran masih mematuhi jendela pemeliharaan Anda, jadi pastikan jendela pemeliharaan Anda memiliki interval yang lebih sering (seperti setiap hari atau dua hari sekali) untuk mengakomodasi pembaruan keamanan yang tidak terduga ini.

Sebagian besar kluster yang melakukan peningkatan di tempat harus menghindari opsi saluran peningkatan gambar simpul None dan Unmanaged.

Pembaruan langsung untuk kluster

Kubernetes adalah platform yang berkembang pesat, dan pembaruan rutin menghadirkan perbaikan keamanan penting dan kemampuan baru. Penting bahwa Anda tetap terkini dengan pembaruan Kubernetes. Anda harus tetap berada dalam dua versi terbaru (N-2). Sangat penting untuk meningkatkan ke versi terbaru Kubernetes karena versi baru sering dirilis.

Sebagian besar kluster harus dapat melakukan pembaruan versi AKS secara langsung dengan kehati-hatian dan ketelitian yang cukup. Risiko melakukan peningkatan versi AKS di tempat sebagian besar dapat dimitigasi melalui pengujian praproduksi yang memadai, validasi kuota, dan konfigurasi anggaran gangguan pod. Tetapi peningkatan di tempat apa pun dapat mengakibatkan perilaku yang tidak terduga. Jika peningkatan di tempat dianggap terlalu berisiko untuk beban kerja Anda, kami sarankan Anda menggunakan penyebaran blue-green kluster AKS daripada mengikuti rekomendasi sisanya.

Sebaiknya hindari fitur peningkatan otomatis cluster saat pertama kali menyebarkan kluster Kubernetes. Gunakan pendekatan manual, yang memberi Anda waktu untuk menguji versi kluster AKS baru di lingkungan praproduksi Anda sebelum pembaruan mencapai lingkungan produksi Anda. Pendekatan ini juga mencapai tingkat prediksi dan kontrol terbesar. Tetapi Anda harus rajin memantau pembaruan baru ke platform Kubernetes, dan dengan cepat mengadopsi versi baru saat dirilis. Lebih baik mengadopsi pola pikir 'tetap terkini' daripada pendekatan dukungan jangka panjang.

Warning

Kami tidak merekomendasikan patching atau pembaruan kluster AKS produksi secara otomatis, bahkan dengan pembaruan versi minor, kecuali Anda menguji pembaruan tersebut di lingkungan yang lebih rendah terlebih dahulu. Untuk informasi selengkapnya, lihat Perbarui secara rutin ke versi terbaru Kubernetes dan Peningkatan kluster AKS.

Anda dapat menerima pemberitahuan saat versi AKS baru tersedia untuk kluster Anda dengan menggunakan sistem AKS untuk Azure Event Grid. Implementasi referensi memasang sistem Event Grid ini sehingga Anda dapat berlangganan peristiwa Microsoft.ContainerService.NewKubernetesVersionAvailable dari solusi pemberitahuan aliran peristiwa Anda. Tinjau catatan rilis AKS untuk masalah kompatibilitas tertentu, perubahan perilaku, atau penghentian fitur.

Akhirnya, Anda mungkin mencapai tingkat keyakinan dengan rilis Kubernetes, rilis AKS, kluster Anda, komponen-komponen di tingkat kluster, serta beban kerja, sehingga memungkinkan Anda menjelajahi fitur pembaruan otomatis. Untuk sistem produksi, jarang bergerak melampaui patch. Selain itu, ketika Anda secara otomatis meningkatkan versi AKS Anda, periksa pengaturan versi AKS di infrastruktur Anda sebagai kode (IaC) sehingga keduanya tidak tidak sinkron. Konfigurasikan jendela pemeliharaan terencana Anda untuk mendukung operasi peningkatan otomatis.

Pemantauan keamanan

Pantau infrastruktur kontainer Anda untuk ancaman aktif dan potensi risiko keamanan. Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Microsoft Defender untuk Kontainer mengidentifikasi dan memulihkan rekomendasi Defender untuk Cloud untuk gambar kontainer Anda.
Defender untuk Kontainer secara teratur memindai gambar kontainer Anda untuk kerentanan.
Defender untuk Kontainer juga menghasilkan pemberitahuan keamanan waktu nyata untuk aktivitas mencurigakan.
Konsep keamanan untuk aplikasi dan kluster di AKS merinci informasi tentang bagaimana keamanan kontainer melindungi seluruh alur end-to-end dari build ke beban kerja aplikasi yang berjalan di AKS.

Operasi kluster dan beban kerja

Untuk pertimbangan operasi kluster dan beban kerja (DevOps), lihat prinsip desain Operational Excellence pilar.

Inisialisasi Klaster

Setelah menyiapkan kluster, kluster tersebut adalah kluster yang berfungsi, tetapi Anda mungkin memiliki lebih banyak langkah yang harus dilakukan sebelum dapat menyebarkan beban kerja. Proses persiapan kluster Anda disebut bootstrapping. Bootstrapping sering terdiri dari menyebarkan image prasyarat ke node kluster, membuat namespace, dan melakukan tugas lain yang memenuhi persyaratan use case organisasi Anda.

Untuk mempercepat transisi dari kluster yang baru disiapkan ke kluster yang dikonfigurasi dengan benar, Anda harus menentukan proses bootstrapping unik Anda dan menyiapkan aset yang relevan terlebih dahulu. Misalnya, jika Anda menggunakan jala layanan seperti Linkerd atau Consul Connect, Anda biasanya menyebarkan jala sebelum beban kerja aplikasi dapat dijadwalkan. Sebelum menyiapkan kluster, Anda harus memvalidasi bahwa gambar jala layanan ada di registri kontainer yang dibuat sebelumnya. Validasi ini membantu mencegah penundaan atau kegagalan penyebaran.

Anda dapat mengonfigurasi proses bootstrapping dengan menggunakan salah satu metode berikut:

ekstensi GitOps Flux v2 untuk kluster
Pipelines
Konfigurasi mandiri dengan FLUX atau CD Argo, misalnya

Note

Salah satu metode ini berfungsi dengan topologi kluster apa pun, tetapi kami merekomendasikan ekstensi kluster GitOps Flux v2 untuk armada karena keseragaman dan tata kelola yang lebih mudah dalam skala besar. Ketika Anda hanya menjalankan beberapa kluster, GitOps mungkin terlalu kompleks. Anda mungkin memilih untuk mengintegrasikan proses ke dalam satu atau beberapa pipeline penerapan untuk memastikan bootstrapping terjadi. Gunakan metode yang paling selaras dengan tujuan organisasi dan tim Anda.

Salah satu keuntungan utama menggunakan ekstensi kluster GitOps Flux v2 untuk AKS adalah bahwa secara efektif tidak ada celah antara kluster yang disediakan dan kluster yang di-bootstrap. Ini mengatur lingkungan dengan fondasi manajemen yang solid ke depannya, dan juga mendukung penginkludsi bootstrapping sebagai templat sumber daya agar selaras dengan strategi IaC Anda.

Akhirnya, ketika Anda menggunakan ekstensi kluster GitOps Flux v2, kubectl tidak diperlukan untuk bagian mana pun dari proses bootstrapping. Anda dapat memesan akses berbasis kubectl untuk situasi perbaikan mendesak. Di antara template untuk definisi sumber daya Azure dan memulai manifest melalui ekstensi GitOps, Anda dapat melakukan semua aktivitas konfigurasi normal tanpa perlu menggunakan kubectl.

Mengisolasi tanggung jawab beban kerja

Bagi beban kerja berdasarkan tim dan jenis sumber daya untuk mengelola setiap bagian secara individual.

Mulailah dengan beban kerja dasar yang berisi komponen fundamental dan kembangkan lebih lanjut. Tugas awal adalah mengonfigurasi jaringan. Siapkan jaringan virtual untuk hub dan spoke, serta subnet di dalam jaringan tersebut. Misalnya, spoke memiliki subnet terpisah untuk kumpulan simpul sistem dan pengguna, sumber daya ingress, dan server API AKS privat. Sebarkan subnet untuk Azure Firewall di hub.

Tugas lain adalah mengintegrasikan beban kerja dasar dengan Microsoft Entra ID.

Menggunakan IaC

Pilih metode deklaratif idempoten daripada pendekatan imperatif, jika memungkinkan. Alih-alih menulis urutan perintah yang menentukan opsi konfigurasi, gunakan sintaks deklaratif yang menggambarkan sumber daya dan propertinya. Implementasi referensi menggunakan Bicep, tetapi Anda dapat memilih untuk menggunakan templat Terraform atau Azure Resource Manager (templat ARM) sebagai gantinya.

Pastikan untuk menyiapkan sumber daya sesuai kebijakan yang mengatur. Misalnya, saat Anda memilih ukuran VM, tetap berada dalam batasan biaya dan opsi zona ketersediaan agar sesuai dengan persyaratan aplikasi Anda. Anda juga dapat menggunakan Azure Policy untuk menegakkan kebijakan organisasi Anda untuk keputusan ini.

Jika Anda perlu menulis urutan perintah, gunakan Azure CLI. Perintah ini mencakup berbagai layanan Azure dan Anda dapat mengotomatiskannya melalui pembuatan skrip. Windows dan Linux mendukung Azure CLI. Opsi lintas platform lainnya adalah Azure PowerShell. Pilihan Anda tergantung pada set keterampilan pilihan Anda.

Simpan dan versi file skrip dan templat Anda di sistem kontrol sumber Anda.

Beban kerja CI/CD

Pipelines untuk alur kerja dan penyebaran harus dapat membangun dan menyebarkan aplikasi secara terus menerus. Pembaruan harus disebarkan dengan aman dan cepat serta dapat dikembalikan jika ada masalah.

Strategi penyebaran Anda perlu menyertakan alur pengiriman berkelanjutan yang andal dan otomatis. Sebarkan perubahan dalam gambar kontainer beban kerja Anda ke kluster secara otomatis.

Dalam arsitektur ini, GitHub Actions mengelola alur kerja dan penyebaran. Opsi populer lainnya termasuk Azure DevOps Services dan Jenkins.

Kluster CI/CD

Unduh file Visio untuk arsitektur ini.

Alih-alih menggunakan pendekatan imperatif seperti kubectl, gunakan alat yang secara otomatis menyinkronkan perubahan kluster dan repositori. Untuk mengelola alur kerja, seperti rilis versi baru dan validasi pada versi tersebut sebelum menyebarkan ke produksi, pertimbangkan alur GitOps.

Bagian penting dari alur CI/CD adalah memulai konfigurasi awal kluster yang baru dipersiapkan. Pendekatan GitOps berguna karena memungkinkan operator secara deklaratif menentukan proses bootstrapping sebagai bagian dari strategi IaC dan melihat konfigurasi yang tercermin dalam kluster secara otomatis.

Saat Anda menggunakan GitOps, agen disebarkan di kluster untuk memastikan bahwa status kluster dikoordinasikan dengan konfigurasi yang disimpan di repositori Git privat Anda. Salah satu agen tersebut adalah Flux, yang menggunakan satu atau beberapa operator dalam kluster untuk memicu penyebaran di dalam Kubernetes. Flux melakukan tugas-tugas berikut:

Memantau semua repositori yang dikonfigurasi
Mendeteksi perubahan konfigurasi baru
Memicu penyebaran
Memperbarui konfigurasi berjalan yang diinginkan berdasarkan perubahan tersebut

Anda juga dapat mengatur kebijakan yang mengatur bagaimana perubahan disebarkan.

Contoh diagram berikut menunjukkan cara mengotomatiskan konfigurasi kluster dengan GitOps dan Flux.

Unduh file Visio untuk arsitektur ini.

Pengembang menerapkan perubahan pada kode sumber, seperti file YAML konfigurasi, yang disimpan dalam repositori Git. Perubahan kemudian didorong ke server Git.
Flux berjalan dalam pod bersama beban kerja. Flux memiliki akses baca-saja ke repositori Git untuk memastikan bahwa Flux hanya menerapkan perubahan seperti yang diminta oleh pengembang.
Flux mengenali perubahan konfigurasi dan menerapkan perubahan tersebut dengan menggunakan perintah kubectl.
Pengembang tidak memiliki access langsung ke API Kubernetes melalui kubectl.

Anda dapat memiliki kebijakan cabang di server Git Anda sehingga beberapa pengembang kemudian dapat menyetujui perubahan melalui permintaan pull sebelum perubahan diterapkan pada produksi.

Meskipun Anda dapat mengonfigurasi GitOps dan Flux secara manual, kami merekomendasikan GitOps dengan ekstensi kluster Flux v2 untuk AKS.

Strategi penyebaran beban kerja dan kluster

Sebarkan perubahan apa pun , seperti komponen arsitektur, beban kerja, dan konfigurasi kluster, ke setidaknya satu kluster AKS praproduksi. Proses ini mensimulasikan perubahan dan mungkin mengidentifikasi masalah sebelum disebarkan ke produksi.

Jalankan pengujian dan validasi di setiap tahap sebelum Anda melanjutkan ke tahap berikutnya. Ini membantu memastikan bahwa Anda dapat mendorong pembaruan ke lingkungan produksi dengan cara yang sangat terkontrol dan meminimalkan gangguan dari masalah penyebaran yang tidak terduga. Penyebaran harus mengikuti pola yang sama dengan produksi, dengan menggunakan pipeline GitHub Actions atau operator Flux yang sama.

Teknik penyebaran tingkat lanjut, seperti penyebaran biru-hijau, pengujian A/B, dan rilis kenari, memerlukan proses tambahan dan alat yang berpotensi ekstra. Flagger adalah solusi sumber terbuka populer untuk membantu menyelesaikan skenario penyebaran tingkat lanjut.

Manajemen biaya

Mulailah dengan meninjau daftar periksa desain pengoptimalan biaya dan daftar rekomendasi yang diuraikan dalam Well-Architected Framework untuk AKS. Untuk rekomendasi beban kerja umum, lihat daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

Anda dapat menemukan perkiraan biaya untuk komponen yang digunakan dalam arsitektur garis besar ini dalam kalkulator harga Azure. Ubah perkiraan Anda untuk menyertakan komponen yang diperlukan untuk kasus penggunaan Anda. Estimasi ini mencakup sumber daya pada tingkat spoke yang terkait langsung dengan klaster. Infrastruktur hub bersama, seperti Azure Firewall, jaringan virtual hub, dan zona Azure Private DNS, tidak disertakan karena sumber daya tersebut biasanya dimiliki dan dikelola oleh tim platform pusat.

Pertimbangkan untuk menggunakan analisis biaya AKS untuk alokasi biaya infrastruktur kluster terperinci oleh konstruksi khusus Kubernetes.

Provision

Pahami dari mana biaya Anda berasal. Ada biaya minimal yang terkait dengan AKS dalam penyebaran, manajemen, dan operasi kluster Kubernetes itu sendiri. Apa yang memengaruhi biaya adalah instans VM, storage, data log, dan sumber daya jaringan yang digunakan oleh kluster. Pertimbangkan untuk memilih VM yang lebih murah untuk kumpulan node sistem. Seri Ddv5 adalah jenis VM umum untuk kumpulan simpul sistem, dan implementasi referensi menggunakan SKU Standard_D2d_v5.
Jangan gunakan konfigurasi yang sama untuk lingkungan dev/test dan produksi. Beban kerja produksi memiliki persyaratan tambahan untuk ketersediaan tinggi dan biasanya lebih mahal. Konfigurasi ini tidak diperlukan di lingkungan dev/test.
Tambahkan SLA kestabilan operasional untuk beban kerja produksi. Tetapi ada penghematan untuk kluster yang dirancang untuk beban kerja pengembangan/pengujian atau eksperimental, di mana ketersediaannya tidak dijamin diperlukan. Misalnya, Sasaran Tingkat Layanan (SLO) Anda mungkin sudah memadai. Selain itu, jika beban kerja Anda mendukungnya, pertimbangkan untuk menggunakan kumpulan simpul spot khusus yang berjalan spot VM.

Untuk beban kerja nonproduksi yang menyertakan Azure SQL Database atau Azure App Service sebagai bagian dari arsitektur beban kerja AKS, evaluasi apakah Anda memenuhi syarat untuk menggunakan langganan Azure Dev/Test dan menerima diskon layanan.
Provisikan kluster dengan jumlah node minimum, dan aktifkan autoscaler kluster untuk memantau dan membuat keputusan ukuran alih-alih memulai dengan kluster yang terlalu besar untuk memenuhi kebutuhan penskalaan.
Atur permintaan dan batas pod untuk memungkinkan Kubernetes mengalokasikan sumber daya simpul dengan kepadatan yang lebih tinggi sehingga Anda menggunakan kapasitas penuh simpul.
Pertimbangkan bahwa ketika Anda mengaktifkan diagnostik pada kluster, itu dapat meningkatkan biaya.
Pilih Instans Komputer Virtual Azure Reservasi dengan komitmen satu atau tiga tahun untuk mengurangi biaya node jika beban kerja Anda perlu ada untuk jangka waktu yang lama. Untuk informasi selengkapnya, lihat Hemat biaya dengan Instans Mesin Virtual Cadangan Azure.
Gunakan tag saat Anda membuat kumpulan node. Tag membantu saat Anda membuat laporan kustom untuk melacak biaya yang dikeluarkan. Anda dapat menggunakan tag untuk melacak total pengeluaran dan memetakan biaya apa pun ke sumber daya atau tim tertentu. Jika kluster dibagikan antar tim, buat laporan penagihan balik untuk setiap pengguna untuk mengidentifikasi biaya terukur untuk layanan cloud yang digunakan bersama. Untuk informasi selengkapnya, lihat Specify taint, label, atau tag untuk kumpulan simpul.
Harapkan biaya bandwidth tambahan jika beban kerja Anda multi-wilayah dan Anda mereplikasi data antar wilayah. Untuk informasi lebih lanjut, lihat Harga Bandwidth.
Buat anggaran untuk tetap berada dalam batasan biaya yang diidentifikasi organisasi Anda. Anda dapat membuat anggaran melalui Microsoft Cost Management. Anda juga dapat membuat pemberitahuan untuk mendapatkan pemberitahuan saat ambang batas tertentu terlampaui. Untuk informasi selengkapnya, lihat Buat anggaran dengan menggunakan templat.

Monitor

Anda dapat memantau seluruh kluster dan biaya komputasi, storage, bandwidth, log, dan firewall. Azure menyediakan opsi berikut untuk memantau dan menganalisis biaya:

Pantau biaya Anda secara real time atau pada jadwal reguler sehingga Anda dapat mengambil tindakan sebelum akhir bulan, ketika biaya sudah dihitung. Pantau tren bulanan dari waktu ke waktu agar tetap sesuai anggaran.

Untuk membuat keputusan berbasis data, tentukan sumber daya mana, pada tingkat terperinci menimbulkan biaya paling besar. Selain itu, memiliki pemahaman yang baik tentang meteran yang menghitung penggunaan sumber daya. Misalnya, dengan menganalisis metrik, Anda dapat menentukan apakah platform terlalu besar. Anda dapat melihat pengukur penggunaan dalam metrik Azure Monitor.

Optimize

Ikuti rekomendasi dari Azure Advisor. Jelajahi cara lain untuk mengoptimalkan:

Aktifkan autoscaler kluster untuk mendeteksi dan menghapus simpul yang kurang digunakan di kumpulan simpul.

Important

Membuat perubahan yang cepat atau sering pada pengaturan autoscaler kluster, seperti jumlah simpul minimum dan maksimum untuk kumpulan simpul, untuk mengontrol biaya dapat menyebabkan hasil yang tidak diinginkan atau kontraproduktif. Misalnya, jika scale-down-unneeded-time diatur ke 10 menit, dan pengaturan node minimum dan maksimum dimodifikasi setiap 5 menit berdasarkan karakteristik beban kerja, jumlah simpul tidak pernah berkurang. Ini karena perhitungan waktu tak terpakai untuk setiap simpul diatur ulang ketika pengaturan autoscaler kluster disesuaikan.
Pilih SKU yang lebih rendah untuk kumpulan node, jika beban kerja Anda mendukungnya.
Jika aplikasi tidak memerlukan penskalaan ledakan, pertimbangkan untuk melakukan rightsizing kluster dengan menganalisis metrik performa dari waktu ke waktu.
Jika beban kerja Anda mendukungnya, atur ukuran simpul pengguna Anda ke nol simpul ketika tidak diperlukan untuk dijalankan. Jika tidak ada beban kerja yang dijadwalkan untuk dijalankan di kluster Anda, pertimbangkan untuk menggunakan fitur mulai/hentikan AKS untuk mematikan semua komputasi, yang mencakup kumpulan simpul sistem Anda dan sarana kontrol AKS.

Untuk informasi selengkapnya, lihat harga AKS.

Langkah selanjutnya

peta strategi AKS pada GitHub

Saran dan Komentar

Apakah halaman ini membantu?

Arsitektur garis besar untuk kluster Azure Kubernetes Service (AKS)

Konfigurasi Jaringan

Kluster komputasi

Pengelolaan identitas

Arus data aman

Kelangsungan bisnis

Operations

Architecture

Topologi jaringan

Hub jaringan virtual

Subnet untuk menghosting Azure Firewall

Jaringan lokal untuk menempatkan gateway

Subnet untuk menghosting Azure Bastion

Jaringan virtual Spoke

Subnet untuk hosting Azure Application Gateway

Subnet untuk menampung sumber daya ingress

Subnet untuk menghosting node kluster

Subnet untuk menghosting titik akhir Azure Private Link

Subnet untuk server API AKS

Merencanakan alamat IP

Ruang alamat IP jaringan virtual

Ruang alamat IP Pod

Pertimbangan ruang alamat IP lainnya

Fitur add-in dan fitur pratinjau

Referensi gambar kontainer

Mengonfigurasi komputasi untuk kluster dasar

Pilih sistem operasi

Mengintegrasikan Microsoft Entra ID untuk kluster

Akses AKS ke komponen Azure

Akses kluster

Kaitkan RBAC Kubernetes dengan Microsoft Entra ID

Gunakan RBAC Azure untuk otorisasi Kubernetes

Akun lokal

Mengintegrasikan Microsoft Entra ID untuk beban kerja

Pilih model jaringan

Menyebarkan sumber daya ingress

Pengaturan router

Mengamankan alur jaringan

Arus lalu lintas masuk

Arus lalu lintas keluar

Lalu lintas Pod-ke-Pod

Lalu lintas manajemen

Menambahkan manajemen rahasia

Akses data rahasia kluster

penyimpanan beban kerja

Manajemen kebijakan

Skalabilitas node dan pod

Horizontal Pod Autoscaler

Pengatur skala otomatis kluster

Keputusan kelangsungan bisnis

Simpul-simpul kluster

Ketersediaan pod

Zona Ketersediaan

Beberapa wilayah

Pemulihan bencana

Pencadangan kluster

Kubernetes API server Perjanjian Tingkat Layanan (SLA)

Kompromi

Uji dengan simulasi dan failover paksa

Memantau dan mengumpulkan log dan metrik

Mengaktifkan pengumpulan log dari pod

Pemberitahuan dan metrik Prometheus

Azure infrastruktur dan log sarana kontrol Kube

Metrik jaringan

Pengoptimalan biaya untuk pengelogan

Mengaktifkan penyembuhan diri

Pembaruan rutin untuk kluster AKS

Infrastruktur yang tidak dapat diubah

Peningkatan in-situ

Peningkatan langsung untuk node

Pembaruan langsung untuk kluster

Pemantauan keamanan

Operasi kluster dan beban kerja

Inisialisasi Klaster

Mengisolasi tanggung jawab beban kerja

Menggunakan IaC

Beban kerja CI/CD

Kluster CI/CD

Strategi penyebaran beban kerja dan kluster

Manajemen biaya