Çakışan Kubernetes CPU kullanımı ve Docker Container Metrics

Kısa bir süre önce üretim ortamımızı Kubernetes'e çevirdik. Kapsayıcılarda CPU sınırlarını zorlamak istiyorum. Birbirine uymayan çakışan CPU metrikleri alıyorum. İşte kurulumum:

• DataDog aracıları Daemonset
• CPU Sınırları olmadan çalışan mevcut uygulamalar
• Söz konusu kaplar çok iş parçacıklı Ruby uygulamalarıdır
• İki ölçüm: kubernetes.cpu.usage.{avg,max}vedocker.cpu.usage
• c4.xlarge küme düğümleri (Kubernetes açısından 4 vCPU veya 4000m)

kubernetes.cpu.usage.maxsöz konusu kaplar için ~ 600m. docker.cpu.usageraporlar ~% 60. 1000m CPU limitinin normal çalışma altında yeterli kapasiteden fazla olacağı sonucuna varılır.

Limiti 1000m olarak ayarladım. Sonra docker.container.throttlesönemli ölçüde artar kubernetes.cpu.usage.maxve docker.cpu.usageaynı kalır. Sistem bu süre zarfında dizlerinin üzerine çöküyor. Bu benim için bir anlam ifade etmiyor.

Docker istatistiklerini araştırdım. Görünüşe göre docker stats(ve altta yatan API) yükü CPU çekirdeklerine göre normalleştiriyor . Benim durumumda, docker.cpu.usageKubernetes cinsinden% 60'ı (4000m * 0.60) ile 2400m arasında geliyor. Ancak bu, herhangi bir Kubernetes numarasıyla ilişkili değildir. Kubernetes sayılarının yanlış olduğu hipotezimi test etmek için başka bir deney yaptım. Limiti 2600m'ye ayarladım (bazı ekstra tavan boşlukları için). Bu herhangi bir gaz kelebeği ile sonuçlanmadı. Ancak Kubernetes, CPU kullanımının değişmediğini gözlemledi. Bu beni şaşırttı.

Yani sorularım:

• Bu Kubernetes'teki bir hata mı (yoksa yığındaki bir şey mi?)
• Anlayışım doğru mu?

Takip eden sorum, Ruby uygulamaları için CPU'nun nasıl doğru bir şekilde belirleneceğiyle ilgilidir. Bir kap Puma kullanır. Bu, yapılandırılabilir miktarda iş parçacığı içeren çok iş parçacıklı bir web sunucusudur. HTTP istekleri iş parçacıklarından biri tarafından işlenir. İkinci uygulama, dişli sunucuyu kullanan bir tasarruf sunucusudur. Gelen her TCP bağlantısı kendi iş parçacığı tarafından gerçekleştirilir. Bağlantı kapandığında iplik çıkar. Ruby olarak GIL (Global Tercüman Kilidi) sayesinde Ruby kodunu aynı anda yalnızca bir iş parçacığı yürütebilir. Bu, IO ve bunun gibi şeyleri yürüten birden fazla iş parçacığına izin verir.

En iyi yaklaşım her uygulamada çalışan iş parçacığı sayısını sınırlamak ve iş parçacığı sayısına bağlı olarak Kubernetes CPU sınırlarına yaklaşmak olduğunu düşünüyorum. İşlemler çatallanmadığı için toplam CPU kullanımını tahmin etmek daha zordur.

Buradaki soru şudur: CPU uygulamaları ve bu uygulamalar için sınırlar nasıl doğru tahmin edilir?

Burada birden fazla şey var:

1. AWS ec2'de bulunuyorsunuz, dolayısıyla CPU'nuzu ölçmek için örneğinizde ne yaparsanız yapın CPU'yu örnek düzeyinde değil hiper yönetici düzeyinde hesaplıyor olursunuz. Bunun için herhangi bir yük testi çalıştırın ve bulut saatinde iostat-cct 1 ve CPU kullanımını kontrol edin. Cloudwatch'ta CPU kullanımı her zaman iostatın rapor edeceğinden% 10-20 daha fazladır ve bunun nedeni iostat'ın hipervizör seviyesinde CPU kullanımı vermesidir.

2. Docker olarak kubernetes ve docker metriklerinin nasıl karşılaştırıldığını görmek için tüm kapların yalnızca tek bir vCPU kullanmasına izin vermek için kapları --cpuset = 1 veya herhangi bir sayı ile çalıştırmanızı öneririm.

3. Ayrıca AWS 1 CPU = 2vcpu'da. 2'ye hiper iş parçacığına sahiptir. Hesaplarken bunu da dikkate alabilirsiniz.

4. Son olarak, belirli bir uygulamanın CPU kullanımını görmek için kullanılacak en iyi ölçüm, htop kullanmak ve bulut saati metriklerinizle ilişkilendirmektir.

5. Bazen docker daemon'un kendini sanal CPU'lardan birine sabitlediğini ve dolayısıyla 1000m'ye indirdiğinizde, belki de tüm kurulum yavaşlıyor çünkü vpcus'un herhangi birinde azalma oluyor. Bunun ayrıntılarına ulaşmak için mpstat kullanabilirsiniz.

6. Son olarak, ana makine düzeyinde docker'ı tek bir CPU'ya sabitleyebilir ve daha fazlasını gözlemleyebilirsiniz.

Umarım bu sizi biraz daha yaklaştırır. Zaten bir çözüm bulduysanız beni güncelleyin.