Ping izleme hâlâ önemlidir; çünkü yönetilen bulut ve Kubernetes ağ arızalarını ortadan kaldırmaz, yalnızca yerlerini değiştirir. Değiştirilmiş bir güvenlik grubu, bozuk bir NAT rotası veya hatalı bir DNS kaydı, her pod Ready durumunu bildirirken sağlıklı iş yüklerini erişilemez hâle getirebilir. Ortamınızın hem dışından hem de içinden çalıştırılan sürekli ICMP ve TCP erişilebilirlik kontrolleri, bu arızaları kullanıcılardan önce yakalar.
Yönetilen Altyapının da Bir Ağı Vardır
Sağlayıcılar donanımı işletir, ancak erişilebilirlik olaylarının çoğunun başladığı sanal ağ yapılandırması sizin sorumluluğunuzdadır:
- Güvenlik grupları ve ağ ACL'leri. Kod olarak altyapı (IaC) aracılığıyla gönderilen fazla kısıtlayıcı tek bir kural, bir katmanı sessizce devre dışı bırakabilir.
- NAT ağ geçitleri. NAT rotasını kaybeden özel iş yükleri artık kayıt defterlerine (registry), ödeme API'lerine veya SaaS bağımlılıklarına erişemez.
- VPC eşleme ve transit ağ geçitleri. Yönlendirme tablosu düzenlemeleri veya ayrılmış bir bağlantı (attachment), VPC'ler ve hesaplar arasındaki trafiği bozar.
- DNS. Özel bölgeler ve çözümleyici kuralları, kesinti gibi görünen şekillerde arızalanır.
- Erişilebilirlik alanları (AZ) ve bölgeler arası gecikme. Bir yük devretmeden sonra trafik alanlar veya bölgeler arasında dolanarak onlarca milisaniye ekleyebilir.
Bunların hiçbiri, istekler zaman aşımına uğramaya başlayana kadar CPU grafiklerinde görünmez.
ICMP Genellikle Engellidir, Bu Yüzden TCP Ping Kullanın
Klasik ping, bulutta çoğu zaman tasarım gereği başarısız olur. AWS'de varsayılan güvenlik grubu yalnızca aynı grubun üyelerinden gelen gelen trafiğe izin verir; bu nedenle açık bir kural ekleyene kadar internetten gelen ICMP düşürülür. Azure ağ güvenlik grupları varsayılan bir DenyAllInBound kuralıyla biter. Google Cloud'un otomatik oluşturulan varsayılan ağı ICMP'ye izin veren bir kuralla gelir, ancak özel VPC ağları siz açmadıkça tüm gelen trafiği reddeder. Yönetilen yük dengeleyiciler genellikle ICMP'ye hiç yanıt vermez.
Pratik çözüm TCP ping'dir: zaten erişilebilir olması gereken bir porta TCP el sıkışmasının süresini ölçün. İyi hedefler şunlardır:
- 443 veya 80 portundaki yük dengeleyici dinleyicileri
- Kubernetes ingress denetleyicisi uç noktaları
- Dışarıya açtığınız NodePort hizmetleri (varsayılan aralık 30000-32767)
- Hizmet portlarındaki bastion sunucuları ve VPN ağ geçitleri
Bir TCP kontrolü, ICMP'yi dünyaya açmadan güvenlik grupları ve dinleyiciler dahil olmak üzere gerçek trafiğin izlediği yolu doğrular. İzin verilen yerlerde düğümden düğüme ve hibrit bağlantı kontrolleri için ICMP'yi dahili olarak kullanmaya devam edin.
Kubernetes Yoklamalarının Zaten Kapsadıkları ve Kapsamadıkları
Liveness, readiness ve startup yoklamaları, konteynerin bulunduğu düğümdeki kubelet tarafından çalıştırılır. Başka birinin konteynere erişip erişemediğini değil, konteynerin o düğümden bakıldığında sağlıklı olup olmadığını yanıtlarlar.
| Konu | Kubelet yoklamaları | Ping / TCP izleme |
|---|---|---|
| Konteyner süreci askıda kaldı | Evet | Hayır |
| Pod, Service uç noktalarından çıkarıldı | Evet | Dolaylı olarak |
| Ingress veya yük dengeleyiciye erişilemiyor | Hayır | Evet |
| Düğüm ağ bağlantısını kaybetti | Hayır | Evet |
| Harici bağımlılık veya NAT yolu çalışmıyor | Hayır | Evet, içeriden |
| Bölgesel gecikme artışı | Hayır | Evet |
Başarısız bir liveness yoklaması sizi uyarmak yerine konteyneri yeniden başlatır. Düğümlere, ingress uç noktalarına ve kritik harici bağımlılıklara ping atın; konteyner sağlığını yoklamalara bırakın. ClusterIP adresleri kube-proxy'nin iptables modunda genellikle ICMP'ye yanıt vermez, bu nedenle hizmetleri TCP ile test edin.
Harici Gözlem Noktaları ve Dahili Yoklamalar
İkisine de ihtiyacınız var. Prometheus Blackbox Exporter dağıtımı gibi dahili kontroller; doğu-batı yollarını, NAT çıkışını ve özel DNS'i doğrular. Harici kontroller ise müşterilerin deneyimlediği şeyi doğrular: DNS, yönlendirme, yük dengeleyici ve ingress.
UpScanX ping izleme, ICMP, TCP ve UDP kontrollerini 15'ten fazla küresel konumdan çalıştırır; böylece bölgesel sorunlar göze çarpar: Frankfurt ve Singapur 120 ms'lik bir sıçrama görürken Virginia sabit kalıyorsa kümenizden değil yönlendirmeden şüphelenin. Tipik bir kurulum 30-60 saniyelik bir aralık kullanır ve birden fazla konumdan art arda iki veya üç başarısızlıktan sonra uyarı verir.
Hibrit ve Çoklu Bulut Bağlantıları
Siteden siteye VPN'ler, Direct Connect veya ExpressRoute devreleri ve bulutlar arası tüneller klasik kör noktalardır. BGP rotaları geri çekmişken veya kayıp %3-5 seviyesindeyken bir tünel konsolda “ayakta” görünebilir. Her bağlantının iki tarafındaki kararlı bir ana bilgisayara ping atın ve yalnızca tam arızada değil, kalıcı bozulmada da uyarı verin. Gecikme, kayıp ve jitter'ın temelleri için ping izlemenin nasıl çalıştığına göz atın.
Önemli Çıkarımlar
- Bulut ve Kubernetes, ağ riskini sizin kontrol ettiğiniz yapılandırmaya kaydırır: güvenlik grupları, NACL'ler, NAT, eşleme ve DNS.
- Çoğu kurulumda ICMP'nin varsayılan olarak engellenmesini bekleyin; yük dengeleyicilere, ingress'e ve hizmet portlarına karşı TCP ping kullanın.
- Kubelet yoklamaları erişilebilirliği değil, konteyner sağlığını kontrol eder. Düğümleri, ingress'i ve bağımlılıkları ayrıca izleyin.
- Küme sorunlarını yönlendirme sorunlarından ayırmak için dahili yoklamaları harici çok konumlu kontrollerle birleştirin.
- Uyarıları ekibinizin zaten baktığı yere gönderin; UpScanX E-posta, Slack, Telegram, Microsoft Teams ve Webhook'u destekler.