Technical Tutorials

Eski monolitik uygulamalar genellikle önemli bir mimari darboğaz temsil eder. Sektör trendleri mikro servislerden yana olsa da, birçok işletme hala sağlam ancak katı yapıdaki monolitlere güvenmektedir. Bu sistemleri mikro servis mimarisine geçirmek yüksek riskli ve yoğun çaba gerektiren bir süreçtir. Ancak, tamamen yeniden yazmak ile eski kısıtlamaları kabul etmek arasında seçim yapmak zorunda değilsiniz. İşte Istio ve güçlü yan konteyner enjeksiyon yetenekleri.

Monolitinize ait pod'lara bir Envoy proxy'sini yan konteyner olarak enjekte ederek, uygulama kodunda tek bir satır bile değiştirmeden mTLS, trafik yönetimi ve gözlemlenebilirlik gibi servis mesh yeteneklerini getirebilirsiniz. Bu blog yazısı, bu işlemi etkili bir şekilde uygulamak için gereken teknik desenleri ve otomasyon stratejilerini incelemektedir.

Yan Konteyner Enjeksiyon Mekanizmasını Anlamak

Istio'nun otomasyonunun çekirdeği mutatingwebhookconfiguration içinde yatar. Istio enjeksiyonu için etiketlenmiş bir Kubernetes namespace'inde yeni bir pod oluşturulduğunda, webhook pod tanımını yakalar ve zamanlayıcı bir düğüm atamadan önce onu değiştirir. Envoy konteynerini (yan konteyner) ekler ve gerekli yapılandırmayı enjekte eder.

Eski monolitler için bu bir oyun değiştiricidir. Monolit değişmeden kalır, ancak ağ katmanı akıllı hale gelir. Giriş trafiğini kontrol edebilir, hız sınırlaması uygulayabilir ve altyapınız genelinde dağıtılmış izlemeleri toplayabilirsiniz.

Hedef Odaklı Namespace Etiketleme

Enjeksiyonu etkinleştirmenin en basit yolu, tüm namespace'i etiketlemektir. Yeni mikro servisler için etkili olsa da, bu genel yaklaşım, altyapıyı diğer kritik eski bileşenlerle paylaşan karmaşık bir monolit için çok agresif olabilir.

# Enjeksiyonu etkinleştirmek için namespace'i etiketle
kubectl label namespace legacy-app-ns istio-injection=enabled

Bununla birlikte, kararlılık için daha ince granüler bir yaklaşım genellikle tercih edilir. Namespace'i etiketlemek yerine, belirli pod'lara veya dağıtımlara (deployments) açıklama (annotation) ekleyebilirsiniz. Bu, monoliti temsil eden yalnızca belirli yüklerin yan konteyner almasını sağlayarak, diğer eski paylaşılan kaynakların dokunulmaz kalmasını güvence altına alır.

Helm ve CI/CD Üzerinden Enjeksiyonun Otomatikleştirilmesi

Üretim dağıtımlarındaki manuel müdahale, hataların bir kaynağıdır. Bu deseni ölçeklendirmek için otomasyon anahtardır. Monolitinizi dağıtmak için Helm kullanıyorsanız, enjeksiyon sürecini basitleştirebilirsiniz.

Öncelikle, kümenizde istio-injection etiketinin aktif olduğundan emin olun. Ardından, uygulamanızı dağıtın. Istio Operator veya Istio Helm şablonlarını kullanıyorsanız, enjeksiyon pod oluşturulduğunda otomatik olarak gerçekleşir.

# Eski uygulamayı dağıt
helm install legacy-monolith ./charts/monolith \
  --namespace legacy-app-ns \
  --set service.type=ClusterIP

Dağıtımdan sonra, pod durumunu kontrol ederek yan konteynerin doğru şekilde enjekte edildiğini doğrulayın.

kubectl get pods -n legacy-app-ns -o wide

İki konteynerin çalıştığını görmelisiniz: uygulama konteyneriniz ve istio-proxy konteyneri.

Eski Ağ Kısıtlamalarının Yönetilmesi

Eski monolitler, genellikle sabit kodlanmış IP adreslerine sahip olabilir veya Envoy proxy'sinin engelleme mekanizmalarıyla çakışabilecek belirli ağ davranışlarına güvenebilir. Bunu hafifletmek için, yan konteyner içindeki iptables kurallarını dikkatlice yapılandırmanız gerekir.

Varsayılan olarak Istio, hangi trafiğin proxy tarafından işleneceğini kontrol etmek için SidecarIngress ve SidecarEgress kaynaklarını kullanır. Bir monolit için genellikle tüm gelen trafiği proxy'lemek, ancak gecikme artışlarını önlemek için eski veritabanlarına veya üçüncü taraf API'lerine yönelik doğrudan çıkış bağlantılarına izin vermek istersiniz.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: legacy-sidecar-config
  namespace: legacy-app-ns
spec:
  workloadSelector:
    labels:
      app: legacy-monolith
  egress:
  - hosts:
    - "./*"       # Tüm çıkış trafiğine izin ver
    - "istio-system/*"
  ingress:
  - port:
      number: 8080
      protocol: HTTP
      name: http
    defaultEndpoint: "127.0.0.1:8080"

Sonuç

Eski monolitler için bir servis mesh benimsemek, kodu düzeltmekle ilgili değildir; bu, ağ katmanını düzeltmekle ilgilidir. Istio'nun yan konteyner enjeksiyon desenlerinden yararlanarak, mevcut iş mantığınızın bütünlüğünü korurken kurumsal düzeyde güvenlik ve gözlemlenebilirlik kazanırsınız. Namespace genelinde etiketler mi yoksa ince granüler açıklamalar mı kullandığınız önemli değildir; asıl olan otomasyondur. Bu desenleri CI/CD pipeline'larınıza entegre ederek altyapınızı kademeli olarak modernize edebilir, riski azaltabilir ve gelecekteki mimari değişikliklere zemin hazırlayabilirsiniz. Küçük başlayın, etkiyi izleyin ve ağır işi mesh'e bırakın.