Ulasan Azure Well-Architected Framework - Azure Kubernetes Service (AKS)
Artikel ini menyediakan praktik terbaik arsitektur untuk Azure Kubernetes Service (AKS). Panduan ini didasarkan pada lima pilar keunggulan arsitektur:
- Keandalan
- Keamanan
- Pengoptimalan biaya
- Keunggulan operasional
- Efisiensi kinerja
Kami berasumsi bahwa Anda memahami prinsip desain sistem, memiliki pengetahuan kerja tentang Azure Kubernetes Service, dan berpengalaman dengan baik dengan fitur-fiturnya. Untuk informasi selengkapnya, lihat Azure Kubernetes Service.
Prasyarat
Memahami pilar Well-Architected Framework dapat membantu menghasilkan arsitektur cloud berkualitas tinggi, stabil, dan efisien. Sebaiknya tinjau beban kerja Anda dengan menggunakan penilaian Tinjauan Kerangka Kerja Azure Well-Architected.
Untuk konteks, pertimbangkan untuk meninjau arsitektur referensi yang mencerminkan pertimbangan ini dalam desainnya. Sebaiknya Anda mulai dengan arsitektur dasar untuk kluster Azure Kubernetes Service (AKS) dan arsitektur Layanan Mikro di Azure Kubernetes Service. Tinjau juga akselerator zona pendaratan AKS, yang menyediakan pendekatan arsitektur dan implementasi referensi untuk menyiapkan langganan zona pendaratan untuk kluster Azure Kubernetes Service (AKS) yang dapat diskalakan.
Keandalan
Di cloud, kami mengakui bahwa kegagalan terjadi. Alih-alih mencoba mencegah kegagalan secara bersamaan, tujuannya adalah untuk meminimalkan efek dari satu komponen yang gagal. Gunakan informasi berikut untuk meminimalkan instans yang gagal.
Saat membahas keandalan dengan Azure Kubernetes Service, penting untuk membedakan antara keandalan kluster dan keandalan beban kerja. Keandalan kluster adalah tanggung jawab bersama antara admin kluster dan penyedia sumber daya mereka, sementara keandalan beban kerja adalah domain pengembang. Azure Kubernetes Service memiliki pertimbangan dan rekomendasi untuk kedua peran ini.
Dalam daftar periksa desain dan daftar rekomendasi di bawah ini, callout dibuat untuk menunjukkan apakah setiap pilihan berlaku untuk arsitektur kluster, arsitektur beban kerja, atau keduanya.
Daftar periksa desain
- Arsitektur kluster: Untuk beban kerja penting, gunakan zona ketersediaan untuk kluster AKS Anda.
- Arsitektur kluster: Rencanakan ruang alamat IP untuk memastikan kluster Anda dapat menskalakan dengan andal, termasuk penanganan lalu lintas failover dalam topologi multi-kluster.
- Arsitektur kluster: Tinjau Praktik terbaik untuk memantau Kubernetes dengan Azure Monitor untuk menentukan strategi pemantauan terbaik untuk beban kerja Anda.
- Arsitektur beban kerja: Pastikan beban kerja dibangun untuk mendukung penskalaan horizontal dan melaporkan kesiapan dan kesehatan aplikasi.
- Arsitektur kluster dan beban kerja: Pastikan beban kerja Anda berjalan pada kumpulan simpul pengguna dan pilih SKU ukuran yang tepat. Minimal, sertakan dua simpul untuk kumpulan simpul pengguna dan tiga simpul untuk kumpulan simpul sistem.
- Arsitektur kluster: Gunakan AKS Uptime SLA untuk memenuhi target ketersediaan untuk beban kerja produksi.
Rekomendasi konfigurasi AKS
Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi AKS Anda untuk Keandalan.
| Rekomendasi | Keuntungan |
|---|---|
| Arsitektur kluster dan beban kerja: Mengontrol penjadwalan pod menggunakan pemilih dan afinitas simpul. | Memungkinkan penjadwal Kubernetes untuk secara logis mengisolasi beban kerja berdasarkan perangkat keras di node. Tidak seperti toleransi, pod tanpa pemilih simpul yang cocok dapat dijadwalkan pada simpul berlabel, yang memungkinkan sumber daya yang tidak digunakan pada simpul untuk digunakan, tetapi memberikan prioritas pada pod yang menentukan pemilih simpul yang cocok. Gunakan afinitas node untuk lebih banyak fleksibilitas, yang memungkinkan Anda menentukan apa yang terjadi jika pod tidak dapat dicocokkan dengan node. |
| Arsitektur kluster: Pastikan pemilihan plugin jaringan yang tepat berdasarkan persyaratan jaringan dan ukuran kluster. | Azure CNI diperlukan untuk skenario tertentu, misalnya, kumpulan node berbasis Windows, persyaratan jaringan khusus, dan Kebijakan Jaringan Kubernetes. Referensi Kubenet versus Azure CNI untuk informasi lebih lanjut. |
| Arsitektur kluster dan beban kerja: Gunakan AKS Uptime SLA untuk kluster tingkat produksi. | AKS Uptime SLA menjamin: - 99.95% ketersediaan titik akhir server API Kubernetes untuk Kluster AKS yang menggunakan Zona Ketersediaan Azure, atau - 99.9% ketersediaan untuk Kluster AKS yang tidak menggunakan Azure Availability Zone. |
| Arsitektur kluster dan beban kerja: Tinjau Praktik terbaik untuk memantau Kubernetes dengan Azure Monitor untuk menentukan strategi pemantauan terbaik untuk beban kerja Anda. | T/A |
| Arsitektur kluster: Gunakan zona ketersediaan untuk memaksimalkan ketahanan dalam wilayah Azure dengan mendistribusikan simpul agen AKS di seluruh pusat data yang terpisah secara fisik. | Dengan menyebarkan kumpulan simpul di beberapa zona, simpul dalam satu kumpulan simpul akan terus berjalan meskipun zona lain telah turun. Jika ada persyaratan kolokalitas, penyebaran AKS berbasis Virtual Machine Scale Sets reguler ke dalam satu zona atau grup penempatan kedekatan dapat digunakan untuk meminimalkan latensi internode. |
| Arsitektur kluster: Mengadopsi strategi multiregion dengan menyebarkan kluster AKS yang disebarkan di berbagai wilayah Azure untuk memaksimalkan ketersediaan dan memberikan kelangsungan bisnis. | Beban kerja yang menghadap internet harus memanfaatkan Azure Front Door atau Azure Traffic Manager untuk merutekan lalu lintas secara global di seluruh kluster AKS. |
| Arsitektur kluster dan beban kerja: Tentukan permintaan dan batas sumber daya Pod dalam manifes penyebaran aplikasi, dan terapkan dengan Azure Policy. | Batas CPU kontainer dan sumber daya memori diperlukan untuk mencegah kelelahan sumber daya di kluster Kubernetes Anda. |
| Arsitektur kluster dan beban kerja: Menjaga kumpulan simpul Sistem terisolasi dari beban kerja aplikasi. | Kumpulan simpul sistem memerlukan SKU VM minimal 2 vCPU dan memori 4 GB, tetapi 4 vCPU atau lebih direkomendasikan. Lihat Kumpulan node pengguna dan sistem untuk persyaratan terperinci. |
| Arsitektur kluster dan beban kerja: Memisahkan aplikasi ke kumpulan simpul khusus berdasarkan persyaratan tertentu. | Aplikasi dapat berbagi konfigurasi yang sama dan memerlukan VM berkemampuan GPU, VM yang dioptimalkan CPU atau memori, atau kemampuan untuk menskalakan ke nol. Hindari sejumlah besar kumpulan simpul untuk mengurangi overhead manajemen tambahan. |
| Arsitektur kluster: Gunakan gateway NAT untuk kluster yang menjalankan beban kerja yang membuat banyak koneksi keluar bersamaan. | Untuk menghindari masalah keandalan dengan batasan Azure Load Balancer dengan lalu lintas keluar bersamaan yang tinggi, kami adalah NAT Gateway sebagai gantinya untuk mendukung lalu lintas keluar yang andal dalam skala besar. |
Untuk saran lainnya, lihat Prinsip pilar keandalan.
Kebijakan Azure
Azure Kubernetes Service menawarkan berbagai Kebijakan Azure bawaan yang berlaku untuk kedua sumber daya Azure seperti Kebijakan Azure biasa dan, menggunakan add-on Azure Policy untuk Kubernetes, juga dalam kluster. Ada banyak kebijakan utama yang terkait dengan pilar ini yang dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.
Arsitektur kluster dan beban kerja
- Kluster memiliki pemeriksaan kesehatan kesiapan atau keaktifan yang dikonfigurasi untuk spesifikasi pod Anda.
Selain definisi Azure Policy bawaan, kebijakan kustom dapat dibuat untuk sumber daya AKS dan untuk add-on Azure Policy untuk Kubernetes. Ini memungkinkan Anda untuk menambahkan batasan keandalan tambahan yang ingin Anda terlaksakan di kluster dan arsitektur beban kerja Anda.
Keamanan
Keamanan adalah salah satu aspek terpenting dari arsitektur apa pun. Untuk menjelajahi bagaimana AKS dapat memperkuat keamanan beban kerja aplikasi Anda, kami sarankan Anda meninjau prinsip desain Keamanan. Jika kluster Azure Kubernetes Service Anda perlu dirancang untuk menjalankan beban kerja sensitif yang memenuhi persyaratan peraturan Standar Keamanan Data Industri Kartu Pembayaran (PCI-DSS 3.2.1), tinjau kluster yang diatur AKS untuk PCI-DSS 3.2.1.
Untuk mempelajari tentang dukungan dan persyaratan DoD Impact Level 5 (IL5) dengan AKS, tinjau persyaratan isolasi IL5 Azure Government.
Saat membahas keamanan dengan Azure Kubernetes Service, penting untuk membedakan antara keamanan kluster dan keamanan beban kerja. Keamanan kluster adalah tanggung jawab bersama antara admin kluster dan penyedia sumber daya mereka, sementara keamanan beban kerja adalah domain pengembang. Azure Kubernetes Service memiliki pertimbangan dan rekomendasi untuk kedua peran ini.
Dalam daftar periksa desain dan daftar rekomendasi di bawah ini, panggilan dilakukan untuk menunjukkan apakah setiap pilihan berlaku untuk arsitektur kluster, arsitektur beban kerja, atau keduanya.
Daftar periksa desain
- Arsitektur kluster: Gunakan Identitas Terkelola untuk menghindari pengelolaan dan rotasi prinsip layanan.
- Arsitektur kluster: Gunakan kontrol akses berbasis peran Kubernetes (RBAC) dengan ID Microsoft Entra untuk akses hak istimewa paling sedikit dan minimalkan pemberian hak istimewa administrator untuk melindungi konfigurasi, dan akses rahasia.
- Arsitektur kluster: Gunakan Pertahanan Microsoft untuk kontainer dengan Azure Sentinel untuk mendeteksi dan merespons ancaman dengan cepat di seluruh kluster dan beban kerja yang berjalan di dalamnya.
- Arsitektur kluster: Sebarkan kluster AKS privat untuk memastikan lalu lintas manajemen kluster ke server API Anda tetap berada di jaringan privat Anda. Atau gunakan daftar izin server API untuk kluster non-privat.
- Arsitektur beban kerja: Gunakan Web Application Firewall untuk mengamankan lalu lintas HTTP.
- Arsitektur beban kerja: Pastikan alur CI/CID Anda diperkuat dengan pemindaian sadar kontainer.
Rekomendasi
Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi AKS Anda untuk keamanan.
| Rekomendasi | Keuntungan |
|---|---|
| Arsitektur kluster: Gunakan integrasi Microsoft Entra. | Menggunakan MICROSOFT Entra ID mempusatkan komponen manajemen identitas. Setiap perubahan di akun pengguna atau status grup secara otomatis diperbarui pada akses ke kluster AKS. Pengembang dan pemilik aplikasi klaster Kubernetes Anda membutuhkan akses ke sumber daya yang berbeda. |
| Arsitektur kluster: Autentikasi dengan ID Microsoft Entra ke Azure Container Registry. | AKS dan Microsoft Entra ID memungkinkan autentikasi dengan Azure Container Registry tanpa menggunakan imagePullSecrets rahasia. Tinjau Mengautentikasi dengan Azure Container Registry dari Azure Kubernetes Service untuk informasi lebih lanjut. |
| Arsitektur kluster: Mengamankan lalu lintas jaringan ke server API Anda dengan kluster AKS privat. | Secara default, lalu lintas jaringan antara kumpulan simpul Anda dan server API melakukan perjalanan jaringan backbone Microsoft; dengan menggunakan kluster privat, Anda dapat memastikan lalu lintas jaringan ke server API Anda tetap berada di jaringan privat saja. |
| Arsitektur kluster: Untuk kluster AKS non-privat, gunakan rentang IP resmi server API. | Saat menggunakan kluster publik, Anda masih dapat membatasi lalu lintas yang dapat menjangkau server API kluster Anda dengan menggunakan fitur rentang IP resmi. Sertakan sumber seperti IP publik agen build penyebaran, manajemen operasi, dan titik keluar kumpulan simpul (seperti Azure Firewall). |
| Arsitektur kluster: Lindungi server API dengan Microsoft Entra RBAC. | Mengamankan akses ke Kubernetes API Server adalah salah satu hal terpenting yang dapat Anda lakukan untuk mengamankan kluster Anda. Integrasikan kontrol akses berbasis peran (RBAC) Kubernetes dengan MICROSOFT Entra ID untuk mengontrol akses ke server API. Nonaktifkan akun lokal untuk menerapkan semua akses kluster menggunakan identitas berbasis ID Microsoft Entra. |
| Arsitektur kluster: Gunakan kebijakan jaringan Azure atau Calico. | Mengamankan dan mengontrol lalu lintas jaringan antar pod dalam kluster. |
| Arsitektur kluster: Mengamankan kluster dan pod dengan Azure Policy. | Azure Policy dapat membantu menerapkan penegakan dan perlindungan dalam skala besar pada kluster Anda secara terpusat dan konsisten. Ini juga dapat mengontrol fungsi apa yang diberikan pod dan jika ada yang bertentangan dengan kebijakan perusahaan. |
| Arsitektur kluster: Mengamankan akses kontainer ke sumber daya. | Batasi akses ke tindakan yang dapat dilakukan kontainer. Berikan jumlah izin paling sedikit, dan hindari penggunaan root atau eskalasi istimewa. |
| Arsitektur beban kerja: Gunakan Web Application Firewall untuk mengamankan lalu lintas HTTP. | Untuk memindai lalu lintas masuk untuk potensi serangan, gunakan firewall aplikasi web seperti Azure Web Application Firewall (WAF) di Azure Application Gateway atau Azure Front Door. |
| Arsitektur kluster: Mengontrol lalu lintas keluar kluster. | Pastikan lalu lintas keluar kluster Anda melewati titik keamanan jaringan seperti Azure Firewall atau proksi HTTP. |
| Arsitektur kluster: Gunakan ID Beban Kerja Microsoft Entra sumber terbuka dan Driver CSI Secrets Store dengan Azure Key Vault. | Lindungi dan putar rahasia, sertifikat, dan string koneksi di Azure Key Vault dengan enkripsi yang kuat. Menyediakan log audit akses, dan menyimpan rahasia inti dari alur penyebaran. |
| Arsitektur kluster: Gunakan Pertahanan Microsoft untuk Kontainer. | Pantau dan pertahankan keamanan kluster, kontainer, dan aplikasi Anda. |
Untuk saran lainnya, lihat Prinsip pilar keamanan.
Azure Advisor membantu memastikan dan meningkatkan layanan Azure Kubernetes. Ini membuat rekomendasi pada subset item yang tercantum di bagian kebijakan di bawah ini, seperti kluster tanpa RBAC yang dikonfigurasi, konfigurasi Pertahanan Microsoft yang hilang, akses jaringan yang tidak dibatasi ke API Server. Demikian juga, membuat rekomendasi beban kerja untuk beberapa item inisiatif keamanan pod. Tinjau rekomendasi.
Definisi kebijakan
Azure Policy menawarkan berbagai definisi kebijakan bawaan yang berlaku untuk sumber daya Azure dan AKS seperti definisi kebijakan standar, dan menggunakan add-on Azure Policy untuk Kubernetes, juga dalam kluster. Banyak kebijakan sumber daya Azure datang dalam varian Audit/Tolak, tetapi juga dalam varian Sebarkan Jika Tidak Ada .
Ada banyak kebijakan utama yang terkait dengan pilar ini yang dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.
Arsitektur kluster
- kebijakan berbasis Microsoft Defender untuk Cloud
- Mode autentikasi dan kebijakan konfigurasi (ID Microsoft Entra, RBAC, nonaktifkan autentikasi lokal)
- Kebijakan akses jaringan API Server, termasuk kluster privat
Arsitektur kluster dan beban kerja
- Inisiatif keamanan pod kluster Kubernetes beban kerja berbasis Linux
- Menyertakan kebijakan kemampuan pod dan kontainer seperti AppArmor, sysctl, batas keamanan, SELinux, seccomp, kontainer istimewa, kredensial API kluster mobil
- Memasang, driver volume, dan kebijakan sistem file
- Kebijakan jaringan Pod/Kontainer, seperti jaringan host, port, IP eksternal yang diizinkan, HTTP, dan load balancer internal
Penyebaran Azure Kubernetes Service sering juga menggunakan Azure Container Registry untuk bagan Helm dan gambar kontainer. Azure Container Registry juga mendukung berbagai kebijakan Azure yang mencakup pembatasan jaringan, kontrol akses, dan Microsoft Defender untuk Cloud, yang melengkapi arsitektur AKS yang aman.
Selain kebijakan bawaan, kebijakan kustom dapat dibuat untuk sumber daya AKS dan untuk add-on Azure Policy untuk Kubernetes. Ini memungkinkan Anda untuk menambahkan batasan keamanan tambahan yang ingin Anda berlakukan di kluster dan arsitektur beban kerja Anda.
Untuk saran lebih lanjut, lihat konsep keamanan AKS dan evaluasi rekomendasi pengerasan keamanan kami berdasarkan tolok ukur CIS Kubernetes.
Pengoptimalan biaya
Pengoptimalan biaya adalah tentang memahami berbagai opsi konfigurasi Anda dan praktik terbaik yang direkomendasikan untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Sebelum Anda mengikuti panduan dalam artikel ini, kami sarankan Anda meninjau sumber daya berikut:
- Prinsip desain pengoptimalan biaya.
- Cara kerja pengelolaan harga dan biaya di Azure Kubernetes Service (AKS) dibandingkan dengan Amazon Elastic Kubernetes Service (Amazon EKS).
- Jika Anda menjalankan AKS lokal atau di tepi, Azure Hybrid Benefit juga dapat digunakan untuk mengurangi biaya lebih lanjut saat menjalankan aplikasi kontainer dalam skenario tersebut.
Saat membahas pengoptimalan biaya dengan Azure Kubernetes Service, penting untuk membedakan antara biaya sumber daya kluster dan biaya sumber daya beban kerja. Sumber daya kluster adalah tanggung jawab bersama antara admin kluster dan penyedia sumber daya mereka, sementara sumber daya beban kerja adalah domain pengembang. Azure Kubernetes Service memiliki pertimbangan dan rekomendasi untuk kedua peran ini.
Dalam daftar periksa desain dan daftar rekomendasi, panggilan keluar dibuat untuk menunjukkan apakah setiap pilihan berlaku untuk arsitektur kluster, arsitektur beban kerja, atau keduanya.
Untuk pengoptimalan biaya kluster, buka kalkulator harga Azure dan pilih Azure Kubernetes Service dari produk yang tersedia. Anda dapat menguji berbagai konfigurasi dan paket pembayaran di kalkulator.
Daftar periksa desain
- Arsitektur kluster: Gunakan SKU VM yang sesuai per kumpulan simpul dan instans cadangan di mana kapasitas jangka panjang diharapkan.
- Arsitektur kluster dan beban kerja: Gunakan tingkat dan ukuran disk terkelola yang sesuai.
- Arsitektur kluster: Tinjau metrik performa, dimulai dengan CPU, memori, penyimpanan, dan jaringan, untuk mengidentifikasi peluang pengoptimalan biaya berdasarkan kluster, node, dan namespace.
- Arsitektur kluster dan beban kerja: Gunakan autoscaler untuk menskalakan ketika beban kerja kurang aktif.
Rekomendasi
Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi AKS Anda dengan biaya.
| Rekomendasi | Keuntungan |
|---|---|
| Arsitektur kluster dan beban kerja: Menyelaraskan pemilihan SKU dan ukuran disk terkelola dengan persyaratan beban kerja. | Mencocokkan pilihan Anda dengan tuntutan beban kerja Anda memastikan Anda tidak membayar sumber daya yang tidak dibutuhkan. |
| Arsitektur kluster: Pilih jenis instans komputer virtual yang tepat. | Memilih jenis instans komputer virtual yang tepat sangat penting karena berdampak langsung pada biaya menjalankan aplikasi di AKS. Memilih instans berkinerja tinggi tanpa pemanfaatan yang tepat dapat menyebabkan pengeluaran yang boros, sementara memilih instans yang kurang kuat dapat menyebabkan masalah performa dan peningkatan waktu henti. Untuk menentukan jenis instans komputer virtual yang tepat, pertimbangkan karakteristik beban kerja, persyaratan sumber daya, dan kebutuhan ketersediaan. |
| Arsitektur kluster: Pilih komputer virtual berdasarkan arsitektur Arm. | AKS mendukung pembuatan simpul agen Arm64 Ubuntu, serta campuran simpul arsitektur Intel dan ARM dalam kluster yang dapat membawa performa yang lebih baik dengan biaya yang lebih rendah. |
| Arsitektur kluster: Pilih Azure Spot Virtual Machines. | Spot VM memungkinkan Anda memanfaatkan kapasitas Azure yang tidak digunakan dengan diskon signifikan (hingga 90% dibandingkan dengan harga bayar sesuai penggunaan). Jika Azure membutuhkan kapasitas kembali, infrastruktur Azure akan mengeluarkan simpul Spot. |
| Arsitektur kluster: Pilih wilayah yang sesuai. | Karena banyak faktor, biaya sumber daya bervariasi per wilayah di Azure. Evaluasi persyaratan biaya, latensi, dan kepatuhan untuk memastikan Anda menjalankan beban kerja secara hemat biaya dan tidak memengaruhi pengguna akhir Anda atau membuat biaya jaringan tambahan. |
| Arsitektur beban kerja: Pertahankan gambar kecil dan dioptimalkan. | Menyederhanakan gambar Anda membantu mengurangi biaya karena simpul baru perlu mengunduh gambar-gambar ini. Buat gambar dengan cara yang memungkinkan kontainer dimulai sesegera mungkin untuk membantu menghindari kegagalan permintaan pengguna atau batas waktu saat aplikasi dimulai, berpotensi menyebabkan provisi berlebih. |
| Arsitektur kluster: Aktifkan Autoscaler Kluster untuk secara otomatis mengurangi jumlah simpul agen sebagai respons terhadap kapasitas sumber daya berlebih. | Menurunkan skala jumlah simpul di kluster AKS secara otomatis memungkinkan Anda menjalankan kluster yang efisien ketika permintaan rendah dan meningkatkan skala saat permintaan kembali. |
| Arsitektur kluster: Aktifkan Provisi Otomatis Simpul untuk mengotomatiskan pemilihan SKU VM. | Node Autoprovision menyederhanakan proses pemilihan SKU dan memutuskan, berdasarkan persyaratan sumber daya pod yang tertunda, konfigurasi VM optimal untuk menjalankan beban kerja dengan cara yang paling efisien dan hemat biaya. |
| Arsitektur beban kerja: Gunakan Autoscaler Pod Horizontal. | Sesuaikan jumlah pod dalam penyebaran tergantung pada pemanfaatan CPU atau metrik pilihan lainnya, yang mendukung operasi penyempurnaan skala kluster. |
| Arsitektur beban kerja: Gunakan Penskala Otomatis Pod Vertikal (pratinjau). | Hakkan pod Anda dan tetapkan permintaan dan batasan secara dinamis berdasarkan penggunaan historis . |
| Arsitektur beban kerja: Gunakan Kubernetes Event Driven Autoscaling (KEDA). | Menskalakan berdasarkan jumlah peristiwa yang sedang diproses. Pilih dari katalog kaya dari 50+ penskala KEDA. |
| Arsitektur kluster dan beban kerja: Mengadopsi disiplin keuangan cloud dan praktik budaya untuk mendorong kepemilikan penggunaan cloud. | Fondasi mengaktifkan pengoptimalan biaya adalah penyebaran kluster penghematan biaya. Pendekatan operasi keuangan (FinOps) sering digunakan untuk membantu organisasi mengurangi biaya cloud. Ini adalah praktik yang melibatkan kolaborasi antara tim keuangan, operasi, dan teknik untuk mendorong keselarasan pada tujuan penghematan biaya dan membawa transparansi pada biaya cloud. |
| Arsitektur kluster: Daftar untuk Reservasi Azure atau Azure Savings Plan. | Jika Anda merencanakan kapasitas dengan benar, beban kerja Anda dapat diprediksi dan ada untuk jangka waktu yang lama, mendaftar untuk Reservasi Azure atau rencana penghematan untuk mengurangi biaya sumber daya Anda lebih lanjut. |
| Arsitektur kluster: Tinjau Praktik terbaik untuk memantau Kubernetes dengan Azure Monitor untuk menentukan strategi pemantauan terbaik untuk beban kerja Anda. | T/A |
| Arsitektur kluster: Konfigurasikan add-on Analisis Biaya AKS. | Ekstensi kluster analisis biaya memungkinkan Anda mendapatkan wawasan terperinci tentang biaya yang terkait dengan berbagai sumber daya Kubernetes di kluster atau namespace Layanan Anda. |
Untuk saran selengkapnya, lihat Prinsip pilar pengoptimalan biaya dan Mengoptimalkan Biaya di Azure Kubernetes Service.
Definisi kebijakan
Meskipun tidak ada kebijakan bawaan yang terkait dengan pengoptimalan biaya, kebijakan kustom dapat dibuat untuk sumber daya AKS dan untuk add-on Azure Policy untuk Kubernetes. Ini memungkinkan Anda untuk menambahkan batasan pengoptimalan biaya tambahan yang ingin Anda berlakukan dalam arsitektur kluster dan beban kerja Anda.
Efisiensi cloud
Membuat beban kerja lebih berkelanjutan dan hemat cloud, membutuhkan upaya menggabungkan sekeliling pengoptimalan biaya, mengurangi emisi karbon, dan mengoptimalkan konsumsi energi. Mengoptimalkan biaya aplikasi adalah langkah awal dalam membuat beban kerja lebih berkelanjutan.
Pelajari cara membangun beban kerja AKS yang berkelanjutan dan efisien, dalam prinsip rekayasa perangkat lunak berkelanjutan di Azure Kubernetes Service (AKS).
Keunggulan operasional
Pemantauan dan diagnostik sangat penting. Anda tidak hanya dapat mengukur statistik performa, tetapi juga menggunakan pemecahan masalah metrik dan memulihkan masalah dengan cepat. Kami sarankan Anda meninjau prinsip desain keunggulan operasional dan panduan operasi Hari-2.
Saat membahas keunggulan operasional dengan Azure Kubernetes Service, penting untuk membedakan antara keunggulan operasional kluster dan keunggulan operasional beban kerja. Operasi kluster adalah tanggung jawab bersama antara admin kluster dan penyedia sumber daya mereka, sementara operasi beban kerja adalah domain pengembang. Azure Kubernetes Service memiliki pertimbangan dan rekomendasi untuk kedua peran ini.
Dalam daftar periksa desain dan daftar rekomendasi di bawah ini, panggilan dilakukan untuk menunjukkan apakah setiap pilihan berlaku untuk arsitektur kluster, arsitektur beban kerja, atau keduanya.
Daftar periksa desain
- Arsitektur kluster: Gunakan penyebaran berbasis templat menggunakan Bicep, Terraform, atau lainnya. Pastikan bahwa semua penyebaran dapat diulang, dapat dilacak, dan disimpan dalam repositori kode sumber.
- Arsitektur kluster: Bangun proses otomatis untuk memastikan kluster Anda di-bootstrap dengan konfigurasi dan penyebaran di seluruh kluster yang diperlukan. Ini sering dilakukan menggunakan GitOps.
- Arsitektur beban kerja: Gunakan proses penyebaran yang dapat diulang dan otomatis untuk beban kerja Anda dalam siklus hidup pengembangan perangkat lunak Anda.
- Arsitektur kluster: Aktifkan pengaturan diagnostik untuk memastikan bidang kontrol atau interaksi server API inti dicatat.
- Arsitektur kluster dan beban kerja: Tinjau Praktik terbaik untuk memantau Kubernetes dengan Azure Monitor untuk menentukan strategi pemantauan terbaik untuk beban kerja Anda.
- Arsitektur beban kerja: Beban kerja harus dirancang untuk memancarkan telemetri yang dapat dikumpulkan, yang juga harus mencakup status keaktifan dan kesiapan.
- Arsitektur kluster dan beban kerja: Gunakan praktik rekayasa chaos yang menargetkan Kubernetes untuk mengidentifikasi masalah keandalan aplikasi atau platform.
- Arsitektur beban kerja: Optimalkan beban kerja Anda untuk mengoperasikan dan menyebarkan secara efisien dalam kontainer.
- Arsitektur kluster dan beban kerja: Menerapkan tata kelola kluster dan beban kerja menggunakan Azure Policy.
Rekomendasi
Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi AKS Anda untuk operasi.
| Rekomendasi | Keuntungan |
|---|---|
| Arsitektur kluster dan beban kerja: Tinjau dokumentasi praktik terbaik AKS. | Untuk berhasil membangun dan menjalankan aplikasi di AKS, ada pertimbangan utama untuk memahami dan mengimplementasikan. Area ini mencakup fitur multi-penyewaan dan penjadwal, kluster, serta keamanan pod, atau keberlangsungan bisnis dan pemulihan bencana. |
| Arsitektur kluster dan beban kerja: Tinjau Azure Chaos Studio. | Azure Chaos Studio dapat membantu mensimulasikan kesalahan dan memicu situasi pemulihan bencana. |
| Arsitektur kluster dan beban kerja: Tinjau Praktik terbaik untuk memantau Kubernetes dengan Azure Monitor untuk menentukan strategi pemantauan terbaik untuk beban kerja Anda. | T/A |
| Arsitektur kluster: Mengadopsi strategi multiregion dengan menyebarkan kluster AKS yang disebarkan di berbagai wilayah Azure untuk memaksimalkan ketersediaan dan memberikan kelangsungan bisnis. | Beban kerja yang menghadap internet harus memanfaatkan Azure Front Door atau Azure Traffic Manager untuk merutekan lalu lintas secara global di seluruh kluster AKS. |
| Arsitektur kluster: Mengoprasikan kluster dan standar konfigurasi pod dengan Azure Policy. | Azure Policy dapat membantu menerapkan penegakan dan perlindungan dalam skala besar pada kluster Anda secara terpusat dan konsisten. Ini juga dapat mengontrol fungsi apa yang diberikan pod dan jika ada yang bertentangan dengan kebijakan perusahaan. |
| Arsitektur beban kerja: Gunakan kemampuan platform dalam proses rekayasa rilis Anda. | Pengontrol Kubernetes dan ingress mendukung banyak pola penyebaran tingkat lanjut untuk dimasukkan dalam proses rekayasa rilis Anda. Pertimbangkan pola seperti penyebaran biru-hijau atau rilis kenari. |
| Arsitektur kluster dan beban kerja: Untuk beban kerja misi penting, gunakan penyebaran biru/hijau tingkat stempel. | Otomatiskan area desain misi penting Anda, termasuk penyebaran dan pengujian. |
Untuk saran selengkapnya, lihat Prinsip pilar keunggulan operasional.
Azure Advisor juga membuat rekomendasi pada subset item yang tercantum di bagian kebijakan di bawah ini, versi AKS yang tidak didukung tersebut dan pengaturan diagnostik yang tidak dikonfigurasi. Demikian juga, itu membuat rekomendasi beban kerja sekeliling penggunaan namespace default.
Definisi kebijakan
Azure Policy menawarkan berbagai definisi kebijakan bawaan yang berlaku untuk sumber daya Azure dan AKS seperti definisi kebijakan standar, dan menggunakan add-on Azure Policy untuk Kubernetes, juga dalam kluster. Banyak kebijakan sumber daya Azure datang dalam varian Audit/Tolak, tetapi juga dalam varian Sebarkan Jika Tidak Ada .
Ada banyak kebijakan utama yang terkait dengan pilar ini yang dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.
Arsitektur kluster
- Add-on Azure Policy untuk Kubernetes
- Kebijakan konfigurasi GitOps
- Kebijakan pengaturan diagnostik
- Pembatasan versi AKS
- Cegah pemanggilan perintah
Arsitektur kluster dan beban kerja
- Pembatasan penyebaran namespace
Selain kebijakan bawaan, kebijakan kustom dapat dibuat untuk sumber daya AKS dan untuk add-on Azure Policy untuk Kubernetes. Ini memungkinkan Anda untuk menambahkan batasan keamanan tambahan yang ingin Anda berlakukan di kluster dan arsitektur beban kerja Anda.
Efisiensi kinerja
Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Sebaiknya Anda meninjau prinsip Efisiensi performa.
Saat membahas performa dengan Azure Kubernetes Service, penting untuk membedakan antara performa kluster dan performa beban kerja. Performa kluster adalah tanggung jawab bersama antara admin kluster dan penyedia sumber daya mereka, sementara performa beban kerja adalah domain pengembang. Azure Kubernetes Service memiliki pertimbangan dan rekomendasi untuk kedua peran ini.
Dalam daftar periksa desain dan daftar rekomendasi di bawah ini, panggilan dilakukan untuk menunjukkan apakah setiap pilihan berlaku untuk arsitektur kluster, arsitektur beban kerja, atau keduanya.
Daftar periksa desain
Saat Anda membuat pilihan desain untuk Azure Kubernetes Service, tinjau prinsip Efisiensi performa.
- Arsitektur kluster dan beban kerja: Lakukan dan iterasi pada latihan rencana kapasitas terperinci yang mencakup SKU, pengaturan skala otomatis, alamat IP, dan pertimbangan failover.
- Arsitektur kluster: Aktifkan autoscaler kluster untuk menyesuaikan jumlah simpul agen secara otomatis dalam tuntutan beban kerja respons.
- Arsitektur kluster: Gunakan autoscaler Pod Horizontal untuk menyesuaikan jumlah pod dalam penyebaran tergantung pada pemanfaatan CPU atau metrik pilihan lainnya.
- Arsitektur kluster dan beban kerja: Lakukan aktivitas pengujian beban berkelanjutan yang menjalankan penskala otomatis pod dan kluster.
- Arsitektur kluster dan beban kerja: Pisahkan beban kerja ke dalam kumpulan simpul yang berbeda yang memungkinkan penskalakan independen.
Rekomendasi
Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi Azure Kubernetes Service Anda untuk performa.
| Rekomendasi | Keuntungan |
|---|---|
| Arsitektur kluster dan beban kerja: Kembangkan rencana kapasitas terperinci dan terus tinjau dan revisi. | Setelah meresmikan rencana kapasitas Anda, rencana tersebut harus sering diperbarui dengan terus mengamati pemanfaatan sumber daya kluster. |
| Arsitektur kluster: Aktifkan autoscaler kluster untuk menyesuaikan jumlah simpul agen secara otomatis sebagai respons terhadap batasan sumber daya. | Kemampuan untuk secara otomatis meningkatkan atau menurunkan jumlah node di kluster AKS Anda memungkinkan Anda menjalankan kluster yang efisien dan hemat biaya. |
| Arsitektur kluster dan beban kerja: Pisahkan beban kerja ke dalam kumpulan simpul yang berbeda dan pertimbangkan untuk menskalakan kumpulan simpul pengguna. | Tidak seperti kumpulan simpul Sistem yang selalu memerlukan simpul yang berjalan, kumpulan simpul pengguna memungkinkan Anda untuk meningkatkan atau menurunkan skala. |
| Arsitektur beban kerja: Gunakan fitur penjadwal tingkat lanjut AKS. | Membantu mengontrol keseimbangan sumber daya untuk beban kerja yang memerlukannya. |
| Arsitektur beban kerja: Gunakan metrik penskalakan beban kerja yang bermakna. | Tidak semua keputusan skala dapat berasal dari metrik CPU atau memori. Sering kali pertimbangan skala akan berasal dari titik data yang lebih kompleks atau bahkan eksternal. Gunakan KEDA untuk membangun kumpulan aturan skala otomatis yang bermakna berdasarkan sinyal yang khusus untuk beban kerja Anda. |
Untuk saran lainnya, lihat Prinsip pilar efisiensi performa.
Definisi kebijakan
Azure Policy menawarkan berbagai definisi kebijakan bawaan yang berlaku untuk sumber daya Azure dan AKS seperti definisi kebijakan standar, dan menggunakan add-on Azure Policy untuk Kubernetes, juga dalam kluster. Banyak kebijakan sumber daya Azure datang dalam varian Audit/Tolak, tetapi juga dalam varian Sebarkan Jika Tidak Ada .
Ada banyak kebijakan utama yang terkait dengan pilar ini yang dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.
Arsitektur kluster dan beban kerja
- Batas sumber daya CPU dan memori
Selain kebijakan bawaan, kebijakan kustom dapat dibuat untuk sumber daya AKS dan untuk add-on Azure Policy untuk Kubernetes. Ini memungkinkan Anda untuk menambahkan batasan keamanan tambahan yang ingin Anda berlakukan di kluster dan arsitektur beban kerja Anda.
Sumber Daya Tambahan:
Panduan Azure Architecture Center
- Arsitektur garis besar AKS
- Arsitektur layanan mikro AKS tingkat lanjut
- Kluster AKS untuk beban kerja PCI-DSS
- Garis besar AKS untuk kluster multiregion
Panduan Cloud Adoption Framework
Langkah berikutnya
- Menyebarkan kluster Azure Kubernetes Service (AKS) menggunakan Mulai Cepat Azure CLI : Menyebarkan kluster Azure Kubernetes Service (AKS) menggunakan Azure CLI