Introduction to Traefik v2 Ingress Controller in Virtuozzo Kubernetes Service

Virtuozzo Kubernetes cluster can be installed with NGINX, Traefik, or HAProxy ingress controllers. In this post, we will take a closer look at Traefik and its evolution in Virtuozzo Kubernetes Service (Virtuozzo KS).

At the moment, all issued Virtuozzo Kubernetes versions support Traefik v1. However, commencing from K8s version 1.21.2, Traefik v2 will be used instead.

A number of internal components of Traefik were conceptually redesigned moving from v1 to v2. Below, we will cover some of them that we consider more important.

No Frontends and Backends

The basic concepts, such as frontend and backend, have been replaced with a combination of routers, services, and middleware.
With Traefik v1, it is considered that the router replaces the frontend and the service takes over the backend role, whilst each router refers to a service.

To increase flexibility tweaking the requests before they are sent to the services, the middleware pieces were attached to the routers in Traefik v2. These middleware can be chained together to fit any scenario. Also, any router can then link to the desired middleware instance.

Middleware

There are a number of middlewares available. Besides serving traditional ingresses for HTTP requests, separate middleware entities allow for modifying the request parameters, the HTTP headers, some are responsible for redirects logic, others add authentication capabilities, etc.

Before the request is sent to the service, it can be modified with middleware(s) attached to a router.

A couple of examples for middlewares used in the requests routing:

• stripPrefix - allows removal of a prefix from the path. This middleware is supposed to be used if your backend serves the path "/" , but should be exposed externally on a specific prefix, e.g., "/foo". This middleware is a replacement of frontend.rule.type annotation in Traefik v1.

http:
  middlewares:
    test-stripprefix:
      stripPrefix:
        prefixes:
          - "/foo"

• basicAuth middleware for implementing basic authorization. For example:

http:
  middlewares:
    test-auth:
      basicAuth:
        users:
          - "user1:$apr1$Kveg6cv0$yJn5mwyfBy7luzZ9Fi1AH0"
          - "user2:$apr1$w70ASLDx$1UJmrFL/lVoltjmAz4UDH/"

This middleware is an alternative to specifying credentials via Kubernetes Secrets and restricts access to the services:

And it is a replacement for the Traefik v1 annotation

traefik.ingress.kubernetes.io/auth-type: "basic".

Several Middlewares at a Time

Middleware employment (as well as other routing components) is optional. Routing logic can use either several middlewares or none at all. For example, in the Ingress below, one middleware handles authentication purposes, and another one strips a source path prefix.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: monitoring-prometheus-alertmanager
  namespace: kubernetes-monitoring
  annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/router.middlewares: 
       kubernetes-monitoring-alert-auth@kubernetescrd, 
       kubernetes-monitoring-alert-prefix@kubernetescrd
spec:
  rules:
  - http:
      paths:
      - path: /prometheus-alert
        pathType: Prefix
           backend:
           service:
            name: monitoring-prometheus-alertmanager
            port:
              number: 80

---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: alert-auth
  namespace: kubernetes-monitoring
spec:
  basicAuth:
    secret: monitoring-prometheus

---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: alert-prefix
  namespace: kubernetes-monitoring
spec:
  stripPrefix:
    prefixes:
      - /prometheus-alert

Providers

Traefik v2 introduces the concept of a provider, which is an infrastructure component that provides information regarding routing to the Traefik. Once the Traefik detects any changes, it automatically updates the routes. The Kubernetes Ingress Traefik provider offers the traditional Kubernetes ingress controller functionality.

Aside from the standard Ingress, Virtuozzo KS now supports an IngressRoute which is the Custom Resource Definition (CRD) implementation of a Traefik HTTP router. This implementation improved accessibility to the K8s clusters without writing annotations. You can get familiar with an example of how to use IngressRoute in our K8s repository.

Services

Among other features, Traefik v2 supports specific Services that are responsible for configuring how to reach the actual Kubernetes services that will ultimately handle incoming requests.

http:
  services:
    my-service:
      loadBalancer:
        servers:
        - url: "http://<private-ip-server-1>:<private-port-server-1>/"
        - url: "http://<private-ip-server-2>:<private-port-server-2>/"

Also, Traefik offers a set of internal services. You can see an example in the config file from the Virtuozzo KS repository: there is access to a built-in Traefik v2 dashboard service via IngressRoute provided.

These are only a few main changes in the new Traefik v2, which is implemented within our Kubernetes v1.21.2+. You can check a full list in the official documentation related to the transition from Traefik v1 to v2.

Don’t forget to keep an eye on new releases.

Want to see how it works for you?
Give it a try with a free trial from a local Virtuozzo Application Platform provider — and see how easy cloud can be.

Want to offer powerful cloud services under your brand?
Get in touch with Virtuozzo to learn how to install the Application Platform on your own infrastructure.