Container Service for Kubernetes:Scheduling FAQ

Sanal anahtardaki yetersiz IP adresleri nedeniyle Pod başlatma hatalarını nasıl önlerim?

Yerel Kubernetes zamanlayıcı, bir düğümde bulunan kullanılabilir IP adreslerini göremez. IP kaynakları tükenmiş düğümlere zamanlanan pod'lar başlatma aşamasında başarısız olur ve bu durum genellikle çok sayıda anormal pod oluşmasına neden olur.

ACK Zamanlayıcı, bu sorunu IP farkındalıklı zamanlama ile çözer. Her düğümdeki k8s.aliyun.com/max-available-ip ek açıklamasını okuyarak bağımsız bir IP gerektiren pod sayısını sınırlar. Bir düğümün IP kaynakları bittiğinde, ACK Zamanlayıcı düğümün durumunda SufficientIP koşulunu ayarlar ve yeni IP bağımlı pod'ların o düğüme zamanlanmasını engeller.

kube-scheduler eklentisi bu özelliği otomatik olarak etkinleştirir. Kümenizin aşağıdaki gereksinimleri karşılaması gerekir:

• Küme, Terway v1.5.7 veya sonraki bir sürümü çalıştıran ACK yönetilen küme Pro Edition olmalıdır. Bkz. ACK yönetilen küme oluşturma.

• kube-scheduler sürümü aşağıdaki gereksinimleri karşılar:

ACK Zamanlayıcının varsayılan zamanlama ilkesi nedir?

ACK Zamanlayıcı, topluluk Kubernetes zamanlayıcısı ile aynı varsayılan ilkeyi izler. Zamanlama iki adımdan oluşur:

• **Filtreleme:** Pod'un çalıştırılamayacağı düğümleri eler. Filtrelemeden geçen hiçbir düğüm yoksa pod zamanlanamaz durumda kalır.

• **Puanlama:** Kalan düğümleri sıralar ve pod için en uygun olanı seçer.

En son ACK Zamanlayıcıda etkinleştirilen tüm Filtreleme ve Puanlama eklentileri kube-scheduler bölümünde listelenmiştir.

Pod'ların yüksek kaynak kullanımına sahip düğümlere zamanlanmasını nasıl önlerim?

Yerel Kubernetes zamanlayıcı, gerçek kullanımı değil kaynak isteklerini kullanır. Bu durum, bazı düğümlerin aşırı yüklenmesine neden olurken diğerlerinin boşta kalmasına yol açabilir. ACK üç yaklaşım sunar:

• Doğru kaynak istekleri ve sınırları ayarlayın. Geçmiş kullanıma dayalı konteyner teknik özellikleri önerileri için kaynak profil oluşturma özelliğini kullanın.

• Yük farkındalıklı zamanlamayı etkinleştirin. ACK Zamanlayıcı, gerçek düğüm yükünü dikkate alır, geçmiş verileri analiz eder, gelen pod gereksinimlerini tahmin eder ve pod'ları daha düşük kullanıma sahip düğümlere yerleştirir. Bkz. Yük farkındalıklı zamanlama.

• Yük farkındalıklı sıcak nokta yeniden zamanlamayı etkinleştirin. Trafik ve iş yükleri değiştikçe bazı düğümler aşırı yüklenebilir. ACK'nin yeniden zamanlayıcısı sıcak noktaları algılar ve dengeyi sağlamak için pod'ları tahliye eder. Bkz. Yük farkındalıklı sıcak nokta yeniden zamanlama kullanma.

Kümeeye yeni bir düğüm eklendi. Neden pod'lar buna zamanlanmıyor?

Aşağıdakileri sırayla kontrol edin:

1. Düğüm durumu: Zamanlayıcı NotReady düğümlerini atlar. Düğümün Ready durumuna gelmesini bekleyin.

2. Pod üzerindeki zamanlama kısıtlamaları: Pod üzerinde nodeSelector, nodeAffinity veya podAffinity kuralları olup olmadığını veya pod'un tolere etmediği düğüm lekelerini kontrol edin.

3. Kaynak isteği dengesizliği: Zamanlayıcı gerçek kullanımı değil kaynak isteklerini kullanır. Mevcut düğümlerde yeterli boş istenen kapasite varsa yeni düğüm kullanılmayabilir. Bkz. Pod'ların yüksek kaynak kullanımına sahip düğümlere zamanlanmasını nasıl önlerim?.

Genel küme kullanımı yüksek olmadığında neden yetersiz CPU veya bellek nedeniyle zamanlama başarısız oluyor?

Zamanlayıcı gerçek tüketimi değil istenen kaynakları değerlendirir. CPU kullanımı düşük olan bir düğüm, pod'ları yüksek kaynak isteklerine sahipse "dolu" görünebilir. Küme genelinde kullanım düşük olsa bile, yeni pod için yeterli istenen kapasiteye sahip tek bir düğüm bulunmadığında zamanlama başarısız olur.

Bkz. Pod'ların yüksek kaynak kullanımına sahip düğümlere zamanlanmasını nasıl önlerim?.

ACK'de yeniden zamanlamayı kullanmadan önce neleri bilmeliyim? Pod'ları yeniden başlatır mı?

ACK, Koordinator Descheduler aracılığıyla yeniden zamanlama sağlar. Akılda tutulması gereken iki husus vardır:

• Yeniden zamanlama yalnızca pod'ları tahliye eder. Koordinator Descheduler çalışan pod'ları tahliye eder ancak bunları yeniden oluşturmaz. İş yükü denetleyicisi (Deployment, StatefulSet vb.) yeniden oluşturmayı gerçekleştirir ve zamanlayıcı yeni pod'u yerleştirir.

• Yeterli çoğaltma sayısını koruyun. Eski pod, yeni pod başlamadan önce tahliye edilir. Tahliye sırasında kullanılabilirliğin korunması için iş yükünüzde yeterli replicas bulunduğundan emin olun.

Bkz. Yeniden zamanlama.

Bir uygulamayı belirli bir düğüme nasıl zamanlarım?

Hedef düğüme bir etiket ekleyin ve uygulamanızın pod spesifikasyonuna eşleşen bir nodeSelector ekleyin. Bkz. Uygulamayı belirli bir düğüme zamanlama.

Bir Deployment içinde, belirli sayıda pod'u ECS'ye ve belirli sayıda pod'u ECI'ye nasıl zamanlarım?

ECS ve ECI için ayrı alt kümeler tanımlamak üzere UnitedDeployment kullanın. Örneğin, ECS alt kümesinde replicas: 10 ve ECI alt kümesinde replicas: 10 ayarlayın. Bkz. UnitedDeployment'a göre iş yüklerini ölçeklendirme.

Zamanlama sırasında bir iş yükünün pod'ları için yüksek kullanılabilirliği nasıl sağlarım?

Pod'ları alanlar veya düğümler arasında yaymak için podAntiAffinity kullanın. Örneğin, aşağıdaki yapılandırma security=S2 etiketine sahip pod'ları farklı alanlara zamanlar. Kısıtlama karşılanamazsa zamanlayıcı diğer düğümlere geri döner.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

Kubernetes belgeleri ayrıca Pod yakınlığı ve anti-yakınlığı ve Pod topoloji yayılım kısıtlamalarını kapsar.

ack-descheduler'ı Koordinator Descheduler'a nasıl geçirim?

ack-descheduler eklentisi kullanımdan kaldırılmıştır. Kubernetes Descheduler için kullanılan adımlarla aynı adımları kullanarak Koordinator Descheduler'a geçiş yapın. Bkz. Kubernetes Descheduler'dan Koordinator Descheduler'a geçiş ve [\[Bildirim\] ack-descheduler geçişi](t2735863.xdita#).

ACK pazar yerindeki ack-descheduler eklentisi, açık kaynaklı Kubernetes Descheduler'a dayanır. 0.20.0 ve 0.27.1 sürümleri, ilgili açık kaynaklı sürümleriyle eşleşir.

Neden bir toplu işteki tüm pod'lar en düşük yüklü düğüme zamanlanmıyor?

Tüm yeni pod'ları en düşük yüklü düğüme yerleştirmek bir sıcak nokta oluşturur. Yük farkındalıklı zamanlama eklentisi, kullanımı henüz rapor edilmemiş yeni zamanlanmış pod'lara sahip olduğunda bir düğümün puanını ayarlayarak aşırı yoğunlaşmayı önler ve yükü düğümler arasında dengeler.

Düğüm yükü dışında zamanlama sonuçlarını etkileyen başka hangi faktörler vardır?

Kubernetes zamanlayıcı, nihai düğüm sıralamasına katkıda bulunan yakınlık kuralları, topoloji yayılım kısıtlamaları ve diğerleri gibi birden çok eklenti kullanır. Gereksinimlerinize bağlı olarak eklenti puanlama ağırlıklarını ayarlayın.

Zamanlayıcıyı yükselttikten sonra eski protokolü kullanan yük farkındalıklı zamanlama özelliği hala destekleniyor mu?

Eski protokol, pod'larda alibabacloud.com/loadAwareScheduleEnabled: "true" ek açıklamasını gerektirir. ACK Zamanlayıcı geriye dönük uyumludur, bu nedenle yükseltme mevcut pod'ları bozmaz. Yükseltmeden sonra, pod başına ek açıklama yönetimini önlemek için genel yük farkındalıklı zamanlama ilkesine geçin.

Aşağıdaki tablolar, küme sürümüne göre protokol desteğini özetlemektedir.

CPU Burst yapılandırmasını etkinleştirdikten sonra pod'larım neden hala kısıtlanıyor?

CPU kısıtlamasının devam etmesine neden olabilecek birkaç koşul vardır:

• Yanlış yapılandırma formatı. Yanlış yapılandırılmış bir CPU Burst ilkesinin etkisi yoktur. Formatı doğrulayın. Bkz. Gelişmiş parametre yapılandırması.

• CPU kullanımı sınıra ulaştı. Gerçek CPU kullanımı cfsQuotaBurstPercent sınırına ulaşırsa, yetersiz fiziksel CPU kaynakları nedeniyle kısıtlama devam eder. İstek ve limit değerlerini gerçek ihtiyaçlara göre ayarlayın.

• cpu.cfs_quota_us ayarlamasında gecikme. CPU Burst, cpu.cfs_quota_us ve cpu.cfs_burst_us değerlerini değiştirir. cpu.cfs_quota_us değeri, ack-koordinator kısıtlamayı algıladıktan sonra güncellenir ve bu da bir gecikmeye neden olur. cpu.cfs_burst_us değeri hemen ayarlanır. En iyi sonuçlar için bu özelliği Alibaba Cloud Linux ile birlikte kullanın.

• Düğüm güvenlik eşiği tetiklendi. Düğüm kullanımı sharePoolThresholdPercent eşiğini aşarsa CPU Burst, cpu.cfs_quota_us değerini temel çizgiye sıfırlar. Eşiği gereksinimlerinize göre ayarlayın.

CPU Burst ilkesi için Alibaba Cloud Linux gerekli midir?

Hayır. CPU Burst, tüm Alibaba Cloud Linux ve CentOS çekirdeklerinde çalışır. ack-koordinator, daha ince taneli CPU esnekliği için çekirdek düzeyi özelliklerden yararlandığından Alibaba Cloud Linux önerilir. Bkz. cgroup v1 arayüzünde CPU Burst özelliğini etkinleştirme.

Bir uygulama Batch kaynaklarını kullandıktan sonra bellek kullanımı neden aniden artar?

Batch bellek sınırına (kubernetes.io/batch-memory) sahip konteynerler için ack-koordinator, konteyner başlatıldıktan sonra cgroup bellek sınırını ayarlar. Uygulama, ack-koordinator bunu uygulamadan önce başlangıçta cgroup sınırını okursa, olması gerekenden daha fazla bellek ayırabilir. İşletim sistemi bu belleği hemen geri almadığından, kullanım bu sınırın altına düşene kadar sınır uygulanmaz.

Bunu çözmek için uygulamayı Batch sınırının altında kalacak şekilde ayarlayın veya bellek limiti parametresinin uygulama başlatılmadan önce ayarlandığından emin olun.

Geçerli bellek sınırını (bayt cinsinden) konteyner içinde görüntüleyin:

# The unit is bytes.
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# Expected output.
1048576000

CPU çekirdek sayısı artırıldıktan sonra performans neden düşer ve CPU kısıtlaması artar?

Eski ack-slo-manager protokolünün dinamik kaynak aşırı tahsis özelliği, ack-koordinator'a yükseltildikten sonra desteklenecek mi?

Evet. ack-koordinator uyumludur. Eski protokol, pod spesifikasyonunda iki bileşen kullanır:

• alibabacloud.com/qosClass ek açıklaması

• İsteklerde ve limitlerdeki alibabacloud.com/reclaimed kaynağı

ack-koordinator her iki protokolü de tanır ve kaynak isteklerini ve kullanılabilirliğini tek tip olarak hesaplar. Eklentiyi, mevcut pod yapılandırmalarını hemen güncellemeden yükseltin.

Eski protokol desteği 30 Temmuz 2023'te sona erecektir. Kaynak parametrelerini mümkün olan en kısa sürede en son sürüme güncelleyin.

Aşağıdaki tablo, zamanlayıcı ve ack-koordinator sürümüne göre protokol desteğini göstermektedir:

Eski ack-slo-manager protokolünün CPU Burst özelliği, ack-koordinator'a yükseltildikten sonra desteklenecek mi?

Evet. Eski protokol alibabacloud.com/cpuBurst ek açıklamasını kullanır. ack-koordinator tam uyumludur ve yükseltmeyi sorunsuz şekilde gerçekleştirir.

Eski protokol desteği 30 Temmuz 2023'te sona erecektir. Mümkün olan en kısa sürede geçerli protokole geçin.

Eski ack-slo-manager protokolünün CPU QoS özelliği, ack-koordinator'a yükseltildikten sonra desteklenecek mi?

Evet. Eski protokol (0.8.0 ve önceki sürümler), CPU QoS'u alibabacloud.com/qosClass ek açıklaması aracılığıyla etkinleştirir. ack-koordinator uyumlu kalır ve koordinator.sh protokolüne kademeli geçişi destekler.

Geriye dönük uyumluluk 30 Temmuz 2023'te sona erecektir. Pod'larınızı derhal yeni protokole taşıyın.

Eski ack-slo-manager protokolünden ack-koordinator'a geçiş yaptıktan sonra konteyner bellek QoS özelliği desteklenecek mi?

Evet. Eski protokol (0.8.0 ve önceki sürümler) alibabacloud.com/qosClass ve alibabacloud.com/memoryQOS ek açıklamalarını kullanır. ack-koordinator ikisiyle de geriye dönük uyumludur.

Geriye dönük uyumluluk 30 Temmuz 2023'te sona erecektir. Mümkün olan en kısa sürede geçerli protokole geçin.

Düğüm kullanımı eşiğe ulaştı ancak pod'lar tahliye edilmiyor. Ne yapmalıyım?

Yeniden zamanlayıcı neden sık sık yeniden başlıyor?

Bu genellikle yeniden zamanlayıcının ConfigMap'inin eksik veya yanlış yapılandırıldığı anlamına gelir. ConfigMap'i düzeltin ve yeniden zamanlayıcıyı yeniden başlatın. Bkz. Gelişmiş yapılandırma parametreleri.

Yük farkındalıklı zamanlama ve sıcak nokta yeniden zamanlamayı birlikte nasıl kullanırım?

Her iki özelliği de etkinleştirin ve eşiklerini hizalayın. Bir düğümün yükü highThresholds değerini aştığında pod'lar tahliye edilir. Tahliye edilen pod'ların aynı aşırı yüklü düğüme yeniden zamanlanmasını önlemek için loadAwareThreshold değerini highThresholds ile aynı değere ayarlayın; bu durum özellikle benzer kullanıma sahip az sayıda düğüm içeren kümelerde önemlidir.

Bkz. Yük farkındalıklı zamanlama kullanma ve İlke açıklaması.

Yeniden zamanlayıcı hangi kullanım algoritmasını kullanır?

Yeniden zamanlayıcı, kullanımı kayan bir pencere üzerinden ortalar ve ortalamanın sürdürülebilir bir süre boyunca (varsayılan: ~10 dakika) eşiği aşması durumunda yalnızca tetiklenir. Bellek hesaplamaları, işletim sisteminin geri alabileceği sayfa önbelleğini dışlar. Buna karşılık, kubectl top node sayfa önbelleğini içerir. Yeniden zamanlayıcının bellek temel çizgisini görüntülemek için Alibaba Cloud Prometheus kullanın.

wrk ile stres testi sırasında sonuç "Socket errors: connect 54," gösteriyor. Ne yapmalıyım?

wrk istemcisi TCP bağlantılarını tüketti. Stres testi makinesinde TCP bağlantı yeniden kullanımını etkinleştirin.

1. TCP bağlantı yeniden kullanımının etkin olup olmadığını kontrol edin:

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   0 veya 2 çıktısı, TCP yeniden kullanımının tam olarak etkinleştirilmediğini gösterir.

2. TCP bağlantı yeniden kullanımını etkinleştirin:

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. wrk testini yeniden çalıştırın. Socket errors: connect 54, ... mesajı artık görünmemelidir.

Bu komutlar yalnızca stres testi makinesi için geçerlidir. Testten sonra orijinal ayarı sysctl -w net.ipv4.tcp_tw_reuse=<original_value> komutuyla geri yükleyin.

Neden k8s-reclaimed-resource sekmesindeki küme birlikte yerleştirme faydaları bölümünde veri görüntülenmiyor?

1. ack-koordinator'un yüklü olduğunu doğrulayın:

   1. ACK konsolu oturumunu açın. Sol gezinme bölmesinde Clusters öğesini tıklayın.

   2. Küme adını tıklayın. Sol gezinme bölmesinde Applications > Helm seçeneğini belirleyin.

   3. Helm sayfasında ack-koordinator'un listelenip listelenmediğini kontrol edin. Listelenmiyorsa yükleyin. Bkz. Eklentileri yükleme ve yönetme.

2. Birlikte yerleştirme panosu veri göstermiyorsa kube_node_labels ölçümünün toplandığını doğrulayın:

   1. ARMS konsolu oturumunu açın.

   2. Sol gezinme bölmesinde Managed Service for Prometheus > Instances seçeneğini belirleyin.

   3. Bölgeyi seçin, Prometheus örnek adını tıklayın ve Metric Management öğesini tıklayın.

   4. Metrics öğesini tıklayın, kube_node_labels araması yapın ve ölçümün veri içerdiğini doğrulayın.

Arm tabanlı öncelikli kesintiye uğrayan örnekleri kullanabilir miyim?

Evet. Bkz. Spot örnekleri kullanma.

Bir ACK kümesinde Arm tabanlı düğümler kullanmanın sınırlamaları nelerdir?

Add-ons sayfasında yalnızca aşağıdaki eklenti kategorileri Arm mimarisini destekler:

• Çekirdek bileşenler

• Günlük kaydı ve izleme

• Depolama

• Ağ

Pazar yerinden alınan eklentiler Arm mimarisini desteklemez.