Arsitektur layanan mikro Azure Kubernetes Service (AKS) Tingkat Lanjut

Arsitektur referensi ini merinci beberapa konfigurasi yang perlu dipertimbangkan saat menjalankan layanan mikro di Azure Kubernetes Services. Topiknya meliputi mengonfigurasi kebijakan jaringan, penskalaan otomatis pod, dan pelacakan terdistribusi di seluruh aplikasi berbasis layanan mikro.

Arsitektur ini dibuat dengan Arsitektur Dasar AKS, titik awal yang direkomendasikan Microsoft untuk infrastruktur AKS. Garis besar AKS merinci fitur infrastructural seperti ID Beban Kerja Microsoft Entra, pembatasan masuk dan keluar, batas sumber daya, dan konfigurasi infrastruktur AKS aman lainnya. Rincian infrastruktur ini tidak tercakup dalam dokumen ini. Sebaiknya pelajari garis besar AKS sebelum melanjutkan ke konten layanan mikro.

Implementasi referensi arsitektur ini tersedia di GitHub.

Arsitektur

Unduh file Visio arsitektur ini.

Jika Anda lebih suka memulai dengan contoh layanan mikro yang lebih mendasar di AKS, lihat Arsitektur layanan mikro di AKS.

Alur kerja

Alur permintaan ini menerapkan pola desain cloud Publisher-Subscriber, Competing Consumers, dan Perutean Gateway. Alur olah pesan berlangsung sebagai berikut:

1. Permintaan HTTPS diajukan untuk menjadwalkan pengambilan drone. Permintaan akan melewati Azure Application Gateway menuju aplikasi web penyerapan, yang berjalan sebagai layanan mikro dalam kluster di AKS.

2. Aplikasi web penyerapan menghasilkan pesan dan mengirimkannya ke antrean pesan Service Bus.

3. Sistem backend menetapkan drone dan memberi tahu pengguna. Alur kerjanya adalah:

   • Mengonsumsi informasi pesan dari antrean pesan Service Bus.
   • Mengirimkan permintaan HTTPS ke layanan mikro Pengiriman, yang meneruskan data ke penyimpanan data eksternal Azure Cache for Redis.
   • Mengirimkan permintaan HTTPS ke layanan mikro Penjadwal Drone.
   • Mengirimkan permintaan HTTPS ke layanan mikro Paket, yang meneruskan data ke penyimpanan data eksternal MongoDB.

4. Permintaan HTTPS GET digunakan untuk mengembalikan status pengiriman. Permintaan ini akan melewati Application Gateway menuju layanan mikro Pengiriman.

5. Layanan mikro pengiriman membaca data dari Azure Cache for Redis.

Komponen

Arsitektur ini menggunakan komponen Azure berikut:

Azure Kubernetes Service adalah penawaran Azure yang menyediakan kluster Kubernetes terkelola. Saat menggunakan AKS, server Kubernetes API dikelola oleh Azure. Node atau kumpulan node Kubernetes dapat diakses dan dapat dikelola oleh operator kluster.

Fitur infrastruktur AKS yang digunakan dalam arsitektur ini meliputi:

• Pemisahan kumpulan node sistem dan pengguna
• ID Microsoft Entra yang dikelola AKS untuk kontrol akses berbasis peran (RBAC)
• ID Beban Kerja Microsoft Entra
• Add-on Azure Policy untuk AKS
• Azure Container Networking Interface (CNI)
• Wawasan kontainer Azure Monitor

Azure Virtual Networks adalah lingkungan yang terisolasi dan sangat aman untuk menjalankan mesin virtual (VM) dan aplikasi. Arsitektur referensi ini menggunakan topologi jaringan virtual hub-spoke yang di-peer. Jaringan virtual hub menampung subnet Azure Bastion dan firewall Azure. Jaringan virtual spoke menampung subnet kumpulan node pengguna dan sistem AKS serta subnet Azure Application Gateway.

Azure Private Link mengalokasikan alamat IP privat tertentu untuk mengakses Azure Container Registry dan Key Vault dari Titik Akhir Privat dalam subnet kumpulan node pengguna dan sistem AKS.

Azure Application Gateway dengan Web Application Firewall (WAF) mengekspos rute HTTP ke kluster AKS dan menyeimbangkan beban lalu lintas web ke aplikasi web. Arsitektur ini menggunakan Azure Application Gateway Ingress Controller (AGIC) sebagai pengontrol masuk Kubernetes.

Azure Bastion menyediakan protokol desktop jarak jauh (RDP) yang aman dan akses Secure Shell (SSH) ke VM di jaringan virtual menggunakan Secure Socket Layer (SSL), tanpa perlu mengekspos VM melalui alamat IP publik.

Azure Firewall adalah layanan keamanan jaringan yang melindungi semua sumber daya Azure Virtual Network. Firewall ini hanya memungkinkan layanan yang disetujui dan nama domain yang sepenuhnya memenuhi syarat (FQDN) sebagai lalu lintas keluar.

Penyimpanan eksternal dan komponen lainnya:

Azure Key Vault menyimpan dan mengelola kunci keamanan untuk layanan AKS.

Azure Container Registry menyimpan gambar kontainer privat yang dapat dijalankan di kluster AKS. AKS mengautentikasi dengan Container Registry menggunakan identitas terkelola Microsoft Entra-nya. Anda juga dapat menggunakan registri kontainer lain seperti Docker Hub.

Azure Cosmos DB menyimpan data menggunakan Azure Cosmos DB sumber terbuka untuk MongoDB. Layanan mikro biasanya bersifat tanpa status dan menulis statusnya ke penyimpanan data eksternal. Azure Cosmos DB adalah database NoSQL dengan API sumber terbuka untuk MongoDB dan Cassandra.

Azure Service Bus menawarkan olah pesan cloud yang andal sebagai layanan dan integrasi hibrid sederhana. Service Bus mendukung pola olah pesan asinkron yang umum dengan aplikasi layanan mikro.

Azure Cache for Redis menambahkan lapisan caching ke arsitektur aplikasi untuk meningkatkan kecepatan dan performa bagi beban lalu lintas yang berat.

Azure Monitor mengumpulkan serta menyimpan metrik dan log, termasuk telemetri aplikasi serta metrik layanan dan platform Azure. Anda dapat menggunakan data ini untuk memantau aplikasi, menyiapkan peringatan dan dasbor, serta melakukan analisis akar penyebab kegagalan.

Komponen sistem pendukung operasi (OSS) lainnya:

Helm, pengelola paket untuk Kubernetes yang memaketkan objek Kubernetes ke dalam satu unit yang dapat diterbitkan, disebarkan, diubah versinya, dan diperbarui.

Penyedia Azure Key Vault Secret Store CSI, menyimpan rahasia di Azure Key Vault dan menggunakan antarmuka Driver Secret Store CSI untuk memasangnya ke pod Kubernetes.

Flux, solusi pengiriman berkelanjutan yang terbuka dan dapat diperluas untuk Kubernetes, yang didukung oleh GitOps Toolkit.

Detail skenario

Contoh Fabrikam Drone Delivery Shipping App yang ditunjukkan pada diagram sebelumnya menerapkan komponen arsitektur dan praktik yang dibahas dalam artikel ini. Dalam contoh ini, Fabrikam, Inc., sebuah perusahaan fiktif, mengelola armada pesawat tak berawak. Bisnis mendaftar dengan layanan, dan pengguna dapat meminta drone untuk mengambil barang untuk pengiriman. Ketika pelanggan menjadwalkan pengambilan, sistem backend menetapkan drone dan memberi tahu pengguna terkait perkiraan waktu pengiriman. Saat pengiriman sedang berlangsung, pelanggan dapat melacak lokasi drone dengan ETA yang terus diperbarui.

Kemungkinan kasus penggunaan

Solusi ini sangat ideal untuk industri pesawat terbang, dirgantara, dan penerbangan.

Rekomendasi

Terapkan rekomendasi ini saat menyebarkan arsitektur layanan mikro AKS tingkat lanjut.

Application Gateway Ingress Controller (AGIC)

Perutean Gateway API adalah pola desain layanan mikro umum. Gateway API bertindak sebagai proksi balik yang merutekan permintaan dari klien ke layanan mikro. Sumber daya masuk Kubernetes dan pengontrol masuk menangani sebagian besar fungsi gateway API dengan:

Merutekan permintaan klien ke layanan backend yang tepat akan menyediakan titik akhir tunggal untuk klien dan membantu memisahkan klien dari layanan.

• Menggabungkan beberapa permintaan menjadi satu permintaan untuk mengurangi obrolan antara klien dan backend.
• Memindahkan fungsi seperti penghentian SSL, autentikasi, pembatasan IP, dan pembatasan tarif klien dari layanan backend.

Status kluster AKS diterjemahkan ke konfigurasi khusus Application Gateway dan diterapkan melalui Azure Resource Manager.

Pengontrol masuk eksternal menyederhanakan penyerapan lalu lintas ke kluster AKS, meningkatkan keamanan dan performa, serta menghemat sumber daya. Arsitektur ini menggunakan Azure Application Gateway Ingress Controller (AGIC) untuk kontrol masuk. Dengan menggunakan Application Gateway untuk menangani semua lalu lintas, Anda tidak akan memerlukan penyeimbang beban tambahan. Karena pod membuat koneksi langsung terhadap Application Gateway, jumlah lompatan yang diperlukan akan berkurang, yang menghasilkan performa yang lebih baik.

Application Gateway memiliki kemampuan penskalaan otomatis bawaan, tidak seperti pengontrol masuk dalam kluster yang harus diskalakan jika menggunakan jumlah sumber daya komputasi yang tidak diinginkan. Application Gateway dapat melakukan perutean lapisan-7 dan penghentian SSL serta memiliki Keamanan Lapisan Transportasi (TLS) end-to-end yang terintegrasi dengan Web Application Firewall (WAF) bawaan.

Untuk opsi masuk AGIC, Anda harus mengaktifkan jaringan CNI saat mengonfigurasikan kluster AKS karena Application Gateway disebarkan ke subnet jaringan virtual AKS. Beban kerja multi-tenant, atau satu kluster yang mendukung lingkungan pengembangan dan pengujian, dapat memerlukan lebih banyak pengontrol masuk.

Kebijakan jaringan zero-trust

Kebijakan jaringan menentukan bagaimana pod AKS diizinkan untuk berkomunikasi satu sama lain dan dengan titik akhir jaringan lainnya. Secara default, semua lalu lintas masuk dan keluar diizinkan bergerak menuju dan dari pod. Saat mendesain bagaimana layanan mikro Anda berkomunikasi satu sama lain dan dengan titik akhir lainnya, sebaiknya ikuti prinsip zero trust, yakni saat akses ke layanan, perangkat, aplikasi, atau repositori data apa pun memerlukan konfigurasi eksplisit.

Salah satu strategi dalam menerapkan kebijakan zero-trust adalah membuat kebijakan jaringan yang menolak semua lalu lintas masuk dan keluar ke semua pod dalam namespace target. Contoh berikut menunjukkan 'kebijakan tolak semua' yang akan berlaku untuk semua pod yang terletak di namespace backend-dev.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Setelah kebijakan pembatasan diberlakukan, mulailah menentukan aturan jaringan tertentu untuk mengizinkan lalu lintas masuk dan keluar dari setiap pod dalam layanan mikro. Dalam contoh berikut, kebijakan jaringan diterapkan ke pod apa pun di namespace backend-dev dengan label yang cocok app.kubernetes.io/component: backend. Kebijakan tersebut menolak lalu lintas apa pun kecuali yang bersumber dari pod dengan label yang cocok app.kubernetes.io/part-of: dronedelivery.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app.kubernetes.io/part-of: dronedelivery
    ports:
    - port: 80
      protocol: TCP

Untuk informasi selengkapnya tentang kebijakan jaringan Kubernetes dan contoh tambahan dari kebijakan default yang mungkin, lihat Kebijakan Jaringan di dokumentasi Kubernetes.

Kuota sumber daya

Kuota sumber daya adalah cara bagi administrator untuk menghemat dan membatasi sumber daya di seluruh tim pengembangan atau proyek. Anda dapat mengatur kuota sumber daya di namespace dan menggunakannya untuk menetapkan batasan pada:

• Menghitung sumber daya , seperti CPU dan memori, atau GPU.
• Sumber daya penyimpanan, termasuk volume atau jumlah ruang disk untuk kelas penyimpanan tertentu.
• Jumlah objek, seperti jumlah maksimum rahasia, layanan, atau pekerjaan yang dapat dibuat.

Setelah total kumulatif permintaan atau batas sumber daya melewati kuota yang ditetapkan, tidak ada penyebaran lebih lanjut yang akan berhasil.

Kuota sumber daya memastikan bahwa total kumpulan pod yang ditetapkan ke namespace tidak dapat melebihi kuota sumber daya dari namespace. Layanan front end tidak dapat mengurangi sumber daya layanan backend atau sebaliknya.

Ketika Anda menentukan kuota sumber daya, semua Pod yang dibuat di namespace harus memberikan batasan atau permintaan dalam spesifikasi Pod-nya. Jika mereka tidak memberikan nilai-nilai ini, penyebaran akan ditolak.

Contoh berikut menunjukkan spesifikasi pod yang menetapkan permintaan dan batas kuota sumber daya:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Untuk informasi selengkapnya tentang kuota sumber daya, lihat:

• Menerapkan kuota sumber daya
• Kuota sumber daya

Penskalaan otomatis

Kubernetes mendukung penskalaan otomatis untuk meningkatkan jumlah pod yang dialokasikan untuk penyebaran atau meningkatkan node dalam kluster untuk meningkatkan total sumber daya komputasi yang tersedia. Penskalaan otomatis adalah sistem umpan balik otonom dengan koreksi mandiri. Meskipun Anda dapat menskalakan pod dan node secara manual, penskalaan otomatis meminimalkan kemungkinan layanan menjadi kekurangan sumber daya saat beban tinggi. Strategi penskalaan otomatis harus memperhitungkan pod dan node.

Penskalaan otomatis kluster

Autoscaler kluster (CA) menskalakan jumlah node. Misalkan pod tidak dapat dijadwalkan karena keterbatasan sumber daya; autoscaler kluster akan memprovisikan lebih banyak node. Anda menentukan jumlah minimum node untuk menjaga agar kluster AKS dan beban kerja Anda dapat tetap beroperasi serta jumlah maksimum node untuk lalu lintas padat. CA memeriksa adanya pod yang tertunda atau node kosong setiap beberapa detik dan menskalakan kluster AKS dengan tepat.

Contoh berikut menunjukkan konfigurasi CA dari templat ARM:

"autoScalerProfile": {
    "scan-interval": "10s",
    "scale-down-delay-after-add": "10m",
    "scale-down-delay-after-delete": "20s",
    "scale-down-delay-after-failure": "3m",
    "scale-down-unneeded-time": "10m",
    "scale-down-unready-time": "20m",
    "scale-down-utilization-threshold": "0.5",
    "max-graceful-termination-sec": "600",
    "balance-similar-node-groups": "false",
    "expander": "random",
    "skip-nodes-with-local-storage": "true",
    "skip-nodes-with-system-pods": "true",
    "max-empty-bulk-delete": "10",
    "max-total-unready-percentage": "45",
    "ok-total-unready-count": "3"
},

Baris berikut dalam set templat ARM memberikan contoh node minimum dan maksimum untuk CA:

"minCount": 2,
"maxCount": 5,

Penskalaan otomatis pod

Horizontal Pod Autoscaler (HPA) menskalakan pod berdasarkan CPU, memori, atau metrik kustom yang diamati. Untuk mengonfigurasi penskalaan pod horizontal, Anda harus menentukan metrik target serta jumlah replika minimum dan maksimum dalam spesifikasi pod penyebaran Kubernetes. Uji beban layanan Anda untuk menentukan angka-angka ini.

CA dan HPA dapat berfungsi bersama dengan baik, jadi aktifkan kedua opsi autoscaler di kluster AKS Anda. HPA menskalakan aplikasi, sementara CA menskalakan infrastruktur.

Contoh berikut menetapkan metrik sumber daya untuk HPA:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 60

HPA melihat sumber daya sebenarnya yang dikonsumsi atau metrik lain dari pod yang berjalan, tetapi CA memprovisikan node untuk pod yang belum dijadwalkan. Oleh karena itu, CA melihat sumber daya yang diminta, seperti yang ditentukan dalam spesifikasi pod. Gunakan pengujian beban untuk menyempurnakan nilai-nilai ini.

Pemeriksaan kesehatan

Kubernetes menyeimbangkan beban lalu lintas ke pod yang cocok dengan pemilih label untuk layanan. Hanya pod yang berhasil dimulai dan sehat yang menerima lalu lintas. Jika kontainer mengalami crash, Kubernetes akan menghapus pod dan menjadwalkan penggantian.

Di Kubernetes, pod dapat mengekspos dua jenis probe kesehatan:

• Probe keaktifan memberi tahu Kubernetes apakah pod berhasil dimulai dan sehat.
• Probe kesiapan memberi tahu Kubernetes apakah pod siap menerima permintaan.

Probe keaktifan menangani pod yang masih berjalan tetapi tidak sehat dan harus didaur ulang. Misalnya, jika kontainer yang melayani permintaan HTTP macet, kontainer tidak akan mengalami crash, tetapi berhenti melayani permintaan. Probe keaktifan HTTP berhenti merespons, yang memberi tahu Kubernetes untuk memulai ulang pod.

Terkadang, pod mungkin tidak siap untuk menerima lalu lintas, meskipun pod berhasil dimulai. Misalnya, aplikasi yang berjalan dalam kontainer mungkin melakukan tugas inisialisasi. Probe kesiapan menunjukkan apakah pod siap untuk menerima lalu lintas.

Layanan mikro harus mengekspos titik akhir dalam kode mereka yang memfasilitasi probe kesehatan, dengan penundaan dan batas waktu yang disesuaikan khusus untuk pemeriksaan yang mereka lakukan. Kunci rumus HPA hampir secara eksklusif berada di luar fase Siap pada pod, jadi adanya probe kesehatan yang akurat sangatlah penting.

Pemantauan

Dalam aplikasi layanan mikro, pemantauan Application Performance Management (APM) sangat penting untuk mendeteksi anomali, mendiagnosis masalah, dan memahami dependensi antarlayanan dengan cepat. Application Insights, yang merupakan bagian dari Azure Monitor, menyediakan pemantauan APM untuk aplikasi aktif yang ditulis dalam .NET Core, Node.js, Java, dan banyak bahasa aplikasi lainnya.

Application Insights:

• Mencatat permintaan HTTP, termasuk latensi dan kode hasil.
• Memungkinkan pelacakan terdistribusi secara default.
• Menyertakan ID operasi dalam jejak, sehingga Anda dapat mencocokkan semua jejak untuk operasi tertentu.
• Sering kali menyertakan informasi kontekstual tambahan dalam jejak.

Untuk mengontekstualisasikan telemetri layanan dengan dunia Kubernetes, integrasikan telemetri Azure Monitor dengan AKS untuk mengumpulkan metrik dari pengontrol, node, dan kontainer, serta log node dan kontainer. Jika Anda menggunakan .NET, pustaka Application Insights for Kubernetes dapat memperkaya telemetri Application Insights dengan informasi gambar, kontainer, node, pod, label, dan set replika.

Diagram berikut menunjukkan contoh peta dependensi aplikasi yang dihasilkan Application Insights untuk jejak telemetri layanan mikro AKS:

Untuk informasi selengkapnya tentang opsi penggunaan bahasa umum untuk integrasi Application Insights, lihat Pemantauan aplikasi untuk Kubernetes.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Skalabilitas

Pertimbangkan poin-poin berikut saat merencanakan skalabilitas.

• Jangan gabungkan penskalaan otomatis dan manajemen imperatif atau deklaratif dari jumlah replika. Pengguna dan autoscaler yang mencoba mengubah jumlah replika dapat menyebabkan perilaku yang tidak terduga. Saat HPA diaktifkan, kurangi jumlah replika menjadi jumlah minimum yang ingin Anda sebarkan.

• Efek samping dari penskalaan otomatis pod yakni pod dapat sering dibuat atau dikeluarkan karena terjadinya peristiwa scale-out dan scale-in. Untuk memitigasi efek ini:

  • Gunakan probe kesiapan untuk memberi tahu Kubernetes kapan pod baru siap menerima lalu lintas.
  • Gunakan anggaran gangguan pod untuk membatasi jumlah pod yang dapat dikeluarkan dari layanan dalam satu waktu.

• Anda tidak dapat mengubah ukuran VM setelah membuat kluster, jadi lakukan perencanaan kapasitas awal guna memilih ukuran VM yang sesuai untuk node agen saat Anda membuat kluster.

• Multi-tenant atau beban kerja tingkat lanjut lainnya mungkin memiliki persyaratan isolasi kumpulan node yang menuntut subnet yang lebih banyak dan mungkin lebih kecil. Untuk informasi selengkapnya tentang membuat kumpulan simpul dengan subnet unik, lihat Menambahkan kumpulan simpul dengan subnet unik. Organisasi memiliki standar yang berbeda untuk penerapan hub-spoke mereka. Pastikan untuk mengikuti panduan organisasi Anda.

Keterkelolaan

Pertimbangkan poin-poin berikut saat merencanakan pengelolaan.

• Kelola infrastruktur kluster AKS melalui alur penyebaran otomatis. Penerapan referensi untuk arsitektur ini menyediakan alur kerja GitHub Actions yang dapat Anda rujuk saat membuat alur.

• File alur kerja hanya menyebarkan infrastruktur, bukan beban kerja, ke jaringan virtual yang sudah ada dan konfigurasi Microsoft Entra. Menyebarkan infrastruktur dan beban kerja secara terpisah memungkinkan Anda mengatasi masalah siklus hidup dan operasional yang berbeda.

• Pertimbangkan alur kerja Anda sebagai mekanisme untuk melakukan penyebaran ke wilayah lain jika ada kegagalan regional. Buat alur sehingga Anda dapat menyebarkan kluster baru di wilayah baru dengan perubahan parameter dan input.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Pertimbangkan poin-poin berikut saat merencanakan keamanan.

• Pod AKS mengautentikasi dirinya sendiri dengan menggunakan identitas beban kerja yang disimpan di ID Microsoft Entra. Menggunakan identitas beban kerja lebih disukai karena tidak memerlukan rahasia klien.

• Dengan identitas terkelola, proses eksekusi dapat dengan cepat mendapatkan token Azure Resource Manager OAuth 2.0; tidak perlu kata sandi atau string koneksi. Di AKS, Anda dapat menetapkan identitas ke masing-masing pod dengan menggunakan ID Beban Kerja Microsoft Entra.

• Setiap layanan dalam aplikasi layanan mikro harus diberi identitas beban kerja unik untuk memfasilitasi penugasan RBAC dengan hak istimewa paling sedikit. Anda harus menetapkan identitas ke layanan yang membutuhkannya saja.

• Dalam kasus di mana komponen aplikasi memerlukan akses API Kubernetes, pastikan bahwa pod aplikasi dikonfigurasi untuk menggunakan akun layanan dengan akses API yang terlingkup dengan tepat. Untuk informasi selengkapnya tentang mengonfigurasi dan mengelola akun layanan Kubernetes, lihat Mengelola Akun Layanan Kubernetes.

• Tidak semua layanan Azure mendukung autentikasi sarana data menggunakan ID Microsoft Entra. Guna menyimpan info masuk atau rahasia aplikasi untuk layanan tersebut, untuk layanan pihak ketiga, atau untuk kunci API, gunakan Azure Key Vault. Azure Key Vault menyediakan manajemen terpusat, kontrol akses, enkripsi saat tidak aktif, dan audit semua kunci dan rahasia.

• Di AKS, Anda dapat memasang satu atau beberapa rahasia dari Key Vault sebagai volume. Pod kemudian dapat membaca rahasia Key Vault seperti volume biasa. Untuk informasi selengkapnya, lihat proyek secrets-store-csi-driver-provider-azure di GitHub.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

• Bagian Biaya dalam Microsoft Azure Well-Architected Framework menjelaskan pertimbangan biaya. Gunakan Kalkulator harga Azure untuk memperkirakan biaya skenario spesifik Anda.

• AKS tidak memiliki biaya yang terkait dengan penyebaran, manajemen, dan operasi kluster Kubernetes. Anda hanya membayar untuk instans VM, penyimpanan, dan sumber daya jaringan yang digunakan kluster. Penskalaan otomatis kluster dapat mengurangi biaya kluster secara signifikan dengan menghapus node kosong atau yang tidak digunakan.

• Untuk memperkirakan biaya sumber daya yang diperlukan, lihat Kalkulator Layanan Kontainer.

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

Langkah berikutnya

• Pengantar Azure Kubernetes Service
• Apa itu Azure Virtual Networks?
• Apa itu Azure Private Link?
• Apa itu Azure Application Gateway?
• Apa itu Azure Bastion?
• Tentang Azure Key Vault
• Pengantar Azure Container Registry
• Selamat datang di Microsoft Azure Cosmos DB
• Gambaran Umum Azure Monitor

Sumber daya terkait

• Arsitektur dasar untuk klaster Azure Kubernetes Service (AKS)
• Mendesain, membuat, dan mengoperasikan layanan mikro di Azure dengan Kubernetes
• Arsitektur layanan mikro di AKS
• Memantau arsitektur layanan mikro di AKS
• Skenario penyetelan performa: Transaksi bisnis terdistribusi
• Membangun alur CI/CD untuk layanan mikro di Kubernetes