İçindekiler

1. Giriş
2. Temel Stratejiler
   1. Sıralı Dağıtım (Rolling Update) Stratejisi
   2. Yeniden Oluşturma (Recreate) Dağıtım Stratejisi
3. Gelişmiş Stratejiler
   1. Mavi-Yeşil (Blue-Green) Dağıtım Stratejisi
   2. Kanarya (Canary) Dağıtım Stratejisi
   3. A/B Testi (A/B Testing) Dağıtımı Stratejisi
   4. Gölge (Shadow) Dağıtım Stratejisi
4. Sonuç ve Kıyaslamalar
5. Kaynakça

1. Giriş

Kubernetes deployment (dağıtım) stratejileri, uygulama güncellemelerini ve sürüm değişikliklerini sorunsuz bir şekilde gerçekleştirmek için kullanılan yöntemlerdir.

Kubernetes dağıtım stratejileri, dağıtılacak uygulamanın gereksinimlerine ve güvenlik ihtiyaçlarına, altyapının karşılayabileceği kaynak ve maliyet analizine uygun bir şekilde belirlenmelidir. Uygulama gereksinimleri; kesinti toleransı, geri dönüş (rollback) hızı, veri tutarlılığı, ölçeklenebilirlik ve güncelleme stratejileri gibi kritik faktörler göz önünde bulundurularak detaylı bir şekilde analiz edilmelidir. Ayrıca, uygulamanın durum saklayan (stateful) veya durumsuz (stateless), her istekte bağımsız çalışan olması, harici bağımlılıkları, depolama gereksinimleri ve ağ politikaları gibi teknik gereklilikler de dağıtım stratejisinin seçiminde belirleyici rol oynar.

Kubernetes’te yaygın olarak kullanılan dağıtım stratejileri genellikle Recreate, Rolling Update, Blue‑Green, Canary, A/B, Shadow, Progressive Delivery şeklinde sınıflandırılır. Bu bağlamda, dağıtım stratejilerini temel ve gelişmiş olarak iki gruba ayırmak, literatürde yaygın kullanılan bir standart olmasa da, anlatım kolaylığı sağlamak adına tercih edilebilir. Temel stratejiler (örneğin Recreate ve Rolling Update) Kubernetes kümesine (cluster) ek bir kurulum veya eklenti gerektirmezken, gelişmiş stratejiler (örneğin Blue‑Green, Canary, Progressive Delivery) genellikle fazladan konfigürasyon adımları veya ilave bileşenlerin yüklenmesini gerektirir.

2. Temel Stratejiler

Rolling Update Stratejisi

Şekil 1’de, bir Kubernetes ortamında 1.9 nginx sürümünden 1.15 nginx sürümüne geçiş sürecini gösteriyor. Bu süreçte eski pod’lar aşamalı olarak sonlandırılırken yeni pod’lar oluşturulup hazır hale gelene kadar sistemde kesintisiz hizmet sağlanıyor.

Kubernetes’in en yaygın kullanılan dağıtım yöntemlerinden birisidir. Varsayılan strateji olarak kabul edilir. Eski pod’lar (bir veya birden fazla konteynerin birlikte çalıştığı en küçük çalışma birimine pod denir) yeni pod’lar ile kademeli olarak değiştirilir [2]. Ana amaç sistemde kesinti olmamasıdır. Eski ve yeni sürümler geçici olarak birlikte çalışır. Bu sebeple dikkatli bir tasarım gerektirir.

Avantajlar:

• Yüksek kullanılabilirlik sağlar.
• Minimum kesinti süresi ile dağıtım gerçekleştirir.
• Küçük sürüm değişiklikleri için idealdir.

Dezavantajlar:

• Eski ve yeni sürümler bir süre birlikte çalıştığından veri veya sürüm uyumsuzlukları oluşabilir.
• Büyük değişikliklerde eski sürümlerle çakışmalar yaşanabilir.
• Kesinti olmadan güncellemeler yapılır ancak değişiklikler tüm kullanıcı kitlesini etkiler.

maxUnavailable (aynı anda kaç pod kapatılabilir) ve maxSurge (toplam pod sayısını aşma sınırı) parametreleriyle güncelleme hızı kontrol altında tutulur. Sayısal (absolute) bir değer alabilirken yüzdesel bir değer de alabilir bu iki değişken. Default değerleri %25’dir.

Uygulaması

İlgili deployment.yaml dosyasındaki strategy bölümü tanımlanır.

1
2
3
4
5
6
spec:
   strategy:
      type: RollingUpdate
      rollingUpdate:
         maxUnavailable: 25% # Aynı anda kaç pod kapatılabilir?
         maxSurge: 25% # Toplam pod sayısını aşma sınırı

Kullanım Alanları:

• Mikroservis mimarileri veya Sürekli Entegrasyon/Sürekli Dağıtım (Continuous Integration/Continuous Delivery - CI/CD) süreçleri için idealdir.
• Geri dönük uyumlu değişiklikler ve performans iyileştirmeleri için uygundur.

Recreate Stratejisi

Recreate dağıtım stratejisi, uygulamanın tüm pod’larının bir anda sonlandırılmasını ve ardından yenilerinin başlatılmasını sağlar. Bu, geçici bir kesinti süresi yaratabilir, çünkü eski sürüm tamamen durdurulmadan yeni sürüm başlatılmaz.

Tüm eski pod’lar öncelikle silinir, ardından yeni pod’lar oluşturulur. Kesinti olur. Eski ve yeni sürümler birlikte çalışmaz.

Basit ve hızlıdır ancak downtime (kesinti süresi) riski yüksektir. (Downtime bir uygulamanın veya sistemin kullanılabilirliğinin geçici olarak kesilmesi anlamına gelir)

Uygulaması

İlgili deployment.yaml dosyasındaki strategy alanının type değişkenin Recreate olarak ayarlanması yeterlidir.

1
2
3
4
5
6
7
8
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  strategy:
    type: Recreate  # Tüm eski podlar silinir, sonra yeni podlar oluşturulur

Avantajlar:

• Basit ve hızlı bir güncelleme süreci sunar.
• Sadece yeni sürüm çalıştığı için eski ve yeni sürümler arasında uyumsuzluk yaşanmaz.

Dezavantajlar:

• Kısa süreli kesintiye neden olur.
• Kullanıcı deneyimini etkileyebilir.

Kullanım Alanı:

• Geliştirme ve test ortamlarında veya kısa kesintiye toleranslı uygulamalarda tercih edilir.
• Tek seferde büyük değişiklikler yapılan sistemlerde kullanılabilir.
• Uygulama yapılandırmalarında köklü değişikliklerin yapıldığı durumlarda da tercih edilebilir (konfigürasyon dosyalarının değiştirilmesi gibi).

3. Gelişmiş Stratejiler

Mavi-Yeşil Dağıtım Stratejisi (Blue-Green Deployment Strategy)

Şekil 2’de görüldüğü gibi, Kubernetes ortamında bir Service bileşeni, app:blue ve app:green etiketlerine sahip iki farklı Deployment (Blue-Deployment-v1 ve Green-Deployment-v1) üzerinden ReplicaSet’leri ve pod’ları yöneterek Blue-Green Deployment stratejisini uygulamaktadır. Bu yapı, yeni bir sürümün (green) devreye alınırken eski sürümün (blue) hâlâ aktif kalmasını ve kesintisiz bir geçiş sağlanmasını mümkün kılmaktadır.

Pod’lar için iki identical (özdeş) namespace (ortam) kullanılır. Mavi ortam mevcut canlı sürümü, yeşil ortamsa yeni sürümü barındırır. Yeşil ortamda test edildikten sonra trafik tamamen buraya yönlendirilir. Anında geri dönüş imkânı sağlar.

Blue-Green dağıtım stratejisinde pod’lar için iki ayrı ortam hazırlanır. Buradaki ortam, ayrı bir ReplicaSet veya dağıtım (ya da bazı durumlarda ayrı ortam veya ayrı bir cluster) artı bunlara işaret eden iki ayrı servis kullanımı veya tek bir servisin etiket (label) seçicisinin değiştirilmesi anlamına gelir. Mavi ortam mevcut canlı sürümü, yeşil ortam ise yeni sürümü barındırır. İki ortamın özdeş olması hedeflenir; ancak pratikte bazı ekipler yeni sürüm ortamında farklı kopya (replica) sayısı veya yapılandırmalar da kullanabilir. Yeşil ortamda gerekli testler yapıldıktan sonra trafik, servis ayarları değiştirilerek tamamen yeşil ortama yönlendirilir. Bu yöntem, ihtiyaç halinde anında eski sürüme geri dönüş imkânı sağlar.

Uygulaması

1
2
3
4
5
# Service örneği
spec:
   selector:
      app: myapp
      version: green # Mavi: "blue" iken yeşile geçiş

Yeni sürümler için ayrı bir dağıtım (yeşil) oluşturulur.

Yaml dosyası içerisinde servisin selector alanı yeşil kurulumun label’ı ile güncellenir.

Avantajlar:

• Sıfır kesinti ile güvenli geçiş sağlar.
• Anlık Rollback işlemi sağlar [3].
• Canlı ortamda test imkânı sunar.

Dezavantajlar:

• Çift kaynak tüketimi nedeniyle maliyetli olabilir.
• Kaynak kullanımını optimize etmek için ekstra yapılandırma gerektirebilir.

Kullanım Alanı:

• Kritik iş uygulamaları ve düşük hata toleransına sahip sistemler için uygundur.
• Canlı ortam testlerinin gerekli olduğu sistemlerde kullanılır.
• Yeni sürümün toplu test edilmesi durumlarında faydalı bir yöntemdir.

Canary Dağıtım Stratejisi (Canary Deployment Strategy)

Şekil 3’te görüldüğü gibi, bir uygulama iki farklı versiyon (appv1 ve appv2) arasında trafik dağılımını göstermektedir; appv1 %85, appv2 ise %15 trafik alırken, her iki versiyon da deployment-v1, service-v1 ve ingress-v1 bileşenleriyle yönetilmektedir. Bu yapı, yeni bir versiyonun (appv2) kademeli olarak devreye alınmasını ve test edilmesini sağlayan bir Canary dağıtım stratejisini temsil etmektedir.

Kullanıcılar arasında Canary şeklinde ifade edilen bir grup belirlenir. Yeni sürüm bu küçük kullanıcı grubuna yayılır. Performans ve stability (kararlılık) test edilir, sorun yoksa tam geçiş yapılır. Sürüm geçişleri esnasında riskleri azaltmak için ve yeni sürümleri gerçek trafikte test etmek için idealdir.

Servis ağı (service mesh) ile uygulanması:

Istio gibi bir service mesh yardımı ile trafiğin belirli bir yüzdesi yeni sürüme yönlendirilebilir.

1
2
3
4
5
6
7
8
9
10
11
# Istio VirtualService örneği
http:
  - route:
      - destination:
          host: myapp
          subset: v1
        weight: 90
      - destination:
          host: myapp
          subset: v2
        weight: 10

Bu dağıtım yönteminin uygulanması Native K8s kullanımı ile veya Ingress Controller Annotations (Giriş Denetleyici Açıklamaları) kullanımı ile de yapılabilir [4]. Ayrıca Service Mesh (Istio, Linkerd), Gateway (Ağ Geçidi), API (Application Programming Interface / Uygulama Programlama Arayüzü) traffic-split, Argo Rollouts gibi araçlar çok daha ayrıntılı oran/metrik kontrolü sağlar.

Avantajlar:

• Hataları erken tespit etme imkânı sağlar.
• Hata durumunda geri alma işlemi daha az kullanıcıyı etkiler.
• Aşamalı geçiş ile olası sorunlar önceden belirlenebilir.

Dezavantajlar:

• Trafik yönlendirme yönetimi karmaşık olabilir.
• Test süreci uzayabilir.
• Kullanıcılar arasında tutarsız deneyimler yaşanabilir.

Kullanım Alanı:

• Kullanıcı geri bildirimiyle geliştirilen uygulamalar ve A/B testleri için idealdir.
• Riskli ve büyük değişiklikler için önerilir.
• Ayrıca kararsız sürümlerin kontrollü dağıtımı için de uygundur.

A/B Testi Dağıtım Stratejisi (A/B Testing Deployment Strategy)

Şekil 4’te görüldüğü gibi, bir Load Balancer üzerinden gelen trafik, versiyon A ve versiyon B olmak üzere iki farklı pod grubuna dağıtılmaktadır; versiyon A %70, versiyon B ise %30 trafik alırken, her iki versiyon da ayrı node’lar üzerinde çalışmaktadır. Bu yapı, yeni bir versiyonun sınırlı bir trafikle test edilmesini sağlayan bir trafik yönlendirme stratejisini göstermektedir.

Kullanıcı trafiği, belirli kriterlere (bölge, cihaz türü, kullanıcı segmenti, Üstmetin Aktarım Protokolü (HyperText Transfer Protocol - HTTP) başlığı (header) vb.) göre farklı sürümlere yönlendirilir. Daha çok ürün odaklı bir yaklaşımdır. Teknik bir dağıtım stratejisinden ziyade deneysel bir yöntemdir. Sürümün işletme hedeflerine ulaşma açısından ne kadar verimli olduğu test edilir, testleri geçen yeni sürüm ölçeği kademeli olarak artırılır [6]. Canary’den farkı trafiğin dağıtımı daha detaylıdır. Canary’de yüzde-baz kademeli artış; A/B’de ise demografik/özellik tabanlı statik dilimleme vardır.

Uygulaması

Service Mesh (Istio) veya Ingress Controller gerektirir. Header, çerez (cookie) veya kullanıcı özelliklerine göre trafik yönetimi örneği:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Istio VirtualService
http:
  - match:
      - headers:
          user-type:
            exact: premium
    route:
      - destination:
          host: myapp
          subset: v2
  - route:
      - destination:
          host: myapp
          subset: v1

Avantajlar:

• Kullanıcı bazlı test yapma imkânı sunar.
• Hedeflenmiş geri bildirim toplama sürecini kolaylaştırır. (bir servisin premium kullanıcıları veya farklı Kullanıcı Arayüzü/Kullanıcı Deneyimi (User Interface/User Experience - UI/UX) tasarımlarının test edilebilmesi gibi durumlar)
• Kullanıcı deneyimi üzerinde doğrudan etki sağlanabilir.

Dezavantajlar:

• Yüksek trafik yönetimi gerektirir.
• Uygulama uyumsuzlukları oluşabilir.
• Karmaşık yönlendirme yapılandırmaları gerekebilir.

Kullanım Alanı:

• Pazarlama stratejileri ve kullanıcı deneyimi testleri için uygundur.
• Bölgesel veya cihaz bazlı değişikliklerde kullanılır.

Shadow Dağıtım Stratejisi

Bu strateji, yeni yazılımın gerçek dünya koşulları altında dağıtıldığı ve test edildiği, canlı sistemi etkilemeyen canlı ortamın bir gölgesini veya kopyasını oluşturmayı içerir. Dağıtımı daha gerçekçi hale getirmek için, üretim trafiği veya verileri gölge ortama yansıtılır, ancak çıktılar veya yanıtlar gerçek kullanıcılara gösterilmez [7]. Bir sürüm, gerçek grafiği gölge olarak alır ancak kullanıcıya yanıt dönmez. Performans ve hata analizi yapılır. Dağıtım sırasında yaşanabilecek riskleri oldukça azaltır.

Kullanımı

Kullanımı için bir service mesh kullanılarak trafiğin kopyası alınmalıdır.

1
2
3
4
5
6
7
8
9
# Istio Mirroring örneği
http:
  - route:
      - destination:
          host: myapp
          subset: v1
    mirror:
      host: myapp
      subset: v2

Avantajlar:

• Gerçek kullanıcı verileriyle test yapmayı mümkün kılar.
• Kullanıcı deneyimini bozmadan hatalar tespit edilebilir.
• Performans değerlendirmesi için idealdir.

Dezavantajlar:

• Çift yük nedeniyle yüksek kaynak tüketimi gerektirir.
• Gerçek veri kullanımı bazı veri güvenliği riskleri doğurabilir.

Kullanım Alanı:

• Büyük sistem değişiklikleri ve yük testleri için uygundur.
• Canlı ortama doğrudan etki etmeden test yapılmasını gerektiren senaryolar için kullanılır.
• Bankacılık gibi güvenliğin yüksek ve hata payının olmadığı durumlarda güzel bir seçenek olacaktır.

4. Sonuç ve Kıyaslamalar

Rolling Update ve Recreate: Basit ve hızlı dağıtımlar için. Rolling Update, genellikle sıfır kesinti ile güncelleme yapmayı hedeflerken Recreate tam kesinti anlamına gelir. Ancak büyük sürüm değişikliklerinde veya konfigürasyon (config) dosyaları gibi önemli değişikliklerde etkili olabilir. Kısaca özetlemek gerekirse Rolling Update kesintisiz dağıtımlar için idealken, Recreate ise hızlı ve basit bir dağıtım için idealken kesintiye neden olur.

Blue-Green ve Canary: Yüksek kararlılık ve risk yönetimi gerektiren üretim sistemleri. Blue-Green sürüm geçişi ve tam güvenli geçiş için idealdir. Canary ise gerçek kullanıcılarla, küçük gruplarda risk azaltarak test yapmaya odaklanır.

A/B ve Shadow: Gelişmiş test ve trafik kontrolü için (genellikle ek araçların yardımıyla uygulanır) idealdir.

Rolling Update ve Canary: Rolling Update’te güncelleme otomatik ve hızlıdır. Ancak bu hızlı olma durumu sonucunda eski ve yeni sürümler geçici olarak birlikte çalışır. Canary’de ise kademeli ve kontrollüdür. Bu kontrol durumu güncellemelerin uzun süreceği anlamına gelir. Ayrıca test süreci daha uzun olabilir. Canary, gerçek kullanıcı verileriyle test yapmayı sağlar; Rolling Update daha çok teknik riskleri azaltır.

Blue/Green ve A/B Testing: Blue/Green, tam bir sürüm geçişleri için kullanılır, tamamen yeni bir sürüme geçiş sağlar. A/B Testing aynı anda iki sürümü test etmeye odaklanır. Temel hedef sadece kullanıcı davranışını anlamaktır ve bazı durumlarda yalnızca bir özelliğin değiştirilmesiyle ilgilidir. A/B Testing, kullanıcı davranışına dayalı karar alır; Blue/Green teknik kararlılığa odaklanır.

Dağıtım stratejilerinin her biri kullanım alanları özelinde avantajlara ve dezavantajlara sahiptir. Doğru yöntemin belirlenmesi sırasında kullanılan sistemin özellikleri, sistemin öncelikleri, sahip olunan kaynaklar ve risk toleransı göz önünde bulundurulmalıdır.

Yazımızın teknik gözden geçirmesi için Zeynep Rümeysa Yorulmaz’a, editör desteği için ise Kübra Ertürk’e teşekkür ederiz.

5. Kaynakça

[1] Golinuxcloud, URL: https://www.golinuxcloud.com/kubernetes-rolling-update/ (Erişim zamanı; 02, 27, 2025).

[2] O’Reilly, URL: https://www.oreilly.com/library/view/kubernetes-design-patterns/9781789619270/54b67af4-af4d-4fa3-842c-5c4597168609.xhtml (Erişim zamanı; 02, 27, 2025).

[3] Medium, URL: https://medium.com/@subhampradhan966/mastering-kubernetes-deployment-strategies-rolling-update-canary-blue-green-9933adac4e76 (Erişim zamanı; 03, 03, 2025).

[4] Cloud Native Computing Foundation, URL: https://www.cncf.io/wp-content/uploads/2020/08/CNCF-Presentation-Template-K8s-Deployment.pdf (Erişim zamanı; 03, 04, 2025).

[5] Microsoft Azure, URL: https://azure.microsoft.com/tr-tr/solutions/kubernetes-on-azure/deployment-strategy/ (Erişim zamanı; 03, 04, 2025).

[6] Codefresh, URL: https://codefresh.io/learn/software-deployment/shadow-deployments-benefits-process-and-4-tips-for-success/ (Erişim zamanı; 03, 07, 2025).