Mimari ve çalışma modeli
Özel Kubernetes kümesinde pod veya node dış IP taşımaz. Dış hedefe giden akış; pod CNI, node yönlendirmesi/SNAT, subnet route, firewall/policy ve Cloud NAT, NAT Gateway veya Azure NAT Gateway gibi çıkış bileşenlerinden geçer. Yönetilen hizmet API'leri private endpoint veya service endpoint üzerinden erişilebiliyorsa internet NAT'i gerekmeyebilir; DNS'in özel adı doğru adrese çözmesi gerekir.
DNS arızası ile egress arızası benzer görünür. Önce pod içinden adı çözün, sonra çözülen IP ve portla TCP/TLS bağlantısını test edin. CoreDNS/kube-dns, node resolver, private zone link/forwarder ve upstream resolver ayrı katmanlardır. NetworkPolicy UDP 53'e izin verip büyük yanıtların TCP 53 fallback'ini engelliyorsa aralıklı hata görülebilir.
NAT port tükenmesi, yüksek paralellik ve uzun bağlantılarda paket kaybı üretir. Toplam bağlantı sayısı yalnız pod sayısı değildir; replica × hedef sayısı × eşzamanlı bağlantı ve retry fırtınasıyla büyür. GKE Cloud NAT port metriği, AWS NAT Gateway ErrorPortAllocation/connection metrikleri ve Azure SNAT/NAT metrikleri ürün adları farklı olsa da aynı kapasite sorusunu yanıtlar.
- 1Pod DNS ve NetworkPolicy
- 2Node/CNI SNAT ve route
- 3Bulut NAT/private endpoint
- 4Hedef TLS ve dönüş trafiği
Tasarım parametreleri
- Çıkış modeli
- İnternet NAT, private endpoint ve proxy hedeflerini FQDN/port bazında envanterleyin.
- SNAT port bütçesi
- Node veya NAT IP başına eşzamanlı hedef bağlantıları ve retry artışını hesaplayın.
- DNS yolu
- Cluster DNS, node resolver, private zone ve kurumsal forwarder zincirini belgeleyin.
- Politika sırası
- CNI NetworkPolicy, bulut firewall/NSG/security group ve route kontrolünü katman katman yapın.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Kontrol | Google Cloud / GKE | AWS / EKS | Azure / AKS |
|---|---|---|---|
| İnternet çıkışı | Cloud NAT ve private node/subnet kapsamı | NAT Gateway veya gerekli VPC endpoint'leri | Managed/user-assigned NAT Gateway ya da UDR/firewall |
| Özel servis erişimi | Private Google Access/PSC ve Cloud DNS | Interface/Gateway VPC endpoints ve private DNS | Private Endpoint/Private DNS zone ve VNet link |
| İlk kapasite kanıtı | NAT port allocation ve dropped packets | ErrorPortAllocation/PacketsDropCount | SNAT/NAT port ve flow log metrikleri |
Hesap ve uygulama örneği
120 pod, pod başına 20 hedef ve hedef başına 4 eşzamanlı bağlantı teorik olarak 9.600 akış üretir. Bir hata sırasında üç retry dalgası anlık talebi 28.800'e çıkarabilir. Tek NAT IP varsayımı yerine hedef başına port tahsisi, node dağılımı ve bağlantı yeniden kullanımını metriklerle doğrulayın.
Bir image pull hatasında önce registry FQDN'ini `getent` ile çözün, 443 TCP/TLS testini yapın ve node ile pod sonucunu karşılaştırın. Pod çözemez, node çözebilirse cluster DNS/policy; ikisi çözer fakat TLS kuramazsa route, NAT, firewall veya proxy katmanına geçin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
kubectl run netcheck --rm -it --restart=Never --image=busybox:1.36 -- sh
getent hosts registry.example.com
nc -vz registry.example.com 443
cat /etc/resolv.conf
kubectl -n kube-system get pods -l k8s-app=kube-dns -o wide
kubectl get networkpolicy -AHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| DNS timeout | CoreDNS kapasitesi, UDP/TCP 53 policy veya upstream forwarder sorunu olabilir. | Pod ve node resolver sonuçlarını, CoreDNS log/metriklerini ve TCP 53 testini karşılaştırın. |
| Bağlantı yoğunlukta kesiliyor | NAT portu tükeniyor veya retry fırtınası oluşuyor olabilir. | NAT port allocation/drop metriklerini uygulama connection/retry metriğiyle eşleyin. |
| Yalnız yönetilen API erişilemiyor | Private endpoint DNS adı, route veya servis endpoint kapsamı eksik olabilir. | FQDN'in çözülen IP'sini ve ilgili private zone/VPC endpoint/VNet link durumunu doğrulayın. |
Kabul ve doğrulama kontrolleri
- Pod ve node için DNS sonucunu ayrı kaydedin.
- Gerekli FQDN/port listesini çıkış yöntemine eşleyin.
- UDP ve TCP 53 erişimini NetworkPolicy altında test edin.
- NAT port kapasitesini normal ve retry yüküyle hesaplayın.
- GKE, EKS ve AKS karşılığında route ve private DNS bağını doğrulayın.
- Düzeltme sonrası DNS hata, NAT drop ve p95 bağlantı süresini karşılaştırın.
İlgili kavramlar
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
Katman 2 ve Katman 3 sınırları
VLAN ayrı bir yayın alanı oluşturur; VLAN’lar arası iletişimi yönlendirme ve erişim politikası belirler. Bir trunk üzerindeki VLAN listesi, access port ataması ve gateway konumu birlikte incelenmelidir. Ağ çiziminde yalnız kablo bağlantısını değil, paketlerin nerede yönlendirildiğini ve nerede filtrelendiğini gösterin. Aynı switchte bulunmak aynı yetkiye sahip olmayı gerektirmez. Bir erişimin çalışmaması halinde önce doğru VLAN ve adresi, ardından gateway, route ve politika eşleşmesini doğrulayın.
IT/OT güvenlik bölgeleri
Bölge, benzer güvenlik ve işletim gereksinimlerini paylaşan varlık grubudur; bölgeler arasındaki iletişim kontrollü geçitlerden geçmelidir. OT cihazının erişilebilir olması, tarama veya güncelleme için güvenli olduğunu göstermez. Kontrol gecikmesi, emniyet, üretici desteği ve bakım penceresi kararları değiştirir. PLC ve SCADA iletişimini mevcut üretim akışından gözlemleyin; IT tarafındaki politikayı olduğu gibi aktarmayın. Uzaktan destek erişimine kimlik, süre, onay ve kayıt koşulları tanımlayın. Aktif test ve geçişleri üretim sorumlusuyla koordine edin.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.