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 --previousilk 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: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.
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.
