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:
- An external request arrives at the entry point defined by
VirtualService
. - 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). - 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.