Azure Kubernetes Service'de (AKS) temel zamanlayıcı özellikleri için en iyi yöntemler
Azure Kubernetes Service'de (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öntemler 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 kaynağı isteklerini ve sınırlarını tanımlama.
Geliştirme ekibi veya proje genelinde kaynakları ayırmak ve sınırlamak için kaynak kotalarını kullanmanız gerekir. Bu kotalar bir ad alanında tanımlanır ve kotaları aşağıdaki temellere göre 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 kaynakları aşırı kullanmaz. Toplu 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öntemler 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. Içerir:
- 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. Içerir:
- Küme yükseltmeleri
- Güncelleştirilmiş dağıtım şablonu
- Yanlışlıkla bir 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 en fazla kullanılamayan kaynak sayısı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 verilmeden ö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 bakalı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 de tanımlayabilirsiniz; bu da çoğaltma kümesinin pod sayısını ölçeklendirmesini otomatik olarak telafi etmenizi sağlar.
Bir çoğaltma kümesinde kullanılamayan en fazla örnek sayısını 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ümesindeki ikiden fazla pod'un kullanılamayacağını tanımlar:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
maxUnavailable: 2
selector:
matchLabels:
app: nginx-frontend
Pod kesinti 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: