GitHub Actions ile Kubernetes'e Deploy: CI/CD Pipeline Tasarımı

GitHub Actions, Kubernetes deploy pipeline’ı için popüler bir başlangıç noktası. Ama basit örneklerin ötesine geçmeden önce birkaç kritik tasarım kararı var.

Push-based mi, GitOps mi?

İlk soru: pipeline doğrudan kümeye mi deploy eder (push-based), yoksa Git’e commit eder ve Argo CD gibi bir araç kümeye çeker mi (pull-based)?

Küçük ekipler için push-based daha az karmaşıklıkla başlayabileceğiniz bir seçenek. Birden fazla kümeniz varsa veya drift detection önemliyse GitOps’a geçin. Bu yazıda push-based yaklaşımı ele alıyoruz.

OIDC ile kubeconfig secret’ını ortadan kaldırın

GitHub Actions’ta Kubernetes kimlik doğrulaması için en yaygın hata: uzun ömürlü bir kubeconfig dosyasını GitHub secret olarak saklamak. Secret’ın rotate edilmesi zor, sızdığında hasarı büyük.

Modern yaklaşım: cloud provider OIDC entegrasyonu. Azure AKS için:

- uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- uses: azure/aks-set-context@v4
  with:
    resource-group: my-rg
    cluster-name: my-aks

Workload Identity ile kubeconfig secret’a hiç gerek kalmaz. Token her workflow run’ında otomatik oluşturulur ve kısa ömürlüdür.

Pipeline yapısı

name: Deploy to Kubernetes

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write  # OIDC için

    steps:
    - uses: actions/checkout@v4

    - name: Build & push Docker image
      uses: docker/build-push-action@v6
      with:
        push: true
        tags: |
          ghcr.io/${{ github.repository }}:${{ github.sha }}
        cache-from: type=gha
        cache-to: type=gha,mode=max

    - name: Set Kubernetes context
      uses: azure/aks-set-context@v4
      with:
        resource-group: ${{ vars.AKS_RG }}
        cluster-name: ${{ vars.AKS_CLUSTER }}

    - name: Deploy with Kustomize
      run: |
        cd k8s/overlays/production
        kustomize edit set image \
          app=ghcr.io/${{ github.repository }}:${{ github.sha }}
        kubectl apply -k .
        kubectl rollout status deployment/app \
          -n backend-prod --timeout=5m

rollout status komutu kritik — pipeline deploy sonrası sağlıklı bir başlangıç bekler. Timeout geçerse pipeline fail eder ve otomatik rollback için hook tetiklenebilir.

Kustomize overlay yapısı

k8s/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml    # replicas: 1
    ├── uat/
    │   └── kustomization.yaml    # replicas: 2
    └── production/
        └── kustomization.yaml    # replicas: 5

Her overlay yalnızca değişen kısımları tanımlar — base’i tekrar etmez. kustomize edit set image komutu image tag’ini overlay dosyasına yazar, bu da her deploy’un tam olarak hangi imajı kullandığını Git geçmişinde izlenebilir kılar.

Rollback stratejisi

Kubernetes’in built-in rollback mekanizması:

# Son deployment'ı geri al
kubectl rollout undo deployment/app -n backend-prod

# Belirli bir revision'a dön
kubectl rollout history deployment/app -n backend-prod
kubectl rollout undo deployment/app --to-revision=3 -n backend-prod

GitHub Actions tarafında rollback için workflow_dispatch trigger’lı ayrı bir workflow oluşturun. Manuel rollback’i pipeline’ın dışında yapmak yerine her zaman aynı deploy mekanizmasını kullanmak izlenebilirliği artırır ve “bu rollback nasıl yapıldı?” sorusunu önler.

Build cache ile süre optimizasyonu

cache-from: type=gha ve cache-to: type=gha,mode=max satırları GitHub Actions cache katmanını kullanır. Değişmeyen katmanlar yeniden build edilmez. Tipik bir uygulama imajı için bu fark build süresini 8-10 dakikadan 2-3 dakikaya indirebilir.

Neler dışarıda kaldı?

Bu yazıda bilinçli olarak ele almadıklarımız: Argo CD ile GitOps, imaj açık kaynak güvenlik taraması (Trivy), SLSA provenance, Helm chart versioning. Her biri ayrı bir konuya değer.

Mevcut pipeline’ınızı değerlendirmek için 30 dakikalık ücretsiz bir teknik görüşme planlayabiliriz.