AKS kümelerinin mavi-yeşil yayılımı

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Bu makale, geçerli sürümü çalıştırmaya devam ederken Azure Kubernetes Service (AKS) kümesinin yeni bir sürümünü test etmek için mavi-yeşil dağıtım stratejisi uygulama konusunda rehberlik sağlar. Yeni sürüm doğrulandıktan sonra, yönlendirme değişikliği kullanıcı trafiğini buna değiştirir. Bu şekilde dağıtmak, AKS kümelerine yükseltmeler de dahil olmak üzere değişiklik yaparken kullanılabilirliği artırır. Bu makalede, Azure yönetilen hizmetlerini ve yerel Kubernetes özelliklerini kullanan mavi-yeşil AKS dağıtımının tasarımı ve uygulaması açıklanmaktadır.

Mimarlık

Bu bölümde AKS kümelerinin mavi-yeşil dağıtımına yönelik mimariler açıklanmaktadır. İki durum vardır:

Uygulamalar ve API'ler genel kullanıma açıktır.
Uygulamalar ve API'ler özel kullanıma yöneliklerdir.

Ayrıca, kümedeki genel kullanıma yönelik ve özel kullanıma yönelik uygulamaların ve API'lerin bir karışımının yer aldığı, burada tartışılmayan karma bir durum da vardır.

Aşağıdaki diyagram, kamuya açık senaryonun mimarisini göstermektedir:

Bu mimarinin bir Visio dosyasını indirin.

Azure Front Door ve Azure DNS, mavi ve yeşil kümeler arasında trafiğin geçişini sağlayan yönlendirme mekanizmasını sağlar. Daha fazla bilgi için bkz. Azure Front Door ile mavi-yeşil dağıtım. Azure Front Door kullanılarak tam bir geçiş veya ağırlıklara dayalı daha kontrollü bir geçiş gerçekleştirilebilir. Bu teknik, Azure ortamındaki en güvenilir ve verimli tekniktir. Kendi Etki Alanı Adı Sisteminizi (DNS) ve yük dengeleyicinizi kullanmak istiyorsanız, bunların güvenli ve güvenilir bir anahtar sağlayacak şekilde yapılandırıldığından emin olmanız gerekir.

Azure Application Gateway, genel uç noktalara ayrılmış ön uçlar sağlar.

Bu diyagram, özel kullanıma yönelik durum içindir:

Bu mimarinin bir Visio dosyasını indirin.

Bu durumda, tek bir Azure DNS örneği mavi ve yeşil kümeler arasındaki trafiğin değiştirilmesini uygular. Bu, A ve CNAME kayıtları kullanılarak yapılır. Daha fazla bilgi için T3: Trafiği yeşil kümeye değiştirme bölümüne bakın.

Application Gateway, özel uç noktalara ayrılmış ön uçlar sağlar.

İş Akışı

Mavi-yeşil dağıtımda, kümenin geçerli sürümünü yeni sürüme güncelleştirmenin beş aşaması vardır. Açıklamamızda mavi küme geçerli sürüm, yeşil küme ise yeni sürümdür.

Aşamalar şunlardır:

T0: Mavi küme açık.
T1: Yeşil kümeyi dağıtın.
T2: Kubernetes durumunu mavi ve yeşil kümeler arasında eşitleyin.
T3: Trafiği yeşil kümeye geçirin.
T4: Mavi kümeyi yok edin.

Yeni sürüm yayımlandıktan sonra, bir sonraki değişiklik veya güncelleştirme için mavi küme haline gelir.

Mavi ve yeşil kümeler aynı anda çalışır, ancak yalnızca sınırlı bir süre için çalışır ve bu da maliyetleri ve operasyonel çabaları iyileştirir.

Geçiş tetikleyicileri

Aşamadan aşamaya geçiş tetikleyicileri otomatikleştirilebilir. Bu başarılana kadar, bunların bazıları veya tümü el ile gerçekleştirilir. Tetikleyiciler şunlarla ilgilidir:

Belirli iş yükü ölçümleri, hizmet düzeyi hedefleri (SLO' lar) ve hizmet düzeyi sözleşmeleri (SLA' lar): Bunlar, trafiği değiştirmeden önce AKS kümesinin genel durumunu doğrulamak için çoğunlukla T3 aşamasında kullanılır.
Azure platformu ölçümleri: Bunlar, iş yüklerinin ve AKS kümesinin durumunu ve durumunu değerlendirmek için kullanılır. Tüm geçişlerde kullanılırlar.

Kümelerin ağ bulunabilirliği

Kümeler için aşağıdaki yollarla ağ bulunabilirliği sağlayabilirsiniz:

Kümelere işaret eden DNS kayıtlarına sahip olun. Örneğin:
- aks-blue.contoso.com mavi kümenin özel veya genel IP'sini gösterir.
- aks-green.contoso.com yeşil kümenin özel veya genel IP'sini gösterir.
Ardından bu konak adlarını doğrudan veya her kümenin önündeki uygulama ağ geçidinin arka uç havuzu yapılandırmasında kullanabilirsiniz.
Uygulama ağ geçitlerine işaret eden DNS kayıtlarının olması. Örneğin:
- aks-blue.contoso.com , mavi kümenin özel veya genel IP'sine arka uç havuzu olarak sahip olan uygulama ağ geçidinin özel veya genel IP'sini gösterir.
- aks-green.contoso.com, arka uç havuzunda yeşil kümenin özel veya genel IP'si bulunan uygulama ağ geçidinin özel veya genel IP'sini işaret eder.

T0: Mavi küme açık

İlk aşama olan T0, mavi kümenin canlı olmasıdır. Bu aşama, kümenin yeni sürümünü dağıtım için hazırlar.

T1 aşaması için tetikleme koşulu, kümenin, yani yeşil kümenin yeni bir sürümünün yayınlanmasıdır.

T1: Yeşil kümeyi dağıtma

Bu aşama, yeni yeşil kümenin dağıtımına başlar. Mavi küme açık kalır ve canlı trafik yine de bu kümeye yönlendirilir.

T2 aşamasına geçme tetikleyicisi, yeşil AKS kümesinin platform düzeyinde doğrulanmasıdır. Doğrulama, dağıtımın durumunu denetlemek için Azure İzleyici ölçümlerini ve CLI komutlarını kullanır. Daha fazla bilgi için Azure İzleyici ile Azure Kubernetes Service'i (AKS) izleme ve AKS izleme veri başvurusu başlıklarına bakın.

AKS izleme, aşağıdaki diyagramda gösterildiği gibi farklı düzeylere ayrılabilir:

AKS izleme düzeylerinin diyagramı.

Kümenin durumu, 1. ve 2. düzeylerde ve 3. düzeyin bazı bölümlerinde değerlendirilir. Düzey 1 için, burada gösterildiği gibi sistem durumunu doğrulamak için İzleyici'den yerel çok kümeli görünümü kullanabilirsiniz:

İzleme kümelerinin ekran görüntüsü.

2. düzeyde Kubernetes API sunucusunun ve Kubelet'in düzgün çalıştığından emin olun. Monitor'de, özellikle düğümlerin temel işletim istatistiklerini gösteren çalışma kitabındaki iki ızgarada, Kubelet çalışma kitabını kullanabilirsiniz:

Düğüm kılavuzuna göre genel bakış, her düğüm için toplam işlemi, toplam hataları ve başarılı işlemleri yüzde ve eğilime göre özetler.
İşlem türü kılavuzuna göre genel bakış, her işlem türü için yüzde ve eğilime göre işlem sayısını, hataları ve başarılı işlemleri sağlar.

Düzey 3, GIBI AKS'de ama-logsküme düzeyinde dağıtılan Kubernetes nesnelerine ve uygulamalarına ayrılmıştır. Bu denetim için, AKS dağıtımlarının durumunu denetlemek için İzleyici'nin İçgörüler görünümünü kullanabilirsiniz:

Alternatif olarak, Container Insights ile Dağıtım ve HPA ölçümleri bölümünde belgelenen özel çalışma kitabını kullanabilirsiniz. İşte bir örnek:

Doğrulama başarılı olduktan sonra T2 aşamasına geçebilirsiniz.

T2: Kubernetes durumunu mavi ve yeşil kümeler arasında eşitleme

Bu aşamada uygulamalar, işleçler ve Kubernetes kaynakları henüz yeşil kümede dağıtılmaz veya AKS kümesi sağlandığında bunların en azından tümü geçerli değildir ve dağıtılmaz. Bu aşamanın nihai hedefi, eşitlemenin sonunda yeşil kümenin mavi kümeyle geriye dönük olarak uyumlu olmasıdır. Öyleyse, trafiği yeşil kümeye geçirmeden önce yeni kümenin durumunu doğrulamak mümkündür.

Kubernetes durumunu kümeler arasında eşitlemenin çeşitli yolları vardır:

Sürekli tümleştirme ve sürekli teslimat (CI/CD) aracılığıyla yeniden dağıtım. Genellikle uygulamaların normal dağıtımı için kullanılan CI/CD işlem hatlarını kullanmak yeterlidir. Bunu yapmaya yönelik yaygın araçlar şunlardır: GitHub Actions, Azure DevOps ve Jenkins.
GitOps; örneğin, Cloud Native Computing Foundation (CNCF) web sitesinde öne çıkarılan Flux ve ArgoCD gibi çözümlerle.
Kubernetes yapılandırmalarını ve kaynaklarını bir veri deposunda depolayan özelleştirilmiş bir çözüm. Bu çözümler genellikle meta veri tanımlarından başlayıp oluşturulan Kubernetes bildirimlerini Azure Cosmos DB gibi bir veri deposunda depolayan Kubernetes bildirim oluşturucularını temel alır. Bunlar genellikle kullanımda olan uygulama açıklaması çerçevesini temel alan özel çözümlerdir.

Aşağıdaki diyagramda Kubernetes durumunu eşitleme işlemi gösterilmektedir:

Eşitleme sırasında genellikle canlı kümede uygulamaların yeni sürümlerinin dağıtımına izin verilmez. Bu süre eşitlemeyle başlar ve yeşil kümeye geçiş tamamlandığında biter. Kubernetes'te dağıtımları devre dışı bırakmanın yolu farklılık gösterebilir. İki olası çözüm şunlardır:

Dağıtım işlem hatlarını devre dışı bırakın.
Dağıtımları yürüten Kubernetes hizmet hesabını devre dışı bırakın.

Açık İlke Aracısı 'nı (OPA) kullanarak hizmet hesabının devre dışı bırakılarak otomatikleştirilmesi mümkündür. Bunun için AKS yerel özelliklerini kullanmak henüz mümkün değildir çünkü bunlar hala önizleme aşamasındadır.

Eşitleme süresi, birden çok kümede Kubernetes durumunu yöneten gelişmiş mekanizmalar kullanılarak önlenebilir.

Eşitleme tamamlandığında kümenin ve uygulamaların doğrulanması gerekir. Buna aşağıdakiler dahildir:

Kümenin sağlığını doğrulamak için izleme ve günlükleme platformlarının kontrolü. T1: Yeşil kümeyi dağıtma aşamasında yaptığınız şeyi yapmayı düşünebilirsiniz.
Şu anda kullanımda olan araç zincirine göre uygulamanın işlevsel testi.

Ayrıca, yeşil küme uygulamalarının performansını bir performans temeli ile karşılaştırmak için bir yük testi oturumu yürütmenizi öneririz. Tercih ettiğiniz aracı veya Azure Yük Testi'ni kullanabilirsiniz.

Genellikle, yeşil küme uygulama ağ geçidinde veya dış yük dengeleyicide dış kullanıcılar tarafından görülmeyecek bir iç URL ile gösterilir.

Yeni küme doğrulandığında, trafiği yeni kümeye geçmek için sonraki aşamaya geçebilirsiniz.

T3: Trafiği yeşil kümeye geçirin

Eşitleme tamamlandıktan ve yeşil küme platform ve uygulama düzeylerinde doğrulandıktan sonra birincil küme olarak yükseltilmeye ve canlı trafiği almaya başlamaya hazır olur. Geçiş ağ düzeyinde yapılır. İş yükleri genellikle durumsuzdur. Ancak, iş yükleri durum bilgiliyse, geçiş sırasında durumu ve önbelleği korumak için ek bir çözüm uygulanmalıdır.

Anahtar uygulandıktan sonra hedef durumu gösteren bir diyagram aşağıda belirtilmiştir:

Bu makalede açıklanan teknikler tam geçişleri uygular: trafiğin %100'ü yeni kümeye yönlendirilir. Bunun nedeni, yönlendirmenin DNS düzeyinde yeşil kümeye işaret eden bir A veya CNAME kayıt atamasıyla uygulanması ve her küme için bir uygulama ağ geçidi olmasıdır.

Aşağıda özel kullanıma yönelik uç noktalar arasında geçiş yapmak için bir yapılandırma örneği verilmiştir. Önerilen çözüm, geçişi gerçekleştirmek için A kayıtlarını kullanır. DNS ve IP eşlemesi açısından, geçişten önce durum aşağıdaki gibidir:

A kayıt aks.priv.contoso.com , mavi uygulama ağ geçidinin özel IP'sini gösterir.
A kayıt aks-blue.priv.contoso.com , mavi uygulama ağ geçidinin özel IP'sini gösterir.
A kayıt aks-green.priv.contoso.com , yeşil uygulama ağ geçidinin özel IP'sini gösterir.

Anahtar aşağıdaki duruma yeniden yapılandırılır:

A kayıt aks.priv.contoso.com , yeşil uygulama ağ geçidinin özel IP'sini gösterir.
A kayıt aks-blue.priv.contoso.com , mavi uygulama ağ geçidinin özel IP'sini gösterir.
A kayıt aks-green.priv.contoso.com , yeşil uygulama ağ geçidinin özel IP'sini gösterir.

Kümelerin kullanıcıları, kayıtların yaşam süresi (TTL) dolduktan ve DNS yayılımı tamamlandıktan sonra bu geçişi görecektir.

Genel kullanıma yönelik uç noktalar için önerilen yaklaşım Azure Front Door ve Azure DNS'yi kullanır. İşte değişiklikten önceki yapılandırma:

CNAME kayıt official-aks.contoso.com, otomatik olarak oluşturulan Azure Front Door etki alanı kaydını işaret eder. Daha fazla bilgi için Öğretici: Front Door'unuza özel etki alanı ekleme konusuna bakın.
A kayıt aks.contoso.com , mavi uygulama ağ geçidinin genel IP'sini gösterir.
Azure Front Door kaynak yapılandırması, aks.contoso.com ana bilgisayar adına işaret eder. Arka uç havuzlarını yapılandırma hakkında daha fazla bilgi için bkz. Azure Front Door'da çıkış noktaları ve kaynak grupları.
- A kayıt aks-blue.contoso.com , mavi uygulama ağ geçidinin genel IP'sini gösterir.
- A kayıt aks-green.contoso.com , yeşil uygulama ağ geçidinin genel IP'sini gösterir.

Anahtar aşağıdaki duruma yeniden yapılandırılır:

CNAME kayıt official-aks.contoso.com, otomatik olarak oluşturulan Azure Front Door etki alanı kaydını işaret eder.
A kayıt aks.contoso.com, yeşil uygulama ağ geçidinin genel IP adresini işaret eder.
Azure Front Door kaynak yapılandırması, aks.contoso.com ana bilgisayar adına işaret eder.
- A kayıt aks-blue.contoso.com , mavi uygulama ağ geçidinin genel IP'sini gösterir.
- A kayıt aks-green.contoso.com, yeşil uygulama ağ geçidinin genel IP adresini işaret eder.

Canary sürümleri için kısmi geçişler gibi alternatif anahtarlama teknikleri, Azure Front Door veya Traffic Manager gibi ek Azure hizmetleri kullanılarak uygulanabilir. Azure Front Door düzeyinde mavi-yeşil trafik geçişinin uygulanmasına ilişkin bilgi için bkz. Azure Front Door ile mavi-yeşil dağıtım.

Örnekte açıklandığı gibi, ağ perspektifinden bu teknik dört ana bilgisayar adının tanımını temel alır:

Resmi genel ana bilgisayar adı: Son kullanıcılar ve tüketiciler tarafından kullanılan resmi genel ana bilgisayar adı.
Küme ana bilgisayar adı: Kümelerde barındırılan iş yüklerinin tüketicileri tarafından kullanılan resmi ana bilgisayar adı.
Mavi küme ana bilgisayar adı: Mavi küme için ayrılmış ana bilgisayar adı.
Yeşil küme ana bilgisayar adı: Yeşil küme için ayrılmış ana bilgisayar adı.

Küme ana bilgisayar adı, giriş trafiğini yönetmek için uygulama ağ geçidi düzeyinde yapılandırılan addır. Ana bilgisayar adı, Aktarım Katmanı Güvenliği'ni (TLS) düzgün yönetmek için AKS giriş yapılandırmasının da bir parçasıdır. Bu ana makine yalnızca gerçek işlemler ve istekler için kullanılır.

Azure Front Door da dağıtımın bir parçasıysa, yalnızca kümenin resmi ana bilgisayar adını yönettiği için bu değişiklikten etkilenmez. Uygulama kullanıcıları için uygun soyutlama sağlar. DNS CNAME kaydı her zaman Azure Front Door’u işaret ettiğinden, onlar bu geçişten etkilenmez.

Mavi ve yeşil küme konak adları genellikle kümeleri test etmek ve doğrulamak için kullanılır. Bu amaçlar doğrultusunda, ana bilgisayar adları, özel uç noktalar üzerinden uygulama ağ geçidi düzeyinde ve ayrıca TLS’nin doğru şekilde yönetilmesi için AKS giriş denetleyicisi düzeyinde sunulur.

Bu aşamada doğrulama, altyapı ve uygulama izleme ölçümlerini ve kullanılabilir olduğunda resmi SLO ve SLA'yı temel alır. Doğrulama başarılı olursa mavi kümeyi yok etmek için son aşamaya geçin.

T4: Mavi kümeyi yok etme

Trafiğin başarıyla değiştirilmesi, yeşil kümenin canlı trafikte beklendiği gibi çalıştığından emin olmak için doğrulama ve izlemenin devam ettiği son aşamaya getirir. Doğrulama ve izleme hem platform hem de uygulama düzeyini kapsar.

Bu doğrulama tamamlandıktan sonra mavi küme yok edilebilir. Yok etme, maliyetleri azaltmak ve Azure'ın sağladığı esnekliğin (özellikle AKS) düzgün bir şekilde kullanılması için kesinlikle önerilen bir adımdır.

Mavi küme yok edildikten sonraki durum şöyledir:

Bileşenler

Application Gateway , web uygulamalarınıza gelen trafiği yönetmenizi sağlayan bir web trafiği (OSI katman 7) yük dengeleyicidir. Bu mimaride Application Gateway, HTTP trafiğinin AKS kümelerine erişmesi için ağ geçidi görevi görür. Dağıtımlar sırasında trafik değişimini etkinleştirmek için mavi ve yeşil kümeler için ayrı örnekler sağlar.
AKS , kapsayıcılı uygulamaları dağıtmak ve yönetmek için kullanabileceğiniz yönetilen bir Kubernetes hizmetidir. Bu mimaride AKS, ana uygulama platformu olarak hizmet vermektedir. Sıfır kesintiyle dağıtıma ve yeni sürümlerin kontrollü dağıtımına olanak tanıyan mavi ve yeşil küme örnekleri sağlar.
Azure Container Registry, kapsayıcı görüntülerini ve ilgili artefaktları depolayan ve yöneten yönetilen bir hizmettir. Bu mimaride Container Registry, dağıtım süreci sırasında kapsayıcı görüntülerini ve Helm çizelgeleri gibi artefaktları mavi ve yeşil AKS kümelerine depolar ve dağıtır.
Azure İzleyici , bulut ve şirket içi ortamlarınızdan izleme verilerini toplamaya, analiz etmeye ve yanıtlamaya yönelik bir izleme çözümüdür. Bu mimaride, mavi-yeşil dağıtımı çalıştırmak için gereken temel izleme özelliklerini sağlar. Azure İzleyici AKS ile tümleşir ve aşama geçişlerini yönetmek için kullanabileceğiniz günlük, izleme ve uyarı özellikleri sağlar.
Azure Key Vault gizli dizileri, anahtarları ve sertifikaları yönetmeye ve korumaya yardımcı olan bir hizmettir. Bu mimaride Key Vault, platform ve uygulama düzeylerinde gereken gizli dizileri ve sertifikaları depolar ve yönetir.
Azure Front Door küresel bir yük dengeleyici ve uygulama uç noktası yönetim sistemidir. Bu mimaride AKS'de barındırılan HTTP uygulamaları için genel uç nokta görevi görür ve mavi ve yeşil uygulama ağ geçitleri arasındaki trafik anahtarını yönetir.
Azure DNS, Microsoft Azure altyapısını kullanarak ad çözümlemesi sağlayan DNS etki alanları için bir barındırma hizmetidir. Bu mimaride, çözümde mavi ve yeşil kümeler için kullanılan ana bilgisayar adlarını yönetir. Ayrıca, özellikle özel uç noktalar için trafik anahtarlarında önemli bir rol oynar.

Alternatif

Daha fazla denetim sağlayabilen trafik anahtarlarını uygulamak için alternatif teknikler vardır. Örneğin, aşağıdaki kriterlerden birini veya daha fazlasını temel alan trafik kurallarını kullanarak kısmi bir geçiş yapmak mümkündür.
- Gelen trafiğin yüzdesi
- HTTP üst bilgileri
- Çerezler
Değişikliklerin neden olduğu sorunlara karşı daha fazla koruma sağlayan bir diğer alternatif de halka tabanlı dağıtımlara sahip olmaktır. Yalnızca mavi ve yeşil kümeler yerine halkalar olarak adlandırılan daha fazla kümeye sahip olmak mümkündür. Her halka, AKS'nin yeni sürümüne erişimi olan kullanıcıları kapsayacak kadar büyüktür. Burada açıklanan mavi-yeşil dağıtım modeli için, uygun maliyet optimizasyonu ve kontrol sağlamak amacıyla halkalar kaldırılabilir.
Application Gateway'in olası alternatifleri NGINX ve HAProxy'dir.
Container Registry'nin olası bir alternatifi Harbor'dır.
Bazı durumlarda, Azure Front Door ve Azure DNS yerine trafik geçişlerini gerçekleştirmek için farklı yük dengeleme ve DNS hizmetlerini kullanmak mümkündür.
Bu çözüm, standart giriş denetleyicisi Kubernetes API'lerini temel alır. Çözümünüz bunun yerine Gateway API'den yarar sağlayacaksa, Application Gateway for Containers kullanın. Yük dengelemeyi yönetmeye ve Application Gateway ile podlar arasındaki giriş trafiği yönetimini işlemeye yardımcı olabilir. Kapsayıcılar için Application Gateway, uygulama ağ geçitlerinin ayarlarını denetler.

Senaryo ayrıntıları

Çözümün temel avantajları şunlardır:

Dağıtım sırasında kesinti süresini en aza indirdi.
Planlı geri alma stratejisi.
AKS değişikliklerinin ve yükseltmelerinin yayımlanması ve dağıtımı sırasında geliştirilmiş denetim ve işlemler.
Olağanüstü durum kurtarma (DR) yordamları yürütme gereksinimini test etme.

Mavi-yeşil dağıtımın temel ilkeleri ve temel yönleri şu makalelerde ele alınıyor:

Otomasyon ve CI/CD açısından bakıldığında, çözüm birden çok şekilde uygulanabilir. Önerimiz:

IaC için Bicep veya Terraform .
CI/CD için Azure Pipelines veya GitHub Actions.

Olası kullanım örnekleri

Mavi-yeşil dağıtım, çalışan uygulamaları ve iş yüklerini etkilemeden kümelerde değişiklik yapmayı mümkün kılar. Değişikliklere örnek olarak şunlar verilebilir:

İşlem değişiklikleri
Yeni AKS özelliklerini etkinleştirme
Kümelerdeki paylaşılan kaynaklarda yapılan değişiklikler
Kubernetes sürümünü güncelleştirme
Giriş ağ geçidi, hizmet ağı, işleçler ve ağ ilkeleri gibi Kubernetes kaynaklarını ve nesnelerini değiştirme
Kümede çalışan iş yüklerini etkilemeden, halen dağıtılmış durumda olan bir AKS kümesinin önceki sürümüne geri alma

Değerlendirmeler

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure Well-Architected Framework'ün yapı taşlarını uygular. Daha fazla bilgi için bkz. Microsoft Azure Well-Architected Framework .

Mavi-yeşil dağıtım, sıfır dokunmalı dağıtım gibi tam otomatikleştirilebilir. Genellikle ilk uygulama, aşamaları etkinleştiren manuel tetikleyicilere sahiptir. Yol boyunca ve uygun olgunluk ve izleme özellikleriyle tetikleyicileri otomatikleştirmek mümkündür. Bu, otomatik testlerin ve tetikleyicilerin otomatik olarak devreye girmesini sağlamak için belirli metriklerin, SLA’lerin ve SLO’ların bulunduğu anlamına gelir.
Mavi ve yeşil kümeler için ayrılmış konak adlarının olması ve ayrıca kümelerin önündeki ağ geçitlerinde ve yük dengeleyicilerde ayrılmış uç nokta yapılandırmalarının olması önemlidir. Bu, yeni kümenin dağıtımının güvenilirliğini ve geçerliliğini geliştirmek için kritik önem taşır. Bu şekilde, dağıtımın doğrulanması standart bir üretim kümesinin aynı mimarisi ve yapılandırmalarıyla gerçekleşir.
AKS kümelerinin farklı iş birimlerinin yönettiği birden çok uygulama için paylaşılan kaynaklar olduğu bir durumu göz önünde bulundurun. Kümelerin genel işleminden ve yaşam döngüsünden sorumlu olan ayrılmış bir ekibin AKS platformunun kendisini yönetmesi ve kümelerde yönetici ve operasyon amacıyla uç noktalar olması yaygın bir durumdur. Bu uç noktaları için, sorumlulukların düzgün şekilde ayrılması ve güvenilirliğin sağlanması amacıyla AKS kümelerinde özel bir ingress denetleyicisi kullanılmasını öneririz.
Mavi-yeşil dağıtım, AKS ve ilgili iş yükleri için iş sürekliliği ve olağanüstü durum kurtarma (BC/DR) çözümlerinin uygulanması ve test edilmesi için yararlıdır. Özellikle, kümelerin birden çok bölgeye yayıldığı durumlar da dahil olmak üzere birden çok kümeyi yönetmek için temel yapıları sağlar.
Mavi-yeşil dağıtımdaki başarı, yalnızca AKS platformuna değil, aynı zamanda platformda dağıtılan iş yüklerine ve uygulamalara otomasyon, izleme ve doğrulama gibi uygulamanın tüm yönlerini uygulamaya dayanır. Bunu yapmak, mavi-yeşil dağıtımdan en yüksek faydayı elde etmenize yardımcı olur.
Önerilen çözümde her senaryo için genel ve özel iki Application Gateway vardır, bu nedenle toplamda dört tane vardır. Bu karar, ağ geçitlerinin yanlış yapılandırılmasından kaynaklanan kapalı kalma süresini önlemek için Azure Application Gateway düzeyinde mavi yeşil dağıtım uygulamaktır. Dört Application Gateway örneği olduğundan bu kararın temel dezavantajı maliyettir. Yalnızca WAF ilkeleri veya ölçeklendirme yapılandırması gibi Application Gateway yapılandırmalarında ilgili değişikliklerin olduğu süre boyunca paralel olarak çalışırlar. Daha fazla maliyet iyileştirmesi için her senaryo için tek bir Application Gateway seçebilirsiniz, bu da toplamda iki Application Gateway anlamına gelir. Bunun için mavi/yeşil mantığı Azure Front Door yerine uygulama ağ geçidine taşımanız gerekir. Bu nedenle Application Gateway, Azure Front Door'un zorunlu olarak denetlenmesi yerine kullanılır.

Güvenilirlik

Güvenilirlik, uygulamanızın müşterilerinize sağladığınız taahhütleri karşılayabilmesini sağlar. Daha fazla bilgi için bkz. Güvenilir uygulama oluşturma önerileri.

Mavi-yeşil dağıtımın AKS platformunun ve iş yüklerinin kullanılabilirliği üzerinde doğrudan ve olumlu bir etkisi vardır. Özellikle AKS platformu değişikliklerinin dağıtımı sırasında kullanılabilirliği artırır. Kullanıcı oturumlarını iyi yönetiyorsanız kesinti süresi çok azdır.
Mavi-yeşil dağıtım, dağıtım sırasında güvenilirlik için kapsam sağlar çünkü varsayılan olarak, yeni küme sürümünde bir sorun olduğunda AKS kümesinin önceki sürümüne geri alma seçeneği vardır.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz. Maliyet iyileştirme sütununa genel bakış.

Mavi-yeşil dağıtım, bulut tarafından sağlanan yerel esneklik nedeniyle Azure'da yaygın olarak benimsenmiştir. Bu, operasyonlar ve kaynak tüketimi açısından maliyetleri iyileştirmeyi mümkün kılar. Tasarrufların çoğu, kümenin yeni sürümü başarıyla dağıtıldıktan sonra artık gerekli olmayan kümenin kaldırılmasından kaynaklanır.
Yeni bir sürüm dağıtıldığında, aynı maliyet temeline sahip olmak için aynı alt ağda hem mavi hem de yeşil kümeleri barındırmak normaldir. Tüm ağ bağlantıları ve kaynaklara ve hizmetlere erişim iki küme için aynıdır ve tüm Azure hizmetleri ve kaynakları aynı kalır.

Operasyonel mükemmellik

Operasyonel mükemmellik, bir uygulamayı dağıtan ve üretimde çalışır durumda tutan operasyon süreçlerini kapsar. Daha fazla bilgi için bkz . Operasyonel mükemmellik sütununa genel bakış.

Düzgün uygulanan mavi-yeşil dağıtım, otomasyon, sürekli teslim ve dayanıklı dağıtım sağlar.
Sürekli teslimin en önemli yönlerinden biri, platform ve iş yükü değişikliklerinde yinelemeli olarak artışlar sağlamasıdır. AKS’nin mavi-yeşil dağıtım yöntemiyle, platform düzeyinde kontrollü ve güvenli bir şekilde sürekli dağıtım sağlayabilirsiniz.
Dayanıklılık, önceki kümeye geri alma seçeneğini içerdiğinden mavi-yeşil dağıtımın temelidir.
Mavi-yeşil dağıtım, iş sürekliliği stratejisiyle ilgili çabayı azaltmak için uygun otomasyon düzeyini sağlar.
Platformu ve uygulamaları izlemek, başarılı bir uygulama için çok önemlidir. Platform için yerel Azure izleme özelliklerini kullanmak mümkündür. Uygulamalar için izlemenin tasarlanması ve uygulanması gerekir.

Bu senaryoyu dağıtın

Bu kılavuzda açıklanan mavi-yeşil dağıtıma ilişkin uygulanmış bir örnek için bkz. İş yükü iniş bölgesinde AKS.

Bu referans uygulaması, Kapsayıcılar için Uygulama Ağ Geçidi temel alınarak oluşturulmuştur. Her kümenin kendine ait bir Application Gateway for Containers dağıtımı vardır ve DNS, trafik geçişini CNAME yapılandırması aracılığıyla gerçekleştirir.

Önemli

Kritik görev iş yükleri için, sıfır kesintiyle dağıtımlar elde etmek amacıyla bu kılavuzda açıklandığı gibi mavi/yeşil dağıtımları dağıtım otomasyonu ve sürekli doğrulamayla birleştirmek önemlidir. Görev açısından kritik tasarım metodolojisinde daha fazla bilgi ve rehberlik sağlanır.

Bölgeyle ilgili dikkat edilmesi gerekenler

Mavi ve yeşil kümeleri ayrı bölgelere veya aynı bölgeye dağıtabilirsiniz. Tasarım ve operasyonel ilkeler bu seçimden etkilenmez. Ancak, aşağıdakiler gibi belirli türlerdeki ek ağ yapılandırmaları etkilenebilir:

AKS ve uygulama ağ geçidi için ayrılmış bir sanal ağ ve alt ağ.
İzleyici, Container Registry ve Key Vault gibi yedekleme hizmetleriyle bağlantı.
Application Gateway’in Azure Front Door görünürlüğü.

Aynı bölgeye dağıtmak için önkoşullar vardır:

Sanal ağlar ve alt ağlar iki kümeyi barındıracak şekilde boyutlandırılmalıdır.
Azure aboneliğinin iki küme için yeterli kapasite sağlaması gerekir.

Giriş denetleyicisinin ve dış yük dengeleyicilerin dağıtımı

Giriş denetleyicisinin ve dış yük dengeleyicilerin dağıtımına yönelik farklı yaklaşımlar vardır:

Küme için ayrılmış bir genel yük dengeleyiciyle eşleştirilmiş tek bir girişe sahip olabilirsiniz. Bu yaklaşım, bu kılavuzda açıklanan mimarinin başvuru uygulaması gibidir. Kapsayıcılar için Application Gateway, AKS için Azure yönetilen katman 7 yük dengeleyici ve giriş çözümüdür. Küme içi uygulama yük dengeleyici denetleyicisi , Kubernetes Gateway API'sini ve Giriş kaynaklarını izleyen ve Kapsayıcılar için Application Gateway'i uygun şekilde yapılandıran bir bileşendir. Bu kaynakları Kapsayıcılar için Application Gateway yapılandırmasına dönüştürür. Belirli senaryolarda AKS kümelerinin uygulama uç noktalarına ek olarak yönetici uç noktaları vardır. Uygulamalarda veya yapılandırma eşlemelerini, gizli dizileri, ağ ilkelerini ve bildirimleri güncelleştirme gibi yapılandırma görevlerini gerçekleştirmek için yönetici uç noktalarını kullanın.
Aynı kümede veya birden çok kümede dağıtılan birden çok girişe hizmet veren tek bir dış yük dengeleyiciniz olabilir. Bu yaklaşım başvuru uygulamasında ele alınmıyor. Bu senaryoda, genel kullanıma yönelik uç noktalar ve özel olanlar için kapsayıcılar için ayrı Application Gateway dağıtımlarına sahip olmanız önerilir.
Bu kılavuzda önerilen ve gösterilen sonuçta elde edilen mimaride Kapsayıcılar için Application Gateway kullanılır. Trafik AKS düğüm havuzunun dışındaki Azure ağ katmanında işlenir, bu nedenle giriş kapasitesi küme düğümlerinden bağımsız olarak ölçeklendirilir. Ayrıca, genel mavi-yeşil mimariyi etkilemeden NGINX veya Envoy gibi standart bir küme içi giriş denetleyicisini de benimseyebilirsiniz.

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

Vincenzo Morra | SAO Kuluçka Mimarı

Diğer katkıda bulunanlar:

Oscar Pla Alvarez | Etki Alanı Çözüm Mimarı

Genel olmayan LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adımlar

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?