> tpl_cld_012
Kubernetes Hazırlığı ve Üretim Yeterlilik Paketi
Kubernetes iş yükü kaynak boyutlandırmasını (CPU/bellek istek ve sınırları), Pod Kesinti Bütçelerini (PDB), zarif kapatma (graceful termination), canlılık/hazırlık sondalarını (probes), NetworkPolicy kurallarını, HPA otomatik yatay ölçeklendirmesini ve admission controller yönetişimini denetleyen üretim yeterlilik puan kartı ve kontrol listesi.
İş yükü boyutlandırmasını, PDB'leri, sondaları, ağ politikalarını, ölçeklendirmeyi ve güvenlik kontrollerini denetleyen Kubernetes puan kartı.
Önemli Teknik Doküman Şablonu ve Hukuki Uyarı
TinyCTO.tv Teknik Doküman Şablon Bildirimi: Bu şablon genel eğitim ve operasyon amaçlı bir başlangıç materyalidir. Hukuki, vergisel, muhasebesel, yatırım, satın alma, mevzuat, güvenlik veya sertifikasyon danışmanlığı değildir. Gereklilikler ülkeye, kuruma, sözleşmeye ve riske göre değişir. Kullanmadan önce yetkin uzmanlarla gözden geçirip uyarlayın.
Çözülen Üretim Problemi
Mühendislik ekipleri kaynak sınırları (limits) belirlemeden, probes ve Pod Disruption Budget tanımlamadan Kubernetes'e uygulama dağıtır; bu da ardışık OOM-kill çökmelerine, düğüm güncellemelerinde kesintilere ve namespace'ler arası denetimsiz yatay saldırılara yol açar.
Ne Zaman Kullanılmalı?
- •EKS, GKE veya AKS kümelerine dağıtılacak yeni mikroservisler için resmi üretime geçiş denetimleri yürütürken
- •Yoğun trafikli ticari lansmanlar veya sezonluk zirve dönemleri öncesinde küme dayanıklılık ayarlarını denetlerken
- •CNCF sıkılaştırma kılavuzları, Pod Güvenlik Standartları ve Kyverno/Gatekeeper politikalarına uyumu doğrularken
Ne Zaman Kullanılmamalı?
- •Terraform ile fiziksel veya bulut altyapısı tedariki için (TPL-CLD-011 kullanın)
- •Konteyner imaj zafiyet taramaları ve yazılım tedarik zinciri onayları için (TPL-SEC-015 kullanın)
5 Şablon Bölümü ve Yapısal İskelet
Her konteyner için sıfır olmayan CPU ve bellek requests/limits zorunluluğu. Gürültülü komşu etkisini ve kontrolsüz bellek sızıntılarının OOM-killer tetiklemesini önlemek için Guaranteed/Burstable QoS yapılandırması.
Farklı AZ'lere dağılmış çoklu replikalar (en az 3 pod), Pod Disruption Budget (minAvailable veya maxUnavailable) ve topologySpreadConstraints ile düğüm güncellemelerinde kesintisiz çalışma güvencesi.
Kalibre edilmiş startup, liveness ve readiness probes tanımları. Devam eden HTTP isteklerini tamamlamak için preStop kancası ve en az 30 saniyelik terminationGracePeriodSeconds yapılandırması.
Namespace bazında varsayılan engelleme (default-deny) NetworkPolicy kuralları. Pod çıkış trafiğini (egress) sadece onaylı FQDN ve portlara sınırlayarak küme içi yatay saldırıları engelleme.
Restricted güvenlik profili zorunluluğu: runAsNonRoot, readOnlyRootFilesystem, tüm yetkileri düşürme (drop ALL), allowPrivilegeEscalation: false. Kyverno/Gatekeeper ile ayrıcalıklı podların reddedilmesi.
Doldurma ve Uygulama Yönergeleri
Bağımsız İnceleme ve Onay Kontrol Listesi
- Tüm zorunlu bölümler dolduruldu
- Gizli anahtar veya parola içermiyor
- Yönetici sponsor onayı alındı
Kubernetes Hazırlığı ve Üretim Yeterlilik Paketi - Örnek Vaka Analizi
Örnek Organizasyon: Fintek Ödeme Platformu (Çoklu AZ Yönetilen AWS EKS Kümesinde 80+ Mikroservis)
Fintek Ödeme Platformu (Çoklu AZ Yönetilen AWS EKS Kümesinde 80+ Mikroservis) için eksiksiz operasyonel uygulamayı gösteren gerçek dünya vaka analizi.
- •PDB ve 35 saniyelik preStop kancaları ile düğüm yükseltmelerindeki kesintiyi 0 milisaniyeye indirdi
- •Doğru kalibre edilmiş bellek sınırları ve Guaranteed QoS ile 12 worker düğümündeki OOM çökmelerini önledi
- •Tüm üretim namespace'lerinde CNCF Restricted Pod Güvenlik Standartlarına %100 uyum sağladı
Sıkça Sorulan Sorular
Pod Disruption Budget (PDB) eksikliği rutin Kubernetes düğüm güncellemelerinde neden kesintiye yol açar?
Düğüm güncellemesi sırasında node drain çalıştırıldığında Kubernetes podları tahliye eder. Eğer PDB ile minimum çalışan kopya sayısı korunmazsa, tüm podlar aynı anda öldürülebilir ve yeni podlar hazır hale gelene kadar servis tamamen kesintiye uğrar.
Readiness probe bağımlılıkları kontrol ederken liveness probe neden sadece lokal kalmalıdır?
Harici bir veritabanı yavaşladığında liveness probe hata verirse Kubernetes podu yeniden başlatır. Tüm replikalar aynı anda yeniden başlatıldığında sistem sonsuz bir çökme döngüsüne (crash loop) girer. Trafik kesme işini readiness probe yapmalı, liveness probe ise sadece uygulamanın kilitlenip kilitlenmediğini izlemelidir.
Ani trafik patlamalarında Horizontal Pod Autoscaler (HPA) ile küme ölçeklendirici (cluster autoscaler) nasıl etkileşime girer?
Beklenmeyen bir trafik artışında HPA, CPU/bellek veya özel metrikleri (kuyruk derinliği) izleyerek pod sayısını artırır. Mevcut worker düğümlerinde yeterli yer yoksa yeni podlar Pending durumuna geçer; bu durum küme ölçeklendiriciyi (veya Karpenter'ı) tetikleyerek 45-90 saniye içinde yeni sanal sunucuların devreye alınmasını sağlar.
Teknik Doküman Şablon Paketi
Giriş GerekliTüm boş şablonları, işlenmiş senaryoları ve doğrulama manifestolarını tek bir arşivde indirin.
Yetkili Standartlar ve Kaynaklar
- Kubernetes Pod Security Standards (Baseline & Restricted Profiles)Kubernetes.io • OFFICIAL REQUIREMENT
- NSA / CISA Kubernetes Hardening Cybersecurity Technical ReportNSA / CISA • OFFICIAL REQUIREMENT
- CNCF Production Readiness & Reliability Best PracticesCloud Native Computing Foundation (CNCF) • OFFICIAL REQUIREMENT