Edit

Bagikan melalui

Arsitektur layanan mikro di Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

Arsitektur referensi ini menunjukkan aplikasi layanan mikro yang disebarkan ke Azure Kubernetes Service (AKS). Ini menjelaskan konfigurasi AKS dasar yang dapat Anda gunakan sebagai titik awal untuk sebagian besar penyebaran. Artikel ini mengasumsikan bahwa Anda memiliki pemahaman dasar tentang Kubernetes. Artikel ini terutama menyoroti aspek infrastruktur dan DevOps tentang cara mengelola layanan mikro di AKS. Untuk informasi selengkapnya tentang cara merancang layanan mikro, lihat desain arsitektur Layanan Mikro.

logo GitHub. Implementasi referensi arsitektur ini tersedia di GitHub.

Sistem

Diagram yang menunjukkan layanan mikro pada arsitektur referensi AKS.

Helm adalah merek dagang dari Cloud Native Computing Foundation (CNCF). Tidak ada dukungan yang tersirat oleh penggunaan tanda ini.

Unduh file Visio arsitektur ini.

Jika Anda ingin melihat contoh layanan mikro yang lebih canggih yang dibangun di atas arsitektur garis besar AKS, lihat arsitektur layanan mikro AKS canggih .

Alur kerja

Alur permintaan ini mengimplementasikan pelanggan penerbit, konsumen yang bersaing, dan perutean gateway pola desain cloud.

Aliran data berikut sesuai dengan diagram sebelumnya:

  1. Aplikasi klien mengirimkan payload JSON melalui HTTPS ke nama domain publik yang sepenuhnya memenuhi syarat dari load balancer (pengontrol ingress terkelola) untuk menjadwalkan pengambilan drone.

    • Pengontrol ingress terkelola merutekan permintaan ke layanan mikro penyerapan.

    • Layanan mikro penyerapan memproses permintaan dan antrean permintaan pengiriman dalam antrean Azure Service Bus.

  2. Layanan mikro alur kerja:

    • Mengonsumsi informasi pesan dari antrean pesan Service Bus.

    • Mengirim permintaan HTTPS ke layanan mikro pengiriman, yang meneruskan data ke penyimpanan data eksternal di Azure Cache for Redis.

    • Mengirim permintaan HTTPS ke layanan mikro penjadwal drone.

    • Mengirim permintaan HTTPS ke layanan mikro paket, yang meneruskan data ke penyimpanan data eksternal di MongoDB.

  3. Permintaan HTTPS GET mengembalikan status pengiriman. Permintaan ini melewati pengontrol ingress terkelola ke dalam layanan mikro pengiriman. Kemudian layanan mikro pengiriman membaca data dari Azure Cache for Redis.

Untuk informasi selengkapnya tentang sampel aplikasi layanan mikro, lihat sampel implementasi referensi layanan mikro .

Komponen

  • AKS adalah kluster Kubernetes terkelola yang dihosting di cloud Azure. AKS mengurangi kompleksitas dan overhead operasional dalam mengelola Kubernetes dengan membongkar sebagian besar tanggung jawab tersebut ke Azure.

  • Server masuk mengekspos rute HTTP ke layanan di dalam kluster. Implementasi referensi menggunakan pengontrol ingress berbasis NGINX terkelola melalui add-on perutean aplikasi. Pengontrol ingress mengimplementasikan pola gateway API untuk layanan mikro.

  • Penyimpanan data eksternal, seperti Azure SQL Database atau Azure Cosmos DB, digunakan oleh layanan mikro stateless untuk menulis data dan informasi status lainnya. Implementasi referensi menggunakan Azure Cosmos DB, Azure Cache for Redis, Azure Cosmos DB for MongoDB dan Service Bus sebagai penyimpanan data atau tempat untuk menyimpan status.

  • Microsoft Entra ID diperlukan untuk kluster AKS. Ini menyediakan identitas terkelola yang digunakan untuk mengakses Azure Container Registry dan untuk mengakses dan menyediakan sumber daya Azure seperti load balancer dan disk terkelola. Beban kerja yang disebarkan pada kluster AKS juga masing-masing memerlukan identitas di Microsoft Entra untuk mengakses sumber daya yang dilindungi Microsoft Entra, seperti Azure Key Vault dan Microsoft Graph. Dalam arsitektur referensi ini, ID Beban Kerja Microsoft Entra terintegrasi dengan Kubernetes dan menyediakan beban kerja dengan identitas. Anda juga dapat menggunakan identitas terkelola atau kredensial aplikasi untuk setiap beban kerja.

  • Container Registry dapat digunakan untuk menyimpan gambar kontainer privat, yang disebarkan ke kluster. AKS dapat mengautentikasi dengan Container Registry dengan menggunakan identitas Microsoft Entra-nya. Dalam implementasi referensi, gambar kontainer layanan mikro dibangun dan didorong ke Container Registry.

  • Azure Pipelines adalah bagian dari rangkaian Azure DevOps dan menjalankan build, pengujian, dan penyebaran otomatis. Pendekatan integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) sangat didorong dalam lingkungan layanan mikro. Berbagai tim dapat secara independen membangun dan menyebarkan layanan mikro ke AKS dengan menggunakan Azure Pipelines.

  • Helm adalah manajer paket untuk Kubernetes yang menyediakan mekanisme untuk memaketkan dan menstandarkan objek Kubernetes ke dalam satu unit yang dapat diterbitkan, disebarkan, di-versi, dan diperbarui.

  • Azure Monitor mengumpulkan dan menyimpan metrik dan log, telemetri aplikasi, dan metrik platform untuk layanan Azure. Azure Monitor terintegrasi dengan AKS untuk mengumpulkan metrik dari pengontrol, node, dan kontainer.

  • Application Insights memantau layanan mikro dan kontainer. Ini dapat digunakan untuk memberikan pengamatan ke layanan mikro, yang mencakup arus lalu lintas, latensi end-to-end, dan persentase kesalahan. Kesehatan layanan mikro dan hubungan di antara mereka dapat ditampilkan pada satu peta aplikasi.

Alternatif

Azure Container Apps memberikan pengalaman Kubernetes tanpa server terkelola. Ini berfungsi sebagai alternatif yang lebih sederhana untuk AKS untuk menghosting layanan mikro ketika Anda tidak memerlukan akses langsung ke Kubernetes atau API-nya dan tidak memerlukan kontrol atas infrastruktur kluster.

Alih-alih gateway ingress terkelola di AKS, Anda dapat menggunakan alternatif seperti Application Gateway untuk Kontainer, gateway masuk Istio, atau solusi non-Microsoft. Untuk informasi selengkapnya, lihat Ingress di AKS.

Anda dapat menyimpan gambar kontainer di registri kontainer non-Microsoft seperti Docker Hub.

Untuk layanan mikro yang perlu mempertahankan informasi status, Dapr menyediakan lapisan abstraksi untuk mengelola status layanan mikro.

Anda dapat menggunakan GitHub Actions untuk membangun dan menyebarkan layanan mikro, atau memilih solusi CI/CD non-Microsoft seperti Jenkins.

Pengamatan layanan mikro dapat dicapai dengan alat alternatif seperti Kiali.

Detail skenario

Contoh implementasi referensi layanan mikro mengimplementasikan komponen dan praktik arsitektur yang dijelaskan dalam artikel ini. Dalam contoh ini, perusahaan fiktif bernama Fabrikam, Inc., mengelola armada pesawat drone. Bisnis mendaftar dengan layanan, dan pengguna dapat meminta drone untuk mengambil barang untuk pengiriman. Ketika pelanggan menjadwalkan penjemputan, sistem back-end menetapkan drone dan memberi tahu pengguna dengan perkiraan waktu pengiriman. Ketika pengiriman sedang berlangsung, pelanggan dapat melacak lokasi drone dengan perkiraan waktu pengiriman yang terus diperbarui.

Skenario ini bertujuan untuk menunjukkan arsitektur layanan mikro dan praktik terbaik penyebaran di AKS.

Potensi kasus penggunaan

Adopsi praktik terbaik berikut dari skenario untuk merancang aplikasi berbasis layanan mikro kompleks di AKS:

  • Aplikasi web kompleks
  • Logika bisnis yang dikembangkan dengan menggunakan prinsip desain layanan mikro

Pertimbangan

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

Rancang

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

Layanan mikro

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. Objek layanan Kubernetes adalah cara umum untuk memodelkan layanan mikro di Kubernetes.

Penyimpanan data

Dalam arsitektur layanan mikro, layanan tidak boleh berbagi solusi penyimpanan data. Setiap layanan harus mengelola himpunan datanya sendiri untuk menghindari dependensi tersembunyi di antara layanan. Pemisahan data membantu menghindari kopling yang tidak disengaja antar layanan. Proses ini dapat terjadi ketika layanan berbagi skema data yang mendasar yang sama. Saat layanan mengelola penyimpanan data mereka sendiri, mereka dapat menggunakan penyimpanan data yang benar untuk persyaratan khusus mereka. Untuk informasi selengkapnya, lihat pertimbangan data untuk layanan mikro.

Hindari menyimpan data persisten di penyimpanan kluster lokal karena metode tersebut mengikat data ke simpul. Sebagai gantinya, gunakan layanan eksternal seperti SQL Database atau Azure Cosmos DB. Opsi lain adalah memasang volume data persisten ke solusi dengan menggunakan Azure Disk Storage atau Azure Files. Untuk informasi selengkapnya, lihat Opsi Microsoft Azure Storage untuk aplikasi di AKS.

Gateway API

Gateway API adalah pola desain layanan mikro umum. Gateway API berada di antara klien eksternal dan layanan mikro. Gateway berfungsi sebagai proksi terbalik dan merutekan permintaan dari klien ke layanan mikro. Gateway API mungkin juga melakukan berbagai tugas lintas pemotongan seperti autentikasi, penghentian Secure Sockets Layer (SSL), dan pembatasan tarif. Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Di Kubernetes, pengontrol ingress terutama menangani fungsionalitas gateway API. Pengontrol ingress dan ingress bekerja bersama dengan:

  • Rutekan permintaan klien ke layanan mikro back-end yang benar. Perutean ini menyediakan satu titik akhir untuk klien dan membantu memisahkan klien dari layanan.

  • Agregat beberapa permintaan ke dalam satu permintaan untuk mengurangi obrolan antara klien dan ujung belakang.

  • Fungsionalitas offload dari layanan back-end, seperti penghentian SSL, autentikasi, pembatasan alamat IP, atau pembatasan laju klien (disebut pembatasan).

Ada pengontrol ingress untuk proksi terbalik, yang mencakup NGINX, HAProxy, Traefik, dan Azure Application Gateway. AKS menyediakan beberapa opsi ingress terkelola. Anda dapat memilih dari pengontrol ingress berbasis NGINX terkelola melalui add-on perutean aplikasi, Application Gateway untuk Kontainer. Atau Anda dapat memilih gateway masuk Istio sebagai pengontrol ingress. Untuk informasi selengkapnya, lihat Ingress di AKS.

Sumber daya ingress objek Kubernetes telah digantikan oleh API Gateway Kubernetes yang lebih canggih dan serbaguna. Pengontrol Ingress dan GATEWAY API adalah objek Kubernetes yang digunakan untuk perutean manajemen lalu lintas dan penyeimbangan beban. Dirancang untuk berorientasi generik, ekspresif, dapat diperluas, dan berorientasi peran, API Gateway adalah sekumpulan API modern untuk menentukan aturan perutean L4 dan L7 di Kubernetes.

Pengontrol ingress beroperasi sebagai router tepi atau proksi terbalik. Server proksi terbalik adalah penyempitan potensial atau titik kegagalan tunggal, jadi kami sarankan Anda menyebarkan setidaknya dua replika untuk membantu memastikan ketersediaan tinggi.

Kapan memilih pengontrol ingress atau Gateway API

Sumber daya Ingress cocok untuk kasus penggunaan berikut:

  • Pengontrol Ingress mudah diatur dan cocok untuk penyebaran Kubernetes yang lebih kecil dan kurang kompleks yang memprioritaskan konfigurasi yang mudah.

  • Jika saat ini Anda memiliki pengontrol ingress yang dikonfigurasi di kluster Kubernetes dan memenuhi persyaratan Anda secara efektif, mungkin tidak ada kebutuhan langsung untuk beralih ke API Gateway Kubernetes.

Anda harus menggunakan API Gateway:

  • Saat Anda berurusan dengan konfigurasi perutean yang kompleks, pemisahan lalu lintas, dan strategi manajemen lalu lintas tingkat lanjut. Fleksibilitas yang disediakan oleh sumber daya Rute API Kubernetes Gateway sangat penting.

  • Jika persyaratan jaringan memerlukan solusi kustom atau integrasi plugin non-Microsoft. Pendekatan API Gateway Kubernetes, berdasarkan definisi sumber daya kustom, dapat memberikan ekstensibilitas yang ditingkatkan.

Keandalan

Keandalan memastikan aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untukKeandalan .

Mempartisi layanan mikro

Gunakan namespace untuk mengatur layanan dalam kluster. Setiap objek dalam kluster Kubernetes adalah bagian dari namespace. Ini adalah praktik yang baik untuk menggunakan namespace layanan untuk mengatur sumber daya dalam kluster.

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. Namespace juga memungkinkan Anda untuk:

  • Terapkan batasan sumber daya ke namespace sehingga total set pod yang ditetapkan ke namespace tersebut tidak dapat melebihi kuota sumber daya namespace layanan.

  • Terapkan kebijakan di tingkat namespace, yang mencakup kontrol akses berbasis peran (RBAC) dan kebijakan keamanan.

Ketika beberapa tim mengembangkan dan menyebarkan layanan mikro, Anda dapat menggunakan namespace layanan sebagai mekanisme yang nyaman untuk mengontrol area yang dapat disebarkan oleh setiap tim. Misalnya, tim pengembangan A hanya dapat diberikan akses ke namespace A, dan tim pengembangan B hanya dapat diberikan akses ke namespace B melalui Kubernetes kebijakan RBAC.

Untuk arsitektur layanan mikro, pertimbangkan untuk mengatur layanan mikro ke dalam konteks terikat dan membuat namespace layanan 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 dapat menyebarkan alat pemantauan kluster seperti Elasticsearch dan Prometheus ke namespace pemantauan.

Pemeriksaan kesehatan

Kubernetes mendefinisikan tiga jenis pemeriksaan kesehatan yang dapat diekspos pod:

  • Readiness probe: Memberi tahu Kubernetes apakah pod siap menerima permintaan.

  • Pemeriksaan keaktifan: Memberi tahu Kubernetes apakah pod harus dihapus dan instans baru dimulai.

  • Startup probe: Memberi tahu Kubernetes apakah pod dimulai.

Ketika Anda berpikir tentang pemeriksaan, penting untuk mengingat cara kerja layanan di Kubernetes. Layanan memiliki pemilih label yang cocok dengan satu set pod nol atau lebih. 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 menghentikan pod dan menjadwalkan penggantian.

Terkadang pod mungkin belum siap untuk menerima lalu lintas, meskipun telah berhasil dimulai. Misalnya, mungkin ada tugas inisialisasi yang sedang berlangsung, seperti ketika aplikasi yang berjalan dalam kontainer memuat data ke dalam memori atau membaca file konfigurasi. Anda dapat menggunakan pemeriksaan startup untuk kontainer mulai lambat ini. Pendekatan ini membantu mencegah Kubernetes mengakhirinya sebelum mereka memiliki kesempatan untuk menginisialisasi sepenuhnya.

Pemeriksaan keaktifan digunakan untuk memeriksa apakah pod berjalan tetapi tidak berfungsi dengan baik dan perlu dimulai ulang. Misalnya, jika kontainer menangani permintaan HTTP tetapi tiba-tiba berhenti merespons tanpa crash, pemeriksaan liveness mendeteksi peristiwa ini dan memicu restart pod. Jika Anda menyiapkan pemeriksaan keaktifan, kontainer tidak merespons dan meminta Kubernetes untuk memulai ulang pod jika kontainer berulang kali gagal dalam pemeriksaan.

Pertimbangkan poin-poin berikut saat Anda merancang pemeriksaan untuk layanan mikro.

  • Jika kode Anda memiliki waktu mulai yang lama, ada bahaya bahwa pemeriksaan keaktifan melaporkan kegagalan sebelum startup selesai. Untuk menunda dimulainya pemeriksaan keaktifan, gunakan pemeriksaan startup, atau gunakan pengaturan initialDelaySeconds dengan pemeriksaan keaktifan.

  • Pemeriksaan keaktifan hanya membantu jika menghidupkan ulang pod kemungkinan akan memulihkannya ke keadaan sehat. Anda dapat menggunakan pemeriksaan keaktifan untuk mengurangi kebocoran memori atau kebuntuan tak terduga, tetapi tidak ada alasan untuk memulai ulang 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 sementara tidak tersedia. Ketidaktersebaran ini menyebabkan pemeriksaan kesiapan gagal untuk semua pod dalam layanan Anda, yang mengakibatkan penghapusannya dari penyeimbangan beban. Penghapusan ini membuat kegagalan bertingkat di hulu.

    Pendekatan yang lebih baik adalah menerapkan penanganan coba lagi dalam layanan Anda sehingga layanan Anda dapat pulih dengan benar dari kegagalan sementara. Sebagai alternatif, penanganan coba lagi, toleransi kesalahan, dan pemutus sirkuit dapat diimplementasikan oleh jala layanan istio untuk menciptakan arsitektur tangguh yang dapat menangani kegagalan layanan mikro.

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, seperti memori dan CPU. Untuk sumber daya non-kontainer, seperti utas atau koneksi jaringan, pertimbangkan untuk menggunakan pola Massal untuk mengisolasi sumber daya.

Gunakan kuota sumber daya untuk membatasi total sumber daya yang diizinkan untuk namespace. Batasan ini memastikan bahwa ujung depan tidak dapat kelaparan layanan back-end untuk sumber daya atau sebaliknya. Kuota sumber daya dapat membantu mengalokasikan sumber daya dalam kluster yang sama ke beberapa tim pengembangan layanan mikro.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Keamanan.

Enkripsi TLS dan SSL

Dalam banyak implementasi, pengontrol ingress digunakan untuk penghentian SSL. Sebagai bagian dari penyebaran pengontrol ingress, Anda perlu membuat atau mengimpor sertifikat Keamanan Lapisan Transportasi (TLS). Hanya gunakan sertifikat yang ditandatangani sendiri untuk tujuan pengembangan dan pengujian. Untuk informasi selengkapnya, lihat Menyiapkan nama domain kustom dan sertifikat SSL dengan add-on perutean aplikasi.

Untuk beban kerja produksi, dapatkan sertifikat yang ditandatangani dari otoritas sertifikat tepercaya.

Anda mungkin juga perlu memutar sertifikat anda tergantung pada kebijakan organisasi. Anda dapat menggunakan Key Vault untuk memutar sertifikat yang digunakan layanan mikro. Untuk informasi selengkapnya, lihat Mengonfigurasi rotasi otomatis sertifikat di Key Vault.

RBAC

Ketika beberapa tim mengembangkan dan menyebarkan layanan mikro secara bersamaan, mekanisme RBAC AKS dapat memberikan kontrol terperinci dan pemfilteran tindakan pengguna. Anda dapat menggunakan Kubernetes RBAC atau Azure RBAC dengan MICROSOFT Entra ID untuk mengontrol akses ke sumber daya kluster. Untuk informasi selengkapnya, lihat opsi Akses dan identitas untuk AKS.

Autentikasi dan otorisasi

Layanan mikro dapat mengharuskan layanan atau pengguna yang menggunakan untuk mengautentikasi dan mengotorisasi akses ke layanan mikro dengan menggunakan sertifikat, kredensial, dan mekanisme RBAC. ID Microsoft Entra dapat digunakan untuk menerapkan token OAuth 2.0 untuk otorisasi. Jala layanan seperti Istio juga menyediakan mekanisme otorisasi dan autentikasi untuk layanan mikro, yang mencakup validasi token OAuth dan perutean berbasis token. Implementasi referensi tidak mencakup skenario autentikasi dan otorisasi layanan mikro.

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, gunakan identitas terkelola jika memungkinkan. Identitas terkelola seperti ID unik untuk aplikasi atau layanan yang disimpan di ID Microsoft Entra. Ini menggunakan identitas ini untuk mengautentikasi dengan layanan Azure. Aplikasi atau layanan memiliki perwakilan layanan yang dibuat untuknya di ID Microsoft Entra dan mengautentikasi dengan menggunakan token OAuth 2.0. Kode yang berjalan dalam proses dapat memperoleh token secara transparan. Pendekatan ini membantu memastikan bahwa Anda tidak perlu menyimpan kata sandi atau string koneksi apa pun. Untuk menggunakan identitas terkelola, Anda dapat menetapkan identitas Microsoft Entra ke masing-masing pod di AKS dengan menggunakan ID Beban Kerja Microsoft Entra.

Bahkan ketika Anda menggunakan identitas terkelola, Anda mungkin masih perlu menyimpan beberapa kredensial atau rahasia aplikasi lainnya. Penyimpanan ini diperlukan untuk layanan Azure yang tidak mendukung identitas terkelola, layanan non-Microsoft, atau kunci API. Anda dapat menggunakan opsi berikut untuk membantu menyimpan rahasia dengan lebih aman:

Menggunakan solusi seperti Key Vault memberikan beberapa keuntungan, termasuk:

  • Kontrol rahasia terpusat.
  • Membantu memastikan bahwa semua rahasia dienkripsi saat tidak aktif.
  • Manajemen kunci terpusat.
  • Akses kontrol rahasia.
  • Manajemen siklus hidup utama.
  • Audit.

Implementasi referensi menyimpan string koneksi Azure Cosmos DB dan rahasia lainnya di Key Vault. Implementasi referensi menggunakan identitas terkelola untuk layanan mikro untuk mengautentikasi ke Key Vault dan mengakses rahasia.

Keamanan kontainer dan orkestrator

Praktik yang direkomendasikan berikut dapat membantu mengamankan pod dan kontainer Anda.

  • Pantau ancaman. Pantau ancaman dengan menggunakan Pertahanan Microsoft untuk Kontainer atau kemampuan non-Microsoft. Jika Anda menghosting kontainer pada komputer virtual (VM), gunakan Pertahanan Microsoft untuk Server atau kemampuan non-Microsoft. Selain itu, Anda dapat mengintegrasikan log dari solusi pemantauan kontainer di Azure Monitor untuk Microsoft Azure Sentinel atau solusi manajemen peristiwa dan informasi keamanan (SIEM) yang ada.

  • Memantau kerentanan. Terus memantau gambar dan menjalankan kontainer untuk kerentanan yang diketahui dengan menggunakan Microsoft Defender for Cloud atau solusi non-Microsoft.

  • Mengotomatiskan patching gambar. Gunakan tugas Azure Container Registry, fitur Container Registry, untuk mengotomatiskan patching gambar. 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 hulu dari pengembang aplikasi, dan pemeliharaan proyek lainnya mempertahankannya. Ketika gambar-gambar ini di-patch upstream, penting untuk memperbarui, menguji, dan menyebarkan ulang gambar Anda sendiri sehingga Anda tidak meninggalkan kerentanan keamanan yang diketahui. Tugas Azure Container Registry dapat membantu mengotomatiskan proses ini.

  • Simpan gambar dalam registri privat tepercaya. Gunakan registri privat tepercaya seperti Container Registry atau Docker Trusted Registry untuk menyimpan gambar. Gunakan webhook penerimaan yang memvalidasi di Kubernetes untuk membantu memastikan bahwa pod hanya dapat mengambil gambar dari registri tepercaya.

  • Menerapkan prinsip hak istimewa minimum. 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 menyediakan isolasi lengkap dari sudut sikap keamanan, jadi lebih baik menjalankan proses kontainer sebagai pengguna yang tidak memiliki hak istimewa.

Pertimbangan CI/CD penyebaran

Pertimbangkan tujuan berikut 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 versi baru layanan disebarkan ke produksi, layanan disebarkan ke lingkungan pengembangan, pengujian, dan Q&A 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.

Menggunakan jala layanan seperti Istio dapat membantu proses CI/CD, seperti penyebaran kenari, pengujian A/B layanan mikro, dan peluncuran bertahap dengan pemisahan lalu lintas berbasis persentase.

Untuk informasi selengkapnya tentang rekomendasi dan praktik terbaik tertentu, lihat Membangun alur CI/CD untuk layanan mikro di Kubernetes dengan Azure DevOps dan Helm.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat daftar periksa Design review untuk Pengoptimalan Biaya.

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

Pertimbangkan poin-poin berikut untuk beberapa layanan yang digunakan dalam arsitektur ini.

AKS

  • Dalam tingkat gratis, tidak ada biaya yang terkait untuk AKS dalam penyebaran, manajemen, dan operasi kluster Kubernetes. Anda hanya membayar instans VM, penyimpanan, dan sumber daya jaringan yang digunakan kluster Kubernetes Anda.

  • Pertimbangkan untuk menggunakan autoscaler pod horizontal untuk secara otomatis menskalakan layanan mikro masuk atau menskalakannya tergantung pada beban.

  • Konfigurasikan autoscaler kluster untuk menskalakan simpul atau meluaskannya tergantung pada beban.

  • Pertimbangkan untuk menggunakan simpul spot untuk menghosting layanan mikro noncritik.

  • Tinjau praktik terbaik pengoptimalan biaya untuk AKS.

  • Untuk memperkirakan biaya sumber daya yang diperlukan, gunakan kalkulator AKS .

Penyeimbang Beban Azure (Azure Load Balancer)

Anda hanya dikenakan biaya untuk jumlah aturan penyeimbangan beban dan keluar yang dikonfigurasi. Aturan terjemahan alamat jaringan 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 menyediakan alur sebagai layanan individual. Anda diizinkan melakukan pekerjaan gratis yang dihosting Microsoft dengan 1.800 menit untuk setiap bulan untuk CI/CD dan satu pekerjaan yang dihost sendiri dengan menit tak terbatas untuk setiap bulan. Pekerjaan tambahan dikenakan lebih banyak 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.

Keunggulan Operasional

Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untukKeunggulan Operasional.

Arsitektur referensi ini mencakup file Bicep untuk menyediakan sumber daya cloud dan dependensinya. Anda dapat menggunakan Azure Pipelines untuk menyebarkan file Bicep ini dan dengan cepat menyiapkan lingkungan yang berbeda, seperti mereplikasi skenario produksi. Pendekatan ini membantu Anda menghemat biaya dengan menyediakan lingkungan pengujian beban hanya jika diperlukan.

Pertimbangkan untuk mengikuti kriteria isolasi beban kerja untuk menyusun file Bicep Anda. Beban kerja biasanya didefinisikan sebagai unit fungsionalitas arbitrer. Misalnya, Anda dapat memiliki file Bicep terpisah untuk kluster dan kemudian file lain untuk layanan dependen. Anda dapat menggunakan Azure DevOps untuk melakukan CI/CD dengan isolasi beban kerja karena setiap beban kerja dikaitkan dan dikelola oleh timnya sendiri.

Menyebarkan skenario ini

Untuk menyebarkan penerapan referensi untuk arsitektur ini, ikuti langkah-langkah dalam repositori GitHub. Untuk informasi selengkapnya, lihat implementasi referensi layanan mikro AKS.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

Kontributor lain:

  • Paolo Salvatori | Insinyur Pelanggan Utama
  • Alessandro Vossa | Spesialis Teknis Senior

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya