Azure Kubernetes Service'e (AKS) kesintisiz geçiş

Bu makalede, mevcut iş yüklerini Azure Kubernetes Service (AKS) geçirmek ve mevcut AKS kümesinde en düşük veya sıfır kapalı kalma süresiyle yeni uygulama sürümleri yayınlamak için pratik, üretim odaklı yaklaşımlar açıklanmaktadır.

Hızlı yanıt: Geçiş için kaynak ve AKS ortamlarını paralel olarak çalıştırın ve trafiği aşamalı olarak kaydırın. Bir AKS kümesindeki tekrarlanan uygulama sürümleri için, hazır olma yoklamaları, denetimli trafik yönlendirmeleri, gözlemlenebilirlik denetimleri ve test edilmiş bir geri alma süreciyle birlikte aşamalı güncelleştirme, kanarya veya küme içi mavi-yeşil dağıtım kullanın.

Hızlı Runbook: AKS'ye Kesintisiz Geçiş İçin 5 Adım

1. Hedef AKS kümesini, sertifikaları, ağ yapılandırmasını ve gözlemlenebilirliği hazırlayın.
2. Uygulamayı hazır olma ve canlılık yoklamaları, PodDisruptionBudget ve kaynak istekleriyle dağıtın.
3. Çoğaltma, CSI anlık görüntüleri veya Velero ile verileri eşitleyin.
4. Traffic Manager ile göreli DNS ağırlıklarını veya giriş veya hizmet ağı yönlendirmesi ile kesin istek yüzdelerini kullanarak trafiği aşamalı olarak kaydırma.
5. Kararlılık ölçütleri karşılandığında SLO kapılarını doğrulayın ve eski altyapıyı devreden çıkarın.

Şunları yapmayı öğreneceksiniz:

• Mevcut AKS kümesinde, kümeyi değiştirmeden yeni bir uygulama sürümü bırakın.
• Mavi-Yeşil, Kanarya ve Sıralı DNS geçiş stratejilerini karşılaştırın.
• AKS'ye özgü komutlarla geçiş öncesi hazırlık denetim listesini çalıştırın.
• AKS ve Azure Traffic Manager kullanarak tam Blue-Green küme geçişi gerçekleştirin.
• CSI anlık görüntülerini, Azure Dosyalar veya Velero'yu kullanarak kalıcı verileri geçirin.
• Tam geçişten önce bir geri dönüş planı hazırlayın.

Geçiş stratejisi karşılaştırması

Risk toleransı, gözlemlenebilirlik olgunluğu ve geri alma gereksinimlerinize uyan bir geçiş yaklaşımı seçmek için bu karşılaştırmayı kullanın.

Strategy	Trafik etkisi	Geri alma hızı	Karmaşıklık	AKS özellikleri ve Azure hizmetleri
Blue-Green (küme veya ad alanı)	Minimum, çünkü trafik yalnızca yeşil sağlıklı olduğunda geçiş yapar	Trafiği yeniden mavi ortama yönlendirerek çok hızlı bir şekilde	Orta, çünkü yinelenen ortamlar ve trafik yönlendirmesi gerektirir	Azure Traffic Manager, Load Balancer genel IP adresleri, giriş
Canary Sürümü	Çok düşük, çünkü trafik yavaş yavaş kayıyor	Hızlı: kanarya ağırlığını azaltarak veya kanarya podlarının sayısını azaltarak	Orta-yüksek, çünkü trafiğin bölünmesi ve gözlemlenebilirlik gerektirir	Ingress (nginx veya Gateway API), servis ağı (Istio veya Linkerd), AKS ingress eklentileri
Sıralı DNS (TTL tabanlı)	DNS TTL'ye bağlıdır; daha kısa TTL etkisini düşürür	Orta, çünkü DNS önbellekleri geri almayı geciktirebilir	Düşük, çünkü kurulum basit ama daha az kesin	Azure DNS, düşük TTL değerine sahip kayıtlar, LoadBalancer veya Ingress

İş yükü karar matrisi

İş yükü türüne göre hızlı bir strateji önerisine ihtiyacınız olduğunda bu tabloyu kullanın.

İş yükü türü	Önerilen strateji	Neden?	Maliyet ve karmaşıklık
Durumsuz web/API	Canary, ardından nihai geçiş için Blue-Green	Hızlı geri dönüşle aşamalı risk azaltma	Medium
Durum bilgisi tutan veritabanı destekli uygulama	Blue-Green artı çoğaltma ve yükseltme veri yolu	En güçlü geri alma kontrolü ve net geri dönüş yolu	Yüksek
Yoğun dosya içeren iş yükleri	Blue-Green ve Azure Dosyalar kopyası/anlık görüntüsü	Geçiş öncesinde veri eşliğinin daha kolay doğrulanması	Orta-yüksek
Uzun süre çalışan işler/çalışanlar	Kuyruk boşaltma ile aşamalı güncelleme veya bakım penceresi	Kullanıcıya yönelik daha düşük etki, daha basit yönlendirme	Düşük-orta

Kademeli dağıtım araç seçenekleri

• El ile ağırlıklı yönlendirme (Traffic Manager artı giriş veya LoadBalancer): açık işleç denetimi ve basit bağımlılıklar istediğinizde en iyisidir.
• Hizmet ağı yönlendirmesi (Istio veya Linkerd): ayrıntılı yönlendirme, yeniden denemeler ve ilke denetimleri gerektiğinde en iyi yöntemdir.
• Argo Rollouts veya Flagger: otomatik aşamalı dağıtım, metrik analizi ve otomatik geri alma istediğiniz durumlarda en iyi seçenektir.

Genel DNS düzeyinde ağırlıklama için Traffic Manager'ı kullanın ve kümenin içinde otomatik dağıtım analizine ihtiyacınız olduğunda Bunu Argo Dağıtımları veya Flagger ile birleştirin.

Mevcut AKS kümesinde bir uygulamayı serbest bırakma

Uygulamanın yeni sürümleri, ikinci bir küme veya DNS geçişi gerektirmez. AKS'de zaten çalışan durum bilgisi olmayan bir uygulama için, birden çok replikaya ve Deployment stratejisine sahip bir Kubernetes RollingUpdate kullanın. Kubernetes aynı kümede yeni sürüm podlar oluşturur, hazır olmalarını bekler ve ardından eski sürüm podlarını aşamalı olarak kaldırır.

Aşağıdaki örnek, Kubernetes aynı anda fazladan bir pod başlatırken mevcut tüm replikaları kullanılabilir durumda tutar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  minReadySeconds: 10
  progressDeadlineSeconds: 600
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]

Kümenin aşırı gerilim podunun kapasitesine sahip olduğundan emin olun. Bildirimi uygulayın, dağıtımı izleyin ve yeni görüntüyü doğrulayın:

kubectl apply -f manifests/app-deployment.yaml
kubectl rollout status deployment/myapp --timeout=10m
kubectl get pods -l app=myapp -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready

Daha sonraki sürümler için imajı güncelleyin ve Deployment rollout'unu izleyin:

kubectl set image deployment/myapp myapp=myregistry.azurecr.io/myapp:v3
kubectl rollout status deployment/myapp --timeout=10m

Dağıtım sırasında hata oranını, gecikme süresini, pod hazırlığını ve iş işlemlerini izleyin. Bir kontrol noktası başarısız olursa sürümü durdurun veya geri alın:

kubectl rollout pause deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout status deployment/myapp --timeout=10m

PodDisruptionBudget, düğüm tahliyesi gibi gönüllü tahliye işlemleri sırasında replikaları korur, ancak bir uygulamanın aşamalı dağıtımı sırasında Deployment öğesinin podları nasıl değiştireceğini denetlemez. Sürüm kullanılabilirliğini denetlemek için maxSurge ve maxUnavailable kullanın. İstek bazında trafik yüzdeleri veya otomatik metrik analizi gerektiren uygulamalar için, stabil ve kanarya sürümlerini aynı kümede çalıştırın ve trafiği kademeli olarak yönlendirmek için bir ingress denetleyicisi, hizmet ağı, Argo Rollouts veya Flagger kullanın.

Başlamadan önce

• Azure CLI sürüm 2.59.0 veya üzeri.
• kubectl kaynak kümenize bağlı.
• Küme, ağ ve kimlik oluşturma ve yönetmeye yönelik AKS izinleri.
• /healthz gibi test edilmiş bir uygulama sağlık durumu uç noktası.
• Trafiğin devri öncesinde, bir geri dönüş sorumlusu ve geri dönüş kontrol listesi onaylanmış olmalıdır.
• DNS TTL azaltma planı tam geçiş işleminden en az 24-48 saat önce hazırlanmıştır.

TLS ve sertifika ön sağlama

Trafik kaydırmadan önce yeşil ortamda sertifika sağlayın. Mevcut ortam TLS sonlandırması yapıyorsa, geçiş yapmadan önce sertifikaları dışa aktarıp Kubernetes secret’larına içe aktarın (veya cert-manager’ı yapılandırın).

# Example: create a TLS secret in the target namespace
kubectl create secret tls myapp-tls \
  --cert ./tls.crt \
  --key ./tls.key \
  --namespace production

ACME kullanıyorsanız (örneğin, Let's Encrypt), HTTPS hatalarını önlemek için geçişten önce etki alanı doğrulamasını tamamlayın.

Geçiş öncesi hazır olma denetim listesi

Geçiş yapmadan önce bu denetimleri çalıştırın. Tüm dışarı aktarmaları sürüm denetimine veya güvenli depolama alanına kaydedin.

Kubernetes kaynaklarını kaynak kümeden dışarı aktarma

kubectl --context=current-prod-cluster get all --all-namespaces -o yaml > exports/all-namespaces-all-resources.yaml
kubectl --context=current-prod-cluster get deployments,statefulsets,daemonsets --all-namespaces -o yaml > exports/workloads.yaml
kubectl --context=current-prod-cluster get svc --all-namespaces -o yaml > exports/services.yaml
kubectl --context=current-prod-cluster get configmap,secret --all-namespaces -o yaml > exports/configs-secrets.yaml
kubectl --context=current-prod-cluster get pvc --all-namespaces -o yaml > exports/pvcs.yaml
kubectl --context=current-prod-cluster get ingress --all-namespaces -o yaml > exports/ingress.yaml

Important

Dışarı aktarılan gizli dizi bildirimlerini hassas veriler olarak kabul edin. Bunları yalnızca güvenli sistemlerde depolayın.

Aboneliği, kotaları ve ağ önkoşullarını doğrulama

az account show --query "{name:name, id:id, tenantId:tenantId}" -o table
az configure --defaults location=eastus resource_group=rg-aks-migration
az vm list-usage --location eastus -o table
az network public-ip list --resource-group rg-aks-migration -o table

Kimlik ve RBAC gereksinimlerini doğrulayın

az aks show --resource-group rg-aks-migration --name existing-aks --query aadProfile
az role assignment list --resource-group rg-aks-migration -o jsonc
az identity list --resource-group rg-aks-migration -o table

Devam etmeden önce aşağıdaki öğeleri onaylayın:

• Küme yöneticisi grupları ve Entra ID tümleştirme modeli.
• Yönetilen kimlik kapsamları ve rol atamaları.
• Hedef ortamda günlükleme, metrikler ve uyarılar etkinleştirildi.

Strateji kılavuzları

Sonraki bölümlerde bir tam Blue-Green örneği ve iş yükünüz için uyarlayabileceğiniz iki daha kısa desen (Kanarya ve Sıralı DNS) sağlanır.

Blue-Green küme geçişi

Bu senaryoda, üretim trafiği şu anda app.example.com konumundaki eski bir ortamdan sunulmaktadır. Yeni bir AKS kümesi (aks-green ) oluşturur, iş yükünü dağıtır, hem eski hem de yeşil uç noktaları Azure Traffic Manager kaydeder ve trafiği aşamalı olarak kaydırabilirsiniz.

Temel geçiş kılavuzu için bkz. Azure Kubernetes Service (AKS) için geçişe genel bakış.

1. Yeşil AKS kümesini oluşturma

RG=rg-aks-migration
LOCATION=eastus
CLUSTER=aks-green
NODE_COUNT=3

az group create --name $RG --location $LOCATION

az aks create \
  --resource-group $RG \
  --name $CLUSTER \
  --location $LOCATION \
  --node-count $NODE_COUNT \
  --enable-managed-identity \
  --network-plugin azure \
  --load-balancer-sku standard \
  --generate-ssh-keys \
  --enable-addons monitoring \
  --attach-acr <yourACRName> \
  --yes

Küme kimlik bilgilerini alma:

az aks get-credentials --resource-group $RG --name $CLUSTER --overwrite-existing
kubectl config use-context $CLUSTER

2. İş yükünü sistem durumu ve kesinti denetimleriyle dağıtın

oluşturun manifests/app-deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:green
        resources:
          requests:
            cpu: 250m
            memory: 256Mi
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-lb
  labels:
    app: myapp
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  externalTrafficPolicy: Local

Kaynak istekleri örnektir. Hedef kümenin üretim zamanlaması ve kapasite davranışını temsil edebilmesi için gözlemlenen iş yükü kullanımı ve yük testi sonuçlarından gelen CPU ve bellek isteklerini boyutlandırın.

externalTrafficPolicy: Local kaynak IP'yi korur ancak düğüm başına kullanılabilir arka uç uç noktalarını azaltabilir. Yapışkan oturum uygulamaları için, trafik vardiyaları sırasında benşim ile ilgili kesintileri önlemek için geçişten önce oturum durumunu (örneğin, Redis için Azure Önbellek) dışlaştırın.

oluşturun manifests/pdb.yaml.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Kaynakları uygulayın ve dağıtımı doğrulayın:

kubectl apply -f manifests/app-deployment.yaml
kubectl apply -f manifests/pdb.yaml
kubectl rollout status deployment/myapp
kubectl get svc myapp-lb -o wide

3. Yeşil uç noktayı alma

kubectl get svc myapp-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Sonraki adımlarda döndürülen IP'yi kullanın.

4. Azure Traffic Manager profili ve uç noktaları oluşturma

TM_PROFILE=myapp-tm

az network traffic-manager profile create \
  --name $TM_PROFILE \
  --resource-group $RG \
  --routing-method Weighted \
  --unique-dns-name myapp-tm-$RANDOM \
  --ttl 30 \
  --protocol http \
  --path /healthz \
  --interval 30 \
  --timeout 10

Eski uç noktayı ekleyin:

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name old-endpoint \
  --target old.example.com \
  --endpoint-status Enabled \
  --weight 100

Yeşil uç noktayı ekleyin:

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name green-endpoint \
  --target <green-endpoint-ip> \
  --endpoint-status Disabled \
  --weight 0

Komut ayrıntıları için bkz. az network traffic-manager profile ve az network traffic-manager endpoint.

5. Trafiği kademeli olarak yeşil ortama yönlendirin

Düşük ağırlıkla başlayın ve sistem durumunu ve gecikme süresini gözlemleyin.

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.endpointStatus=Enabled \
  --weight 10

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=90

Örneğin old ve green için önce 10:90, ardından 50:50 gibi aşamalı göreli ağırlık değişimleriyle devam edin. Traffic Manager, bu göreli ağırlıklara göre her DNS sorgusu için bir uç nokta seçer; ağırlıklar tam istek yüzdelerini garanti etmemektedir. DNS yanıtları istemciler ve özyinelemeli çözümleyiciler tarafından önbelleğe alınır ve bu da gözlemlenen dağıtımı çarpıtabilir. Devam etmeden önce her aşamayı, en az profil TTL’si kadar ve ayrıca temsili uygulama trafiğini ölçmeye yetecek süre boyunca sürdürün. İstek başına hassas dağıtıma ihtiyaç duyarsanız L7 girişi veya hizmet ağı kullanın.

Tam geçiş ölçütleri, izleme kontrol noktaları ve geri alma prosedürü

Her trafik artışı öncesinde açık geçitler tanımlayın.

Örnek geçitler

• HTTP 5xx arka arkaya 3 dakika boyunca 1% aşıyorsa geri alın.
• p95 gecikme süresi, baz değeri 5 dakika boyunca 200 ms'den fazla aşarsa geri alın.
• Veritabanı çoğaltma gecikmesi RPO eşiğinizi aşarsa dağıtımı duraklatın.
• Pod yeniden başlatma oranı normal düzeyin üzerine çıkarsa dağıtımı duraklatın.

İleri taşıma dizisi

1. Trafik ağırlığını küçük artışlarla artırın.
2. SLO geçitlerini ve iş dumanı testlerini doğrulayın.
3. Yalnızca tüm kapılar bekleme süresi boyunca geçerse devam edin.

Geri alma sırası

1. Eski uç noktaya yönlendirmeyi başlatın. İstemciler, TTL'lerinin süresi dolana kadar önbelleğe alınmış DNS yanıtlarını kullanmaya devam edebilir.
2. Dağıtımı geri alın veya gerekirse yeşili sıfıra ölçeklendirin.
3. Eski ortam durumunu ve veri bütünlüğünü yeniden doğrulayın.

# Restore old endpoint to 100
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=100

# Set green endpoint to 0
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.weight=0

# Optional Kubernetes rollback options
kubectl rollout undo deployment/myapp
kubectl scale deployment myapp --replicas=0

6. Gerekirse hızla geri alın

Hatalar artarsa veya SLO eşikleri başarısız olursa:

• Eski uç nokta kalınlığını 100 olarak, yeşili ise olarak 0ayarlayın.
• Daha fazla dağıtımı duraklatın ve isteğe bağlı olarak yeşil podların ölçeğini küçültün.

kubectl scale deployment myapp --replicas=0

Canary geçişi (kısa kılavuz)

Minimum düzeyde ek altyapıyla kademeli sürüm kontrolü istediğinizde canary dağıtımını kullanın.

1. Kararlı bir iş yükü ve bir kanarya iş yükü dağıtın.
2. Trafiğin küçük bir yüzdesini kanaryaya yönlendirin.
3. Önemli sinyalleri gözlemleyin, ardından artırın veya geri alın.

NGINX canary için örnek Ingress açıklamaları:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

Sağlık durumu stabil kaldığı sürece canary-weight değerini aşamalı olarak artırın.

Aşamalı DNS geçişi (kısa kılavuz)

Birincil trafik denetim mekanizmanız DNS geçişi olduğunda sıralı DNS kullanın.

Önbelleklerin eskiyebilmesi için tam geçişten en az 24-48 saat önce DNS TTL değerini düşük bir değere ayarlayın. Geçiş dengelendikten sonra sorgu hacmini ve çözümleyici değişim sıklıklarını azaltmak için daha yüksek bir TTL'yi geri yükleyin.

1. Daha düşük DNS TTL (örneğin, 30 saniye).
2. AKS uç noktasını dağıtın.
3. DNS A/CNAME kayıtlarını güncelleştirin.
4. Yayılmayı ve sağlığı gözlemleyin.

Örnek Kayıt güncelleştirmesi:

RG=rg-aks-migration

az network dns record-set a update \
  --resource-group $RG \
  --zone-name example.com \
  --name app \
  --set ttl=30

az network dns record-set a remove-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 13.78.1.2

az network dns record-set a add-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 52.160.1.100

Kalıcı birimler için veri geçişi

Durum bilgili geçiş genellikle en yüksek risk taşıyan alandır. Depolama türü ve tutarlılık gereksinimlerinizle eşleşen veri yolunu seçin.

Veritabanı stratejileri

Kapalı kalma süresi ve tutarlılık gereksinimlerinizle uyumlu bir veritabanı geçiş deseni seçin.

Desen	Pros	Takaslar	Tipik kullanım
Dış veritabanı (paylaşılan)	En basit uygulama taşıma yolu; uygulama taşınırken veritabanı cutover’ı gerekmez	Paylaşılan etki alanı, olası performans bağımlılığı	Eski ve yeni uygulama tarafından paylaşılan mevcut yönetilen PaaS DB
Çoğalt ve tanıt	Kontrollü geçiş ve geri alma noktası	Çoğaltma ve yükseltme için işlem yükü	Katı RPO gereksinimlerine sahip kritik durum bilgisi içeren iş yükleri
Çift yazma (geçici)	Neredeyse sıfır kesinti süresiyle uygulama geçişini mümkün kılar	Karmaşık mutabakat ve idempotentlik gereksinimleri	Olgun veri işlem hatlarına sahip olay odaklı sistemler

CDC ve geçiş düzenlemesi için Azure Veritabanı Geçiş Hizmeti ve Debezium'ı değerlendirin. Geçiş sırasında eski ve yeni uygulama sürümlerini uyumlu tutmak için expand -> migrate -> contract şema değişikliklerini kullanın.

Azure Disk CSI anlık görüntüleri

Anlık görüntü CRD'leri ve anlık görüntü denetleyicisi kuruluysa, blok birimleri için CSI anlık görüntülerini kullanın.

Örnek VolumeSnapshotClass:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-azuredisk-snapclass
driver: disk.csi.azure.com
deletionPolicy: Delete

Mevcut bir PVC'den örnek anlık görüntü:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mydata-snapshot
spec:
  volumeSnapshotClassName: csi-azuredisk-snapclass
  source:
    persistentVolumeClaimName: mydata-pvc

Anlık görüntüden PVC geri yükleme örneği:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mydata-pvc-restored
spec:
  storageClassName: managed-csi
  dataSource:
    name: mydata-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Important

Anlık görüntüler genellikle uygulama açısından tutarlı değil, çökme açısından tutarlıdır. Veritabanları için çoğaltma veya uygulamaya duyarlı yedekleme ve geri yükleme kullanın.

Azure Dosyalar

Dosya tabanlı iş yükleri için:

• Kaynak dosya paylaşımları için anlık görüntü veya kopyalama planları oluşturun.
• verileri AzCopy gibi araçlarla kopyalayın.
• Hedef paylaşım için StorageClass ve PVC yapılandırmasını güncelleştirin.

Örnek kopyalama düzeni:

az storage share snapshot --account-name mystorage --name myshare
azcopy copy "https://<src>/myshare" "https://<dest>/myshare" --recursive

Velero yedekleme ve geri yükleme

Azure eklentisiyle yapılandırıldığında PV verileri de dahil olmak üzere küme kaynağı yedekleme ve geri yükleme için Velero kullanın.

RG=rg-aks-migration

velero install \
  --provider azure \
  --bucket my-velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config resourceGroup=$RG,storageAccount=myvelerostorage,subscriptionId=<subscription-id>

velero backup create pre-migration-backup --include-namespaces my-namespace
velero restore create --from-backup pre-migration-backup

Velero belgelerine bakın ve AKS ile Azure Disk CSI anlık görüntülerini kullanma.

Gözlemlenebilirlik ve otomatik geri alma

Herhangi bir trafik kaydırmasından önce bu sinyalleri ölçümleyin:

• HTTP istek oranı ve başarı oranı.
• HTTP 5xx hata oranı.
• p95 ve p99 istek gecikme süresi.
• Pod yeniden başlatma hızı ve hazır olma hataları.
• Düğüm yükü ve bekleyen pod sayısı.
• Veritabanı çoğaltma gecikmesi.
• Eşzamansız iş yükleri için kuyruk derinliği.

Örnek PromQL stili uyarı koşulları:

# Rollback gate: 5xx error rate over 1%
sum(rate(http_requests_total{status=~"5.."}[3m]))
/
sum(rate(http_requests_total[3m])) > 0.01

# Rollback gate: p95 latency exceeds 200ms over baseline target
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.2

Uyarıları rollout denetleyicinizle (manuel runbook, Argo Rollouts veya Flagger) ilişkilendirin; böylece geçit başarısızlıkları otomatik olarak duraklatma veya geri alma işlemini tetikler.

Test ve doğrulama tarifleri

Gölge trafik

Son kullanıcılara yeşil yanıt döndürmeden üretim trafiğinin bir dilimini yeşile yansıtın. Bu, düşük kullanıcı riskiyle gerçekçi yük altında davranışı doğrular.

Duman testleri

Her ağırlık artışının ardından iş açısından kritik denetimler çalıştırın, örneğin:

• Oturum açma akışı
• Ödeme veya sipariş tamamlama akışı
• API yolunu okuma ve yazma
• Arka plan işi tamamlama

Yük testi

Son tam geçiş öncesinde kapasiteyi ve otomatik ölçeklendirme davranışını doğrulamak için k6, hey veya Azure Yük Testi gibi araçları kullanın.

Özellik bayrakları

Dağıtımı yayından ayrıştırmak için özellik bayraklarını kullanın. Riskli kod yollarını yeniden dağıtmadan devre dışı bırakmanız gerektiğinde özellik bayrakları ikinci bir güvenlik katmanı sağlayabilir.

Tam üretim denetim listesi

• [ ] Hazırlık ve canlılık problarının gerçekten hizmet vermeye hazır olma durumunu yansıttığını doğrulayın.
• [ ] Yük altındaki preStop ve terminationGracePeriodSeconds değerlerini doğrulayın.
• [ ] Yükseltme ve çıkarma olayları için PodDisruptionBudget değerlerini onaylayın.
• [ ] Beklenen geçiş trafiği ani artışları için otomatik ölçeklendirme ayarlarını onaylayın.
• [ ] Trafik giriş noktanız üzerinden uçtan uca durum denetimlerini doğrulayın.
• [ ] Geçişten önce günlükleri, metrikleri, uyarıları ve sentetik kontrolleri doğrulayın.
• [ ] Geri dönüşten sorumlu kişiyi, geri dönüşü tetikleme kriterlerini ve geri dönüş uygulama kılavuzunu onaylayın.
• [ ] Yeni uç noktalar için NSG, güvenlik duvarı ve sistem durumu yoklaması kurallarını doğrulayın.
• [ ] TLS sonlandırma davranışını doğrulayın ve CORS ayarları eski ortamla eşleşsin.
• [ ] Geçici mavi-yeşil örtüşme dönemi için maliyet planını doğrulayın.

Geri döndürme kontrol listesi

1. Trafiği eski uç noktaya kaydırın (Traffic Manager ağırlıkları veya DNS’yi geri alma).
2. Yeşil dağıtımı duraklatın veya ölçeğini küçültün.
3. Gerekirse önceki yapılandırmayı veya gizli dizileri geri yükleyin.
4. Normal işlemlere devam etmeden önce eski ortamın sağlığını yeniden doğrulayın.

Sonraki Adımlar

• Azure Kubernetes Service (AKS) için geçişe genel bakış konusunu inceleyin.
• AKS üretim yükseltme stratejilerini gözden geçirin.
• AKS’de mavi-yeşil düğüm havuzu yükseltmelerini inceleyin.
• Azure Traffic Manager belgelerini gözden geçirin.