Arsitektur dasar untuk klaster Azure Kubernetes Service (AKS)

Arsitektur referensi ini menyediakan arsitektur infrastruktur dasar yang direkomendasikan untuk menyebarkan kluster Azure Kubernetes Service (AKS) di Azure. Ini menggunakan prinsip desain kami dan didasarkan pada praktik terbaik arsitektur kami dari Azure Well-Architected Framework untuk memandu tim interdisipliner atau beberapa tim yang berbeda seperti jaringan, keamanan, dan identitas melalui penyebaran infrastruktur tujuan umum ini.

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

Arsitektur target dipengaruhi oleh kebutuhan bisnis Anda, dan akibatnya dapat bervariasi di antara konteks aplikasi yang berbeda. Ini harus dianggap sebagai titik awal Anda untuk tahap pra-produksi dan produksi.

Implementasi arsitektur ini juga tersedia di GitHub: Implementasi Referensi Garis Besar Azure Kubernetes Service (AKS). Anda dapat menggunakannya sebagai titik awal alternatif dan mengonfigurasinya berdasarkan kebutuhan Anda.

Konfigurasi Jaringan

Topologi jaringan
Merencanakan alamat IP
Menyebarkan Sumber daya ingress (masuk)

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-spoke. Hub dan spoke digunakan dalam jaringan virtual terpisah yang terhubung melalui peering. Beberapa keuntungan dari topologi ini adalah:

• Manajemen terpisah. Memungkinkan cara untuk menerapkan tata kelola dan mematuhi prinsip hak istimewa paling sedikit. Ini juga mendukung konsep zona pendaratan Azure dengan pemisahan tugas.

• Meminimalkan paparan langsung sumber daya Azure ke internet publik.

• Banyak organisasi yang beroperasi dengan topologi hub-spoke regional. Topologi jaringan hub-spoke dapat diperluas di masa depan dan memberikan isolasi beban kerja.

• Semua aplikasi web harus memerlukan layanan firewall aplikasi web (WAF) untuk membantu mengatur arus lalu lintas HTTP.

• Pilihan alami untuk beban kerja yang mencakup beberapa langganan.

• Ini membuat arsitektur dapat diperluas. Untuk mengakomodasi fitur atau beban kerja baru, spoke baru dapat ditambahkan tanpa mendesain ulang topologi jaringan.

• Sumber daya tertentu, seperti firewall dan DNS dapat dibagikan di seluruh jaringan.

• Selaras dengan zona pendaratan skala perusahaan Azure.

Unduh file Visio arsitektur ini.

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

Untuk meninjau perubahan desain jaringan yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Hub

Jaringan virtual hub adalah titik pusat konektivitas dan pengamatan. Hub selalu berisi Azure Firewall dengan kebijakan firewall global yang ditentukan oleh tim IT pusat Anda untuk menerapkan kebijakan firewall luas organisasi, Azure Bastion, subnet gateway untuk konektivitas VPN, dan Azure Monitor untuk pengamatan jaringan.

Dalam jaringan, tiga subnet disebarkan.

Subnet untuk menghosting Azure Firewall

Azure Firewall adalah firewall sebagai layanan. Firewall mengamankan lalu lintas jaringan. Tanpa lapisan keamanan ini, lalu lintas ini mungkin berkomunikasi dengan layanan pihak ketiga berbahaya yang dapat menyelundupkan data perusahaan sensitif. Azure Firewall Manager memungkinkan Anda 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 placeholder untuk gateway VPN atau 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 Bastion untuk mengakses sumber daya Azure dengan aman tanpa mengekspos sumber daya ke internet. Subnet ini hanya digunakan untuk manajemen dan operasi.

Spoke

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

Subnet untuk menghosting Azure Application Gateway

Azure Application Gateway adalah penyeimbang beban lalu lintas web yang beroperasi di Layer 7. Implementasi referensi menggunakan Application Gateway v2 SKU yang mengaktifkan Web Application Firewall (WAF). WAF mengamankan lalu lintas masuk dari serangan lalu lintas web umum, termasuk bot. Instans memiliki konfigurasi IP 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 akan memenuhi sumber daya ingress Kubernetes. Penyeimbang beban internal Azure ada di subnet ini. Untuk informasi selengkapnya, lihat Menggunakan load balancer internal dengan Azure Kubernetes Service (AKS).

Subnet untuk menghosting node kluster

AKS memelihara dua kelompok node yang terpisah (atau kumpulan node). 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 Private Link

Koneksi Azure Private Link dibuat untuk Azure Container Registry dan Azure Key Vault, sehingga layanan ini dapat diakses menggunakan titik akhir privat dalam jaringan virtual spoke. Titik akhir privat tidak memerlukan subnet khusus dan juga dapat ditempatkan di jaringan virtual hub. Dalam implementasi garis besar, mereka disebarkan ke subnet khusus dalam jaringan virtual spoke. Pendekatan ini mengurangi lalu lintas yang melewati koneksi jaringan yang di-peering, menyimpan sumber daya yang termasuk dalam kluster dalam jaringan virtual yang sama, dan memungkinkan Anda menerapkan aturan keamanan terperinci di tingkat subnet menggunakan kelompok 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. Akun untuk semua entitas yang akan menerima lalu lintas. Alamat IP untuk entitas tersebut akan dialokasikan dari ruang subnet address. Pertimbangkan juga poin-poin ini.

• Mutakhirkan

  AKS memperbarui node secara teratur untuk memastikan mesin virtual yang mendasarinya memiliki fitur keamanan dan patch sistem lain yang terkini. 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.

  Untuk pod, Anda mungkin memerlukan alamat tambahan tergantung pada strategi Anda. Untuk pembaruan bergulir, Anda memerlukan alamat untuk pod sementara yang menjalankan beban kerja saat pod yang sebenarnya 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 akan membutuhkan empat kali jumlah alamat untuk semua node yang diluaskan skalanya.

  Dalam arsitektur ini, setiap pod dapat dihubungi secara langsung. Jadi, setiap pod membutuhkan alamat individual. Skalabilitas pod akan memengaruhi perhitungan alamat. Keputusan itu akan tergantung pada pilihan Anda tentang jumlah pod yang ingin Anda kembangkan.

• Alamat Azure Private Link

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

• Alamat tertentu disediakan untuk digunakan oleh Azure. Alamat tersebut tidak bisa ditetapkan.

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

Arsitektur ini dirancang untuk satu beban kerja. Untuk beberapa beban kerja, Anda mungkin ingin mengisolasi kumpulan simpul pengguna satu sama lain dan dari kumpulan simpul sistem. Pilihan tersebut 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 meninjau pertimbangan perencanaan alamat IP yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Fitur add-on dan pratinjau

Kubernetes dan AKS terus mengembangkan produk, 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. Perbedaan antara keduanya adalah sebagai berikut:

• Tim AKS menjelaskan fitur pratinjau sebagai dikirim dan disempurnakan. Alasan di balik itu adalah bahwa banyak fitur pratinjau tetap berada dalam status itu hanya selama beberapa bulan sebelum pindah ke fase rilis umum (GA).
• Add-on dan ekstensi AKS menyediakan fungsionalitas tambahan yang didukung. Instalasi, konfigurasi, dan siklus hidup mereka dikelola oleh AKS.

Arsitektur garis besar ini tidak menyertakan setiap fitur pratinjau atau add-on, sebagai gantinya hanya yang menambahkan nilai signifikan ke kluster tujuan umum yang disertakan. Karena fitur-fitur ini keluar dari pratinjau, arsitektur garis besar ini akan direvisi sesuai dengan itu. Ada beberapa fitur pratinjau tambahan atau add-on AKS yang mungkin ingin Anda evaluasi di kluster pra-produksi yang menambah keamanan, pengelolaan, atau persyaratan lainnya. Dengan add-on pihak ketiga, Anda perlu 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 menariknya ke dalam kluster Anda.

• Kluster diautentikasi untuk menarik gambar.

• Jika Anda menggunakan gambar publik, pertimbangkan untuk mengimpornya ke registri kontainer yang selaras dengan SLO Anda. Jika tidak, gambar mungkin mengalami masalah ketersediaan yang tidak terduga. Masalah tersebut dapat menyebabkan masalah operasional jika gambar tidak tersedia saat Anda membutuhkannya. Berikut adalah beberapa manfaat menggunakan registri kontainer Anda alih-alih registri publik:

  • Anda dapat memblokir akses tidak sah ke gambar Anda.
  • Anda tidak akan memiliki dependensi yang dihadapi publik.
  • Anda dapat mengakses log tarik gambar untuk memantau aktivitas dan mengatasi masalah konektivitas.
  • Manfaatkan pemindaian kontainer terintegrasi dan kepatuhan gambar.

  Salah satunya adalah Azure Container Registry (ACR).

• Tarik gambar dari registri resmi. Anda dapat menerapkan pembatasan ini melalui Azure Policy. Dalam implementasi referensi ini, kluster hanya menarik gambar dari ACR yang digunakan sebagai bagian dari arsitektur.

Mengonfigurasi komputasi untuk kluster dasar

Di AKS, setiap kumpulan simpul memetakan ke Virtual Machine Scale Set. 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 OS 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. Ini akan meminimalkan jejak layanan yang berjalan di semua node, seperti pemantauan dan logging.

• Menyebarkan setidaknya dua node. Dengan begitu, beban kerja akan memiliki pola ketersediaan yang tinggi dengan dua replika. Dengan AKS, Anda dapat mengubah jumlah node tanpa membuat ulang kluster.

• Ukuran node yang sebenarnya untuk beban kerja Anda akan tergantung pada persyaratan yang ditentukan oleh tim desain. Berdasarkan persyaratan bisnis, kami telah memilih DS4_v2 untuk beban kerja produksi. Untuk menurunkan biaya seseorang bisa menurunkan ukuran ke DS3_v2, yang merupakan rekomendasi minimum.

• Saat merencanakan kapasitas untuk kluster Anda, asumsikan bahwa beban kerja Anda dapat menghabiskan hingga 80% dari setiap node; 20% sisanya disediakan untuk layanan AKS.

• Atur pod maksimum per node berdasarkan perencanaan kapasitas Anda. Jika Anda mencoba menetapkan garis dasar 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 ketika Anda membuat pilihan keamanan:

• Akses dalam ke luar. Akses AKS ke komponen Azure seperti infrastruktur jaringan, Azure Container Registry, dan Azure Key Vault. Hanya otorisasi sumber daya yang dapat diakses oleh 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 cara tersebut, identitas terkelola yang direkomendasikan. Dengan prinsipal layanan, Anda bertanggung jawab untuk mengelola dan memutar rahasia, baik secara manual maupun terprogram. Dengan identitas terkelola, MICROSOFT Entra ID mengelola dan melakukan autentikasi dan rotasi rahasia tepat waktu untuk Anda.

Disarankan agar identitas terkelola diaktifkan sehingga kluster dapat berinteraksi dengan sumber daya Azure eksternal melalui ID Microsoft Entra. Anda dapat mengaktifkan pengaturan ini hanya selama pembuatan kluster. Bahkan jika ID Microsoft Entra tidak segera digunakan, Anda dapat menggabungkannya nanti.

Secara default, ada dua identitas utama yang digunakan oleh kluster, identitas kluster dan identitas kubelet. Identitas kluster digunakan oleh komponen sarana kontrol AKS untuk mengelola sumber daya kluster termasuk load balancer ingress, IP publik terkelola AKS, dll. Identitas kubelet digunakan untuk mengautentikasi dengan Azure Container Registry (ACR). Beberapa add-on juga mendukung autentikasi menggunakan identitas terkelola.

Sebagai contoh untuk kasus dalam ke luar, mari kita pelajari penggunaan identitas terkelola ketika kluster perlu menarik gambar dari registri kontainer. Tindakan ini mengharuskan kluster untuk mendapatkan kredensial registri. Salah satu caranya adalah dengan menyimpan informasi tersebut dalam bentuk objek Kubernetes Secrets dan gunakan imagePullSecrets untuk mengambil rahasia tersebut. Pendekatan ini tidak dianjurkan karena kompleksitas keamanan. Anda tidak hanya membutuhkan pengetahuan sebelumnya tentang rahasia tetapi juga tentang pengungkapan rahasia melalui alur DevOps. Alasan lain adalah biaya operasional dalam mengelola rotasi rahasia. Sebagai gantinya, berikan acrPull akses ke identitas terkelola kubelet kluster ke registri Anda. Pendekatan ini dapat mengatasi masalah tersebut.

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

• Kontributor jaringan. Kemampuan kluster untuk mengontrol jaringan virtual spoke. Penetapan peran ini memungkinkan sistem kluster AKS yang diberi identitas untuk bekerja dengan subnet khusus untuk layanan Pengontrol Ingress Internal.
• Memantau Penerbit Metrik. Kemampuan kluster untuk mengirim metrik ke Azure Monitor.
• AcrPull. Kemampuan kluster untuk menarik gambar dari Azure Container Registry yang ditentukan.

Akses kluster

Integrasi Microsoft Entra juga menyederhanakan keamanan untuk akses luar masuk. Misalkan pengguna ingin menggunakan kubectl. Sebagai langkah awal, mereka menjalankan az aks get-credentials perintah untuk mendapatkan kredensial kluster. ID Microsoft Entra akan mengautentikasi identitas pengguna terhadap peran Azure yang diizinkan untuk mendapatkan kredensial kluster. Untuk informasi selengkapnya, lihat Izin peran kluster yang tersedia.

AKS memungkinkan akses Kubernetes menggunakan MICROSOFT Entra ID dengan dua cara. Yang pertama adalah menggunakan MICROSOFT Entra ID sebagai idP yang terintegrasi dengan sistem RBAC Kubernetes asli. Yang satunya menggunakan Azure RBAC asli untuk mengontrol akses kluster. Keduanya dirinci di bawah ini.

Kaitkan RBAC Kubernetes ke ID Microsoft Entra

Kubernetes mendukung role-based access control (RBAC) melalui:

• Serangkaian izin. Ditentukan oleh objek Role atau ClusterRole untuk izin di seluruh kluster.

• Pengikatan yang menetapkan pengguna dan grup yang diizinkan untuk melakukan tindakan. Didefinisikan oleh objek RoleBinding atau ClusterRoleBinding.

Kubernetes memiliki beberapa peran bawaan seperti admin kluster, mengedit, menampilkan, dan sebagainya. 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 grup Microsoft Entra Anda yang digunakan untuk akses kluster dan namespace disertakan 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, opsi lain yang kami rekomendasikan, adalah menggunakan Penetapan peran Azure RBAC dan Azure untuk memberlakukan pemeriksaan otorisasi pada kluster. Penetapan peran ini bahkan dapat ditambahkan pada cakupan grup langganan atau sumber daya sehingga semua kluster di bawah cakupan 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. Akses pengguna ke kluster menggunakan metode ini tidak disarankan. Karena berbasis sertifikat dan dilakukan di luar penyedia identitas utama Anda; membuat kontrol akses pengguna terpusat dan tata kelola menjadi sulit. Selalu kelola akses ke kluster Anda menggunakan ID Microsoft Entra, dan konfigurasikan kluster Anda untuk menonaktifkan akses akun lokal secara eksplisit.

Dalam implementasi referensi ini, akses melalui akun kluster lokal dinonaktifkan secara eksplisit saat kluster diterapkan.

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 akan mengautentikasi dirinya sendiri terhadap sumber daya sebagai identitas terkelola Azure.

Dalam implementasi referensi ini, identitas terkelola untuk pod disediakan melalui ID Beban Kerja Microsoft Entra pada AKS. Ini terintegrasi dengan kemampuan asli Kubernetes untuk bergabung dengan penyedia identitas eksternal. Untuk informasi selengkapnya tentang federasi ID Beban Kerja Microsoft Entra, lihat gambaran umum berikut.

Menyebarkan Sumber daya ingress (masuk)

Sumber daya Kubernetes Ingress merutekan dan mendistribusikan lalu lintas masuk ke kluster. Ada dua bagian dari sumber daya Ingress:

• Penyeimbang beban internal. Dikelola oleh AKS. Penyeimbang beban ini mengekspos pengontrol ingress melalui alamat IP statis pribadi. Ini berfungsi sebagai titik kontak tunggal yang menerima aliran masuk.

  Dalam arsitektur ini, Azure Load Balancer digunakan. Azure Load Balancer ditempatkan di luar kluster di subnet yang dikhususkan untuk sumber daya ingress. Azure Load Balancer menerima lalu lintas dari Azure Application Gateway dan komunikasi tersebut melalui TLS. Untuk informasi tentang enkripsi TLS untuk lalu lintas masuk, lihat Arus lalu lintas Ingress.

• Pengontrol ingress. Kita telah memilih 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 ini saat mengonfigurasi komponen ini.

• Sebagai bagian dari keputusan desain Anda, pilih ruang lingkup di mana pengontrol ingress akan diizinkan beroperasi. 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 memastikan kelangsungan bisnis jika node turun. Gunakan podAntiAffinity untuk tujuan ini.

• Batasi pod yang akan dijadwalkan hanya pada kumpulan node pengguna dengan menggunakan nodeSelectors. Pengaturan ini akan 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 traffic dari Azure Application Gateway.

• Pengontrol ingress harus mengirim sinyal yang menunjukkan kesehatan pod. Konfigurasi pengaturan readinessProbe dan livenessProbe yang akan memantau kesehatan pod pada interval yang ditentukan.

• Pertimbangkan untuk membatasi akses pengontrol ingress ke sumber daya tertentu dan kemampuan untuk melakukan tindakan tertentu. Pembatasan tersebut dapat diimplementasikan melalui izin RBAC Kubernetes. Misalnya, dalam arsitektur ini, Traefik telah diberikan izin untuk menonton, mendapatkan, dan mencantumkan layanan dan titik akhir dengan menggunakan aturan di objek ClusterRole Kubernetes.

Untuk meninjau desain ingress yang digunakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

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. annotations, tls, dan entrypoints menunjukkan bahwa rute akan dilayani melalui HTTPS. middlewares menentukan bahwa hanya lalu lintas dari subnet Azure Application Gateway yang diizinkan. Tanggapan akan menggunakan pengkodean gzip jika klien menerima. Karena Traefik melakukan penghentian TLS, komunikasi dengan layanan backend dilakukan 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

Aliran jaringan, dalam konteks ini, dapat dikategorikan sebagai:

• Lalu lintas ingress. Dari klien hingga beban kerja yang berjalan di kluster.

• Lalu Lintas Egress. Dari pod atau node di kluster ke layanan eksternal.

• Lalu lintas Pod ke pod. Komunikasi antar pod. Lalu lintas ini mencakup komunikasi antara pengontrol ingress dan beban kerja. Juga, jika beban kerja Anda terdiri dari beberapa aplikasi yang disebarkan ke kluster, komunikasi antara aplikasi tersebut akan termasuk ke dalam kategori ini.

• Lalu lintas manajemen. Lalu lintas yang terjadi 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 satu set cyphers terbatas. Indikasi Nama Server (SNI) yang ketat diaktifkan. TLS end-to-end diatur melalui Application Gateway dengan menggunakan dua sertifikat TLS yang berbeda, seperti yang ditunjukkan pada gambar ini.

Unduh file Visio arsitektur ini.

1. Klien mengirimkan permintaan HTTPS ke nama domain: bicycle.contoso.com. Nama tersebut dikaitkan melalui catatan DNS A ke alamat IP publik Azure Application Gateway. Lalu lintas ini dienkripsi untuk memastikan bahwa lalu lintas antara browser klien dan gateway tidak dapat diperiksa atau diubah.

2. Application Gateway memiliki firewall aplikasi web terintegrasi (WAF) dan menegosiasikan handshake TLS untuk bicycle.contoso.com, yang hanya memungkinkan cipher yang aman. Application Gateway adalah titik penghentian TLS, karena diperlukan untuk memproses aturan inspeksi WAF, dan menjalankan aturan perutean yang meneruskan lalu lintas ke backend yang dikonfigurasi. Sertifikat TLS disimpan di Azure Key Vault. Ini diakses menggunakan identitas terkelola yang ditetapkan pengguna yang terintegrasi dengan Application Gateway. Untuk informasi tentang fitur tersebut, lihat penghentian TLS dengan sertifikat Key Vault.

3. Saat lalu lintas berpindah dari Application Gateway ke backend, lalu lintas dienkripsi lagi dengan sertifikat TLS lain (wildcard untuk *.aks-ingress.contoso.com) saat diteruskan ke load balancer internal. Enkripsi ulang ini memastikan 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 Azure Key Vault dan dipasang ke dalam kluster menggunakan driver Container Storage Interface (CSI). Untuk informasi selengkapnya, lihat Menambahkan manajemen rahasia.

Anda dapat mengimplementasikan traffic TLS end-to-end di setiap hop hingga ke pod beban kerja. Pastikan untuk mengukur kinerja, latensi, dan dampak operasional saat membuat keputusan untuk mengamankan lalu lintas pod ke pod. Untuk sebagian besar kluster penyewa tunggal, dengan RBAC bidang kontrol yang tepat dan praktik Siklus Hidup Pengembangan Perangkat Lunak yang matang, cukup untuk mengenkripsi TLS ke pengontrol ingress dan melindunginya dengan Web Application Firewall (WAF). Itu akan meminimalkan biaya dalam manajemen beban kerja dan dampak kinerja jaringan. Persyaratan beban kerja dan kepatuhan Anda akan menentukan di mana Anda melakukan penghentian TLS.

Arus lalu lintas keluar

Dalam arsitektur ini, kami merekomendasikan semua lalu lintas keluar dari kluster yang berkomunikasi melalui Azure Firewall atau appliance virtual jaringan serupa Anda sendiri, melalui opsi lain seperti NAT Gateway atau proksi HTTP. Untuk kontrol zero-trust dan kemampuan untuk memeriksa lalu lintas, semua lalu lintas keluar dari kluster bergerak melalui Azure Firewall. Anda dapat menerapkan pilihan tersebut menggunakan rute yang ditentukan pengguna (UDR). Hop berikutnya dari rute ini adalah alamat IP pribadi dari Azure Firewall. Di sini, Azure Firewall memutuskan apakah akan memblokir atau mengizinkan lalu lintas keluar. Keputusan itu didasarkan pada aturan spesifik yang didefinisikan dalam Azure Firewall atau aturan intelijen ancaman bawaan.

Alternatif untuk menggunakan Azure Firewall adalah dengan menggunakan fitur Proksi HTTP AKS. Semua lalu lintas yang keluar kluster diatur terlebih dahulu ke alamat IP Proksi HTTP, yang memutuskan untuk meneruskan lalu lintas atau menjatuhkannya.

Dengan salah satu metode, tinjau aturan jaringan keluar yang diperlukan untuk AKS.

Pengecualian untuk kontrol zero-trust adalah saat kluster perlu berkomunikasi dengan sumber daya Azure lainnya. Misalnya, kluster perlu menarik gambar yang diperbarui dari registri kontainer, atau rahasia dari Azure Key Vault. Pendekatan yang disarankan adalah dengan menggunakan Azure Private Link. Keuntungannya adalah bahwa subnet tertentu mencapai layanan secara langsung alih-alih lalu lintas antara kluster dan layanan yang melalui internet. Kelemahannya adalah Bahwa Private Link membutuhkan konfigurasi tambahan alih-alih menggunakan layanan target melalui titik akhir publiknya. Selain itu, tidak semua layanan atau SKU Azure mendukung Private Link. Untuk kasus tersebut, pertimbangkan untuk mengaktifkan titik akhir layanan Virtual Network 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 akan melalui alamat IP statis firewall, alamat tersebut dapat ditambahkan daftar ip layanan yang diizinkan. Salah satu kelemahannya adalah Azure Firewall perlu memiliki aturan tambahan untuk memastikan hanya lalu lintas dari subnet tertentu yang diizinkan. Faktor dalam alamat tersebut saat Anda merencanakan beberapa alamat IP untuk lalu lintas keluar dengan Azure Firewall, jika tidak, Anda dapat mencapai kelelahan port. Untuk informasi selengkapnya tentang beberapa perencanaan alamat IP, lihat Membatasi dan mengontrol lalu lintas keluar.

Untuk meninjau pertimbangan keluar khusus Windows yang digunakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Lalu lintas Pod ke pod

Secara default, pod dapat menerima lalu lintas dari pod lain di kluster. Kubernetes NetworkPolicy digunakan untuk membatasi lalu lintas jaringan antar pod. Terapkan kebijakan dengan bijaksana, jika tidak, Anda mungkin akan mengalami situasi di mana aliran jaringan kritis 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 kluster disediakan karena tidak dapat ditambahkan nanti. Ada beberapa pilihan untuk teknologi yang menerapkan NetworkPolicy. Azure Network Policy direkomendasikan, yang memerlukan Azure Container Networking Interface (CNI), lihat catatan di bawah ini. Pilihan lain termasuk Calico Network Policy, opsi sumber terbuka yang 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 kebijakan Azure Network Policy dan Calico dan kemampuannya.

Lalu lintas manajemen

Sebagai bagian dari menjalankan kluster, server API Kubernetes akan menerima lalu lintas dari sumber daya yang ingin melakukan operasi manajemen pada kluster, seperti permintaan untuk membuat sumber daya atau skala kluster. Contoh sumber daya tersebut termasuk kumpulan agen build dalam alur DevOps, subnet Bastion, dan kumpulan node itu sendiri. Alih-alih menerima lalu lintas manajemen ini dari semua alamat IP, gunakan fitur Authorized IP Ranges 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 tambahan, dengan biaya kompleksitas tambahan, Anda dapat menyediakan kluster AKS privat. Dengan menggunakan kluster privat, Anda dapat memastikan lalu lintas jaringan antara server API dan kumpulan simpul Anda tetap berada di jaringan privat saja, tidak terekspos ke internet. Untuk informasi selengkapnya, lihat Kluster Privat AKS.

Menambahkan manajemen rahasia

Simpan rahasia di penyimpanan kunci terkelola, seperti Azure Key Vault. Keuntungannya adalah bahwa penyimpanan terkelola menangani rotasi rahasia, menawarkan enkripsi yang kuat, menyediakan log audit akses, dan menjauhkan rahasia inti dari alur penyebaran. Dalam arsitektur ini, firewall Azure Key Vault diaktifkan dan dikonfigurasi dengan koneksi tautan privat ke sumber daya di Azure yang perlu mengakses rahasia dan sertifikat.

Azure Key Vault terintegrasi dengan baik dengan layanan Azure lainnya. Gunakan fitur bawaan dari layanan tersebut untuk mengakses rahasia. Untuk contoh tentang cara Azure Application Gateway mengakses sertifikat TLS untuk alur masuk, lihat bagian Alur 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 Azure Key Vault menggunakan RBAC.

Mengakses rahasia kluster

Anda harus menggunakan identitas beban kerja untuk memungkinkan pod mengakses rahasia dari penyimpanan tertentu. Untuk memudahkan proses pengambilan, gunakan driver CSI Secrets Store. Saat 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. Dalam implementasi ini, kami telah memilih Azure Key Vault dengan Driver Secrets Store CSI menggunakan add-on untuk mengambil sertifikat TLS dari Azure Key Vault dan memuatnya di pod yang menjalankan pengontrol ingress. Ini dilakukan selama pembuatan pod dan volume menyimpan kunci publik dan pribadi.

Penyimpanan beban kerja

Beban kerja yang digunakan dalam arsitektur ini tidak memiliki status. Jika Anda perlu menyimpan status, dianjurkan untuk mempertahankannya di luar kluster. Panduan untuk status beban kerja berada di luar cakupan artikel ini.

Untuk mempelajari opsi penyimpanan selengkapnya, lihat Opsi penyimpanan untuk aplikasi di Azure Kubernetes Service (AKS).

Manajemen kebijakan

Cara efektif untuk mengelola kluster AKS adalah dengan menegakkan tata kelola melalui kebijakan. Kubernetes menerapkan kebijakan melalui OPA Gatekeeper. Untuk AKS, kebijakan dikirimkan melalui Azure Policy. Setiap kebijakan diterapkan untuk semua kelompok dalam ruang lingkupnya. Penegakan Azure Policy pada akhirnya ditangani oleh OPA Gatekeeper di kluster dan semua pemeriksaan kebijakan dicatat. Perubahan kebijakan tidak segera tercermin dalam kluster Anda, berharap untuk melihat beberapa penundaan.

Ada dua skenario berbeda yang diberikan Azure Policy untuk mengelola kluster AKS Anda:

• Mencegah atau membatasi penyebaran kluster AKS dalam grup sumber daya atau langganan dengan mengevaluasi standar organisasi Anda. Misalnya, ikuti konvensi penamaan, tentukan tag, dll.
• 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 mengatur kumpulan kebijakan (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. Sebaiknya Pilih inisiatif dan pilih kebijakan tambahan untuk kluster dan sumber daya (ACR, Application Gateway, Key Vault, dan lainnya) yang berinteraksi dengan kluster, sesuai kebutuhan organisasi Anda.

• Ingin Mengaudit atau Menolak tindakan? Dalam mode Audit, tindakan diizinkan tetapi ditandai sebagai Tidak Patuh. Lakukan proses pemeriksaan status yang tidak patuh secara teratur dan ambil tindakan yang diperlukan. Dalam mode Tolak, tindakan diblokir karena melanggar kebijakan. Berhati-hatilah dalam memilih mode ini karena bisa terlalu membatasi fungsi beban kerja.

• Apakah Anda memiliki area dalam beban kerja Anda yang tidak sesuai dengan desain? Azure Policy memiliki kemampuan untuk menentukan namespace Kubernetes yang dikecualikan dari penegakan kebijakan. Disarankan agar tetap 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 mempelajari selengkapnya tentang membuat kebijakan kustom, 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 kerja sendiri, bahkan jika organisasi memiliki kebijakan umum.

• Kebijakan Azure ditetapkan ke cakupan tertentu. Pastikan kebijakan produksi juga divalidasi terhadap lingkungan pra-produksi Anda. Jika tidak, saat menyebarkan ke lingkungan produksi, Anda mungkin mengalami pembatasan tambahan tak terduga yang tidak diperhitungkan dalam pra-produksi.

Dalam implementasi referensi ini, Azure Policy diaktifkan saat kluster AKS dibuat dan menetapkan inisiatif pembatasan dalam mode Audit untuk mendapatkan visibilitas ke dalam ketidakpatuhan.

Implementasi ini juga menetapkan kebijakan tambahan yang bukan bagian dari perintah bawaan. Kebijakan tersebut diatur dalam mode Tolak. Misalnya, ada kebijakan untuk memastikan gambar hanya ditarik dari ACR 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, Anda dapat mengakses log pod untuk semua pod di gatekeeper-systemnamespace serta log untuk pod azure-policy dan azure-policy-webhook di namespace kube-system.

Untuk meninjau pertimbangan Azure Policy khusus Windows yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Skalabilitas node dan pod

Dengan meningkatnya permintaan, Kubernetes dapat menskalakan dengan menambahkan lebih banyak pod ke node yang ada, melalui penskalaan pod horizontal (HPA). Ketika pod tambahan tidak dapat lagi dijadwalkan, jumlah node 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.

Cara manual atau terprogram mengharuskan Anda untuk memantau dan mengatur peringatan tentang pemanfaatan CPU atau metrik khusus. Untuk penskalaan pod, operator aplikasi dapat menambah atau mengurangi jumlah replika pod dengan menyesuaikan ReplicaSet melalui API Kubernetes. Untuk penskalaan kluster, salah satu caranya adalah dengan mendapatkan pemberitahuan saat penjadwal Kubernetes gagal. Cara lain adalah dengan mengawasi pod yang tertunda dari waktu ke waktu. Anda dapat menyesuaikan jumlah node melalui Azure CLI atau portal.

Penskalaan otomatis adalah pendekatan yang direkomendasikan karena beberapa mekanisme manual tersebut dibangun ke dalam autoscaler.

Sebagai pendekatan umum, mulailah dengan pengujian kinerja dengan jumlah minimum pod dan node. Gunakan nilai-nilai tersebut untuk menetapkan ekspektasi dasar. Kemudian gunakan kombinasi metrik kinerja dan penskalaan manual untuk menemukan hambatan dan memahami respons aplikasi terhadap penskalaan. Terakhir, gunakan data ini untuk mengatur parameter penskalaan otomatis. Untuk informasi tentang skenario penyetelan kinerja menggunakan AKS, lihat Skenario penyetelan kinerja: Transaksi bisnis terdistribusi.

Penskala pod horizontal

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

Dalam sumber daya HPA, pengaturan jumlah replika minimum dan maksimum disarankan. Nilai-nilai tersebut membatasi batas penskalaan otomatis.

HPA dapat menskalakan berdasarkan pemanfaatan CPU, penggunaan memori, dan metrik kustom. Hanya penggunaan CPU yang disediakan di luar kotak. Definisi HorizontalPodAutoscaler menentukan nilai target untuk metrik tersebut. Misalnya, spesifikasi menetapkan target pemanfaatan CPU. Saat pod berjalan, pengontrol HPA menggunakan API Metrik Kubernetes untuk memeriksa pemanfaatan CPU masing-masing pod. Pemeriksaan dilakukan dengan membandingkan nilai tersebut dengan pemanfaatan target dan menghitung rasionya. 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 persaingan di mana (HPA) diperiksa sebelum operasi penskalaan selesai. Hasilnya mungkin adalah perhitungan rasio yang salah. Untuk mengetahui detailnya, lihat Pendinginan peristiwa penskalaan.

Jika beban kerja Anda didorong oleh peristiwa, opsi sumber terbuka yang populer adalah KEDA. Pertimbangkan KEDA jika beban kerja Anda didorong oleh sumber peristiwa, seperti antrean pesan, alih-alih terikat CPU atau memori. KEDA mendukung banyak sumber acara (atau penskala). Anda dapat menemukan daftar scaler KEDA yang didukung di sini termasuk penskala Azure Monitor; cara yang nyaman 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. Ini harus ditambahkan selama penyediaan kluster. Anda memerlukan penskala otomatis kluster terpisah untuk setiap kumpulan node pengguna.

Kluster autoscaler dipicu oleh penjadwal Kubernetes. 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 node lain, dan node yang tidak digunakan akan dihapus.

Saat Anda mengaktifkan penskala otomatis, atur jumlah node 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 2 karena sifat beban kerja yang sederhana.

Untuk kumpulan node sistem, nilai minimum yang disarankan adalah 3.

Untuk meninjau pertimbangan penskalaan yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Keputusan kelangsungan bisnis

Untuk menjaga kelangsungan bisnis, tentukan Perjanjian Tingkat Layanan untuk infrastruktur dan aplikasi Anda. Untuk informasi tentang perhitungan waktu aktif bulanan, lihat SLA untuk Azure Kubernetes Service (AKS).

Simpul kluster

Untuk memenuhi tingkat ketersediaan minimum untuk beban kerja, diperlukan beberapa node dalam kumpulan node. Jika node turun, node lain di kumpulan node di kluster yang sama dapat terus menjalankan aplikasi. Untuk keandalan, tiga node direkomendasikan untuk kumpulan node sistem. Untuk kumpulan node pengguna, mulailah dengan tidak kurang dari dua node. 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. Penggunaan tag, label, dan taint disarankan untuk mengidentifikasi kumpulan simpul untuk menjadwalkan beban kerja Anda, dan memastikan kumpulan simpul sistem Anda ternoda dengan CriticalAddonsOnly [taint] (/azure/aks/use-system-pools#system-and-user-node-pools).

Pemeliharaan rutin kluster Anda seperti pembaruan tepat waktu sangat penting bagi keandalan. Juga memantau kesehatan pods melalui probe sangat dianjurkan.

Ketersediaan pod

Pastikan sumber daya pod. Sangat disarankan agar penyebaran menentukan persyaratan sumber daya pod. Penjadwal kemudian dapat menjadwalkan pod dengan tepat. Keandalan akan terdepresiasi secara signifikan jika pod tidak dapat dijadwalkan.

Tetapkan anggaran gangguan pod. Pengaturan ini memeriksa seberapa banyak replika dalam penyebaran yang dapat Anda turunkan fungsinya 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 memastikan jumlah replika pod yang diperlukan tersedia untuk menangani beban aplikasi yang diharapkan.

Atur kuota sumber daya pada namespace beban kerja. Kuota sumber daya pada namespace akan memastikan permintaan dan batas pod diatur dengan benar pada penyebaran. Untuk informasi selengkapnya, lihat Menerapkan kuota sumber daya.

Tetapkan permintaan dan batas pod. Mengatur batas ini memungkinkan Kubernetes untuk mengalokasikan sumber daya CPU dan/atau memori secara efisien ke pod dan memiliki kepadatan kontainer yang lebih tinggi pada node. Batas juga dapat meningkatkan keandalan dengan biaya yang lebih rendah karena pemanfaatan perangkat keras yang lebih baik.

Untuk memperkirakan batas, uji dan buat garis besar. Mulailah dengan nilai yang sama untuk permintaan dan batas. Kemudian, sesuaikan nilai tersebut secara bertahap hingga Anda menetapkan ambang batas yang dapat menyebabkan ketidakstabilan di kluster.

Batas tersebut dapat ditentukan dalam manifes penyebaran Anda. Untuk informasi selengkapnya, lihat Mengatur permintaan dan batas pod.

Zona ketersediaan dan dukungan multi-wilayah

Jika SLA Anda memerlukan waktu aktif yang lebih tinggi, lindungi dari pemadaman dengan menggunakan zona ketersediaan. Anda dapat menggunakan 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 simpul memetakan ke Virtual Machine Scale Set terpisah, yang mengelola instans dan skalabilitas node. Operasi dan konfigurasi set skala dikelola oleh layanan AKS. Berikut adalah beberapa pertimbangan saat mengaktifkan multi-wilayah:

• Seluruh infrastruktur. Pilih wilayah yang mendukung zona ketersediaan. Untuk informasi selengkapnya, lihat Batasan dan ketersediaan wilayah. Jika Anda ingin membeli SLA Waktu Aktif, pilih wilayah yang mendukung opsi tersebut. SLA Waktu Aktif lebih baik saat menggunakan zona ketersediaan.

• Kluster. Zona Ketersediaan hanya dapat diatur saat kumpulan node dibuat dan tidak dapat diubah nanti. Ukuran node harus didukung di semua zona sehingga memungkinkan distribusi yang diharapkan. Set Skala Komputer Virtual yang mendasar menyediakan konfigurasi perangkat keras yang sama di seluruh zona.

  Dukungan multi zona tidak hanya berlaku untuk kumpulan node, tetapi juga bidang kontrol. Bidang kontrol AKS akan menjangkau zona yang diminta, seperti kumpulan node. Jika Anda tidak menggunakan dukungan zona di kluster Anda, komponen bidang kontrol tidak dijamin akan tersebar di seluruh zona ketersediaan.

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

Misalnya, disk terkelola tersedia di zona di mana disk tersebut disediakan. Jika terjadi kegagalan, node mungkin pindah ke zona lain, tetapi disk terkelola tidak akan pindah dengan node ke zona itu.

Untuk kesederhanaan, dalam arsitektur ini AKS dikerahkan ke satu wilayah dengan kumpulan node yang mencakup zona ketersediaan 1, 2, dan 3. Sumber daya lain dari infrastruktur, seperti Azure Firewall dan Application Gateway dikerahkan ke wilayah yang sama juga dengan dukungan multi zona. Replikasi geografis diaktifkan untuk Azure Container Registry.

Beberapa wilayah

Mengaktifkan zona ketersediaan tidak akan cukup jika seluruh wilayah turun. Untuk memiliki ketersediaan yang lebih tinggi, jalankan beberapa kluster AKS, di berbagai wilayah.

• Gunakan wilayah berpasangan. Pertimbangkan untuk menggunakan alur CI/CD yang dikonfigurasi untuk menggunakan wilayah yang dipasangkan untuk memulihkan dari kegagalan wilayah. Manfaat menggunakan wilayah yang dipasangkan adalah keandalan selama proses pembaruan. Azure memastikan bahwa hanya satu wilayah dalam pasangan yang diperbarui pada satu waktu. Alat DevOps tertentu seperti Flux dapat membuat penyebaran multi-wilayah lebih mudah.

• Jika sumber daya Azure mendukung redundansi geografis, berikan lokasi di mana layanan yang redundan akan memiliki wilayah sekunder. Misalnya, mengaktifkan replikasi geografis untuk Azure Container Registry akan secara otomatis mereplikasi gambar ke wilayah Azure yang dipilih, dan akan memberikan akses berkelanjutan ke gambar bahkan jika suatu wilayah mengalami pemadaman.

• Pilih router lalu lintas yang dapat mendistribusikan lalu lintas melintasi zona atau wilayah, tergantung pada kebutuhan Anda. Arsitektur ini menyebarkan Azure Load Balancer karena dapat mendistribusikan lalu lintas non-web di seluruh zona. Jika Anda perlu mendistribusikan lalu lintas di seluruh wilayah, Azure Front Door harus dipertimbangkan. Untuk pertimbangan lainnya, lihat Memilih penyeimbang beban.

Pemulihan dari bencana

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

• Gunakan wilayah berpasangan.

• Beban kerja non-status dapat direplikasi secara efisien. Jika Anda perlu menyimpan status di kluster (tidak disarankan), pastikan Anda sering mencadangkan data di wilayah yang dipasangkan.

• Integrasikan strategi pemulihan, seperti mereplikasi ke wilayah lain, sebagai bagian dari alur DevOps untuk memenuhi Tujuan Tingkat Layanan (SLO) Anda.

• Saat menyediakan setiap layanan Azure, pilih fitur yang mendukung pemulihan bencana. Misalnya, dalam arsitektur ini, Azure Container Registry diaktifkan untuk replikasi geografis. Jika suatu wilayah tidak berfungsi, Anda masih dapat menarik gambar dari wilayah yang direplikasi.

Pencadangan kluster

Untuk banyak arsitektur, menyediakan kluster baru dan mengembalikannya ke status operasi dapat dicapai melalui [Bootstrapping kluster berbasis GitOps}(#cluster-bootstrapping) dan diikuti oleh penyebaran aplikasi. Namun, jika ada status sumber daya penting seperti peta konfigurasi, pekerjaan, dan kemungkinan rahasia yang karena alasan tertentu tidak dapat ditangkap dalam proses bootstrapping Anda, maka pertimbangkan strategi pemulihan Anda. Umumnya disarankan untuk menjalankan beban kerja tanpa status di Kubernetes, tetapi jika arsitektur Anda melibatkan status berbasis disk, Anda juga perlu mempertimbangkan strategi pemulihan untuk konten tersebut.

Ketika pencadangan kluster perlu menjadi bagian dari strategi pemulihan Anda, Anda perlu menginstal solusi yang sesuai dengan persyaratan bisnis Anda dalam kluster. Agen ini akan bertanggung jawab untuk mendorong status sumber daya kluster ke tujuan memilih dan mengoordinasikan rekam jepret volume persisten berbasis Azure Disk.

Velero VMware adalah contoh solusi cadangan Kubernetes umum yang dapat Anda instal dan kelola secara langsung. Atau, ekstensi cadangan AKS dapat digunakan 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 akan melibatkan sumber daya Azure tambahan dalam arsitektur untuk mengelola, memantau, membayar, dan mengamankan; seperti akun Azure Storage, vault & konfigurasi Azure Backup, dan Akses Tepercaya. GitOps dikombinasikan dengan niat untuk menjalankan beban kerja tanpa status adalah solusi pemulihan yang diterapkan.

Pilih dan validasi solusi yang memenuhi tujuan bisnis Anda, termasuk tujuan titik pemulihan (RPO) & tujuan waktu pemulihan (RTO) yang ditentukan. Tentukan proses pemulihan ini dalam runbook tim dan praktikkan untuk semua beban kerja penting bisnis.

Kubernetes API Server SLA

AKS dapat digunakan sebagai layanan gratis, tetapi tingkat itu tidak menawarkan SLA yang didukung secara finansial. Untuk mendapatkan SLA tersebut, Anda harus memilih tingkat Standar. Sebaiknya semua kluster produksi menggunakan tingkat Standar. Pesan kluster tingkat Gratis untuk kluster pra-produksi. Jika dikombinasikan dengan Azure Availability Zones, SLA server API Kubernetes meningkat menjadi 99,95%. Kumpulan node Anda, dan sumber daya lainnya tercakup dalam SLA miliknya sendiri.

Tradeoff

Ada tradeoff biaya-ke-ketersediaan untuk menyebarkan arsitektur di seluruh zona dan terutama wilayah. Beberapa fitur replikasi, seperti replikasi geografis di Azure Container Registry, tersedia dalam SKU premium, yang lebih mahal. Biaya juga akan meningkat karena biaya bandwidth yang diterapkan saat lalu lintas bergerak melintasi zona dan wilayah.

Juga, dapatkan latensi jaringan tambahan dalam komunikasi node antara zona atau wilayah. Ukur dampak keputusan arsitektur ini pada beban kerja Anda.

Uji dengan simulasi dan failover paksa

Pastikan keandalan melalui pengujian failover paksa dengan simulasi pemadaman seperti menghentikan node, menurunkan semua sumber daya AKS di zona tertentu untuk mensimulasikan kegagalan zonal, atau memanggil kegagalan dependensi eksternal. Azure Chaos Studio juga dapat memanfaatkan untuk mensimulasikan berbagai jenis pemadaman di Azure dan pada kluster.

Untuk informasi selengkapnya, lihat Azure Chaos Studio.

Memantau dan mengumpulkan metrik

Wawasan Kontainer Azure Monitor adalah alat yang direkomendasikan 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. Fitur ini juga mengumpulkan informasi dari API Metrik tentang pemanfaatan memori dan CPU untuk memantau kesehatan sumber daya dan beban kerja yang berjalan. Anda juga dapat menggunakannya untuk memantau performa saat pod diskalakan. Ini termasuk pengumpulan telemetri penting untuk pemantauan, analisis, dan visualisasi data yang dikumpulkan untuk mengidentifikasi tren, dan mengonfigurasi pemberitahuan agar secara proaktif diberi tahu tentang masalah penting.

Sebagian besar beban kerja yang dihosting dalam pod memancarkan metrik Prometheus. Wawasan kontainer mampu berintegrasi dengan Prometheus untuk melihat metrik aplikasi dan beban kerja yang dikumpulkannya dari simpul dan Kubernetes.

Ada beberapa solusi pihak ketiga yang terintegrasi dengan Kubernetes yang dapat Anda manfaatkan, seperti Datadog, Grafana, atau New Relic, jika organisasi Anda sudah menggunakannya.

Dengan AKS, Azure mengelola beberapa layanan Kubernetes inti dan log untuk komponen sarana kontrol AKS diimplementasikan di Azure sebagai log sumber daya. Disarankan agar sebagian besar kluster mengaktifkan hal berikut setiap saat karena dapat membantu Anda memecahkan masalah kluster dan memiliki kepadatan log yang relatif rendah:

• Pengelogan di ClusterAutoscaler untuk mendapatkan pengamatan ke dalam operasi penskalaan. Untuk informasi selengkapnya, lihat Mengambil log dan status penskala otomatis kluster.
• KubeControllerManager untuk memiliki pengamatan ke dalam interaksi antara Kubernetes dan sarana kontrol Azure.
• KubeAuditAdmin untuk memiliki pengamatan ke dalam aktivitas yang memodifikasi kluster Anda. Tidak ada alasan untuk mengaktifkan KubeAudit dan KubeAuditAdmin , karena KubeAudit adalah superset Dari KubeAuditAdmin yang mencakup operasi non-modifikasi (baca) juga.
• Guard menangkap audit Microsoft Entra ID dan Azure RBAC.

Kategori log lainnya, seperti KubeScheduler atau KubeAudit, mungkin sangat membantu untuk mengaktifkan selama kluster awal atau pengembangan siklus hidup beban kerja, di mana menambahkan penskalaan otomatis kluster, penempatan pod & penjadwalan, dan data serupa dapat membantu memecahkan masalah operasi kluster atau beban kerja. Menyimpan log pemecahan masalah yang diperluas pada waktu penuh, setelah kebutuhan pemecahan masalah berakhir, mungkin dianggap sebagai biaya yang tidak perlu untuk diserap dan disimpan 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 menggunakan satu atau beberapa paket kueri. Pustaka kueri kustom Anda membantu mengaktifkan pengamatan tambahan ke dalam kesehatan dan performa kluster AKS Anda, dan mendukung tujuan tingkat layanan (SLO) Anda.

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

Untuk meninjau pertimbangan pemantauan khusus Windows yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Aktifkan perbaikan diri

Pantau kesehatan pod dengan menyetel probe Keaktifan dan Kesiapan. Jika pod yang tidak responsif terdeteksi, Kubernetes akan memulai ulang pod. Probe keaktifan menentukan apakah pod itu sehat. Jika tidak merespons, Kubernetes akan memulai ulang pod. Probe kesiapan menentukan apakah pod siap menerima permintaan/lalu lintas.

Pembaruan kluster AKS

Menentukan strategi pembaruan yang konsisten dengan persyaratan bisnis adalah yang terpenting. Memahami tingkat prediksi untuk tanggal dan waktu ketika versi kluster AKS atau nodenya diperbarui, dan tingkat kontrol yang diinginkan atas gambar atau biner tertentu yang diinstal adalah aspek mendasar yang akan menggambarkan cetak biru pembaruan kluster AKS Anda. Prediktabilitas terkait dengan dua properti pembaruan kluster AKS utama yang merupakan irama pembaruan dan jendela pemeliharaan. Kontrol adalah apakah pembaruan diinstal secara manual atau otomatis. Organisasi dengan kluster AKS yang tidak berada di bawah peraturan keamanan yang ketat mungkin mempertimbangkan pembaruan mingguan atau bahkan bulanan, sementara sisanya harus memperbarui patch berlabel keamanan segera setelah tersedia (harian). Organisasi yang mengoperasikan kluster AKS sebagai infrastruktur yang tidak dapat diubah tidak memperbaruinya. Ini berarti, tidak ada pembaruan otomatis atau manual yang dilakukan. Sebaliknya ketika pembaruan yang diinginkan tersedia, stempel replika akan disebarkan dan hanya ketika instans infrastruktur baru siap yang lama dikeringkan memberi mereka tingkat kontrol tertinggi.

Setelah cetak biru pembaruan kluster AKS ditentukan, yang dapat dengan mudah dipetakan ke dalam opsi pembaruan yang tersedia untuk simpul AKS dan versi kluster AKS:

• Simpul AKS:

  1. Pembaruan Tidak Ada/Manual: Ini untuk infrastruktur yang tidak dapat diubah atau ketika pembaruan manual adalah preferensi. Hal ini mencapai prediksi dan kontrol tingkat yang lebih besar atas pembaruan simpul AKS.
  2. Pembaruan Tanpa Pengawas Otomatis: AKS menjalankan pembaruan OS asli. Ini memberikan prediksi dengan mengonfigurasi jendela pemeliharaan yang selaras dengan apa yang baik untuk bisnis. Mungkin didasarkan pada jam sibuk dan apa yang terbaik operasi-bijaksana. Tingkat kontrol rendah karena tidak mungkin untuk mengetahui terlebih dahulu apa yang akan diinstal secara khusus dalam simpul AKS.
  3. Pembaruan gambar Simpul Otomatis: Disarankan untuk memperbarui gambar simpul AKS secara otomatis saat hard disk virtual (VHD) baru tersedia. Merancang jendela pemeliharaan untuk diselaraskan sebanyak mungkin dengan kebutuhan bisnis. Untuk pembaruan VHD berlabel keamanan, disarankan untuk mengonfigurasi jendela pemeliharaan harian yang memberikan prediksi terendah. Pembaruan VHD reguler dapat dikonfigurasi dengan jendela pemeliharaan mingguan, setiap dua minggu atau bahkan bulanan. Tergantung pada apakah kebutuhannya adalah untuk VHD berlabel keamanan vs reguler yang dikombinasikan dengan jendela pemeliharaan terjadwal, prediksi berfluktuasi menawarkan lebih banyak atau kurang fleksibilitas untuk selaras dengan persyaratan bisnis. Meskipun meninggalkan ini selalu sesuai dengan persyaratan bisnis akan ideal, realitas mengamanatkan organisasi untuk menemukan titik tip. Tingkat kontrol rendah karena tidak mungkin untuk mengetahui terlebih dahulu biner tertentu apa yang disertakan ke dalam VHD baru dan masih jenis pembaruan otomatis ini adalah opsi yang direkomendasikan karena gambar diperiksa sebelum tersedia.

  Catatan

  Untuk informasi selengkapnya tentang cara mengonfigurasi pembaruan simpul AKS otomatis, silakan lihat Gambar OS simpul peningkatan otomatis.

• Versi kluster AKS:

  1. Pembaruan Tidak Ada/Manual: Ini untuk infrastruktur yang tidak dapat diubah atau ketika pembaruan manual adalah preferensi. Ini mencapai prediksi dan kontrol tingkat yang lebih besar atas pembaruan versi kluster AKS. Keikutsertaan untuk ini disarankan, karena ini meninggalkan kontrol penuh memberikan kesempatan untuk menguji versi kluster AKS baru (yaitu 1.14.x hingga 1.15.x) di lingkungan yang lebih rendah sebelum mencapai produksi.
  2. Pembaruan otomatis: Kluster produksi tidak disarankan untuk secara otomatis di-patch atau diperbarui dengan cara apa pun (yaitu 1.16.x hingga 1.16.y) ke versi kluster AKS baru yang tersedia tanpa diuji dengan benar di lingkungan yang lebih rendah. Meskipun rilis upstream Kubernetes dan pembaruan versi kluster AKS dikoordinasikan dengan menyediakan irama reguler, rekomendasinya masih harus defensif dengan kluster AKS dalam produksi yang meningkatkan prediksi dan kontrol atas proses pembaruan. Dengan mempertimbangkan konfigurasi ini untuk lingkungan yang lebih rendah sebagai bagian dari Keunggulan Operasional, memungkinkan eksekusi pengujian rutin proaktif untuk mendeteksi potensi masalah sedini mungkin.

Selalu perbarui versi Kubernetes dengan versi N-2 yang didukung. Peningkatan ke Kubernetes versi terbaru sangat penting karena versi baru dirilis secara berkala.

Untuk informasi selengkapnya, lihat Memperbarui secara berkala ke versi terbaru Kubernetes dan Meningkatkan kluster Azure Kubernetes Service (AKS).

Pemberitahuan peristiwa yang diangkat oleh kluster Anda, seperti ketersediaan versi AKS baru untuk klaster Anda, dapat dicapai melalui 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.

Pembaruan mingguan

AKS menyediakan gambar node baru yang memiliki pembaruan OS dan runtime terbaru. Gambar baru ini tidak diterapkan secara otomatis. Anda bertanggung jawab untuk memutuskan seberapa sering gambar harus diperbarui. Sebaiknya Anda memiliki proses untuk meningkatkan gambar dasar kumpulan node Anda setiap minggu. Untuk informasi lebih lanjut, lihat Meningkatkan gambar node Azure Kubernetes Service (AKS)Catatan Rilis AKS.

Pembaruan harian

Di antara peningkatan gambar, node AKS mengunduh dan memasang patch OS dan runtime secara individual. Pemasangan mungkin memerlukan VM node untuk dimulai ulang. AKS tidak akan memulai ulang node karena pembaruan yang tertunda. Lakukan proses yang memantau node untuk pembaruan yang diterapkan yang memerlukan mulai ulang dan lakukan mulai ulang node tersebut secara terkendali. Opsi sumber terbuka adalah Kured (Kubernetes reboot daemon).

Menjaga gambar node Anda agar selaras dengan rilis mingguan terbaru akan meminimalkan permintaan mulai ulang sesekali dengan tetap mempertahankan postur keamanan yang ditingkatkan. Hanya mengandalkan peningkatan gambar node akan memastikan kompatibilitas AKS dan patching keamanan mingguan. Sedangkan menerapkan pembaruan harian akan memperbaiki masalah keamanan lebih cepat, mereka belum tentu diuji di AKS. Jika memungkinkan, gunakan peningkatan gambar node sebagai strategi patching keamanan mingguan utama Anda.

Pemantauan keamanan

Pantau infrastruktur kontainer Anda untuk ancaman aktif dan potensi risiko keamanan:

• Aktifkan Pertahanan Microsoft untuk Kontainer untuk mengidentifikasi dan memulihkan rekomendasi Defender untuk Cloud untuk gambar Kontainer Anda.
• Pertahanan Microsoft untuk Kontainer secara teratur memindai gambar kontainer Anda untuk kerentanan.
• Pertahanan Microsoft untuk Kontainer juga menghasilkan pemberitahuan keamanan real-time untuk aktivitas yang mencurigakan.
• Untuk informasi tentang pengetatan keamanan yang diterapkan pada host mesin virtual AKS, lihat Pengetatan Keamanan di OS host.

Operasi kluster dan beban kerja (DevOps)

Berikut adalah beberapa pertimbangan. Untuk informasi selengkapnya, lihat pilar Keunggulan Operasional.

Klaster bootstrapping

Setelah provisi selesai, Anda memiliki kluster yang berfungsi, tetapi mungkin masih ada langkah-langkah yang diperlukan sebelum menyebarkan beban kerja. Proses persiapan kluster Anda disebut bootstrapping, dan dapat terdiri dari tindakan seperti menyebarkan gambar prasyarat ke node kluster, membuat namespace layanan, dan hal lain yang memenuhi persyaratan kasus atau organisasi penggunaan Anda.

Untuk mengurangi kesenjangan antara kluster yang disediakan dan kluster yang telah dikonfigurasi dengan benar, operator kluster harus memikirkan seperti apa proses bootstrapping unik mereka dan menyiapkan aset yang relevan terlebih dahulu. Misalnya, jika memiliki Kured yang berjalan pada setiap node sebelum menyebarkan beban kerja aplikasi penting, operator kluster akan ingin memastikan ACR yang berisi gambar Kured target sudah ada sebelum menyediakan kluster.

Proses bootstrapping dapat dikonfigurasi menggunakan salah satu metode berikut:

• Konfigurasi mandiri menggunakan sesuatu seperti Flux atau Argo CD
• Pipelines
• Ekstensi kluster GitOps Flux v2

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 penyertaan 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, dan penggunaan kubectlakses berbasis dapat dicadangkan untuk situasi perbaikan darurat. Antara templat untuk definisi Azure Resource dan bootstrapping manifes melalui ekstensi GitOps, semua aktivitas konfigurasi normal dapat dilakukan 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. Menyediakan jaringan virtual untuk hub dan berbicara dan subnet dalam jaringan tersebut. Misalnya, spoke memiliki subnet terpisah untuk kumpulan node sistem dan pengguna, dan sumber daya ingress. Subnet untuk Azure Firewall di hub.

Bagian lain bisa untuk mengintegrasikan beban kerja dasar dengan ID Microsoft Entra.

Gunakan Infrastruktur sebagai Kode (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. Salah satu opsinya adalah templat Azure Resource Manager (ARM). Yang lain adalah Terraform.

Pastikan Anda menyediakan sumber daya sesuai kebijakan yang mengatur. Misalnya, saat memilih ukuran VM yang tepat, tetap dalam batasan biaya, opsi zona ketersediaan agar sesuai dengan persyaratan aplikasi Anda.

Jika Anda perlu menulis urutan perintah, gunakan Azure CLI. Perintah ini mencakup berbagai layanan Azure dan dapat diotomatisasi melalui skrip. Azure CLI didukung di Windows dan Linux. Opsi lintas platform lainnya adalah Azure PowerShell. Pilihan akan tergantung pada keahlian yang Anda pilih.

Skrip dan versi penyimpanan dan file templat di sistem kontrol sumber Anda.

Beban Kerja CI/CD

Alur dari alur kerja dan penyebaran harus memiliki kemampuan untuk membangun dan menyebarkan aplikasi secara terus menerus. Pembaruan harus diterapkan dengan aman dan cepat dan digulirkan kembali jika ada masalah.

Strategi penyebaran Anda harus menyertakan alur pengiriman berkelanjutan (CD) yang andal dan otomatis. Perubahan pada gambar kontainer beban kerja Anda harus diterapkan secara otomatis ke kluster.

Dalam arsitektur ini, kami telah memilih GitHub Tindakan untuk mengelola alur kerja dan penyebaran. Pilihan populer lainnya termasuk Azure DevOps Services 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 baru dan validasi versi tersebut sebelum disebarkan ke produksi, pertimbangkan alur GitOps.

Bagian penting dari alur CI/CD adalah bootstrapping kluster yang baru disediakan. Pendekatan GitOps berguna menjelang akhir ini, memungkinkan operator untuk secara deklaratif menentukan proses bootstrapping sebagai bagian dari strategi IaC dan melihat konfigurasi yang tercermin dalam kluster secara otomatis.

Saat 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 menetapkan kebijakan yang mengatur bagaimana perubahan tersebut diterapkan.

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

Unduh file Visio arsitektur ini.

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

2. Fluks berjalan di 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 menggunakan perintah kubectl.

4. Pengembang tidak memiliki akses langsung ke API Kubernetes melalui kubectl.

5. Memiliki kebijakan cabang di server Git Anda. Dengan begitu, beberapa pengembang dapat menyetujui perubahan melalui permintaan pull sebelum diterapkan ke produksi.

Meskipun GitOps dan Flux dapat dikonfigurasi secara manual, ekstensi kluster GitOps dengan Flux v2 direkomendasikan untuk AKS.

Strategi penyebaran beban kerja dan kluster

Terapkan perubahan apa pun (komponen arsitektur, beban kerja, konfigurasi kluster), ke setidaknya satu kluster AKS pra-produksi. Melakukannya akan mensimulasikan perubahan yang mungkin mengungkap masalah sebelum diterapkan ke produksi.

Jalankan tes/validasi pada setiap tahap sebelum beralih ke tahap berikutnya untuk memastikan Anda dapat mendorong pembaruan ke lingkungan produksi dengan cara yang sangat terkontrol dan meminimalkan gangguan dari masalah penyebaran yang tidak terduga. Penerapan ini harus mengikuti pola yang sama dengan produksi, menggunakan alur GitHub Actions atau operator Flux yang sama.

Teknik penerapan lanjutan seperti Penyebaran biru-hijau, pengujian A/B, dan rilis Canary, akan memerlukan proses tambahan dan kemungkinan alat. Flagger adalah solusi sumber terbuka yang populer untuk membantu menyelesaikan skenario penyebaran lanjutan Anda.

Cost management

Mulailah dengan meninjau daftar periksa desain pengoptimalan biaya dan daftar rekomendasi yang diuraikan dalam Well Architected Framework untuk AKS. Gunakan harga Azure untuk memperkirakan biaya layanan yang digunakan dalam arsitektur. Praktik terbaik lainnya dijelaskan di bagian Pengoptimalan Biaya dalam Microsoft Azure Well-Architected Framework.

Pertimbangkan untuk mengaktifkan analisis biaya AKS untuk alokasi biaya infrastruktur kluster terperinci oleh konstruksi tertentu Kubernetes.

Untuk meninjau pertimbangan manajemen biaya khusus untuk beban kerja berbasis Windows yang disertakan dalam kontainer Windows pada arsitektur referensi garis besar AKS, lihat artikel pendamping.

Provisikan

• Tidak ada biaya apa pun yang terkait dengan AKS dalam penyebaran, manajemen, dan operasi kluster Kubernetes. Apa yang memengaruhi biaya adalah instans komputer virtual, penyimpanan, data log, dan sumber daya jaringan yang digunakan oleh kluster. Pertimbangkan untuk memilih VM yang lebih murah untuk kumpulan node sistem. SKU 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.

• Untuk beban kerja produksi, tambahkan SLA Waktu Aktif. Namun, ada penghematan untuk kluster yang dirancang untuk beban kerja pengembangan/pengujian atau eksperimental di mana ketersediaan tidak perlu dijamin. Misalnya, SLO sudah cukup. Juga, jika beban kerja Anda mendukungnya, pertimbangkan untuk menggunakan kumpulan node spot khusus yang menjalankan SPOT VM.

  Untuk beban kerja non-produksi 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.

• Alih-alih memulai dengan kluster besar untuk memenuhi kebutuhan penskalaan, sediakan kluster dengan jumlah node minimum dan aktifkan autoscaler kluster untuk memantau dan membuat keputusan ukuran.

• Atur permintaan dan batasan pod untuk memungkinkan Kubernetes mengalokasikan sumber daya node dengan kepadatan yang lebih tinggi sehingga perangkat keras digunakan sesuai kapasitas.

• Mengaktifkan diagnostik pada kluster dapat meningkatkan biaya.

• Jika beban kerja Anda diperkirakan ada untuk waktu yang lama, Anda dapat berkomitmen menggunakan Reserved Virtual Machine Instances satu atau tiga tahun untuk mengurangi biaya node. Untuk informasi selengkapnya, lihat VM cadangan.

• Gunakan tag saat Anda membuat kumpulan node. Tag berguna dalam membuat laporan khusus untuk melacak biaya yang dikeluarkan. Tag memberikan kemampuan 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.

• Transfer data antar zona ketersediaan di suatu wilayah tidak gratis. Jika beban kerja Anda multi-wilayah atau ada transfer di seluruh zona ketersediaan, maka harapkan biaya bandwidth tambahan. Untuk informasi selengkapnya, lihat Lalu lintas di seluruh zona penagihan dan wilayah.

• Buat anggaran untuk tetap berada dalam batasan biaya yang diidentifikasi oleh organisasi. Salah satu caranya adalah dengan membuat anggaran melalui Azure Cost Management. Anda juga dapat membuat peringatan untuk mendapatkan notifikasi saat ambang batas tertentu terlampaui. Untuk informasi selengkapnya, lihat Membuat anggaran menggunakan templat.

Monitor

Untuk memantau biaya seluruh kluster, bersama dengan biaya komputasi, kumpulkan juga informasi biaya tentang penyimpanan, bandwidth, firewall, dan log. Azure menyediakan berbagai dasbor untuk memantau dan menganalisis biaya:

• Azure Advisor

• Azure Cost Management

Idealnya, pantau biaya secara real time atau setidaknya secara reguler untuk mengambil tindakan sebelum akhir bulan ketika biaya sudah dihitung. Juga pantau tren bulanan dari waktu ke waktu agar tetap sesuai anggaran.

Untuk membuat keputusan berbasis data, tentukan sumber daya mana (tingkat granular) yang paling banyak dikenakan biaya. Juga miliki pemahaman yang baik tentang meter yang digunakan untuk menghitung penggunaan setiap sumber daya. Dengan menganalisis metrik, Anda dapat menentukan apakah platform terlalu besar misalnya. Anda dapat melihat meteran penggunaan dalam metrik Azure Monitor.

Optimalkan

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

• Aktifkan kluster penskala otomatis untuk mendeteksi dan menghapus node yang kurang dimanfaatkan di kumpulan node.

• 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 node pengguna Anda ke 0 node ketika tidak ada harapan untuk menjalankannya. Selain itu, jika tidak ada beban kerja yang tersisa yang dijadwalkan untuk dijalankan di kluster Anda, pertimbangkan untuk menggunakan fitur Mulai/Berhenti AKS untuk mematikan semua komputasi, yang mencakup kumpulan node sistem Anda dan bidang kontrol AKS.

Untuk informasi terkait biaya lainnya, lihat harga AKS.

Langkah berikutnya

Lanjutkan pembelajaran tentang arsitektur garis besar AKS:

• Untuk mempelajari tentang hosting Microservices pada garis besar AKS, lihat Arsitektur layanan mikro Azure Kubernetes Service (AKS) tingkat lanjut.
• Untuk menerapkan garis besar AKS di beberapa wilayah, lihat garis besar AKS untuk kluster multi-wilayah.
• Untuk menerapkan garis besar AKS ke lingkungan PCI-DSS 3.2.1, lihat kluster yang diatur AKS untuk PCI-DSS 3.2.1.
• Untuk mempelajari tentang pertimbangan untuk menambahkan kontainer Windows ke arsitektur referensi, lihat artikel pendamping: Kontainer Windows pada arsitektur referensi garis besar AKS

Pelajari selengkapnya tentang AKS

• Tinjau peta jalan produk AKS, lihat Peta Jalan Layanan Azure Kubernetes di GitHub.
• Jika Anda memerlukan penyegaran pada Kubernetes, selesaikan pengantro kubernetes dan Kembangkan dan sebarkan aplikasi di jalur pembelajaran Kubernetes .

Sumber daya terkait

Lihat panduan terkait berikut:

• Ulasan Azure Well-Architected Framework untuk Azure Kubernetes Service (AKS)
• Akselerator Zona Pendaratan AKS, yang merupakan implementasi skala perusahaan berdasarkan arsitektur ini. Akselerator membantu Anda menyiapkan lingkungan Azure secara konsisten dan berulang menggunakan Infrastructure-As-Code (IaC) untuk penyebaran Azure Kubernetes Service (AKS).
• Panduan operasi Azure Kubernetes Services (AKS) hari ke-2

Lihat arsitektur terkait berikut ini:

• Arsitektur layanan mikro pada Azure Kubernetes Service
• Menggunakan Azure Firewall untuk membantu melindungi kluster Azure Kubernetes Service (AKS)
• GitOps untuk Azure Kubernetes Service
• Streaming data dengan AKS