Kubernetes'te veritabanı (operator)

Belirti

Amaç: Kubernetes üzerinde veritabanını bir operator ile çalıştır; StatefulSet yerine operator'ün sağladığı otomatik failover, kalıcı depolama ve yedek özelliklerini kullan.

1. Neden operator: StatefulSet tek başına yetmez

Düz StatefulSet sana kalıcı kimlikli pod'lar ve PVC verir ama failover, replikasyon kurulumu, yedek ve yükseltme mantığını vermez. Operator, veritabanına özel bu operasyonel bilgiyi bir denetleyici (controller) + özel kaynak (CRD) olarak paketler. Yani 'Cluster' adında bir CR yazarsın, operator arkada StatefulSet, Service, Secret ve yedek işlerini yönetir. Üretimde veritabanını genelde operator ile çalıştırmak tercih edilir.

PostgreSQL

# operator'ler PostgreSQL için:
#  - CloudNativePG (CNPG)
#  - Zalando postgres-operator
#  - Crunchy PGO

2. Operator'ü seç ve kur

Motora göre operator seç: PostgreSQL için CloudNativePG veya Zalando postgres-operator; MySQL ve MongoDB için Percona operatörleri (Percona Operator for MySQL / for MongoDB) yaygındır. Operator'ü Helm veya bundle manifest ile kur; bu adımda CRD'ler ve denetleyici pod'u kümeye eklenir.

PostgreSQL

# CloudNativePG kurulumu
kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-1.24.0.yaml

MySQL

# Percona Operator for MySQL (Helm)
helm install my-op percona/pxc-operator

MongoDB

# Percona Operator for MongoDB (Helm)
helm install psmdb-op percona/psmdb-operator

3. Depolamayı (StorageClass / PVC) planla

Veritabanı durumu (state) PVC'lerde tutulur; hangi StorageClass'ın kullanılacağını CR'da belirt. Düşük gecikmeli, bloklu (block) ve mümkünse yerel-benzeri SSD sağlayan bir StorageClass seç; ağ dosya sistemi (NFS) çoğu veritabanı için önerilmez. PVC boyutunu ve genişletilebilirliği (allowVolumeExpansion) baştan doğru ayarla, çünkü küçültmek zordur.

PostgreSQL

spec:
  storage:
    storageClass: fast-ssd
    size: 50Gi

4. Cluster CR'ını uygula (replika ve otomatik failover)

İnstance/replika sayısını CR'da ver; operator senkron/asenkron replikasyonu kurar ve primary düşerse otomatik failover yaparak bir replikayı terfi ettirir. Uygulama, operator'ün oluşturduğu '-rw' (okuma-yazma) Service'ine bağlanmalı; bu servis her zaman güncel primary'ye yönlenir. Böylece failover sırasında bağlantı hedefi değişmez.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: uygulama-db
spec:
  instances: 3
  storage:
    storageClass: fast-ssd
    size: 50Gi
# uygulama şuna bağlanır: uygulama-db-rw

5. Yedeklemeyi CR ile S3'e yaz

Operator'ler yedeği de bildirimsel (declarative) yönetir: birincil yedek hedefini (object storage/S3) ve WAL arşivlemeyi CR'da tanımlarsın. CloudNativePG'de spec.backup.barmanObjectStore ile S3 bilgisi verilir (1.26'dan beri deprecated; yeni kurulumlarda Barman Cloud Plugin ve ObjectStore kaynağını kullan); sürekli WAL arşivi + baz yedek ile point-in-time recovery mümkün olur. Kimlik bilgilerini Kubernetes Secret'tan referansla.

PostgreSQL

spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://sirket-yedek/uygulama-db
      s3Credentials:
        accessKeyId:
          name: s3-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: s3-creds
          key: SECRET_ACCESS_KEY

6. Zamanlanmış yedek ve geri yükleme CR'ı

Tek seferlik yedek için Backup, zamanlanmış için ScheduledBackup CR'ı oluştur; cron ifadesiyle düzenli baz yedek al. Geri yüklemeyi de bildirimsel yaparsın: yeni bir Cluster'ı 'bootstrap.recovery' ile mevcut object store yedeğinden başlatırsın. Restore tatbikatını düzenli yap; yalnızca yedek almak yetmez, geri dönüşü test et.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: gece-yedek
spec:
  schedule: "0 0 2 * * *"
  cluster:
    name: uygulama-db