Arsitektur layanan mikro di Azure Kubernetes Service

Arsitektur referensi ini menunjukkan aplikasi layanan mikro yang disebarkan ke Azure Kubernetes Service (AKS). Ini menggambarkan konfigurasi AKS dasar yang dapat menjadi titik awal untuk sebagian besar penyebaran. Artikel ini mengasumsikan pengetahuan dasar Kubernetes. Artikel ini berfokus terutama pada infrastruktur dan pertimbangan DevOps menjalankan arsitektur layanan mikro di AKS. Untuk panduan tentang cara mendesain layanan mikro, lihat Membuat layanan mikro di Azure.

Implementasi referensi arsitektur ini tersedia di GitHub.

Arsitektur

Unduh file Visio arsitektur ini.

Jika Anda lebih suka melihat contoh layanan mikro yang lebih di tingkat lanjut yang dibuat di atas arsitektur Baseline AKS, lihat Arsitektur layanan mikro Azure Kubernetes Service (AKS) tingkat lanjut

Alur kerja

Arsitektur ini terdiri dari komponen berikut.

Azure Kubernetes Service (AKS). AKS adalah kluster Kubernetes terkelola yang di-hosting di cloud Azure. Azure mengelola layanan API Kubernetes, dan Anda hanya perlu mengelola simpul agen.

Jaringan virtual. Secara default, AKS membuat jaringan virtual tempat node agen terhubung. Anda dapat membuat jaringan virtual terlebih dahulu untuk skenario yang lebih di tingkat lanjut, yang memungkinkan Anda mengontrol hal-hal seperti konfigurasi subnet, konektivitas lokal, dan alamat IP. Untuk informasi selengkapnya, lihat Mengonfigurasi jaringan tingkat lanjut di Azure Kubernetes Service (AKS).

Ingress. Server ingress mengekspos rute HTTP ke layanan di dalam kluster. Untuk informasi selengkapnya, lihat bagian Gateway API di bawah ini.

Azure Load Balancer. Setelah membuat kluster AKS, kluster siap menggunakan penyeimbang beban. Kemudian, setelah layanan NGINX disebarkan, penyeimbang beban akan dikonfigurasi dengan IP publik baru yang akan menghadap pengontrol ingress Anda. Dengan cara ini, penyeimbang beban merutekan lalu lintas internet ke ingress.

Penyimpanan data eksternal. Layanan mikro biasanya tanpa status dan status tulis ke penyimpanan data eksternal, seperti Azure SQL Database atau Azure Cosmos DB.

ID Microsoft Entra. AKS menggunakan identitas Microsoft Entra untuk membuat dan mengelola sumber daya Azure lainnya seperti load balancer Azure. ID Microsoft Entra juga direkomendasikan untuk autentikasi pengguna di aplikasi klien.

Azure Container Registry. Gunakan Container Registry untuk menyimpan gambar Docker pribadi, yang disebarkan ke kluster. AKS dapat mengautentikasi dengan Container Registry menggunakan identitas Microsoft Entra-nya. AKS tidak memerlukan Azure Container Registry. Anda dapat menggunakan registri kontainer lainnya, seperti Docker Hub. Pastikan registri kontainer Anda cocok atau melebihi perjanjian tingkat layanan (SLA) untuk beban kerja Anda.

Azure Pipelines. Azure Pipelines adalah bagian dari Azure DevOps Services dan menjalankan build, pengujian, dan penyebaran otomatis. Anda juga dapat menggunakan solusi CI/CD pihak ketiga seperti Jenkins.

Helm. Helm adalah manajer paket untuk Kubernetes, cara untuk menggabungkan dan menggeneralisasi objek Kubernetes menjadi satu unit yang dapat diterbitkan, disebarkan, dibuat versinya, dan diperbarui.

Azure Monitor. Azure Monitor mengumpulkan dan menyimpan metrik dan log, telemetri aplikasi, dan metrik platform untuk layanan Azure. Gunakan data ini untuk memantau aplikasi, mengatur peringatan, dasbor, dan melakukan analisis akar penyebab kegagalan. Azure Monitor terintegrasi dengan AKS untuk mengumpulkan metrik dari pengontrol, node, dan kontainer.

Pertimbangan

Desain

Arsitektur referensi ini berfokus pada arsitektur layanan mikro, meskipun banyak praktik yang direkomendasikan berlaku untuk beban kerja lain yang berjalan di AKS.

Microservice

Layanan mikro adalah unit kode yang dapat digunakan secara longgar dan dapat disebarkan secara independen. Layanan mikro biasanya berkomunikasi melalui API yang ditentukan dengan baik dan dapat ditemukan melalui beberapa bentuk penemuan layanan. Layanan harus selalu dapat dijangkau bahkan saat pod bergerak. Objek Kubernetes Service adalah cara alami untuk membuat model layanan mikro di Kubernetes.

Gateway API

Gateway API adalah pola desain layanan mikro umum. Gateway API berada di antara klien eksternal dan layanan mikro. Ini berfungsi sebagai proksi terbalik, merutekan permintaan dari klien ke layanan mikro. Ini juga dapat melakukan berbagai tugas lintas sektoral seperti autentikasi, penghentian SSL, dan pembatasan tarif. Untuk informasi selengkapnya, lihat:

• Menggunakan gateway API di layanan mikro
• Memilih teknologi gateway

Di Kubernetes, fungsionalitas gateway API utamanya ditangani oleh pengontrol Ingress. Pertimbangan akan dijelaskan di bagian Ingress.

Penyimpanan data

Dalam arsitektur layanan mikro, layanan tidak boleh berbagi solusi penyimpanan data. Setiap layanan harus mengelola himpunan datanya sendiri untuk menghindari ketergantungan tersembunyi di antara layanan. Pemisahan data membantu menghindari penyambungan yang tidak disengaja antara layanan, yang dapat terjadi saat layanan berbagi skema data dasar yang sama. Selain itu, saat layanan mengelola penyimpanan datanya sendiri, mereka dapat menggunakan penyimpanan data yang tepat untuk kebutuhan khusus mereka.

Untuk informasi selengkapnya, lihat Merancang layanan mikro: Pertimbangan data.

Hindari menyimpan data persisten dalam penyimpanan kluster lokal karena hal itu akan mengikat data ke node. Sebagai gantinya, gunakan layanan eksternal seperti Azure SQL Database atau Azure Cosmos DB. Opsi lainnya adalah memasang volume data persisten ke solusi menggunakan Azure Disks atau Azure Files.

Untuk informasi selengkapnya, lihat Opsi Storage untuk aplikasi di Azure Kubernetes Service.

Objek layanan

Objek Kubernetes Service memberikan serangkaian kemampuan yang sesuai dengan persyaratan layanan mikro untuk kemudahan penemuan layanan:

• Alamat IP. Objek Layanan menyediakan alamat IP internal statis untuk sekelompok pod (ReplicaSet). Saat pod dibuat atau dipindahkan, layanan selalu dapat dijangkau di alamat IP internal ini.

• Penyeimbangan beban. Lalu lintas yang dikirim ke alamat IP adalah beban seimbang dengan pod.

• Penemuan layanan Layanan diberi entri DNS internal oleh layanan DNS Kubernetes. Itu artinya gateway API dapat memanggil layanan backend menggunakan nama DNS. Mekanisme yang sama dapat digunakan untuk komunikasi layanan ke layanan. Entri DNS diatur oleh namespace, jadi jika namespace Anda sesuai dengan konteks terbatas, maka nama DNS untuk layanan akan dipetakan secara alami ke domain aplikasi.

Diagram berikut memperlihatkan hubungan konseptual antara layanan dan pod. Pemetaan aktual ke alamat IP titik akhir dan port dilakukan oleh proksi kube, proksi jaringan Kubernetes.

Ingress

Di Kubernetes, pengontrol Ingress dapat menerapkan pola gateway API. Dalam hal ini, Ingress dan pengontrol Ingress bekerja bersama untuk menyediakan fitur ini:

• Rutekan permintaan klien ke layanan backend yang tepat. Perutean ini menyediakan satu titik akhir untuk klien, dan membantu memisahkan klien dari layanan.

• Kumpulkan beberapa permintaan menjadi satu permintaan, untuk mengurangi obrolan antara klien dan backend.

• Pindahkan fungsi dari layanan backend, seperti penghentian SSL, autentikasi, pembatasan IP, atau pembatasan tarif klien (pembatasan).

Ingress mengabstraksi pengaturan konfigurasi untuk server proksi. Anda juga memerlukan pengontrol Ingress, yang menyediakan penerapan Ingress yang mendasarinya. Ada pengontrol Ingress untuk Nginx, HAProxy, Traefik, dan Azure Application Gateway, antara lain.

Sumber daya Ingress dapat dipenuhi oleh teknologi yang berbeda. Untuk bekerja sama, mereka harus digunakan sebagai pengontrol Ingress di dalam kluster. Ini beroperasi sebagai router tepi atau proksi terbalik. Server proksi terbalik adalah potensi penyempitan atau titik kegagalan tunggal, jadi selalu sebarkan setidaknya dua replika untuk ketersediaan tinggi.

Seringkali, mengonfigurasi server proksi membutuhkan file yang kompleks, yang bisa sulit untuk disetel jika Anda bukan seorang ahli. Jadi, pengontrol Ingress memberikan abstraksi yang bagus. Pengontrol Ingress juga memiliki akses ke API Kubernetes, sehingga dapat membuat keputusan cerdas tentang perutean dan penyeimbangan beban. Misalnya, pengontrol ingress Nginx melewati proksi jaringan proksi kube.

Di sisi lain, jika Anda memerlukan kontrol penuh atas pengaturan, Anda mungkin ingin melewati abstraksi ini dan mengonfigurasi server proksi secara manual. Untuk informasi selengkapnya, lihat Menyebarkan Nginx atau HAProxy ke Kubernetes.

Untuk informasi tentang layanan penyeimbangan beban di Azure, lihat Ringkasan opsi penyeimbangan beban di Azure.

Enkripsi TLS/SSL

Dalam penerapan umum, pengontrol Ingress digunakan untuk penghentian SSL. Jadi, sebagai bagian dari penerapan pengontrol Ingress, Anda perlu membuat sertifikat TLS. Hanya gunakan sertifikat yang ditandatangani sendiri untuk tujuan dev/test. Untuk informasi selengkapnya, lihat Membuat pengontrol ingress HTTPS dan menggunakan sertifikat TLS Anda sendiri di Azure Kubernetes Service (AKS).

Untuk beban kerja produksi, dapatkan sertifikat yang ditandatangani dari otoritas sertifikat tepercaya (CA). Untuk informasi tentang membuat dan mengonfigurasi sertifikat Let's Encrypt, lihat Membuat pengontrol ingress dengan alamat IP publik statis di Azure Kubernetes Service (AKS).

Anda mungkin juga perlu memutar sertifikat sesuai kebijakan organisasi. Untuk informasi selengkapnya, lihat, Memutar sertifikat di Azure Kubernetes Service (AKS).

Namespace

Gunakan namespace untuk mengatur layanan dalam kluster. Setiap objek dalam kluster Kubernetes adalah bagian dari namespace. Secara default, saat Anda membuat objek baru, objek tersebut masuk ke namespace default. Tapi itu adalah praktik yang baik untuk membuat namespace yang lebih deskriptif untuk membantu mengatur sumber daya dalam kluster.

Pertama, namespace membantu mencegah tabrakan penamaan. Ketika beberapa tim menyebarkan layanan mikro ke dalam kluster yang sama, dengan mungkin ratusan layanan mikro, akan sulit dikelola jika mereka semua masuk ke namespace yang sama. Selain itu, namespace memungkinkan Anda untuk:

• Menerapkan batasan sumber daya ke namespace, sehingga total kumpulan pod yang ditetapkan ke namespace tersebut tidak dapat melebihi kuota sumber daya dari namespace.

• Menerapkan kebijakan di tingkat namespace, termasuk RBAC dan kebijakan keamanan.

Untuk arsitektur layanan mikro, pertimbangkan untuk mengatur layanan mikro ke dalam konteks terikat, dan membuat ruang nama untuk setiap konteks terikat. Misalnya, semua layanan mikro yang terkait dengan konteks terikat "Pemenuhan Pesanan" dapat masuk ke namespace yang sama. Atau, buat namespace untuk setiap tim pengembangan.

Letakkan layanan utilitas ke dalam namespace mereka sendiri yang terpisah. Misalnya, Anda mungkin menyebarkan Elasticsearch atau Prometheus untuk pemantauan kluster, atau Tiller untuk Helm.

Pemeriksaan kesehatan

Kubernetes menentukan dua jenis probe kesehatan yang dapat diekspos oleh pod:

• Probe kesiapan: Memberi tahu Kubernetes apakah pod siap menerima permintaan.

• Probe keaktifan: Memberitahu Kubernetes apakah pod harus dihapus dan instans baru dimulai.

Saat memikirkan probe, ini berguna untuk mengingat cara kerja layanan di Kubernetes. Layanan memiliki pemilih label yang cocok dengan satu set (nol atau lebih) pod. Beban Kubernetes menyeimbangkan lalu lintas ke pod yang cocok dengan pemilih. Hanya pod yang berhasil dimulai dan sehat yang menerima lalu lintas. Jika kontainer mengalami crash, Kubernetes akan membunuh pod dan menjadwalkan penggantian.

Terkadang, pod mungkin tidak siap untuk menerima lalu lintas, meskipun pod berhasil dimulai. Misalnya, mungkin ada tugas inisialisasi, di mana aplikasi yang berjalan dalam kontainer memuat hal-hal ke dalam memori atau membaca data konfigurasi. Untuk menunjukkan bahwa pod sehat tetapi tidak siap untuk menerima lalu lintas, tentukan probe kesiapan.

Probe keaktifan menangani kasus saat pod masih berjalan, tetapi tidak sehat dan harus didaur ulang. Sebagai contoh, misalkan kontainer melayani permintaan HTTP tetapi macet karena alasan tertentu. Kontainer tidak mengalami crash, tetapi telah berhenti melayani permintaan apa pun. Jika Anda menentukan probe keaktifan HTTP, probe akan berhenti merespons dan yang menginformasikan Kubernetes untuk memulai ulang pod.

Berikut ini beberapa pertimbangan saat merancang probe:

• Jika kode Anda memiliki waktu startup yang lama, ada bahaya bahwa probe keaktifan akan melaporkan kegagalan sebelum startup selesai. Untuk mencegah kegagalan pemeriksaan ini, gunakan initialDelaySeconds pengaturan , yang menunda pemeriksaan dimulai.

• Probe keaktifan tidak membantu kecuali memulai ulang pod mungkin akan mengembalikannya ke keadaan sehat. Anda bisa menggunakan probe keaktifan untuk mengurangi kebocoran memori atau kebuntuan yang tidak terduga, tetapi tidak ada gunanya memulai kembali pod yang akan segera gagal lagi.

• Terkadang probe kesiapan digunakan untuk memeriksa layanan dependen. Misalnya, jika pod memiliki dependensi pada database, probe mungkin memeriksa koneksi database. Namun, pendekatan ini dapat menciptakan masalah yang tidak terduga. Layanan eksternal mungkin tidak tersedia untuk sementara karena beberapa alasan. Hal itu akan menyebabkan probe kesiapan gagal untuk semua pod dalam layanan Anda, menyebabkan semuanya dihapus dari penyeimbangan beban, dan dengan demikian menciptakan upstream kegagalan kaskade. Pendekatan yang lebih baik adalah menerapkan penanganan percobaan ulang dalam layanan Anda, sehingga layanan Anda dapat pulih dengan benar dari kegagalan sementara.

Batasan sumber daya

Ketidaksesuaian sumber daya dapat memengaruhi ketersediaan layanan. Tentukan batasan sumber daya untuk kontainer, sehingga satu kontainer tidak dapat membanjiri sumber daya kluster (memori dan CPU). Untuk sumber daya non-kontainer, seperti utas atau koneksi jaringan, pertimbangkan untuk menggunakan Pola Sekat untuk mengisolasi sumber daya.

Gunakan kuota sumber daya untuk membatasi total sumber daya yang diizinkan untuk namespace. Dengan begitu, frontend tidak dapat mengurangi sumber daya layanan backend atau sebaliknya.

Keamanan

Kontrol akses berbasis peran (RBAC)

Kubernetes dan Azure keduanya memiliki mekanisme untuk kontrol akses berbasis peran (RBAC):

• Azure RBAC mengontrol akses ke sumber daya di Azure, termasuk kemampuan untuk membuat sumber daya Azure baru. Izin dapat ditetapkan untuk pengguna, grup, atau perwakilan layanan. (Perwakilan layanan adalah identitas keamanan yang digunakan oleh aplikasi.)

• Kubernetes RBAC mengontrol izin ke API Kubernetes. Misalnya, membuat pod dan daftar pod adalah tindakan yang dapat diotorisasi (atau ditolak) kepada pengguna melalui Kubernetes RBAC. Untuk menetapkan izin Kubernetes ke pengguna, Anda membuat peran dan pengikatan peran:

  • Peran adalah sekumpulan izin yang berlaku dalam namespace. Izin didefinisikan sebagai kata kerja (mendapatkan, memperbarui, membuat, menghapus) pada sumber daya (pod, penyebaran, dll.).

  • RoleBinding menetapkan pengguna atau grup ke Peran.

  • Ada juga objek ClusterRole, yang seperti Peran tetapi berlaku untuk seluruh kluster, di semua namespace layanan. Untuk menetapkan pengguna atau grup ke ClusterRole, buat ClusterRoleBinding.

AKS mengintegrasikan dua mekanisme RBAC ini. Saat membuat kluster AKS, Anda dapat mengonfigurasinya untuk menggunakan ID Microsoft Entra untuk autentikasi pengguna. Untuk detail tentang cara menyiapkannya, lihat Mengintegrasikan ID Microsoft Entra dengan Azure Kubernetes Service.

Setelah ini dikonfigurasi, pengguna yang ingin mengakses API Kubernetes (misalnya, melalui kubectl) harus masuk menggunakan kredensial Microsoft Entra mereka.

Secara default, pengguna Microsoft Entra tidak memiliki akses ke kluster. Untuk memberikan akses, administrator kluster membuat RoleBindings yang merujuk ke pengguna atau grup Microsoft Entra. Jika pengguna tidak memiliki izin untuk operasi tertentu, proses ini akan gagal.

Jika pengguna tidak memiliki akses secara default, bagaimana admin kluster memiliki izin untuk membuat pengikatan peran terlebih dahulu? Kluster AKS sebenarnya memiliki dua jenis kredensial untuk memanggil server API Kubernetes: pengguna kluster dan admin kluster. Kredensial admin kluster memberikan akses penuh ke kluster. Perintah Azure CLI az aks get-credentials --admin mengunduh kredensial admin kluster dan menyimpannya ke file kubeconfig Anda. Administrator kluster dapat menggunakan kubeconfig ini untuk membuat peran dan pengikatan peran.

Alih-alih mengelola objek Role dan RoleBinding kluster Kubernetes secara asli di Kubernetes, lebih disukai untuk menggunakan Azure RBAC untuk Otorisasi Kubernetes. Ini memungkinkan manajemen terpadu dan kontrol akses di seluruh sumber daya Azure Resources, AKS, dan Kubernetes. Penetapan peran Azure RBAC ini dapat menargetkan kluster atau namespace dalam kluster untuk kontrol akses yang lebih halus. Azure RBAC mendukung serangkaian izin default terbatas, dan Anda dapat menggabungkannya dengan mekanisme Kubernetes asli untuk mengelola Peran dan RoleBindings untuk mendukung pola akses tingkat lanjut atau lebih terperinci. Saat diaktifkan, perwakilan Microsoft Entra akan divalidasi secara eksklusif oleh Azure RBAC sementara pengguna dan akun layanan Kubernetes reguler divalidasi secara eksklusif oleh Kubernetes RBAC.

Karena kredensial admin kluster sangat kuat, gunakan Azure RBAC untuk membatasi akses ke kredensial tersebut:

• "Peran Admin Kluster Azure Kubernetes Service" memiliki izin untuk mengunduh kredensial admin kluster. Hanya administrator kluster yang akan ditetapkan untuk peran ini.

• "Peran Pengguna Kluster Azure Kubernetes Service" memiliki izin untuk mengunduh kredensial pengguna kluster. Pengguna non-admin dapat ditetapkan untuk peran ini. Peran ini tidak memberikan izin tertentu pada sumber daya Kubernetes di dalam kluster - peran ini hanya memungkinkan pengguna untuk terhubung ke server API.

Saat Anda menentukan kebijakan RBAC (Kubernetes dan Azure), pikirkan peran dalam organisasi Anda:

• Siapa yang dapat membuat atau menghapus kluster AKS dan mengunduh kredensial admin?
• Siapa yang dapat mengelola kluster?
• Siapa yang dapat membuat atau memperbarui sumber daya dalam namespace?

Ini adalah praktik yang baik untuk menjangkau izin Kubernetes RBAC dengan namespace, menggunakan Peran dan RoleBindings, bukan ClusterRoles dan ClusterRoleBindings.

Terakhir, ada pertanyaan tentang izin apa yang harus dilakukan kluster AKS untuk membuat dan mengelola sumber daya Azure, seperti load balancer, jaringan, atau penyimpanan. Untuk mengautentikasi dirinya dengan Api Azure, kluster menggunakan perwakilan layanan Microsoft Entra. Jika Anda tidak menentukan perwakilan layanan saat membuat kluster, kluster akan dibuat otomatis. Namun, ini adalah praktik keamanan yang baik untuk membuat perwakilan layanan terlebih dahulu dan menetapkan izin RBAC minimal untuk itu. Untuk informasi selengkapnya, lihat Perwakilan layanan dengan Azure Kubernetes Service.

Manajemen rahasia dan kredensial aplikasi

Aplikasi dan layanan sering memerlukan kredensial yang memungkinkan mereka untuk terhubung ke layanan eksternal seperti Azure Storage atau SQL Database. Tantangannya adalah menjaga kredensial ini tetap aman dan tidak membocorkannya.

Untuk sumber daya Azure, salah satu opsinya adalah menggunakan identitas terkelola. Ide identitas terkelola adalah bahwa aplikasi atau layanan memiliki identitas yang disimpan di ID Microsoft Entra, dan menggunakan identitas ini untuk mengautentikasi dengan layanan Azure. Aplikasi atau layanan memiliki Perwakilan Layanan yang dibuat untuknya di ID Microsoft Entra, dan mengautentikasi menggunakan token OAuth 2.0. Kode proses yang dijalankan dapat secara transparan mendapatkan token untuk digunakan. Dengan begitu, Anda tidak perlu menyimpan kata sandi atau string koneksi apa pun. Anda dapat menggunakan identitas terkelola di AKS dengan menetapkan identitas Microsoft Entra ke pod individual, menggunakan ID Beban Kerja Microsoft Entra (pratinjau).

Saat ini, tidak semua layanan Azure mendukung autentikasi menggunakan identitas terkelola. Untuk daftar, lihat Layanan Azure yang mendukung autentikasi Microsoft Entra.

Bahkan dengan identitas terkelola, Anda mungkin harus menyimpan beberapa kredensial atau rahasia aplikasi lainnya, baik untuk layanan Azure yang tidak mendukung identitas terkelola, layanan pihak ketiga, kunci API, dan sebagainya. Berikut ini beberapa opsi untuk menyimpan rahasia dengan aman:

• Azure Key Vault. Di AKS, Anda dapat memasang satu atau beberapa rahasia dari Key Vault sebagai volume. Volume akan membaca rahasia dari Key Vault. Pod kemudian dapat membaca rahasia seperti volume biasa. Untuk informasi selengkapnya, lihat Menggunakan Penyedia Azure Key Vault untuk Driver CSI Penyimpanan Rahasia di kluster AKS.

  Pod mengautentikasi dirinya sendiri dengan menggunakan identitas beban kerja atau dengan menggunakan identitas terkelola yang ditetapkan pengguna atau sistem. Lihat Memberikan identitas untuk mengakses Penyedia Azure Key Vault untuk Driver Secrets Store CSI untuk pertimbangan selengkapnya.

• HashiCorp Vault. Aplikasi Kubernetes dapat mengautentikasi dengan HashiCorp Vault menggunakan identitas terkelola Microsoft Entra. Lihat HashiCorp Vault berbicara ID Microsoft Entra. Anda dapat menyebarkan Vault sendiri ke Kubernetes, pertimbangkan untuk menjalankannya di kluster khusus yang terpisah dari kluster aplikasi Anda.

• Rahasia Kubernetes. Pilihan lainnya adalah hanya menggunakan rahasia Kubernetes. Opsi inilah yang paling mudah dikonfigurasi tetapi memiliki beberapa tantangan. Rahasia akan disimpan dalam etcd, yang merupakan penyimpanan kunci-nilai terdistribusi. AKS mengenkripsi etcd saat tidak aktif. Microsoft mengelola kunci enkripsi.

Menggunakan sistem seperti HashiCorp Vault atau Azure Key Vault memberikan beberapa keuntungan, seperti:

• Kontrol rahasia terpusat.
• Memastikan bahwa semua rahasia dienkripsi saat tidak aktif.
• Manajemen kunci terpusat.
• Akses kontrol rahasia.
• Audit

Keamanan Kontainer dan Orkestrator

Ini adalah praktik yang disarankan untuk mengamankan pod dan kontainer Anda:

• Pemantauan ancaman: Pantau ancaman menggunakan Pertahanan Microsoft untuk Kontainer (atau kemampuan pihak ke-3). Jika Anda menghosting kontainer di VM, gunakan Pertahanan Microsoft untuk server atau kemampuan pihak ke-3. Selain itu, Anda dapat mengintegrasikan log dari Solusi Pemantauan Kontainer di Azure Monitor ke Microsoft Sentinel atau solusi SIEM yang ada.

• Pemantauan kerentanan: Terus memantau gambar dan menjalankan kontainer untuk kerentanan yang diketahui menggunakan Microsoft Defender untuk Cloud atau solusi pihak ke-3 yang tersedia melalui Azure Marketplace.

• Otomatiskan patching gambar menggunakan Tugas ACR, fitur Azure Container Registry. Gambar kontainer dibuat dari lapisan. Lapisan dasar termasuk gambar OS dan gambar kerangka kerja aplikasi, seperti ASP.NET Core atau Node.js. Gambar dasar biasanya dibuat di upstream dari pengembang aplikasi, dan dikelola oleh pengelola proyek lainnya. Ketika gambar ini diproses dengan patch di upstream, penting untuk memperbarui, menguji, dan memindahkan gambar Anda sendiri, sehingga Anda tidak meninggalkan kerentanan keamanan yang diketahui. Tugas ACR dapat membantu mengotomatiskan proses ini.

• Simpan gambar di registri privat tepercaya seperti Azure Container Registry atau Registri Tepercaya Docker. Gunakan webhook penerimaan validasi di Kubernetes untuk memastikan bahwa pod hanya dapat menarik gambar dari registri tepercaya.

• Prinsip Menerapkan Hak Istimewa Terkecil

  • Jangan menjalankan kontainer dalam mode dengan hak istimewa. Mode dengan hak istimewa memberi kontainer akses ke semua perangkat di host.
  • Jika memungkinkan, hindari menjalankan proses sebagai akar di dalam kontainer. Kontainer tidak memberikan isolasi penuh dari sudut pandang keamanan, sehingga lebih baik menjalankan proses kontainer sebagai pengguna yang tidak memiliki hak istimewa.

DevOps

Arsitektur referensi ini menyediakan templat Azure Resource Manager untuk menyediakan sumber daya cloud, dan dependensinya. Dengan penggunaan [templat Azure Resource Manager][arm-template] Anda dapat menggunakan Azure DevOps Services untuk menyediakan lingkungan yang berbeda dalam hitungan menit, misalnya untuk mereplikasi skenario produksi. Ini memungkinkan Anda menghemat biaya dan memprovisikan lingkungan pengujian beban hanya jika diperlukan.

Pertimbangkan untuk mengikuti kriteria isolasi beban kerja untuk menyusun template ARM Anda, beban kerja biasanya ditentukan sebagai unit fungsionalitas arbitrer; misalnya, Anda bisa memiliki template terpisah untuk kluster dan kemudian lainnya untuk layanan dependen. Isolasi beban kerja memungkinkan DevOps untuk melakukan integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD), karena setiap beban kerja dikaitkan dan dikelola oleh tim DevOps yang sesuai.

Pertimbangan penyebaran (CI/CD)

Berikut ini beberapa tujuan dari proses CI/CD yang kuat untuk arsitektur layanan mikro:

• Setiap tim dapat membuat dan menyebarkan layanan yang dimilikinya secara independen, tanpa memengaruhi atau mengganggu tim lain.
• Sebelum layanan versi baru ditempatkan ke produksi, versi ini akan ditempatkan ke lingkungan dev/test/QA untuk validasi. Gerbang kualitas akan diberlakukan pada setiap tahap.
• Layanan versi baru dapat ditempatkan secara berdampingan dengan versi sebelumnya.
• Kebijakan kontrol akses yang memadai sudah ada.
• Untuk pembatasan beban kerja, Anda dapat mempercayai gambaran wadah yang ditempatkan ke produksi.

Untuk mempelajari selengkapnya tentang tantangan, lihat CI/CD untuk arsitektur layanan mikro.

Untuk rekomendasi dan praktik terbaik yang spesifik, lihat CI/CD untuk layanan mikro di Kubernetes.

Pengoptimalan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Pertimbangan lainnya dijelaskan di bagian Biaya di Microsoft Azure Well-Architected Framework.

Berikut ini beberapa poin yang perlu dipertimbangkan untuk beberapa layanan yang digunakan dalam arsitektur ini.

Azure Kubernetes Service (AKS)

Tidak ada biaya yang terkait untuk AKS dalam penyebaran, manajemen, dan operasi kluster Kubernetes. Anda hanya membayar instans komputer virtual, penyimpanan, dan sumber daya jaringan yang digunakan oleh kluster Kubernetes kamu.

Untuk memperkirakan biaya sumber daya yang diperlukan, silakan lihat kalkulator Layanan Kontainer.

Azure Load Balancer

Anda hanya dikenakan biaya untuk jumlah aturan penyeimbangan beban dan keluar yang dikonfigurasi. Aturan NAT masuk gratis. Tidak ada biaya per jam untuk Standard Load Balancer jika tidak ada aturan yang dikonfigurasi.

Untuk informasi selengkapnya, lihat Harga Azure Load Balancer.

Azure Pipelines

Arsitektur referensi ini hanya menggunakan Azure Pipelines. Azure menawarkan Azure Pipeline sebagai Layanan individu. Anda diizinkan melakukan pekerjaan gratis yang dihosting Microsoft dengan 1.800 menit per bulan untuk CI/CD dan satu pekerjaan yang dihost sendiri dengan menit tanpa batas per bulan, pekerjaan tambahan memiliki biaya. Untuk informasi selengkapnya, lihat Harga Layanan Azure DevOps.

Azure Monitor

Untuk Azure Monitor Log Analytics, Anda dikenakan biaya untuk penyerapan dan retensi data. Untuk informasi selengkapnya, lihat Harga Azure Monitor.

Menyebarkan skenario ini

Untuk menyebarkan penerapan referensi untuk arsitektur ini, ikuti langkah-langkah dalam repositori GitHub.

Langkah berikutnya

• Perwakilan layanan dengan Azure Kubernetes Service
• Pertahanan Microsoft untuk Kontainer
• Microsoft Defender untuk server
• Solusi Pemantauan Kontainer di Azure Monitor
• Microsoft Sentinel atau solusi SIEM yang ada.
• Microsoft Defender untuk Cloud atau solusi pihak ke-3 yang tersedia melalui Marketplace Azure.
• Tugas ACR

Sumber daya terkait

• Untuk mengerjakan contoh layanan mikro yang lebih di tingkat lanjut, lihat Arsitektur layanan mikro Azure Kubernetes Service (AKS) tingkat lanjut
• Untuk mempelajari tentang pemantauan arsitektur ini, lihat Memantau arsitektur layanan mikro di Azure Kubernetes Service (AKS).
• Untuk mempelajari cara kami mengukur performa aplikasi ini, lihat Skenario penyetelan performa: Transaksi bisnis terdistribusi.
• CI/CD untuk arsitektur layanan mikro
• CI/CD untuk layanan mikro dalam Kubernetes