Using kubernetes linkerd.io with gateway.envoyproxy.io

Question

Pulumi · Accepted Answer

To use Linkerd with Envoy as the gateway in Kubernetes, you would ideally configure Linkerd to handle service mesh responsibilities, while Envoy would serve as the ingress controller, directing external traffic into your cluster.

Below is a conceptual overview, followed by a simple example of how you might configure an Ingress resource in Kubernetes to work with Linkerd and Envoy.

### Conceptual Overview

1. **Linkerd Installation**: Linkerd is typically installed using the Linkerd CLI by executing `linkerd install | kubectl apply -f -`. This installs Linkerd's control plane and the data plane proxy in each service's pod through the process of pod injection.

2. **Envoy Installation**: For the ingress controller, you can use the Envoy-based Ingress Controller like Ambassador or Contour. For this example, I'll assume that you've chosen an Envoy proxy that is compatible with Kubernetes Ingress resources and is installed in your cluster.

3. **Kubernetes Ingress Resource**: This resource defines how external traffic should be routed to the services within the cluster. Using annotations, you can instruct the Ingress controller to route traffic through Linkerd (if your Envoy-based Ingress supports this).

4. **mTLS and Traffic Management**: Linkerd will automatically add mutual TLS (mTLS) and provide other features like service discovery, traffic shifting, and detailed metrics.

5. **Monitoring and Visualization**: With Linkerd's dashboard or Grafana integration, you can monitor the performance and health of your services within the service mesh.

### Example Program in TypeScript

Below is a Pulumi program in TypeScript, demonstrating how one might define a Kubernetes Ingress resource that uses Envoy as the Ingress controller and integrates with Linkerd. For demonstration simplicity, we will focus on the Ingress manifest and assume that both Linkerd and Envoy are already installed and configured in the cluster.

Remember that specifics can vary based on the Envoy-based ingress controller you use, and this example assumes the controller has built-in support for Linkerd or is configured appropriately to work with Linkerd's service mesh.

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

// This is a simple Ingress resource that can be modified to meet the specifics of your Envoy configuration
// and the needs of your application services.

const name = 'my-ingress';

const myIngress = new k8s.networking.v1.Ingress(name, {
    metadata: {
        name: name,
        annotations: {
            // Replace with the appropriate annotation for your Envoy-based ingress controller
            // For example, if using Ambassador, it may look like this:
            // 'getambassador.io/config': '...'
            // This annotation typically would hint at enabling Linkerd injection or some form of cooperation
            // between the Ingress and Linkerd.
        },
    },
    spec: {
        ingressClassName: 'envoy', // This field should match your Envoy ingress class name
        rules: [
            {
                host: 'example.com', // Your domain here
                http: {
                    paths: [
                        {
                            path: '/',
                            pathType: 'ImplementationSpecific', // Use the appropriate pathType for your scenario
                            backend: {
                                service: {
                                    // Ensure that this service name & port match the service you want to expose
                                    name: 'my-service',
                                    port: {
                                        number: 80,
                                    },
                                },
                            },
                        },
                        // Additional routing paths can be added here
                    ],
                },
            },
        ],
    },
});

export const ingressName = myIngress.metadata.name;
```

This program defines a simple Ingress resource that would work with Envoy as the ingress controller. The `annotations` field in the Ingress' metadata would generally be used to configure aspects specific to your ingress setup or how it interacts with Linkerd. The actual annotations and their values would be determined based on the ingress controller you are using and should be consulted in the respective documentation:

- [Linkerd Documentation](https://www.pulumi.com/registry/packages/kubernetes/api-docs/linkerd/linkerd/)
- [Envoy Documentation](https://www.envoyproxy.io/docs/envoy/latest/)

The `ingressClassName` should correspond to the class of the Envoy ingress controller deployed on your cluster. This class allows Kubernetes to use the correct Ingress Controller when you have multiple running in your cluster.

In our `rules`, we specify that any traffic intended for "`example.com`" should be routed to the "`my-service`" Kubernetes service on port 80.

**Note**: This code assumes that you have Pulumi and Kubernetes setup done. You'd run the `pulumi up` command in the directory containing this script to apply it to your cluster.

Remember, when working with Pulumi and Kubernetes, the precise annotations, labels, and configurations can depend heavily on your specific environment and the tools you are using in conjunction. Always review documentation for each tool and consult with their communities or support channels if you encounter issues.