Kubernetes'i Üretime Hazırlamak: Kaynak, Güvenlik ve Gözlemlenebilirlik

Bir Kubernetes cluster'ını ayağa kaldırmak bugün birkaç komutluk iş. Asıl emek, o cluster'ın gece yarısı bir node kaybedildiğinde, bir deploy yarıda kaldığında ya da bir pod belleği tükettiğinde de sakin kalmasını sağlamakta. Bu yazıda bir workload'u "çalışıyor" durumundan "üretime hazır" durumuna taşıyan ayarları dört başlıkta topluyoruz: kaynak yönetimi, sağlık ve dayanıklılık, güvenlik, gözlemlenebilirlik ve maliyet.

Kaynak Yönetimi: Request ve Limit'leri Bilinçli Koyun

Scheduler, pod'u hangi node'a yerleştireceğine requests değerine bakarak karar verir. Request tanımlanmamış bir pod, node üzerinde ne kadar kaynak kullanacağı bilinmeyen bir misafir gibidir; yoğunluk anında ilk tahliye edilenler arasında olur. Bu yüzden her container için en azından CPU ve bellek request'i tanımlanmalıdır.

Limit'lerde iki kaynak farklı davranır:

• Bellek limiti aşılırsa container OOMKilled ile sonlandırılır. Bellek request'ini ve limitini birbirine yakın (çoğu zaman eşit) tutmak, davranışı öngörülebilir kılar.
• CPU limiti aşılırsa container öldürülmez, kısıtlanır (throttling). Gecikmeye duyarlı servislerde sıkı CPU limitleri beklenmedik yavaşlamalara yol açabilir; bu yüzden birçok ekip CPU'da request'i özenle belirleyip limiti daha gevşek tutar ya da hiç koymaz. Hangisinin size uyduğunu metriklere bakarak seçin.

Namespace düzeyinde LimitRange ile varsayılan değerler, ResourceQuota ile de toplam üst sınır koymak, tek bir ekibin ya da hatalı bir manifest'in cluster'ı doldurmasını engeller.

Sağlık Kontrolleri ve Dayanıklılık

Üç probe'un üç ayrı görevi var

• readinessProbe: Pod trafik almaya hazır mı? Başarısız olursa pod Service arkasından çıkarılır ama yeniden başlatılmaz.
• livenessProbe: Süreç kilitlendi mi? Başarısız olursa container yeniden başlatılır. Liveness içinde veritabanı gibi dış bağımlılıkları kontrol etmeyin; veritabanı kısa süre yanıt vermediğinde bütün pod'larınızın aynı anda yeniden başlaması sorunu büyütür.
• startupProbe: Yavaş açılan uygulamalarda, uygulama ayağa kalkana kadar liveness kontrolünü erteler.

Kesintisiz deploy ve düzgün kapanış

Kubernetes bir pod'u kapatırken önce SIGTERM gönderir, terminationGracePeriodSeconds (varsayılan 30 saniye) dolunca da SIGKILL. Uygulamanın SIGTERM'i yakalayıp yeni istek almayı bırakması, elindeki işleri bitirmesi ve bağlantıları kapatması gerekir. Endpoint güncellemesi ile sinyal aynı anda yayıldığı için kısa bir preStop beklemesi, kapanan pod'a son anda istek düşmesini azaltır.

Üretimdeki her servis için en az iki replika, bu replikaların farklı node'lara ya da zonlara dağılması için topologySpreadConstraints ve node bakımı sırasında hepsinin aynı anda tahliye edilmemesi için bir PodDisruptionBudget tanımlayın.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      terminationGracePeriodSeconds: 45
      containers:
        - name: api
          image: registry.example.com/api@sha256:...
          resources:
            requests: { cpu: "250m", memory: "512Mi" }
            limits:   { memory: "512Mi" }
          readinessProbe:
            httpGet: { path: /ready, port: 8080 }
            periodSeconds: 5
          livenessProbe:
            httpGet: { path: /live, port: 8080 }
            periodSeconds: 10
            failureThreshold: 3
          lifecycle:
            preStop:
              exec: { command: ["sleep", "5"] }

Örnekteki imajın etiket yerine digest ile sabitlendiğine dikkat edin. latest gibi değişken etiketler, hangi sürümün çalıştığını belirsizleştirir ve geri dönüşü zorlaştırır.

Güvenlik: Varsayılanlar Sizi Korumaz

Pod Security Standards

PodSecurityPolicy Kubernetes 1.25 ile kaldırıldı; yerini yerleşik Pod Security Admission aldı. Namespace'e pod-security.kubernetes.io/enforce: restricted etiketi eklemek, root olarak çalışan ya da yetki yükseltmeye izin veren pod'ları reddeder. Container tarafında karşılığı şu securityContext ayarlarıdır:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities: { drop: ["ALL"] }
  seccompProfile: { type: RuntimeDefault }

RBAC ve servis hesapları

Her uygulamaya kendi ServiceAccount'unu verin ve yalnız ihtiyaç duyduğu yetkileri bağlayın. Kubernetes API'sine hiç erişmeyen pod'larda automountServiceAccountToken: false ile token'ın pod'a bağlanmasını kapatın. cluster-admin yetkisini CI hesaplarına "işi kolaylaştırmak için" vermek, en sık karşılaşılan ve en pahalı kestirmelerden biridir.

NetworkPolicy ile varsayılan olarak kapalı ağ

Kubernetes'te varsayılan olarak her pod her pod'a erişebilir. NetworkPolicy'ler bunu kısıtlar; ancak yalnız NetworkPolicy destekleyen bir ağ eklentisi (örneğin Calico veya Cilium) kullanıldığında etkili olur. Namespace başına "her şeyi reddet" politikası koyup ihtiyaç duyulan trafiği tek tek açmak, bir pod ele geçirildiğinde etki alanını daraltır.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

Egress'i de kapattığınızda DNS (kube-dns) erişimini ayrıca açmayı unutmayın; aksi hâlde servisler isim çözemez.

Secret'lar ve audit log

Kubernetes Secret'ları varsayılan olarak yalnız base64 ile kodlanır, şifrelenmez. etcd için encryption at rest'i açın ya da sırları External Secrets Operator gibi bir araçla harici bir kasadan çekin. API sunucusunun audit log'u, "bu deployment'ı kim değiştirdi?" sorusunun tek güvenilir cevabıdır; yönetilen cluster'larda bu kaydı sağlayıcının panelinden etkinleştirmek gerekir.

Gözlemlenebilirlik: Sorunu Kullanıcıdan Önce Görmek

Üretimde bir sorunu çözmenin ilk adımı, onun nerede olduğunu bulmaktır. Bunun için üç sinyal birlikte gerekir:

• Metrikler: Prometheus ile istek sayısı, hata oranı ve gecikme (RED metrikleri) ile node ve pod kaynak kullanımı.
• Loglar: Yapılandırılmış (JSON) loglar ve bunları toplayan Loki ya da benzeri bir sistem. Log'larda istek kimliğini taşımak, ilgili satırları bir araya getirmeyi kolaylaştırır.
• İzler (traces): OpenTelemetry ile enstrümante edilmiş servisler ve Tempo, Jaeger gibi bir arka uç. Bir isteğin hangi servis zincirinde zaman kaybettiğini en hızlı izler gösterir.

Alarmları altyapı belirtilerine değil, kullanıcıyı etkileyen semptomlara bağlayın: "CPU yüksek" yerine "son beş dakikada hata oranı eşiği aştı" gibi. Her alarmın bir runbook bağlantısı olsun; gece uyanan kişinin ne yapacağını düşünmesine gerek kalmasın.

Ölçekleme ve Maliyet

HorizontalPodAutoscaler (autoscaling/v2) replika sayısını CPU, bellek ya da özel metriklere göre değiştirir. VerticalPodAutoscaler ise ayrı kurulan bir bileşendir ve pod'ların request değerlerini önerir ya da uygular. İkisini aynı workload'da aynı metrik (CPU veya bellek) üzerinden birlikte çalıştırmak birbirleriyle çatışmalarına yol açar. Yaygın bir yaklaşım, VPA'yı yalnız öneri modunda (updateMode: "Off") çalıştırıp request'leri bu önerilere göre elle ayarlamak, ölçeklemeyi de HPA'ya bırakmaktır.

Maliyetin büyük kısmı node'lardan gelir ve node sayısını belirleyen şey kullanılan kaynak değil, toplam request'tir. Gerçek kullanımın çok üzerinde request tanımlamak, boşta duran ama parası ödenen kapasite demektir. Düzenli aralıklarla request ile gerçek kullanımı karşılaştırın; Cluster Autoscaler ya da Karpenter gibi bir node ölçekleyici ile boşalan node'ların kapanmasını sağlayın.

Üretime Çıkmadan Önce Kontrol Listesi

1. Her container'da CPU ve bellek request'i, bellek limiti var mı?
2. Readiness, liveness ve gerekiyorsa startup probe'ları ayrı ayrı ve doğru amaçla tanımlı mı?
3. Uygulama SIGTERM'de düzgün kapanıyor mu?
4. En az iki replika, PodDisruptionBudget ve topoloji dağılımı var mı?
5. İmajlar digest ile sabit mi?
6. Namespace restricted Pod Security seviyesinde mi?
7. Her uygulamanın kendi ServiceAccount'u ve en az yetkili RBAC rolü var mı?
8. Varsayılan reddeden NetworkPolicy uygulanmış mı?
9. Secret'lar şifreli saklanıyor ya da harici kasadan mı geliyor?
10. Metrik, log ve iz toplanıyor; alarmların runbook'u var mı?

Bu listenin hepsini ilk günden kusursuz uygulamak gerekmiyor. Ama her maddenin bilinçli bir kararla atlandığından emin olmak, Kubernetes'i bir kurulumdan işletilebilir bir platforma dönüştüren şeydir.