Container Service for Kubernetes:Pemulihan bencana antarzona dengan gateway multi-kluster ACK One MSE

Buat Ingress untuk zona redundansi aktif

Buat Ingress yang meneruskan trafik ke service1 di domain example.com. Gateway mendistribusikan permintaan ke Service dengan nama yang sama di kedua kluster.

ingress-demo.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /svc1
        pathType: Exact
        backend:
          service:
            name: service1
            port:
              number: 80

Deploy Ingress di instans fleet.

kubectl apply -f ingress-demo.yaml -n gateway-demo

Verifikasi zona redundansi aktif

1. Dapatkan Alamat IP publik gateway multi-kluster.

   kubectl get ingress web-demo -n gateway-demo -ojsonpath="{.status.loadBalancer}"

2. Kirim 100 permintaan dan amati distribusi trafik. Ganti XX.XX.XX.XX dengan alamat IP gateway.

   for i in {1..100}; do curl -H "host: example.com" XX.XX.XX.XX; done

   Hasil yang diharapkan: Trafik didistribusikan antara Kluster 1 dan Kluster 2 dengan rasio 9:1.

   

3. Simulasikan kegagalan kluster dengan menskalakan replika Deployment di Kluster 1 menjadi 0. Seluruh trafik secara otomatis dialihkan ke Kluster 2.

   

Lakukan rilis canary dengan routing berbasis header

Dalam mode zona redundansi aktif, Anda dapat menguji rilis canary di satu kluster tanpa memengaruhi trafik langsung. Deploy versi canary sebagai Service dan Deployment terpisah, lalu gunakan anotasi Ingress untuk meneruskan permintaan dengan header tertentu ke versi tersebut.

1. Deploy aplikasi canary di Kluster 1. new-app.yaml

   apiVersion: v1
   kind: Service
   metadata:
     name: service1-canary-1
     namespace: gateway-demo
   spec:
     ports:
     - port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: web-demo-canary-1
     sessionAffinity: None
     type: ClusterIP
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-demo-canary-1
     namespace: gateway-demo
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: web-demo-canary-1
     template:
       metadata:
         labels:
           app: web-demo-canary-1
       spec:
         containers:
           - env:
               - name: ENV_NAME
                 value: cluster-demo-1-canary
             image: 'registry-cn-hangzhou.ack.aliyuncs.com/acs/web-demo:0.6.0'
             imagePullPolicy: Always
             name: web-demo

   kubectl apply -f new-app.yaml

2. Buat Ingress canary berbasis header di instans fleet. Permintaan dengan header canary-dest: cluster1 akan diteruskan ke Service canary. new-ingress.yaml

   Anotasi	Deskripsi
   nginx.ingress.kubernetes.io/canary	Diatur ke "true" untuk mengaktifkan routing berbasis header untuk Ingress ini
   nginx.ingress.kubernetes.io/canary-by-header	Kunci header yang dicocokkan (canary-dest)
   nginx.ingress.kubernetes.io/canary-by-header-value	Nilai header yang dicocokkan (cluster1)

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: web-demo-canary-1
     namespace: gateway-demo
     annotations:
       nginx.ingress.kubernetes.io/canary: "true"
       nginx.ingress.kubernetes.io/canary-by-header: "canary-dest"
       nginx.ingress.kubernetes.io/canary-by-header-value: "cluster1"
   spec:
     ingressClassName: mse
     rules:
     - host: example.com
       http:
         paths:
         - path: /svc1
           pathType: Exact
           backend:
             service:
               name: service1-canary-1
               port:
                 number: 80

   kubectl apply -f new-ingress.yaml

3. Verifikasi bahwa permintaan dengan header tersebut diteruskan ke versi canary.

   for i in {1..100}; do curl -H "host: example.com" -H "canary-dest: cluster1" XX.XX.XX.XX/svc1; sleep 1; done

   Hasil yang diharapkan: Semua permintaan dengan canary-dest: cluster1 ditangani oleh rilis canary di Kluster 1.

   

Buat Ingress untuk pemulihan bencana primer/sekunder

1. Buat Ingress primer yang mengikat trafik ke Kluster 1. Ganti ${cluster1-id} dengan ID kluster aktual. ingress-demo-cluster-one.yaml

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       mse.ingress.kubernetes.io/service-subset: cluster-demo-1
       mse.ingress.kubernetes.io/subset-labels: |
         topology.istio.io/cluster ${cluster1-id}
     name: web-demo-cluster-one
   spec:
     ingressClassName: mse
     rules:
     - host: example.com
       http:
         paths:
         - path: /service1
           pathType: Exact
           backend:
             service:
               name: service1
               port:
                 number: 80

   kubectl apply -f ingress-demo-cluster-one.yaml -n gateway-demo

Lakukan rilis canary tingkat kluster

Gunakan Ingress canary berbasis header bersama Ingress primer untuk meneruskan permintaan tertentu ke Kluster 2 guna validasi, tanpa mengubah jalur trafik default.

1. Buat Ingress canary yang menargetkan Kluster 2. Ganti ${cluster2-id} dengan ID kluster aktual. ingress-demo-cluster-gray.yaml

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       mse.ingress.kubernetes.io/service-subset: cluster-demo-2
       mse.ingress.kubernetes.io/subset-labels: |
         topology.istio.io/cluster ${cluster2-id}
       nginx.ingress.kubernetes.io/canary: "true"
       nginx.ingress.kubernetes.io/canary-by-header: "app-web-demo-version"
       nginx.ingress.kubernetes.io/canary-by-header-value: "gray"
     name: web-demo-cluster-gray
   spec:
     ingressClassName: mse
     rules:
     - host: example.com
       http:
         paths:
         - path: /service1
           pathType: Exact
           backend:
             service:
               name: service1
               port:
                 number: 80

   kubectl apply -f ingress-demo-cluster-gray.yaml -n gateway-demo

Verifikasi pemulihan bencana primer/sekunder

1. Dapatkan Alamat IP publik gateway multi-kluster.

   kubectl get ingress web-demo -n gateway-demo -ojsonpath="{.status.loadBalancer}"

2. Konfirmasi trafik default dialihkan ke Kluster 1.

   for i in {1..100}; do curl -H "host: example.com" XX.XX.XX.XX/service1; sleep 1; done

   Hasil yang diharapkan: Seluruh trafik default ditangani oleh Kluster 1.

   

3. Konfirmasi trafik canary dialihkan ke Kluster 2.

   for i in {1..50}; do curl -H "host: example.com" -H "app-web-demo-version: gray" XX.XX.XX.XX/service1; sleep 1; done

   Hasil yang diharapkan: Semua permintaan dengan app-web-demo-version: gray ditangani oleh Kluster 2.

   

4. Simulasikan kegagalan Kluster 1 dengan menskalakan replika Deployment menjadi 0. Seluruh trafik default secara otomatis dialihkan ke Kluster 2.