Kazanimlar:
- Kubernetes'in temel nesnelerini (Pod, Deployment, Service, ConfigMap, Secret, Namespace) ve bildirimsel felsefesini kavrayıp yapay zekaya sağlam manifestler ürettirebilme
- Kaynak limiti, sağlık kontrolleri (probe), sabit imaj etiketi ve dar RBAC ile manifestleri üretime hazır ve güvenli hale getirebilme
- Uygulamadan önce doğru context'i doğrulama ve dry-run/diff ile kuru çalıştırma disiplinini uygulayabilme
Bir tane konteyner çalıştırmak kolaydır. Ama yüzlerce konteyneri, onlarca sunucuya yayıp, biri çökünce otomatik yeniden başlatan, yük artınca çoğaltan, sıfır kesintiyle güncelleyen bir sistem kurmak? İşte bu orkestrasyondur ve endüstri standardı aracı Kubernetes (kısaca K8s) — konteynerleri bir küme (cluster) üzerinde otomatik dağıtan, ölçekleyen ve yöneten platformdur. Kubernetes güçlüdür ama karmaşıktır: her şey uzun, girintiye duyarlı YAML dosyalarıyla — manifest denir — tanımlanır. İşte YZ tam burada nefes aldırır; doğru bağlamla bu manifestleri hızla üretir ve gizemli hatalarını çözer.
Ancak Kubernetes'te bir yanlış manifest, tüm bir servisi ayağa kaldıramamak, yanlış ölçeklenmek veya bir güvenlik açığı bırakmak demektir. YZ'nin ürettiği her manifesti anlamak ve doğrulamak — özellikle kubectl apply yapmadan önce — sizin sorumluluğunuzdur.
Kubernetes'in temel nesneleri
Kubernetes'i denetlemek için ana kavramları bilmelisiniz:
- Pod: En küçük çalışma birimi; bir veya birkaç konteyneri barındırır. Genellikle doğrudan Pod değil, onu yöneten üst nesneler kullanılır.
- Deployment: Bir uygulamanın kaç kopya (replica) çalışacağını, hangi imajı kullanacağını ve nasıl güncelleneceğini tanımlar. Bir Pod çökerse otomatik yeniden yaratır.
- Service: Pod'lara sabit bir ağ adresi ve yük dengeleme (load balancing) sağlar; Pod'lar gelip gitse de erişim adresi değişmez.
- ConfigMap ve Secret: Yapılandırma değerlerini ve gizli bilgileri Pod'lardan ayrı tutar. ConfigMap açık ayarlar, Secret ise hassas değerler içindir.
- Namespace: Kaynakları mantıksal olarak bölen, izole eden alan (örneğin dev, prod).
- Ingress: Dış dünyadan kümedeki servislere HTTP trafiğini yönlendiren kural kümesi.
Helm ise Kubernetes'in "paket yöneticisi"dir: tekrar eden manifestleri şablonlaştırıp (chart) tek komutla, farklı ortamlara farklı değerlerle kurmanızı sağlar. YZ hem ham manifest hem de Helm chart üretir.
Neden bu kadar çok nesne var? Çünkü Kubernetes'in temel felsefesi bildirimsel (declarative) olmasıdır: siz "sistemin nihai olarak nasıl görünmesini istediğinizi" tanımlarsınız (örneğin "bu uygulamadan her zaman 3 kopya çalışsın"), Kubernetes ise mevcut durumu sürekli bu istenen duruma yaklaştırır. Bir Pod ölürse yenisini yaratır, bir düğüm düşerse iş yükünü başka düğüme taşır. Bu yüzden manifestler "yap" komutları değil, "böyle olsun" tarifleridir. Bu ayrımı kavramak, YZ'nin ürettiği manifestleri okurken kritiktir: her alan, sistemin arzu edilen halinin bir parçasını tanımlar. Yanlış bir alan, Kubernetes'in yanlış bir hedefe doğru çalışması demektir — ve o hedef sessizce, ısrarla uygulanır.
İpucu: Kubernetes'te en önemli güvenli deneme aracı kubectl apply --dry-run=server -f dosya.yaml'dır: manifesti gerçekten uygulamadan sunucunun kabul edip etmeyeceğini ve ne yapacağını gösterir. Bir manifesti prod'a uygulamadan önce mutlaka dry-run ve kubectl diff çalıştırın.
Adım adım: YZ ile manifest üretmek
- Uygulamayı ve ihtiyacı tarif et. İmaj adı, port, kaç replica, kaynak limitleri (CPU/bellek).
- Deployment + Service iste. Genelde ikisi birlikte gerekir.
- Yapılandırma ve secret'ı ayır. Ayarlar ConfigMap'e, hassas değerler Secret'e.
- Sağlık kontrollerini eklet. livenessProbe (canlı mı) ve readinessProbe (trafiğe hazır mı) kritiktir.
- Kaynak limiti koy. requests/limits olmadan bir Pod tüm düğümü tüketebilir.
- `--dry-run` ve `diff` ile doğrula, sonra uygula. Önce test namespace'inde.
Güvenlik: Kubernetes'e özgü riskler
- Secret gerçekten gizli değildir — sadece base64. Kubernetes Secret nesnesi, değerleri base64 ile kodlar; bu şifreleme değildir, kolayca çözülür. Gerçek gizlilik için etcd şifrelemesi ve harici kasa (Vault, cloud secret manager) gerekir. Secret manifestlerini asla düz Git'e commit etmeyin (bunun için Sealed Secrets/External Secrets gibi çözümler var).
- Kaynak limiti koyun. limits olmayan bir Pod, bellek sızıntısıyla tüm düğümü çökertebilir.
- En az yetki (RBAC). Role-Based Access Control ile her servis/kullanıcı yalnızca ihtiyacı olan izne sahip olsun. YZ bazen geniş cluster-admin verir; bunu daraltın.
- `latest` imaj etiketi kullanmayın. Hangi sürümün çalıştığını bilemez, geri alamazsınız.
Dikkat: kubectl delete veya yanlış bir apply, canlı bir Deployment'ı yok edebilir. Komutları çalıştırmadan önce hangi namespace'te olduğunuzu (kubectl config current-context) mutlaka doğrulayın; prod context'inde yanlışlıkla iş yapmak sık görülen bir felakettir.
Ham manifest vs. Helm tablosu
Kriter
Ham YAML manifest
Helm chart
Kurulum
kubectl apply -f
helm install
Çok ortam (dev/prod)
Kopyala-yapıştır, hataya açık
Tek chart, farklı values.yaml
Sürümleme/geri alma
Elle
helm rollback ile kolay
Öğrenme eğrisi
Düşük
Orta
Ne zaman
Küçük, tek ortam
Çok ortam, tekrar eden servis
Üç mini vaka
Vaka 1 — çöken servisin sırrı. Bir Pod sürekli yeniden başlıyordu (CrashLoopBackOff). Ekip logları ve manifesti YZ'ye verdi; YZ, readinessProbe'un yanlış porta bakması nedeniyle Pod'un asla "hazır" sayılmadığını gösterdi. Portu düzelttiler, servis 10 dakikada stabil oldu. Elle bu ilişkiyi kurmak saatler alabilirdi.
Vaka 2 — limit koymamak düğümü çökertti. Bir Deployment'ta limits yoktu; bir bellek sızıntısı Pod'u şişirdi ve tüm düğümü çökertip komşu servisleri de düşürdü. Olaydan sonra YZ'ye "tüm Deployment'lara makul CPU/bellek requests ve limits ekle" dedirtip standart hale getirdiler. Tek satırlık eksik, saatlerce kesintiye mal olmuştu.
Vaka 3 — geniş RBAC yakalandı. Bir inceleme sırasında, YZ'nin ürettiği bir ServiceAccount manifestinin cluster-admin rolüne bağlandığı görüldü — yani o servis tüm kümeyi yönetebiliyordu. Ekip izni yalnızca kendi namespace'indeki Pod'ları okumaya daralttı. En az yetki ilkesi bir güvenlik açığını kapattı.
Dört kopyalanabilir şablon
1) Deployment + Service üretme:
Kubernetes için bir Deployment ve Service manifesti yaz.Uygulama: [AD], imaj: [imaj:sabit-sürüm], port: [X], replica: [N].Kurallar:- CPU/bellek requests ve limits ekle.- livenessProbe ve readinessProbe tanımla.- Yapılandırmayı ConfigMap'ten, secret'ı Secret nesnesinden oku; değerleri manifeste gömme, yer tutucu kullan.- imaj etiketi ":latest" OLMASIN.Açıklamalı ver.
2) Manifest hatası çözme:
Şu Pod [CrashLoopBackOff / Pending / ImagePullBackOff] durumunda.Aşağıdaki manifest ve 'kubectl describe' çıktısına göre olası köknedenleri olasılık sırasıyla listele ve her biri için doğrulamakomutunu ver. Manifest: [YAML] Describe: [ÇIKTI]
3) Güvenlik/sağlamlık denetimi:
Bu Kubernetes manifestini denetle: kaynak limiti eksik mi, probyok mu, :latest etiketi var mı, aşırı geniş RBAC/izin var mı,secret manifeste gömülü mü? Bulguları önem sırasıyla vedüzeltmesiyle yaz. Manifest: [YAML]
4) Helm chart'a dönüştürme:
Aşağıdaki ham manifestleri yeniden kullanılabilir bir Helm chart'adönüştür: hangi değerler values.yaml'a çıkmalı (imaj, replica,kaynak, ortam)? Chart yapısını ve örnek values.yaml'ı göster.Manifestler: [YAML]
Zayıf prompt / Güçlü prompt
Zayıf: "Uygulamam için Kubernetes YAML'ı yaz."
Sonuç: prob'suz, limitsiz, :latest etiketli, secret'ı düz gömen bir Deployment; prod'da güvensiz ve kırılgan.
Güçlü: "Kubernetes Deployment + Service yaz. İmaj myapp:1.4.2, 3 replica, 8080 portu. CPU 100m-500m, bellek 128Mi-512Mi requests/limits ekle. /healthz için liveness, /ready için readiness probe koy. Secret'ı Secret nesnesinden oku, manifeste gömme. Açıklamalı ver."
Fark: ikinci istem sürümü, ölçeği, kaynak limitlerini, sağlık kontrollerini ve secret kuralını verir; çıktı üretime yakın ve güvenlidir.
Sık yapılan hatalar
- Kaynak limiti koymamak. Tek bir Pod tüm düğümü tüketebilir.
- Sağlık kontrolü (probe) eklememek. Kubernetes çöken/hazırolmayan Pod'u anlayamaz.
- `:latest` etiketi. Hangi sürümün çalıştığı belirsizleşir, geri alınamaz.
- Secret'ı düz Git'e commit etmek. Base64 şifreleme değildir; herkes çözer.
- Yanlış context/namespace'te komut çalıştırmak. Prod'da kaza yapmanın en sık yolu.
- `--dry-run`/`diff` atlamak. Uygulamadan önce ne olacağını görmemek.
Özetle
Kubernetes, konteynerleri bir küme üzerinde otomatik dağıtan, ölçekleyen ve iyileştiren güçlü ama karmaşık bir orkestratördür; her şey manifest YAML'larıyla tanımlanır, Helm ise bunları şablonlaştırır. YZ, Deployment/Service manifestlerini ve Helm chart'larını hızla üretir, gizemli hataları çözer — ama kaynak limiti, sağlık kontrolü, sabit imaj etiketi, dar RBAC ve secret güvenliği kurallarını açıkça istemeniz gerekir. --dry-run, diff ve doğru context kontrolü, prod kazalarını önleyen alışkanlıklardır.
Uygulama görevi
YZ'den "Deployment + Service üretme" şablonuyla bir örnek uygulama için manifest ürettirin. Sonra: (1) "Güvenlik/sağlamlık denetimi" şablonuyla kaynak limiti, prob, :latest ve secret açısından denetletin; (2) mümkünse bir test kümesinde/minikube'de kubectl apply --dry-run=server çalıştırıp çıktıyı okuyun; (3) eksik bulduğunuz en kritik iki güvenlik/sağlamlık maddesini not edin.
Kontrol listesi
- [ ] İstememe imaj sürümünü, replica sayısını, port ve kaynak limitlerini ekledim.
- [ ] Manifeste liveness ve readiness probe ekledim.
- [ ] İmaj etiketi sabit; :latest kullanmadım.
- [ ] Secret manifeste gömülü değil; Secret nesnesi/harici kasa kullandım.
- [ ] RBAC/izinleri en az yetkiye daralttım.
- [ ] Uygulamadan önce doğru context'te olduğumu ve --dry-run/diff çıktısını doğruladım.