Kubernetes ve pod izleme, kendi ağınızın içinde

Kümenize ne uygulanıyor?

Platform ekipleri önce kümelerine neyin uygulanacağını bilmek ister. Sıra şöyle:

1. Wrentrix arayüzünden bir küme ekleyin.
2. Hazır YAML dosyasını indirin, jeton içinde gelir.
3. Dosyayı okuyun. İnceleme hakkınız var, güvenlik ekibiniz de bakmak isteyebilir.
4. Uygulayın.

oc apply -f wrentrix-k8s-agent.yaml

Saf Kubernetes kullanıyorsanız aynı dosyayı kubectl apply -f ile uygulayabilirsiniz. Düğümler ve pod'lar yaklaşık iki dakikada görünür. Java ve .NET iş yükleri bir sonraki yeniden başlatmada metot düzeyinde izlenmeye başlar, Wrentrix bunları kendisi yeniden başlatmaz.

Platformun kendisi Helm chart, OpenShift operatörü veya Docker Compose ile kurulur:

helm install wrentrix ./wrentrix.tgz -n wrentrix -f values.yaml

İndirilen ajan dosyası jeton içerdiği için onu kimlik bilgisi gibi ele alın. Ortak bir Git deposuna düz metin olarak koymayın. GitOps kullanıyorsanız diğer secret'lar için izlediğiniz yolu izleyin.

Pod izlemede gerçekten baktığınız şeyler

Wrentrix iş yüklerini, pod'ları, olayları ve HPA durumunu; kaynak kullanımını da en düşük, ortalama, p95 ve tepe değerleriyle gösterir. Bunu uygulama verisiyle yan yana koyar: istekler, trace'ler, metotlar, loglar. OpenShift'in yerleşik izleme yığınını kaldırmanız gerekmez. O platformun sağlığını izler, Wrentrix ise platform görünümünü uygulamaların yaptıklarıyla bağlar. Yerleşik parçaların neyi kapsadığını OpenShift izleme rehberinde anlattık.

Olaylar hak ettikleri ilgiyi görmez. OOMKilling, BackOff, FailedScheduling ve Unhealthy gibi Kubernetes olayları çoğu zaman bir pod'un neden yeniden başladığının tek kaydıdır ve kümede kısa süre tutulur (API sunucusunun --event-ttl varsayılanı bir saattir). Süre dolunca describe çıktısı dün gece ne olduğunu söylemez.

restricted-v2 altında çalışmak ne demek?

İzleme ajanlarının uzun bir istek geçmişi vardır: ayrıcalıklı konteyner, host path, host ağı, özel SCC. Denetimli OpenShift ortamlarında bu istek, değerlendirmeden uzun süren bir inceleme başlatabilir.

Wrentrix varsayılan restricted-v2 SCC altında, en az yetkili pod'larla, root ve ek SCC olmadan çalışır. Bu SCC altında OpenShift ad alanının ayrılan aralığından bir UID atar, yetki yükseltmeyi yasaklar, tüm yetenekleri düşürür (yalnızca NET_BIND_SERVICE eklenebilir) ve RuntimeDefault benzeri bir seccomp profili ister. Sonucu kendiniz doğrulayabilirsiniz:

oc get pods -n wrentrix -o custom-columns='POD:.metadata.name,SCC:.metadata.annotations.openshift\.io/scc'

Sütunda restricted-v2 görüyorsanız iddia kendi kümenizde doğrulanmıştır, kimsenin sözüne güvenmeniz gerekmez.

Fail-open admission

Ajan, metot düzeyi enstrümantasyonu yürüten bir admission webhook içerir. Pod oluşturma yoluna giren her şey şüpheyi hak eder: failurePolicy: Fail ile kötü ayarlanmış bir webhook, kümedeki tüm pod'ların, sorunu çözecek olanlar dahil, başlamasını engelleyebilir.

Wrentrix webhook'u fail-open çalışır: ajan erişilemezse pod'lar enstrümantasyonsuz başlar. Pod başlangıcı başına p95 ek yükü 25 ms'nin altındadır. Doğrudan incelemek için:

oc get mutatingwebhookconfigurations
oc get mutatingwebhookconfiguration <ad> -o yaml

failurePolicy, timeoutSeconds ve namespaceSelector alanlarına bakın.

Dört sayıyla boyutlandırma

Fazla yüksek request kapasite israfıdır. Fazla düşük request zamanlama baskısı ve kaynak çekişmesi getirir. Fazla düşük limit CPU kısıtlaması ve OOM ile sonuçlanır. Ekipler bunları çoğunlukla bir kez, tahminle ayarlar ve bir daha bakmaz.

En düşük, ortalama, p95 ve tepe değerleri farklı şeyler söyler, asıl bakmanız gereken aralarındaki mesafedir. Aşağıdaki değerler örnektir:

CPU ile bellek farklı düşünülmelidir. CPU sıkıştırılabilir: limiti aşmak hataya değil, kısıtlamaya yol açar. Bellek öyle değildir: limiti aşan konteyner OOM ile öldürülür. Bu yüzden p95 CPU request'i için makul bir girdi olabilir, bellek limiti ise tepe artı pay gözetmelidir. Tepe değer de ağır işlerinizi içeren bir dönemden gelmelidir: ay sonu, toplu iş pencereleri, maaş günleri.

Wrentrix bu veriden boyutlandırma ipuçları üretir. Bunlar ipucudur, karar büyümeyi ve uygulamayı bilen sizdedir. Kendi rakamlarınızı denemek için Kubernetes kaynak hesaplayıcı sayfasını kullanabilirsiniz.

HPA tuzağı

CPU tabanlı HPA hedefleri request yüzdesi olarak tanımlanır, yani request değiştiğinde ölçekleme davranışı da değişir. Kubernetes formülü desiredReplicas = ceil(currentReplicas × currentMetric ÷ targetMetric) şeklindedir.

Örnek: 6 replika, her biri 1000m request ve ortalama 300m kullanıyor, hedef yüzde 60. Mevcut kullanım yüzde 30, HPA ceil(6 × 30 ÷ 60) = 3 replika ister. Şimdi aynı kullanımla request'i 500m'ye indirin. Kullanım yüzde 60 olur, HPA ceil(6 × 60 ÷ 60) = 6 hesaplar. Aynı yükte farklı bir denge durumu çıkar, azaltacağınızı düşündüğünüz kapasite beklediğiniz kadar düşmez. HPA ile request'leri tek değişiklik olarak ele alın.

Bozulmadan önce ne değişti?

Üretim olaylarının çoğu bir değişiklikle başlar. Onu bulmak gerektiğinden zordur, çünkü başkasının yaptığı bir değişiklik olabilir. Wrentrix spec, ConfigMap, Secret ve rollout restart değişikliklerini gecikme ve hata sıçramalarıyla aynı zaman çizelgesine koyar.

Bunların her biri farklı şekilde gözden kaçar:

• Spec değişiklikleri Deployment için yeni bir ReplicaSet oluşturur, rollout geçmişinde görünür.
• ConfigMap düzenlemeleri pod'ları yeniden başlatmaz. Bağlı dosya bir gecikmeyle güncellenir, ortam değişkeni olarak alınan değer ise ancak sonraki pod başlangıcında değişir. Değişiklik ile etkisi arasında saatler veya günler olabilir.
• Secret değişiklikleri aynı şekilde davranır. Yeniden başlatmayla devreye giren döndürülmüş bir veritabanı şifresi, "durup dururken başladı" denen olayların klasik kaynağıdır.
• Rollout restart pod şablonuna kubectl.kubernetes.io/restartedAt notunu ekler. İmaj ve ayar değişmediği için Git farkında bir şey görünmez, ama bütün pod'lar yenidir.

Kurgu bir örnek: odeme servisinin p99 değeri 02.14'te tırmanıyor. O gece dağıtım yok. Zaman çizelgesi önceki gün 18.30'da bir ConfigMap düzenlemesi ve 02.12'de iki pod'u yeniden oluşturan bir düğüm boşaltması gösteriyor. Yeni değeri ilk okuyan bu iki pod, yavaş olanlardır. Ortak bir zaman çizelgesi olmadan bunu bulmak saatler ve iyi bir hafıza ister. Korelasyon kanıttır, ispat değildir: ilgisiz değişiklikler de olayların yakınında olur, geri almadan önce doğrulayın.

Başka bir şeye bakmanız gereken durumlar

• Küçük bir ortamda yalnızca küme sağlığı gerekiyorsa OpenShift'in yerleşik izlemesi tek başına yeterli olabilir.
• Konunuz etcd gecikmesi veya API sunucusu kısıtlaması gibi kontrol düzlemi iç işleyişiyse platformun kendi panelleri en doğrudan yerdir.
• Docker Compose tek sunucuda çalışır, mimari şemasındaki 3 ve üzeri replikalı yerleşimi veremez. O yerleşim için OpenShift veya Kubernetes kurun.
• Keyfi küme sayıları için donanım boyutu yayınlamıyoruz. Düğüm ve pod sayılarınızla gelip bize sorun: demo talebi.

Sık sorulan sorular

Wrentrix OpenShift'te özel SCC veya ayrıcalıklı pod ister mi?

Hayır. Wrentrix varsayılan restricted-v2 SCC altında, root ve ek SCC olmadan çalışır. Bunu kendi kümenizde pod'lardaki openshift.io/scc notunu okuyarak doğrulayabilirsiniz.

Ajan kurulumu iş yüklerimi yeniden başlatır mı?

Hayır. Wrentrix iş yüklerini hiçbir zaman yeniden başlatmaz. Düğümler ve pod'lar YAML uygulandıktan yaklaşık iki dakika sonra görünür, Java ve .NET için metot düzeyi izleme her pod kendi nedeniyle yeniden başladığında devreye girer.

Ajan veya webhook düşükse yeni pod'lara ne olur?

Webhook fail-open çalıştığı için pod'lar enstrümantasyonsuz başlar, dağıtımlar engellenmez. Bu pod'larda ajan erişilebilir durumdayken yeniden başlayana kadar metot düzeyi veri olmaz. Davranışı test kümenizde ajanı küçültüp pod oluşturarak kontrol edin.

Pod bellek ve CPU kullanımını nasıl izlerim?

Tek başına kubectl top anlık değer verir, boyutlandırma kararı için yetmez. Ortalama, p95 ve tepe değerlerine ağır dönemleri kapsayan bir aralıkta bakın ve bunları request ile limitlerle karşılaştırın. Wrentrix kaynak kullanımını en düşük, ortalama, p95 ve tepe olarak gösterir.

Hangi değişikliğin gecikmeye yol açtığını görebilir miyim?

Wrentrix spec, ConfigMap, Secret ve rollout restart değişikliklerini gecikme ve hata sıçramalarıyla aynı zaman çizelgesine koyar. Böylece sıçramadan hemen önce ne değiştiğini görürsünüz. Bunlardan birinin gerçek neden olup olmadığını siz doğrularsınız, çünkü zamanlama tek başına kanıt değildir.