Traefik’s entrypoints are the gateways into your cluster, defining the network ports and protocols Traefik listens on for incoming traffic.
Let’s see Traefik in action, listening on ports 80 and 443.
# traefik.yaml
entryPoints:
web:
address: ":80"
websecure:
address: ":443"
When you define entryPoints in Traefik, you’re essentially telling it which doors to open. For every request that arrives at one of these specified addresses (host and port), Traefik will inspect it, consult its routing rules, and decide which service should handle it.
The address field is where you specify the port Traefik will bind to. It can be just a port number (e.g., :80), or a host and port (e.g., 192.168.1.100:80). If you omit the host, Traefik binds to all available network interfaces on that port.
Here’s how this plays out in a Kubernetes IngressRoute:
# my-app-ingressroute.yaml
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: my-app
spec:
entryPoints:
- web
- websecure
routes:
- match: Host(`my-app.example.com`)
kind: Rule
services:
- name: my-app-service
port: 80
In this IngressRoute, we’re telling Traefik that any traffic arriving on the web or websecure entrypoints that matches the Host header my-app.example.com should be forwarded to the my-app-service on port 80. The web entrypoint, as defined in traefik.yaml, is listening on port 80, and websecure is listening on port 443. This setup allows you to handle both plain HTTP and HTTPS traffic for your application.
The magic happens in how Traefik differentiates between HTTP and HTTPS. When a request comes in on :80, Traefik assumes it’s HTTP. If it comes in on :443, it assumes HTTPS and will attempt to perform TLS (Transport Layer Security) handshake using certificates it has been configured with (often via certificatesResolvers).
Consider what happens when you have multiple applications behind Traefik. Each application can have its own IngressRoute, and Traefik uses the Host header (and potentially other matchers like Path) to direct traffic to the correct backend service.
# another-app-ingressroute.yaml
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: another-app
spec:
entryPoints:
- web
routes:
- match: Host(`another-app.example.com`) && PathPrefix(`/api`)
kind: Rule
services:
- name: another-app-api-service
port: 8080
Here, another-app.example.com on port 80 (via the web entrypoint) will be routed to another-app-api-service on port 8080, but only if the request path starts with /api.
The address configuration is fundamental. If you need Traefik to listen on a specific IP address rather than all interfaces, you’d specify it like this:
# traefik.yaml
entryPoints:
internal:
address: "192.168.1.100:8080"
This binds Traefik to port 8080 only on the interface with the IP address 192.168.1.100. This is useful in environments where you have multiple network interfaces and want to control precisely which ones Traefik uses.
When you configure Traefik to listen on a port, it’s not just about making the port available; it’s about establishing a listening socket that actively waits for incoming TCP connections. Traefik then takes over the communication, terminating the connection from the client, inspecting the request, and establishing a new connection to your backend service. This intermediary role is key to its functionality as a reverse proxy and load balancer.
The underlying mechanism Traefik uses to manage these entrypoints involves creating goroutines (lightweight threads in Go) for each configured entrypoint. Each goroutine is responsible for accepting incoming connections on its assigned address. When a connection arrives, it’s passed to a request handler that determines the appropriate route based on the request’s properties. If no TLS is configured for an entrypoint, Traefik will simply pass the plaintext HTTP traffic through. Conversely, for TLS-enabled entrypoints, it intercepts the TLS handshake and uses the configured certificates to establish a secure connection before processing the HTTP request within that secure tunnel.
The most powerful aspect of entrypoints is their ability to be dynamically reconfigured. If you change the address in your Traefik configuration, Traefik can often reload this change without requiring a full restart, allowing for seamless updates to your network ingress. This dynamic nature means you can add or remove ports, or change IP bindings, on the fly.
When you deploy Traefik in Kubernetes, the IngressRoute CRD is the primary way you interact with entrypoints, but the underlying traefik.yaml or Helm chart values are where the actual port bindings are defined. The IngressRoute then references these defined entrypoints by name.
If you’ve set up TLS termination on an entrypoint, Traefik doesn’t just listen for traffic; it actively participates in the TLS handshake. It negotiates cipher suites, verifies client certificates (if configured), and decrypts the traffic before routing it. This offloads the burden of TLS management from your backend applications.
Understanding the relationship between the Traefik configuration (where entrypoints are defined with their addresses) and the IngressRoute (which selects which entrypoints to use for specific routes) is crucial for effective traffic management.
The next step after configuring your entrypoints is to set up TLS certificates to secure your HTTPS traffic.