Kubernetes YAML Yapıları: Detaylı Anlatım

**ConfigMap**, uygulama yapılandırma verilerini Pod'lardan ayırmak için kullanılan bir Kubernetes API objesidir. Bu, uygulama kodunu değiştirmeden yapılandırma ayarlarını kolayca güncellemenizi sağlar. Hassas olmayan (non-sensitive) verileri depolamak için idealdir. Örneğin, veritabanı bağlantı dizeleri, loglama seviyeleri, API URL'leri gibi bilgileri ConfigMap'lerde saklayabilirsiniz.

Kullanım Senaryoları:

• Uygulama ortam değişkenlerini yönetme.
• Yapılandırma dosyalarını (örneğin `nginx.conf`, `application.properties`) Pod'lara bağlama.
• Komut satırı argümanları sağlama.

Örnek YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: uygulama-ayarlari
data:
  # Key-value çiftleri olarak yapılandırma verileri
  API_URL: "http://api.example.com/v1"
  DATABASE_HOST: "mysql-service"
  LOG_LEVEL: "INFO"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: your-app-image:latest
        ports:
        - containerPort: 80
        envFrom: # ConfigMap'ten ortam değişkenlerini yükleme
        - configMapRef:
            name: uygulama-ayarlari
        volumeMounts: # ConfigMap'i dosya olarak bağlama
        - name: app-config-volume
          mountPath: "/etc/app-config"
          readOnly: true
      volumes:
      - name: app-config-volume
        configMap:
          name: uygulama-ayarlari
          items:
          - key: API_URL
            path: api_url.txt
          - key: DATABASE_HOST
            path: db_host.txt
                

**Secret**'lar, parolalar, API anahtarları, OAuth tokenları ve SSH anahtarları gibi hassas bilgileri depolamak ve yönetmek için kullanılır. ConfigMap'ler gibi hassas olmayan verilerden farklı olarak, Secret'lar hassas veriler için tasarlanmıştır. Kubernetes, Secret'ları Pod'lara ortam değişkenleri veya dosya sistemi aracılığıyla güvenli bir şekilde enjekte etmenin birden fazla yolunu sunar. Veriler `base64` ile kodlanmış olarak saklanır, ancak bu bir şifreleme değildir; sadece bir kodlamadır. Hassas verilerinizin gerçekten güvende olduğundan emin olmak için ek güvenlik önlemleri (örneğin, şifreleme çözümleri) almanız önerilir.

Kullanım Senaryoları:

• Veritabanı kimlik bilgileri (kullanıcı adı, parola).
• API anahtarları ve tokenlar.
• Özel SSH anahtarları.
• TLS sertifikaları ve anahtarları.

Örnek YAML:

apiVersion: v1
kind: Secret
metadata:
  name: my-database-secret
type: Opaque # Varsayılan tip, genellikle hassas veriler için kullanılır
data:
  # base64 kodlanmış değerler
  # echo -n 'myuser' | base64
  DB_USERNAME: bXl1c2Vy
  # echo -n 'mypassword' | base64
  DB_PASSWORD: bXlwYXNzd29yZA==
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: database-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: database-app
  template:
    metadata:
      labels:
        app: database-app
    spec:
      containers:
      - name: database-app-container
        image: your-db-app-image:latest
        ports:
        - containerPort: 80
        env: # Secret'tan ortam değişkeni olarak yükleme
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: my-database-secret
              key: DB_USERNAME
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: my-database-secret
              key: DB_PASSWORD
        volumeMounts: # Secret'ı dosya olarak bağlama
        - name: secret-volume
          mountPath: "/etc/secrets"
          readOnly: true
      volumes:
      - name: secret-volume
        secret:
          secretName: my-database-secret
                

**Deployment**, durum bilgisiz (stateless) uygulamalar için Pod ve ReplicaSet yönetimini kolaylaştıran yüksek seviyeli bir Kubernetes kaynağıdır. Uygulamanızın istenen durumunu tanımlar (kaç kopya, hangi imaj, hangi portlar vb.) ve Kubernetes Deployment Controller bu durumu korumak için gerekli Pod'ları ve ReplicaSet'leri otomatik olarak yönetir. Kesintisiz güncellemeler (rolling updates) ve kolay geri alma (rollback) yetenekleri sunar.

Kullanım Senaryoları:

• Web uygulamaları ve API'ler gibi durum bilgisi olmayan hizmetleri dağıtma.
• Uygulama sürüm güncellemeleri yapma (sıfır kesintiyle).
• Uygulama sürümünü önceki bir stabil duruma geri alma.
• Uygulama kopyalarını yatay olarak ölçeklendirme.

Örnek YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: web-server
spec:
  replicas: 3 # 3 adet Pod kopyası çalıştır
  selector:
    matchLabels:
      app: web-server
  template: # Pod şablonu - bu Deployment'ın oluşturacağı Pod'ların tanımı
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest # Nginx imajını kullan
        ports:
        - containerPort: 80 # Konteynerin açığa çıkardığı port
        resources: # Konteyner için kaynak limitleri ve istekleri
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
      affinity: # Pod'ların düğümlere nasıl dağıtılacağını belirler
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: web-server
            topologyKey: "kubernetes.io/hostname" # Aynı düğümde birden fazla Pod olmasını engeller
                

**PersistentVolumeClaim (PVC)**, bir kullanıcının veya uygulamanın bir `PersistentVolume` (PV) için yaptığı depolama isteğidir. PV'ler, küme yöneticileri tarafından sağlanan veya dinamik olarak oluşturulan fiziksel depolama birimlerini temsil ederken, PVC'ler bu depolamayı talep eden Pod'lar için bir soyutlama katmanı sağlar. Bu sayede, Pod'lar hangi depolama teknolojisinin kullanıldığını bilmek zorunda kalmadan kalıcı depolama isteyebilir. PVC'ler genellikle durum bilgisi olan (stateful) uygulamalar (örneğin veritabanları) için kullanılır, çünkü bu uygulamaların verileri konteynerlerin yaşam döngüsünden bağımsız olarak kalıcı olmalıdır.

Kullanım Senaryoları:

• Veritabanı verilerini kalıcı olarak depolama.
• Uygulama loglarını veya kullanıcı yüklemelerini depolama.
• Sıra dışı veya büyük veri setlerini işleyen uygulamalar için depolama sağlama.

Örnek YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-data-pvc
spec:
  accessModes: # Erişim modları
    - ReadWriteOnce # Tek bir düğümden yazma/okuma
  resources:
    requests:
      storage: 5Gi # 5 Gigabayt depolama alanı isteği
  storageClassName: standard # Kullanılacak depolama sınıfı (Cloud'da GCE, AWS EBS vb.)
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateful-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: stateful-app
  template:
    metadata:
      labels:
        app: stateful-app
    spec:
      containers:
      - name: stateful-app-container
        image: your-stateful-app-image:latest
        volumeMounts:
        - name: app-persistent-storage
          mountPath: "/data" # Konteyner içinde verinin bağlanacağı yol
      volumes:
      - name: app-persistent-storage
        persistentVolumeClaim:
          claimName: my-app-data-pvc # Yukarıda tanımlanan PVC'ye referans
                

**Service** (Hizmet), kümedeki Pod'lara ağ trafiğini eşleyen bir Kubernetes kaynağıdır. Pod'lar geçici olduğu ve IP adresleri değişebileceği için, Servisler Pod'ların önüne geçerek onlara sabit bir erişim noktası ve yük dengeleme yeteneği sağlar. Bu sayede, Pod'lar yeniden oluşturulsa bile uygulamalar Servis üzerinden istikrarlı bir şekilde erişilebilir kalır. Farklı Servis türleri, uygulamanızın küme içinde mi yoksa küme dışında mı erişilebilir olacağını belirler.

Kullanım Senaryoları:

• Küme içindeki diğer Pod'ların bir dizi Pod'a erişmesini sağlama (Microservices iletişimi).
• Uygulamanın dışarıdan (internet üzerinden) erişilebilir olmasını sağlama.
• Yük dengeleme ve trafik dağıtımı yapma.
• Sabit bir DNS adı ve IP adresi sağlama.

Örnek YAML:

apiVersion: v1
kind: Service
metadata:
  name: my-web-service
spec:
  selector:
    app: web-server # Bu Servis'in trafiği yönlendireceği Pod'lar için etiket seçici
  ports:
    - protocol: TCP
      port: 80 # Servis'in dinleyeceği port
      targetPort: 80 # Pod'ların dinlediği port
      nodePort: 30080 # (NodePort tipi için isteğe bağlı) Düğümde açılacak port
  type: LoadBalancer # Servis tipi: ClusterIP, NodePort, LoadBalancer, ExternalName
                

**Servis Tipleri:**

• ClusterIP: Varsayılan tiptir. Servis'i yalnızca küme içinde erişilebilir sabit bir IP adresi altında birleştirir. Mikroservisler arası iletişim için kullanılır.
• NodePort: Her çalışan düğümde belirli bir port açarak Servis'i küme dışına açar. Küme dışından erişim için temel bir yoldur, ancak genellikle gelişim/test ortamlarında kullanılır.
• LoadBalancer: Servis'i bulut sağlayıcısının (AWS, GCP, Azure vb.) bir yük dengeleyicisi aracılığıyla dışarıya açar. İnternetten erişim için tercih edilen yoldur. Bulut sağlayıcınızda otomatik olarak bir yük dengeleyici oluşturur.
• ExternalName: Bir DNS CNAME kaydı döndürerek Servis'i harici bir DNS adına eşler. Genellikle harici bir hizmeti küme içindeki Pod'lara açmak için kullanılır.