Technical Tutorials

Sistem yöneticileri ve DevOps mühendisleri sıklıkla bir paradoksla karşı karşıya kalır: konteynerleştirmenin esnekliği ile sanallaştırmanın güvenlik izolasyonu. KVM sağlam donanım düzeyinde izolasyon sağlarken, Podman hafif ve root'suz çalıştırma sunar. Ancak, bu iki paradigma arasında sıfır kesinti (zero-downtime) sürdürmek basit değildir. Bu gönderi, durumlu iş yüklerini KVM sanal makinelerinden Podman konteynerlerine canlı olarak (live-migrate) taşımak ve işletme sürekliliğini sağlamak için gelişmiş stratejileri ele alır.

Neden Hibrit Migrasyon Önemlidir?

Örgütler, çekirdek izolasyonu veya belirli donanım erişimi gerektiren geleneksel uygulamalar için genellikle KVM VM'leriyle başlar. Modernizasyon çabaları ilerledikçe, bu iş yüklerini konteynerize edilmiş ortamlara taşımak maliyeti azaltır ve ölçekleme yeteneklerini iyileştirir. Zorluk, bunu hizmeti kesmeden yapmaktır. Geleneksel anlamda doğrudan "canlı migrasyon" (vMotion gibi), farklı hipervizör çalışma zamanları veya konteyner motorları arasında mevcut değildir. Bu nedenle, bir uygulama düzeyinde migrasyon stratejisi uygulamalıyız.

Ön Koşul: Uygulama Katmanını Standartlaştırma

KVM ve Podman arasında migrasyon yapmak için, uygulama, altta yatan hesaplama kaynağından soyutlanmalıdır. Bu genellikle şunları içerir:

Durumun dışa aktarılması (ortak ağ depolama veya harici veritabanı kullanılarak).
VM'ye özel köprü arayüzleri yerine standart ağın (IPv4/IPv6) kullanılması.
Sağlık kontrolleri ve zarif kapanma (graceful shutdown) kanca noktalarının (hooks) uygulanması.

Strateji 1: Mavi-Yeşil Dağıtım Yaklaşımı

Sıfır kesintili migrasyon için en güvenilir yöntem Mavi-Yeşil (Blue-Green) desenidir. *Örneği* (instance) taşımazsınız; *trafiği* (traffic) kaydırırsınız.

Hedefi Hazırlayın: Kaynak KVM VM'i ile aynı uygulama görüntüsüne ve yapılandırmaya sahip yeni bir Podman konteyneri başlatın.
Durumu Eşitleyin: Uygulama yerel durum tutuyorsa, VM'den konteyner ana bilgisayarının depolama birimine veri senkronizasyonu için rsync veya mantıksal veritabanı yedekleri gibi araçları kullanın.
Sağlık Kontrolü: Podman konteynerinin sağlıklı olduğunu ve istekleri işleyebildiğini doğrulayın.
Trafiği Değiştirin: Yükleme dengeleyicinizi (load balancer) veya DNS'inizi yeni Podman konteyneri IP'sine yönlendirmek için güncelleyin.
Kaynağı Devre Dışı Bırakın: Trafik kaydırıldıktan sonra, KVM VM'ini zarifçe durdurun.

Pratik Örnek: Bir Web Hizmetinin Migrasyonu

10.0.1.50 adresindeki bir KVM VM üzerinde çalışan bir Node.js uygulaması olduğunu varsayalım. Bunu host-podman-01 üzerinde 10.0.1.75 adresindeki bir Podman konteynerine taşımak istiyoruz.

Adım 1: Podman Konteynerini Oluşturma ve Dağıtma

# Uygulama kaynağından konteyner görüntüsünü oluşturun
podman build -t my-app:v1.0 .

# Kalıcı depolama ve sağlık kontrolü ile konteyneri çalıştırın
podman run -d \
  --name my-app-migrated \
  -p 8080:3000 \
  -v /data/my-app-storage:/app/data \
  --health-cmd="curl -f http://localhost:3000/health || exit 1" \
  --health-interval=30s \
  my-app:v1.0

Adım 2: Verileri Eşitleme

Uygulama yerel dosya depolama kullanıyorsa, hizmet canlıyken (yazmaların idempotent veya kuyrukta beklediği varsayımıyla) verileri eşitleyin.

# Podman ana bilgisayarından, KVM VM'den verileri eşitleyin
rsync -avz --progress 10.0.1.50:/var/www/my-app/data/ /data/my-app-storage/

Adım 3: Trafiği Kaydırma

Ters vekil (reverse proxy) olarak Nginx kullandığınızı varsayalım. Upstream yapılandırmasını güncelleyin:

# /etc/nginx/conf.d/upstream.conf
upstream backend {
    # server 10.0.1.50:8080;  # Eski KVM VM
    server 10.0.1.75:8080;    # Yeni Podman Konteyneri
}

# Nginx'i yeniden yükleyin
sudo nginx -s reload

Strateji 2: Veritabanı Destekli Migrasyon

Uygulamanız durumdan bağımsızsa (stateless) (durum, PostgreSQL veya Redis gibi harici bir veritabanında yönetiliyorsa), migrasyon daha da basittir. Hem KVM VM hem de Podman konteyneri aynı harici veritabanına bağlanır. Sadece ağ bağlantısını ve gizli anahtar (secret) yönetimini sağlamanız gerekir.

Gizli Anahtarları (Secrets) Güvenli Yönetme

Bilgileri kodun içine gömmeden (hardcoding) kullanın. Podman secrets veya güvenli bir kasadan (vault) ortam değişkeni enjeksiyonu kullanın:

podman run -d \
  --secret db_password:/run/secrets/db_password \
  -e DB_PASSWORD_FILE=/run/secrets/db_password \
  my-app:v1.0

İzleme ve Doğrulama

Migrasyon sonrası, istikrarı sağlamak için aşağıdaki metrikleri izleyin:

Gecikme (Latency): Eski ve yeni uç noktalar arasındaki yanıt sürelerini karşılaştırın.
Hata Oranları: Uygulama günlüklerinde 5xx hatalarını izleyin.
Kaynak Kullanımı: Konteynerin bellek sızıntısı yapmadığından veya CPU kısıtlamasına (throttling) uğramadığından emin olmak için podman stats kullanın.

podman stats --no-stream my-app-migrated

Zorluklar ve Dikkat Edilmesi Gerekenler

Ağ Adres Değişiklikleri

IP adreslerini kodun içine gömen (hardcode) uygulamalar başarısız olacaktır. Uygulamanızın servis uç noktaları için servis keşfi (service discovery) veya ortam değişkenleri kullandığından emin olun. Diğer konteynerlerle iletişim kuruyorsanız, Podman'da bir overlay ağ kullanmayı düşünün:

podman network create my-network
podman run -d --network my-network --network-alias my-app my-app:v1.0

Systemd ve Konteyner Init

KVM VM'leri genellikle systemd çalıştırır. Podman konteynerleri ise tek bir süreç çalıştırır. Uygulamanız systemd servislerine dayanıyorsa, supervisord gibi bir süreç denetleyicisi (process supervisor) kullanacak şekilde yeniden yapılandırın veya uygulamayı tek bir giriş noktası (entrypoint) süreci olarak çalışacak şekilde yeniden yapılandırın.

Depolama Performansı

Podman birimleriniz için depolama arka planının (ör. XFS, overlayfs), KVM VM'nin diskiyle benzer IOPS sağladığından emin olun. Yüksek performans gereksinimleri için, yerel bir SSD takmayı veya ağa bağlı bir depolama çözümü kullanmayı düşünün.

Migrasyonu Otomatikleştirme

Ölçeklenebilirlik için bu süreci Altyapı Olarak Kod (Infrastructure as Code - IaC) kullanarak otomatikleştirin. Ansible veya Terraform gibi araçlar, kaynak oluşturma, veri senkronizasyonu ve trafik değiştirme işlemlerini orkestre edebilir.

# Örnek Ansible Görevi: Podman sağlığını doğruladıktan sonra KVM VM'ini durdur
- name: Podman konteynerinin sağlıklı olmasını bekle
  command: podman inspect --format "{{.State.Health.Status}}" my-app-migrated
  register: health
  until: health.stdout == "healthy"
  retries: 10
  delay: 5

- name: KVM VM'ini yok et
  virt:
    name: "legacy-vm"
    command: destroy
    state: absent
  when: health.stdout == "healthy"

Sonuç

KVM VM'leri ile Podman konteynerleri arasındaki canlı migrasyon, tek atomik bir işlem değil, stratejik bir süreçtir. Mavi-yeşil dağıtımları benimseyerek, durumu dışa aktararak ve trafik kaydırma işlemini otomatikleştirerek sıfır kesintili bakım sağlayabilirsiniz. Bu yaklaşım yalnızca modernizasyonu kolaylaştırmakla kalmaz, aynı zamanda sanallaştırılmış ve konteynerize edilmiş ortamlar arasında sorunsuz devralma (failover) imkânı sunarak dayanıklılığı da artırır. Altyapınız evrildikçe, bu hibrit migrasyon stratejilerini ustalaşmak, yüksek kullanılabilirliği ve operasyonel verimliliği sürdürmenin anahtarı olacaktır.