AKS kümelerinin mavi-yeşil dağıtı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.

Mimari

Bu bölümde AKS kümelerinin mavi-yeşil dağıtımına yönelik mimariler açıklanmaktadır. Olası iki 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 diyagramda genel kullanıma yönelik büyük/küçük harf mimarisi gösterilmektedir:

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 kullanarak, ağırlıkları temel alan tam anahtar veya daha kontrollü bir anahtar uygulamak mümkündür. Bu teknik, Azure ortamındaki en güvenilir ve verimli tekniktir. Kendi 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 Uygulaması lication Gateway, genel uç noktalara ayrılmış ön uçları sağlar.

Bu diyagram, özel kullanıma yönelik servis talebine yöneliktir:

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, ve CNAME kayıtları kullanılarak A yapılır. Ayrıntılar 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 , yeşil kümenin özel veya genel IP'sine arka uç havuzu olarak sahip olan uygulama ağ geçidinin özel veya genel IP'sini gösterir.

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ının tetikleyici koşulu, kümenin yeni bir sürümü olan yeşil kümenin sürümü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 bkz. AKS veri başvurusu İzleme ve İzleme ile Azure Kubernetes Service'i (AKS) izleme.

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

Kümenin sistem durumu düzey 1 ve 2 ve düzey 3'ün bazılarında 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:

2. düzeyde Kubernetes API sunucusunun ve Kubelet'in düzgün çalıştığından emin olun. Kubelet çalışma kitabını, özellikle de düğümlerin önemli çalışma istatistiklerini gösteren çalışma kitabının iki kılavuzu olan İzleyici'de 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, AKS'de omsagent, kube-proxy gibi varsayılan olarak 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 Analizler görünümünü kullanabilirsiniz:

Alternatif olarak, Kapsayıcı içgörüleri ile Dağıtım ve HPA ölçümleri bölümünde belgelenen ayrılmış çalışma kitabını kullanabilirsiniz. Bir örnek aşağıda verilmiştir:

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 teslim (CI/CD) aracılığıyla yeniden dağıtma. 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.
Flux ve ArgoCD gibi Cloud Native Computing Foundation (CNCF) web sitesinde tanıtılan çözümlerle GitOps.
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 durumunu doğrulamak için izleme ve günlüğe kaydetme platformlarının denetimi. T1: Yeşil küme aşamasını dağıtma bölümünde ne yaptığınızı 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. Anahtar ağ düzeyinde gerçekleştirilir. genellikle iş yükleri durum bilgisi yoktur. Ancak, iş yükleri durum bilgisi varsa, geçiş sırasında durumu ve önbelleğe almayı 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 anahtarlar uygular: Trafiğin %100'ünün yeni kümeye yönlendirilmiş olması. 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ş yapmak için kayıtları kullanır A . DNS ve IP eşleme perspektifinden bakıldığında, durum anahtardan önce 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 şekilde yeniden yapılandırr:

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ı, yaşam süresi (TTL) ve kayıtların DNS yayılması sonrasında anahtarı görür.

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

CNAME kayıt official-aks.contoso.com , otomatik olarak oluşturulan Azure Front Door etki alanının kaydını gösterir. Daha fazla bilgi için bkz. Öğretici: Front Door’unuza özel etki alanı ekleme.
A kayıt aks.contoso.com , mavi uygulama ağ geçidinin genel IP'sini gösterir.
Azure Front Door kaynak yapılandırması ana bilgisayar adını gösterir aks.contoso.com . 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 şekilde yeniden yapılandırr:

CNAME kayıt official-aks.contoso.com , otomatik olarak oluşturulan Azure Front Door etki alanının kaydını gösterir.
A kayıt aks.contoso.com , yeşil uygulama ağ geçidinin genel IP'sine işaret etti.
Azure Front Door kaynak yapılandırması ana bilgisayar adını gösterir aks.contoso.com .
- 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'sine işaret etti.

Kanarya sürümleri için kısmi anahtarlar gibi alternatif anahtarlama teknikleri, Azure Front Door veya Traffic Manager gibi ek Azure hizmetleriyle mümkündür. Azure Front Door düzeyinde mavi-yeşil trafik anahtarının uygulanması 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 konak 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 konak yalnızca canlı işlemler ve istekler için kullanılır.

Azure Front Door da dağıtımın bir parçasıysa, yalnızca resmi küme ana bilgisayar adını yönettiğinden anahtardan etkilenmez. Uygulama kullanıcıları için uygun soyutlama sağlar. DNS CNAME kaydı her zaman Azure Front Door'a işaret ettiğinden anahtardan etkilenmez.

Mavi ve yeşil küme konak adları genellikle kümeleri test etmek ve doğrulamak için kullanılır. Bu amaçlarla, konak adları ayrılmış uç noktaları olan uygulama ağ geçidi düzeyinde ve AYRıCA TLS'yi düzgün yönetmek için AKS giriş denetleyicisi düzeyinde kullanıma 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 çözümde, HTTP trafiğinin AKS kümelerine erişmesi için ağ geçidi olarak kullanılır.
Azure Kubernetes Service (AKS), kapsayıcılı uygulamaları dağıtmak ve yönetmek için kullanabileceğiniz yönetilen bir Kubernetes hizmetidir. Bu uygulama platformu, bu düzenin ana bileşenidir.
Azure Container Registry , kapsayıcı görüntülerini ve ilgili yapıtları depolamak ve yönetmek için kullanılan yönetilen bir hizmettir. Bu çözümde, Helm grafikleri gibi kapsayıcı görüntülerini ve yapıtlarını AKS kümelerinde depolamak ve dağıtmak için kullanılı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. Mavi yeşil dağıtımı yürütmek için gereken temel izleme özelliklerini sağlar. AKS ile tümleştirmesi ve aşama geçişlerini yönetmek için kullanılabilecek günlüğe kaydetme, izleme ve uyarı özellikleri sağlama özelliği nedeniyle bu mimaride kullanılır.
Azure Key Vault aşağıdaki sorunların çözülmesine yardımcı olur: Gizli Dizi Yönetimi, Anahtar Yönetimi ve Sertifika Yönetimi; bu çözüm için platfomr ve uygulama düzeyinde gereken gizli dizileri ve sertifikaları depolamak ve yönetmek için kullanılır.
Azure Front Door küresel bir yük dengeleyici ve uygulama uç noktası yönetim sistemidir. Bu çözümde, AKS'de barındırılan HTTP uygulamaları için genel uç nokta olarak kullanılır. Bu çözümde, mavi ve yeşil uygulama ağ geçitleri arasındaki trafik anahtarını yönetmek kritik sorumluluğa sahiptir.
Azure DNS , Microsoft Azure altyapısını kullanarak ad çözümlemesi sağlayan DNS etki alanları için bir barındırma hizmetidir. Mavi ve yeşil kümeler için çözümde kullanılan konak adlarını yönetir ve özellikle özel uç noktalar için trafik anahtarlarında önemli bir rol oynar.

Alternatifler

Daha fazla denetim sağlayabilen trafik anahtarlarını uygulamak için alternatif teknikler vardır. Örneğin, aşağıdakilerden birini veya daha fazlasını temel alan trafik kurallarını kullanarak kısmi bir anahtar yapmak mümkündür:
- Gelen trafiğin yüzdesi
- HTTP üst bilgileri
- Tanımlama bilgileri
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ı sayısı için yeterince büyüktür. Burada açıklanan mavi-yeşil dağıtıma gelince, uygun maliyet iyileştirme ve denetimine sahip olmak için halkalar kaldırılabilir.
Application Gateway'in olası alternatifleri NGINX ve HAProxy'dir.
Container Registry'nin olası bir alternatifi Harbor'dır.
Bazı durumlarda trafik anahtarlarını gerçekleştirmek için Azure Front Door ve Azure DNS yerine farklı yük dengeleme ve DNS hizmetleri kullanmak mümkündür.
Bu çözüm, standart giriş denetleyicisi Kubernetes API'lerini temel alır. Çözümünüz Ağ Geçidi API'sinden yararlanacaksa Kapsayıcılar için Application Gateway'i 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 kapalı kalma süresini en aza indirin.
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, ağ ilkeleri vb. gibi Kubernetes kaynaklarını ve nesnelerini değiştirme
Kümede çalışan iş yüklerini etkilemeden aks kümesinin hala dağıtılmış olan önceki sürümüne geri dönme

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Mavi-yeşil dağıtım, sıfır dokunmalı dağıtım gibi tam otomatikleştirilebilir. Genellikle, bir ilk uygulama aşamaları etkinleştirmek için el ile tetikleyiciler vardır. Yol boyunca ve uygun olgunluk ve izleme özellikleriyle tetikleyicileri otomatikleştirmek mümkündür. Bu, otomatikleştirilmiş test ve tetikleyicileri otomatikleştirmek için belirli ölçümler, SLA ve SLO olduğ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ş birimleri tarafından yönetilen birden çok uygulama için paylaşılan kaynaklar olduğu bir durumu göz önünde bulundurun. Bu gibi durumlarda AKS platformunun kendisinin kümelerin genel işleminden ve yaşam döngüsünden sorumlu ayrılmış bir ekip tarafından yönetilmesi ve kümelerde yönetici ve operasyon amacıyla uç noktalar olması yaygın bir durumdur. Bu uç noktaların, endişelerin doğru şekilde ayrılması ve güvenilirlik için AKS kümelerinde ayrılmış bir giriş denetleyicisine sahip olması önerisinde bulunur.
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 avantajı elde edebilirsiniz.
Ö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 Uygulaması Lication 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üvenilirlik sütununa genel bakış.

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ı iyi yönetiliyorsa çok az kapalı kalma süresi vardı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ı ile platform düzeyinde kontrollü ve güvenli bir şekilde sürekli teslim elde edebilirsiniz.
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 uygulanan bir örnek için bkz . AKS Giriş Bölgesi Hızlandırıcısı.

Bu başvuru uygulaması Application Gateway ve Application Gateway Giriş Denetleyicisi'ni (AGIC) temel alır. Her kümenin kendi uygulama ağ geçidi vardır ve trafik anahtarı DNS aracılığıyla, özellikle de yapılandırma yoluyla CNAME gerçekleştirilir.

Önemli

Görev açısından kritik iş yükleri için, sıfır kapalı kalma süresi dağıtımı elde etmek için bu kılavuzda özetlenen mavi/yeşil dağıtımları dağıtım otomasyonu ve sürekli doğrulama ile 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ğlan.
Uygulama ağ geçidinin 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:

Bu kılavuzda açıklanan mimarinin başvuru uygulaması gibi ayrılmış bir dış yük dengeleyiciye sahip tek bir giriş denetleyiciniz olabilir. AGIC , bulut yazılımını İnternet'te kullanıma açmak için Application Gateway L7 yük dengeleyiciyi kullanmayı mümkün kılan bir Kubernetes uygulamasıdır. Bazı senaryolarda, AKS kümelerinde uygulama uç noktalarına ek olarak yönetici uç noktaları vardır. Yönetici uç noktaları, uygulamalarda veya yapılandırma eşlemelerini, gizli dizileri, ağ ilkelerini ve bildirimleri güncelleştirme gibi yapılandırma görevlerini gerçekleştirmeye yöneliktir.
Aynı kümede veya birden çok kümede dağıtılan birden çok giriş denetleyicisine 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 ayrı uygulama ağ geçitleriniz olması önerilir.
Bu kılavuzda önerilen ve gösterilen mimari, NGINX ve Envoy tabanlı olanlar gibi AKS kümesinin bir parçası olarak dağıtılan standart bir giriş denetleyicisini temel alır. Başvuru uygulamasında AGIC kullanıyoruz, yani uygulama ağ geçidi ile AKS podları arasında doğrudan bağlantı var, ancak bu genel mavi-yeşil mimariyi etkilemez.

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.

Aracılığıyla paylaş

AKS kümelerinin mavi-yeşil dağıtımı