Aracılığıyla paylaş

Azure Kubernetes Service'te (AKS) büyük iş yükleri için performans ve ölçeklendirme için en iyi yöntemler

  • Makale

Not

Bu makale, büyük iş yükleri için genel en iyi yöntemlere odaklanmaktadır. Küçük ve orta ölçekli iş yüklerine özgü en iyi yöntemler için bkz. Azure Kubernetes Service'te (AKS) küçük ve orta ölçekli iş yükleri için performans ve ölçeklendirme en iyi yöntemleri.

AKS'de kümeleri dağıtır ve korurken, performansı ve ölçeklendirmeyi iyileştirmenize yardımcı olması için aşağıdaki en iyi yöntemleri kullanabilirsiniz.

Büyük ifadesinin göreli bir terim olduğunu unutmayın. Kubernetes'te çok boyutlu bir ölçek zarfı vardır ve iş yükünüz için ölçek zarfı kullandığınız kaynaklara bağlıdır. Örneğin, 100 düğüm ve binlerce pod veya CRD içeren bir küme büyük kabul edilebilir. 1.000 pod ve diğer çeşitli kaynaklara sahip 1.000 düğümlü bir küme, denetim düzlemi açısından küçük kabul edilebilir. Kubernetes denetim düzleminin ölçeği için en iyi sinyal API sunucusu HTTP isteği başarı oranı ve gecikme süresidir çünkü bu, denetim düzlemi üzerindeki yük miktarı için bir ara sunucudur.

Bu makalede şunları öğreneceksiniz:

  • AKS ve Kubernetes, düzlem ölçeklenebilirliğini denetler.
  • Geri alma, saatler ve sayfalandırma da dahil olmak üzere Kubernetes İstemcisi en iyi yöntemleri.
  • Azure API ve platform azaltma sınırları.
  • Özellik sınırlamaları.
  • Ağ ve düğüm havuzu ölçeklendirme en iyi yöntemleri.

AKS ve Kubernetes kontrol düzlemi ölçeklenebilirliği

AKS'de bir küme , Kubernetes aracılarını çalıştıran ve AKS tarafından barındırılan Kubernetes denetim düzlemi tarafından yönetilen bir düğüm kümesinden (fiziksel veya sanal makineler (VM)) oluşur. AKS, Kubernetes denetim düzlemini ve bileşenlerini ölçeklenebilirlik ve performans için iyileştirse de, yine de yukarı akış proje sınırlarına bağlıdır.

Kubernetes'in her kaynak türü bir boyutu temsil eden çok boyutlu bir ölçek zarfı vardır. Tüm kaynaklar aynı değildir. Örneğin, saatler genellikle gizli diziler üzerinde ayarlanır ve bu da kube-apiserver'a maliyet ekleyen liste çağrılarına ve denetim düzleminde saatsiz kaynaklara kıyasla orantısız olarak daha yüksek yüke neden olur.

Denetim düzlemi kümedeki tüm kaynak ölçeklendirmesini yönetir, böylece kümeyi belirli bir boyut içinde ne kadar çok ölçeklendirirseniz, diğer boyutlar içinde o kadar az ölçeklendirme yapabilirsiniz. Örneğin, bir AKS kümesinde yüz binlerce pod çalıştırmak, kontrol düzleminin ne kadar pod değişim hızını (saniyede pod mutasyonları) destekleyeebileceğini etkiler.

Zarfın boyutu Kubernetes kontrol düzleminin boyutuyla orantılıdır. AKS, Temel SKU'nun bir parçası olarak üç denetim düzlemi katmanını destekler: Ücretsiz, Standart ve Premium katmanı. Daha fazla bilgi için bkz . AKS küme yönetimi için Ücretsiz, Standart ve Premium fiyatlandırma katmanları.

Önemli

Üretim veya ölçekli iş yükleri için Standart veya Premium katmanını kullanmanızı kesinlikle öneririz. AKS, aşağıdaki ölçek sınırlarını desteklemek için Kubernetes denetim düzleminin ölçeğini otomatik olarak genişletir:

  • AKS kümesi başına en fazla 5.000 düğüm
  • AKS kümesi başına 200.000 pod (Azure CNI Katmanı ile)

Çoğu durumda ölçek sınırı eşiğinin aşılması performansın düşmesine neden olur, ancak kümenin hemen yük devretmesine neden olmaz. Kubernetes denetim düzlemindeki yükü yönetmek için geçerli ölçeğin %10-20'sine kadar toplu ölçeklendirmeyi göz önünde bulundurun. Örneğin, 5.000 düğümlü bir küme için, 500-1.000 düğüm artışlarıyla ölçeklendirin. AKS kontrol düzleminizi otomatik olarak ölçeklendirse de anında gerçekleşmez.

Yüksek değişim sıklığı ve yükleme sırasında denetim düzlemini korumak üzere belirli istemcileri ve istek türlerini kısıtlamak için API Önceliği ve Eşitliği 'ni (APF) kullanabilirsiniz.

Kubernetes istemcileri

Kubernetes istemcileri, kube-api sunucusuyla okuma veya mutat işlemleri gerçekleştirmek için iletişim kurması gereken Kubernetes kümesinde dağıtılan işleçler veya izleme aracıları gibi uygulama istemcileridir. Kube-api sunucusuna ve Kubernetes denetim düzlemine ekledikleri yükü en aza indirmek için bu istemcilerin davranışını iyileştirmek önemlidir.

Kube Denetim günlükleri aracılığıyla API sunucusu trafiğini ve istemci davranışını analiz edebilirsiniz. Daha fazla bilgi için bkz . Kubernetes denetim düzleminde sorun giderme.

LIST istekleri pahalı olabilir. Birkaç binden fazla küçük nesne veya birkaç yüzden fazla büyük nesne içeren listelerle çalışırken aşağıdaki yönergeleri dikkate almanız gerekir:

  • Yeni bir kaynak türü (CRD) tanımlarken sonunda var olmasını beklediğiniz nesne sayısını (CR) göz önünde bulundurun.
  • etcd ve API sunucusu üzerindeki yük öncelikle döndürülen nesne sayısına değil, var olan nesne sayısına bağlıdır. Listeyi filtrelemek ve yalnızca az sayıda sonuç almak için alan seçici kullansanız bile, bu yönergeler geçerli olmaya devam eder. Tek özel durum, tarafından metadata.nametek bir nesnenin alınmasıdır.
  • Kodunuzun bellekteki nesnelerin güncelleştirilmiş bir listesini tutması gerekiyorsa mümkünse yinelenen LIST çağrılarından kaçının. Bunun yerine, çoğu Kubernetes kitaplığında sağlanan Informer sınıflarını kullanmayı göz önünde bulundurun. Bilgilendiriciler, bellek içi koleksiyonu verimli bir şekilde korumak için LIST ve WATCH işlevlerini otomatik olarak birleştirir.
  • Bilgilendiriciler ihtiyaçlarınızı karşılamıyorsa güçlü tutarlılık gerekip gerekmediğini göz önünde bulundurun. Sorguyu yayımladığınız zamana kadar en son verileri görmeniz gerekiyor mu? Aksi takdirde ayarlayın ResourceVersion=0. Bu, API sunucusu önbelleğinin etcd yerine isteğinize hizmet vermesine neden olur.
  • Bilgilendiricileri veya API sunucusu önbelleğini kullanamıyorsanız büyük listeleri öbekler halinde okuyun.
  • Gerektiğinden daha sık listelemekten kaçının. Bilgilendiricileri kullanamıyorsanız uygulamanızın kaynakları ne sıklıkta listelediğini göz önünde bulundurun. Büyük bir listedeki son nesneyi okuduktan sonra, aynı listeyi hemen yeniden sorgulamayın. Bunun yerine biraz beklemelisiniz.
  • İstemci uygulamanızın çalışan örneklerinin sayısını göz önünde bulundurun. Nesneleri listeleyen tek bir denetleyici ile her düğümde aynı şeyi yapan podların olması arasında büyük bir fark vardır. İstemci uygulamanızın çok sayıda nesneyi düzenli aralıklarla listeleyen birden çok örneğini almayı planlıyorsanız çözümünüz büyük kümelere ölçeklendirilmeyecektir.

Azure API ve Platform azaltma

Bulut uygulamasındaki yük, etkin kullanıcı sayısı veya kullanıcıların gerçekleştirdiği eylem türleri gibi faktörlere bağlı olarak zaman içinde değişebilir. Sistemin işleme gereksinimleri kullanılabilir kaynakların kapasitesini aşarsa, sistem aşırı yüklenebilir ve düşük performans ve hatalardan muzdarip olabilir.

Bir bulut uygulamasındaki değişen yük boyutlarını işlemek için uygulamanın belirtilen sınıra kadar olan kaynakları kullanmasına izin verebilir ve sınıra ulaşıldığında bunları kısıtlayabilirsiniz. Azure'da azaltma iki düzeyde gerçekleşir. Azure Resource Manager (ARM), abonelik ve kiracı isteklerini kısıtlar. İstek, abonelik ve kiracı için azaltma sınırları altındaysa ARM, isteği kaynak sağlayıcısına yönlendirir. Kaynak sağlayıcısı daha sonra işlemlerine göre uyarlanmış azaltma sınırları uygular. Daha fazla bilgi için bkz . ARM azaltma istekleri.

AKS'de azaltmayı yönetme

Azure API sınırları genellikle abonelik bölgesi birleşim düzeyinde tanımlanır. Örneğin, belirli bir bölgedeki bir abonelikteki tüm istemciler, put API'Sanal Makine Ölçek Kümeleri leri gibi belirli bir Azure API'sine yönelik API sınırlarını paylaşır. Her AKS kümesinin bulut sağlayıcısı veya küme otomatik ölçeklendiricisi gibi AKS'ye ait birkaç istemcisi ya da Azure API'lerini çağıran Datadog veya şirket içinde barındırılan Prometheus gibi müşteriye ait istemcileri vardır. Belirli bir bölgedeki bir abonelikte birden çok AKS kümesi çalıştırırken, kümelerdeki AKS'ye ait ve müşteriye ait tüm istemciler ortak bir API sınırları kümesini paylaşır. Bu nedenle, bir abonelik bölgesinde dağıtabileceğiniz küme sayısı, dağıtılan istemci sayısının, bunların çağrı desenlerinin ve kümelerin genel ölçeğinin ve esnekliğinin bir işlevidir.

Yukarıdaki noktaları göz önünde bulundurarak müşteriler genellikle abonelik bölgesi başına 20-40 küçük ila orta ölçekli küme dağıtabilir. Aşağıdaki en iyi yöntemleri kullanarak abonelik ölçeğinizi en üst düzeye çıkarabilirsiniz:

Kubernetes kümelerinizi her zaman en son sürüme yükseltin. Daha yeni sürümler, performans ve azaltma sorunlarını ele alan birçok geliştirme içerir. Kubernetes'in yükseltilmiş bir sürümünü kullanıyorsanız ve hala gerçek yük veya abonelikteki istemci sayısı nedeniyle azaltma görüyorsanız, aşağıdaki seçenekleri deneyebilirsiniz:

  • AKS Tanılama ve Çözme Sorunlarını Kullanarak Hataları Çözümleme: Aks Tanılama ve Sorunları Çözme'yi kullanarak hataları analiz edebilir, kök nedeni tanımlayabilir ve çözüm önerileri alabilirsiniz.
    • Küme Otomatik Ölçeklendiricisi tarama aralığını artırma: Tanılama raporları Küme Otomatik Ölçeklendiricisi azaltmanın algılandığını gösteriyorsa, Küme Otomatik Ölçeklendiricisi'nden Sanal Makine Ölçek Kümeleri çağrı sayısını azaltmak için tarama aralığını artırabilirsiniz.
    • Daha az çağrı yapmak için üçüncü taraf uygulamaları yeniden yapılandırın: görünüm isteği hızı ve azaltma ayrıntıları tanılamasında kullanıcı aracılarına göre filtreleme yaparsanız ve izleme uygulaması gibi üçüncü taraf bir uygulamanın çok sayıda GET isteği yaptığını görürseniz, GET çağrılarının sıklığını azaltmak için bu uygulamaların ayarlarını değiştirebilirsiniz. Uygulama istemcilerinin Azure API'lerini çağırırken üstel geri alma kullandığından emin olun.
  • Kümelerinizi farklı aboneliklere veya bölgelere bölün: Sanal Makine Ölçek Kümeleri kullanan çok sayıda kümeniz ve düğüm havuzunuz varsa, bunları aynı abonelik içindeki farklı aboneliklere veya bölgelere bölebilirsiniz. Azure API sınırlarının çoğu abonelik bölgesi düzeyinde paylaşıldığından, Azure API azaltmasının engelini kaldırmak için kümelerinizi farklı aboneliklere veya bölgelere taşıyabilir veya ölçeklendikleyebilirsiniz. Kümelerinizin yüksek etkinlik olmasını bekliyorsanız bu seçenek özellikle yararlıdır. Bu sınırlar için genel yönergeler yoktur. Belirli bir rehberlik istiyorsanız bir destek bileti oluşturabilirsiniz.

Özellik sınırlamaları

AKS kümelerinizi daha büyük ölçek noktalarına ölçeklendirirken aşağıdaki özellik sınırlamalarını göz önünde bulundurun:

Not

Denetim düzlemini ölçeklendirme işlemi sırasında 15 dakikaya kadar yükseltilmiş API sunucusu gecikme süresi veya zaman aşımlarıyla karşılaşabilirsiniz. Desteklenen sınıra ölçeklendirme konusunda sorun yaşamaya devam ederseniz bir destek bileti açın.

  • Azure Ağ İlkesi Yöneticisi (Azure npm) en fazla 250 düğümü destekler.
  • Düğüm diski kullanımı, düğüm CPU/bellek kullanımı ve ağ giriş/çıkış dahil olmak üzere bazı AKS düğümü ölçümlerine, denetim düzlemi ölçeklendirildikten sonra Azure İzleyici platformu ölçümlerinde erişilemez. Denetim düzleminizin ölçeğinin artırılıp artırıldığını onaylamak için 'control-plane-scaling-status' yapılandırma haritasını arayın
kubectl describe configmap control-plane-scaling-status -n kube-system
  • Durdur ve Başlat özelliğini 100'den fazla düğümü olan kümelerle kullanamazsınız. Daha fazla bilgi için bkz . AKS kümesini durdurma ve başlatma.

Ağ

AKS kümelerinizi daha büyük ölçek noktalarına ölçeklendirirken aşağıdaki ağ en iyi yöntemlerini göz önünde bulundurun:

  • NAT ağ geçidinde en az iki genel IP ile küme çıkışı için Yönetilen NAT kullanın. Daha fazla bilgi için bkz . AKS kümeniz için yönetilen NAT ağ geçidi oluşturma.
  • Küme başına 200.000 pod ve 5.000 düğüme kadar ölçeklendirmek için Azure CNI Katman'ı kullanın. Daha fazla bilgi için bkz . AKS'de Azure CNI Katman ağını yapılandırma.
  • Uygulamanızın kümeler arasında doğrudan pod-pod iletişimine ihtiyacı varsa, dinamik IP ayırma ile Azure CNI kullanın ve pod başına bir yönlendirilebilir IP ile küme başına 50.000 uygulama pod'una kadar ölçeklendirin. Daha fazla bilgi için bkz . AKS'de dinamik IP ayırma için Azure CNI ağını yapılandırma.
  • İç yük dengeleyicinin arkasındaki iç Kubernetes hizmetlerini kullanırken, en iyi ölçeklendirme performansı ve yük dengeleyici esnekliği için 750 düğüm ölçeğinin altında bir iç yük dengeleyici veya hizmet oluşturmanızı öneririz.
  • Azure npm yalnızca 250 düğüme kadar destekler. Daha büyük kümeler için ağ ilkelerini zorunlu kılmak istiyorsanız, yüksek performanslı ağ ve güvenlik sağlamak için Azure CNI'nin güçlü denetim düzlemini Cilium veri düzlemiyle birleştiren Cilium tarafından desteklenen Azure CNI kullanmayı göz önünde bulundurun.

Düğüm havuzu ölçeklendirme

AKS kümelerinizi daha büyük ölçek noktalarına ölçeklendirirken aşağıdaki düğüm havuzu ölçeklendirme en iyi yöntemlerini göz önünde bulundurun:

  • Sistem düğümü havuzları için kube sistem podları için yeterli işlem kaynağı sağlamak üzere kısa ömürlü işletim sistemi diskleriyle Standard_D16ds_v5 SKU'su veya eşdeğer bir çekirdek/bellek VM SKU'su kullanın.
  • AKS'nin düğüm havuzu başına 1.000 düğüm sınırı olduğundan, ölçeği 5.000 düğüme kadar artırmak için en az beş kullanıcı düğümü havuzu oluşturmanızı öneririz.
  • Ölçekli AKS kümelerini çalıştırırken, işlem kaynaklarına yönelik talebe göre düğüm havuzlarının dinamik olarak ölçeklendirilmesini sağlamak için mümkün olduğunca küme otomatik ölçeklendiricisini kullanın. Daha fazla bilgi için bkz . Aks kümesini uygulama taleplerini karşılayacak şekilde otomatik olarak ölçeklendirme.
  • 1.000 düğümün ötesine ölçeklendirme gerçekleştiriyorsanız ve küme otomatik ölçeklendiricisini kullanmıyorsanız , bir kerede 500-700 düğüm toplu olarak ölçeklendirmenizi öneririz. Ölçeklendirme işlemlerinin Azure API azaltmasını önlemek için ölçeği artırma işlemleri arasında iki dakika ila beş dakika bekleme süresi olmalıdır. Daha fazla bilgi için bkz. API yönetimi: Önbelleğe Alma ve azaltma ilkeleri.

Küme yükseltmesi ile ilgili dikkat edilmesi gerekenler ve en iyi yöntemler

  • Bir küme 5.000 düğüm sınırına ulaştığında, küme yükseltmeleri engellenir. Maksimum aşırı gerilim özellik sınırı içinde sıralı güncelleştirmeler gerçekleştirmek için kullanılabilir düğüm kapasitesi olmadığından bu sınırlar yükseltmeyi engeller. Bu sınırda bir kümeniz varsa, küme yükseltmeyi denemeden önce kümenin ölçeğini 3.000 düğüm altında azaltmanızı öneririz. Bu, düğüm değişim sıklığı için ek kapasite sağlar ve kontrol düzleminde yükü en aza indirir.
  • 500'den fazla düğüme sahip kümeleri yükseltirken, düğüm havuzunun kapasitesinin %10-20'sinde maksimum dalgalanma yapılandırması kullanılması önerilir. AKS, yükseltmeleri maksimum artış için %10 varsayılan değerle yapılandırıyor. Yükseltme hızı ve iş yükü kesintisi arasında dengeyi sağlamak için düğüm havuzu başına maksimum dalgalanma ayarlarını özelleştirebilirsiniz. Maksimum dalgalanma ayarlarını artırdığınızda yükseltme işlemi daha hızlı tamamlanır, ancak yükseltme işlemi sırasında kesintilerle karşılaşabilirsiniz. Daha fazla bilgi için bkz . Düğüm dalgalanması yükseltmesini özelleştirme.
  • Daha fazla küme yükseltme bilgisi için bkz . AKS kümesini yükseltme.