Temel Kubernetes Kavramları ve K8S’e Giriş

Bu dokümanla, Kubernetes (K8s) konteyner orkestrasyon platformunun temel mimari bileşenlerini, kubectl komut satırı arayüzü (CLI) kullanımını ve endüstri standartlarındaki en iyi uygulamaları (best practices) kapsamlı bir şekilde ele almaktayız. Özellikle bulut bilişim, sistem yönetimi ve siber güvenlik disiplinlerinde uzmanlaşmış profesyoneller için teknik bir referans kaynağı olarak tasarlanmıştır.

Bölüm 1: Temel Mimari Bileşenler

Kubernetes platformunun işleyişini kavramak için aşağıda sıralanan nesnelerin anlaşılması esastır.

• Node (Düğüm): Bir Kubernetes kümesi içerisindeki işlem kaynaklarını sağlayan ve Pod’ların çalıştırılmasından sorumlu olan işçi makinelere (worker machine) verilen isimdir. Bu makineler, fiziksel veya sanal sunucular olabilir.
  
• Pod: Kubernetes mimarisinin en küçük dağıtılabilir işlem birimidir. Bir Pod, tek bir mantıksal hizmeti temsil eden bir veya daha fazla konteyner grubunu, bu konteynerler tarafından paylaşılan depolama (volumes) ve ağ kaynaklarını (benzersiz IP adresi) ve konteynerlerin çalışma biçimini belirleyen konfigürasyonel özellikleri kapsar. En yaygın kullanım senaryosu tek konteynerli Pod’lar olsa da, sıkıca bağlı (tightly coupled) süreçler için birden fazla konteyner de barındırabilir.
  
• Deployment: Uygulamaların durumunu bildirimsel (declarative) olarak yönetmek için kullanılan bir API nesnesidir. Bir Deployment kaynağı, Pod’lar ve onları yöneten ReplicaSet’ler için istenen durumu (desired state) tanımlar. Kubernetes kontrol düzlemi, mevcut durumu sürekli olarak istenen durumla karşılaştırır ve gerekli değişiklikleri (Pod oluşturma, silme, güncelleme) otomatik olarak uygular. Bu yapı, kesintisiz güncellemeler (rolling updates) ve önceki sürümlere geri dönme (rollbacks) gibi gelişmiş yaşam döngüsü yönetimi stratejilerini mümkün kılar.
  
• ReplicaSet: Belirli bir zamanda, tanımlanmış sayıda Pod replikasının çalışır durumda olmasını garanti eden bir kontrol mekanizmasıdır. ReplicaSet’ler, yüksek erişilebilirlik ve ölçeklenebilirlik sağlamakla görevlidir. Modern Kubernetes uygulamalarında, genellikle doğrudan yönetilmezler; bunun yerine, orkestrasyonu bir Deployment nesnesi tarafından soyutlanırlar.
  
• Service: Mantıksal olarak bir grup halinde çalışan Pod’lara erişim için sabit bir ağ uç noktası (endpoint) ve politika tanımlayan bir soyutlama katmanıdır. Pod’ların yaşam döngüsü geçici (ephemeral) olduğundan, Service nesnesi onlara kararlı bir IP adresi ve DNS ismi atayarak küme içi ve dışı ağ trafiği için güvenilir bir erişim noktası oluşturur. Bu, hizmet keşfi (service discovery) ve yük dengeleme (load balancing) işlevlerini kolaylaştırır.
  • Türleri:
    ClusterIP (varsayılan, sadece küme içinden erişim),
    NodePort (her düğümün portu üzerinden dış erişim),
    LoadBalancer (bulut sağlayıcısının yük dengeleyicisini kullanarak dış erişim).
    
• Namespace: Tek bir fiziksel Kubernetes kümesini, kaynak isimlerinin kapsamını belirleyerek birden çok sanal çalışma alanına bölmek için kullanılan bir mekanizmadır. Namespace’ler, kaynakları (Pod’lar, Service’ler, vb.) mantıksal gruplar halinde izole ederek çoklu kullanıcı, proje veya ortam (örneğin, geliştirme, test, üretim) yönetimi senaryolarında düzen ve kontrol sağlar.
  
• ConfigMap & Secret: Bu iki nesne, konfigürasyon verilerini konteyner imajlarından ayırarak taşınabilirliği ve yönetilebilirliği artırır.
  • ConfigMap: Hassas olmayan konfigürasyon verilerini anahtar-değer (key-value) çiftleri formatında saklamak için kullanılır. Bu veriler, ortam değişkenleri, komut satırı argümanları veya bir Pod içindeki konfigürasyon dosyaları olarak konteynerlere sunulabilir.
  • Secret: Parolalar, API anahtarları veya TLS sertifikaları gibi hassas bilgileri depolamak amacıyla tasarlanmıştır. Veriler varsayılan olarak Base64 ile kodlanmış olsa da, bu bir şifreleme yöntemi değildir. Üretim ortamlarında, bu nesnelerin harici sır yönetim sistemleri (örn. HashiCorp Vault) ile entegre edilmesi ve etcd üzerinde durağan haldeki verinin şifrelenmesinin (Encryption at Rest) etkinleştirilmesi kritik bir güvenlik pratiğidir.

Bölüm 2: kubectl Komut Referansı

2.1. Küme ve Kaynakları Gözlemleme (Inspection)

• kubectl get <nesne>: Belirtilen türdeki bir veya daha fazla kaynağın özet bilgisini listeler.
  • kubectl get pods: Geçerli namespace’deki tüm Pod’ları listeler.
  • kubectl get all --all-namespaces: Tüm namespace’lerdeki en yaygın kaynakları (Pod, Service, Deployment vb.) listeler.
  • kubectl get nodes -o wide: Düğümler hakkında daha detaylı bilgi (IP adresi, OS imajı vb.) gösterir.
  • kubectl get deployment -w: Deployment’lardaki değişiklikleri canlı olarak izler (--watch).
  • kubectl get service my-service -o yaml: Bir kaynağın YAML tanımını çıktılar. Otomasyon ve yedekleme için kullanışlıdır.
• kubectl describe <nesne> <nesne_adı>: Belirtilen bir kaynak hakkında, ilişkili olaylar (events) ve konfigürasyon dahil olmak üzere kapsamlı ve ayrıntılı bilgi sunar. Hata tespiti ve analizi (troubleshooting) için temel bir komuttur.
  • kubectl describe pod my-pod-xyz123: Pod’un durumu, olayları (Events), volüm bağlantıları, IP adresi ve üzerinde çalıştığı düğüm gibi kritik hata ayıklama bilgilerini gösterir. Bir Pod’un başlatılamaması durumunda başvurulması gereken ilk komuttur.
• kubectl logs <pod_adı>: Bir Pod içerisindeki konteyner tarafından üretilen standart çıktı (stdout) ve standart hata (stderr) günlüklerini görüntüler.
  • kubectl logs my-pod: Pod’un standart çıktısını (stdout) gösterir.
  • kubectl logs -f my-pod: Logları canlı olarak akıtır (--follow).
  • kubectl logs my-pod -c my-container: Pod içinde birden fazla konteyner varsa, belirli bir konteynerin loglarını gösterir.

2.2. Bildirimsel ve Zorunlu Yönetim (Declarative vs. Imperative)

• kubectl apply -f <dosya_adı.yaml>: (Bildirimsel Yaklaşım – Önerilen Metot) Belirtilen bir konfigürasyon dosyasındaki (YAML/JSON) kaynak tanımlarını kümeye uygular. Bu komut, kaynak mevcut değilse onu oluşturur, mevcutsa bildirimsel tanıma göre günceller. İşlemin tekrarlanabilir (idempotent) doğası, GitOps gibi modern CI/CD ve altyapı otomasyonu paradigmaları için temel teşkil eder.
• kubectl create -f <dosya_adı.yaml>: (Zorunlu Yaklaşım) Belirtilen bir konfigürasyon dosyasından yalnızca yeni kaynaklar oluşturur. Eğer kaynak zaten mevcutsa, komut bir hata ile sonuçlanır.
• kubectl create <nesne> <ad> --image=...: (Zorunlu Yaklaşım) Konfigürasyon dosyası kullanmaksızın, komut satırı argümanları aracılığıyla anlık olarak kaynak oluşturur. Genellikle geçici test ve geliştirme senaryoları için kullanılır; sürüm kontrolü eksikliği nedeniyle üretim ortamları için tavsiye edilmez.
  • kubectl create deployment nginx-web --image=nginx:latest
• kubectl delete <kaynak_türü> <kaynak_adı>: Bir veya daha fazla kaynağı, konfigürasyon dosyasına veya isme göre siler.
  • kubectl delete -f deployment.yaml
  • kubectl delete deployment nginx-web

2.3. Uygulama Güncelleme ve Ölçeklendirme

• kubectl scale deployment <deployment_adı> --replicas=<sayı>: Bir Deployment, ReplicaSet veya StatefulSet gibi ölçeklenebilir bir kaynağın replika sayısını ayarlar.
  • kubectl scale deployment my-app --replicas=5
• kubectl edit <nesne> <nesne_adı>: Kümede mevcut olan bir kaynağın canlı konfigürasyonunu, sistemin varsayılan metin düzenleyicisinde düzenlemek üzere açar. Değişiklikler kaydedildiğinde anında uygulanır. Bu yöntem, acil müdahaleler için faydalı olabilmekle birlikte, denetlenebilirlik ve sürüm kontrolü eksikliği nedeniyle dikkatli kullanılmalıdır.
• kubectl rollout <komut> deployment/<deployment_adı>: Bir Deployment’ın dağıtım (rollout) sürecini yönetir. status ile mevcut dağıtımın durumu izlenir, history ile geçmiş sürümler listelenir ve undo ile önceki bir sürüme geri dönüş yapılır.

2.4. Hata Ayıklama (Debugging)

• kubectl exec -it <pod_adı> -- <komut>: Çalışır durumdaki bir Pod içerisindeki bir konteynerde interaktif veya non-interaktif bir komut icra eder. Bu, canlı sistemlerde hata ayıklama ve teşhis için temel bir araçtır.
  • kubectl exec -it my-app-pod-123 -- bash: Pod içinde interaktif bir bash kabuğu başlatır.
• kubectl port-forward <pod_adı> <lokal_port>:<pod_port>: Yerel bir makinedeki bir ağ portunu, bir Pod veya Service üzerinde çalışan bir porta yönlendirerek, küme ağı dışından geçici ve güvenli erişim sağlar. Genellikle geliştirme ve hata ayıklama amaçlı kullanılır.
  • kubectl port-forward my-app-pod-123 8080:80
• kubectl cp <kaynak_dosya_yolu> <pod_adı>:<hedef_dosya_yolu>: Yerel dosya sistemi ile bir Pod içerisindeki konteynerin dosya sistemi arasında dosya transferi gerçekleştirir.
  • kubectl cp ./app.log my-app-pod-123:/tmp/app.log

Bölüm 3: Örnek YAML Manifestoları

Kubernetes ortamlarında altyapı yönetimi için endüstri standardı, Altyapıyı Kod Olarak (Infrastructure as Code – IaC) tanımlama prensibine dayanır. Aşağıda, temel bir Nginx uygulaması için Deployment ve Service kaynaklarını tanımlayan örnek YAML manifestoları sunulmuştur.

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Deployment'ın adı
  labels:
    app: nginx
spec:
  replicas: 3 # Başlangıçta 3 adet Pod oluşturulacak
  selector:
    matchLabels:
      app: nginx # Bu Deployment'ın hangi Pod'ları yönettiğini belirtir
  template: # Pod'ların şablonu
    metadata:
      labels:
        app: nginx # Pod'lara verilecek etiket. Selector ile eşleşmeli.
    spec:
      containers:
      - name: nginx
        image: nginx:1.25 # Kullanılacak konteyner imajı
        ports:
        - containerPort: 80 # Konteynerin dinlediği port

nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service # Service'in adı
spec:
  selector:
    app: nginx # Bu Service'in hangi etiketli Pod'lara trafik yönlendireceğini belirtir
  ports:
    - protocol: TCP
      port: 80       # Service'in kendi portu
      targetPort: 80 # Trafiğin yönlendirileceği Pod'ların portu
  type: LoadBalancer # Dışarıdan erişim için bulut sağlayıcıdan bir yük dengeleyici ister

Manifestoların Uygulanması:

1. Yukarıdaki içerikleri sırasıyla nginx-deployment.yaml ve nginx-service.yaml olarak kaydediniz.
2. kubectl apply -f nginx-deployment.yaml komutunu çalıştırarak Deployment kaynağını oluşturunuz.
3. Benzer şekilde, kubectl apply -f nginx-service.yaml komutu ile Service kaynağını oluşturunuz.
4. Oluşturulan kaynakların durumunu doğrulamak için kubectl get pods ve kubectl get service komutlarını kullanınız.

Bölüm 4: İleri Düzey Güvenlik Konuları ve Pratikleri

• RBAC (Role-Based Access Control): Role, ClusterRole, RoleBinding ve ClusterRoleBinding nesneleri aracılığıyla kullanıcı ve servis hesabı yetkileri, “en az yetki” (principle of least privilege) prensibine sıkı sıkıya bağlı kalarak yapılandırılmalıdır.
  
• Network Policies: Varsayılan olarak Pod’lar arası ağ trafiğine izin verilen Kubernetes ortamlarında, NetworkPolicy kaynakları kullanılarak katman 3/4 seviyesinde mikro-segmentasyon ve güvenlik duvarı kuralları tanımlanmalı, böylece ağ trafiği kontrol altına alınmalıdır.
  
• Pod Security Admission / Policies: Konteynerlerin root kullanıcısı olarak çalışmasını engellemek, hostPath volüm kullanımını kısıtlamak ve ayrıcalıklı (privileged) konteynerleri önlemek gibi güvenlik standartlarını küme genelinde zorunlu kılan mekanizmalardır.
  
• Secrets Yönetimi: Secret nesnelerinin yalnızca Base64 ile kodlandığı ve şifrelenmediği unutulmamalıdır. Üretim ortamlarında, bu nesneler mutlaka HashiCorp Vault veya bulut sağlayıcıların sunduğu sır yönetim servisleri (örn. AWS Secrets Manager) gibi harici ve güvenli çözümlerle entegre edilmeli ve veritabanı seviyesinde durağan haldeki verinin şifrelenmesi (Encryption at Rest) etkinleştirilmelidir.

Mutlu günler dilerim. :)