Azure Kubernetes Service'teki (AKS) temel zamanlayıcı özellikleri için en iyi yöntemler

Makale
08/02/2024

Azure Kubernetes Service'te (AKS) kümeleri yönetirken genellikle ekipleri ve iş yüklerini yalıtmalısınız. Kubernetes zamanlayıcı, işlem kaynaklarının dağıtımını denetlemenize veya bakım olaylarının etkisini sınırlamanıza olanak tanır.

Bu en iyi yöntemler makalesi, küme işleçleri için temel Kubernetes zamanlama özelliklerine odaklanır. Bu makalede şunları öğreneceksiniz:

Ekiplere veya iş yüklerine sabit miktarda kaynak sağlamak için kaynak kotalarını kullanma
Pod kesintisi bütçelerini kullanarak zamanlanmış bakımın etkisini sınırlama

Kaynak kotalarını zorunlu kılma

En iyi yöntem kılavuzu

Kaynak kotalarını ad alanı düzeyinde planlayın ve uygulayın. Podlar kaynak isteklerini ve sınırlarını tanımlamıyorsa dağıtımı reddedin. Kaynak kullanımını izleyin ve kotaları gerektiği gibi ayarlayın.

Kaynak istekleri ve sınırları pod belirtimine yerleştirilir. İstekler, Kubernetes zamanlayıcı tarafından kümede kullanılabilir bir düğümü bulmak için dağıtım zamanında kullanılır. Sınırlar ve istekler tek tek pod düzeyinde çalışır. Bu değerleri tanımlama hakkında daha fazla bilgi için bkz . Pod kaynak isteklerini ve sınırlarını tanımlama.

Geliştirme ekibi veya proje genelinde kaynakları ayırmanın ve sınırlamanın bir yolunu sağlamak için kaynak kotalarını kullanmanız gerekir. Bu kotalar bir ad alanında tanımlanır ve aşağıdaki temellere göre kotaları ayarlamak için kullanılabilir:

CPU ve bellek veya GPU'lar gibi işlem kaynakları.
Belirli bir depolama sınıfı için toplam birim sayısı veya disk alanı miktarı dahil olmak üzere depolama kaynakları.
En fazla gizli dizi, hizmet veya iş sayısı gibi nesne sayısı oluşturulabilir.

Kubernetes fazla kaynak kullanmaz. Birikmeli kaynak isteği toplamınız atanan kotayı geçtikten sonra diğer tüm dağıtımlar başarısız olur.

Kaynak kotalarını tanımladığınızda, ad alanında oluşturulan tüm podların pod belirtimlerinde sınırlar veya istekler sağlaması gerekir. Bu değerleri sağlamazlarsa dağıtımı reddedebilirsiniz. Bunun yerine, bir ad alanı için varsayılan istekleri ve sınırları yapılandırabilirsiniz.

Dev-app-team-quotas.yaml adlı aşağıdaki örnek YAML bildirimi, toplam 10 CPU, 20Gi bellek ve 10 pod için sabit bir sınır ayarlar:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

Bu kaynak kotası, dev-apps gibi ad alanı belirtilerek uygulanabilir:

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

Gereksinimlerini anlamak ve uygun kaynak kotalarını uygulamak için uygulama geliştiricilerinizle ve sahiplerinizle birlikte çalışın.

Kullanılabilir kaynak nesneleri, kapsamları ve öncelikleri hakkında daha fazla bilgi için bkz . Kubernetes'te kaynak kotaları.

Pod kesintisi bütçelerini kullanarak kullanılabilirliği planlama

En iyi yöntem kılavuzu

Uygulamaların kullanılabilirliğini korumak için, kümede en az sayıda pod olduğundan emin olmak için Pod Kesinti bütçeleri (PDB) tanımlayın.

Podların kaldırılmasına neden olan iki kesintiye neden olan olay vardır:

İstemsiz kesintiler

İstemsiz kesintiler , küme işlecinin veya uygulama sahibinin tipik denetiminin ötesindeki olaylardır. Kapsamak:

Fiziksel makinede donanım hatası
Çekirdek paniği
Düğüm VM'sini silme

İstemsiz kesintiler şu şekilde azaltılabilir:

Dağıtımda podlarınızın birden çok çoğaltmasını kullanma.
AKS kümesinde birden çok düğüm çalıştırma.

Gönüllü kesintiler

Gönüllü kesintiler , küme operatörü veya uygulama sahibi tarafından istenen olaylardır. Kapsamak:

Küme yükseltmeleri
Güncelleştirilmiş dağıtım şablonu
Yanlışlıkla pod silme

Kubernetes, gönüllü kesintiler için pod kesintisi bütçeleri sağlayarak, gönüllü bir kesinti olayı gerçekleştiğinde dağıtımların veya çoğaltma kümelerinin nasıl yanıt vereceğini planlamanıza olanak sağlar. Küme işleçleri pod kesintisi bütçelerini kullanarak kullanılabilir en düşük veya kullanılamayan kaynak sayısı üst sınırını tanımlayabilir.

Bir kümeyi yükseltir veya dağıtım şablonunu güncelleştirirseniz Kubernetes zamanlayıcı, gönüllü kesinti olaylarının devam etmesi için izin vermeden önce diğer düğümlerde ek podlar zamanlar. Zamanlayıcı, kümedeki diğer düğümlerde tanımlanan pod sayısı başarıyla zamanlanana kadar düğümü yeniden başlatmayı bekler.

Şimdi NGINX çalıştıran beş pod içeren bir çoğaltma kümesi örneğine göz atalım. Çoğaltma kümesindeki podlara etiketi app: nginx-frontendatanır. Küme yükseltmesi gibi gönüllü bir kesinti olayı sırasında en az üç pod'un çalışmaya devam ettiğinden emin olmak istersiniz. PodDisruptionBudget nesnesi için aşağıdaki YAML bildirimi bu gereksinimleri tanımlar:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: nginx-pdb
spec:
   minAvailable: 3
   selector:
    matchLabels:
      app: nginx-frontend

Ayrıca,% 60 gibi bir yüzde tanımlayabilirsiniz; bu da pod sayısını ölçeklendiren çoğaltma kümesini otomatik olarak telafi etmenizi sağlar.

Bir çoğaltma kümesinde en fazla sayıda kullanılamayan örnek tanımlayabilirsiniz. Yine, kullanılamayan pod sayısı üst sınırı için bir yüzde de tanımlanabilir. Aşağıdaki pod kesinti bütçesi YAML bildirimi, çoğaltma kümesinde en fazla iki pod kullanılamayacağını tanımlar:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: nginx-pdb
spec:
   maxUnavailable: 2
   selector:
    matchLabels:
      app: nginx-frontend

Pod kesintisi bütçeniz tanımlandıktan sonra, diğer Kubernetes nesnelerinde olduğu gibi AKS kümenizde oluşturursunuz:

kubectl apply -f nginx-pdb.yaml

Gereksinimlerini anlamak ve uygun pod kesintisi bütçelerini uygulamak için uygulama geliştiricilerinizle ve sahiplerinizle birlikte çalışın.

Pod kesintisi bütçelerini kullanma hakkında daha fazla bilgi için bkz . Uygulamanız için kesinti bütçesi belirtme.

Sonraki adımlar

Bu makale temel Kubernetes zamanlayıcı özelliklerine odaklanmıştır. AKS'deki küme işlemleri hakkında daha fazla bilgi için aşağıdaki en iyi yöntemlere bakın:

Aracılığıyla paylaş