Azure Kubernetes Service için işlem yönetimiyle ilgili dikkat edilmesi gerekenler

Kubernetes, etkileyici bir ekosistemle hızla gelişen görece yeni bir teknolojidir. Bu nedenle, yönetmek ve korumak zor olabilir.

AKS için işlem temeli

Yönetim ve izlemeyi göz önünde bulundurarak Azure Kubernetes Service (AKS) çözümünüzü düzgün bir şekilde tasarlayarak operasyonel mükemmellik ve müşteri başarısı için çalışabilirsiniz.

Tasarımla ilgili dikkat edilecek noktalar

Aşağıdaki etmenleri inceleyin:

• AKS sınırlarına dikkat edin. Bu sınırların ötesine ölçeklendirmek için birden çok AKS örneği kullanın.
• İş yüklerini bir küme içinde mantıksal olarak ve fiziksel olarak ayrı kümelerde yalıtmanın yollarını unutmayın.
• kaynak tüketimini iş yüklerine göre denetlemenin yollarını unutmayın.
• Kubernetes'in iş yüklerinizin durumunu anlamasına yardımcı olmanın yollarını unutmayın.
• Çeşitli sanal makine boyutlarına ve birini veya diğerini kullanmanın etkisine dikkat edin. Daha büyük VM'ler daha fazla yükü işleyebilir. Planlı ve plansız bakım için kullanılamadığında daha küçük VM'ler başkaları tarafından daha kolay değiştirilebilir. Ayrıca, bir ölçek kümesindeki düğüm havuzlarına ve VM'lere dikkat ederek aynı kümedeki farklı boyutlardaki sanal makinelere izin verin. AKS kaynaklarının daha küçük bir yüzdesini ayırarak kaynaklarının daha fazlasını iş yükleriniz için kullanılabilir hale getirmesi nedeniyle daha büyük VM'ler daha uygundur.
• AKS'yi izlemenin ve günlüğe kaydetmenin yollarını unutmayın. Kubernetes çeşitli bileşenlerden oluşur ve izleme ve günlüğe kaydetme özelliği sistem durumu, eğilimleri ve olası sorunları hakkında içgörü sağlamalıdır.
• İzleme ve günlüğe kaydetme üzerine oluşturulan kubernetes veya uygulamalar tarafından oluşturulan ve en üstte çalışan birçok olay olabilir. Uyarılar, geçmişe dönük amaçlarla günlük girdileri ile anında eylem gerektirenler arasında ayrım yapmanıza yardımcı olabilir.
• Yapmanız gereken güncelleştirmelere ve yükseltmelere dikkat edin. Kubernetes düzeyinde ana, ikincil ve düzeltme eki sürümleri vardır. Müşterinin bu güncelleştirmeleri yukarı akış Kubernetes'teki ilkeye göre desteklenmeye devam etmesi için uygulaması gerekir. Çalışan ana bilgisayar düzeyinde, işletim sistemi çekirdeği düzeltme ekleri müşterinin yapması ve yeni işletim sistemi sürümlerine yükseltmesi gereken bir yeniden başlatma gerektirebilir. Bir kümeyi el ile yükseltmeye ek olarak, kümenizde bir otomatik yükseltme kanalı ayarlayabilirsiniz.
• Kümenin kaynak sınırlamalarına ve tek tek iş yüklerine dikkat edin.
• Yatay pod otomatik ölçeklendiricisi ile küme otomatik ölçeklendiricisi arasındaki farkları unutmayın
• Ağ ilkelerini ve Azure ilkeleri eklentisini kullanarak podlar arasındaki trafiğin güvenliğini sağlamayı göz önünde bulundurun
• AKS üzerinde çalışan uygulama ve hizmetlerinizin sorunlarını gidermeye yardımcı olmak için denetim düzlemi bileşenleri tarafından oluşturulan günlükleri görüntülemeniz gerekebilir. Günlük kaydı varsayılan olarak etkinleştirilmediğinden AKS için kaynak günlüklerini etkinleştirmek isteyebilirsiniz.

Öneriler

• AKS sınırlarını anlama:

  • Kotalar ve bölgesel sınırlar
  • AKS hizmet sınırları

• Uygulamaları, ekipleri, ortamları ve iş birimlerini ayırmak için ad alanı düzeyinde mantıksal yalıtım kullanın. Çok kiracılı ve küme yalıtımı. Ayrıca düğüm havuzları farklı düğüm belirtimlerine sahip düğümlerde yardımcı olabilir ve Kubernetes gibi bakımlar birden çok düğüm havuzunu yükseltir

• Kaynak kotalarını ad alanı düzeyinde planlayın ve uygulayın. Podlar kaynak isteklerini ve sınırlarını tanımlamıyorsa, ilkeleri kullanarak dağıtımı reddedin vb. Bu, kube-system podları için geçerli değildir çünkü tüm kube-system podlarının istekleri ve sınırları yoktur. Kaynak kullanımını izleyin ve kotaları gerektiği gibi ayarlayın. Temel zamanlayıcı özellikleri

• Podlarınıza sistem durumu yoklamaları ekleyin. Podların , readinessProbeve startupProbe AKS sistem durumu yoklamaları içerdiğinelivenessProbe emin olun.

• Birden çok kapsayıcı örneği içerecek kadar büyük VM boyutları kullanın; böylece artan yoğunluk avantajlarından yararlanabilirsiniz, ancak kümeniz başarısız olan bir düğümün iş yükünü işleyemeyen kadar büyük değildir.

• İzleme çözümü kullanın. Azure İzleyici kapsayıcı içgörüleri varsayılan olarak ayarlanır ve birçok içgörüye kolay erişim sağlar. Daha ayrıntılı detaya gitmek veya Prometheus kullanma deneyimi yaşamak istiyorsanız Prometheus tümleştirmesini kullanabilirsiniz. AKS'de de bir izleme uygulaması çalıştırmak istiyorsanız, bu uygulamayı izlemek için Azure İzleyici'yi de kullanmanız gerekir.

• İşlerin doğrudan eyleme ihtiyacı olduğunda bildirim sağlamak için Azure İzleyici kapsayıcı içgörüleri ölçüm uyarılarını kullanın.

• Uygulama taleplerini karşılamak ve yoğun saat yüklerini azaltmak için otomatik düğüm havuzu ölçeklendirme özelliğini yatay pod otomatik ölçeklendiricisi ile birlikte kullanın.

• Maliyet, güvenlik, güvenilirlik, operasyonel mükemmellik ve performansla ilgili en iyi deneyim önerilerini almak için Azure Danışmanı'ni kullanın. Ayrıca görüntü güvenlik açıkları gibi tehditleri önlemek ve algılamak için Bulut için Microsoft Defender kullanın.

• Azure'da AKS olmayan Kubernetes kümelerini Azure İlkesi, Bulut için Defender, GitOps vb. kullanarak yönetmek için Azure Arc özellikli Kubernetes'i kullanın.

• AKS kümesindeki işlem kaynaklarını yönetmek için pod isteklerini ve sınırlarını kullanın. Pod istekleri ve sınırları, Kubernetes zamanlayıcısını bir pod'a atanacak işlem kaynakları hakkında bilgilendirir.

AKS'yi korumak ve kurtarmak için iş sürekliliği/olağanüstü durum kurtarma

Kuruluşunuzun belirli gereksinimlerini karşılamak için uygun Azure Kubernetes Service (AKS) platform düzeyinde özellikler tasarlaması gerekir. Bu uygulama hizmetlerinin kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) ile ilgili gereksinimleri vardır. AKS olağanüstü durum kurtarma için dikkat edilmesi gereken birden çok nokta vardır. İlk adımınız, altyapınız ve uygulamanız için bir hizmet düzeyi sözleşmesi (SLA) tanımlamaktır. Azure Kubernetes Service (AKS) için SLA hakkında bilgi edinin. Aylık çalışma süresi hesaplamaları hakkında bilgi için SLA ayrıntıları bölümüne bakın.

Tasarımla ilgili dikkat edilecek noktalar

Aşağıdaki etmenleri inceleyin:

• AKS kümesi, uygulamanız için en düşük kullanılabilirlik düzeyini sağlamak için düğüm havuzunda birden çok düğüm kullanmalıdır.

• Pod isteklerini ve sınırlarını ayarlayın. Bu sınırların ayarlanması Kubernetes'in şunları yapmasına olanak tanır:

  • Podlara verimli bir şekilde CPU ve bellek kaynakları verin.
  • Bir düğümde daha yüksek kapsayıcı yoğunluğuna sahip olun.

  Sınırlar, donanımın daha iyi kullanılması nedeniyle daha düşük maliyetlerle güvenilirliği de artırabilir.

• Kullanılabilirlik Alanları veya kullanılabilirlik kümeleri için AKS uygunluğu.

  • Kullanılabilirlik Alanları destekleyen bir bölge seçin.
  • Kullanılabilirlik Alanları yalnızca düğüm havuzu oluşturulduğunda ayarlanabilir ve daha sonra değiştirilemez. Çok bölgeli destek yalnızca düğüm havuzları için geçerlidir.
  • Tüm bölgesel avantaj için tüm hizmet bağımlılıklarının bölgeleri de desteklemesi gerekir. Bağımlı bir hizmet bölgeleri desteklemiyorsa, bölge hatası bu hizmetin başarısız olmasına neden olabilir.
  • Kullanılabilirlik Alanları ulaşabileceklerinin ötesinde daha yüksek kullanılabilirlik için farklı eşleştirilmiş bölgelerde birden çok AKS kümesi çalıştırın. Azure kaynağı coğrafi olarak yedekliliği destekliyorsa, yedekli hizmetin ikincil bölgesine sahip olduğu konumu belirtin.

• AKS'de olağanüstü durum kurtarma yönergelerini bilmeniz gerekir. Ardından Bunların Azure Dev Spaces için kullandığınız AKS kümelerine uygulanıp uygulanmayacağını göz önünde bulundurun.

• Uygulamalar ve veriler için sürekli olarak yedeklemeler oluşturun.

  • Durum bilgisi olmayan bir hizmet verimli bir şekilde çoğaltılabilir.
  • Kümede durum depolamanız gerekiyorsa, eşleştirilmiş bölgede verileri sık sık yedekleyin. Dikkat edilmesi gereken noktalardan biri, kümede durumu düzgün bir şekilde depolamanın karmaşık olabileceğidir.

• Küme güncelleştirmesi ve bakımı.

  • Kümenizi her zaman güncel tutun.
  • Sürüm ve kullanımdan kaldırma işlemine dikkat edin.
  • Güncelleştirmelerinizi ve bakımlarınızı planlayın.

• Yük devretme gerçekleşirse ağ bağlantısı.

  • Gereksinimlerinize bağlı olarak trafiği bölgeler veya bölgeler arasında dağıtabilecek bir trafik yönlendiricisi seçin. Bu mimari, web dışı trafiği bölgeler arasında dağıtabildiğinden Azure Load Balancer'ı dağıtır.
  • Trafiği bölgeler arasında dağıtmanız gerekiyorsa Azure Front Door kullanmayı göz önünde bulundurun.

• Planlı ve plansız yük devretmeler.

  • Her Azure hizmetini ayarlarken olağanüstü durum kurtarmayı destekleyen özellikleri seçin. Örneğin, bu mimari coğrafi çoğaltma için Azure Container Registry'yi etkinleştirir. Bir bölge kapatılırsa yine de çoğaltılan bölgeden görüntü çekebilirsiniz.

• Hizmet düzeyi hedeflerine ulaşmak için mühendislik DevOps özelliklerini koruyun.

• Kubernetes API sunucu uç noktanız için mali olarak yedeklenmiş bir SLA'ya ihtiyacınız olup olmadığını belirleyin.

Tasarım önerileri

Tasarımınız için en iyi yöntemler şunlardır:

• Sistem düğümü havuzu için üç düğüm kullanın. Kullanıcı düğümü havuzu için en az iki düğümle başlayın. Daha yüksek kullanılabilirliğe ihtiyacınız varsa daha fazla düğüm ayarlayın.

• Uygulamanızı ayrı bir düğüm havuzuna yerleştirerek sistem hizmetlerinden yalıtın. Bu şekilde Kubernetes hizmetleri ayrılmış düğümlerde çalışır ve diğer hizmetlerle rekabet etmez. İş yükünüzü zamanlamak için düğüm havuzunu tanımlamak için etiketleri, etiketleri ve renk tonlarını kullanın.

• Kümenizin düzenli olarak desteklenmesi( örneğin, zamanında güncelleştirmeler yapmak) güvenilirlik açısından çok önemlidir. AKS'de Kubernetes sürümleri için destek penceresine dikkat edin ve güncelleştirmelerinizi planlayın. Ayrıca, yoklamalar aracılığıyla podların durumunun izlenmesi önerilir.

• Mümkün olduğunda kapsayıcıların içinden hizmet durumunu kaldırın. Bunun yerine, çok bölgeli çoğaltmayı destekleyen bir hizmet olarak Azure platformu (PaaS) kullanın.

• Pod kaynaklarının olduğundan emin olun. Dağıtımların pod kaynak gereksinimlerini belirtmesi kesinlikle önerilir. Zamanlayıcı daha sonra uygun şekilde pod zamanlayabilir. Podlar zamanlanmamışsa güvenilirlik kullanım dışıdır.

• Donanım hataları gibi kesintileri işlemek için dağıtımda birden çok çoğaltma ayarlayın. Güncelleştirmeler ve yükseltmeler gibi planlı olaylar için kesinti bütçesi, beklenen uygulama yükünü işlemek için gerekli pod çoğaltması sayısının mevcut olmasını sağlayabilir.

• Uygulamalarınız verileri için Azure Depolama kullanabilir. Uygulamalarınız farklı bölgelerdeki birden çok AKS kümesine yayıldığından, depolamayı eşitlenmiş durumda tutmanız gerekir. Depolamayı çoğaltmanın iki yaygın yolu şunlardır:

  • Altyapı tabanlı zaman uyumsuz çoğaltma
  • Uygulama tabanlı zaman uyumsuz çoğaltma

• Pod sınırlarını tahmin edin. Temeli test edin ve oluşturun. İstekler ve sınırlar için eşit değerlerle başlayın. Ardından, kümede istikrarsızlığa neden olabilecek bir eşik oluşturana kadar bu değerleri aşamalı olarak ayarlayın. Pod sınırları dağıtım bildirimlerinizde belirtilebilir.

  Yerleşik özellikler, hizmet mimarisindeki hataları ve kesintileri işlemeye yönelik karmaşık görev için bir çözüm sağlar. Bu yapılandırmalar hem tasarım hem de dağıtım otomasyonlarını basitleştirmeye yardımcı olur. Bir kuruluş SLA, RTO ve RPO için bir standart tanımladığında, iş hedeflerine ulaşmak için Kubernetes ve Azure'a yönelik yerleşik hizmetleri kullanabilir.

• Pod kesintisi bütçelerini ayarlayın. Bu ayar, bir güncelleştirme veya yükseltme olayı sırasında dağıtımda kaç çoğaltma indirebileceğinizi denetler.

• Hizmet ad alanları üzerinde kaynak kotalarını zorunlu kılma. Bir ad alanı üzerindeki kaynak kotası, pod isteklerinin ve sınırların dağıtımda düzgün şekilde ayarlanmasını sağlar.

  • Kaynak kotalarının küme düzeyinde ayarlanması, uygun isteklere ve sınırlara sahip olmayan iş ortağı hizmetleri dağıtılırken sorunlara neden olabilir.

• Kapsayıcı görüntülerinizi Azure Container Registry'de depolayın ve kayıt defterini her AKS bölgesine coğrafi olarak çoğaltın.

• Üretim iş yüklerini barındıran tüm kümeler için finansal olarak yedeklenmiş, daha yüksek bir SLA'yı etkinleştirmek için Çalışma Süresi SLA'sını kullanın. Çalışma süresi SLA’sı, Kullanılabilirlik Alanlarını kullanan kümeler için Kubernetes API sunucusu uç noktasının % 99,95 oranında, Kullanılabilirlik Alanlarını kullanmayan kümeler için % 99,9 oranında kullanılabilirliği garanti eder. Düğümleriniz, düğüm havuzlarınız ve diğer kaynaklarınız SLA kapsamındadır. AKS, kontrol düzlemi bileşenleri için %99,5 hizmet düzeyi hedefine (SLO) sahip ücretsiz bir katman sunar. Çalışma Süresi SLA'sı etkinleştirilmemiş kümeler üretim iş yükleri için kullanılmamalıdır.

• Azure ExpressRoute bağlantısı için birden çok bölge ve eşleme konumu kullanın.

  Azure bölgesini veya eşleme sağlayıcısı konumunu etkileyen bir kesinti oluşursa, yedekli karma ağ mimarisi kesintisiz şirket içi bağlantı sağlanmasına yardımcı olabilir.

• Genel sanal ağ eşlemesi ile bölgeler arasında bağlantı kurma. Kümelerin birbirleriyle konuşması gerekiyorsa, her iki sanal ağı birbirine bağlamak sanal ağ eşlemesi aracılığıyla gerçekleştirilebilir. Bu teknoloji sanal ağları birbirine bağlayarak Farklı coğrafi bölgelerde bile Microsoft'un omurga ağı genelinde yüksek bant genişliği sağlar.

• Bölünmüş TCP tabanlı herhangi bir noktaya yayın protokolünün kullanıldığı Azure Front Door, son kullanıcılarınızın en yakın Front Door iletişim noktasına hemen bağlanmasını sağlar. Azure Front Door'un diğer özellikleri şunlardır:

  • TLS sonlandırma
  • Özel etki alanı
  • Web Uygulaması Güvenlik Duvarı
  • URL yeniden yazma
  • Oturum benzeşimi

  En uygun çözümü öğrenmek için uygulama trafiğinizin gereksinimlerini gözden geçirin.