Yeni bir GKE kümesi için pod CIDR ve service CIDR planlıyorsunuz ancak mevcut bir alt ağ zaten bir aralıkla çakışıyor. Doğru tasarım kararı nedir?

Doğru seçenek, GKE kümesi için Pod'lar ve Servisler için çakışmayan ikincil IP aralıkları seçmek ve bunları mevcut alt ağa atamaktır. GKE kümeleri, Pod ve Servis IP'leri için birincil alt ağ aralığından ayrı ikincil IP aralıkları kullanabilir. Bu, mevcut birincil alt ağ ile çakışma sorununu doğrudan çözer. Diğer seçenekler neden yanlış: "Çakışan service CIDR'ı VPC aralığına çevirmek için VPC güvenlik duvarı kurallarını kullanın": Güvenlik duvarı kuralları IP çakışmalarını çözmez, trafik akışını kontrol eder. "Servis IP'lerini çakışan alt ağa eşleyen statik rotaları manuel olarak ekleyin": GKE, Pod ve Servis IP'lerini otomatik olarak yönetir. Manuel statik rotalar eklemek karmaşıklığı artırır ve GKE'nin çalışma şekliyle uyumlu değildir. Ayrıca, çakışan bir aralık için statik rota eklemek yönlendirme sorunlarına yol açacaktır. "Kümenin çakışan aralıklar oluşturmasına izin verin; GKE servis IP'lerini otomatik olarak NAT'layacaktır": GKE, Pod ve Servis IP'leri için çakışan aralıkları otomatik olarak NAT'lamaz. IP çakışmaları ağ sorunlarına ve iletişim hatalarına neden olur.