Aracılığıyla paylaş

İyi durumdaki bir düğümün Hazır Değil durumunda sorun giderme

  • Makale

Bu makalede, bir Azure Kubernetes Service (AKS) küme düğümünün durumunun, düğüm bir süre iyi durumda olduktan sonra Hazır Değil olarak değiştirildiği bir senaryo açıklanmıştır. Bu makalede belirli bir neden özetlenmiştir ve olası bir çözüm sağlanır.

Önkoşullar

Belirtiler

Durumu iyi durumda olan bir küme düğümünün durumu (tüm hizmetler çalışıyor) beklenmedik bir şekilde Hazır Değil olarak değişir. Düğümün durumunu görüntülemek için aşağıdaki kubectl describe komutunu çalıştırın:

kubectl describe nodes

Neden

Kubelet, Hazır durumunu göndermeyi durdurdu.

Koşullar alanını ve Capacity ve Allocatable bloklarını bulmak için komutun çıkışını kubectl describe nodes inceleyin. Bu alanların içeriği beklendiği gibi görünüyor mu? (Örneğin, Koşullar alanında özelliği "kubelet hazır durum deftere naklediliyor" dizesini içeriyor mu message ?) Bu durumda düğüme doğrudan Secure Shell (SSH) erişiminiz varsa hatayı anlamak için son olayları denetleyin. /var/log/messages dosyasının içine bakın. Veya aşağıdaki kabuk komutlarını çalıştırarak kubelet ve kapsayıcı daemon günlük dosyalarını oluşturun:

journalctl --directory=. --unit=kubelet > kubelet.log
journalctl --directory=. --unit=docker > docker.log

Bu komutları çalıştırdıktan sonra hatayla ilgili ayrıntılar için daemon günlük dosyalarını inceleyin.

1. Adım: Ağ düzeyindeki değişiklikleri denetleme

Tüm küme düğümleri Hazır Değil durumuna gerilediyse, ağ düzeyinde herhangi bir değişiklik yapılıp yapılmadığını denetleyin. Ağ düzeyindeki değişikliklere örnek olarak aşağıdaki öğeler verilebilir:

  • Etki alanı adı sistemi (DNS) değişiklikleri
  • Güvenlik duvarı bağlantı noktası değişiklikleri
  • Ağ güvenlik grupları (NSG) eklendi

Ağ düzeyinde değişiklikler yapıldıysa, gerekli düzeltmeleri yapın. Sorunları düzeltdikten sonra çalışan düğümleri durdurun ve yeniden başlatın. Bu düzeltmelerden sonra düğümler iyi durumda kalırsa, kalan adımları güvenle atlayabilirsiniz.

2. Adım: Düğümleri durdurma ve yeniden başlatma

Yalnızca birkaç düğüm Hazır Değil durumuna gerilediyse, düğümleri durdurmanız ve yeniden başlatmanız yeterlidir. Yalnızca bu eylem düğümleri iyi durumda döndürebilir. Ardından, aşağıdaki sorunlar gibi herhangi bir sorun olup olmadığını belirlemek için tanılamaya genel bakış Azure Kubernetes Service denetleyin:

  • Düğüm hataları
  • Kaynak ağ adresi çevirisi (SNAT) hataları
  • Saniye başına düğüm giriş/çıkış işlemleri (IOPS) performans sorunları
  • Diğer sorunlar

Tanılamada temel alınan herhangi bir sorun bulunamazsa, kalan adımları güvenle atlayabilirsiniz.

3. Adım: Genel AKS API kümeleri için SNAT sorunlarını düzeltme

AKS tanılaması herhangi bir SNAT sorununu ortaya çıkardı mı? Öyleyse, aşağıdaki eylemlerden uygun şekilde bazılarını gerçekleştirin:

  • Bağlantılarınızın uzun süre boşta kalıp kalmadığını denetleyin ve bağlantı noktasını serbest bırakmak için varsayılan boşta kalma zaman aşımına bağlı kalın. Bağlantılar bu davranışı sergilerse varsayılan zaman aşımı süresini 30 dakika azaltmanız gerekebilir.

  • Uygulamanızın giden bağlantıyı nasıl oluşturduğunu belirleyin. Örneğin, kod gözden geçirme veya paket yakalama kullanıyor mu?

  • Bu etkinliğin beklenen davranışı mı temsil ettiğini yoksa uygulamanın yanlış davrandığını mı gösterdiğini belirleyin. Bulgularınızı doğrulamak için Azure İzleyici'deki ölçümleri ve günlükleri kullanın. Örneğin, Başarısız kategorisini SNAT Connections ölçümü olarak kullanabilirsiniz.

  • Uygun desenlerin izlenip izlenmediğini değerlendirin.

  • Ek giden IP adresleri ve daha fazla ayrılmış giden bağlantı noktası kullanarak SNAT bağlantı noktası tükenmesini azaltmanız gerekip gerekmediğini değerlendirin. Daha fazla bilgi için bkz. Yönetilen giden genel IP'lerin sayısını ölçeklendirme ve Ayrılan giden bağlantı noktalarını yapılandırma.

4. Adım: IOPS performans sorunlarını düzeltme

AKS tanılamaları IOPS performansını düşüren sorunları ortaya çıkarırsa aşağıdaki eylemlerden bazılarını uygun şekilde gerçekleştirin:

  • Sanal makine (VM) ölçek kümelerinde IOPS'yi artırmak için yeni bir düğüm havuzu dağıtarak disk boyutunu değiştirin.

  • Daha fazla bellek ve CPU işleme özelliği için düğüm SKU boyutunu artırın.

  • Kısa ömürlü işletim sistemi kullanmayı göz önünde bulundurun.

  • Podlar için CPU ve bellek kullanımını sınırlayın. Bu sınırlar düğüm CPU tüketimini ve yetersiz bellek durumlarını önlemeye yardımcı olur.

  • Daha fazla düğüm eklemek ve yükü düğümler arasında dağıtmak için zamanlama topolojisi yöntemlerini kullanın. Daha fazla bilgi için bkz. Pod topolojisi yayma kısıtlamaları.

5. Adım: İş parçacığı oluşturma sorunlarını düzeltme

Kubelet'ler ve kapsayıcılı çalışma zamanları gibi Kubernetes bileşenleri, iş parçacığı oluşturma işlemini yoğun bir şekilde kullanır ve düzenli olarak yeni iş parçacıkları oluşturur. Yeni iş parçacıklarının ayrılması başarısız olursa, bu hata aşağıdaki gibi hizmet hazırlığını etkileyebilir:

  • Düğüm durumu Hazır Değil olarak değişir, ancak bir düzeltici tarafından yeniden başlatılır ve kurtarılır.

  • /var/log/messages ve /var/log/syslog günlük dosyalarında, aşağıdaki hata girişlerinin yinelenen tekrarları vardır:

    pthread_create başarısız oldu: Kaynak çeşitli işlemler tarafından geçici olarak kullanılamıyor

    Belirtilen işlemler kapsayıcılı ve muhtemelen kubelet'i içerir.

  • Düğüm durumu, hata girişleri günlük dosyalarına pthread_create yazıldıktan hemen sonra Hazır Değil olarak değişir.

İşlem kimlikleri (PID) iş parçacıklarını temsil eder. Bir podun kullanabileceği varsayılan PID sayısı işletim sistemine bağlı olabilir. Ancak varsayılan sayı en az 32.768'dir. Bu miktar çoğu durum için fazlasıyla yeterli PID'dir. Daha yüksek PID kaynakları için bilinen uygulama gereksinimleri var mı? Yoksa, 262.144 PIN'e sekiz kat artış bile yüksek kaynaklı bir uygulamayı barındırmak için yeterli olmayabilir.

Bunun yerine, sorunlu uygulamayı belirleyin ve ardından uygun eylemi gerçekleştirin. VM boyutunu artırma veya AKS'yi yükseltme gibi diğer seçenekleri göz önünde bulundurun. Bu eylemler sorunu geçici olarak hafifletebilir, ancak sorunun yeniden gösterilmeyebileceğini garanti etmez.

Her denetim grubunun (cgroup) iş parçacığı sayısını izlemek ve ilk sekiz cgroup'u yazdırmak için aşağıdaki kabuk komutunu çalıştırın:

watch 'ps -e -w -o "thcount,cgname" --no-headers | awk "{a[\$2] += \$1} END{for (i in a) print a[i], i}" | sort --numeric-sort --reverse | head --lines=8'

Daha fazla bilgi için bkz . İşlem Kimliği sınırları ve rezervasyonlar.

Kubernetes, PID tükenmesini düğüm düzeyinde yönetmek için iki yöntem sunar:

  1. parametresini kullanarak --pod-max-pids kubelet içindeki bir podda izin verilen en fazla PID sayısını yapılandırın. Bu yapılandırma, pids.max ayarı her podun cgroup'unun içinde ayarlar. Sistem ve kubelet sınırlarını sırasıyla yapılandırmak için ve --kube-reserved parametrelerini de kullanabilirsiniz--system-reserved.

  2. PID tabanlı çıkarmayı yapılandırın.

Not

Varsayılan olarak, bu yöntemlerden hiçbiri ayarlanmadı. Ayrıca, AKS düğüm havuzları için Düğüm yapılandırmasını kullanarak şu anda iki yöntemi de yapılandıramazsınız.

6. Adım: Daha yüksek bir hizmet katmanı kullanma

Daha yüksek bir hizmet katmanı kullanarak AKS API sunucusunun yüksek kullanılabilirliğe sahip olduğundan emin olabilirsiniz. Daha fazla bilgi için bkz. Azure Kubernetes Service (AKS) Çalışma Süresi SLA'sı.

Daha fazla bilgi