Automating Kubernetes Deployments with Fleet

Değişiklikleri Algılama: Polling ve Webhook'lar

Fleet, Git deposundaki değişiklikleri tespit etmek için temel olarak iki mekanizma kullanır:

1. Polling (Periyodik Sorgulama): Fleet, varsayılan olarak belirli aralıklarla Git deposunu kontrol eder ve "Yeni bir değişiklik var mı?" diye sorar.
2. Webhooks (Anlık Bildirim): Git sağlayıcınız (örn. GitHub), bir değişiklik olduğunda Fleet'e anında bir bildirim gönderir.

Şimdi bu iki yöntemi ve aralarındaki farkları inceleyelim.

Polling: Varsayılan Senkronizasyon Mekanizması

Fleet'i bir GitRepo kaynağıyla bir depoya bağladığınızda, varsayılan olarak polling modunda çalışmaya başlar. Her 15 saniyede bir depoyu kontrol ederek yeni commit'leri arar.

Bu davranış, GitRepo manifestosundaki spec.pollingInterval alanı ile kontrol edilebilir.

Polling'in avantajı basit olmasıdır; ek bir yapılandırma gerektirmez. Ancak bazı dezavantajları vardır:

• Gecikme: Değişikliğinizin dağıtılması için bir sonraki sorgulama döngüsünü beklemeniz gerekir. Bu, 15 saniyeye kadar bir gecikme anlamına gelebilir.
• Verimsizlik: Çok sayıda deponuz varsa, Fleet'in sürekli olarak tüm bu depoları sorgulaması hem Fleet denetleyicisinde hem de Git sağlayıcınızda gereksiz bir yük oluşturur.

Aşağıdaki video, polling mekanizmasının pratikte nasıl çalıştığını gösterir. Depoya bir değişiklik gönderildikten sonra Fleet'in bunu algılayıp dağıtımı başlatması arasındaki kısa gecikmeye dikkat edin.

Webhook'lar: Anlık ve Verimli Dağıtımlar

Daha modern ve verimli yaklaşım webhook kullanmaktır. Bu modelde Fleet, pasif bir şekilde bekler. Değişiklikleri sürekli sorgulamak yerine, GitHub gibi Git sağlayıcınız, depoya yeni bir commit gönderildiğinde Fleet'e bir HTTP POST isteği göndererek "Hey, yeni bir güncelleme var!" der.

Bu olay odaklı (event-driven) yaklaşımın faydaları şunlardır:

• Anında Dağıtım: git push komutunu çalıştırdıktan saniyeler sonra dağıtımınız tetiklenir.
• Yüksek Verimlilik: Yalnızca bir değişiklik olduğunda iletişim kurulduğu için gereksiz ağ trafiği ve CPU kullanımı ortadan kalkar.

Bu, tam otomatik ve hızlı bir CD boru hattı kurma hedefimizle mükemmel bir şekilde örtüşür.

Pratik Rehber: Fleet için GitHub Webhook Yapılandırması

Bir webhook kurmak birkaç adımdan oluşur: Fleet'in dinleyici servisini dış dünyaya açmak ve ardından GitHub'ı bu adrese bildirim gönderecek şekilde yapılandırmak.

Yukarıdaki dokümanı rehber alarak adımları özetleyelim:

1. gitjob Servisini Erişilebilir Kılın: Fleet, webhook isteklerini cattle-fleet-system ad alanındaki gitjob servisi ile dinler. Bu servisin GitHub tarafından erişilebilir olması için bir Kubernetes Ingress kaynağı oluşturmanız gerekir. Aşağıdaki örnek, gitjob.sizin-alan-adiniz.com gibi bir adres üzerinden servisi erişilebilir kılar:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: webhook-ingress
     namespace: cattle-fleet-system
   spec:
     rules:
     - host: gitjob.sizin-alan-adiniz.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: gitjob
               port:
                 number: 80
   

   Not: Bu Ingress'in çalışması için kümenizde bir Ingress Controller (Nginx, Traefik vb.) ve ilgili DNS kaydının yapılandırılmış olması gerekir.

2. GitHub'da Webhook Oluşturun:

   • GitOps deponuzun GitHub sayfasında Settings > Webhooks > Add webhook yolunu izleyin.
   • Payload URL: Bir önceki adımda oluşturduğunuz Ingress'in herkese açık URL'sini girin (örn. http://gitjob.sizin-alan-adiniz.com).
   • Content type: application/json olarak seçin.
   • Secret: Güvenlik için buraya rastgele bir dize girin. Bu, Fleet'in yalnızca GitHub'dan gelen meşru istekleri kabul etmesini sağlar.
   • "Add webhook" düğmesine tıklayın.

3. Webhook Secret'ını Fleet'te Yapılandırın (Önerilir):
   GitHub'da bir "Secret" tanımladıysanız, Fleet'e bu değeri söylemeniz gerekir. Bunu, cattle-fleet-system ad alanında özel bir Kubernetes Secret oluşturarak yaparsınız.

   kubectl create secret generic gitjob-webhook \
     -n cattle-fleet-system \
     --from-literal=github=SizinGitHubdaTanımladığınızSecretDeğer
   

4. Polling'i Devre Dışı Bırakın (İsteğe Bağlı):
   Webhook'unuzun çalıştığından emin olduktan sonra, GitRepo manifestonuzda spec.disablePolling: true ayarını yaparak periyodik sorgulamayı tamamen kapatabilir ve yalnızca anlık bildirimlere güvenebilirsiniz.

Tam Döngü: Kod Değişikliğinden Dağıtıma

Artık tüm parçaları bir araya getirebiliriz. Gerçek bir CI/CD senaryosunda, CI (GitHub Actions) ve CD (Fleet) süreçleri birlikte çalışır:

1. CI Süreci Tetiklenir: Siz veya ekibinizden biri, PySpark ETL kodunu içeren uygulama deposuna bir git push yapar.
2. Test ve İnşa: GitHub Actions, testleri (pytest) ve kod stil denetimini (ruff) çalıştırır.
3. İmaj Oluşturma ve Yayınlama: Testler başarılı olursa, CI süreci yeni bir Docker imajı oluşturur ve bunu commit SHA'sı gibi benzersiz bir etiketle bir container registry'ye (Docker Hub, GHCR vb.) push'lar.
4. GitOps Deposunu Güncelleme: CI boru hattının en kritik adımı budur. CI betiği, bizim GitOps depomuzu klonlar, prod ortamına ait kustomization.yaml veya values.yaml dosyasını düzenleyerek imaj etiketini az önce oluşturulan yeni etiketle günceller ve bu değişikliği GitOps deposuna commit edip push'lar.
5. CD Süreci Tetiklenir: Bu push işlemi, GitOps deposunda yapılandırdığımız webhook'u tetikler.
6. Fleet Dağıtımı Başlatır: GitHub, Fleet'in gitjob servisine bildirim gönderir. Fleet, GitOps deposundan en son manifestleri çeker ve Kustomize aracılığıyla bunları birleştirerek güncellenmiş SparkApplication'ı kümenize uygular.

Bu tam döngü, baştan sona otomasyonu sağlar. Aşağıdaki video, bu akışın tamamını mükemmel bir şekilde göstermektedir.

Özet ve Sonuç

Bu derste, GitOps tabanlı dağıtım mekanizmamızı tamamlayan kritik adımı attık. Artık Fleet'in Git'teki değişikliklere nasıl tepki verdiğini ve bu süreci nasıl otomatikleştireceğimizi biliyoruz.

Temel Çıkarımlar:

• Fleet, değişiklikleri varsayılan olarak polling (periyodik sorgulama) ile algılar, ancak bu yöntem gecikmeli ve verimsiz olabilir.
• Webhook'lar, Git sağlayıcısının Fleet'e anlık bildirimler gönderdiği, olay odaklı, verimli ve hızlı bir alternatiftir.
• Webhook yapılandırması, Fleet'in gitjob servisinin bir Ingress ile erişilebilir kılınmasını ve GitHub deposunda bir webhook URL'sinin tanımlanmasını içerir.
• Tam bir CI/CD döngüsünde, CI süreci yeni bir imaj oluşturur ve ardından GitOps deposundaki manifestleri güncelleyerek CD sürecini (Fleet dağıtımı) tetikler.

Gelecek Dersin Önizlemesi:
Otomatik dağıtım boru hattımız artık çalışır durumda. Peki ya bir dağıtım başarısız olursa? Bir manifest dosyasında hata yaparsak veya yeni imaj çalışmazsa ne olur? Bir sonraki dersimizde, dağıtımların durumunu izlemeyi, olası hataları teşhis etmeyi ve başarısız dağıtımları Rancher arayüzü ve kubectl komut satırı aracını kullanarak nasıl gidereceğimizi öğreneceğiz.