Migrasyon sunumunda “Kubernetes'e 20.000 mikroservis” yazıyordu. Kimse 20.000 mikroservis çalıştırmaz — dünyada yalnızca bir avuç şirket bunun bir kesrini bile işletir. Gerçek envanter, yaklaşık 20.000 VM instance'ı olarak çalışan kabaca 900 ayrı servisti. Şişirilmiş sayı önemliydi, çünkü üzerine kurulan plan her instance'ı birbirinin aynı, konteynerleştirmeye hazır ve otopilotta taşınması güvenli kabul ediyordu.

Plan

  • “Sadece konteynerleştir ve deploy et”
  • Otomatik dönüştürme araçları, servis başına asgari inceleme
  • Haftalarla ölçülen agresif cutover dalgaları

Ne ters gitti

İlk büyük dalgada taşınan servislerin kabaca üçte ikisi readiness veya health check'lerden geçemedi. Nedenler nadiren egzotikti:

  • Yıllardır kimsenin açmadığı config dosyalarındaki hardcoded IP adresleri
  • /opt/app/tmp'ye geçici dosya yazan servisler — yeni imajlarda salt okunur
  • Bir servis hangi ortamda olduğuna karar vermek için kendi hostname'ini parse ediyordu; “prod-db-01” adlı bir makinede yaşamayı bekliyordu
  • Artık uygulamanın yanında çalışmayan daemon'lara yüzlerce hardcoded localhost referansı
  • Container'lar varsayılan olarak UTC'ye geçtiği anda batch job'ları bozan saat dilimi varsayımları

Bunların hiçbiri deployment artefaktının otomatik taramasında görünmez. Bu altyapı arkeolojisidir ve servis başına gerçek zamana mal olur.

Bunun yerine ne işe yarar

  • Önce envanter. Instance'ları gerçek servislere indirgeyin ve her birini sınıflandırın — bu, aklı başında her bulut migrasyon yol haritasının değerlendirme adımıdır ve 6R/7R terimleriyle hangi iş yüklerinin replatform edileceğine, hangilerinin olduğu gibi rehost edileceğine ve hangilerinin emekliye ayrılacağına karar verir.
  • Servis başına bir container hazırlık kontrol listesi: dosya sistemi yazmaları, ağ ve hostname varsayımları, config kaynakları, saat ve locale.
  • Küçük dalgalar, önce stateless olanlar, kademeli trafik kaydırma ve anında rollback ile. Canary release'ler trafik katmanına aittir; veri migrasyonları — dual-write gibi desenlerin geçerli olduğu yer — ayrı bir iş akışıdır, konteynerleştirme düzeltmesi değil.
  • Tranş başına aylarla ölçülen bir takvim, cutover hafta sonu değil.

Bu tür yapılar, bulut migrasyon projelerini kimse daha bir Dockerfile yazmadan önce keşif aşaması etrafında kapsamlandırmamızın tam nedenidir.

Ders: Konteynerleştirme “docker build” değildir. Replatform projelerini öldüren şey Kubernetes değil, belgelenmemiş bağımlılıklardır — ve onları bulmanın tek yolu servislere teker teker bakmaktır.

← Çıkarılan Dersler'e dön

Bu tür olaylar önlenebilir. AWS Yönetilen Hizmetler ekibimiz müşteri ortamlarını yapay zekâ destekli izleme ve nöbetteki kıdemli mühendislerle 7/24 gözetir — böylece bu tür hikâyeler arşivde kalır.

Etiketler: #Kubernetes #Migrasyon #Konteynerler #Mimari