Arsitektur dasar untuk klaster Azure Kubernetes Service (AKS)

Artikel ini menyediakan arsitektur infrastruktur dasar yang direkomendasikan untuk menyebarkan kluster Azure Kubernetes Service (AKS). Ini menggunakan prinsip desain kami dan didasarkan pada praktik terbaik arsitektur AKS dari Azure Well-Architected Framework. Artikel ini membantu memandu beberapa grup interdisipliner yang berbeda, seperti tim jaringan, keamanan, dan identitas, ketika mereka menyebarkan infrastruktur tujuan umum 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 yang berbeda. Pertimbangkan arsitektur sebagai titik awal Anda untuk tahap praproduksi dan produksi.

Anda dapat menggunakan implementasi arsitektur ini di GitHub: Implementasi referensi garis besar AKS. Gunakan sebagai titik awal alternatif dan konfigurasikan arsitektur referensi berdasarkan kebutuhan Anda.

Konfigurasi Jaringan

Topologi jaringan
Merencanakan alamat IP
Menyebarkan sumber daya ingress

Komputasi kluster

Menghitung untuk kluster dasar
Referensi gambar kontainer
Manajemen kebijakan

Pengelolaan identitas

Mengintegrasikan ID Microsoft Entra untuk kluster
Mengintegrasikan ID Microsoft Entra untuk beban kerja

Alur data aman

Mengamankan alur jaringan
Menambahkan manajemen rahasia

Keberlangsungan bisnis

Skalabilitas
Ketersediaan kluster dan node
Ketersediaan dan dukungan multi wilayah

Operasional

Kluster dan beban kerja alur CI/CD
Kesehatan dan metrik kluster
Manajemen biaya dan pelaporan

Topologi jaringan

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

• Aktifkan manajemen yang dipisahkan. Anda dapat menerapkan tata kelola dan mematuhi prinsip hak istimewa paling sedikit. Ini juga mendukung konsep zona pendaratan Azure dengan pemisahan tugas.

• Minimalkan paparan langsung sumber daya Azure ke internet publik.

• Sediakan topologi hub regional dan spoke. Anda dapat memperluas topologi jaringan hub dan spoke di masa mendatang dan menyediakan isolasi beban kerja.

• Gunakan layanan firewall aplikasi web 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.

Unduh file Visio arsitektur ini.

Untuk informasi selengkapnya, lihat Topologi jaringan hub-spoke di Azure.

Untuk informasi selengkapnya tentang perubahan desain jaringan yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat kontainer Windows di AKS.

Jaringan virtual hub

Jaringan virtual hub adalah titik pusat konektivitas dan pengamatan. Dalam arsitektur ini, hub berisi:

• Azure Firewall dengan kebijakan firewall global, yang ditentukan oleh tim IT pusat Anda untuk menerapkan kebijakan firewall di seluruh organisasi.
• Azure Bastion untuk akses jarak jauh ke komputer virtual (VM).
• Subnet gateway untuk 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 non-Microsoft berbahaya 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 jenis arsitektur jaringan virtual hub ini.

Subnet untuk menghosting gateway

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

Subnet untuk menghosting Azure Bastion

Subnet ini adalah placeholder untuk Azure Bastion. Anda dapat menggunakan Azure Bastion untuk mengakses sumber daya Azure dengan aman tanpa mengekspos sumber daya ke internet. Subnet ini hanya untuk manajemen dan operasi.

Jaringan virtual spoke

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

Subnet untuk menghosting Azure Application Gateway

Application Gateway adalah penyeimbang beban lalu lintas web yang beroperasi di Lapisan 7. Implementasi referensi menggunakan Application Gateway v2 SKU yang mengaktifkan 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 menghosting sumber daya ingress

Untuk merutekan dan mendistribusikan lalu lintas, Traefik adalah pengontrol ingress yang memenuhi sumber daya ingress Kubernetes. Penyeimbang beban internal Azure ada di subnet ini. Untuk informasi selengkapnya, lihat Menggunakan 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 Private Link untuk Azure Container Registry dan Azure Key Vault sehingga pengguna dapat mengakses layanan ini dengan cara titik akhir privat dalam jaringan virtual spoke. Titik akhir privat tidak memerlukan subnet khusus. Anda juga dapat menempatkan titik akhir privat di jaringan virtual hub. Dalam implementasi garis besar, 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 di jaringan virtual yang sama. Anda juga dapat menerapkan aturan keamanan terperinci di tingkat subnet dengan menggunakan grup keamanan jaringan.

Untuk informasi selengkapnya, lihat Opsi penyebaran Private Link.

Merencanakan alamat IP

Unduh file Visio arsitektur ini.

Ruang alamat jaringan virtual harus cukup besar untuk menampung semua subnet. Memperhitungkan semua entitas yang menerima lalu lintas. Kubernetes mengalokasikan alamat IP untuk entitas tersebut dari ruang alamat subnet. Pertimbangkan juga poin-poin ini.

• Peningkatan

  AKS memperbarui simpul secara teratur untuk memastikan VM yang mendasar sudah diperbarui pada fitur keamanan dan patch sistem lainnya. Selama proses peningkatan, AKS membuat node yang menghosting pod sementara, sedangkan node yang ditingkatkan ditutup dan dikosongkan. Node sementara itu diberi alamat IP dari subnet kluster. Pastikan Anda memiliki cukup ruang alamat untuk alamat IP simpul sementara ini.

  Untuk pod, Anda mungkin memerlukan lebih banyak alamat tergantung pada strategi Anda. Untuk pembaruan bergulir, Anda memerlukan alamat untuk pod sementara yang menjalankan beban kerja saat pod aktual diperbarui. Jika Anda menggunakan strategi pengganti, pod akan dihapus, dan yang baru dibuat. Jadi, alamat yang terkait dengan pod lama digunakan kembali.

• Skalabilitas

  Pertimbangkan jumlah node dari semua sistem dan node pengguna dan batas skalabilitas maksimum mereka. Misalkan Anda ingin meningkatkan sebesar 400%. Anda memerlukan empat kali jumlah alamat untuk semua node yang diskalakan.

  Dalam arsitektur ini, sumber daya menghubungi setiap pod secara langsung. Jadi, setiap pod membutuhkan alamat individual. Skalabilitas pod memengaruhi perhitungan alamat. Keputusan tersebut tergantung pada pilihan Anda tentang jumlah pod yang ingin Anda kembangkan.

• Alamat Private Link

  Faktor dalam alamat yang diperlukan untuk komunikasi dengan layanan Azure lainnya melalui Private Link. Arsitektur ini memiliki dua alamat yang ditetapkan untuk tautan ke Container Registry dan Key Vault.

• Azure mencadangkan alamat tertentu untuk penggunaannya. Alamat tersebut tidak bisa ditetapkan.

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 kumpulan simpul pengguna satu sama lain. Ketika Anda melakukannya, itu menghasilkan lebih banyak subnet yang berukuran lebih kecil. Selain itu, sumber daya ingress mungkin lebih kompleks, dan akibatnya Anda mungkin memerlukan beberapa pengontrol ingress yang memerlukan alamat IP tambahan.

Untuk serangkaian pertimbangan lengkap untuk arsitektur ini, lihat Topologi jaringan garis besar AKS.

Untuk informasi terkait perencanaan IP untuk kluster AKS, lihat Merencanakan pengalamatan IP untuk kluster Anda.

Untuk informasi selengkapnya tentang pertimbangan perencanaan alamat IP yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat kontainer Windows di AKS.

Fitur add-on dan pratinjau

Kubernetes dan AKS terus berkembang, dengan siklus rilis yang lebih cepat daripada perangkat lunak untuk lingkungan lokal. Arsitektur dasar ini bergantung pada fitur pratinjau AKS tertentu dan add-on AKS. Berikut perbedaan antara keduanya:

• Tim AKS menjelaskan fitur pratinjau sebagai dikirim dan disempurnakan karena banyak fitur pratinjau tetap berada dalam status tersebut hanya selama beberapa bulan sebelum pindah ke fase ketersediaan umum (GA).

• Add-on dan ekstensi AKS menyediakan fungsionalitas tambahan yang didukung. AKS mengelola instalasi, konfigurasi, dan siklus hidup mereka.

Arsitektur garis besar ini tidak menyertakan setiap fitur pratinjau atau add-on. Sebaliknya, hanya mencakup yang menambahkan nilai signifikan ke kluster tujuan umum. Karena fitur-fitur ini keluar dari pratinjau, arsitektur garis besar 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, termasuk melacak versi yang tersedia dan menginstal pembaruan setelah meningkatkan versi Kubernetes kluster.

Referensi gambar kontainer

Selain beban kerja, kluster mungkin berisi beberapa gambar lain, seperti pengontrol ingress. Beberapa gambar tersebut mungkin berada di registri publik. Pertimbangkan poin-poin ini saat Anda menarik gambar ke kluster Anda.

• Autentikasi kluster untuk menarik gambar.

• Impor gambar publik ke dalam registri kontainer yang selaras dengan tujuan tingkat layanan (SLO), jika Anda menggunakan gambar publik. Jika tidak, gambar mungkin mengalami masalah ketersediaan yang tidak terduga. Jika gambar tidak tersedia saat Anda membutuhkannya, itu dapat menyebabkan masalah operasional. Berikut adalah beberapa manfaat menggunakan registri kontainer privat, seperti Azure Container Registry, alih-alih registri publik:

  • Anda dapat memblokir akses tidak sah ke gambar Anda.
  • Anda tidak memiliki dependensi yang menghadap publik.
  • Anda dapat mengakses log penarikan gambar untuk memantau aktivitas dan masalah konektivitas triase.
  • Anda dapat memanfaatkan pemindaian kontainer terintegrasi dan kepatuhan gambar.

• Tarik gambar dari registri resmi. Anda dapat menerapkan pembatasan ini melalui Azure Policy. Dalam implementasi referensi ini, kluster hanya menarik gambar dari instans Container Registry yang disebarkan.

Mengonfigurasi komputasi untuk kluster dasar

Di AKS, setiap kumpulan node dipetakan ke set skala mesin virtual. Node adalah VM di setiap kumpulan node. Pertimbangkan untuk menggunakan ukuran VM yang lebih kecil untuk kumpulan node sistem agar meminimalkan biaya. Implementasi referensi ini menyebarkan kumpulan node sistem dengan tiga node DS2_v2. Ukuran itu cukup untuk memenuhi beban pod sistem yang diharapkan. Disk sistem operasi adalah 512 GB.

Untuk kumpulan node pengguna, berikut adalah beberapa pertimbangan:

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

• 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 mesin virtual di Azure.

• Menyebarkan setidaknya dua node. Dengan begitu, beban kerja memiliki 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 oleh tim desain Anda. Berdasarkan persyaratan bisnis, arsitektur ini menggunakan DS4_v2 untuk beban kerja produksi. Untuk menurunkan biaya, Anda dapat menurunkan ukuran ke DS3_v2, yang merupakan rekomendasi minimum.

• Asumsikan bahwa beban kerja Anda mengonsumsi hingga 80% dari setiap simpul saat merencanakan kapasitas untuk kluster Anda. Sisanya 20% dicadangkan untuk layanan AKS.

• Atur pod maksimum per node berdasarkan perencanaan kapasitas Anda. Jika Anda mencoba membuat garis besar kapasitas, mulailah dengan nilai 30. Sesuaikan nilai tersebut berdasarkan persyaratan beban kerja, ukuran node, dan kendala IP Anda.

Mengintegrasikan ID Microsoft Entra untuk kluster

Mengamankan akses ke dan dari kluster sangat penting. Pikirkan dari perspektif kluster saat Anda membuat pilihan keamanan:

• Akses dalam ke luar. Pertimbangkan akses AKS ke komponen Azure seperti infrastruktur jaringan, Container Registry, dan Key Vault. Otorisasi hanya sumber daya yang harus diakses kluster.
• Akses luar ke dalam. Menyediakan akses identitas ke kluster Kubernetes. Hanya otorisasi entitas eksternal yang diizinkan mengakses server API Kubernetes dan Azure Resource Manager.

Akses AKS ke Azure

Ada dua cara untuk mengelola akses AKS ke Azure melalui ID Microsoft Entra: perwakilan 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.

Kami menyarankan agar Anda mengaktifkan dan menggunakan identitas terkelola sehingga kluster dapat berinteraksi dengan sumber daya Azure eksternal melalui ID Microsoft Entra. Bahkan jika Anda tidak segera menggunakan integrasi MICROSOFT Entra ID, Anda dapat menggabungkannya nanti.

Secara default, ada dua identitas utama yang digunakan oleh kluster: identitas kluster dan identitas kubelet. Komponen sarana kontrol AKS menggunakan identitas kluster untuk mengelola sumber daya kluster termasuk load balancer ingress, dan 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 mengharuskan kluster untuk mendapatkan kredensial registri. Jika Anda tidak menggunakan identitas terkelola, maka Anda dapat menyimpan informasi tersebut dalam bentuk objek rahasia Kubernetes dan menggunakan imagePullSecrets untuk mengambil rahasia. Kami tidak merekomendasikan pendekatan ini karena kompleksitas keamanan. Anda tidak hanya memerlukan pengetahuan sebelumnya tentang rahasia, Anda juga perlu menyimpan rahasia itu dalam alur DevOps. Alasan lain kami tidak merekomendasikan pendekatan ini adalah overhead operasional untuk mengelola rotasi rahasia. Sebagai gantinya, berikan AcrPull akses ke identitas terkelola kubelet kluster ke registri Anda. Pendekatan ini mengatasi kekhawatiran.

Dalam arsitektur ini, kluster mengakses sumber daya Azure yang diamankan MICROSOFT Entra ID dan kluster melakukan operasi yang mendukung identitas terkelola. Tetapkan kontrol akses berbasis peran Azure (Azure RBAC) dan izin ke identitas terkelola kluster, tergantung pada operasi yang dilakukan kluster. Kluster mengautentikasi dirinya sendiri ke ID Microsoft Entra dan kemudian diizinkan atau ditolak akses berdasarkan peran yang ditetapkan untuknya. 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.

• Memantau peran Penerbit Metrik. Mengelola kemampuan kluster untuk mengirim metrik ke Azure Monitor.

• Peran AcrPull. Mengelola kemampuan kluster untuk menarik gambar dari instans Azure 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 Izin peran kluster yang tersedia.

AKS mendukung akses Kubernetes dengan menggunakan MICROSOFT Entra ID dengan dua cara. Yang pertama adalah dengan menggunakan MICROSOFT Entra ID sebagai idP yang terintegrasi dengan sistem RBAC Kubernetes asli. Metode lain menggunakan Azure RBAC asli untuk mengontrol akses kluster. Bagian berikut merinci kedua pendekatan.

Kaitkan RBAC Kubernetes dengan ID Microsoft Entra

Kubernetes mendukung RBAC melalui:

• Sekumpulan izin yang Anda tentukan dengan menggunakan Role objek atau ClusterRole untuk izin di seluruh kluster.

• Pengikatan 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. Ikat peran tersebut ke pengguna dan grup Microsoft Entra untuk menggunakan direktori perusahaan untuk mengelola akses. Untuk informasi selengkapnya, lihat Menggunakan RBAC Kubernetes dengan integrasi Microsoft Entra.

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

Menggunakan Azure RBAC guna otorisasi Kubernetes

Alih-alih menggunakan RBAC asli Kubernetes, ClusterRoleBindings dan RoleBindings untuk otorisasi dengan autentikasi Microsoft Entra terintegrasi, kami sarankan Anda menggunakan penetapan peran Azure RBAC dan Azure. Pendekatan ini memberlakukan pemeriksaan otorisasi pada kluster. Anda bahkan dapat menetapkan peran ini di lingkup 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.

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 akses pengguna ke kluster. Metode ini berbasis sertifikat dan dilakukan di luar penyedia identitas utama Anda, yang membuat kontrol akses dan tata kelola pengguna terpusat Anda sulit. Selalu kelola akses ke kluster Anda dengan menggunakan ID Microsoft Entra, dan konfigurasikan kluster Anda untuk menonaktifkan akses akun lokal secara eksplisit.

Dalam implementasi referensi ini, akses akun kluster lokal secara eksplisit dinonaktifkan saat sistem menyebarkan kluster.

Mengintegrasikan ID Microsoft Entra 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 ID Microsoft Entra. Misalnya, beban kerja menyimpan file di Azure Storage. Ketika perlu mengakses file-file tersebut, pod mengautentikasi dirinya sendiri terhadap sumber daya sebagai identitas terkelola Azure.

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

Menyebarkan sumber daya ingress

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

• Load balancer internal, dikelola oleh AKS. Load balancer 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 melebihi keamanan lapisan transportasi (TLS). Untuk informasi selengkapnya tentang enkripsi TLS untuk lalu lintas masuk, lihat Arus lalu lintas masuk.

• Pengontrol ingress. Contoh ini menggunakan Traefik. Ini berjalan di kumpulan node pengguna di kluster. Ini menerima lalu lintas dari penyeimbang beban internal, mengakhiri TLS, dan meneruskannya ke pod beban kerja melalui HTTP.

Pengontrol ingress adalah komponen penting dari kluster. Pertimbangkan poin-poin berikut saat 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 readinessProbe dan livenessProbe pengaturan yang memantau kesehatan pod pada interval yang ditentukan. Pengontrol ingress harus mengirim sinyal yang menunjukkan kesehatan pod.

• Pertimbangkan untuk membatasi akses pengontrol ingress ke sumber daya tertentu dan kemampuan untuk melakukan tindakan tertentu. 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 .

Untuk informasi selengkapnya tentang desain ingress untuk kontainer Windows pada AKS dalam arsitektur referensi garis besar, lihat kontainer Windows di AKS.

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 meliputi:

• Lalu lintas masuk dari klien ke beban kerja yang berjalan di kluster.

• Keluarkan lalu lintas 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 arsitektur ini.

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

Arus lalu lintas ingress

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 dalam diagram berikut.

Unduh file Visio arsitektur ini.

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

2. Application Gateway memiliki firewall aplikasi web 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 firewall aplikasi web Application Gateway perlu memeriksa 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 pemeriksaan firewall aplikasi web dan menjalankan aturan perutean yang meneruskan lalu lintas ke back end yang dikonfigurasi.

3. Saat lalu lintas berpindah dari Application Gateway ke ujung belakang, lalu lintas dienkripsi lagi dengan sertifikat TLS lain, yang merupakan kartubebas untuk *.aks-ingress.contoso.com, seperti yang diteruskan ke load balancer internal. Enkripsi ulang ini membantu memastikan bahwa lalu lintas yang tidak aman tidak mengalir ke subnet kluster.

4. Pengontrol ingress menerima lalu lintas terenkripsi melalui penyeimbang beban. Pengontrol adalah titik penghentian TLS lain untuk *.aks-ingress.contoso.com dan meneruskan lalu lintas ke pod beban kerja melalui HTTP. Sertifikat disimpan di 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 di setiap hop melalui pod beban kerja. Pastikan untuk mengukur performa, latensi, dan efek operasional saat membuat keputusan untuk mengamankan lalu lintas pod-ke-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 menyarankan agar semua lalu lintas keluar dari kluster berkomunikasi melalui Azure Firewall. Atau Anda dapat menggunakan appliance virtual jaringan serupa Anda sendiri. Kami tidak merekomendasikan penggunaan 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, semua lalu lintas keluar dari kluster bergerak melalui Firewall. Anda dapat menerapkan konfigurasi ini dengan rute yang ditentukan pengguna (UDR). Lompatan berikutnya dari rute adalah alamat IP privat Azure Firewall. Azure Firewall memutuskan apakah akan memblokir atau mengizinkan lalu lintas keluar. Keputusan tersebut didasarkan pada aturan tertentu yang Anda tentukan di Azure Firewall atau aturan inteligensi ancaman bawaan.

Alternatif untuk Azure Firewall adalah menggunakan fitur proksi HTTP AKS. Semua lalu lintas yang meninggalkan kluster masuk ke alamat IP proksi HTTP, yang meneruskan lalu lintas atau menjatuhkannya.

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

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. Keuntungannya adalah bahwa subnet tertentu mencapai layanan secara langsung, dan lalu lintas antara kluster dan layanan tidak melalui internet. Kelemahannya adalah 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.

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 disertakan dalam layanan target. Karena lalu lintas ini melewati alamat IP statis firewall, Anda dapat menambahkan alamat tersebut ke daftar izin IP layanan. Salah satu kelemahannya adalah Azure Firewall kemudian membutuhkan lebih banyak aturan untuk memastikan hanya mengizinkan lalu lintas dari subnet tertentu. Perhitungkan alamat tersebut saat Anda merencanakan beberapa alamat IP untuk lalu lintas keluar dengan Azure Firewall. Jika tidak, Anda bisa mencapai kelelahan port. Untuk informasi selengkapnya tentang perencanaan untuk beberapa alamat IP, lihat Membuat Azure Firewall dengan beberapa alamat IP.

Untuk informasi tentang pertimbangan keluar khusus Windows dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat kontainer Windows di AKS.

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 secara yudisial, atau Anda mungkin memiliki situasi di mana aliran jaringan penting diblokir. Hanya izinkan jalur komunikasi tertentu, sesuai kebutuhan, seperti lalu lintas antara pengontrol masuk dan beban kerja. Untuk informasi selengkapnya, lihat Kebijakan jaringan.

Aktifkan kebijakan jaringan saat Anda memprovisikan kluster karena Anda tidak dapat menambahkannya nanti. Anda memiliki beberapa pilihan untuk teknologi yang mengimplementasikan NetworkPolicy. Kami merekomendasikan kebijakan jaringan Azure, yang memerlukan Azure Container Networking Interface (CNI). Untuk informasi selengkapnya, lihat catatan berikut ini. Opsi lain termasuk kebijakan jaringan Calico, opsi sumber terbuka terkenal. Pertimbangkan Calico jika Anda perlu mengelola kebijakan jaringan di seluruh kluster. Calico tidak termasuk dalam dukungan Azure 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 pada kluster, seperti permintaan untuk membuat sumber daya untuk menskalakan kluster. Contoh sumber daya tersebut termasuk kumpulan agen build dalam alur DevOps, instans Azure Bastion dalam subnet Azure Bastion, dan kumpulan simpul itu sendiri. Alih-alih menerima lalu lintas manajemen ini dari semua alamat IP, gunakan fitur rentang IP resmi AKS untuk hanya mengizinkan lalu lintas dari rentang IP resmi Anda ke server API

Untuk informasi selengkapnya, lihat Menentukan rentang IP resmi server API.

Untuk lapisan kontrol lain, dengan biaya kompleksitas ekstra, Anda dapat menyediakan kluster AKS privat. Dengan menggunakan kluster privat, Anda dapat membantu memastikan lalu lintas jaringan antara server API dan kumpulan simpul Anda tetap berada di jaringan privat saja dan tidak pernah terekspos ke internet. Untuk informasi selengkapnya, lihat kluster privat AKS.

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 keluar dari alur penyebaran. Dalam arsitektur ini, firewall Key Vault diaktifkan dan dikonfigurasi, dan Private Link digunakan saat menyambungkan dari sumber daya di Azure yang perlu mengakses rahasia dan sertifikat.

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

Model izin Azure RBAC untuk Key Vault memungkinkan Anda menetapkan identitas beban kerja ke penetapan peran Pengguna Rahasia Key Vault atau Pembaca Key Vault, dan mengakses rahasia. Untuk informasi selengkapnya, lihat Mengakses Key Vault dengan menggunakan RBAC.

Mengakses rahasia kluster

Anda perlu 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 rahasia dari sistem file volume.

Driver CSI memiliki banyak penyedia untuk mendukung berbagai toko terkelola. Implementasi ini menggunakan Key Vault dengan driver CSI penyimpanan rahasia. Add-on mengambil sertifikat TLS dari Key Vault dan memuat driver di 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 perlu menyimpan status, sebaiknya pertahankan di luar kluster. Panduan untuk status beban kerja berada di luar cakupan artikel ini.

Untuk informasi selengkapnya, lihat Opsi Microsoft Azure 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 untuk:

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

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

• Apakah Anda ingin menetapkan kumpulan kebijakan, juga disebut 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.

• Ingin Mengaudit atau Menolak tindakan? Dalam mode Audit , tindakan diizinkan tetapi ditandai sebagai Tidak Patuh. Memiliki proses untuk memeriksa status yang tidak patuh pada irama reguler dan mengambil tindakan yang diperlukan. Dalam mode Tolak, tindakan diblokir karena melanggar kebijakan. Berhati-hatilah saat memilih mode ini, karena bisa terlalu ketat agar beban kerja berfungsi.

• Apakah Anda memiliki area dalam beban kerja Anda yang tidak sesuai dengan desain? Azure Policy memiliki kemampuan untuk menentukan namespace Layanan Kubernetes yang dikecualikan dari penegakan kebijakan. Kami menyarankan agar Anda masih menerapkan kebijakan dalam mode Audit sehingga Anda mengetahui instans tersebut.

• 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 Membuat dan menetapkan definisi kebijakan kustom.

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

• Apakah Anda menetapkan kebijakan Azure ke cakupan tertentu? Pastikan kebijakan produksi juga divalidasi terhadap lingkungan praproduksi Anda. Jika tidak, saat 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 mendapatkan visibilitas ke dalam 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 kebiasaan yang sering dilakukan Anda sendiri. Gabungkan kebijakan beban kerja Anda menjadi satu tugas.

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

Untuk informasi selengkapnya tentang pertimbangan Azure Policy khusus Windows, lihat kontainer Windows pada artikel manajemen kebijakan AKS.

Skalabilitas node dan pod

Dengan meningkatnya permintaan, Kubernetes dapat meluaskan skala dengan menambahkan lebih banyak pod ke simpul yang ada, melalui autoscaling pod 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 merekomendasikan pendekatan penskalaan otomatis karena beberapa mekanisme manual tersebut 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. Untuk informasi selengkapnya tentang skenario penyetelan performa menggunakan AKS, lihat Skenario penyetelan performa: Transaksi bisnis terdistribusi.

Penskala pod horizontal

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

Di sumber daya HPA, sebaiknya atur 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 di luar kotak. 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.

Mungkin ada kondisi balapan di mana HPA memeriksa sebelum operasi penskalakan selesai. Hasilnya mungkin adalah perhitungan rasio yang salah. Untuk informasi selengkapnya, lihat Cooldown 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 penskala Azure Monitor, yang merupakan cara mudah untuk menskalakan beban kerja KEDA berdasarkan metrik Azure Monitor.

Autoscaler kluster

Penskala otomatis kluster adalah komponen add-on AKS yang menskalakan jumlah node dalam kumpulan node. Tambahkan selama provisi kluster. Anda memerlukan penskala otomatis kluster terpisah untuk setiap kumpulan node pengguna.

Penjadwal Kubernetes memicu autoscaler kluster. Ketika penjadwal Kubernetes gagal menjadwalkan pod karena keterbatasan sumber daya, penskala otomatis secara otomatis menyediakan node baru di kumpulan node. Sebaliknya, penskala otomatis kluster memeriksa kapasitas node yang tidak terpakai. Jika node tidak berjalan pada kapasitas yang diharapkan, pod akan 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.

Untuk informasi tentang pertimbangan penskalaan khusus Windows yang disertakan dalam arsitektur referensi garis besar ini, lihat artikel Kontainer Windows di AKS .

Keputusan kelangsungan bisnis

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

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 membutuhkan ketersediaan yang lebih tinggi, sediakan lebih banyak node.

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 ternoda dengan CriticalAddonsOnly taint.

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 sangat berkurang jika pod Anda tidak dapat 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 Pod.

Konfigurasikan beberapa replika dalam penerapan 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 permintaan dan batas pod diatur dengan benar pada penyebaran. Untuk informasi selengkapnya, lihat Menerapkan kuota sumber daya.

Mengatur permintaan dan batas pod: Mengatur permintaan dan batas memungkinkan Kubernetes untuk mengalokasikan sumber daya CPU dan memori secara efisien ke pod, dan memungkinkan Anda memiliki 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 dapat menyebabkan ketidakstabilan dalam kluster.

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

Zona ketersediaan dan dukungan multi-wilayah

Untuk melindungi dari beberapa jenis pemadaman, gunakan zona ketersediaan jika wilayah mendukungnya. Baik komponen bidang kontrol dan node di kumpulan node kemudian dapat menyebar di seluruh zona. Jika seluruh zona tidak tersedia, node di zona lain di dalam wilayah masih tersedia. Setiap kumpulan node memetakan ke set skala mesin virtual terpisah, yang mengelola instans node dan skalabilitas. Layanan AKS mengelola operasi dan konfigurasi set skala. Berikut adalah beberapa pertimbangan saat Anda mengaktifkan beberapa zona:

• Seluruh infrastruktur: Pilih wilayah yang mendukung zona ketersediaan. Untuk informasi selengkapnya, lihat Batasan. Untuk memiliki SLA waktu aktif, Anda perlu memilih tingkat Standar atau Premium. SLA waktu aktif lebih besar saat menggunakan zona ketersediaan.

• Kluster: Anda hanya dapat mengatur zona ketersediaan saat membuat kumpulan simpul. Mereka tidak dapat 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.

  Dukungan beberapa zona tidak hanya berlaku untuk kumpulan simpul, tetapi juga sarana kontrol. Sarana kontrol AKS mencakup zona yang diminta, seperti kumpulan simpul. Jika Anda tidak menggunakan dukungan zona di kluster Anda, komponen sarana kontrol tidak dijamin tersebar di seluruh zona ketersediaan.

• Sumber daya dependen: Untuk manfaat zona lengkap, semua dependensi layanan juga harus mendukung zona. Jika layanan dependen tidak mendukung zona, ada kemungkinan bahwa kegagalan zona dapat menyebabkan layanan tersebut gagal.

  Misalnya, disk terkelola tersedia di zona tempat disk tersebut disediakan. Jika kegagalan terjadi, simpul mungkin berpindah ke zona lain, tetapi disk terkelola tidak berpindah dengan simpul ke zona tersebut.

Untuk kesederhanaan dalam arsitektur ini, AKS disebarkan ke satu wilayah dengan kumpulan simpul yang mencakup zona ketersediaan satu, dua, dan tiga. 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

Saat Anda mengaktifkan zona ketersediaan, cakupannya tidak cukup jika seluruh wilayah gagal. Untuk mendapatkan ketersediaan yang lebih tinggi, jalankan beberapa kluster AKS di berbagai wilayah.

• Lebih suka 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 waktu. 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 membuat penyebaran multi-wilayah lebih mudah.

• 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 direplikasi 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 Memilih load balancer.

Pemulihan dari bencana

Jika kegagalan terjadi di wilayah utama, idealnya, Anda dapat dengan cepat membuat instans baru di wilayah lain. Berikut beberapa rekomendasi kami:

• Gunakan beberapa wilayah. Jika wilayah utama Anda memiliki wilayah berpasangan, gunakan pasangan tersebut. Jika tidak, pilih wilayah berdasarkan persyaratan residensi dan latensi data Anda.

• Gunakan beban kerja nonstateful yang dapat Anda replikasi secara efisien. Jika Anda perlu menyimpan status di 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.

• Provisikan setiap layanan Azure dengan menggunakan fitur yang mendukung pemulihan bencana. Misalnya, dalam arsitektur ini, Container Registry diaktifkan untuk replikasi geografis. Jika wilayah gagal, Anda masih dapat menarik gambar dari wilayah yang direplikasi.

• 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 menyediakan kluster baru dan mengembalikannya ke status operasi melalui bootstrapping kluster berbasis operasi Git, 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 perlu menginstal solusi yang sesuai dengan persyaratan bisnis Anda dalam kluster. Agen ini bertanggung jawab untuk mendorong status sumber daya kluster ke tujuan memilih dan mengoordinasikan rekam jepret 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 cadangan 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 menyertakan akun Azure Storage, vault dan konfigurasi Azure Backup, dan fitur akses tepercaya. Sebagai gantinya, operasi Git dikombinasikan dengan niat untuk menjalankan beban kerja tanpa status adalah solusi pemulihan.

Pilih dan validasi solusi cadangan yang memenuhi tujuan bisnis Anda, termasuk tujuan titik pemulihan dan tujuan waktu pemulihan yang ditentukan. Tentukan proses pemulihan Anda dalam runbook tim dan praktikkan untuk semua beban kerja penting bisnis.

Kubernetes API server SLA

Anda dapat menggunakan AKS sebagai layanan gratis, tetapi tingkatan tersebut tidak menawarkan SLA yang didukung secara finansial. Untuk mendapatkan SLA, Anda harus memilih tingkat Standar. Sebaiknya semua kluster produksi menggunakan tingkat Standar. Pesan tingkat Gratis untuk kluster praproduksi dan tingkat Premium hanya untuk beban kerja misi penting. Saat Anda menggunakan zona ketersediaan Azure, SLA server API Kubernetes lebih tinggi. Kumpulan simpul dan sumber daya lainnya tercakup dalam SLA mereka sendiri. Untuk informasi selengkapnya tentang SLA tertentu untuk setiap layanan, lihat SLA untuk layanan online.

Tradeoff

Ada tradeoff biaya-ke-ketersediaan untuk menyebarkan arsitektur di seluruh zona dan terutama 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 latensi jaringan tambahan dalam komunikasi simpul antara zona atau 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 zonal, 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 metrik

Kami merekomendasikan wawasan kontainer Azure Monitor untuk memantau performa beban kerja kontainer karena Anda dapat melihat peristiwa secara real time. Fitur ini menangkap log kontainer dari pod yang berjalan dan mengumpulkannya 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 wawasan kontainer untuk memantau performa saat pod diskalakan. Ini termasuk telemetri yang penting untuk pemantauan, analisis, dan visualisasi data yang dikumpulkan. Wawasan kontainer mengidentifikasi tren dan memungkinkan Anda mengonfigurasi pemberitahuan untuk menerima pemberitahuan proaktif tentang masalah kritis.

Sebagian besar beban kerja yang dihosting dalam pod memancarkan metrik Prometheus. Wawasan kontainer dapat diintegrasikan dengan Prometheus. Anda dapat melihat metrik aplikasi dan beban kerja yang dikumpulkan dari simpul dan Kubernetes.

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

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

• ClusterAutoscaler: dapatkan pengamatan ke dalam operasi penskalaan dengan pengelogan. Untuk informasi selengkapnya, lihat Mengambil log dan status penskala otomatis kluster.
• KubeControllerManager: mendapatkan pengamatan ke dalam interaksi antara Kubernetes dan sarana kontrol Azure.
• kube-audit-admin: dapatkan pengamatan menjadi aktivitas yang memodifikasi kluster Anda. Tidak ada alasan untuk memiliki keduanya kube-audit dan kube-audit-admin diaktifkan. kube-audit adalah superset dari kube-audit-admin yang mencakup operasi nonmodifikasi (baca) juga.
• guard: ambil audit Microsoft Entra ID dan Azure RBAC.

Mungkin berguna bagi Anda untuk mengaktifkan kategori log lain, seperti KubeScheduler atau kube-audit, selama kluster awal atau pengembangan siklus hidup beban kerja. Penskalaan otomatis kluster tambahan, penempatan dan penjadwalan pod, dan data serupa dapat membantu Anda memecahkan masalah 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 di Azure Monitor.

Meskipun Azure Monitor menyertakan sekumpulan kueri log yang sudah ada untuk memulai, 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 kueri. Pustaka kueri kustom Anda memberikan lebih banyak pengamatan ke dalam kesehatan dan performa kluster AKS Anda. Ini mendukung pencapaian SLA Anda.

Untuk informasi selengkapnya tentang praktik terbaik pemantauan kami untuk AKS, lihat Memantau AKS dengan Azure Monitor.

Untuk informasi selengkapnya tentang pertimbangan pemantauan khusus Windows, lihat Kontainer Windows di AKS.

Metrik jaringan

Metrik jaringan tingkat kluster dasar tersedia melalui platform asli dan metrik Prometheus. Anda selanjutnya dapat menggunakan add-on Network Observability untuk mengekspos metrik jaringan di tingkat simpul. Sebagian besar kluster harus menggunakan add-on Network Observability untuk menyediakan kemampuan pemecahan masalah jaringan tambahan, dan untuk mendeteksi penggunaan atau masalah jaringan yang tidak terduga di tingkat node.

Untuk beban kerja yang sangat sensitif terhadap kehilangan paket Protokol Kontrol Transmisi (TCP) atau Protokol Datagram Pengguna (UDP), latensi, atau tekanan DNS, metrik jaringan tingkat pod penting. Di AKS, Anda dapat menemukan tingkat detail tersebut dengan fitur Advanced Network Observability . Sebagian besar beban kerja tidak memerlukan kedalaman pengamatan jaringan ini. Anda tidak boleh menginstal add-on Advanced Network Observability kecuali pod Anda menuntut jaringan yang sangat dioptimalkan, dengan sensitivitas turun ke tingkat paket.

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

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 (misalnya, Kubernetes 1.30.3 hingga 1.30.7 atau Kubernetes 1.30.7 hingga 1.31.1), yang mungkin disertakan dengan perubahan dan penghentian API Kube. 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 komprehensif tentang patching 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 gambar simpul 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 menguji pembaruan di lingkungan praproduksi dan mengevaluasi kompatibilitasnya pada kluster baru. Setelah itu, sebarkan stempel replika produksi yang menyertakan versi AKS dan VHD kumpulan simpul yang diperbarui. Ketika kluster produksi baru siap, kluster lama dikosongkan dan akhirnya dinonaktifkan.

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 di tempat

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 terencana 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 anggaran gangguan pod sehingga aplikasi Anda tetap stabil selama peningkatan bergulir. Tetapi jangan mengonfigurasi anggaran agar sangat agresif sehingga mereka memblokir peningkatan node agar tidak terjadi, karena sebagian besar peningkatan memerlukan proses cordon dan pengurasan pada setiap simpul.
• Konfirmasikan kuota sumber daya Azure dan ketersediaan sumber daya. Peningkatan di tempat menyebarkan instans node baru, yang dikenal sebagai node lonjakan, sebelum simpul lama dihapus. Ini berarti kuota Azure dan ruang alamat IP harus tersedia untuk simpul baru. Nilai lonjakan 33% adalah titik awal yang baik untuk sebagian besar beban kerja.
• Uji kompatibilitas dengan alat, seperti jala layanan atau agen keamanan yang Anda tambahkan ke kluster Anda. Dan uji komponen beban kerja Anda, seperti pengontrol ingress, jala layanan, dan pod beban kerja Anda. Lakukan pengujian di lingkungan praproduksi.

Peningkatan di tempat untuk simpul

NodeImage Gunakan saluran peningkatan otomatis untuk peningkatan gambar OS simpul. Saluran ini mengonfigurasi kluster Anda untuk memperbarui VHD pada setiap simpul dengan pembaruan tingkat simpul. Microsoft menguji pembaruan terhadap versi AKS Anda. Untuk simpul Windows, pembaruan terjadi sekitar sekali per bulan. Untuk simpul Linux, pembaruan ini 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 apa pun sistem operasi gambar simpul yang Anda gunakan untuk membantu memastikan aplikasi 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 irama patching yang lebih agresif dan kluster Anda dapat mentolerir potensi gangguan, gunakan SecurityPatch saluran peningkatan sebagai gantinya. Microsoft juga menguji pembaruan ini. Pembaruan hanya diterbitkan jika ada peningkatan keamanan yang dianggap cukup penting oleh Microsoft untuk dirilis sebelum peningkatan gambar simpul terjadwal berikutnya. Saat menggunakan SecurityPatch saluran, Anda juga mendapatkan pembaruan yang NodeImage diterima saluran. Opsi SecurityPatch saluran masih menghormati jendela pemeliharaan Anda, jadi pastikan jendela pemeliharaan Anda memiliki celah yang lebih sering (seperti harian atau setiap hari lainnya) untuk mendukung pembaruan keamanan yang tidak terduga ini.

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

Pembaruan di tempat 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 atau N-2. Sangat penting untuk meningkatkan ke versi terbaru Kubernetes karena versi baru sering dirilis.

Sebagian besar kluster harus dapat melakukan pembaruan versi AKS di tempat dengan cukup hati-hati dan ketat. 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 pendekatan penyebaran kluster AKS berwarna biru-hijau alih-alih mengikuti rekomendasi yang tersisa.

Sebaiknya hindari fitur peningkatan otomatis kluster 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' melalui pendekatan dukungan jangka panjang.

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

Anda mungkin akhirnya mencapai titik keyakinan dengan rilis Kubernetes, rilis AKS, kluster Anda, komponen tingkat klusternya, dan beban kerja, untuk menjelajahi fitur peningkatan otomatis. Untuk sistem produksi, jarang sekali bergerak melampaui patch. Selain itu, saat secara otomatis memutakhirkan versi AKS Anda, periksa juga pengaturan versi AKS infrastruktur sebagai kode (IaC) untuk kluster Anda sehingga 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. Berikut adalah beberapa sumber daya:

• Pertahanan Microsoft untuk Kontainer untuk 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 real-time untuk aktivitas yang mencurigakan.
• Konsep Keamanan AKS untuk aplikasi dan kluster 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 kluster dan operasi beban kerja (DevOps), lihat pilar prinsip desain Keunggulan Operasional.

Klaster bootstrapping

Setelah melakukan provisi, Anda memiliki kluster yang berfungsi, tetapi Anda mungkin masih memiliki beberapa langkah yang diperlukan sebelum Dapat menyebarkan beban kerja. Proses persiapan kluster Anda disebut bootstrapping. Bootstrapping dapat terdiri dari menyebarkan gambar prasyarat ke node kluster, membuat namespace, dan melakukan tugas lain yang memenuhi persyaratan kasus penggunaan organisasi Anda.

Untuk mengurangi kesenjangan antara kluster yang disediakan dan yang dikonfigurasi dengan benar, operator kluster harus memikirkan seperti apa proses bootstrapping unik mereka. Mereka perlu menyiapkan aset yang relevan terlebih dahulu. Misalnya, jika kured berjalan pada setiap simpul sebelum menyebarkan beban kerja aplikasi penting, operator kluster harus memverifikasi bahwa instans Container Registry yang berisi gambar Kured target, sudah ada sebelum mereka memprovisikan kluster.

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

• Ekstensi kluster GitOps Flux v2
• Pipelines
• Konfigurasi mandiri dengan FLUX atau CD Argo, misalnya

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 termasuk bootstrapping tersebut sebagai templat sumber daya untuk selaras dengan strategi IaC Anda.

Akhirnya, saat menggunakan ekstensi, kubectl tidak diperlukan untuk bagian mana pun dari proses bootstrapping. Anda dapat memesan akses berbasis kubectl untuk situasi perbaikan darurat. Antara templat untuk definisi sumber daya Azure dan bootstrapping manifes 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 dasar dan membangunnya. Tugas awal adalah mengonfigurasi jaringan. Provisikan jaringan virtual untuk hub dan spoke dan juga subnet dalam jaringan tersebut. Misalnya, spoke memiliki subnet terpisah untuk kumpulan simpul sistem dan pengguna dan sumber daya ingress. Sebarkan subnet untuk Azure Firewall di hub.

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

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. Anda dapat menggunakan Bicep, templat Azure Resource Manager (templat ARM), atau Terraform.

Pastikan untuk menyediakan 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

Alur untuk alur kerja dan penyebaran harus dapat membangun dan menyebarkan aplikasi secara terus menerus. Pembaruan harus disebarkan dengan aman dan cepat dan kembali 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 dan Jenkins.

Kluster CI/CD

Unduh file Visio 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 dan validasi baru pada versi tersebut sebelum menyebarkan ke produksi, pertimbangkan alur GitOps.

Bagian penting dari aliran CI/CD adalah bootstrapping kluster yang baru disediakan. 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 fluks, yang menggunakan satu atau beberapa operator dalam kluster untuk memicu penyebaran di dalam Kubernetes. Flux melakukan tugas-tugas ini:

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

Berikut adalah contoh yang menunjukkan cara mengotomatiskan konfigurasi kluster dengan GitOps dan Fluks:

Unduh file Visio arsitektur ini.

1. Pengembang menerapkan perubahan pada kode sumber, seperti file YAML konfigurasi, yang disimpan dalam repositori Git. Perubahan kemudian didorong ke server Git.

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

3. Flux mengenali perubahan konfigurasi dan menerapkan perubahan tersebut dengan menggunakan perintah kubectl.

4. Pengembang tidak memiliki akses 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. Melakukannya mensimulasikan perubahan dan mungkin mengidentifikasi masalah sebelum disebarkan ke produksi.

Jalankan pengujian dan validasi di setiap tahap sebelum 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 serupa sebagai produksi, dengan menggunakan alur 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.

Cost management

Mulailah dengan meninjau daftar periksa desain pengoptimalan biaya dan daftar rekomendasi yang diuraikan dalam Well-Architected Framework untuk AKS. Gunakan kalkulator harga Azure untuk memperkirakan biaya untuk layanan yang Anda gunakan dalam arsitektur. Untuk praktik terbaik lainnya, lihat Pengoptimalan Biaya.

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

Untuk informasi tentang pertimbangan manajemen biaya khusus Windows, lihat kontainer Windows di AKS.

Provisikan

• 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, penyimpanan, data log, dan sumber daya jaringan yang digunakan oleh kluster. Pertimbangkan untuk memilih VM yang lebih murah untuk kumpulan node sistem. Seri DS2_v2 adalah jenis VM khas untuk kumpulan simpul sistem.

• Jangan menggunakan konfigurasi yang sama untuk lingkungan pengembangan/pengujian 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 waktu aktif untuk beban kerja produksi. Tetapi ada penghematan untuk kluster yang dirancang untuk beban kerja dev/test atau eksperimental di mana ketersediaan tidak diperlukan untuk dijamin. Misalnya, SLO sudah cukup. Selain itu, jika beban kerja Anda mendukungnya, pertimbangkan untuk menggunakan kumpulan simpul spot khusus yang menjalankan VM spot.

  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 untuk 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 perangkat keras untuk kapasitas.

• Pertimbangkan bahwa ketika Anda mengaktifkan diagnostik pada kluster, itu dapat meningkatkan biaya.

• Berkomitmen untuk Instans Komputer Virtual Cadangan Azure satu tahun atau tiga tahun untuk mengurangi biaya simpul jika beban kerja Anda harus ada untuk jangka waktu yang lama. Untuk informasi selengkapnya, lihat Menghemat biaya dengan Azure Reserved Virtual Machine Instances.

• 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. Selain itu, jika kluster dibagikan di antara tim, tagihan balik build melaporkan per konsumen untuk mengidentifikasi biaya terukur atas layanan cloud bersama. Untuk informasi selengkapnya, lihat Menentukan taint, label, atau tag untuk kumpulan node.

• Harapkan biaya bandwidth tambahan jika beban kerja Anda multi-wilayah dan Anda mereplikasi data antar wilayah. Untuk informasi selengkapnya, 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 peringatan untuk mendapatkan notifikasi saat ambang batas tertentu terlampaui. Untuk informasi selengkapnya, lihat Membuat anggaran menggunakan templat.

Monitor

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

• Azure Advisor

• Microsoft Cost Management

Idealnya, pantau biaya Anda secara real time atau setidaknya pada irama biasa. Anda kemudian dapat mengambil tindakan sebelum akhir bulan ketika biaya sudah dihitung. Selain itu, pantau tren bulanan dari waktu ke waktu untuk tetap dalam 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 meteran penggunaan dalam metrik Azure Monitor.

Optimalkan

Bertindak berdasarkan rekomendasi yang disediakan oleh Azure Advisor. Ada cara lain untuk mengoptimalkan:

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

  Penting

  Mengubah pengaturan autoscaler kluster secara agresif, seperti pengaturan simpul minimum dan maksimum untuk kumpulan simpul, untuk memengaruhi biaya mungkin memiliki hasil yang kontraproduktif. Misalnya, jika scale-down-unneeded-time diatur ke 10 menit, dan pengaturan node minimum dan maksimum dimodifikasi setiap lima menit berdasarkan karakteristik beban kerja, jumlah simpul tidak akan pernah berkurang. Ini karena perhitungan waktu yang tidak diperlukan untuk setiap reset simpul karena pengaturan autoscaler kluster sedang disegarkan.

• Pilih SKU yang lebih rendah untuk kumpulan node, jika beban kerja Anda mendukungnya.

• Jika aplikasi tidak memerlukan penskalaan burst, pertimbangkan untuk mengukur kluster dengan ukuran yang tepat dengan menganalisis metrik kinerja dari waktu ke waktu.

• Jika beban kerja Anda mendukungnya, skalakan kumpulan simpul pengguna Anda menjadi 0 simpul saat tidak ada harapan untuk dijalankan. Selain itu, jika tidak ada beban kerja yang dijadwalkan untuk berjalan 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 terkait biaya lainnya, lihat harga AKS.

Langkah berikutnya

• Arsitektur layanan mikro AKS tingkat lanjut
• Garis besar AKS untuk kluster multiregion
• Kluster yang diatur AKS untuk PCI-DSS 3.2.1
• Kontainer Windows pada arsitektur referensi garis besar AKS

Sumber daya terkait

• Peta jalan AKS di GitHub
• Pengandalan Kubernetes
• Mengembangkan dan menyebarkan aplikasi di Kubernetes
• Ulasan Well-Architected Framework untuk AKS
• Akselerator zona pendaratan AKS
• Panduan operasi hari-2 AKS
• Arsitektur layanan mikro di AKS
• Menggunakan Azure Firewall untuk membantu melindungi kluster AKS
• Operasi Git untuk AKS
• Streaming data dengan AKS