All Products
Search

This Product

    Alibaba Cloud Service Mesh:Menggunakan service mesh untuk pemulihan bencana zona ketersediaan

    Document Center

    Alibaba Cloud Service Mesh:Menggunakan service mesh untuk pemulihan bencana zona ketersediaan

    Last Updated:Jun 21, 2026

    Kegagalan tingkat zona ketersediaan merupakan gangguan ekstrem namun mungkin terjadi pada layanan cloud. Jika suatu zona ketersediaan gagal, workload di zona tersebut dapat menjadi tidak tersedia, tidak dapat dijangkau, atau mengembalikan error data. Topik ini menjelaskan cara menggunakan Container Service for Kubernetes (ACK) Alibaba Cloud dengan Service Mesh (ASM) Alibaba Cloud untuk menerapkan pemulihan bencana terhadap gangguan semacam itu.

    Latar Belakang

    Ketersediaan tinggi komponen yang dikelola

    Semua komponen yang dikelola dari kluster ACK dan instans ASM diterapkan dengan beberapa replika yang didistribusikan secara merata di beberapa zona ketersediaan. Hal ini memastikan bahwa lapisan kontrol kluster dan service mesh tetap beroperasi meskipun satu zona ketersediaan gagal. Demikian pula, node pekerja dan instans kontainer elastis dalam kluster juga didistribusikan di berbagai zona ketersediaan. Dalam kejadian kegagalan tingkat zona ketersediaan, seperti gangguan daya atau jaringan, zona ketersediaan yang sehat tetap beroperasi secara normal.

    Konfigurasi ketersediaan tinggi dan service mesh untuk kegagalan zona ketersediaan

    Untuk menangani kegagalan tingkat zona ketersediaan, langkah pertama adalah menerapkan workload aplikasi Anda secara merata di berbagai zona ketersediaan.

    ACK mendukung node pool multi-zona ketersediaan (AZ). Saat membuat dan mengelola node pool, disarankan untuk memilih vSwitch dari AZ berbeda serta menerapkan kebijakan distribusi seimbang saat mengonfigurasi auto-scaling. Pendekatan ini memungkinkan instans ECS didistribusikan secara merata di beberapa AZ yang ditentukan untuk grup penskalaan. Selain itu, Anda dapat memanfaatkan fitur seperti auto-scaling node, deployment set, dan distribusi multi-AZ, dikombinasikan dengan batasan penyebaran topologi Kubernetes, untuk menerapkan workload secara merata di berbagai AZ. Untuk detailnya, lihat Konfigurasi yang direkomendasikan untuk arsitektur kluster ketersediaan tinggi.

    Setelah aplikasi Anda diterapkan di beberapa zona ketersediaan, Anda perlu memantau kesehatan aplikasi dan kluster Kubernetes secara real time untuk mendeteksi kegagalan zona ketersediaan dan merespons dengan cepat guna memulihkan layanan.

    • Teknologi service mesh meningkatkan observabilitas jaringan sistem Anda. Proxy bidang data dalam service mesh mengekspos metrik utama terkait permintaan jaringan dan interaksi layanan aplikasi. Metrik ini, yang mencakup data untuk zona ketersediaan tertentu, dapat mengindikasikan berbagai masalah dan membantu Anda mendeteksi kegagalan zona ketersediaan.

    • Untuk kegagalan tingkat zona ketersediaan, ASM menyediakan pemulihan bencana dengan menggabungkan kemampuan traffic-shifting-nya dengan load balancer Anda. Ketika suatu zona ketersediaan menjadi tidak tersedia, Anda dapat merespons alert dengan mengonfigurasi traffic shifting untuk sementara mengalihkan lalu lintas jaringan intra-kluster dari zona yang terdampak. Ketika zona ketersediaan tersebut kembali sehat, Anda dapat melanjutkan pengiriman traffic ke zona tersebut.

    Arsitektur pemulihan bencana

    Menangani kegagalan tingkat zona ketersediaan melibatkan beberapa langkah:

    • Menerapkan workload secara merata di beberapa zona ketersediaan dan menyediakan kapasitas di masing-masing zona tersebut.

    • Memantau metrik layanan untuk mendeteksi kegagalan.

    • Ketika suatu zona ketersediaan gagal, segera mengalihkan traffic dari zona yang terdampak (secara manual atau otomatis) untuk memulihkan dari kegagalan. Hal ini terutama melibatkan:

      • Pengalihan traffic ingress: Pastikan load balancer yang berfungsi sebagai ingress traffic berhenti mengirimkan traffic ke zona ketersediaan yang terdampak.

      • Pengalihan traffic intra-kluster: Pastikan panggilan layanan dalam kluster tidak lagi mengirimkan traffic ke zona ketersediaan yang terdampak.

    Seperti yang ditunjukkan pada gambar berikut, untuk menangani kegagalan di beberapa zona ketersediaan, buatlah kluster ACK dengan node pekerja di beberapa zona ketersediaan dan terapkan workload Anda secara merata di antara zona-zona tersebut. Anda juga dapat mengumpulkan log lapisan kontrol dan event kluster dari kluster ACK dan instans ASM ke Log Service (SLS). ACK dan ASM dapat mengumpulkan metrik terkait node, kontainer, dan layanan ke Alibaba Cloud Managed Service for Prometheus. Pengaturan ini memungkinkan Anda segera mengamati event kegagalan di berbagai tingkat dan melihat status layanan dalam kluster melalui log dan Dasbor Grafana. Untuk ingress kluster, gunakan load balancer yang mendukung arsitektur multi-zona ketersediaan aktif-aktif, seperti Network Load Balancer (NLB) atau Application Load Balancer (ALB).

    ASM terus-menerus melaporkan log akses dan metrik permintaan untuk seluruh traffic ke dan dari layanan dalam kluster. ASM mengagregasi metrik seperti kode respons, latensi, dan ukuran permintaan. Ketika terjadi gray failure di suatu zona ketersediaan, metrik permintaan dan konfigurasi alert yang disediakan oleh service mesh sangat berguna untuk menentukan cakupan dan gejala kegagalan tersebut. Contoh ini menjelaskan cara melihat metrik traffic layanan yang dilaporkan oleh service mesh. Untuk informasi tentang metrik workload kluster dan konfigurasi alert, lihat Menghubungkan dan mengonfigurasi Managed Service for Prometheus, Manajemen alarm untuk Container Service, dan Pemantauan event.

    Konfigurasi pemulihan bencana

    Contoh ini menunjukkan cara melakukan pemulihan bencana untuk kegagalan tingkat zona ketersediaan dengan menggunakan kluster yang mencakup beberapa zona ketersediaan.

    Langkah 1: Siapkan lingkungan

    1. Buat kluster ACK yang dikelola. Saat membuat kluster, pilih vSwitch dari dua zona ketersediaan untuk mengaktifkan dukungan multi-AZ. Anda dapat mempertahankan nilai default untuk pengaturan lainnya. Node pool secara default menggunakan kebijakan penskalaan distribusi seimbang. Untuk informasi lebih lanjut, lihat Membuat kluster ACK yang dikelola.

    2. Buat instans ASM dengan konfigurasi zona ketersediaan yang sama seperti kluster ACK. Untuk informasi lebih lanjut, lihat Membuat instans ASM.

    3. Terapkan gateway dan aplikasi contoh.

      1. Di instans ASM, buat ASM Gateway dan asosiasikan dengan Network Load Balancer (NLB). Pilih dua zona ketersediaan yang sama untuk NLB seperti pada instans ASM dan kluster ACK (dalam contoh ini, cn-hangzhou-k dan cn-hangzhou-h). Untuk informasi lebih lanjut, lihat Menggunakan instans NLB di gerbang masuk ASM.

        Catatan

        Contoh ini menggunakan ASM Gateway yang diasosiasikan dengan NLB sebagai ingress traffic. Anda juga dapat menggunakan Application Load Balancer (ALB) sebagai ingress untuk aplikasi Anda. ALB juga menyediakan pemulihan bencana multi-zona ketersediaan dan kemampuan penghapusan rekaman DNS.

      2. Nonaktifkan fitur cross-zone forwarding untuk NLB. Hal ini memastikan bahwa NLB di setiap zona ketersediaan hanya meneruskan traffic ke backend dalam zona ketersediaan yang sama.

      3. Aktifkan injeksi sidecar otomatis untuk namespace default. Untuk informasi lebih lanjut, lihat Mengelola namespace global.

      4. Terapkan aplikasi contoh.

        Kode

        kubectl apply -f- <<EOF
apiVersion: v1
kind: Service
metadata:
  name: mocka
  labels:
    app: mocka
    service: mocka
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mocka
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-cn-hangzhou-h
  labels:
    app: mocka
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
  template:
    metadata:
      labels:
        app: mocka
        locality: cn-hangzhou-h
    spec:
      nodeSelector:      
        topology.kubernetes.io/zone: cn-hangzhou-h  
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: cn-hangzhou-h 
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mocka-cn-hangzhou-k
  labels:
    app: mocka
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mocka
  template:
    metadata:
      labels:
        app: mocka
        locality: cn-hangzhou-k
    spec:
      nodeSelector:      
        topology.kubernetes.io/zone: cn-hangzhou-k
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: cn-hangzhou-k
        - name: app
          value: mocka
        - name: upstream_url
          value: "http://mockb:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: mockb
  labels:
    app: mockb
    service: mockb
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mockb
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-cn-hangzhou-h
  labels:
    app: mockb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
  template:
    metadata:
      labels:
        app: mockb
        locality: cn-hangzhou-h
    spec:
      nodeSelector:      
        topology.kubernetes.io/zone: cn-hangzhou-h
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: cn-hangzhou-h
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockb-cn-hangzhou-k
  labels:
    app: mockb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockb
  template:
    metadata:
      labels:
        app: mockb
        locality: cn-hangzhou-k
    spec:
      nodeSelector:      
        topology.kubernetes.io/zone: cn-hangzhou-k
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: cn-hangzhou-k
        - name: app
          value: mockb
        - name: upstream_url
          value: "http://mockc:8000/"
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: mockc
  labels:
    app: mockc
    service: mockc
spec:
  ports:
  - port: 8000
    name: http
  selector:
    app: mockc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-cn-hangzhou-h
  labels:
    app: mockc
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
  template:
    metadata:
      labels:
        app: mockc
        locality: cn-hangzhou-h
    spec:
      nodeSelector:      
        topology.kubernetes.io/zone: cn-hangzhou-h
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: cn-hangzhou-h
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mockc-cn-hangzhou-k
  labels:
    app: mockc
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mockc
  template:
    metadata:
      labels:
        app: mockc
        locality: cn-hangzhou-k
    spec:
      nodeSelector:      
        topology.kubernetes.io/zone: cn-hangzhou-k
      containers:
      - name: default
        image: registry-cn-hangzhou.ack.aliyuncs.com/ack-demo/go-http-sample:tracing
        imagePullPolicy: IfNotPresent
        env:
        - name: version
          value: cn-hangzhou-k
        - name: app
          value: mockc
        ports:
        - containerPort: 8000
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: mocka
  namespace: default
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - '*'
      port:
        name: test
        number: 80
        protocol: HTTP
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: demoapp-vs
  namespace: default
spec:
  gateways:
    - mocka
  hosts:
    - '*'
  http:
    - name: test
      route:
        - destination:
            host: mocka
            port:
              number: 8000
EOF

        Perintah di atas menerapkan aplikasi yang terdiri dari layanan mocka, mockb, dan mockc. Setiap layanan mencakup dua deployment tanpa status, masing-masing dengan satu replika. Deployment didistribusikan ke node di zona ketersediaan berbeda menggunakan field nodeSelector yang berbeda dan dikonfigurasi dengan variabel lingkungan untuk mengembalikan zona ketersediaan tempat mereka berada.

        Catatan

        Untuk memberikan demonstrasi yang jelas, contoh ini menggunakan field nodeSelector pod untuk memilih secara manual zona ketersediaan pod tersebut. Di lingkungan produksi ketersediaan tinggi, Anda harus mengonfigurasi batasan penyebaran topologi untuk memastikan bahwa pod didistribusikan di berbagai zona ketersediaan sebanyak mungkin. Untuk informasi lebih lanjut, lihat Konfigurasi ketersediaan tinggi workload.

    Langkah 2: Pantau metrik layanan

    Ketika terjadi kegagalan, log, metrik, dan alert workload membantu Anda dengan cepat mendeteksi kegagalan, menentukan cakupannya, serta memahami dampak atau akar penyebabnya.

    1. Tambahkan dimensi zona ketersediaan ke metrik permintaan.

      Proxy mesh dapat secara otomatis mendeteksi zona ketersediaan tempat workload diterapkan dan menyimpan informasi ini dalam metadata proxy. Anda dapat mengedit dimensi metrik untuk menambahkan dimensi locality ke metrik service mesh dan mengatur nilainya ke xds.node.locality.zone, yang merepresentasikan zona ketersediaan workload tersebut. Untuk informasi lebih lanjut, lihat Konfigurasi observabilitas.

    2. Kirim permintaan ke aplikasi contoh untuk menghasilkan metrik permintaan.

      watch -n 0.1 curl nlb-xxxxxxxxxxxxx.cn-xxxxxxx.nlb.aliyuncsslb.com/mock -v

      Output yang diharapkan:

      > GET /mock HTTP/1.1
> Host: nlb-85h289ly4hz9qhaz58.cn-hangzhou.nlb.aliyuncsslb.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK
< date: Sun, 08 Dec 2024 11:53:26 GMT
< content-length: 150
< content-type: text/plain; charset=utf-8
< x-envoy-upstream-service-time: 5
< server: istio-envoy
< 
* Connection #0 to host nlb-85h289ly4hz9qhaz58.cn-hangzhou.nlb.aliyuncsslb.com left intact
-> mocka(version: cn-hangzhou-h, ip: 192.168.122.66)-> mockb(version: cn-hangzhou-k, ip: 192.168.0.47)-> mockc(version: cn-hangzhou-h, ip: 192.168.122.44)%

      Output menunjukkan bahwa permintaan diarahkan secara acak ke dua zona ketersediaan berbeda, yang mengindikasikan bahwa workload di kedua zona tersebut tersedia.

    3. Setelah mengirim permintaan selama periode tertentu, jelajahi metrik di Managed Service for Prometheus. Untuk informasi lebih lanjut, lihat Metric Explorer.

      1. Lihat informasi kode status permintaan untuk workload di zona ketersediaan berbeda.

        Untuk memeriksa laju permintaan untuk workload di zona ketersediaan tertentu (dikelompokkan berdasarkan nama layanan dan kode respons), gunakan kueri PromQL berikut di instans Prometheus Anda:

        sum by(app, response_code) (rate(istio_requests_total{locality="cn-hangzhou-h", reporter="destination"}[$__rate_interval]))

        Hasil yang diharapkan:

        image

        Dengan penerapan yang merata, laju permintaan yang diterima oleh kedua zona ketersediaan hampir identik. Anda dapat mengubah kondisi filter menjadi locality="cn-hangzhou-k" untuk melihat laju permintaan dan informasi kode status untuk zona ketersediaan cn-hangzhou-k.

      2. Lihat informasi latensi permintaan untuk workload di zona ketersediaan berbeda.

        Untuk memeriksa latensi permintaan rata-rata untuk workload di zona ketersediaan tertentu (dikelompokkan berdasarkan nama layanan dan kode respons), gunakan kueri PromQL berikut di instans Prometheus Anda:

        sum by(app, response_code) (rate(istio_request_duration_milliseconds_sum{locality="cn-hangzhou-h", reporter="destination"}[$__rate_interval]))

        Anda dapat mengubah kondisi filter menjadi locality="cn-hangzhou-k" untuk melihat informasi latensi rata-rata untuk zona ketersediaan cn-hangzhou-k.

    4. Konfigurasikan aturan alert berdasarkan metrik.

      Anda dapat mengonfigurasi alert dengan menggunakan kueri PromQL kustom. Ketika latensi layanan atau laju kode status non-200 melebihi ambang batas, Prometheus mengirim alert ke kontak yang ditentukan. Untuk informasi lebih lanjut, lihat Membuat aturan alert Prometheus.

      1. Buat aturan alert berdasarkan latensi aplikasi.

        Gunakan kueri PromQL berikut untuk membuat alert untuk layanan mockb.

        sum by(response_code, locality) (rate(istio_request_duration_milliseconds_sum{app="mockb",reporter= "destination"}[1m])) > 3

        Kueri di atas memicu alert jika latensi rata-rata layanan mockb selama interval satu menit melebihi 3 ms. Alert dikelompokkan berdasarkan kode status dan zona ketersediaan.

      2. Buat aturan alert berdasarkan kode status respons layanan.

        Gunakan kueri PromQL berikut untuk membuat alert untuk layanan mocka.

        sum by (locality, response_code) (rate(istio_requests_total{app="mocka",reporter="destination",response_code!="200"}[1m])) >= 0

      Anda dapat membuat aturan alert untuk aplikasi lain dengan mengubah pengaturan app="mockb" pada aturan alert di atas.

    Langkah 3: Lakukan latihan pemulihan bencana

    Setelah Anda menerima alert bahwa suatu zona ketersediaan di kluster ACK Anda tidak sehat atau terganggu, Anda dapat mengisolasi workload layanan yang diterapkan di zona tersebut dari zona lain. Hal ini memungkinkan Anda menyelidiki penyebab kegagalan sambil menjaga bisnis tetap berjalan. Setelah kegagalan terselesaikan, Anda dapat memulihkan traffic ke zona ketersediaan tersebut.

    1. Isolasi node di zona ketersediaan yang terdampak.

      Terapkan taint pada node untuk mencegah penjadwalan pod baru di atasnya. Setelah taint diterapkan, node menjadi tidak dapat dijadwalkan. Pod yang sudah ada tetap berada di node tersebut, tetapi tidak ada pod baru yang dijadwalkan di zona ketersediaan tersebut. Untuk informasi lebih lanjut, lihat Mengatur status penjadwalan untuk node. Contoh berikut menunjukkan cara mengisolasi zona ketersediaan cn-hangzhou-h dengan menandai semua node di dalamnya sebagai tidak dapat dijadwalkan.

    2. Alihkan traffic ingress north-south.

      Karena NLB dikonfigurasi untuk forwarding zona yang sama, Anda harus menggunakan fitur penghapusan rekaman DNS NLB (atau ALB) untuk segera mengalihkan traffic north-south di lapisan ingress ketika terjadi kegagalan. Hal ini mencegah traffic eksternal terus mengalir ke zona ketersediaan yang gagal.

      1. Masuk ke Konsol NLB dan klik instans NLB yang diasosiasikan dengan ASM Gateway.

      2. Pada halaman detail instans NLB, di tab Zone, temukan zona ketersediaan yang terdampak. Di kolom Actions, klik Remove DNS, lalu klik OK pada kotak dialog yang muncul. Setelah rekaman DNS dihapus, alamat IP publik NLB di zona ketersediaan yang terdampak tidak lagi termasuk dalam catatan resolusi DNS.

    3. Alihkan lalu lintas timur-barat.

      Anda dapat menggunakan fitur traffic shifting zona ketersediaan Alibaba Cloud Service Mesh (ASM) untuk segera mengarahkan ulang traffic east-west dalam kluster, mencegah traffic mencapai endpoint di zona ketersediaan tertentu.

      1. Masuk ke Konsol Service Mesh dan klik instans ASM yang mengelola kluster tersebut.

      2. Pada halaman detail mesh, klik Service Discovery Selectors. Klik Show Advanced Settings, masukkan informasi wilayah dan zona ketersediaan tempat pod berada, lalu klik OK.

      Setelah operasi ini, instans akan sejenak memasuki status pembaruan. Ketika pembaruan selesai, endpoint di zona ketersediaan yang ditentukan dikecualikan dari cakupan penemuan layanan.

    4. Amati efek isolasi.

      Lanjutkan mengakses aplikasi contoh. Anda akan menemukan bahwa semua respons berasal dari layanan di zona ketersediaan cn-hangzhou-k. Hal ini menunjukkan bahwa traffic telah sepenuhnya dialihkan dari zona ketersediaan cn-hangzhou-h. Output yang diharapkan:

      > Host: nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com
> User-Agent: curl/8.7.1q
> Accept: */*
> A
* Request completely sent off
< HTTP/1.1 200 OKe
< date: Tue, 10 Dec 2024 04:03:26 GMT
< content-length: 1500
< content-type: text/plain; charset=utf-8
< x-envoy-upstream-service-time: 30
< server: istio-envoyr
< s
{ [150 bytes data]
{100   150  100   150    0     0   2262      0 --:--:-- --:--:-- --:--:--  2238
* Connection #0 to host nlb-xxxxxxxxxxxxxxxxxxx8.cn-hangzhou.nlb.aliyuncsslb.com left intact
-> mocka(version: cn-hangzhou-k, ip: 192.168.0.44)-> mockb(version: cn-hangzhou-k, ip: 192.168.0.47)-> mockc(version: cn-hangzhou-k, ip: 192.168.0.46)