Güncellendi:
Kubernetes’e geçiş, mevcut uygulamayı bir container imajına dönüştürmekten daha geniş bir değişikliktir. Dağıtım biçimi, yapılandırma yönetimi, veri erişimi ve ekiplerin sorumlulukları yeniden ele alınır. Başarılı bir dönüşüm planı, teknoloji hedefini müşteri deneyimi ve işletim ihtiyacıyla ilişkilendirir.
Görseli büyüt →
Önce çözmek istediğiniz sorunu tanımlayın
Yayınların uzun sürmesi, ortamların farklı olması veya kapasite değişikliğinin zor yapılması farklı problemlerdir. Her biri için mevcut durumu ölçün: dağıtım süresi, başarısız yayın oranı, geri dönüş süresi ve operasyon yükü gibi göstergeler kullanılabilir. Teknolojiyi kurmayı tek başına başarı saymayın.
Bazı uygulamalar daha basit bir otomasyon veya sanal makine düzeniyle aynı ihtiyacı karşılayabilir. Kubernetes’in kontrol düzlemi, ağ, depolama ve güvenlik bakımını yapabilecek ekip kapasitesini maliyet hesabına ekleyin. Kararı yalnız gelecekteki büyüme beklentisiyle vermeyin.
Uygulama ve veri envanteri
Çalışma zamanı, işletim sistemi bağımlılıkları, dosya yazılan dizinler, zamanlanmış görevler, e-posta ve dış API bağlantılarını kaydedin. Oturum bilgisinin veya yüklenen dosyaların yalnız yerel diskte tutulduğu uygulamalarda birden fazla örnek çalıştırmak yeni tutarlılık sorunları oluşturabilir.
Veritabanı, kuyruk ve kalıcı dosyaların hangi platformda kalacağını belirleyin. Uygulamayı Kubernetes’e taşımak, bütün veri hizmetlerini de aynı anda kümeye taşıma zorunluluğu getirmez. Ağ gecikmesi, erişim kontrolü ve geri yükleme planını seçilen sınır üzerinden değerlendirin.
Pilotu temsili bir uygulamayla kurun
- Tekrar üretilebilir bir imaj hazırlayın ve bağımlılık sürümlerini kaydedin.
- Yapılandırmayı koddan, gizli değerleri genel tanımlardan ayırın.
- Kaynak talepleri ve sağlık kontrollerini gerçek başlangıç/yük davranışına göre belirleyin.
- Log, metrik ve kullanıcı etkisini ölçen kontrolleri kurun.
- Yeni sürüm dağıtımı, Pod kaybı ve geri dönüş senaryosunu deneyin.
Pilot yalnız örnek bir karşılama sayfasından oluşursa gerçek uygulamanın veri ve kimlik bağımlılıklarını sınamaz. Düşük riskli fakat gerçek mimariyi temsil eden bir bileşen seçin.
Veri değişikliğini uygulama yayınından ayırın
Deployment geri alma mekanizması, veritabanı şemasını veya dış sistemlerde yapılan işlemleri kendiliğinden geri almaz. Şema değişikliklerinde önceki ve yeni uygulama sürümlerinin uyumunu planlayın. Veri taşıma için doğrulama, son eşitleme ve kaynak ortamı kapatma ölçütleri belirleyin.
Kademeli trafik geçişinde oturumların, cache’lerin ve arka plan görevlerinin iki ortam arasında nasıl çalışacağını değerlendirin. Aynı görevin iki yerde çalışması veya aynı veriye farklı sürümlerin yazması iş sonucunu etkileyebilir. Geri dönüş için yalnız eski imajı saklamak yeterli olmayabilir.
Ekip modelini ve kabul ölçütlerini kurun
Uygulama ekibi, platform ekibi ve destek kanalının sınırlarını yazılı hale getirin. Üretim değişikliği, Secret yönetimi, kapasite artışı ve olay müdahalesinin sahibi bilinmelidir. Eğitim ve dokümantasyon, geçiş planının sonuna bırakılacak işler değildir.
Kabulde müşteri iş akışını, hata oranını, yanıt süresini, veri doğruluğunu ve işletim maliyetini birlikte ölçün. Pilotun sonucuna göre kapsamı genişletin veya daha basit yaklaşımı sürdürün. Dijital dönüşüm, belirli bir platformun her uygulamada kullanılmasını gerektirmez.
Sık sorulan sorular
- Kubernetes’e geçerken uygulamayı mutlaka mikroservise bölmeli miyim?
-
Hayır. Uygulama sınırları iş ihtiyacına göre belirlenmelidir. Platform geçişiyle kapsamlı mimari dönüşümü aynı anda yapmak riski artırabilir.
- Eski Deployment’a dönmek bütün geçişi geri alır mı?
-
Hayır. Veri şeması, dış işlemler, dosyalar ve mesaj kuyrukları için ayrı geri dönüş veya ileri düzeltme planı gerekir.
Sonraki adım
Platform seçimini Kubernetes uygunluk rehberi ile, canlı işletimi günlük yönetim planı ile tamamlayın.
