Aracılığıyla paylaş

Azure Kubernetes Service (AKS) için etkin-pasif olağanüstü durum kurtarma çözümüne genel bakış

  • Makale

Azure Kubernetes Service'te (AKS) bir uygulama oluşturduğunuzda ve kaynak oluşturma sırasında bir Azure bölgesi seçtiğinizde, bu tek bölgeli bir uygulamadır. Bölge olağanüstü durum sırasında kullanılamaz duruma geldiğinde uygulamanız da kullanılamaz duruma gelir. İkincil bir Azure bölgesinde aynı dağıtımı oluşturursanız, uygulamanız iş sürekliliğini garanti eden tek bölgeli olağanüstü duruma daha az duyarlı hale gelir ve bölgeler arasında veri çoğaltması son uygulama durumunuzu kurtarmanıza olanak tanır.

Bu kılavuzda AKS için etkin-pasif olağanüstü durum kurtarma çözümü özetlenmiştir. Bu çözümde, yalnızca bir kümenin etkin olarak trafiğe hizmet veren iki eşleştirilmiş Azure bölgesine iki bağımsız ve özdeş AKS kümesi dağıtacağız.

Not

Aşağıdaki uygulama, Microsoft iş ortaklarımızla birlikte şirket içinde gözden geçirildi ve incelendi.

Etkin-pasif çözüme genel bakış

Bu olağanüstü durum kurtarma yaklaşımında iki Azure bölgesine dağıtılan iki bağımsız AKS kümemiz vardır. Ancak kümelerden yalnızca biri herhangi bir anda etkin olarak trafiğe hizmet ediyor. İkincil küme (etkin olarak trafiğe hizmet vermiyor) birincil kümeyle aynı yapılandırma ve uygulama verilerini içerir, ancak Azure Front Door trafik yöneticisi tarafından yönetilmediği sürece herhangi bir trafiği kabul etmez.

Senaryolar ve yapılandırmalar

Bu çözüm, veritabanları gibi tek bir bölgedeki trafiğe etkin bir şekilde hizmet veren kaynaklara dayalı uygulamalar barındırılırken en iyi şekilde uygulanır. Yatay ölçeklendirme gibi her iki bölgede de dağıtılan durum bilgisi olmayan uygulamaları barındırmanız gereken senaryolarda, etkin-pasif ek gecikme süresi gerektirdiği için etkin-etkin bir çözüm kullanmayı göz önünde bulundurmanızı öneririz.

Bileşenler

Etkin-pasif olağanüstü durum kurtarma çözümü birçok Azure hizmetini kullanır. Bu örnek mimari aşağıdaki bileşenleri içerir:

Birden çok küme ve bölge: Her birinde ayrı bir Azure bölgesinde birden çok AKS kümesi dağıtırsınız. Normal işlemler sırasında ağ trafiği, Azure Front Door yapılandırmasında ayarlanan birincil AKS kümesine yönlendirilir.

Yapılandırılmış küme önceliklendirmesi: Her küme için 1-5 arasında bir öncelik belirleme düzeyi ayarlarsınız (1 en yüksek öncelik ve 5 en düşük önceliktir). Birden çok kümeyi aynı öncelik düzeyine ayarlayabilir ve her küme için ağırlığı belirtebilirsiniz. Birincil küme kullanılamaz duruma gelirse trafik otomatik olarak Azure Front Door'da seçilen sonraki bölgeye yönlendirilir. Bu sistemin çalışması için tüm trafiğin Azure Front Door'a gitmesi gerekir.

Azure Front Door: Azure Front Door, trafiği birincil bölgedeki Azure Uygulaması lication Gateway örneğine yönlendirir (küme 1 önceliğiyle işaretlenmelidir). Bölge hatası durumunda hizmet, trafiği öncelik listesindeki bir sonraki kümeye yönlendirir.

Daha fazla bilgi için bkz . Öncelik tabanlı trafik yönlendirme.

Merkez-uç çifti: Her bölgesel AKS örneği için bir merkez-uç çifti dağıtılır. Azure Güvenlik Duvarı Yöneticisi ilkeleri her bölgede güvenlik duvarı kurallarını yönetir.

Key Vault: Gizli dizileri ve anahtarları depolamak için her bölgede bir Azure Key Vault sağlanır.

Log Analytics: Bölgesel Log Analytics örnekleri bölgesel ağ ölçümlerini ve tanılama günlüklerini depolar. Paylaşılan örnek, tüm AKS örnekleri için ölçümleri ve tanılama günlüklerini depolar.

Container Registry: İş yükünün kapsayıcı görüntüleri yönetilen bir kapsayıcı kayıt defterinde depolanır. Bu çözümle, kümedeki tüm Kubernetes örnekleri için tek bir Azure Container Registry örneği kullanılır. Azure Container Registry için coğrafi çoğaltma, görüntüleri seçili Azure bölgelerine çoğaltmanıza olanak tanır ve bir bölgede kesinti yaşansa bile görüntülere sürekli erişim sağlar.

Yük devretme işlemi

Bir hizmet veya hizmet bileşeni bir bölgede kullanılamaz duruma gelirse trafik, hizmetin kullanılabilir olduğu bir bölgeye yönlendirilmelidir. Çok bölgeli mimari birçok farklı hata noktası içerir. Bu bölümde olası hata noktalarını ele alacağız.

Uygulama Podları (Bölgesel)

Kubernetes dağıtım nesnesi bir podun (ReplicaSet) birden çok çoğaltmasını oluşturur. Biri kullanılamıyorsa, trafik kalan çoğaltmalar arasında yönlendirilir. Kubernetes ReplicaSet , belirtilen sayıda çoğaltmayı çalışır durumda tutmaya çalışır. Bir örnek devre dışı kalırsa yeni bir örnek yeniden oluşturulmalıdır. Canlılık yoklamaları podda çalışan uygulamanın veya işlemin durumunu denetleyebilir. Pod yanıt vermiyorsa canlılık yoklaması podu kaldırır ve bu da ReplicaSet'i yeni bir örnek oluşturmaya zorlar.

Daha fazla bilgi için bkz . Kubernetes ReplicaSet.

Uygulama Podları (Genel)

Tüm bölge kullanılamaz duruma geldiğinde, kümedeki podlar artık istek sunmak için kullanılamaz. Bu durumda, Azure Front Door örneği tüm trafiği kalan sistem durumu bölgelerine yönlendirir. Bu bölgelerdeki Kubernetes kümeleri ve podları isteklere hizmet etmeye devam eder. Artan trafiği ve kalan kümeye yönelik istekleri telafi etmek için aşağıdaki yönergeleri göz önünde bulundurun:

Kubernetes düğüm havuzları (Bölgesel)

Bazen, tek bir Azure sunucu rafında güç kullanılamaması gibi işlem kaynaklarında yerelleştirilmiş hata oluşabilir. AKS düğümlerinizi tek nokta bölgesel hata haline getirmekten korumak için Azure Kullanılabilirlik Alanları kullanın. Kullanılabilirlik alanları, her kullanılabilirlik alanındaki AKS düğümlerinin başka bir kullanılabilirlik alanında tanımlananlardan fiziksel olarak ayrılmasını sağlar.

Kubernetes düğüm havuzları (Genel)

Tam bir bölgesel hatada, Azure Front Door trafiği kalan iyi durumdaki bölgelere yönlendirir. Yine, artan trafiği ve kalan kümeye yönelik istekleri telafi etmeye özen gösterin.

Yük devretme testi stratejisi

Aks'de şu anda test amacıyla tüm dağıtım bölgesini çökertmeye yönelik bir mekanizma olmasa da Azure Chaos Studio, kümenizde bir kaos denemesi oluşturma olanağı sunar.

Sonraki adımlar

Farklı bir çözüm kullanmayı düşünüyorsanız aşağıdaki makalelere bakın: