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. Modern bulut sağlayıcılarının yönetilen servislerinde ve birçok kurumsal üretim ortamında yaygın kullanılır; fakat her uygulama için varsayılan en iyi cevap değildir.

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.

## Tipik üretim mimarisi
Kurduğumuz mimaride trafik sırayla şu katmanlardan geçer: dış yük dengeleyici (Cloudflare, HAProxy veya MetalLB), ingress denetleyicisi (Traefik ya da Nginx), Cilium tabanlı ağ/politika katmanı ve son olarak uygulama pod'ları. Uygulamalar veritabanı, mesaj kuyruğu ve S3 uyumlu depolama gibi dış servislere buradan bağlanır. Dağıtımı ArgoCD ile GitOps yaklaşımıyla yönetiriz; derleme ve test tarafında GitLab CI veya GitHub Actions kullanılır.

Çok bölgeli kurulumlarda çoğu senaryoda **bölge başına bağımsız küme** tercih edilir. Federasyon, Cluster API veya multi-cluster ağ kararları iş yükünün ağ, veri ve operasyon gereksinimine göre ayrıca değerlendirilir. Amaç tek bir büyük kümeye bağımlılığı azaltmak ve blast-radius'u kontrol etmektir; RTO/RPO hedefleri veri katmanı mimarisiyle birlikte tasarlanmalıdır.

## Ne zaman Kubernetes seçmemeli?
- Tek hostta çalışan, düşük trafikli ve seyrek deploy edilen uygulamalarda Docker Compose veya klasik VM daha sade olabilir.
- Ekipte platform sahipliği yoksa Kubernetes kurmak yalnızca karmaşıklığı YAML dosyalarına taşır.
- Veritabanı, mesaj kuyruğu ve dosya depolama için yedek/restore disiplini yoksa orkestrasyon katmanı tek başına yüksek erişilebilirlik sağlamaz.
- Lisanslı veya donanım bağımlı legacy yazılımlarda VM tabanlı model daha az riskli olabilir.

## Maliyet ve işletme kalemleri
Kubernetes maliyeti yalnızca node ücretinden ibaret değildir. Kontrol düzlemi veya self-managed master node'ları, worker kapasitesi, load balancer, persistent storage, log/metric saklama, image registry, backup hedefi, güvenlik taramaları, uzman işletme ve sürüm yükseltmeleri toplam maliyeti belirler. Yönetilen servis kullanılsa bile uygulama güvenliği, namespace politikaları, kaynak limitleri, CI/CD ve incident yönetimi kurumda kalır.

## Yaygın sorunlar ve çözümler
- **CrashLoopBackOff:** Pratikte en sık görülen nedenler yanlış ortam değişkeni, eksik secret veya readiness probe ayarıdır. `kubectl describe pod` + `kubectl logs --previous` ilk durağınız olmalı.
- **OOMKilled:** Memory request/limit değerleri gerçek kullanımla uyumsuzdur. Ölçümü bir süre toplayıp (örneğin birkaç hafta) limitleri gerçek tüketime göre güncelleyin.
- **DNS gecikmesi:** CoreDNS replica sayısı + `ndots:5` problemi. 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.

## Resmi kaynaklar
- Kubernetes dokümantasyonu: https://kubernetes.io/docs/
- Kubernetes production checklist: https://kubernetes.io/docs/setup/production-environment/
- CNCF Kubernetes proje sayfası: https://www.cncf.io/projects/kubernetes/

## Mono'nun yaklaşımı
Kubernetes'i bir "araç" değil **platform mühendisliği disiplini** olarak ele alırız. Alıcı açısından kritik soru "kurabilir miyiz?" değil, "yedek, yükseltme, izleme, güvenlik ve incident sorumluluğunu kim sürekli taşıyacak?" sorusudur.

**MonoCloud önceliği:** Veri ikametgâhı ve KVKK gereksinimi olan kurumlarda **MonoCloud üzerinde RKE2 tabanlı Kubernetes kümelerini** tercih ediyoruz. Kümenin kurulum, bakım, sürüm yükseltme ve günlük işletme sorumluluğunu **Mono ekibi olarak biz yönetiyoruz**. Müşteri yalnızca uygulama deployment'larına odaklanır; altyapı, güvenlik ve platform güncellemeleri bizim sorumluluğumuzdadır.

**Standart kurulum bileşenleri:**
- **CNI:** Tüm kurulumlarda **Cilium** (eBPF tabanlı yüksek performans ve ağ politikası desteği) kullanıyoruz.
- **Ağ politikaları:** Baştan "tümünü engelle" (zero-trust) varsayılanı ile kurulur.
- **Servis ağı:** Ayrı bir service mesh ürünü kullanmıyoruz; ihtiyaç oluştuğunda **Cilium'un mesh özellikleri** devreye alınır. Böylece CNI ve mesh aynı katmanda, tek bir bileşenle yönetilir.
- **Güvenlik:** Pod Security Admission, Kyverno politika denetimi, Cosign imza doğrulama ve SBOM üretimi standart kurulum parçasıdır.
- **Gözlemlenebilirlik:** Prometheus + Grafana (metrik), Loki (log), Tempo (trace) ve OpenTelemetry entegrasyonu önerimizdir.

Aşağıdaki kararlar projenin başında netleştirilir:

- **Dağıtım modeli:** MonoCloud üzerinde RKE2 (veri ikametgâhı + KVKK) veya public cloud üzerinde yönetilen servis (EKS, GKE, AKS) seçimi yapılır.
- **Depolama:** Kullanılacak CSI sürücüsü, anlık görüntü ve kopyalama politikaları tanımlanır. Birden fazla pod'un aynı diske yazması gerekiyorsa CephFS veya Longhorn gibi çözümler değerlendirilir.
- **Yaşam döngüsü:** Sürüm yükseltme takvimi çıkarılır, kaldırılacak API sürümleri önceden kontrol edilir, etcd yedekleri alınır, geri yükleme tatbikatı yapılır ve kapasite planı ile nöbet sınırları yazılı hâle getirilir.