AI Destekli Yazılım Geliştirmede Kubernetes ile Güvenli Dağıtım

AI destekli yazılım geliştirme çıktısını dağıtılabilir artefakta dönüştürmek

Generative AI veya bir kod ajanının ürettiği değişiklikte güven sınırı commit değil, çalıştırılan OCI imajıdır. Ajanın doğrudan kubectl yetkisi alması yerine PR açması, CI işinin imajı derlemesi ve Argo CD'nin Git'teki onaylı manifesti reconcile etmesi gerekir. Bu ayrım, prompt injection ile eklenen bir Deployment'ın cluster'a yazılmasını engeller; ajan yalnızca kaynak kodu ve sınırlı CI token'ını etkileyebilir.

Değişmez referans kullanın: mutable tag olan api:main yerine manifestte digest taşıyın. Tag aynı kalsa bile registry'deki içerik değişebildiğinden tag tabanlı dağıtım, incelemede görülen kod ile çalışan byte'ların eşleşmesini garanti etmez.

IMAGE=ghcr.io/acme/payments-api
SHA=$(git rev-parse HEAD)
docker buildx build --platform linux/amd64   --provenance=true --sbom=true --push   -t $IMAGE:$SHA .
DIGEST=$(crane digest $IMAGE:$SHA)
printf 'image: %s@%s\n' $IMAGE $DIGEST > deploy/image.lock.yaml

Bu komutta BuildKit'in ürettiği provenance ve SBOM, daha sonra hangi kaynak revizyonu ve bağımlılık grafiğinin dağıtıldığını doğrulamak için saklanır. crane ile digest'i registry'den tekrar okumak önemlidir: build çıktısından türetilen yerel bir değer, çoklu platform manifest listesinde yanlış platform digest'ine işaret edebilir.

Bir ci cd pipeline içinde deploy/image.lock.yaml yalnızca bot hesabının açtığı ayrı bir PR ile güncellenebilir. CODEOWNERS kuralını /deploy/ dizinine uygulayın ve merge sonrasında Argo CD'nin yalnızca protected branch'i izlemesini sağlayın. Bu yaklaşım cloud native mimari içinde build, yayınlama ve reconciliation sorumluluklarını ayırır; container orchestration katmanı derleme işleminin güvenilirliğine dair varsayım yapmak zorunda kalmaz.

Kubernetes eğitimi için admission policy: imzasız imajı kapıda durdurmak

Kubernetes eğitimi sırasında sık görülen hata, imzalı imajı üretip policy'nin hâlâ :latest kabul etmesidir. Kyverno ile hem digest zorunluluğu hem de Cosign imzası kontrol edilebilir. Aşağıdaki örnek, yalnızca belirli registry yolundan gelen ve OIDC issuer ile imzalanmış imajları kabul eder. Gerçek ortamda issuer ve subject değerlerini CI sağlayıcınızın imza kimliğiyle değiştirin.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validationFailureAction: Enforce
  background: false
  rules:
  - name: verify-payment-image
    match:
      any:
      - resources:
          kinds:
          - Pod
    verifyImages:
    - imageReferences:
      - ghcr.io/acme/payments-*
      mutateDigest: false
      attestors:
      - count: 1
        entries:
        - keyless:
            issuer: https://token.actions.githubusercontent.com
            subject: https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main

mutateDigest: false kritik bir ayrıntıdır: policy imajı tag'den digest'e sessizce dönüştürürse Git manifesti ile çalışan Pod spec'i farklılaşır ve GitOps drift incelemesi yanıltıcı olur.

Önce CI'da imzayı üretin, sonra policy'yi Enforce edin:

cosign sign --yes $IMAGE@$DIGEST
cosign verify   --certificate-identity https://github.com/acme/payments/.github/workflows/release.yml@refs/heads/main   --certificate-oidc-issuer https://token.actions.githubusercontent.com   $IMAGE@$DIGEST

Geçiş aşamasında Kyverno policy report'larını audit modunda toplayıp reddedilecek workload sayısını ölçün. Ardından staging namespace'inde Enforce, sonrasında üretim namespace'lerinde Enforce uygulayın. Bu, docker eğitimi kapsamında öğrenilen imaj etiketleme bilgisini, çalışma zamanında doğrulanan tedarik zinciri kontrolüne bağlar.

Yerelde policy testi için minikube üzerinde Kyverno kurulumu ve negatif test kullanın:

minikube start --driver=docker
helm upgrade --install kyverno kyverno/kyverno -n kyverno --create-namespace
kubectl apply -f policy.yaml
kubectl run unsigned --image=nginx:latest
kubectl get policyreport -A

Son komuttaki PolicyReport, webhook log'una bakmadan hangi kuralın neden reddettiğini gösterir. Edge case: image pull başarısızlığı admission aşamasından sonradır; imza policy'si geçtiği halde private registry için ServiceAccount'a yanlış imagePullSecret atanmış olabilir. Bu iki arızayı aynı hata sınıfı gibi ele almayın.

Terraform ile GitOps erişimini daraltmak: infrastructure as code sınırı

Ajanların ürettiği YAML'i kabul etmek için cluster-admin token vermek yerine Argo CD'ye namespace kapsamlı bir ServiceAccount bağlayın. Terraform modülü ile bu sınırı tekrar üretilebilir tanımlayın. infrastructure as code dosyasındaki Role, CRD veya ClusterRole yazma izni içermemelidir; aksi halde namespaced bir uygulama manifesti cluster ölçekli yetki yükseltmeye dönüşebilir.

resource "kubernetes_role" "argo_deployer" {
  metadata { name = "argo-deployer" namespace = "payments" }
  rule {
    api_groups = ["apps", ""]
    resources  = ["deployments", "services", "configmaps"]
    verbs      = ["get", "list", "watch", "create", "update", "patch", "delete"]
  }
}

resource "kubernetes_role_binding" "argo_deployer" {
  metadata { name = "argo-deployer" namespace = "payments" }
  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = kubernetes_role.argo_deployer.metadata[0].name
  }
  subject { kind = "ServiceAccount" name = "argocd-application-controller" namespace = "argocd" }
}

Planı merge öncesinde terraform plan -out=tfplan ile üretip terraform show -json tfplan çıktısında yeni clusterrolebindings olmadığını OPA veya Checkov kuralıyla kontrol edin.

AWS eğitimi ve Google Cloud eğitimi laboratuvarlarında aynı prensip farklı kimlik mekanizmalarıyla uygulanır: EKS'te IAM role ile Kubernetes ServiceAccount eşlemesi, GKE'de Workload Identity kullanılır. Ancak uygulama deployer'ının bulut hesabına geniş yetki verilmemelidir. Örneğin registry'den çekme node veya workload kimliğinin sorumluluğuyken, Terraform çalıştıran CI rolü state backend'e yazma ve daraltılmış Kubernetes API erişimiyle sınırlı kalmalıdır. Bu ayrım, bulut anahtarının bir LLM cevabına, log'a veya oluşturulan manifest içine sızması riskini azaltır.

Canary dağıtımda gecikme ve hata bütçesini ölçerek geri alma

Yeni bir agent patch'ini yüzde 100 trafiğe vermeden önce Argo Rollouts ve Prometheus ile iki eşik tanımlayın: 5xx oranı ve p95 gecikme. Karşılaştırma mantığı sabit bir sayı kullanmak değildir. Önce mevcut stable ReplicaSet için aynı gün-saat penceresinde 15 dakikalık baseline alın, sonra canary'nin aynı sorgudaki değerini izleyin. Trafik hacmi düşükse oran tek bir hatayla anlamsız sıçrar; bu nedenle analiz başlamadan önce minimum istek sayısı da şarttır.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: api-canary-health
spec:
  metrics:
  - name: error-rate
    interval: 1m
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus-operated.monitoring:9090
        query: |
          sum(rate(http_requests_total{app="payments",status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total{app="payments"}[5m]))
    successCondition: result[0] < 0.01
  - name: p95-latency
    interval: 1m
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus-operated.monitoring:9090
        query: |
          histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket{app="payments"}[5m])))
    successCondition: result[0] < 0.35

Örnekteki 0.01 ve 0.35 değerleri örnek başlangıç eşikleridir; kendi SLO ve baseline verinizle değiştirilmelidir. histogram_quantile için le etiketi korunmazsa sorgu teknik olarak sonuç döndürse bile p95 hesaplaması geçersiz olur.

Önce ve sonra karşılaştırmasını yük altında tekrar üretmek için k6 kullanın. Aynı test datası, aynı VU sayısı ve aynı ramp profili olmadan canary değişikliğini ölçmeyin.

k6 run --vus 50 --duration 10m smoke.js
kubectl argo rollouts get rollout payments -n payments --watch

smoke.js içine sabit bir request corpus ve correlation ID ekleyin; rastgele üretilen payload'lar cache davranışını değiştirip p95 farkını yanlış yorumlatabilir. Bu bölüm, devops eğitimi içinde gözlemlenebilirlik verisini gerçek bir dağıtım kararına bağlayan pratik bir egzersizdir.

Yazılım eğitimi programında LLM, DevOps ve dağıtım pratiğini birleştirmek

Yazılım eğitimi veya teknoloji eğitimi tasarlarken yalnızca bir yapay zeka kursu ile prompt yazdırmak yeterli değildir. Yapay zeka eğitimi ve llm eğitimi modülünde katılımcıya bir servis değişikliği ürettirin; ardından docker eğitimi modülünde SBOM ve digest oluşturmasını, kubernetes eğitimi modülünde Kyverno reddini düzeltmesini, devops eğitimi modülünde ise Argo Rollouts analizini başarısız senaryoda geri aldırın. Değerlendirilebilir çıktı şudur: imzalı digest, policy report, Terraform plan JSON'u ve canary metrik ekran görüntüsü.

Vibe coding eğitimi ve vibe coding kursu için özellikle faydalı bir kısıt, ajanın sadece uygulama kodu ile test yazabilmesi; deploy/, Terraform state ve CI secret dosyalarına doğrudan değişiklik açamamasıdır. İnceleyen mühendis, önerilen patch'i git diff --check, trivy image --scanners vuln ve staging canary ile kabul eder. Böylece ai destekli yazılım geliştirme pratikleri, kontrol edilmemiş üretim yetkisinden ayrılır ve generative ai çıktısı normal bir mühendislik artefaktı gibi kanıt zincirine girer.

Sık Sorulan Sorular

Kubernetes eğitimi için minikube üzerinde Cosign ve Kyverno nasıl test edilir?

Minikube'u Docker driver ile başlatın, Kyverno'yu Helm üzerinden kurun ve önce unsigned bir nginx Pod'u uygulayın. PolicyReport kaydında ihlal görülmelidir. Ardından kendi registry'nize digest ile push edilen imajı cosign sign ile imzalayıp aynı Pod'u bu digest ile deneyin. Admission webhook kararını ve image pull hatasını ayrı ayrı doğrulayın.

AI destekli yazılım geliştirme için ci cd pipeline neden digest kullanmalı?

Tag tekrar işaretlenebilir, digest ise registry içeriğinin hash tabanlı kimliğidir. CI, buildx ile imajı push ettikten sonra crane digest ile registry'nin döndürdüğü digest'i manifest PR'ına yazar. Kyverno da bu imajı Cosign imzası ile doğrularsa, merge edilen kaynak, dağıtılan imaj ve CI kimliği arasında denetlenebilir bağ kurulur.

Terraform ve infrastructure as code ile Argo CD'ye hangi izinler verilmelidir?

Uygulama namespace'inde Deployment, Service ve gerekli ConfigMap kaynakları için Role kullanın; ClusterRole, ClusterRoleBinding, CRD ve Secret yazma yetkilerini varsayılan olarak vermeyin. terraform plan çıktısında bu kaynakların eklenmesini policy-as-code kontrolüyle engelleyin. Secret ihtiyacı varsa External Secrets gibi ayrı bir operatör ve daraltılmış okuyucu kimliği kullanın.

Vibe coding kursu canary dağıtım ölçümünü nasıl değerlendirmeli?

Katılımcı önce stable sürüm için Prometheus'tan 5 dakikalık hata oranı ve histogram_quantile ile p95 baseline toplamalıdır. Ardından k6 ile sabit VU ve süre kullanarak canary'yi çalıştırmalı, Argo Rollouts AnalysisTemplate'in iki ardışık başarısız ölçümde rollback yaptığını göstermelidir. Düşük trafikte minimum istek sayısı kontrolü eklenmezse tek hata yüzdesel sonucu bozabilir.