Penyebaran biru-hijau kluster AKS

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Artikel ini memberikan panduan tentang menerapkan strategi penyebaran biru-hijau untuk menguji versi baru kluster Azure Kubernetes Service (AKS) sambil terus menjalankan versi saat ini. Setelah versi baru divalidasi, perubahan perutean mengalihkan lalu lintas pengguna ke dalamnya. Menyebarkan dengan cara ini meningkatkan ketersediaan saat membuat perubahan, termasuk peningkatan, ke kluster AKS. Artikel ini menjelaskan desain dan implementasi penyebaran AKS biru-hijau yang menggunakan layanan terkelola Azure dan fitur Kubernetes asli.

Sistem

Bagian ini menjelaskan arsitektur untuk penyebaran biru-hijau kluster AKS. Ada dua kasus:

Aplikasi dan API menghadap publik.
Aplikasi dan API menghadap ke privat.

Ada juga kasus hibrid, tidak dibahas di sini, di mana ada campuran aplikasi dan API yang menghadap publik dan privat di kluster.

Diagram berikut menunjukkan arsitektur untuk kasus yang menghadap publik:

Unduh file Visio arsitektur ini.

Azure Front Door dan Azure DNS menyediakan mekanisme perutean yang mengalihkan lalu lintas antara kluster biru dan hijau. Untuk informasi selengkapnya, lihat Penyebaran biru-hijau dengan Azure Front Door. Dengan menggunakan Azure Front Door, dimungkinkan untuk menerapkan sakelar penuh atau sakelar yang lebih terkontrol yang didasarkan pada bobot. Teknik ini adalah yang paling andal dan efisien di lingkungan Azure. Jika Anda ingin menggunakan DNS dan load balancer Anda sendiri, Anda perlu memastikan bahwa mereka dikonfigurasi untuk menyediakan sakelar yang aman dan andal.

Azure Application Gateway menyediakan ujung depan, yang didedikasikan untuk titik akhir publik.

Diagram ini untuk kasus yang menghadap privat:

Unduh file Visio arsitektur ini.

Untuk kasus ini, satu instans Azure DNS mengimplementasikan peralihan lalu lintas antara kluster biru dan hijau. Ini dilakukan dengan menggunakan A dan CNAME merekam. Untuk detailnya, lihat bagian T3: Mengalihkan lalu lintas ke kluster hijau.

Application Gateway menyediakan ujung depan, yang didedikasikan untuk titik akhir privat.

Alur kerja

Dalam penyebaran biru-hijau ada lima tahap untuk memperbarui versi kluster saat ini ke versi baru. Dalam deskripsi kami, kluster biru adalah versi saat ini, dan kluster hijau adalah yang baru.

Tahapannya adalah:

T0: Kluster biru aktif.
T1: Sebarkan kluster hijau.
T2: Sinkronkan status Kubernetes antara kluster biru dan hijau.
T3: Alihkan lalu lintas ke kluster hijau.
T4: Hancurkan kluster biru.

Setelah versi baru ditayangkan, itu menjadi kluster biru untuk perubahan atau pembaruan apa pun yang akan datang berikutnya.

Kluster biru dan hijau berjalan pada saat yang sama, tetapi hanya untuk jangka waktu terbatas, yang mengoptimalkan biaya dan upaya operasional.

Pemicu transisi

Pemicu untuk transisi dari tahap ke tahap dapat diotomatisasi. Sampai itu tercapai, beberapa atau semuanya manual. Pemicu terkait dengan:

Metrik beban kerja tertentu, tujuan tingkat layanan (SLA), dan perjanjian tingkat layanan (SLA): Ini digunakan terutama dalam tahap T3 untuk memvalidasi status keseluruhan kluster AKS sebelum mengalihkan lalu lintas.
Metrik platform Azure: Ini digunakan untuk mengevaluasi status dan kesehatan beban kerja dan kluster AKS. Mereka digunakan dalam semua transisi.

Penemuan jaringan kluster

Anda dapat memberikan penemuan jaringan untuk kluster dengan cara berikut:

Memiliki rekaman DNS yang menunjuk ke kluster. Contohnya:
- aks-blue.contoso.com menunjuk ke IP privat atau publik kluster biru.
- aks-green.contoso.com menunjuk ke IP privat atau publik kluster hijau.
Kemudian Anda dapat menggunakan nama host ini secara langsung atau di konfigurasi kumpulan backend gateway aplikasi yang ada di depan setiap kluster.
Memiliki catatan DNS yang menunjuk ke gateway aplikasi. Contohnya:
- aks-blue.contoso.com menunjuk ke IP privat atau publik gateway aplikasi, yang memiliki sebagai kumpulan backend IP privat atau publik kluster biru.
- aks-green.contoso.com menunjuk ke IP privat atau publik gateway aplikasi, yang memiliki sebagai kumpulan backend IP privat atau publik kluster hijau.

T0: Kluster biru aktif

Tahap awal, T0, adalah bahwa kluster biru ditayangkan. Tahap ini menyiapkan versi baru kluster untuk penyebaran.

Kondisi pemicu untuk tahap T1 adalah rilis versi baru kluster, kluster hijau.

T1: Menyebarkan kluster hijau

Tahap ini memulai penyebaran kluster hijau baru. Kluster biru tetap menyala, dan lalu lintas langsung masih dirutekan ke dalamnya.

Pemicu untuk pindah ke tahap T2 adalah validasi kluster AKS hijau di tingkat platform. Validasi menggunakan metrik Azure Monitor dan perintah CLI untuk memeriksa kesehatan penyebaran. Untuk informasi selengkapnya, lihat Memantau Azure Kubernetes Service (AKS) dengan referensi data AKS Monitor dan Monitoring.

Pemantauan AKS dapat dibagi menjadi tingkat yang berbeda, seperti yang ditunjukkan dalam diagram berikut:

Kesehatan kluster dievaluasi pada tingkat 1 dan 2, dan pada beberapa tingkat 3. Untuk tingkat 1, Anda dapat menggunakan tampilan multi-kluster asli dari Monitor untuk memvalidasi kesehatan, seperti yang ditunjukkan di sini:

Pada tingkat 2, pastikan bahwa server API Kubernetes dan Kubelet berfungsi dengan baik. Anda bisa menggunakan buku kerja Kubelet di Monitor, khususnya, dua kisi buku kerja yang memperlihatkan statistik operasi utama simpul:

Gambaran umum oleh kisi simpul meringkas total operasi, total kesalahan, dan operasi yang berhasil berdasarkan persen dan tren untuk setiap simpul.
Gambaran umum menurut kisi jenis operasi menyediakan, untuk setiap jenis operasi, jumlah operasi, kesalahan, dan operasi yang berhasil berdasarkan persen dan tren.

Level 3 didedikasikan untuk objek dan aplikasi Kubernetes yang disebarkan secara default di AKS, seperti omsagent, kube-proxy dan sebagainya. Untuk pemeriksaan ini, Anda dapat menggunakan tampilan Insight Monitor untuk memeriksa status penyebaran AKS:

Sebagai alternatif, Anda dapat menggunakan buku kerja khusus yang didokumentasikan dalam Metrik Penyebaran & HPA dengan wawasan Kontainer. Berikut contohnya:

Setelah validasi berhasil, Anda dapat beralih ke tahap T2.

T2: Sinkronkan status Kubernetes antara kluster biru dan hijau

Pada tahap ini, aplikasi, operator, dan sumber daya Kubernetes belum disebarkan di kluster hijau, atau setidaknya tidak semuanya berlaku dan disebarkan ketika kluster AKS disediakan. Tujuan utama dari tahap ini adalah bahwa, pada akhir sinkronisasi, kluster hijau kompatibel mundur dengan yang biru. Jika demikian, dimungkinkan untuk memvalidasi status kluster baru sebelum mengalihkan lalu lintas ke kluster hijau.

Ada berbagai cara untuk menyinkronkan status Kubernetes antar kluster:

Penyebaran ulang melalui integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD). Biasanya cukup untuk menggunakan alur CI/CD yang sama yang digunakan untuk penyebaran normal aplikasi. Alat umum untuk melakukan ini adalah: GitHub Actions, Azure DevOps, dan Jenkins.
GitOps, dengan solusi yang dipromosikan di situs web Cloud Native Computing Foundation (CNCF), seperti Flux dan ArgoCD.
Solusi yang disesuaikan yang menyimpan konfigurasi dan sumber daya Kubernetes di datastore. Biasanya, solusi ini didasarkan pada generator manifes Kubernetes yang dimulai dari definisi metadata dan kemudian menyimpan manifes Kubernetes yang dihasilkan ke dalam datastore seperti Azure Cosmos DB. Ini biasanya merupakan solusi kustom yang didasarkan pada kerangka kerja deskripsi aplikasi yang digunakan.

Diagram berikut menunjukkan proses sinkronisasi status Kubernetes:

Biasanya, selama sinkronisasi, penyebaran versi baru aplikasi tidak diizinkan di kluster langsung. Periode waktu ini dimulai dengan sinkronisasi dan selesai ketika pengalihan ke kluster hijau selesai. Cara menonaktifkan penyebaran di Kubernetes dapat bervariasi. Dua solusi yang mungkin adalah:

Nonaktifkan alur penyebaran.
Nonaktifkan akun layanan Kubernetes yang menjalankan penyebaran.

Dimungkinkan untuk mengotomatiskan penonaktifan akun layanan dengan menggunakan Agen Kebijakan Terbuka (OPA). Belum dimungkinkan untuk menggunakan fitur asli AKS untuk ini karena masih dalam pratinjau.

Periode sinkronisasi dapat dihindari dengan menggunakan mekanisme tingkat lanjut yang mengelola status Kubernetes di beberapa kluster.

Ketika sinkronisasi selesai, validasi kluster dan aplikasi diperlukan. Drive ini termasuk:

Pemeriksaan platform pemantauan dan pengelogan untuk memvalidasi kesehatan kluster. Anda dapat mempertimbangkan untuk melakukan apa yang Anda lakukan di tahap T1: Menyebarkan kluster hijau.
Pengujian fungsional aplikasi berdasarkan toolchain yang saat ini digunakan.

Sebaiknya Anda juga menjalankan sesi uji beban untuk membandingkan performa aplikasi kluster hijau dengan garis besar performa. Anda dapat menggunakan alat pilihan Anda atau Azure Load Testing.

Biasanya, kluster hijau diekspos pada gateway aplikasi atau load balancer eksternal dengan URL internal yang tidak terlihat oleh pengguna eksternal.

Ketika kluster baru divalidasi, Anda dapat melanjutkan ke tahap berikutnya untuk mengalihkan lalu lintas ke kluster baru.

T3: Alihkan lalu lintas ke kluster hijau

Setelah sinkronisasi selesai dan kluster hijau divalidasi pada tingkat platform dan aplikasi, siap untuk dipromosikan menjadi kluster utama dan untuk mulai menerima lalu lintas langsung. Sakelar dilakukan pada tingkat jaringan. Seringkali beban kerja tidak memiliki status. Namun, jika beban kerja bersifat stateful, solusi tambahan harus diterapkan untuk mempertahankan status dan penembolokan selama pengalihan.

Berikut adalah diagram yang memperlihatkan status target setelah sakelar diterapkan:

Teknik yang dijelaskan dalam artikel ini menerapkan sakelar penuh: 100% lalu lintas dirutekan ke kluster baru. Ini karena perutean diterapkan pada tingkat DNS dengan A penetapan catatan atau CNAME yang diperbarui untuk menunjuk ke kluster hijau, dan ada gateway aplikasi untuk setiap kluster.

Berikut adalah contoh konfigurasi untuk beralih titik akhir yang menghadap privat. Solusi yang diusulkan menggunakan A rekaman untuk beralih. Dari perspektif pemetaan DNS dan IP, situasinya adalah sebagai berikut sebelum pengalihan:

A catatan aks.priv.contoso.com menunjuk ke IP privat gateway aplikasi biru.
A catatan aks-blue.priv.contoso.com menunjuk ke IP privat gateway aplikasi biru.
A catatan aks-green.priv.contoso.com menunjuk ke IP privat gateway aplikasi hijau.

Sakelar mengonfigurasi ulang ke hal berikut:

A catatan aks.priv.contoso.com menunjuk ke IP privat gateway aplikasi hijau.
A catatan aks-blue.priv.contoso.com menunjuk ke IP privat gateway aplikasi biru.
A catatan aks-green.priv.contoso.com menunjuk ke IP privat gateway aplikasi hijau.

Pengguna kluster akan melihat sakelar setelah time to live (TTL) dan penyebaran DNS rekaman.

Untuk titik akhir yang menghadap publik, pendekatan yang direkomendasikan menggunakan Azure Front Door dan Azure DNS. Berikut adalah konfigurasi sebelum pengalihan:

CNAME catatan official-aks.contoso.com menunjuk ke catatan domain Azure Front Door yang dibuat secara otomatis. Untuk informasi selengkapnya, lihat Tutorial: Menambahkan domain kustom ke Front Door Anda.
A rekaman aks.contoso.com menunjuk ke IP publik gateway aplikasi biru.
Konfigurasi asal Azure Front Door menunjuk ke aks.contoso.com nama host. Untuk informasi selengkapnya tentang mengonfigurasi kumpulan backend, lihat Asal dan grup asal di Azure Front Door.
- A rekaman aks-blue.contoso.com menunjuk ke IP publik gateway aplikasi biru.
- A catatan aks-green.contoso.com menunjuk ke IP publik gateway aplikasi hijau.

Sakelar mengonfigurasi ulang ke hal berikut:

CNAME catatan official-aks.contoso.com menunjuk ke catatan domain Azure Front Door yang dibuat secara otomatis.
A catatan aks.contoso.com menunjuk ke IP publik gateway aplikasi hijau.
Konfigurasi asal Azure Front Door menunjuk ke aks.contoso.com nama host.
- A rekaman aks-blue.contoso.com menunjuk ke IP publik gateway aplikasi biru.
- A catatan aks-green.contoso.com menunjuk ke IP publik gateway aplikasi hijau.

Teknik pengalihan alternatif, seperti sakelar parsial untuk rilis kenari, dimungkinkan dengan layanan Azure tambahan seperti Azure Front Door atau Traffic Manager. Untuk implementasi sakelar lalu lintas biru-hijau di tingkat Azure Front Door, lihat Penyebaran biru-hijau dengan Azure Front Door.

Seperti yang dijelaskan dalam contoh, dari perspektif jaringan teknik ini didasarkan pada definisi empat nama host:

Nama host resmi yang menghadap publik: Nama host publik resmi yang digunakan oleh pengguna akhir dan konsumen.
Nama host kluster: Nama host resmi yang digunakan oleh konsumen beban kerja yang dihosting di kluster.
Nama host kluster biru: Nama host khusus untuk kluster biru.
Nama host kluster hijau: Nama host khusus untuk kluster hijau.

Nama host kluster adalah nama yang dikonfigurasi di tingkat gateway aplikasi untuk mengelola lalu lintas masuk. Nama host juga merupakan bagian dari konfigurasi ingress AKS untuk mengelola Keamanan Lapisan Transportasi (TLS) dengan benar. Host ini hanya digunakan untuk transaksi langsung dan permintaan.

Jika Azure Front Door juga merupakan bagian dari penyebaran, azure Front Door tidak terpengaruh oleh sakelar, karena hanya mengelola nama host kluster resmi. Ini memberikan abstraksi yang tepat untuk pengguna aplikasi. Mereka tidak terpengaruh oleh pengalihan, karena catatan DNS CNAME selalu menunjuk ke Azure Front Door.

Nama host kluster biru dan hijau terutama digunakan untuk menguji dan memvalidasi kluster. Untuk tujuan ini, nama host diekspos di tingkat gateway aplikasi dengan titik akhir khusus, dan juga di tingkat pengontrol ingress AKS untuk mengelola TLS dengan benar.

Pada tahap ini, validasi didasarkan pada metrik pemantauan infrastruktur dan aplikasi, dan pada SLO dan SLA resmi, jika tersedia. Jika validasi berhasil, transisi ke tahap akhir untuk menghancurkan kluster biru.

T4: Hancurkan kluster biru

Mengalihkan lalu lintas berhasil membawa kita ke tahap akhir, di mana masih ada validasi dan pemantauan yang terjadi untuk memastikan bahwa kluster hijau berfungsi seperti yang diharapkan dengan lalu lintas langsung. Validasi dan pemantauan mencakup tingkat platform dan aplikasi.

Setelah validasi ini selesai, kluster biru dapat dihancurkan. Penghancuran adalah langkah yang sangat disarankan untuk mengurangi biaya dan memanfaatkan elastisitas yang disediakan Azure dengan benar, terutama AKS.

Berikut adalah situasi setelah kluster biru dihancurkan:

Komponen

Application Gateway adalah load balancer lalu lintas web (OSI layer 7) yang memungkinkan Anda mengelola lalu lintas ke aplikasi web Anda. Dalam solusi ini digunakan sebagai gateway untuk lalu lintas HTTP untuk mengakses kluster AKS.
Azure Kubernetes Service (AKS) adalah layanan Kubernetes terkelola yang dapat Anda gunakan untuk menyebarkan dan mengelola aplikasi dalam kontainer. Platform aplikasi ini adalah komponen utama dari pola ini.
Azure Container Registry adalah layanan terkelola yang digunakan untuk menyimpan dan mengelola gambar kontainer dan artefak terkait. Dalam solusi ini digunakan untuk menyimpan dan mendistribusikan gambar dan artefak kontainer, seperti bagan Helm, di kluster AKS.
Azure Monitor adalah solusi pemantauan untuk mengumpulkan, menganalisis, dan merespons data pemantauan dari lingkungan cloud dan lokal Anda. Ini menyediakan fitur pemantauan inti yang diperlukan untuk menjalankan penyebaran hijau biru. Ini digunakan dalam arsitektur ini karena integrasinya dengan AKS dan kemampuannya untuk menyediakan kemampuan pengelogan, pemantauan, dan pemberitahuan yang dapat digunakan untuk mengelola transisi tahap.
Azure Key Vault membantu menyelesaikan masalah berikut:Manajemen Rahasia, Manajemen Kunci, dan Manajemen Sertifikat; digunakan untuk menyimpan dan mengelola rahasia dan sertifikat yang diperlukan di platfomr dan tingkat aplikasi untuk solusi ini.
Azure Front Door adalah penyeimbang beban global dan sistem manajemen titik akhir aplikasi. Ini digunakan dalam solusi ini sebagai titik akhir publik untuk aplikasi HTTP yang dihosting di AKS. Dalam solusi ini, ia memiliki tanggung jawab penting untuk mengelola peralihan lalu lintas antara gateway aplikasi biru dan hijau.
Azure DNS merupakan layanan hosting untuk domain DNS yang menyediakan resolusi nama menggunakan infrastruktur Microsoft Azure. Ini mengelola nama host yang digunakan dalam solusi untuk kluster biru dan hijau, dan memainkan peran penting dalam pengalihan lalu lintas, terutama untuk titik akhir privat.

Alternatif

Ada teknik alternatif untuk menerapkan sakelar lalu lintas yang dapat memberikan lebih banyak kontrol. Misalnya, dimungkinkan untuk melakukan pengalihan parsial dengan menggunakan aturan lalu lintas yang didasarkan pada satu atau beberapa hal berikut:
- Persentase lalu lintas masuk
- Header HTTP
- Cookie
Alternatif lain yang memberikan perlindungan yang lebih besar dari masalah yang disebabkan oleh perubahan adalah memiliki penyebaran berbasis cincin. Alih-alih hanya kluster biru dan hijau, dimungkinkan untuk memiliki lebih banyak kluster, yang disebut cincin. Setiap cincin cukup besar untuk jumlah pengguna yang memiliki akses ke versi baru AKS. Adapun penyebaran biru-hijau yang dijelaskan di sini, cincin dapat dihapus untuk memiliki pengoptimalan dan kontrol biaya yang tepat.
Alternatif yang mungkin untuk Application Gateway adalah NGINX dan HAProxy.
Alternatif yang mungkin untuk Container Registry adalah Harbor.
Dalam beberapa keadaan, Anda dapat menggunakan layanan penyeimbang beban dan DNS yang berbeda untuk melakukan pengalihan lalu lintas, bukan Azure Front Door dan Azure DNS.
Solusi ini didasarkan pada API Kubernetes pengontrol ingress standar. Jika solusi Anda akan mendapat manfaat sebagai gantinya dari API Gateway, gunakan Application Gateway untuk Kontainer. Ini dapat membantu mengelola penyeimbangan beban dan menangani manajemen lalu lintas ingress antara Application Gateway dan pod. Application Gateway untuk Kontainer mengontrol pengaturan gateway aplikasi.

Detail skenario

Manfaat utama dari solusi ini adalah:

Meminimalkan waktu henti selama penyebaran.
Strategi putar kembali yang direncanakan.
Peningkatan kontrol dan operasi selama rilis dan penyebaran perubahan dan peningkatan AKS.
Pengujian untuk kebutuhan untuk menjalankan prosedur pemulihan bencana (DR).

Prinsip-prinsip utama dan aspek dasar penyebaran biru-hijau dibahas dalam artikel ini:

Dari perspektif otomatisasi dan CI/CD, solusinya dapat diimplementasikan dengan berbagai cara. Saran kami:

Bicep atau Terraform untuk IaC.
Azure Pipelines atau GitHub Actions untuk CI/CD.

Kemungkinan kasus penggunaan

Penyebaran biru-hijau memungkinkan untuk membuat perubahan pada kluster tanpa memengaruhi aplikasi dan beban kerja yang sedang berjalan. Contoh perubahannya adalah:

Perubahan operasional
Mengaktifkan fitur AKS baru
Perubahan pada sumber daya bersama dalam kluster
Memperbarui versi Kubernetes
Memodifikasi sumber daya dan objek Kubernetes, seperti gateway ingress, jala layanan, operator, kebijakan jaringan, dan sebagainya
Menggulung balik ke versi kluster AKS sebelumnya yang masih disebarkan, tanpa memengaruhi beban kerja yang berjalan di kluster

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.

Penyebaran biru-hijau dapat sepenuhnya otomatis, seperti penyebaran zero-touch. Biasanya, implementasi awal memiliki pemicu manual untuk mengaktifkan tahapan. Sepanjang jalan dan dengan fitur kematangan dan pemantauan yang tepat, dimungkinkan untuk mengotomatiskan pemicu. Ini berarti bahwa ada pengujian otomatis dan metrik tertentu, SLA, dan SLO untuk mengotomatiskan pemicu.
Penting untuk memiliki nama host khusus untuk kluster biru dan hijau dan juga memiliki konfigurasi titik akhir khusus pada gateway dan load balancer yang ada di depan kluster. Ini sangat penting untuk meningkatkan keandalan dan validitas penyebaran kluster baru. Dengan cara ini, validasi penyebaran terjadi dengan arsitektur dan konfigurasi yang sama dari kluster produksi standar.
Pertimbangkan situasi di mana kluster AKS adalah sumber daya bersama untuk beberapa aplikasi yang dikelola oleh unit bisnis yang berbeda. Dalam kasus seperti itu, adalah umum bahwa platform AKS itu sendiri dikelola oleh tim khusus yang bertanggung jawab atas operasi keseluruhan dan siklus hidup kluster, dan bahwa ada titik akhir dalam kluster untuk tujuan admin dan ops. Kami menyarankan agar titik akhir ini memiliki pengontrol ingress khusus di kluster AKS untuk pemisahan kekhawatiran yang tepat dan untuk keandalan.
Penyebaran biru-hijau berguna untuk menerapkan dan menguji solusi kelangsungan bisnis dan pemulihan bencana (BC/DR) untuk AKS dan beban kerja terkait. Secara khusus, ini menyediakan struktur mendasar untuk mengelola beberapa kluster, termasuk kasus di mana kluster tersebar di antara beberapa wilayah.
Keberhasilan dengan penyebaran biru-hijau bergantung pada penerapan semua aspek implementasi, seperti otomatisasi, pemantauan, dan validasi, tidak hanya ke platform AKS, tetapi juga untuk beban kerja dan aplikasi yang disebarkan di platform. Melakukan ini membantu Anda mendapatkan manfaat maksimum dari penyebaran biru-hijau.
Dalam solusi yang diusulkan ada dua Application Gateway per setiap skenario publik dan privat, jadi totalnya empat. Keputusan ini adalah menerapkan penyebaran hijau biru di tingkat Azure Application Gateway untuk menghindari waktu henti yang disebabkan oleh kesalahan konfigurasi gateway. Kelemahan utama dari keputusan ini adalah biaya, karena ada empat instans Application Gateway. Mereka berjalan secara paralel hanya dalam periode waktu di mana ada perubahan yang relevan pada konfigurasi Application Gateway, seperti kebijakan WAF atau konfigurasi penskalaan. Untuk pengoptimalan biaya lebih lanjut, Anda dapat memilih satu Application Gateway per setiap skenario, ini berarti dua Application Gateway secara total. Ini akan mengharuskan Anda untuk memindahkan logika biru/hijau ke gateway aplikasi, bukan Azure Front Door. Jadi alih-alih Azure Front Door dikontrol secara imperatif, Application Gateway adalah.

Keandalan

Keandalan memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.

Penyebaran biru-hijau memiliki efek langsung dan positif pada ketersediaan platform AKS dan beban kerja. Secara khusus, ini meningkatkan ketersediaan selama penyebaran perubahan platform AKS. Ada sedikit waktu henti jika sesi pengguna dikelola dengan baik.
Penyebaran biru-hijau memberikan cakupan untuk keandalan selama penyebaran karena, secara default, ada opsi untuk mengembalikan ke versi kluster AKS sebelumnya jika ada yang salah dalam versi kluster baru.

Pengoptimalan biaya

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

Penyebaran biru-hijau diadopsi secara luas di Azure karena elastisitas asli yang disediakan oleh cloud. Hal ini memungkinkan untuk mengoptimalkan biaya dalam hal operasi dan konsumsi sumber daya. Sebagian besar hasil penghematan dari menghapus kluster yang tidak lagi diperlukan setelah berhasil menyebarkan versi baru kluster.
Ketika versi baru disebarkan, biasanya untuk menghosting kluster biru dan hijau di subnet yang sama, untuk terus memiliki garis besar biaya yang sama. Semua koneksi dan akses jaringan ke sumber daya dan layanan sama untuk dua kluster, dan semua layanan dan sumber daya Azure tetap sama.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.

Penyebaran biru-hijau, diimplementasikan dengan benar, menyediakan otomatisasi, pengiriman berkelanjutan, dan penyebaran tangguh.
Salah satu aspek utama pengiriman berkelanjutan adalah secara berulang memberikan kenaikan platform dan perubahan beban kerja. Dengan penyebaran AKS biru-hijau, Anda mencapai pengiriman berkelanjutan di tingkat platform, dengan cara yang terkontrol dan aman.
Ketahanan sangat mendasar untuk penyebaran biru-hijau, karena mencakup opsi untuk kembali ke kluster sebelumnya.
Penyebaran biru-hijau menyediakan tingkat otomatisasi yang tepat untuk mengurangi upaya yang terkait dengan strategi kelangsungan bisnis.
Memantau platform dan aplikasi sangat penting untuk implementasi yang sukses. Untuk platform, Anda dapat menggunakan kemampuan pemantauan Azure asli. Untuk aplikasi, pemantauan perlu dirancang dan diimplementasikan.

Menyebarkan skenario ini

Untuk contoh penerapan biru-hijau yang diimplementasikan yang dijelaskan dalam panduan ini, lihat AKS Landing Zone Accelerator.

Implementasi referensi ini didasarkan pada Application Gateway dan Application Gateway Ingress Controller (AGIC). Setiap kluster memiliki gateway aplikasinya sendiri dan pengalihan lalu lintas dilakukan melalui DNS, khususnya melalui CNAME konfigurasi.

Penting

Untuk beban kerja misi penting, penting untuk menggabungkan penyebaran biru/hijau seperti yang diuraikan dalam panduan ini dengan otomatisasi penyebaran dan validasi berkelanjutan untuk mencapai penyebaran waktu henti nol. Informasi dan panduan lebih lanjut tersedia dalam metodologi desain misi-kritis.

Pertimbangan wilayah

Anda dapat menyebarkan kluster biru dan hijau untuk memisahkan wilayah atau ke wilayah yang sama. Prinsip desain dan operasional tidak terpengaruh oleh pilihan ini. Namun, jenis konfigurasi jaringan tambahan tertentu dapat terpengaruh, seperti:

Jaringan virtual dan subnet khusus untuk AKS dan gateway aplikasi.
Koneksi dengan layanan dukungan seperti Monitor, Container Registry, dan Key Vault.
Visibilitas Azure Front Door dari gateway aplikasi.

Ada prasyarat untuk menyebarkan ke wilayah yang sama:

Jaringan virtual dan subnet harus berukuran untuk menghosting dua kluster.
Langganan Azure harus menyediakan kapasitas yang memadai untuk dua kluster.

Penyebaran pengontrol ingress dan load balancer eksternal

Ada berbagai pendekatan untuk penyebaran pengontrol ingress dan load balancer eksternal:

Anda dapat memiliki pengontrol ingress tunggal dengan load balancer eksternal khusus, seperti implementasi referensi arsitektur yang dijelaskan dalam panduan ini. AGIC adalah aplikasi Kubernetes yang memungkinkan penggunaan load balancer Application Gateway L7 untuk mengekspos perangkat lunak cloud ke internet. Dalam skenario tertentu, ada titik akhir admin di kluster AKS selain titik akhir aplikasi. Titik akhir admin adalah untuk melakukan tugas operasional pada aplikasi atau untuk tugas konfigurasi seperti memperbarui peta konfigurasi, rahasia, kebijakan jaringan, dan manifes.
Anda dapat memiliki satu penyeimbang beban eksternal yang melayani beberapa pengontrol ingress yang disebarkan pada kluster yang sama atau pada beberapa kluster. Pendekatan ini tidak tercakup dalam implementasi referensi. Dalam skenario ini, kami sarankan Anda memiliki gateway aplikasi terpisah untuk titik akhir yang menghadap publik dan untuk yang privat.
Arsitektur yang dihasilkan yang diusulkan dan digambarkan dalam panduan ini didasarkan pada pengontrol ingress standar yang disebarkan sebagai bagian dari kluster AKS, seperti yang berbasis NGINX dan Envoy . Dalam implementasi referensi, kami menggunakan AGIC, yang berarti bahwa ada koneksi langsung antara gateway aplikasi dan pod AKS, tetapi ini tidak memengaruhi arsitektur biru-hijau secara keseluruhan.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Vincenzo Morra | Arsitek Inkubasi SAO

Kontributor lain:

Oscar Pla Alvarez | Arsitek Solusi Domain

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Bagikan melalui

Penyebaran biru-hijau kluster AKS