Rate-limiting applications with Traefik on Civo

Rate-limiting is a method of reducing the rate at which requests are made to a server or resource on a network. It plays a crucial role in preventing abuse and controlling traffic, whether that traffic is a scraper, a runaway retry loop, or a brute-force script.

One of the key advantages of enforcing rate limits at the ingress layer is that you don't need to introduce any additional logic or modifications to your application code. This decouples rate-limiting logic from your application, simplifies the deployment process, and enables you to manage rate limits centrally, regardless of the underlying application architecture.

The original version of this tutorial used the ingress-nginx controller. The Kubernetes project has since put ingress-nginx on the path to retirement, with end of life in March 2026 and no further releases, bugfixes, or security patches after that. On Civo you don't need it anyway: Civo k3s ships Traefik as the default ingress controller, so it is already running on every cluster you create. In this guide we'll use Traefik's native middleware to rate-limit a sample application.

Benefits of rate-limiting

Some of the benefits of rate-limiting include:

• Abuse prevention: limiting the rate of requests helps deter brute-force attacks.
• Denial-of-service (DoS) prevention: rate limits mitigate attacks that target your application's availability.
• Cost optimization: when you are charged per API call, capping request rates keeps usage under control.

Prerequisites

To follow along you'll need:

• kubectl installed
• A Civo account
• The Civo CLI installed and configured
• Basic familiarity with Kubernetes

Creating a cluster

We only need Traefik, and Civo k3s installs it by default, so the create command is short. There's no need to add a second controller:

1civo k3s create --create-firewall --nodes 2 -m --save --switch --wait \
2  traefik-rate-test -r=Traefik
3kubectl get nodes

Once the nodes report Ready, confirm Traefik's load balancer is up:

1kubectl get svc -n kube-system traefik

Deploying a sample application

We'll deploy traefik/whoami, a tiny service that echoes request details back to the caller. That makes the rate-limit behavior easy to observe. Apply the Deployment and Service:

1kubectl apply -f - <<'EOF'
2apiVersion: apps/v1
3kind: Deployment
4metadata:
5  name: whoami
6  namespace: default
7spec:
8  replicas: 1
9  selector:
10    matchLabels:
11      app: whoami
12  template:
13    metadata:
14      labels:
15        app: whoami
16    spec:
17      containers:
18        - name: whoami
19          image: traefik/whoami
20          ports:
21            - containerPort: 80
22---
23apiVersion: v1
24kind: Service
25metadata:
26  name: whoami
27  namespace: default
28spec:
29  selector:
30    app: whoami
31  ports:
32    - protocol: TCP
33      port: 80
34      targetPort: 80
35EOF

Grab the public hostname Traefik is serving on. We'll use it for every test:

1export HOST=$(kubectl get svc -n kube-system traefik \
2  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
3echo "Using HOST=$HOST"

Implementing rate-limiting (requests per second)

Instead of an ingress annotation, we'll define a Traefik RateLimit middleware. Traefik uses a token-bucket algorithm, so three fields control the behavior:

• average: the steady rate of requests allowed, measured over period.
• period: the window average is measured against. With average: 10 and period: 1s we allow an average of 10 requests per second.
• burst: the bucket size, the number of requests allowed to spike through at once before the average kicks in.

Apply the middleware:

1kubectl apply -f - <<'EOF'
2apiVersion: traefik.io/v1alpha1
3kind: Middleware
4metadata:
5  name: ratelimit-rps
6  namespace: default
7spec:
8  rateLimit:
9    average: 10
10    period: 1s
11    burst: 5
12EOF

Rate-limiting by connections (in-flight requests)

Rate per second is one dimension. Another is how many requests a single client can have in flight at the same time. For that we use a Traefik inFlightReq middleware. The amount field caps simultaneous in-flight requests.

By default Traefik groups in-flight requests by request host, which would apply one shared limit to everyone. To make the limit per client IP, we add a sourceCriterion.ipStrategy:

1kubectl apply -f - <<'EOF'
2apiVersion: traefik.io/v1alpha1
3kind: Middleware
4metadata:
5  name: inflight-conns
6  namespace: default
7spec:
8  inFlightReq:
9    amount: 5
10    sourceCriterion:
11      ipStrategy:
12        depth: 1
13EOF

Confirm both middleware exist:

1kubectl get middleware -n default

Attaching the middleware

Defining a middleware doesn't do anything on its own. It has to be wired onto a route. There are two ways to do that. We'll show both and recommend the first for readers coming from a plain Ingress.

Option A (recommended): plain Ingress plus annotation

This keeps a standard, portable Ingress object and references the middleware through an annotation. The reference must be namespace-qualified in the form <namespace>-<middleware-name>@kubernetescrd: ratelimit-rps@kubernetescrd on its own will silently fail to attach, it has to be default-ratelimit-rps@kubernetescrd:

1kubectl apply -f - <<EOF
2apiVersion: networking.k8s.io/v1
3kind: Ingress
4metadata:
5  name: whoami
6  namespace: default
7  annotations:
8    traefik.ingress.kubernetes.io/router.middlewares: default-ratelimit-rps@kubernetescrd
9spec:
10  ingressClassName: traefik
11  rules:
12    - host: "${HOST}"
13      http:
14        paths:
15          - path: /
16            pathType: Prefix
17            backend:
18              service:
19                name: whoami
20                port:
21                  number: 80
22EOF

To chain both middleware, comma-separate them in the annotation:

1    traefik.ingress.kubernetes.io/router.middlewares: default-ratelimit-rps@kubernetescrd,default-inflight-conns@kubernetescrd

Option B: Traefik IngressRoute CR

IngressRoute is Traefik's native routing object. It references middleware by name and namespace directly, with no @kubernetescrd suffix:

1kubectl apply -f - <<EOF
2apiVersion: traefik.io/v1alpha1
3kind: IngressRoute
4metadata:
5  name: whoami
6  namespace: default
7spec:
8  entryPoints:
9    - web
10  routes:
11    - match: Host(\`${HOST}\`)
12      kind: Rule
13      services:
14        - name: whoami
15          port: 80
16      middlewares:
17        - name: ratelimit-rps
18        - name: inflight-conns
19EOF

Use Option A if you want to keep portable, standard Ingress objects and only annotate them. Use Option B if you are already all-in on Traefik CRs and want the matcher expressiveness of IngressRoute.

Load testing with fortio (expecting 429s)

To confirm the limit works, install fortio locally, then drive more traffic than the limit allows. With average: 10 per second, we'll push 15 qps:

1fortio load --qps 15 -t 30s "http://${HOST}/"

Over the limit, fortio logs each rejected request as a 429 (not a 503), with lines like:

1{"ts":1750000000.123456,"level":"warn","file":"http_client.go","line":1079,"msg":"Non ok http code","code":"429","status":"HTTP/1.1 429","thread":"2","run":"0"}

The end-of-run summary shows the split between accepted and rejected requests. This capture is from a live 50-request burst against the RateLimit middleware:

1Code 200 : 16 (32.0 %)
2Code 429 : 34 (68.0 %)

A 50-request burst against the RateLimit middleware: a portion served 200, the rest rejected with 429.

A control test confirms the middleware is what's enforcing the limit: remove the annotation from the Ingress, re-run the burst, and every request returns 200 again.

To exercise the connection limit instead, push concurrent connections above amount: 5:

1fortio load --qps 30 -t 30s -c 8 "http://${HOST}/"

Connections beyond 5 in flight at once are rejected with 429.

Cleaning up

When you're done, remove the cluster so you stop paying for it:

1civo k3s remove traefik-rate-test

Summary

Rate-limiting can be extremely useful in mitigating DoS attacks and preventing abuse. In this guide we used the Traefik ingress controller that ships with Civo k3s, defined a RateLimit middleware for requests per second and an inFlightReq middleware for concurrent connections, attached them with either a plain annotated Ingress or a native IngressRoute, and confirmed with fortio that traffic over the limit is rejected with 429 Too Many Requests.

Before implementing rate-limiting, it is crucial to assess your environment and requirements, considering expected traffic patterns, application sensitivity, and potential security risks. A limit that is too aggressive will reject legitimate users. From here you can tune average, burst, and amount to match your service's capacity, chain additional middleware (retries, circuit breakers, headers), and explore the full RateLimit and inFlightReq references.