Bir Prometheus ihracatçısı olan Kube Eagle'ı yarattım. Küçük ve orta ölçekli kümelerin kaynaklarının daha iyi anlaşılmasına yardımcı olan harika bir şey olduğu ortaya çıktı. Sonunda, doğru makine türlerini seçtiğim ve iş yükleri için uygulama kaynak sınırlarını yapılandırdığım için yüzlerce dolar tasarruf ettim.
Size faydalarından bahsedeceğim , ancak önce bu yaygaraya neyin sebep olduğunu ve neden yüksek kaliteli izlemeye ihtiyaç duyulduğunu açıklayacağım.
4-50 düğümden oluşan birkaç kümeyi yönettim. Her küme 200'e kadar mikro hizmet ve uygulama içerir. Mevcut donanımdan daha iyi yararlanmak için çoğu dağıtım, artırılabilir RAM ve CPU kaynaklarıyla yapılandırıldı. Bu sayede pod'lar gerektiğinde mevcut kaynakları alabilir ve aynı zamanda bu düğümdeki diğer uygulamalara müdahale etmez. Harika değil mi?
Küme nispeten az CPU (%8) ve RAM (%40) tüketse de, düğümde mevcut olandan daha fazla bellek ayırmaya çalıştıklarında bölmelerin öncelikli olarak kullanılmasıyla ilgili sürekli sorunlar yaşadık. O zamanlar Kubernetes kaynaklarını izlemek için tek bir kontrol panelimiz vardı. Bunun gibi:
Yalnızca cAdvisor ölçümlerini içeren Grafana kontrol paneli
Böyle bir panelde çok fazla bellek ve CPU tüketen düğümleri görmek sorun değil. Sorun bunun sebebinin ne olduğunu bulmaktır. Bölmeleri yerinde tutmak için elbette tüm bölmelerde garantili kaynaklar ayarlanabilir (talep edilen kaynaklar sınıra eşittir). Ancak bu, donanımın en akıllıca kullanımı değildir. Kümenin birkaç yüz gigabaytlık belleği vardı, bazı düğümler açlıktan ölüyordu, diğerlerinde ise yedekte 4-10 GB kalmıştı.
Kubernetes planlayıcısının iş yüklerini mevcut kaynaklar arasında eşit olmayan bir şekilde dağıttığı ortaya çıktı. Kubernetes zamanlayıcı farklı yapılandırmaları dikkate alır: benzeşim, kusurlar ve tolerans kuralları, kullanılabilir düğümleri sınırlayabilen düğüm seçiciler. Ancak benim durumumda böyle bir şey yoktu ve bölmeler, her düğümde talep edilen kaynaklara göre planlandı.
Pod için en fazla boş kaynağa sahip olan ve istek koşullarını karşılayan düğüm seçildi. Düğümlerde talep edilen kaynakların gerçek kullanımla eşleşmediğini gördük ve bu noktada Kube Eagle ve kaynak izleme yetenekleri imdadımıza yetişti.
Neredeyse tüm Kubernetes kümelerini yalnızca şununla izliyorum: и . Node Exporter, G/Ç ve disk, CPU ve RAM kullanımına ilişkin istatistikler sağlarken Kube Durum Metrikleri, istekler ve CPU ve bellek kaynağı sınırları gibi Kubernetes nesne ölçümlerini gösterir.
Kullanım metriklerini Grafana'daki request ve limit metrikleriyle birleştirmemiz gerekiyor ve ardından sorunla ilgili tüm bilgileri alacağız. Bu basit gibi görünse de aslında iki araç etiketleri farklı şekilde adlandırır ve bazı metriklerin hiçbir meta veri etiketi yoktur. Kube Eagle her şeyi kendisi yapıyor ve panel şöyle görünüyor:
Kaynaklarla ve ekipman tasarrufuyla ilgili birçok sorunu çözmeyi başardık:
- Bazı geliştiriciler mikro hizmetlerin ne kadar kaynağa ihtiyaç duyduğunu bilmiyordu (ya da umursamadı). Kaynaklara yönelik hatalı talepleri bulmamızın hiçbir yolu yoktu; bunun için tüketimin yanı sıra talep ve limitleri de bilmemiz gerekiyor. Artık Prometheus ölçümlerini görüyor, gerçek kullanımı izliyor ve istekleri ve limitleri ayarlıyorlar.
- JVM uygulamaları işleyebilecekleri kadar RAM alır. Çöp toplayıcı yalnızca %75'ten fazlası kullanıldığında belleği serbest bırakır. Ve çoğu hizmetin patlamalı belleği olduğundan, her zaman JVM tarafından kullanılıyordu. Bu nedenle tüm bu Java hizmetleri beklenenden çok daha fazla RAM tüketiyordu.
- Bazı uygulamalar çok fazla bellek talep ediyordu ve Kubernetes zamanlayıcısı, aslında diğer düğümlerden daha özgür olmalarına rağmen bu düğümleri diğer uygulamalara vermiyordu. Bir geliştirici, isteğe yanlışlıkla fazladan bir rakam ekledi ve büyük bir RAM parçası aldı: 20 yerine 2 GB. Kimse fark etmedi. Uygulamanın 3 kopyası vardı, dolayısıyla en fazla 3 düğüm etkilendi.
- Kaynak sınırlarını uygulamaya koyduk, bölmeleri doğru isteklerle yeniden planladık ve tüm düğümlerde ideal bir donanım kullanımı dengesi elde ettik. Birkaç düğüm tamamen kapatılmış olabilir. Ve sonra yanlış makinelere sahip olduğumuzu gördük (bellek odaklı değil, CPU odaklı). Türü değiştirdik ve birkaç düğümü daha sildik.
sonuçlar
Kümedeki artırılabilir kaynaklarla, mevcut donanımı daha verimli kullanırsınız, ancak Kubernetes zamanlayıcısı, kaynak isteklerine göre bölmeleri planlar ve bu endişe vericidir. Bir taşla iki kuş vurmak: Sorunlardan kaçınmak ve kaynakları sonuna kadar kullanmak için iyi bir izlemeye ihtiyacınız var. Bu yüzden faydalı olacaktır (Prometheus ihracatçısı ve Grafana kontrol paneli).
Kaynak: habr.com
