Kubernetes Mimari Tasarımı: Kurumsal Konteyner Orkestrasyonu

## Kubernetes Mimari Tasarımı ve Modern Backend Altyapıları **Kubernetes (K8s)**, konteynerize edilmiş uygulamaların dağıtımını, ölçeklendirilmesini ve yönetimini otomatize eden açık kaynaklı bir orkestrasyon platformudur. Modern backend mimarilerinde, mikroservislerin karmaşıklığını yönetmek ve yüksek erişilebilirlik sağlamak için standart haline gelmiştir. Bu rehberde, bir Kubernetes kümesinin anatomisini, bileşenler arası iletişimi ve kurumsal seviyede bir mimari kurulumun nasıl olması gerektiğini teknik detaylarıyla ele alacağız. ## Kubernetes Küme Anatomisi ve Temel Kavramlar Bir Kubernetes kümesi (cluster), iki ana bölümden oluşur: **Control Plane** (Kontrol Düzlemi) ve **Worker Nodes** (İşçi Düğümler). Control Plane, kümenin karar mekanizmasıyken, Worker Node'lar uygulamaların fiilen çalıştığı yerlerdir. ### Control Plane Bileşenleri - **kube-apiserver:** Kümenin giriş kapısıdır. Tüm REST komutları buradan geçer. - **etcd:** Kümenin tüm verilerinin tutulduğu, yüksek erişilebilir anahtar-değer deposudur. - **kube-scheduler:** Yeni oluşturulan Pod'ları izler ve onları uygun Node'lara yerleştirir. - **kube-controller-manager:** Kümedeki durum değişimlerini yönetir (örneğin, bir Node çöktüğünde yeni Pod başlatılması). ### Worker Node Bileşenleri - **kubelet:** Her Node'da çalışan ve konteynerlerin Pod içinde istenen durumda olduğundan emin olan ajandır. - **kube-proxy:** Ağ kurallarını yönetir ve servislerin iletişimini sağlar. - **Container Runtime:** Konteynerleri çalıştıran yazılımdır (Docker, containerd, CRI-O). ## Kurulum ve Altyapı Hazırlığı Kurumsal bir Kubernetes mimarisi için genellikle `kubeadm` ile manuel kurulum veya bulut sağlayıcıların (EKS, GKE, AKS) yönetilen servisleri tercih edilir. Aşağıda, temel bir küme konfigürasyonu için gerekli olan bir **Deployment** kaynağının yapısını görebilirsiniz. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: backend-api labels: app: production spec: replicas: 3 selector: matchLabels: app: backend-api template: metadata: labels: app: backend-api spec: containers: - name: api-container image: my-registry/backend:v1.2.0 ports: - containerPort: 8080 ``` ## Detaylı Kullanım Örnekleri ve Mimari Bileşenler ### 1. Servis Yönetimi (Services) Pod'lar geçicidir; öldüklerinde IP adresleri değişir. **Service** objesi, Pod grubuna sabit bir IP ve DNS adı sağlar. ```yaml apiVersion: v1 kind: Service metadata: name: backend-service spec: selector: app: backend-api ports: - protocol: TCP port: 80 targetPort: 8080 type: ClusterIP ``` ### 2. Dış Dünyaya Erişim: Ingress Uygulamanızı dış dünyaya açmak için bir **Ingress Controller** ve Ingress kuralları tanımlamanız gerekir. ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: main-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: api.sirketiniz.com http: paths: - path: /v1 pathType: Prefix backend: service: name: backend-service port: number: 80 ``` ### 3. Yapılandırma Yönetimi: ConfigMap Uygulama ayarlarını koddan ayırmak için **ConfigMap** kullanılır. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: app-config data: DB_URL: "jdbc:postgresql://db-service:5432/mydb" DEBUG_LEVEL: "info" ``` ### 4. Hassas Veri Yönetimi: Secrets Şifreler ve API anahtarları gibi veriler **Secret** objelerinde base64 formatında saklanır. ```yaml apiVersion: v1 kind: Secret metadata: name: db-credentials type: Opaque data: password: dXNlci1zaWZyZXNpCg== # base64 encoded ``` ### 5. Kalıcı Veri: PersistentVolumeClaim (PVC) Konteynerler stateless (durumsuz) yapıdadır. Veriyi kalıcı hale getirmek için PVC kullanılır. ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: storage-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi ``` ### 6. Otomatik Ölçeklendirme: Horizontal Pod Autoscaler (HPA) CPU kullanımı arttığında Pod sayısını otomatik artırmak için HPA tanımlanır. ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: backend-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: backend-api minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 ``` ### 7. Kaynak Limitleri (Resource Quotas) Bir namespace'in tüketeceği toplam kaynağı sınırlandırmak kritiktir. ```yaml apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: requests.cpu: "4" requests.memory: 8Gi limits.cpu: "8" limits.memory: 16Gi ``` ### 8. Ağ Politikaları (Network Policies) Pod'lar arası trafiği kısıtlamak güvenlik için zorunludur. ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-allow-db spec: podSelector: matchLabels: app: database ingress: - from: - podSelector: matchLabels: app: backend-api ``` ### 9. Pod Bozulma Bütçesi (Pod Disruption Budget) Bakım sırasında minimum kaç Pod'un ayakta kalacağını belirler. ```yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: backend-pdb spec: minAvailable: 2 selector: matchLabels: app: backend-api ``` ### 10. Node Affinity ve Taints Uygulamaların belirli özelliklere sahip Node'larda çalışmasını sağlar. ```yaml spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: disktype operator: In values: - ssd ``` ## Kubernetes Mimarisinde Best Practices 1. **Resource Requests ve Limits Kullanın:** Pod'ların ne kadar kaynak tüketeceğini mutlaka belirtin. Aksi takdirde bir Pod tüm Node kaynağını tüketebilir. 2. **Liveness ve Readiness Probes:** Uygulamanın sağlıklı olup olmadığını anlamak için bu kontrolleri ekleyin. 3. **Immutable Tags:** `:latest` tag'ini kullanmayın. Versiyonlanmış tag'ler (örn: `:v1.2.3`) kullanın. 4. **RBAC (Role-Based Access Control):** Her kullanıcıya ve servise sadece ihtiyacı olan yetkiyi verin. 5. **Multi-AZ Deployment:** Yüksek erişilebilirlik için Node'larınızı farklı kullanılabilirlik bölgelerine dağıtın. ## Sık Yapılan Hatalar - **Root Kullanıcısı Kullanmak:** Konteynerleri root yetkisiyle çalıştırmak büyük bir güvenlik açığıdır. - **Stateless ve Stateful Ayrımı Yapmamak:** Veritabanı gibi stateful uygulamaları yönetirken StatefulSet yerine Deployment kullanmak veri kaybına yol açabilir. - **İzleme ve Loglama Eksikliği:** Prometheus ve Grafana gibi araçlar olmadan Kubernetes yönetmek, karanlıkta araba sürmeye benzer. ## Performans İpuçları - **Küçük İmajlar Kullanın:** Alpine tabanlı imajlar, deployment süresini ve ağ trafiğini azaltır. - **Service Mesh Değerlendirmesi:** Çok karmaşık mikroservis ağlarında Istio veya Linkerd gibi Service Mesh yapılarını kullanarak trafiği optimize edin. - **Pod Topology Spread Constraints:** Pod'ların Node'lar arasında dengeli dağılmasını sağlayarak yükü optimize edin. ## Sık Sorulan Sorular | Soru | Cevap | | :--- | :--- | | Pod nedir? | Kubernetes'teki en küçük, dağıtılabilir nesnedir; bir veya daha fazla konteyneri barındırır. | | ReplicaSet ve Deployment farkı nedir? | Deployment, ReplicaSet'leri yönetir ve rolling update gibi gelişmiş özellikler sunar. | | Helm nedir? | Kubernetes uygulamalarını paketlemek ve yönetmek için kullanılan bir paket yöneticisidir. | | Node nedir? | Kubernetes kümesindeki fiziksel veya sanal bir makinedir. | | Kube-proxy ne işe yarar? | Servis IP'lerine gelen trafiği doğru Pod'lara yönlendiren ağ kurallarını yönetir. | ## Özet ve Sonuç Kubernetes mimari tasarımı, kurumsal uygulamaların sürdürülebilirliği için kritik bir yatırımdır. Doğru yapılandırılmış bir Control Plane ve optimize edilmiş Worker Node'lar, sistemin hataya dayanıklı (fault-tolerant) ve ölçeklenebilir olmasını sağlar. Bu rehberdeki prensipleri uygulayarak, karmaşık backend sistemlerinizi modernize edebilir ve operasyonel yükünüzü minimize edebilirsiniz.