Kubernetes (K8s); konteyner uygulamalarının dağıtımını, ölçeklenmesini ve yönetimini otomatikleştiren, Cloud Native Computing Foundation (CNCF) çatısı altında geliştirilen açık-kaynak platformdur. 2014’te Google’ın Borg deneyiminden doğmuş ve bugün hem hyperscale bulut sağlayıcılarının hem de finans, telekom, kamu sektörünün üretim ortamlarında fiili standart hâline gelmiştir.
Bir Kubernetes kümesi; kontrol düzlemi (API server, scheduler, controller-manager, etcd) ve veri düzlemi (kubelet, kube-proxy, container runtime) bileşenlerinden oluşur. Tüm kaynaklar declarative YAML/JSON manifest’lerle tanımlanır ve API server üzerinden yönetilir. Bu mimari sayesinde GitOps, kendi-kendine iyileşen sistemler ve çok sağlayıcılı portabilite mümkündür.
Mono’nun yaklaşımı
Bin mertebesinde production node’u yöneten ekibimiz, Kubernetes’i bir “araç” değil platform mühendisliği disiplini olarak ele alır. Aşağıdaki kararlar, projenin ilk haftasında verilir:
- Dağıtım modeli: Yönetilen (EKS/GKE/AKS) vs. self-managed (RKE2, Talos, kubeadm). KVKK ve veri ikametgâhı gerektiren kurumlar için Mono Cloud üzerinde RKE2 tabanlı küme.
- Ağ: CNI seçimi (Cilium/Calico), NetworkPolicy varsayılanı (deny-all), service-mesh kararı (Linkerd ile başla).
- Depolama: CSI sürücüsü, snapshot/clone politikaları, ReadWriteMany gereksinimi varsa CephFS/Longhorn.
- Güvenlik: PodSecurity admission, OPA/Gatekeeper veya Kyverno politikaları, image-signing (Sigstore/Cosign), SBOM üretimi.
- Gözlemlenebilirlik: Prometheus + Grafana + Loki + Tempo (Mono’nun Grafana Stack önerimiz). OpenTelemetry SDK ile uygulama traces.
Tipik üretim mimarisi
Tipik bir Mono Kubernetes mimarisi şu katmanlardan oluşur: dış yük dengeleyici (Cloudflare/HAProxy/MetalLB) → ingress controller (Traefik veya Nginx) → service-mesh sidecar → uygulama Pod’ları → dış servisler (RDS-eşdeğeri, Kafka, S3 uyumlu depolama). GitOps tarafı için ArgoCD; CI tarafı için GitHub Actions veya GitLab CI.
Çok bölgeli kurulumlarda bölge başına bağımsız küme + federasyon yerine cluster-API + multi-cluster service-mesh tercih ederiz. Bu, “tek küme, çok bölge” yaklaşımına göre daha düşük blast-radius ve daha sade RTO/RPO sunar.
Yaygın sorunlar ve çözümler
- CrashLoopBackOff: %80’i yanlış environment variable, eksik secret veya readiness probe gecikmesi.
kubectl describe pod+kubectl logs --previousilk durağınız olmalı. - OOMKilled: Memory request/limit’leri yanlış kalibre edilmiş. VPA önerilerini 2-4 hafta toplayıp uygulayın.
- DNS gecikmesi: CoreDNS replica sayısı +
ndots:5problemi. NodeLocalDNS önbellek katmanı ekleyin. - etcd büyümesi: Event retention’ı düşürün, defragmentation cron’u kurun, etcd disk’ini ayrı NVMe’ye taşıyın.
- Yavaş scale-up: Karpenter ile node hazırlama süresini saniyelere indirin; image pre-pull stratejileri kullanın.
