Istio implements canary deployment of Kubernetes cluster applications

Istio implements canary deployment of Kubernetes cluster applications

Istio is an open source service mesh platform that provides a way to connect, protect, control, and observe microservices. As a service mesh, Istio provides network proxies between the different services of an application. These proxies are collectively called “sidecars.” These sidecars can control all communication to and from the service without requiring any changes to the service’s code. Istio mainly uses Envoy Proxy to intercept network communications and provides a series of network functions, such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC support, circuit breakers, health checks, and percentage-based traffic Shunting and delayed injection are used for fault recovery, etc.

Canary Deployment

Canary Release is a software release strategy that is used to reduce the risk of problems introduced by new versions and implement rolling updates of software by gradually replacing old versions. In a canary deployment, a new version (the canary version) is first deployed to a small subset of users or servers in the production environment. This allows the team to observe how new releases perform under real production conditions without impacting all users.

If the new version works well and no major issues are found, it will be gradually pushed to more users, eventually replacing the old version. If something goes wrong during the canary phase, the new version can be rolled back quickly, minimizing the impact on users.

1. Istio installation

Istio installation is relatively simple, which is why Istio is so popular in the Kubernetes community. If it is a pure installation test, it is recommended that you follow the “Istio Tutorial (1) – Install Istio” method to install a demo version of the Istio service.
Istio official website installation method
Istio Tutorial (1)-Installing Istio

2. Default namespace sets “sidecars” proxy

kubectl label namespace default istio-injection=enabled

istio-injection=enabled: Sets the tag istio-injection to the value enabled. Istio’s change admissions webhook uses this tag to decide whether to inject Envoy sidecar proxies into Pods created in this namespace.

3. Create Deployment

Create two Deployments respectively, using the mirrors “harbor.example.com/library/version-test:v1” and “harbor.example.com/library/version-test:v2” (mirror download address) respectively, where the version. The effects obtained by html page access are different. Please note the labels created for each Deployment.

apiVersion: apps/v1
Kind: Deployment
metadata:
  name: appv1
  labels:
    app: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: v1
      apply:canary
  template:
    metadata:
      labels:
        app: v1
        apply:canary
    spec:
      containers:
      - name: nginx
        image: harbor.example.com/library/version-test:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: apps/v1
Kind: Deployment
metadata:
  name: appv2
  labels:
    app: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: v2
      apply:canary
  template:
    metadata:
      labels:
        app: v2
        apply:canary
    spec:
      containers:
      - name: nginx
        image: harbor.example.com/library/version-test:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

4. Create Service

Proxy traffic from containers whose labels contain “canary”.

apiVersion: v1
Kind: Service
metadata:
  name:canary
  labels:
    apply: canary
spec:
  selector:
    apply: canary
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

5. Create Gateway resources

In Istio, a Gateway is a configuration resource that defines the specification as an entry point at the edge of a service mesh. These specifications allow you to control traffic from external networks to services in your mesh. In short, Gateway resources are key components for managing and controlling traffic in the grid. Next we will create an “ingressgateway” resource object.

apiVersion: networking.istio.io/v1beta1
Kind: Gateway
metadata:
 name: canary-gateway
spec:
 selector:
   istio: ingressgateway
 servers:
 - port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   - "*"

5. Create DestinationRule and VirtualService resources

In the Istio service mesh, DestinationRule and VirtualService are key custom resources that define routing and service-level characteristics. These two resources work together to allow you to control the behavior of traffic between services.

VirtualService

VirtualService is used to define routing rules for services. It tells the mesh how traffic should be forwarded from one service to another based on specified matching criteria. These routing rules can match traffic based on attributes of the request (such as HTTP headers, URI, etc.) and redirect or distribute it to one or more services.

For example, you can use VirtualService to implement the following functionality:

  • Route requests to different versions of services (for canary deployments or blue-green deployments).
  • Rewrite the request path or redirect the request to another address.
  • Configure retry, timeout and circuit breaker policies for different request paths.
  • Apply access control policies to specific service calls.
DestinationRule

DestinationRule defines which policies can be applied to traffic directed to a specific destination. These rules can include load balancing configuration, TLS settings, circuit breaker parameters, and subset declarations.

Subsetting is a key concept of DestinationRule, which allows you to define policies for different versions of the same destination service. Doing so allows the VirtualService‘s routing rules to direct traffic to these different subsets.

Here are some scenarios for using DestinationRule:

  • Configure mTLS communication between services.
  • Define the load balancing strategy of the service, such as round-robin or minimum number of connections.
  • Set circuit breaker policies to prevent faults from spreading between services.
  • Routing to different versions of a service via subsetting.
How to work together

VirtualService and DestinationRule are often used together to implement complex routing logic. VirtualService handles the entry point and routing direction of traffic, while DestinationRule defines the specific behavior of traffic once it reaches its destination.

This is a typical workflow:

  1. An external request arrives at the entry point defined by VirtualService.
  2. Based on the routing rules of VirtualService, traffic is distributed to the appropriate service or version of a service (perhaps a specific subset of a service).
  3. Once a destination is selected, the policies defined in the DestinationRule (such as load balancing, TLS, etc.) are applied to the traffic.

Through this separation, VirtualService provides powerful routing capabilities, while DestinationRule provides target service level control, making Istio’s traffic management both flexible and powerful.

Create a resource, define the traffic in VirtualService to come from “canary-gateway”, and define two “destination” with different traffic weights. “subset: v1” and “subset: v2” are defined in DestinationRule, which respectively correspond to two different Deployments through the label selector.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
 name:canary
spec:
 hosts:
 - "*"
 gateways:
 -canary-gateway
 http:
 - route:
   -destination:
       host: canary.default.svc.cluster.local
       subset: v1
     weight: 90
   -destination:
       host: canary.default.svc.cluster.local
       subset: v2
     weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
 name:canary
spec:
 host: canary.default.svc.cluster.local
 subsets:
 - name: v1
   labels:
     app: v1
 - name: v2
   labels:
     app: v2

6. Inspection

Check the port address of “istio-ingressgateway”.

kubectl get svc -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-egressgateway ClusterIP 10.233.9.96 <none> 80/TCP,443/TCP 5d
istio-ingressgateway LoadBalancer 10.233.187.217 <pending> 15021:32374/TCP,80:30131/TCP,443:31064/TCP,31400:31267/TCP,15443:31428/TCP 5d
istiod ClusterIP 10.233.73.11 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 5d

Execute the following command on any machine in the cluster

for i in `seq 1 100`; do curl <IP address of any machine in the cluster>:30131/version.html;done > 1.txt

By looking at 1.txt, the frequency of v1 tags and v2 tags is 9:1.