Jelastic 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 Jelastic Kubernetes Service (Jelastic KS).
At the moment all issued Jelastic Kubernetes versions support Traefik v1, but 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 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 the router replaces the frontend and the service takes over the backend role, whilst each router refers to a service.
In order to increase flexibility tweaking the requests before they will be 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.
There are a number of middlewares available. Besides serving traditional ingresses for HTTP requests, separate middleware entities allow to modify the request parameters, the HTTP headers, some are responsible for redirects logic, other ones add authentication capabilities, etc.
Before the request will be sent to the service it can be modified with middleware(s) attached to a router.
The couple of examples for middlewares used in the requests routing:
- stripPrefix - allows to remove 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
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
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, Jelastic 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.
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 Jelastic KS repository: there is an 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 Jelastic Kubernetes v1.21.2+. You can check a full list in the official documentation related to transition from Traefik v1 to v2.