Azure Kubernetes Service (AKS) içindeki temel Zamanlayıcı özellikleri için en iyi yöntemler
Azure Kubernetes Service (AKS) içindeki kümeleri yönetirken, genellikle takımları ve iş yüklerini yalıtmanız gerekir. 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:
- Takımlara veya iş yüklerine sabit miktarda kaynak sağlamak için kaynak kotalarını kullanın
- Pod kesinti bütçelerini kullanarak zamanlanan bakımın etkisini sınırlayın
Kaynak kotalarını zorla
En iyi yöntemler kılavuzu
Ad alanı düzeyinde kaynak kotalarını planlayın ve uygulayın. Pod kaynak isteklerini ve sınırlarını tanımlamaz, dağıtımı reddedin. Kaynak kullanımını izleyin ve kotaları gerektiği şekilde ayarlayın.
Kaynak istekleri ve limitleri Pod belirtimine yerleştirilir. Sınırlar, küme içinde kullanılabilir bir düğüm bulmak için dağıtım zamanında Kubernetes Zamanlayıcı tarafından kullanılır. Sınırlar ve istekler bireysel Pod düzeyinde çalışır. Bu değerlerin nasıl tanımlanacağı hakkında daha fazla bilgi için bkz. Pod kaynak isteklerini ve sınırlarını tanımlama
Bir geliştirme takımı veya projesindeki kaynakları ayırabilmeniz ve sınırlandırmaya yönelik bir yol sağlamak için kaynak kotalarını kullanmanız gerekir. Bu kotalar bir ad alanında tanımlanmıştır ve kotaları aşağıdaki şekilde 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 yaymaz. Kümülatif kaynak isteği toplamını atanan kotayı geçtikten sonra diğer tüm dağıtımlar başarısız olur.
Kaynak kotalarını tanımlarken, ad alanı içinde oluşturulan tüm podların pod belirtimlerinde sınırlar veya istekler sağlamaları gerekir. Bu değerler sağlanmasa dağıtımı reddedebilirsiniz. Bunun yerine, bir ad alanı için varsayılan istekleri ve sınırları yapılandırebilirsiniz.
Aşağıdaki örnek YAML bildirimi dev-app-team-quotas.yaml 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ı belirterek uygulanabilir:
kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps
İhtiyaçlarını anlamak ve uygun kaynak kotalarını uygulamak için uygulama geliştiricileriniz ve sahipleriyle birlikte çalışma.
Kullanılabilir kaynak nesneleri, kapsamlar ve öncelikler hakkında daha fazla bilgi için bkz. Kubernetes'te kaynak kotaları.
Pod kesinti bütçelerini kullanarak kullanılabilirliği planlama
En iyi yöntemler kılavuzu
Uygulamaların kullanılabilirliğini korumak için, kümede en az sayıda pod kullanılabilir 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:
Istemsiz kesintiler
Istemsiz kesintiler, küme işlecinin veya uygulama sahibinin tipik denetimi dışında olan olaylardır. Içerir:
- Fiziksel makinede donanım hatası
- Çekirdek paniği
- Düğüm VM'lerini silme
Şu şekilde, istemsiz kesintiler azaltıcı olabilir:
- Bir dağıtımda, yığınlarınızın birden fazla çoğaltmasını kullanma.
- AKS kümesinde birden çok düğüm çalıştırma.
İsteyerek kesintiler
Gönüllü kesintiler , küme operatörü veya uygulama sahibi tarafından istenen olaylardır. İçeriyor
- Küme yükseltmeleri
- Dağıtım şablonu güncelleştirildi
- Yanlışlıkla Pod silme
Kubernetes gönüllü kesintiler için Pod kesinti bütçeleri sağlar ve gönüllü bir kesinti olayı gerçekleştiğinde dağıtımları veya çoğaltma kümelerinin nasıl yanıt vereceğini planlamanız için plan yapmanıza olanak sağlar. Küme işleçleri, Pod kesinti bütçelerini kullanarak kullanılabilir en düşük veya en fazla kullanılamayan kaynak sayısını tanımlayabilir.
Bir kümeyi yükseltir veya bir dağıtım şablonunu güncelleştirirseniz, Kubernetes Zamanlayıcı, isteğe bağlı kesintilere izin vermeden önce diğer düğümlerde ek düğüm zamanlar. Zamanlayıcı, tanımlanan düğüm sayısı kümedeki diğer düğümlerde başarıyla zamanlanana kadar bir düğümü yeniden başlatmayı bekler.
NGıNX çalıştıran beş Pod içeren bir çoğaltma kümesi örneğine göz atalım. Çoğaltma kümesindeki Dizin, etikete atanır app: nginx-frontend . Küme yükseltmesi gibi gönüllü bir kesinti olayı sırasında, en az üç Pod çalışmaya devam etmesini sağlamak istersiniz. Pod kesintiler için aşağıdaki YAML bildirimi, bu gereksinimleri tanımlar:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 3
selector:
matchLabels:
app: nginx-frontend
Ayrıca, küme sayısının ölçeğini ölçeklendirerek çoğaltma kümesini otomatik olarak telafi etmenizi sağlayan %60 gibi bir yüzde de tanımlayabilirsiniz.
Bir çoğaltma kümesinde kullanılamayan en fazla örnek sayısını tanımlayabilirsiniz. Ayrıca, kullanılamayan en fazla sayıda pod için bir yüzde de tanımlanabilir. Aşağıdaki Pod kesintisi bütçesi YAML bildirimi, çoğaltma kümesinde ikiden fazla sayıda Pod olmadığını tanımlar:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
maxUnavailable: 2
selector:
matchLabels:
app: nginx-frontend
Pod kesinti bütçeniz tanımlandıktan sonra, bunu AKS kümeniz içinde diğer Kubernetes nesnelerinde olduğu gibi oluştururuz:
kubectl apply -f nginx-pdb.yaml
İhtiyaçlarını anlamak ve uygun pod kesinti bütçelerini uygulamak için uygulama geliştiricileriniz ve sahipleriyle birlikte çalışma.
Pod kesinti bütçelerini kullanma hakkında daha fazla bilgi için bkz. Uygulamanıza bir kesinti bütçesi belirtme.
Sonraki adımlar
Bu makale, temel Kubernetes zamanlayıcı özelliklerine odaklandı. AKS'de küme işlemleri hakkında daha fazla bilgi için aşağıdaki en iyi yöntemlere bakın: