Çok katmanlı AKS uygulamaları için yüksek kullanılabilirlik

Azure Cosmos DB
Azure Disk Depolama
Azure Dosyaları
Azure Kubernetes Service (AKS)
Azure Load Balancer

Bu kılavuzda, Azure Kubernetes Service (AKS) kümelerinde çok katmanlı uygulama dağıtımı için yüksek kullanılabilirlik (HA) ele alınmaktadır. Makale, Kubernetes HA mekanizmalarını ve yapılarını açıklar ve ha hatasının tek noktalarını belirlemek ve ortadan kaldırmak için bir denetim listesi ve yönergeler sağlar.

AKS uygulamaları için HA uygulamak için iki temel görev vardır.

  • Uygulamadaki tüm tek hata noktalarını belirleyin.
  • Tek hata noktalarını ortadan kaldırın.

Tek hata noktalarının ortadan kaldırılması için bir HA çözümü gerekir.

Dört HA sütunu

Yüksek oranda kullanılabilir her sistemde dört HA sütunu görünür:

  • Artıklık
  • İzleme
  • Kurtarma
  • Denetim noktası oluşturma

Trafiğin iş mantığı katmanına ulaştığı, veri katmanının durumu koruduğu ve uygulamanın kullanıcılara yanıt döndürdüğü çok katmanlı bir AKS uygulaması düşünün.

ÇOK katmanlı AKS uygulamasının çizimini gösteren diyagram.

Tek hata noktalarını belirleme

Tek hata noktalarını belirlemek için, istemci istekleriyle bu isteklere hizmet eden bileşenler arasındaki kritik yolu belirleyerek başlayın. Bu yoldaki dört HA sütununa göre yönetilmeyen bileşenler veya denetim noktası olmadan durum bilgisi olmayan bir bileşense üç yapı taşı tek bir hata noktasıdır. Çoğaltılan bir bileşen bile izlenmezse tek bir hata noktası olarak kabul edilir, çünkü hatası sessizce algılanmaz.

Tek hata noktalarını ortadan kaldırma

Tek hata noktalarını ortadan kaldırmak için uygulamanızı kritik yol bileşenlerini çoğaltacak şekilde dağıtın ve yük dengeleyiciler, izleme ve kurtarma mekanizmaları kullanın. Kubernetes tüm bu etkinlikleri işleyebilir.

AKS çok katmanlı bir uygulamadaki çoğaltılmış bileşenlerin çizimini gösteren diyagram.

Bu diyagramın Visio dosyasını indirin.

Çoğaltılmış bir uygulamada:

  • İş katmanı bileşenlerini, performanslarına ve iş yüklerine bağlı olarak bileşen başına çeşitli sayıda çoğaltmayla çoğaltabilirsiniz.
  • Ayrıca veri katmanını bir yük dengeleyicinin arkasına da çoğaltabilirsiniz.

Kubernetes, HA sütunlarının uygulanmasına yardımcı olan yük dengeleme ve canlılık yoklamaları gibi çeşitli yapı ve mekanizmalar sunar. Aşağıdaki denetim listesi ve tartışma, bu yapıları ve mekanizmaları dört HA sütunuyla eşleyen kategorilere ayırır.

Kubernetes HA denetim listesi

Durum yönetimi dışında Kubernetes, uygulama HA'sını korumak için olağanüstü bir iş yapar. HA denetim listesi, Kubernetes HA yönetimini iyileştirmek için kullanabileceğiniz yaygın yapılandırmaları listeler. Denetim listesini kullanmak için Kubernetes dağıtımınızı aşağıdaki mekanizmalara ve yapılara göre değerlendirin ve eksik olan tüm öğeleri uygulayın.

HA sütunu Çözüm
Yedeklilik ☐ Kubernetes denetleyici türü
☐ Çoğaltma sayısı
☐ Benzeşimsizliği zamanlama
İzleme ☐ Canlılık yoklamaları
☐ Hazırlık yoklamaları
☐ Başlangıç yoklamaları
Kurtarma ☐ Hizmet türü
☐ Lider seçimi
☐ Yeniden başlatma ilkesi
☐ Ön durdurma kancaları
Denetim noktası oluşturma ☐ Kalıcı birim talepleri
☐ Kalıcı birimler

Yedeklilik

Yedeklilik, tek bir hata noktasına sahip olmayı azaltır. Bir uygulamanın tüm katmanlarında yedekliliğe ihtiyacınız vardır. Yedeklilik elde etmek için, belirli bir katmanın bileşenini bir veya daha fazla özdeş çoğaltmayla çoğaltabilirsiniz.

  • Denetleyici türü, yapılandırma kind: Deployment. Kubernetes, uygulamanızın podunun yaşam döngüsünü yönetebilen çeşitli denetleyiciler sunar. En popüler denetleyicidir Deployment. Diğer denetleyiciler, kurtarma sonrasında Statefulsetpod kimliğini korumak önemli olduğunda kullanışlı olan öğesini içerir. Gibi Replicasets diğer denetleyiciler, dağıtımın sunduğu geri alma işlemleri gibi kullanışlı işlevleri sunmaz.

  • Çoğaltma sayısı, yapılandırma spec.replicas. Çoğaltma sayısını yalnızca bir çoğaltma olarak ayarlamak, soğuk bekleme modeli kullanmaya yönelik kasıtlı bir karardır. Soğuk bekleme, bir hata oluştuğunda yeni bir örneğin sıfırdan başladığı ve bu da kullanılabilirliği etkilediği anlamına gelir. Bu model düşük hacimli iş yüklerine sahip bileşenler için çalışabilir, ancak durum bilgisi olmayan, yüksek hacimli bileşenleri çoğaltmayı göz önünde bulundurun.

    kaynak isteği sınırlarını belirterek, spec.containers[].resourceskubernetes'in tanımladığınız kaynak kullanım eşiklerine göre çoğaltma sayısını otomatik olarak artırmasına veya azaltmasına neden olan yatay pod otomatik ölçeklendirme (HPA) ekleyebilirsiniz. HPA, yükte bir dalgalanmanın uygulamanızın aşırı yükleme nedeniyle istek sunmasını engellediği durumlardan kaçınmaya yardımcı olur.

  • Benzeşimsizliği, yapılandırmayı spec.affinity.podAntiAffinityzamanlama. Tipik bir üretim düzeyi Kubernetes kümesi, kullanılarak ifade edilen birden çok topologyKey yayılmış düğümlere sahiptir. Aynı dağıtımın podları birbirleriyle tercih edilen veya yumuşak benzeşimsiz olmalıdır. Bu yapılandırma, podların farklı kullanılabilirlik alanlarındaki düğümlerde zamanlanmasını sağlar.

    AKS kümesinde, her biri farklı sanal makineler ölçek kümesi boyutlarına ve belirtimlerine sahip birden çok düğüm havuzu olabilir. Örneğin, veritabanı podlarınızı hızlı katı hal sürücülerine (SSD) sahip düğümlerde barındırabilir ve makine öğrenmesi podlarınızı grafik işleme birimleri (GPU) olan düğümlerde barındırabilirsiniz.

İzleme

İzleme olmadan yedeklilik etkisiz hale gelebilir. İş yükünün iyi durumdaki bir çoğaltmaya ulaştığından emin olmak için sabit bir izleme mekanizmasına ihtiyacınız vardır.

  • Canlılık yoklamaları, yapılandırma spec.containers.livenessProbe, podlarınızın durumunu izler. Bir kapsayıcı kilitlenir veya çıkarsa Kubernetes kapsayıcıyı algılayabilir. Canlılık başarısız olduğunda Kubernetes kapsayıcıyı yeniden başlatır.

  • Hazır olma yoklamaları, yapılandırma spec.containers.readinessProbe, pod'a trafik gönderilip gönderilmeyeceğini belirler. Bir dağıtımın podları hazır değilse, kubernetes hizmetinin dağıtımı soyutlayan uç noktalarının bir parçası olmaz ve bu nedenle yararlı olmaz. Hazır olma yoklamalarını dikkatli bir şekilde ayarlamak önemlidir, çünkü bunlar yeniden başlatma tetiklemez, ancak podları hazır olana kadar trafiği almaktan yalıtmak için kullanılırlar.

  • Başlangıç yoklamaları, yapılandırma spec.containers.startupProbe, yavaş başlatan uygulamalarda hazır olma ve canlılık açısından hatalı pozitif sonuçların oluşmasını esas olarak önler. Başlatma araştırması başarılı olduktan sonra canlılık yoklaması devreye giriyor.

Azure, kümenizin durumuna göre uyarılar ayarlamanıza olanak sağlayan daha derin içgörüler sunar.

Kurtarma

İzlemenin temel amacı, bir hata algıladığında kurtarmayı tetiklemesidir. Kurtarma işlemi üç aşamadan oluşur:

  1. Yalıtma ve yeniden yönlendirme: Hatalı çoğaltmanın trafik almadığından emin olun ve iş yükünü iyi durumdaki çoğaltmalara yönlendirin.
  2. Onarım: Geçici hataları onarabilen hatalı çoğaltmayı yeniden başlatın.
  3. Yeniden katılma: Onarımdan sonra, izleme çoğaltmanın iyi durumda olduğunu kabul ederse, iş yükünü işlerken çoğaltmayı diğer çoğaltmalara yeniden katılma.

  • Hizmet türü, yapılandırma spec.type. Podlarınızı bir hizmet aracılığıyla açığa çıkarmak, kurtarmanın yanı sıra yedeklilik altında sınıflandırılabilir. Ancak bazı durumlarda tek çoğaltmalı bir dağıtımınız olabilir. Yük dengeleme olmasa bile podları bir hizmet aracılığıyla kullanıma çıkarmanın avantajları vardır.

    Hizmetin temel avantajı, etki alanı adı hizmeti (DNS) girdilerinin Kubernetes hizmet uç noktalarıyla otomatik olarak güncelleştiriliyor olmasıdır. Başarısız hazırlık yoklamalarına sahip kapsayıcıları olan bir pod AKS üzerinden trafik almaz. Kubernetes kümesi IP hizmetlerinin yük dengeleme özelliği ilkel olsa da, yük dağılımını daha iyi dengelemek için giriş veya diğer hizmet ağı çözümleriyle başsız bir hizmeti birleştirebilirsiniz.

    Dış trafiğin AKS kümenize ulaşma şekli Kubernetes kapsamı dışındadır. dış trafiği Azure Uygulaması lication Gateway gibi hizmetlerle işleyebilirsiniz.

  • Lider seçimi. Bazı bileşenler en iyi şekilde tekil olarak dağıtılır. İki etkin zamanlayıcı çakışabileceğinden zamanlayıcı böyle bir bileşendir. Tekli olması, uygulamayı soğuk bekleme sorunlarına maruz bırakır. Bir podun sıcak beklemesini etkinleştirmek için, yalnızca bir podun, yani liderin istekleri işlediği öncü seçimini kullanabilirsiniz.

  • yeniden başlatma ilkesi, yapılandırma spec.restartPolicy. Yeniden başlatma ilkesi poddaki tüm kapsayıcılar için geçerlidir. Bu özniteliği Neverolarak ayarlamak için geçerli bir gerekçe olmalıdır. Bazı kapsayıcılar her başlatıldığında bir lisans sunucusuyla iletişim kurar ve aşırı yeniden başlatmaların ek maliyetlerinden kaçınmak isteyebilirsiniz.

  • Ön durdurma kancaları, yapılandırma spec.containers.lifecycle.preStop. Ön durdurma kancaları, kapsayıcıya bir SIGTERM sinyal gönderilmeden önce çalışır. Durdurma öncesi betik, 30 saniyelik uyku komutu kadar basit olabilir.

    Örneğin, HPA tarafından yönetilen bir uygulama ölçeği azalttığında, uygulama çıkmadan önce istekleri sunma işlemini tamamlayan bir SIGTERM işleyiciye sahip olmadığı sürece devam eden istekler aniden sonlandırılabilir. Ön durdurma kancası pod uç noktasını ve dolayısıyla DNS girişini hizmet uç noktasından kaldırır. Ön durdurma kancası çalışırken pod'a yeni istek gönderilemiyor. Ön durdurma kancası, pod'un devam eden isteklerini yenilerini almadan işlemeyi bitirmesini sağlar. Ön durdurma kancaları, uygulama kodunu değiştirmeden bırakılan istekleri en aza indirmenin basit bir yoludur.

Denetim noktası oluşturma

Modern uygulamaların durum bilgisi olmayan birçok bileşeni vardır, ancak tamamen durum bilgisi olmayan uygulamalar hala nadirdir. Çoğu uygulama, veri katmanındaki durumlarını denetler. Kubernetes kasıtlı olarak uygulama durumunu işlemek için herhangi bir mekanizma sağlamaz. Durum yönetimi, kapsayıcı yönetiminin parçası olmayan karmaşık bir görevdir.

Uygulama durumunu üç düzeyde kalıcı hale gelebilirsiniz:

  • Veri kayıtları düzeyi, verileri bir veritabanında depolar. Her veritabanı kaydı birden çok veritabanı örneğinde çoğaltılabilir. Veritabanı kayıtları, özellikle Azure Cosmos DB gibi yönetilen bulut veritabanlarında durum kalıcılığının baskın biçimidir.

  • Dosya sistemi düzeyi genellikle önceden yazma günlüğü (WAL) dosyaları gibi veri dosyalarını çoğaltır. Çoğu bulut sağlayıcısı, çözümleri için Azure Dosyalar gibi eklentiler sunar.

  • Disk düzeyi verileri blok düzeyinde kalıcı hale getirir ve bu da Azure Disk Depolama'da olduğu gibi kullanılacak dosya sistemini tanımlama esnekliği sağlar.

Kubernetes birimleri, kalıcı birimler ve kalıcı birim talepleri , uygulamanın durumunu dosya sistemi veya disk düzeyinde kalıcı hale getirir. Durumu depolamak için en yaygın desen yine de veri kayıtları düzeyidir.

HA ve DR

Hem HA hem de olağanüstü durum kurtarmada (DR), ağ topolojisi ve yük dengeleme çözümlerinin seçimleri önemlidir.

Ancak DR, Azure bölgeleri arasında yük dengeleme çözümleriyle birlikte hizmet düzeyinin tamamında çok bölgeli hizmet dağıtımı gerektirir. Uygulama birden çok bölgeye yayılır veya her bölgeye bir uygulama örneğinin tamamı dağıtılır. Seçim, uygulama türüne, uygulama mimarisine ve bileşenler arasındaki gecikme toleransı'na bağlıdır.

HA, birden çok bölge kullanmak yerine Azure bölgeleri içindeki çok bölgeli dağıtımlardan yararlanır. Aşağıdaki diyagramda, HA ve DR için kullanılabilirlik alanları ile bölgeler arasındaki fark gösterilmektedir.

HA ve DR için kullanılabilirlik alanlarını ve Azure bölgelerini karşılaştıran diyagram.

Bu mimarinin bir Visio dosyasını indirin.

Bu kılavuz, bir AKS kümesindeki uygulama düzeyinde HA'ya odaklanmıştır. AKS çok kümeli dağıtımlarında DR hakkında daha fazla bilgi için bkz . Çok bölgeli kümeler için AKS temeli.

Dikkat edilecek diğer noktalar

  • Uygulama HA'sını korumak için API sunucusu ve denetleyici yöneticisi dahil olmak üzere Kubernetes denetim düzleminizin yüksek oranda kullanılabilir olduğundan emin olun. HA'yı güvence altına almak için AKS Çalışma Süresi SLA'sı kullanmayı göz önünde bulundurun.

  • Kaynak birleştirme stratejisi, HA yedeklilik sütununu doğrudan karşılar. Bu nedenle, yedeklilik maliyetini dikkatlice analiz etmelisiniz. Azure fiyatlandırma hesaplayıcısı yardımcı olabilir.

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 yazar:

Diğer katkıda bulunanlar:

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

Sonraki adımlar