Using Traefik Ingress Controller with Istio Service Mesh

Tetrate sponsored this post.

Petr McAllister

Petr is an IT Professional with more than 20+ years of international experience and Master’s Degree in Computer Science. He is a technologist at Tetrate.

The Istio service mesh comes with its own ingress, but we see customers with requirements to use a non-Istio ingress all the time. Previously, we’ve covered integrating NGINX with Istio. Recently we’ve been working with customers that are using Traefik ingress. With some slight adjustments to the approach we suggested previously, we at Tetrate learned how to implement Traefik as the ingress gateway to your Istio Service Mesh. This article will show you how.

The flow of traffic is shown on the diagram below. As soon as requests arrive at the service mesh from the Traefik ingress, Istio has the ability to apply security, observability and traffic steering rules to the request:

Incoming traffic bypasses the Istio sidecar and arrives directly at Traefik, so the requests terminate at the Traefik ingress.

Traefik uses the IngressRoute config to rewrite the “Host” header to match the destination, and forwards the request to the targeted service, which is a several step process:

• Requests exiting Traefik Ingress are redirected to the Istio sidecar (by iptables).
• The sidecar receives the request, encrypts it (because our Istio PeerAuthentication policy dictates STRICT mTLS), and forwards the request to a pod of the target service.

Below is an end-to-end walkthrough of an example deployment, using Istio’s bookinfo demo application but fronting the entire deployment with a Traefik ingress. In short, to get this to work in your own environment:

• Deploy Traefik controller with an Istio sidecar, annotating the deployment so that inbound traffic bypasses the Istio Sidecar:

• Enable Istio sidecar injection in the application namespace and deploy any Istio-specific config you need.
• Create IngressRoute with a Traefik Middleware object that rewrites the hostname to one recognized by the mesh (i.e. a service in the cluster; this is discussed below in the details with an example).

Bookinfo with Traefik Ingress

The rest of this post covers deploying Istio’s Bookinfo sample application, using Traefik as the ingress proxy for the deployment.

Tetrate is an enterprise service mesh company. Our flagship product, TSB, enables customers to bridge their workloads across bare metal, VMs, K8s, & cloud at the application layer and provide a resilient, feature-rich service mesh fabric powered by Istio, Envoy, and Apache SkyWalking.

Learn More

The latest from Tetrate

Setting up the Environment

To follow this example yourself:

1. Deploy a Kuberentes cluster of at least version 1.17 (minimal Istio 1.8 supported version). We use a Google Kubernetes Engine cluster created by:

2. Download Istio 1.8.x.

3. Install it with enabled HTTP access logs.

Deploying Bookinfo Application

With Istio installed, we can start deploying our application. We’ll use Istio’s Bookinfo application for our demonstration. This sample application is part of Istio distribution (in the ./istio-1.8.1/samples/ folder)

4. Create bookinfo namespace.

5. Label it for the sidecar injection.

6. Deploy bookinfo application in that namespace.

Confirm that all the pods are started and have sidecars deployed with them.

Enable Istio mTLS for Service-to-Service Communications for the Application Namespace

Deploy Traefik Ingress

Now it’s time to deploy Traefik by following v2.3 documentation (The most recent version of Traefik as of this post is 2.3, but it’ll work with any version of Traefik if you adjust the IngressRoute and Middleware resources as required for your version).

7. Deploy Traefik constructs. Please note that there are some modifications to the documented deployment on the Traefik website (instead of default namespace in Traefik documentation, bookinfo namespace will be specified). The file can be accessed here and applied as follows:

8. Create a service for incoming requests. The service will receive the external IP address. (There are a few changes to the example from the Traefik website):

1. The Namespace needs to be specified.
2. Only two ports are published: 80 for the Bookinfo application and 8080 for Traefik management.
3. The service needs to point to Traefik with a label (traefik-ingress-lb) that is used here.
4. “Type: Loadbalancer” is added to tell GCP to assign an external IP to the service.

9. Confirm that the service is created as expected:

10. As the Traefik website describes in detail, the Kubernetes Deployment with ServiceAccount needs to be applied. Besides the name and namespace, the following changes are introduced to the website example:

1. Secure endpoint removed for simplicity.
2. Accesslog – added “=true” as it didn’t work without the value.
3. Log.level set to DEBUG will help us to see what’s happening.
4. Added traffic.sidecar.istio.io annotations (For more details please refer to the previously mentioned Tetrate NGINX article).

11. Confirm the deployment of Traefik in the Bookinfo Namespace:

12. Get the service IP and record BOOKINFO_IP variable value.

13. Test response from the Ingress port 80 and see that it doesn’t have route to the application.

Make sure it returns “404 Not Found” — not-200 response is expected as the ingress rules are not implemented yet.

Configure Traefik Ingress Rules

1. Traefik’s Middleware header rewrite functionality will allow Istio Service mesh to function correctly. In this example, the host needs to be defined as “productpage.bookinfo.svc”. The header can be defined according to the Traefik documentation:

2. The final step is to specify the routing logic for the ingress requests, since the focus of this article is Service Mesh integration and Kubernetes. The definition is very simple and forwards all incoming requests arriving on port 80 to the fronting bookinfo application service called ProductPage (serving traffic on port 9080). It also uses the middleware object created in the previous step:

Validate Your Deployment Functionality

1. Retest the application response:

We’ll receive “200 OK” response. It can also be tested via the browser using http://<BOOKINFO_IP value from above>/productpage:

2. If /productpage is added to the url http://<BOOKINFO_IP value>/productpage, it will return the application response:

3. By querying the Traefik pod logs in the bookinfo namespace of the istio-proxy container, the outgoing request to the application can be seen in istio-proxy logs. There are no incoming requests, since they reach the Traefik Ingress directly.

Please note that the logs take a few seconds to be displayed after the request is processed. Logs are only available if the Istio install was done with the “meshConfig.accessLogFile=/dev/stdout” flag:

Summary

This article demonstrates how Traefik Ingress can be implemented as an entry point to an Istio service mesh. The basic approach applied here should be applicable even if your environment is different from the one used in our example. The Traefik / Service Mesh integration can be successfully implemented in different clouds with brand-new or existing (a.k.a. brownfield) deployments of Traefik, when the service mesh is introduced during Day Two implementations stage. In the end, you’re getting the best of two worlds: Istio Service Mesh integrating with the Ingress controller of your choice!

Feature image via Pixabay.

Tetrate is an enterprise service mesh company. Our flagship product, TSB, enables customers to bridge their workloads across bare metal, VMs, K8s, & cloud at the application layer and provide a resilient, feature-rich service mesh fabric powered by Istio, Envoy, and Apache SkyWalking.

Learn More

The latest from Tetrate

Petr is an IT Professional with more than 20+ years of international experience and Master’s Degree in Computer Science. He is a technologist at Tetrate.

Read more from Petr McAllister