Google PCNE: GKE, Konteynerler ve Uygulama Ağı — Çalışma kılavuzu

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Network Engineer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google Kubernetes Engine (GKE), Google Cloud ağıyla sıkı bir şekilde entegre olur. Güvenilirlik ve güvenlik için tasarım yapmak; VPC-native IP adreslemesini, özel kontrol düzlemlerini, egress’i, kuzey-güney ve doğu-batı trafiğini, politika zorlamasını ve çoklu küme yapılarını anlamayı gerektirir. Bu bölüm, Google Cloud üzerindeki konteynerler ve uygulama ağı için tasarım rehberliği, operasyonel mantık ve yaygın hata modları sunmaktadır.

GKE IP mimarisi ve özel kümeler

VPC-native kümeler

• Bir VPC alt ağında iki ikincil aralığa sahip alias IP’ler kullanır: biri Pod’lar (PodCIDR) ve diğeri Service’ler (ServiceCIDR) için. Bu, düğümlerde iptables tabanlı SNAT’ı önler, NEG’ler ile konteyner-native yük dengelemeyi mümkün kılar ve rota tabanlı kümelere göre daha iyi ölçeklenir.
• Boyutlandırma yönergeleri:
  • Pod’lar: PodsPerNode × MaxNodes artı pay (%20–30) ayırın. Örneğin, mevcut 10 düğüm × 20 Pod + 100 × 200’e büyüme, bir /17 Pod aralığını önerir; Service’ler genellikle 2000’den fazla servis için bir /21’e sığar.
  • Service’ler: Her ClusterIP bir IP tüketir; headless’tan ClusterIP’ye geçişler ve eklentiler için payı hesaba katın.
• Hata modları:
  • Pod IP’lerinin tükenmesi: Pod’lar Beklemede (Pending) kalır veya CNI/IPAM hataları görünür; ikincil Pod aralığını ölçeklendirin veya düğüm başına maksimum pod sayısını azaltın, ardından düğümleri yeniden oluşturun.
  • Service IP’lerinin tükenmesi: Yeni Service’ler ClusterIP atayamaz; Service ikincil aralığını genişletin.
  • Çakışan alias aralıkları: Küme oluşturma başarısız olur veya yönlendirme kara delikleri oluşur; diğer alt ağlar veya eşlenmiş VPC’ler ile çakışma olmadığını doğrulayın.

Özel kümeler, kontrol düzlemi erişimi ve düğüm egress’i

• Özel kümeler, kontrol düzlemi uç noktasını, VPC’nizden yalnızca producer peering aracılığıyla erişilebilen özel bir RFC1918 adresiyle kısıtlar. Düğümler harici IP gerektirmez.
• Operatörler için seçenekler:
  • Yalnızca özel uç nokta: Kontrol düzlemi, VPC alt ağlarından ve bağlı ağlardan erişilebilir. Erişmek için Private Service Connect ile bastion veya Cloud Shell kullanın.
  • Authorized Networks ile genel uç nokta: Kontrol düzlemini, belirli kaynak CIDR’ları tarafından kontrol edilen bir genel IP üzerinde kullanıma açın. Bu kullanışlıdır ancak riski artırır; yalnızca sıkı CIDR kapsamlandırması ve güçlü yönetici kimlik kontrolleri ile kullanın.
• Düğüm egress’i:
  • Harici IP’leri olmayan düğümler için, Cloud NAT aracılığıyla internete yönelik egress sağlayın. Bu, düğümleri özel tutarken işletim sistemi güncellemelerine, harici registry’lerden konteyner imajı çekmeye ve iş ortağı API erişimine olanak tanır.
  • Harici IP’ler olmadan Google API’lerine ve Artifact/Container Registry’ye erişim için, düğüm alt ağlarında Private Google Access’i (PGA) etkinleştirin. PGA, Google API’leri/registry trafiğini, genel kaynak IP’leri olmadan Google’ın uç noktasına çözer ve yönlendirir. İmaj çekme işlemleri için PGA tercih edilir; Google dışı egress de gerekiyorsa Cloud NAT ile birleştirin.
  • Eğer 0.0.0.0/0 trafiği üçüncü parti bir güvenlik duvarından geçiriliyorsa, yine de PGA’yı etkinleştirin ve Google servisleri için güvenlik duvarını atlamak üzere Google API’leri VIP aralıkları için varsayılan internet ağ geçidine statik rotalar ekleyin.

Ölçeklendirme ve IP sorunlarını giderme

• Alt ağ ikincil aralığı seviyesinde alias IP tüketimini izleyin. Eğer IP baskısı artarsa:
  • İkincil aralık boyutlarını artırın (daha büyük aralıklar ekleyin, gerektiğinde kümeyi yeniden oluşturun veya iş yüklerini taşıyın).
  • Düğüm başına IP kullanımı ile zamanlama parçalanması arasında denge kurmak için max-pods-per-node ayarını yapın.
  • Terk edilmiş Service’leri temizleyin; headless Service’ler ClusterIP atamaz, ancak ClusterIP’ye dönüştürmek IP tüketecektir.
• Shared VPC, VPC Peering veya çoklu küme servisleri kullanırken yeniden IP ataması yapmaktan kaçınmak için çok bölgeli büyüme için çakışmayan ikincil aralıklarla plan yapın.

Ingress, Gateway API, Service’ler ve politikalar

Service’ler ve yük dengeleyiciler

• Service türleri:
  • ClusterIP: yalnızca küme içi erişim; doğu-batı trafiği kube-proxy veya dataplane v2 kullanır.
  • NodePort: her node üzerinde bir port ayırır; birçok LB tarafından bir backend olarak kullanılır ancak doğrudan internete açmaktan kaçının.
  • LoadBalancer: bir bulut yük dengeleyici sağlar. Harici veya dahili L4 yük dengeleyiciler TCP/UDP’yi destekler; session affinity ClientIP, gerektiğinde birden çok protokol arasında kalıcılık (stickiness) sağlar.
• Konteyner tabanlı (container-native) yük dengeleme, Network Endpoint Groups (NEG’ler) kullanır, böylece yük dengeleyici doğrudan Pod IP:port’larını hedefler, sağlık sinyallerini iyileştirir ve node atlamalarını (hop) azaltır. GKE için GKE Pod NEG’leri (GCE_POD) kullanın. Diğer NEG türleri arasında VM_IP_PORT, Internet FQDN ve PSC bulunur.
• GKE Ingress ve Gateway API:
  • Ingress, Google’ın genel harici HTTP(S) yük dengeleyicisi veya bölgesel dahili HTTP(S) yük dengeleyicisi ile HTTP(S) kuzey-güney trafiği için kararlıdır. Controller, standart desenler için sağlık kontrollerini ve güvenlik duvarı kurallarını otomatik olarak programlar.
  • Gateway API, Gateway’ler ve HTTPRoute’lar/TCPRoute’lar ile daha ifade gücü yüksek bir model sunar. Çoklu kiracılı (multi-tenant) yapılandırmaları, gelişmiş yönlendirmeyi ve ortamlar arasında tutarlı bir spesifikasyonu destekler. Geleceğe dönük uyumluluk için Gateway API’yi seçin; basitlik ve uyumluluğun önemli olduğu yerlerde Ingress kullanın.

İstemci kısıtlaması ve sağlık kontrolleri

• İstemcileri belirli kaynak aralıklarıyla kısıtlamak, L4 seviyesinde backend örneklerini hedefleyen VPC güvenlik duvarı kurallarıyla veya L7 seviyesinde HTTP(S) yük dengeleyiciler üzerindeki Cloud Armor politikalarıyla yapılabilir.
• Sağlık kontrollerinin başarılı olması için Google sağlık denetleyicisi (health checker) kaynak aralıklarına backend hedeflerine veya Pod’lara her zaman izin verin. Bazı dağıtımlarda GKE, k8s-fw kurallarını otomatik olarak oluşturur; eğer kısıtlayıcı kurallar eklerseniz, sağlık denetleyicisi aralıkları için açık izinleri koruyun.
• L4 backend’ler için örnek yaklaşım: node’ları “application” ile etiketleyin ve izin verilen istemci CIDR’larından ve Google sağlık kontrolü aralıklarından gelen tcp:NodePort trafiği için bir izin (allow) güvenlik duvarı kuralı ve düşen paketleri (drop) gözlemlemek için günlük kaydı (logging) ile birlikte diğer tüm kaynaklar için daha yüksek öncelikli bir engelleme (deny) kuralı oluşturun.

Ağ politikaları ve dataplane v2

• Kubernetes NetworkPolicy’yi etkinleştirin ve iptables tabanlı motorlara kıyasla performansı ve doğruluğu (fidelity) artıran eBPF tabanlı zorlama (enforcement) için GKE Dataplane V2’yi kullanın.
• Temel duruş:
  • Namespace’ler için varsayılan olarak egress ve ingress trafiğini engelleyin; Pod’dan Pod’a ve Pod’dan Service’e akışlara açıkça izin verin.
  • Servis katmanları (frontend, backend, data) oluşturmak için namespace ve podSelector’ları kullanın ve yalnızca minimum düzeyde gerekli yönlere ve portlara izin verin.
• Güvenli servis iletişimi:
  • Küme içi sıfır güven (zero trust) için mTLS en iyi bir service mesh tarafından sağlanır; NetworkPolicy L3/L4’ü yönetir ve kimlikleri doğrulayamaz.
  • Kuzey-güney trafiği için, kullanıcıları etkilemeden şüpheli saldırganlar üzerinde bir engellemeyi (deny) test etmek amacıyla WAF, hız sınırlama (rate limiting) ve önizleme modu için HTTP(S) LB’lere Cloud Armor ekleyin.

Hata modları ve ödünleşimler

• Çok sayıda veya aşırı geniş NetworkPolicy’ler beklenmedik paket düşüşlerine (drop) neden olabilir; aşamalı dağıtımlar (staged rollouts), günlük kaydı (logging) ve politika açıklama araçlarıyla doğrulayın.
• NodePort ve harici güvenlik duvarı kurallarına güvenmek kırılgandır; yönetilen yük dengeleyicileri ve Pod NEG’leri tercih edin.
• Gateway API daha zengin özellikler sunar ancak controller olgunluğu ve ekip aşinalığı gerektirir; her sürüm kanalına (release channel) göre header tabanlı yönlendirme veya mTLS passthrough gibi özellikleri doğrulayın.

Çoklu küme, service mesh ve kimlik

Çoklu küme servisleri ve filo ağı

• Kümeler arası servis keşfi ve yük dengeleme için Multi-Cluster Services (MCS) kullanmak üzere kümeleri bir filoya kaydedin. Her kümeden servisleri dışa aktarın; istemciler, kümeler arasındaki uç noktalar tarafından desteklenen tek bir DNS adını çözer.
• Kümeler arası trafik desenleri:
  • Aynı VPC, farklı alt ağlar: trafik, optimum maliyet ve gecikme ile özel RFC1918 üzerinden akar.
  • Farklı VPC’ler: geçişkenlik (transitivity) olmaksızın özel, basit bağlantı için VPC Peering ile bağlanın veya kuruluşlar farklıysa ya da internet üzerinden şifreleme gerekiyorsa Cloud VPN/Cloud Router kullanın. Merkezi yönetim için Shared VPC, yalnızca gerekli alt ağları servis projelerine sunar.
• Hata modları:
  • Çakışan CIDR’lar yönlendirmeyi engeller; peering veya VPN’den önce PodCIDR ve ServiceCIDR arasında çakışma olmadığından emin olun.
  • DNS split-horizon sorunları kümeler arası çözümlemeyi bozabilir; arama yollarını (search paths) ve taslak alan adlarını (stub domains) doğrulayın.

Service mesh, doğu-batı (east–west) ve gözlemlenebilirlik

• Aşağıdakiler için Anthos Service Mesh gibi bir service mesh dağıtın:
  • Güçlü iş yükü kimliği ile mTLS, trafik politikası (yeniden denemeler, zaman aşımları, aykırı değer tespiti) ve trafik bölme.
  • Mesh federasyonu veya çoklu birincil (multi-primary) topolojilerle kümeler arasında tutarlı doğu-batı politikası.
  • Zengin telemetri: iş yükü başına altın sinyaller (golden signals), istek izleri ve politika denetimleri.
• Artıları ve eksileri:
  • Sidecar’lar kaynak yükünü artırır; ambient veya sidecar’sız modlar maliyeti düşürebilir ancak özellik denkliğini doğrulayın.
  • Mesh, kontrol düzlemi bağımlılıkları ekler; yüksek erişilebilirlikli (HA) kontrol düzlemleri ve kontrollü performans düşüşü (graceful degradation) için tasarım yapın.

İş yükü kimliği, gizli anahtarlar (secrets) ve en az ayrıcalık ilkesi

• Uzun ömürlü anahtarları ortadan kaldırarak Kubernetes Service Account’larını (KSA) Google service account’larına (GSA) eşlemek için Workload Identity kullanın. KSA’yı GSA e-postası ile notlandırın (annotate) ve GSA’ya minimum IAM rollerini verin.
• Gizli anahtar (secret) yönetimi:
  • Gizli anahtarları çalışma zamanında bağlamak (mount) için CSI sürücüsü ile Secret Manager’ı tercih edin; hassas veriler için düz Kubernetes Secret’larını kaldırın veya saklanacaklarsa CMEK ile durağan haldeyken (at rest) şifreleyin.
  • GSA’da gizli anahtarlara ve bucket’lara en az ayrıcalıklı erişim verin. Proje genelindeki rollerden kaçının; uygun olduğunda storage.objectViewer gibi kaynak seviyesindeki rollerle kapsamı daraltın.

Dayanıklılık ve güvenli platform tasarımıyla ilgili dikkat edilmesi gerekenler

• Yüksek erişilebilirlik için bölgesel (regional) kümeler; node’ları zone’lara yayın. Kuzey-güney (north–south) için, küresel kullanıcılara en düşük gecikmeyi sağlamak amacıyla global HTTP(S) yük dengeleme kullanın.
• Kontrol düzlemi bağlantısı: özel kontrol düzlemlerini seçin; Authorized Networks ile kesinlikle gerekli olmadıkça halka açık erişimden kaçının.
• Giden trafik (Egress): harici IP’leri olmayan node’lar ile Cloud NAT ve PGA, güvenlik ve işlevselliği dengeler.
• Gözlemlenebilirlik: politika düşüşlerini veya gecikme artışlarını hızla teşhis etmek için güvenlik duvarı günlük kaydını, VPC Flow Logs’u ve mesh telemetrisini etkinleştirin.

Pratik Problem Senaryosu

Contoso Retail, us-east1 ve europe-west1 bölgelerinde iki adet özel (private) GKE bölgesel kümesi işletmektedir. Gereksinimler: node’larda harici IP olmaması, güvenli gelen trafiğin (ingress) kurumsal CIDR’larla sınırlandırılması, bir vitrin (storefront) servisi için küresel erişilebilirlik, internete maruz kalmadan imaj çekme (image pull) ve API katmanı için kümeler arası yük devretme (failover). Daha önce bir yoğunluk sırasında Pod IP tükenmesi sorunu yaşamışlardı.

Yaklaşım

1. Geniş ikincil aralıklara sahip VPC-native alt ağlar tasarlayın.

   • Gerekçe: Her bölge için 100 node × 200 Pod/node ve 1.500 servisi %20-30’luk bir payla karşılamak üzere bir /17 Pod aralığı ve bir /21 Servis aralığı ayırın. Bu, Pod IP tükenmesinin tekrarlanmasını önler ve büyüme sırasında yeniden IP ataması yapmaktan kaçınır.

2. Özel kontrol düzlemi uç noktalarına sahip özel kümeler oluşturun.

   • Gerekçe: Kontrol düzleminin VPC’ye maruz kalmasını sınırlar. Operatörler, bir yönetim alt ağındaki bir bastion üzerinden bağlanır. Bu, Authorized Networks ile halka açık uç noktalarına kıyasla saldırı yüzeyini azaltır.

3. Node alt ağlarında Cloud NAT ve Private Google Access’i etkinleştirin.

   • Gerekçe: Node’ların harici IP’leri yoktur ancak yine de Artifact Registry’den imaj çekmeleri ve işletim sistemi/paket yansımalarına (mirrors) ulaşmaları gerekir. PGA, halka açık kaynak IP’leri olmadan Google API erişimini sağlar; Cloud NAT ise gerektiğinde Google dışı giden trafiği (egress) yönetir.

4. Pod NEG’leri ile Gateway API kullanarak global HTTP(S) gelen trafiğini (ingress) uygulayın.

   • Gerekçe: Tek bir global anycast VIP, dünya çapındaki kullanıcılar için gecikmeyi azaltır. GKE Pod NEG’leri, sağlık kontrollerini doğrudan Pod’lara gönderir ve hata tespitini iyileştirir. Gateway API, altyapı Gateway’leri ile uygulamaya ait Route’lar arasında net bir ayrım sağlar.

5. İstemci erişimini kısıtlayın ve sağlık kontrollerine izin verin.

   • Gerekçe: Yalnızca kurumsal CIDR’lara izin vermek için bir Cloud Armor politikası ekleyin; yeni engellemeleri güvenli bir şekilde değerlendirmek için varsayılan olarak reddetme (default deny) ve önizleme modu (preview mode) kullanın. Ek olarak, VPC güvenlik duvarı kurallarının, sağlık kontrollerinin yeşil kalması için Google sağlık kontrolü kaynak aralıklarının arka uç (backend) NEG’lerine erişimine izin verdiğinden emin olun.

6. GKE Dataplane V2 ile NetworkPolicy uygulayın.

   • Gerekçe: Her namespace için gelen (ingress) ve giden (egress) trafiği varsayılan olarak reddedin; yalnızca ön uçtan (frontend) arka uca (backend) ve arka uçtan veritabanına giden portlara izin verin. Dataplane V2, politikaları eBPF ile verimli bir şekilde uygular ve ele geçirilmiş Pod’lar için etki alanını (blast radius) daraltır.

7. Filo genelinde Multi-Cluster Services’ı etkinleştirin.

   • Gerekçe: API servisini her iki bölgede de dışa aktarın ve tek bir DNS yayınlayın. İstemciler, kümeler arasındaki sağlıklı uç noktalara otomatik olarak yük devreder. Her iki küme de bölgesel alt ağlarla aynı VPC’de olduğundan, bölgeler arası trafik özel kalır ve minimum ek yük oluşturur.

8. Doğu-batı (east–west) güvenliği ve gözlemlenebilirlik için bir service mesh benimseyin.

   • Gerekçe: Servisler arasında mTLS’i zorunlu kılın, yeniden deneme/zaman aşımı bütçeleri ekleyin ve rota başına metrikler ve izler (traces) alın. Mesh seviyesi politika, NetworkPolicy’yi tamamlar: NetworkPolicy L3/L4 erişilebilirliğini kontrol ederken; mesh, L7’de servis kimliklerini doğrular ve yetkilendirir.

9. İş yükü kimliklerini ve gizli anahtarları (secrets) sıkılaştırın.

   • Gerekçe: Workload Identity aracılığıyla KSA’ları dar kapsamlı GSA’lara eşleyin; rapor alıcıları için yalnızca storage.objectViewer gibi gerekli rolleri verin. Manifest’lerdeki statik gizli anahtarlardan kaçınmak için kimlik bilgilerini Secret Manager CSI aracılığıyla dağıtın.

10. Kapasite ve günlük kaydı için koruma mekanizmaları (guardrails) uygulayın.

    • Gerekçe: IP kullanımını dengelemek için max-pods-per-node değerini dikkatli bir şekilde ayarlayın. İkincil aralık kullanımını ve VPC Flow Logs’u izleyin. İzin verilen yolları korurken istenmeyen istemci trafiğini ortaya çıkarmak için uygulama etiketi üzerinde günlük kaydı ile açık, yüksek öncelikli bir her şeyi reddet (deny-all) güvenlik duvarı kuralı oluşturun.

Bu tasarım, varsayılan olarak özel (private-by-default) olan, kontrollü kuzey-güney (north–south) erişimine sahip, dayanıklı çoklu küme yük devretme (failover) yeteneği olan, ilkeli en az ayrıcalık kimliğine sahip ve tekrarlayan IP tükenmesi olmadan ölçeklenebilen bir veri düzlemi (dataplane) ortaya çıkarır.

← Yönlendirme · Tüm alanlar · Ağ Gözlemlenebilirliği →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Google'a göz atın →