Routing traffic to multiple versions of a microservice with Istio

Question

Pulumi · Accepted Answer

Routing traffic between different versions of a microservice is a common pattern for canary releases, A/B testing, and other scenarios where you want to gradually introduce or test new features in a production environment. In Kubernetes, this is often achieved using Istio, which is a service mesh that provides the underlying mechanisms to safely control the flow of traffic at the platform layer.

To route traffic to multiple versions of a microservice using Istio in Pulumi, you would typically define the following resources:
1. A `Deployment` for each version of your microservice, where each Deployment's Pods are labeled with a version-specific label.
2. A `Service` that provides a stable endpoint for your microservices.
3. A `DestinationRule` that configures labels for routing to your microservice's different versions.
4. A `VirtualService` which specifies the routing rules to distribute traffic between versions.

Below is a TypeScript program that demonstrates how to use Pulumi to deploy multiple versions of a microservice and use Istio to manage traffic routing.
The code includes:
- Kubernetes deployments for two versions of a microservice.
- A Kubernetes service to expose the microservice.
- Istio DestinationRule and VirtualService to control the traffic routing.

```typescript
import * as k8s from "@pulumi/kubernetes";
import * as istio from "@pulumi/istio";

// Create a Kubernetes Namespace for Istio
const namespace = new k8s.core.v1.Namespace("microservice-ns");

// Istio must be installed in the cluster and the namespace must be enabled for Istio

// Deploy version 1 of the microservice
const microserviceV1 = new k8s.apps.v1.Deployment("microservice-v1", {
    metadata: {
        // Apply this label for Istio to automatically inject sidecar proxies
        labels: {"istio-injection": "enabled"},
        namespace: namespace.metadata.name,
    },
    spec: {
        replicas: 1,
        selector: {
            matchLabels: {
                app: "microservice",
                version: "v1",
            },
        },
        template: {
            metadata: {
                labels: {
                    app: "microservice",
                    version: "v1",
                },
            },
            spec: {
                containers: [
                    {
                        name: "microservice",
                        image: "my-repo/microservice:v1",
                    },
                ],
            },
        },
    },
});

// Deploy version 2 of the microservice
const microserviceV2 = new k8s.apps.v1.Deployment("microservice-v2", {
    metadata: {
        labels: {"istio-injection": "enabled"},
        namespace: namespace.metadata.name,
    },
    spec: {
        replicas: 1,
        selector: {
            matchLabels: {
                app: "microservice",
                version: "v2",
            },
        },
        template: {
            metadata: {
                labels: {
                    app: "microservice",
                    version: "v2",
                },
            },
            spec: {
                containers: [
                    {
                        name: "microservice",
                        image: "my-repo/microservice:v2",
                    },
                ],
            },
        },
    },
});

// Create a Kubernetes Service to expose the microservice deployments
const service = new k8s.core.v1.Service("microservice", {
    metadata: { namespace: namespace.metadata.name },
    spec: {
        selector: { app: "microservice" }, // Selects both v1 and v2 versions
        ports: [{ port: 80, targetPort: 8080 }],
    },
});

// Create an Istio DestinationRule to specify available versions/subsets
const destinationRule = new istio.networking.v1alpha3.DestinationRule("microservice-destination-rule", {
    metadata: { namespace: namespace.metadata.name },
    spec: {
        host: "microservice",
        subsets: [
            { name: "v1", labels: { version: "v1" } },
            { name: "v2", labels: { version: "v2" } },
        ],
    },
});

// Create an Istio VirtualService to distribute traffic between versions
const virtualService = new istio.networking.v1alpha3.VirtualService("microservice-virtual-service", {
    metadata: { namespace: namespace.metadata.name },
    spec: {
        hosts: ["microservice"],
        http: [{
            route: [
                { destination: { host: "microservice", subset: "v1" }, weight: 90 },
                { destination: { host: "microservice", subset: "v2" }, weight: 10 },
            ],
        }],
    },
});

// Export the namespace and service name
export const namespaceName = namespace.metadata.name;
export const serviceName = service.metadata.name;
```

In this program:

- We first create a `Namespace` for the microservices.
- We then create two `Deployment` resources, `microserviceV1` and `microserviceV2`. Each deployment is for a different version of the microservice. They are labeled appropriately with `version: "v1"` and `version: "v2"` respectively.
- The Kubernetes `Service` named `microservice` is created to provide a stable endpoint. The service selects pods labeled with `app: "microservice"`, which will select pods from both deployments.
- An Istio `DestinationRule` named `microservice-destination-rule` defines subsets for routing, specifying `v1` and `v2` as the versions.
- Lastly, an Istio `VirtualService` named `microservice-virtual-service` specifies the routing rules to distribute traffic between the two versions. Here, 90% of the traffic goes to `v1` and 10% goes to `v2`.

This is a simplified example that assumes Istio is already installed on your Kubernetes cluster, and the namespace is labeled for automatic Istio sidecar injection. Substitute `"my-repo/microservice:v1"` and `"my-repo/microservice:v2"` with your actual Docker image locations.

After deploying this Pulumi program, you will establish a traffic management strategy for your microservice that routes requests between different versions as specified. You can adjust the `weight` properties in the `VirtualService` spec to control the percentages of traffic that each version receives.

Remember to replace the image URLs with your actual microservice image URLs, and ensure Istio is correctly set up in your Kubernetes cluster for this to work.