Google ACE: Konteynerler, Uygulama Barındırma ve Sunucusuz Platformlar — Çalışma kılavuzu

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Şunun bir parçası: Google Associate Cloud 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 Cloud, tam yönetilen sunucusuz platformlardan yapılandırılabilir Kubernetes kümelerine kadar, konteynerleri ve uygulamaları çalıştırmak için bir dizi platform sunar. Doğru platformu seçmek ve işletmek; kontrol düzlemlerini, ölçeklendirme modellerini, sürüm mekanizmalarını, ağ yapılandırmasını ve güvenliği anlamayı gerektirir. Bu bölüm, Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine ve Cloud Functions için operasyonel rehberliği; gizli anahtar yönetimi, güvenli dağıtım ve teşhis kalıplarıyla birlikte bir araya getirir.

Kubernetes Engine: Kümeler, İş Yükleri ve Ağ

GKE kümeleri, sizin boyutlandırdığınız ve güvence altına aldığınız düğüm havuzlarına sahip, yönetilen bir Kubernetes kontrol düzlemi sağlar. Minimum operasyonel yük ve standartlaştırılmış varsayılanlar için Autopilot’ı, düğümler, ağ ve eklentiler üzerinde ayrıntılı kontrol için ise Standard’ı seçin. Tahmin edilebilir, güvenli yükseltmeler için sürüm kanallarını ve düğüm otomatik yükseltmeyi kullanın; düğüm otomatik onarımını etkinleştirin. Belirli paketler Ubuntu gerektirmedikçe, sıkılaştırılmış düğümler için Container-Optimized OS’i tercih edin.

• Düğüm havuzları ve zamanlama

  • Düğüm havuzlarını iş yükü sınıfına göre (ör. genel, GPU, spot) ayırın ve Pod’ları yönlendirmek için taint’ler/toleration’lar kullanın.
  • Küme otomatik ölçeklendiriciyi etkinleştirin ve havuz başına min/maks değerlerini yapılandırın. PodDisruptionBudget’ların ve kaynak taleplerinin, küçülmeyi engelleyebileceğini veya talepler mevcut düğüm şekillerini aşarsa Pod’ları bekleyen durumda bırakabileceğini unutmayın.
  • Spot/öncelikli olarak sonlandırılabilir düğümler maliyeti düşürür ancak tahliye riski getirir; dayanıklılık için Deployment artış bütçeleri ve Pod topoloji kısıtlamaları ile birleştirin.

• Namespace’ler ve çoklu kiracılık

  • Kotaları, politikaları ve RBAC’yi bölümlendirmek için namespace’leri kullanın. Doğu-batı trafiğini kısıtlamak için NetworkPolicies uygulayın. Ayrıcalıklı iş yüklerinden kaçınmak için Pod Güvenlik standartlarını namespace kapsamında zorunlu kılın.

• İş Yükleri

  • Deployment’lar, durum bilgisi olmayan (stateless) Pod’ları sıralı güncellemeler, artış/kullanılamaz bütçeleri ve hızlı geri almalar ile yönetir. Trafiği kontrol etmek için readiness probe’larını, otomatik iyileştirme için ise liveness/startup probe’larını kullanın. Yanlış yapılandırılmış readiness probe’ları trafiği karadeliğe düşürebilir; üretimden önce test edin.
  • StatefulSet’ler, veritabanları ve çoğunluk tabanlı sistemler için kararlı kimlikler ve sıralı ölçeklendirme sağlar. Başsız (headless) bir Service ve dinamik provizyonu destekleyen bir StorageClass kullanın; bölgesel (zonal) PV yerelliğini planlayın.
  • DaemonSet’ler, her düğüme bir Pod zamanlar (ör. günlükleme/izleme ajanları). Otomatik ölçeklendirme ve boşaltma (drain) olaylarına uyum sağlarlar ve düğüm çapında telemetri için idealdirler.

• Service’ler ve Ingress

  • ClusterIP, küme içi DNS ve yük dengeleme sunar. NodePort, öncelikle sorun giderme amaçlıdır. LoadBalancer, bir Google Cloud harici veya dahili TCP/UDP yük dengeleyici sağlar; özel servisler için dahili olanı kullanın.
  • GKE Ingress, yönetilen sertifikalar, URL haritaları ve Cloud Armor ile küresel HTTP(S) yük dengelemeyi yapılandırır. Modern trafik yönetimi için, Pod başına sağlık kontrolleri ve daha hızlı yakınsama sağlayan konteyner-yerel yük dengelemeyi (NEG) tercih edin. Hazır olma (readiness) uç noktalarının gerçek uygulama sağlığını yansıttığından emin olun; aksi takdirde arka uç sağlıksız hale gelir ve 502 hatalarına neden olur.

• Otomatik Ölçeklendirme

  • Horizontal Pod Autoscaler, CPU gibi metriklere veya Cloud Monitoring aracılığıyla özel metriklere göre replikaları ölçeklendirir; Metrics Server’ın sağlıklı olduğundan emin olun. Vertical Pod Autoscaler, talepleri doğru boyutlandırabilir; HPA tarafından yönetilen iş yükleri için VPA’yı “tavsiye” modunda kullanarak veya HPA+VPA uyumlu modunu dikkatli bir şekilde kullanarak HPA ile çakışmaları önleyin.
  • Küme otomatik ölçeklendirici, Pod’ları sığdırmak için düğüm ekler/kaldırır. Pod’lar herhangi bir düğüm şeklinin sunduğundan daha fazla kaynak talep ederse, asla zamanlanmazlar; talep/limitleri düğüm havuzu şekilleriyle hizalayın.

Kısa örnekler:

• Bozuk bir sürümü geri almak:

undefined

• Başka bir bağlamı hızlıca incelemek:

undefined

Yapıt Yönetimi, Tedarik Zinciri Güvenliği ve Güvenli Sürümler

Artifact Registry, VPC Service Controls desteği ile bölge başına konteyner imajlarını barındırır. Ortamlar için ayrı repolar (veya önekler) benimseyin ve değiştirilemez etiketleri zorunlu kılın; belirsizliği ortadan kaldırmak için özet (digest) ile dağıtım yapın. Kaynak kökeni (provenance) üst verisi ile derlemek ve göndermek için Cloud Build’ı veya kendi CI’ınızı entegre edin.

• Güvenlik açığı yönetimi

  • İşletim sistemi ve dil CVE’leri için imajları taramak üzere Artifact Analysis’i etkinleştirin. Yüksek önem dereceli bulgularda derlemeleri durdurun veya yükseltmeyi engelleyin. GKE’ye kabul edilmeden önce imza/onay (ör. güvenlik açığı politikası onayı, SLSA provenance) gerektirmek için bunu Binary Authorization ile birleştirin.

• İmaj yükseltme

  • Bir imaj özetini dev’den staging/prod repolarına kopyalayarak veya bir yükseltme reposunda yeniden etiketleyerek yükseltme yapın; değiştirilebilir “latest” etiketinden kaçının. Test ve tarama sonuçlarına bağlı Cloud Build tetikleyicileri ile otomatikleştirin.

• Gizli anahtarlar ve yapılandırma

  • En az ayrıcalıklı erişimle Secret Manager’ı tercih edin. GKE’de, düğümlerin uzun ömürlü gizli anahtarları asla görmemesi için Workload Identity ile Secret Manager CSI sürücüsünü kullanın. KRM yapılandırmaları için ConfigMap’i (gizli olmayan) Secret’tan (hassas) ayırın ve salt okunur olarak bağlayın.
  • Sunucusuz platformlar için, gizli anahtarları doğrudan Secret Manager bağlantıları aracılığıyla bağlayın; kesinlikle gerekli olmadıkça gizli anahtarları ortam değişkenlerine gömmekten kaçının.

• Geri alma ve sürüm kalıpları

  • Kubernetes: kesintisiz dağıtım için maxUnavailable=0 ile sıralı güncellemeleri ve kapasiteye göre ayarlanmış maxSurge’ü kullanın; bir Service arkasındaki iki Deployment ile kanarya (canary) dağıtımı yapın veya kademeli yüzdeler için Service mesh kullanın. Kritik iş yüklerini PodDisruptionBudget’lar ve minReadySeconds ile koruyun.
  • Cloud Run ve App Engine: kanarya ve mavi/yeşil (blue/green) dağıtımlar için revizyonları/sürümleri ve trafik bölmeyi kullanın. Geri alma gecikmesini azaltmak için önceki revizyonları sıcak tutun.
  • Hata modları: değiştirilebilir etiket kayması, tarama zamanı boşlukları ve yanlış yapılandırılmış hazır olma denetimleri, kesintilerin yaygın nedenleridir. İmaj özetlerini, dağıtım öncesi kontrolleri ve sentetik sağlık denetimlerini kullanın.

Sunucusuz Uygulama Platformları

Cloud Run, otomatik olarak sıfıra ölçeklenme ve istek başına kimlik zorlaması özelliklerine sahip, konteyner tabanlı, istek odaklı işlem gücü sağlar.

• Cloud Run servisleri ve işleri (jobs)

  • Servisler HTTP isteklerini işler; eş zamanlılık (concurrency), örnek başına düşen anlık istek sayısını kontrol eder (gecikme ve verimlilik arasında denge kurmak için ayarlayın). İşler (jobs), HTTP dışı toplu iş/cron görevlerini yürütür ve paralelleştirilebilir.
  • Revizyonlar (revisions) değiştirilemez anlık görüntülerdir (snapshot). Trafik bölme, yüzdelik oranla canary dağıtımı sağlar. Soğuk başlatmaları (cold start) azaltmak için minimum örnek (instance) sayısını ayarlayın; arka plan işi gerekiyorsa boştayken CPU tahsisi kullanın.
  • Kimlik: Her servis/revizyon için en az ayrıcalık ilkesiyle adanmış bir hizmet hesabı atayın. Çağırmayı IAM (Cloud Run Invoker rolü) aracılığıyla kısıtlayın veya gerekirse herkese açık yapın. Son kullanıcı kimlik doğrulaması için imzalı IAP jetonları veya Identity Platform ile Cloud Run’ın yerleşik kimlik doğrulama özelliğini kullanın.

• Ağ (Networking)

  • Özel VPC kaynaklarına ulaşmak için Sunucusuz VPC bağlayıcıları (connectors) kullanın. Çıkış (egress) trafiğini seçin: tüm trafik bağlayıcı üzerinden veya yalnızca özel RFC1918 aralıkları. Bağlayıcının verim (throughput) kotalarına dikkat edin; bağlayıcının boyutunu ölçeklendirin ve servisle aynı bölgede olacak şekilde hizalayın. Yalnızca özel IP’li kaynaklarla giden internet trafiği için Cloud NAT ile birleştirin.
  • Private Service Connect, üretici (producer) servisleri özel olarak tüketebilir veya dahili uç noktaları (endpoint) kullanıma sunabilir. Harici HTTP(S) üzerinden veri alımı (ingest) için sunucusuz NEG’ler ile Cloud Load Balancing kullanın.

App Engine iki ortam sunar:

• Standart (Standard)
  • Korumalı alan (sandbox) içinde çalışır, hızla ölçeklenir, otomatik, temel veya manuel ölçeklendirmeyi destekler. min_idle_instances ile otomatik ölçeklendirme, önceden ısıtılmış kapasite sağlar. Hızlı soğuk başlatma ve basit dağıtım modeli; sınırlı işletim sistemi seviyesinde özelleştirmeler ve sabit bir çalışma zamanı (runtime) seti vardır.
• Esnek (Flexible)
  • Sistem kütüphaneleri ve ağ üzerinde daha fazla kontrol ile Compute Engine VM’leri üzerinde Docker çalıştırır. Daha yavaş örnek (instance) yaşam döngüsü ve daha yüksek taban maliyet; özel çalışma zamanları (runtime) veya yerel (native) kütüphaneler gerektiğinde uygundur.
• Servisler ve sürümler
  • Trafiği sürüme göre bölün (rastgele, çerez veya IP). Her servis bağımsız olarak ölçeklenebilir. Kademeli dağıtımlar kullanın ve anında geri alma (rollback) için önceki bir sürümü koruyun.

Cloud Functions, olay güdümlü, tek amaçlı fonksiyonlar sağlar.

• Tetikleyiciler (Triggers): Pub/Sub, Cloud Storage, HTTP, birçok kaynak için Eventarc. İşleyicileri (handler) birim etkili (idempotent) yapın; bazı tetikleyiciler hata durumunda yeniden deneyerek yinelenen işlemeye yol açar.
• Çalışma zamanı (runtime) yapılandırması: ortam değişkenleri, Secret Manager bağlamaları, maksimum örnek (instance) sayısı, bellek/CPU. Gecikme ve maliyeti dengelemek için HTTP fonksiyonlarında eş zamanlılığı (concurrency) kontrol edin.
• Sık karşılaşılan tuzaklar: sınırsız eş zamanlılık veya birim etkili olmayan yan etkiler veri tekrarına neden olur; Pub/Sub için DLQ’ların (teslim edilemeyen mesaj kuyruğu) olduğundan emin olun; uygun zaman aşımları ayarlayın.

Platform Seçimi, Ağ (Networking) ve Operasyonel Sahiplik

Gereken kontrol, ölçeklenme özellikleri, taşınabilirlik ihtiyaçları ve operasyon bütçesine göre bir platform seçin.

• Kontrol ve ek yük (overhead) karşılaştırması

  • En yüksek kontrol: GKE Standard (düğüm işletim sistemi, ağ, güvenlik eklentileri) ve buna karşılık gelen operasyonel ek yük.
  • Dengeli: GKE Autopilot (düğüm yönetimi yok, standartlaştırılmış güvenlik).
  • En düşük ek yük: Cloud Run, App Engine, Cloud Functions (düğüm yok, yönetilen ölçeklendirme), ancak çalışma zamanı (runtime) ve istek modelleriyle sınırlıdır.

• Ölçeklenme ve iş yükü uyumu

  • Ani artış gösteren (spiky) istek iş yükleri: Cloud Run/App Engine Standard bu konuda öne çıkar; olay tabanlı işleyiciler (handler’lar) için Functions kullanılır.
  • Durum bilgisi tutan (stateful) veya özel ağ yapılandırması: StatefulSets ve CNI özellikleriyle GKE.
  • Taşınabilirlik: GKE/Cloud Run üzerindeki container’lar; Functions, FaaS modeli nedeniyle daha az taşınabilirdir.

• Sunucusuz (Serverless) ağ yapılandırması, dışa trafik (egress) ve özel servisler

  • Özel erişim için VPC bağlayıcıları (connector) kullanın; kısıtlamayı (throttling) önlemek için bağlayıcı kullanımını izleyin. Dışa trafiği (egress) yalnızca gerektiğinde “all” olarak ayarlayın; aksi takdirde maliyeti ve riski azaltmak için özel aralıklarla (private ranges) sınırlayın.
  • Özel içe trafik (ingress) için, sunucusuz NEG’ler (serverless NEGs) veya Private Service Connect ile dahili HTTP(S) yük dengelemeyi değerlendirin.
  • Veri sızıntısı kontrolü için, desteklendiği yerlerde VPC Service Controls ile eşleştirin ve güvenlik duvarı ile Cloud NAT aracılığıyla dışa trafik rotalarını (egress routes) kısıtlayın.

• Teşhis (Diyagnostik) ve operasyonel sahiplik

  • Servisler arası korelasyon için yapılandırılmış loglar (JSON) ve iz/aralık (trace/span) kimlikleri ile Cloud Logging’i standartlaştırın. Cloud Monitoring panolarını, çalışma süresi kontrollerini (uptime checks), SLO’ları ve uyarı politikalarını kullanın.
  • GKE için: Cloud Ops for GKE’yi etkinleştirin, Prometheus veya Cloud Monitoring aracılığıyla uygulama metriklerini toplayın (scrape) ve düğüm seviyesinde telemetri için DaemonSets kullanın.
  • Sunucusuz (Serverless) için: yerleşik istek loglarından, Error Reporting, Trace ve Profiler’dan yararlanın. Gecikme, hata oranı ve doygunluk (eş zamanlılık, örnek CPU’su) üzerine servis başına SLO’lar ve uyarılar ayarlayın.
  • Sahiplik modeli: çalışma zamanı parametrelerinin (ölçeklenme, eş zamanlılık), IAM’in ve sürüm yayınlama işlem hatlarının (pipeline) kime ait olduğunu tanımlayın. Geri alma (rollback) ve felaket senaryolarını düzenli olarak test edin.

Pratik Problem Senaryosu

Acme Retail, dahili servislerini modernize ederken yeni bir ödeme (checkout) API’sini kullanıma sunmayı planlıyor. Gereksinimler: kanarya (canary) dağıtımları ile halka açık, düşük gecikmeli bir API, bir VPC içindeki dahili envanter veritabanına özel erişim, tedarik zinciri zorlaması ve minimum operasyonel ek yük ile net bir geri alma (rollback) süreci.

1. Halka açık API için Cloud Run’ı ve dahili envanter servisi için GKE Autopilot’ı seçin.

• Gerekçe: Cloud Run, durum bilgisi tutmayan (stateless) HTTP için operasyonel ek yükü en aza indirir, revizyonları ve trafik bölmeyi destekler; GKE Autopilot, düğüm yönetimi olmadan durum bilgisi tutan (stateful)/dahili servisler için Kubernetes özellikleri sağlar.

2. İmajları Artifact Registry’de kaynak bilgisi (provenance) ile birlikte oluşturun, tarayın ve saklayın.

• Gerekçe: Cloud Build, container imajları üretir; Artifact Analysis, CVE’ler için tarama yapar. Özetleri (digest) ve kaynak bilgisini (provenance) saklamak, Binary Authorization’ın yalnızca taranmış, imzalanmış imajların çalıştırılmasını zorunlu kılmasını sağlar.

3. Kabul politikalarını (admission policies) zorunlu kılın.

• Gerekçe: İmzaları ve politika onaylarını (attestation) zorunlu kılmak için GKE kümesinde Binary Authorization’ı etkinleştirin. Cloud Run için, dağıtım otomasyonunu, yükseltmeyi güvenlik açığı politikasının geçilmesine bağlayacak şekilde yapılandırın.

4. Ağı bir Serverless VPC connector ve Cloud NAT ile yapılandırın.

• Gerekçe: Cloud Run API’si, envanter servisine ve Cloud SQL’e özel olarak erişmelidir. Bir VPC connector, özel RFC1918 dışa trafiğine (egress) izin verir; Cloud NAT, özel kaynaklarda harici IP’ler olmadan bağımlılık indirmeleri için giden internet erişimi sağlar. Bağlayıcıyı ve servisleri aynı bölgede tutun ve işlem hacmini (throughput) doğru boyutlandırın.

5. Kimlikleri ve izinleri güvenli hale getirin.

• Gerekçe: Cloud Run servisine en az ayrıcalık ilkesiyle (örneğin, Cloud SQL Client, gerekirse dahili uç noktalara çağırma (invoke) izinleri) özel bir hizmet hesabı atayın. GKE için, Pod’ların düğüm seviyesinde kimlik bilgileri olmadan hizmet hesaplarını üstlenmesi (assume) için Workload Identity kullanın.

6. Güvenli sürüm yayınlama ve geri alma (rollback) uygulayın.

• Gerekçe: API’yi yeni bir Cloud Run revizyonuna dağıtın ve kanarya (canary) testi için trafiğin %5’ini ayırın. Gecikmeyi, hata oranını ve doygunluğu (saturation) izleyin; ardından trafiği %100’e yükseltin veya trafiği önceki revizyona geri döndürerek anında geri alın. GKE’de, tam dağıtımdan önce doğrulamak için hazır olma probları (readiness probes) ile Deployment sıralı güncellemelerini (rolling updates) ve aynı Service arkasında küçük bir kanarya (canary) Deployment’ı kullanın.

7. Gözlemlenebilirliği ve SLO’ları yapılandırın.

• Gerekçe: Her iki platformdan da iz kimlikleri (trace ID) ile yapılandırılmış JSON loglarını Cloud Logging’e gönderin. p95 gecikme ve 5xx hata oranı üzerine SLO’lar oluşturun; bunlara uyarı politikaları ekleyin. Kök neden analizi için Error Reporting ve Trace kullanın. GKE için, düğüm metrikleri için bir DaemonSet dağıtın ve Cloud Ops for GKE’yi etkinleştirin.

8. Hata modlarını ve kapasiteyi doğrulayın.

• Gerekçe: VPC connector işlem hacmini, Cloud Run eş zamanlılığını ve GKE HPA davranışını doğrulamak için yük testi yapın. Kara deliğe düşmeyi (blackholing) önlemek için hazır olma probunun (readiness probe) doğruluğunu teyit edin. Tedarik zinciri zorlaması altında kurtarılabilirliği sağlamak için binary authorization reddetme yollarını ve özete (digest) göre imaj geri almayı test edin.

Bu yaklaşım, Google Cloud operasyonel en iyi uygulamalarıyla uyumlu olarak, düşük operasyonlu ve güvenli bir halka açık API, kontrollü dahili servisler, özel ağ, zorunlu kılınabilir tedarik zinciri güvenliği ve hızlı geri alma (rollback) imkanı sunar.

← Compute Engine ve Sanal Makine İşlemleri · Tüm alanlar · VPC Ağ İletişimi →

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

Google'a göz atın →