Ulasan Azure Well-Architected Framework - Azure Kubernetes Service (AKS)

  • Artikel

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 performa

Kami berasumsi bahwa Anda memahami prinsip desain sistem, memiliki pengetahuan kerja tentang Azure Kubernetes Service, dan berpengalaman 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. Kami menyarankan agar Anda meninjau beban kerja anda dengan menggunakan penilaian Azure Well-Architected Framework Review .

Untuk konteksnya, pertimbangkan untuk meninjau arsitektur referensi yang mencerminkan pertimbangan ini dalam desainnya. Kami menyarankan agar Anda mulai dengan arsitektur dasar untuk kluster Azure Kubernetes Service (AKS) dan arsitektur Layanan Mikro pada 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 sama sekali, 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, panggilan dilakukan 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: Aktifkan wawasan Kontainer untuk memantau kluster Anda dan mengonfigurasi pemberitahuan untuk peristiwa yang berdampak keandalan.
  • 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 Manfaat
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 selengkapnya.
Arsitektur kluster dan beban kerja: Gunakan AKS Uptime SLA untuk kluster tingkat produksi. AKS Uptime SLA menjamin:
- 99.95% ketersediaan titik akhir server Kubernetes API untuk Kluster AKS yang menggunakan Zona Ketersediaan Azure, atau
- 99.9% ketersediaan untuk Kluster AKS yang tidak menggunakan Zona Ketersediaan Azure.
Arsitektur kluster dan beban kerja: Mengonfigurasi pemantauan kluster dengan wawasan Kontainer. Wawasan kontainer membantu memantau kesehatan dan performa pengontrol, simpul, dan kontainer yang tersedia di Kubernetes melalui API Metrik. Integrasi dengan Prometheus memungkinkan pengumpulan metrik aplikasi dan beban kerja.
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 bahkan jika zona lain telah turun. Jika ada persyaratan kolokalitas, penyebaran AKS berbasis VMSS 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 batasan 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: Jaga agar kumpulan simpul Sistem terisolasi dari beban kerja aplikasi. Kumpulan simpul sistem memerlukan SKU VM setidaknya 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: Pisahkan 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 ekstra.
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 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 sumber daya Azure seperti Kebijakan Azure umum dan, menggunakan add-on Azure Policy untuk Kubernetes, juga dalam kluster. Ada banyak kebijakan, dan kebijakan utama yang terkait dengan pilar ini dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.

Arsitektur kluster dan beban kerja

  • Kluster memiliki kesiapan atau pemeriksaan kesehatan 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 berlakukan 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 Azure Government persyaratan isolasi IL5.

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 (RBAC) Kube dengan Microsoft Entra ID untuk akses hak istimewa paling sedikit dan minimalkan pemberian hak istimewa administrator untuk melindungi konfigurasi, dan akses rahasia.
  • Arsitektur kluster: Gunakan Microsoft Defender 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 diperkeras dengan pemindaian sadar kontainer.

Rekomendasi

Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi AKS Anda untuk keamanan.

Rekomendasi Manfaat
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 Microsoft Entra ID ke Azure Container Registry. AKS dan Microsoft Entra ID memungkinkan autentikasi dengan Azure Container Registry tanpa menggunakan imagePullSecrets rahasia. Tinjau Autentikasi dengan Azure Container Registry dari Azure Kubernetes Service untuk informasi selengkapnya.
Arsitektur kluster: Amankan 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 mencapai 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) Kube dengan Microsoft Entra ID untuk mengontrol akses ke server API. Nonaktifkan akun lokal untuk memberlakukan semua akses kluster menggunakan identitas berbasis Microsoft Entra ID.
Arsitektur kluster: Gunakan kebijakan jaringan Azure atau Calico. Mengamankan dan mengontrol lalu lintas jaringan antara 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 Microsoft Entra Workload ID sumber terbuka dan Driver Secrets Store CSI 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 Microsoft Defender untuk Kontainer. Pantau dan jaga keamanan kluster, kontainer, dan aplikasinya.

Untuk saran selengkapnya, 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 Microsoft Defender hilang, akses jaringan tidak terbatas ke API Server. Demikian juga, ini 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 di Audit/Tolak, tetapi juga dalam varian Deploy If Not Exists .

Ada banyak kebijakan, dan kebijakan utama yang terkait dengan pilar ini dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.

Arsitektur kluster

  • Microsoft Defender untuk kebijakan berbasis Cloud
  • Mode autentikasi dan kebijakan konfigurasi (Microsoft Entra ID, 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
  • Sertakan kebijakan kemampuan pod dan kontainer seperti AppArmor, sysctl, batas keamanan, SELinux, seccomp, kontainer istimewa, kredensial API kluster automount
  • Memasang, driver volume, dan kebijakan sistem file
  • Kebijakan jaringan Pod/Kontainer, seperti jaringan host, port, IP eksternal yang diizinkan, HTTP, dan load balancer internal

Azure Kubernetes Service penyebaran 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 dalam arsitektur kluster dan 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:

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 dilakukan 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, simpul, dan namespace layanan.
  • Arsitektur kluster dan beban kerja: Gunakan autoscaler untuk menskalakan saat beban kerja kurang aktif.

Rekomendasi

Jelajahi tabel rekomendasi berikut untuk mengoptimalkan konfigurasi AKS Anda untuk biaya.

Rekomendasi Manfaat
Arsitektur kluster dan beban kerja: Sejajarkan pemilihan SKU dan ukuran disk terkelola dengan persyaratan beban kerja. Mencocokkan pilihan Anda dengan tuntutan beban kerja memastikan Anda tidak membayar sumber daya yang tidak perlu.
Arsitektur kluster: Pilih jenis instans komputer virtual yang tepat. Memilih jenis instans komputer virtual yang tepat sangat penting karena secara langsung berdampak pada biaya menjalankan aplikasi di AKS. Memilih instans berkinerja tinggi tanpa pemanfaatan yang tepat dapat menyebabkan pengeluaran yang boros, sementara memilih instans yang 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 node arsitektur Intel dan ARM campuran 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 yang signifikan (hingga 90% dibandingkan dengan harga bayar sesuai penggunaan). Jika Azure membutuhkan kapasitas kembali, infrastruktur Azure 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. Bangun 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 yang berlebih. Menurunkan jumlah simpul di kluster AKS secara otomatis memungkinkan Anda menjalankan kluster yang efisien saat permintaan rendah dan meningkatkan skala ketika 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 Autoscaler 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). Skalakan 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: Mengonfigurasi pemantauan kluster dengan wawasan Kontainer. Wawasan kontainer membantu memberikan wawasan yang dapat ditindaklanjuti ke dalam kluster Anda diam dan sumber daya yang tidak dialokasikan. Wawasan kontainer juga mendukung pengumpulan metrik Prometheus dan terintegrasi dengan Azure Managed Grafana untuk mendapatkan tampilan holistik dari aplikasi dan infrastruktur Anda.
Arsitektur kluster: Konfigurasikan add-on Analisis Biaya AKS. Ekstensi kluster analisis biaya memungkinkan Anda untuk 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 dalam 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. Sebaiknya tinjau 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: Buat 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 berulang 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: Aktifkan wawasan Kontainer untuk mengumpulkan metrik, log, dan diagnostik untuk memantau ketersediaan dan performa kluster dan beban kerja yang berjalan di dalamnya.
  • 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 teknik 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 Manfaat
Arsitektur kluster dan beban kerja: Tinjau dokumentasi praktik terbaik AKS . Untuk membangun dan menjalankan aplikasi dengan sukses 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: Mengonfigurasi pemantauan kluster dengan wawasan Kontainer. Wawasan kontainer membantu memantau performa kontainer dengan mengumpulkan metrik memori dan prosesor dari pengontrol, simpul, dan kontainer yang tersedia di Kubernetes melalui API Metrik dan log kontainer.
Arsitektur beban kerja: Memantau performa aplikasi dengan Azure Monitor. Konfigurasikan Application Insights untuk pemantauan aplikasi berbasis kode yang berjalan di kluster AKS.
Arsitektur beban kerja: Konfigurasikan pengikisan metrik Prometheus dengan wawasan Kontainer. Wawasan kontainer, yang merupakan bagian dari Azure Monitor, memberikan pengalaman onboarding yang mulus untuk mengumpulkan metrik Prometheus. Referensi Konfigurasikan pengikisan metrik Prometheus untuk informasi selengkapnya.
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: Mengoprasi 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. Kubernetes dan pengontrol 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 dan pengaturan diagnostik yang tidak dikonfigurasi. Demikian juga, ini 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 hadir dalam varian Audit/Tolak, tetapi juga dalam varian Sebarkan Jika Tidak Ada .

Ada banyak kebijakan, dan kebijakan utama yang terkait dengan pilar ini dirangkum di sini. Untuk tampilan yang lebih rinci, lihat definisi kebijakan bawaan untuk Kubernetes.

Arsitektur kluster

  • Azure Policy add-on untuk Kubernetes
  • Kebijakan konfigurasi GitOps
  • Kebijakan pengaturan diagnostik
  • Pembatasan versi AKS
  • Mencegah 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 terlaksakan dalam arsitektur kluster dan beban kerja Anda.

Efisiensi performa

Efisiensi performa adalah kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan yang diberikan oleh pengguna dengan cara yang efisien. Sebaiknya tinjau 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 secara otomatis menyesuaikan jumlah simpul agen 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 yang sedang berlangsung 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 Manfaat
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 secara otomatis menyesuaikan jumlah simpul agen 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 penyeimbangan 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. Seringkali pertimbangan skala akan berasal dari titik data yang lebih kompleks atau bahkan eksternal. Gunakan KEDA untuk membangun set aturan skala otomatis yang bermakna berdasarkan sinyal yang khusus untuk beban kerja Anda.

Untuk saran selengkapnya, 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 hadir dalam varian Audit/Tolak, tetapi juga dalam varian Sebarkan Jika Tidak Ada .

Ada banyak kebijakan, dan kebijakan utama yang terkait dengan pilar ini 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 terlaksakan dalam arsitektur kluster dan beban kerja Anda.

Sumber Daya Tambahan:

Panduan Azure Architecture Center

Panduan Cloud Adoption Framework

Langkah berikutnya