Gunakan kontroler Ingress NGINX untuk mengimplementasikan rilis canary dan penyebaran biru-hijau - Container Service for Kubernetes

Saat memperbarui versi aplikasi, Anda dapat mengimplementasikan pembaruan bertahap, rilis bertahap, blue-green deployment, dan rilis canary. Topik ini menjelaskan cara mengimplementasikan rilis canary untuk aplikasi dalam kluster Container Service for Kubernetes (ACK) menggunakan NGINX Ingress Controller.

Informasi Latar Belakang

Anda dapat mengimplementasikan rilis canary atau blue-green deployment untuk mempublikasikan aplikasi dari versi sebelumnya dan versi baru ke lingkungan produksi yang identik. Dalam hal ini, ketika pengguna mengirim permintaan, ACK akan merutekan beberapa permintaan ke versi baru berdasarkan aturan tertentu. Jika versi baru berjalan normal selama periode waktu tertentu, Anda dapat beralih semua trafik dari versi sebelumnya ke versi baru.

Blue-green deployment adalah metode untuk mengimplementasikan rilis canary. Dalam blue-green deployment, beberapa pengguna menggunakan versi sebelumnya, dan permintaan dari pengguna lainnya diteruskan ke versi baru. Jika versi baru berjalan normal selama periode waktu tertentu, Anda dapat secara bertahap beralih semua trafik ke versi baru.

Anda dapat mengonfigurasi cara mengimplementasikan rilis canary menggunakan salah satu metode berikut di konsol ACK:

Gunakan anotasi canary-*: Anda dapat menggunakan anotasi canary-* untuk mengonfigurasi cara mengimplementasikan penyebaran biru-hijau dan rilis canary. Anotasi canary-* digunakan oleh Kubernetes.
Gunakan anotasi service-*: Anda dapat menggunakan anotasi service-* untuk mengonfigurasi cara mengimplementasikan penyebaran biru-hijau dan rilis canary. Anotasi service-* digunakan oleh versi kontroler Ingress NGINX awal untuk mengimplementasikan rilis canary. Anotasi service-match dan service-weight tidak lagi dipelihara dan akan segera ditinggalkan. Anotasi service-* masih dapat digunakan.

Skenario penggunaan

Traffic splitting based on requests

Sebagai contoh, Anda sudah membuat Layanan A di lingkungan produksi Anda untuk menyediakan akses Lapisan 7 bagi pengguna. Saat fitur baru tersedia, Anda ingin membuat Layanan A' untuk versi aplikasi baru. Jika Anda ingin tetap menggunakan Layanan A untuk akses eksternal, Anda dapat meneruskan permintaan yang nilainya dari parameter foo di header permintaan cocok dengan bar atau yang nilainya dari parameter foo di cookie cocok dengan bar ke Layanan A'. Jika versi baru berjalan stabil selama periode waktu tertentu, Anda dapat beralih semua trafik dari Layanan A ke Layanan A'. Kemudian, Anda dapat menghapus Layanan A.

Traffic splitting based on Service weights

Sebagai contoh, Anda sudah membuat Layanan B di lingkungan produksi Anda untuk menyediakan akses Lapisan 7 bagi pengguna. Saat beberapa masalah diperbaiki, Anda ingin membuat Layanan B' untuk versi aplikasi baru. Jika Anda ingin tetap menggunakan Layanan B untuk akses eksternal, Anda dapat beralih 20% trafik ke Layanan B'. Jika versi baru berjalan stabil selama periode waktu tertentu, Anda dapat beralih semua trafik dari Layanan B ke Layanan B'. Kemudian, Anda dapat menghapus Layanan B.

Ingress Controller dari ACK menyediakan metode pemisahan trafik berikut untuk mendukung persyaratan aplikasi yang disebutkan di atas.

Pemisahan trafik berdasarkan header permintaan. Metode ini berlaku untuk skenario di mana rilis canary atau pengujian A/B diperlukan.
Pemisahan trafik berdasarkan cookie. Metode ini berlaku untuk skenario di mana rilis canary atau pengujian A/B diperlukan.
Pemisahan trafik berdasarkan parameter query. Metode ini berlaku untuk skenario di mana rilis canary atau pengujian A/B diperlukan.
Pemisahan trafik berdasarkan bobot layanan. Metode ini berlaku untuk skenario di mana blue-green deployment diperlukan.

Gunakan anotasi canary-*

Annotations

Tabel berikut menjelaskan anotasi canary-* yang digunakan oleh kontroler Ingress NGINX untuk mengimplementasikan rilis canary:

Anotasi	Deskripsi	Versi NGINX Ingress controller yang berlaku
nginx.ingress.kubernetes.io/canary	Anda harus menyetel nilai anotasi ini ke `true`. Jika tidak, aturan lainnya tidak akan berlaku. Nilai valid: `true`: mengaktifkan fitur `canary`. `false`: menonaktifkan fitur `canary`.	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-by-header	Mengimplementasikan rilis canary berdasarkan header permintaan. Nilai khusus berikut didukung: `always`: meneruskan semua trafik ke versi aplikasi baru. `never`: tidak meneruskan trafik ke versi aplikasi baru. Jika Anda tidak menentukan header, semua permintaan dengan header akan diteruskan.	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-by-header-value	Mengimplementasikan rilis canary berdasarkan nilai header permintaan. Anda harus menggunakan anotasi ini bersama dengan anotasi `canary-by-header`.	≥ 0.30.0
nginx.ingress.kubernetes.io/canary-by-header-pattern	Mengimplementasikan rilis canary berdasarkan apakah nilai header permintaan cocok dengan ekspresi reguler yang ditentukan. Anda harus menggunakan anotasi ini bersama dengan anotasi `canary-by-header`. Tetapkan nilai ke ekspresi reguler yang ingin Anda gunakan untuk mencocokkan nilai header permintaan.	≥ 0.44.0
nginx.ingress.kubernetes.io/canary-by-cookie	Mengimplementasikan rilis canary berdasarkan cookie. Contoh: `nginx.ingress.kubernetes.io/canary-by-cookie: foo`. Nilai cookie: `always`: Jika `foo=always` ditentukan dalam cookie, permintaan diteruskan ke versi aplikasi baru. `never`: Jika `foo=never` ditentukan dalam cookie, permintaan tidak diteruskan ke versi aplikasi baru. Trafik hanya diteruskan jika cookie ada dan nilainya adalah `always`.	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-weight	Mengimplementasikan rilis canary berdasarkan bobot. Nilai valid: 0 hingga total bobot. Total bobot default adalah 100.	≥ 0.22.0
nginx.ingress.kubernetes.io/canary-weight-total	Total bobot. Total bobot default adalah 100.	≥ 1.1.2

Anotasi di atas berlaku dalam urutan prioritas menurun:

canary-by-header>canary-by-cookie>canary-weight

Catatan

Anda hanya dapat menentukan satu Ingress canary dalam aturan Ingress. Jika menentukan lebih dari satu Ingress canary, hanya satu Ingress canary yang digunakan untuk mengimplementasikan rilis canary.

Langkah 1: Menyebarkan aplikasi

Buat aplikasi NGINX dan terapkan NGINX Ingress Controller untuk mengaktifkan akses Lapisan 7 ke aplikasi menggunakan nama domain.

Buat Deployment dan Layanan.

Buat file bernama nginx.yaml.

Tampilkan konten YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: old-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: old-nginx
  sessionAffinity: None
  type: NodePort

Jalankan perintah berikut untuk membuat Deployment dan Layanan:
```
kubectl apply -f nginx.yaml
```

Buat Ingress.

Buat file bernama ingress.yaml.

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```

Uji Akses ke Ingress.
1. Jalankan perintah berikut untuk menanyakan alamat IP publik dari Ingress:
```
kubectl get ingress
```
2. Jalankan perintah berikut untuk mengakses Ingress:
```
curl -H "Host: www.example.com"  http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
old
```

Langkah 2: Implementasikan rilis canary aplikasi

Rilis versi baru aplikasi NGINX dan konfigurasikan aturan Ingress.

Buat Deployment dan Layanan untuk versi aplikasi baru.

Buat file bernama nginx1.yaml.

Tampilkan konten YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: NodePort

Jalankan perintah berikut untuk menyebarkan Deployment dan Layanan untuk versi aplikasi baru:
```
kubectl apply -f nginx1.yaml
```

Konfigurasikan aturan Ingress untuk versi aplikasi baru.

ACK menyediakan jenis aturan Ingress berikut. Pilih jenis aturan Ingress berdasarkan kebutuhan Anda.

Konfigurasikan aturan Ingress untuk meneruskan permintaan yang sesuai dengan aturan ke versi aplikasi baru. Dalam contoh berikut, hanya permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke versi aplikasi baru.

Buat Ingress baru bernama gray-release-canary di file ingress1.yaml.

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary.
    nginx.ingress.kubernetes.io/canary: "true"
    # Tetapkan header permintaan ke foo.
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Hanya permintaan yang header-nya adalah foo dan nilai headernya adalah bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary.
    nginx.ingress.kubernetes.io/canary: "true"
    # Tetapkan header permintaan ke foo.
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Hanya permintaan yang header-nya adalah foo dan nilai headernya adalah bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"

spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk menyebarkan Ingress1:
```
kubectl apply -f ingress1.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Uji akses ke Ingress.
1. Jalankan perintah berikut untuk mengakses aplikasi NGINX:
```
curl -H "Host: www.example.com"  http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
old
```
2. Jalankan perintah berikut untuk mengakses aplikasi NGINX menggunakan permintaan yang nilai parameter foo di header permintaan cocok dengan bar:
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
new
```
Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa hanya permintaan yang nilai parameter foo di header permintaan cocok dengan bar yang diteruskan ke versi aplikasi baru.

Teruskan proporsi tertentu dari permintaan ke versi aplikasi baru saat permintaan tidak sesuai dengan aturan. Dalam contoh berikut, hanya 50% dari permintaan di mana nilai parameter foo di header permintaan tidak cocok dengan bar yang diteruskan ke versi baru.

Ubah Ingress yang dibuat di 2 berdasarkan konten berikut:

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary.
    nginx.ingress.kubernetes.io/canary: "true"
    # Tetapkan header permintaan ke foo.
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Hanya permintaan yang header-nya adalah foo dan nilai headernya adalah bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
    # Hanya 50% dari permintaan yang tidak sesuai dengan aturan sebelumnya yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary.
    nginx.ingress.kubernetes.io/canary: "true"
    # Tetapkan header permintaan ke foo.
    nginx.ingress.kubernetes.io/canary-by-header: "foo"
    # Hanya permintaan yang header-nya adalah foo dan nilai headernya adalah bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/canary-by-header-value: "bar"
    # Hanya 50% dari permintaan yang tidak sesuai dengan aturan sebelumnya yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Uji akses ke Ingress.
1. Jalankan perintah berikut untuk mengakses aplikasi NGINX:
```
curl -H "Host: www.example.com"  http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
old
```
2. Jalankan perintah berikut untuk mengakses aplikasi NGINX menggunakan permintaan yang nilai parameter foo di header permintaan cocok dengan bar:
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
new
```
- Permintaan yang nilai parameter foo di header permintaan cocok dengan bar:
  Semua permintaan diteruskan ke Layanan new-nginx. Anda dapat mengonfigurasi aturan pencocokan menggunakan anotasi canary-by-header dan canary-by-header-value.
- Permintaan yang nilai parameter foo di header permintaan tidak cocok dengan bar:
  50% dari permintaan diteruskan ke Layanan new-nginx. Anda dapat mengonfigurasi aturan pencocokan menggunakan anotasi canary-weight.

Konfigurasikan aturan Ingress untuk meneruskan proporsi tertentu dari permintaan ke versi aplikasi baru. Dalam contoh berikut, hanya 50% dari permintaan yang diteruskan ke versi aplikasi baru.

Ubah Ingress yang dibuat di Langkah 2 berdasarkan konten berikut:

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary.
    nginx.ingress.kubernetes.io/canary: "true"
    # Hanya 50% dari permintaan yang diteruskan ke Layanan new-nginx.
    # Total bobot default adalah 100.
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release-canary
  annotations:
    # Aktifkan fitur rilis canary.
    nginx.ingress.kubernetes.io/canary: "true"
    # Hanya 50% dari permintaan yang diteruskan ke Layanan new-nginx.
    # Total bobot default adalah 100.
    nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```
Jalankan perintah berikut untuk mendapatkan alamat IP dari Ingress guna akses eksternal:
```
kubectl get ingress
```

Jalankan perintah berikut untuk mengakses Ingress:

curl -H "Host: www.example.com" http://<EXTERNAL_IP>

Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa hanya 50% dari permintaan yang diteruskan ke versi aplikasi baru.

Langkah 3: Hapus versi aplikasi sebelumnya dan Layanan terkait

Jika versi aplikasi baru berjalan sesuai harapan selama periode waktu tertentu, Anda perlu membawa versi aplikasi sebelumnya offline dan hanya menyediakan versi aplikasi baru untuk akses. Untuk melakukannya, gunakan Layanan yang dibuat untuk versi aplikasi lama untuk memberikan akses ke Deployment yang dibuat untuk versi aplikasi baru. Anda juga harus menghapus Deployment yang dibuat untuk versi aplikasi lama dan Layanan yang dibuat untuk versi aplikasi baru.

Ubah file nginx.yaml dari versi aplikasi lama untuk memilih Deployment yang dibuat untuk versi aplikasi baru.

Lihat konten YAML

apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    # Tentukan pemilih yang digunakan untuk memilih Deployment yang dibuat untuk versi aplikasi baru.
    run: new-nginx
  sessionAffinity: None
  type: NodePort

Jalankan perintah berikut untuk membuat Layanan untuk versi aplikasi lama:
```
kubectl apply -f nginx.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Jalankan perintah berikut untuk mengakses Ingress:
```
curl -H "Host: www.example.com" http://<EXTERNAL_IP>
```
Output yang Diharapkan:
```
new
```
Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa semua permintaan diteruskan ke versi aplikasi baru.
Jalankan perintah berikut untuk menghapus Ingress canary bernama gray-release-canary:
```
kubectl delete ingress gray-release-canary
```
Hapus Deployment yang dibuat untuk versi aplikasi sebelumnya dan Layanan yang dibuat untuk versi aplikasi baru.
1. Jalankan perintah berikut untuk menghapus Deployment yang dibuat untuk versi aplikasi sebelumnya:
```
kubectl delete deploy old-nginx
```
2. Jalankan perintah berikut untuk menghapus Layanan yang dibuat untuk versi aplikasi baru:
```
kubectl delete svc new-nginx
```

service-* annotations

Annotations

Daftar berikut menjelaskan anotasi service-* yang digunakan oleh NGINX Ingress Controller untuk mengimplementasikan rilis canary:

nginx.ingress.kubernetes.io/service-match

Anotasi ini digunakan untuk mengonfigurasi aturan pencocokan untuk permintaan ke Layanan yang dibuat untuk versi aplikasi baru.

nginx.ingress.kubernetes.io/service-match: | 
    <service-name>: <match-rule>
# Parameter
# service-name: nama Layanan. Permintaan yang sesuai dengan aturan yang ditentukan oleh match-rule akan diteruskan ke Layanan.
# match-rule: aturan pencocokan untuk permintaan.
#
# Aturan pencocokan:
# 1. Jenis aturan pencocokan berikut didukung:
# - header: mencocokkan permintaan berdasarkan header permintaan. Ekspresi reguler dan aturan pencocokan tepat didukung.
# - cookie: mencocokkan permintaan berdasarkan cookie. Ekspresi reguler dan aturan pencocokan tepat didukung.
# - query: berdasarkan parameter query. Ekspresi reguler dan aturan pencocokan tepat didukung.
#
# 2. Metode pencocokan berikut didukung:
# - Ekspresi reguler: /{ekspresi reguler}/. Ekspresi reguler diapit oleh sepasang garis miring (/).
# - Aturan pencocokan tepat:"{ekspresi tepat}". Aturan pencocokan tepat diapit oleh sepasang tanda kutip (").

Contoh aturan pencocokan:

# Jika nilai parameter foo di header permintaan cocok dengan ekspresi reguler ^bar$, permintaan diteruskan ke Layanan new-nginx.
new-nginx: header("foo", /^bar$/)
# Jika nilai parameter foo di header permintaan persis cocok dengan nilai bar, permintaan diteruskan ke Layanan new-nginx.
new-nginx: header("foo", "bar")
# Jika nilai parameter foo di cookie cocok dengan ekspresi reguler ^sticky-.+$, permintaan diteruskan ke Layanan new-nginx.
new-nginx: cookie("foo", /^sticky-.+$/)
# Jika nilai parameter foo di parameter query persis cocok dengan nilai bar, permintaan diteruskan ke Layanan new-nginx.
new-nginx: query("foo", "bar")

nginx.ingress.kubernetes.io/service-weight

Anotasi ini digunakan untuk menetapkan bobot Layanan yang dibuat untuk versi aplikasi lama dan baru.

nginx.ingress.kubernetes.io/service-weight: | 
    <new-svc-name>:<new-svc-weight>, <old-svc-name>:<old-svc-weight>
Parameter dalam perintah di atas:
new-svc-name: nama Layanan yang dibuat untuk versi aplikasi baru.
new-svc-weight: bobot trafik Layanan yang dibuat untuk versi aplikasi baru.
old-svc-name: nama Layanan yang dibuat untuk versi aplikasi lama.
old-svc-weight: bobot trafik Layanan yang dibuat untuk versi aplikasi lama.

Contoh konfigurasi bobot Layanan:

nginx.ingress.kubernetes.io/service-weight: | 
    new-nginx: 20, old-nginx: 60

Langkah 1: Menyebarkan aplikasi

Buat aplikasi NGINX dan terapkan NGINX Ingress Controller untuk mengaktifkan akses Lapisan 7 ke aplikasi menggunakan nama domain.

Buat Deployment dan Layanan.

Buat file bernama nginx.yaml.

Lihat konten YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: old-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: old-nginx
  sessionAffinity: None
  type: NodePort

Jalankan perintah berikut untuk membuat Deployment dan Layanan:
```
kubectl apply -f nginx.yaml
```

Buat Ingress.

Buat file bernama ingress.yaml.

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```

Uji akses ke Ingress.
1. Jalankan perintah berikut untuk menanyakan alamat IP publik dari Ingress:
```
kubectl get ingress
```
2. Jalankan perintah berikut untuk mengakses Ingress:
```
curl -H "Host: www.example.com"  http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
old
```

Langkah 2: Implementasikan rilis canary aplikasi

Rilis versi baru aplikasi NGINX dan konfigurasikan aturan Ingress.

Buat Deployment dan Layanan untuk versi aplikasi baru.

Buat file bernama nginx1.yaml.

Lihat konten YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/acs-sample/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: NodePort

Buat Deployment dan Layanan untuk versi aplikasi baru.
```
kubectl apply -f nginx1.yaml
```

Konfigurasikan aturan Ingress untuk versi aplikasi baru.

ACK menyediakan jenis aturan Ingress berikut. Pilih jenis aturan Ingress berdasarkan kebutuhan Anda.

Ubah Ingress yang dibuat di Langkah 2 berdasarkan konten berikut:

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Hanya permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/service-match: | 
      new-nginx: header("foo", /^bar$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Hanya permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/service-match: | 
      new-nginx: header("foo", /^bar$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Uji akses ke Ingress.
1. Jalankan perintah berikut untuk mengakses aplikasi NGINX:
```
curl -H "Host: www.example.com"  http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
old
```
2. Jalankan perintah berikut untuk mengakses aplikasi NGINX menggunakan permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar:
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
new
```

Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa hanya permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke versi aplikasi baru.

Konfigurasikan aturan Ingress untuk meneruskan proporsi tertentu dari permintaan yang sesuai dengan aturan ke versi aplikasi baru. Dalam contoh berikut, hanya 50% dari permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke versi baru.

Ubah Ingress yang dibuat di Langkah 2 berdasarkan konten berikut:

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Hanya permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # Hanya 50% dari permintaan yang sesuai dengan aturan sebelumnya yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80
 servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    # Hanya permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/service-match: |
        new-nginx: header("foo", /^bar$/)
    # Hanya 50% dari permintaan yang sesuai dengan aturan sebelumnya yang diteruskan ke Layanan new-nginx.
    nginx.ingress.kubernetes.io/service-weight: |
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Uji akses ke Ingress.
1. Jalankan perintah berikut untuk mengakses aplikasi NGINX:
```
curl -H "Host: www.example.com"  http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
old
```
2. Jalankan perintah berikut untuk mengakses aplikasi NGINX menggunakan permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar:
```
curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP>
```
  Output yang Diharapkan:
```
new
```
Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa hanya 50% dari permintaan yang nilai parameter foo di header permintaan cocok dengan ekspresi reguler bar yang diteruskan ke versi aplikasi baru.

Konfigurasikan aturan Ingress untuk meneruskan proporsi tertentu dari permintaan ke versi aplikasi baru. Dalam contoh berikut, hanya 50% dari permintaan yang diteruskan ke versi aplikasi baru.

Ubah Ingress yang dibuat di Langkah 2 berdasarkan konten berikut:

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      # 50% dari permintaan diteruskan ke Layanan new-nginx.
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      # 50% dari permintaan diteruskan ke Layanan new-nginx.
      nginx.ingress.kubernetes.io/service-weight: |
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi lama.
      - path: /
        backend:
          service: 
            name: old-nginx
            port:
              number: 80
        pathType: ImplementationSpecific
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Jalankan perintah berikut untuk mengakses Ingress:
```
curl -H "Host: www.example.com" http://<EXTERNAL_IP>
```
Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa hanya 50% dari permintaan yang diteruskan ke versi aplikasi baru.

Langkah 3: Hapus versi aplikasi sebelumnya dan Layanan terkait

Jika versi aplikasi baru berjalan sesuai harapan selama periode waktu tertentu, Anda perlu membawa versi aplikasi sebelumnya offline dan hanya menyediakan versi aplikasi baru untuk akses.

Ubah Ingress yang dibuat di Langkah 2 berdasarkan konten berikut:

Kluster yang menjalankan versi Kubernetes lebih lama dari 1.19

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Kluster yang menjalankan Kubernetes 1.19 dan yang lebih baru

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gray-release
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Informasi tentang Layanan yang dibuat untuk versi aplikasi baru.
      - path: /
        backend:
          service: 
            name: new-nginx
            port:
              number: 80
        pathType: ImplementationSpecific

Jalankan perintah berikut untuk membuat Ingress:
```
kubectl apply -f ingress.yaml
```
Jalankan perintah berikut untuk menanyakan alamat IP dari Ingress untuk akses eksternal:
```
kubectl get ingress
```
Jalankan perintah berikut untuk mengakses Ingress:
```
curl -H "Host: www.example.com" http://<EXTERNAL_IP>
```
Output yang Diharapkan:
```
new
```
Anda dapat menjalankan perintah di atas lagi untuk menguji akses. Hasilnya menunjukkan bahwa semua permintaan diteruskan ke versi aplikasi baru.
Hapus Deployment dan Layanan yang dibuat untuk versi aplikasi sebelumnya.
1. Jalankan perintah berikut untuk menghapus Deployment yang dibuat untuk versi aplikasi sebelumnya:
```
kubectl delete deploy <Nama Deployment>
```
2. Jalankan perintah berikut untuk menghapus Layanan yang dibuat untuk versi aplikasi sebelumnya:
```
kubectl delete svc <Nama Layanan>
```