DDoS detection for
Kubernetes clusters

Back to Blog

DDoS and Kubernetes

Kubernetes abstracts away the underlying infrastructure, but DDoS attacks do not care about your abstraction layer. A volumetric flood hitting a node saturates the NIC and affects every pod on that node. Kubernetes health checks restart pods, autoscalers spin up replacements, but none of that matters if the underlying network is congested.

Traditional Kubernetes monitoring (Prometheus metrics, HPA triggers, pod-level alerts) tracks application performance, not network-layer attacks. By the time your pods report high latency or health check failures, the attack has been running for seconds or minutes.

ftagent monitors at the host network level, below Kubernetes. It detects volumetric DDoS attacks in under one second and can deploy mitigation rules on the node before the attack affects your pods.

DaemonSet Deployment (Recommended)

The recommended pattern is to deploy ftagent as a DaemonSet. This ensures one ftagent pod runs on every node in your cluster, providing per-node DDoS detection and mitigation.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ftagent
  namespace: flowtriq
spec:
  selector:
    matchLabels:
      app: ftagent
  template:
    metadata:
      labels:
        app: ftagent
    spec:
      hostNetwork: true
      containers:
      - name: ftagent
        image: flowtriq/ftagent:latest
        securityContext:
          capabilities:
            add: ["NET_ADMIN", "SYS_PTRACE"]
        volumeMounts:
        - name: config
          mountPath: /etc/ftagent
        - name: data
          mountPath: /var/lib/ftagent
      volumes:
      - name: config
        hostPath:
          path: /etc/ftagent
      - name: data
        hostPath:
          path: /var/lib/ftagent

Apply with kubectl apply -f ftagent-daemonset.yaml. Each node's ftagent pod monitors the host network and reports to its own Flowtriq node in the dashboard.

Create a dedicated namespace (flowtriq) for the ftagent DaemonSet to keep it separate from application workloads and make RBAC policies cleaner.

Sidecar Pattern

For specific high-value pods where you want dedicated monitoring, you can run ftagent as a sidecar container. The sidecar shares the pod's network namespace and monitors traffic to that specific pod.

This is less common than the DaemonSet approach because DDoS attacks are typically visible at the node level, not the pod level. However, the sidecar pattern is useful when you want per-service baselines or when you need PCAP captures scoped to a specific workload.

The sidecar approach requires the same security capabilities (NET_ADMIN, SYS_PTRACE) but does not need hostNetwork: true since it monitors the pod network namespace.

Ingress Controller Monitoring

If your Kubernetes cluster uses an ingress controller (NGINX, Traefik, HAProxy, etc.), the ingress nodes are typically the first point of contact for external traffic. These nodes are the most likely targets for DDoS attacks because all inbound traffic flows through them.

Deploy ftagent on your ingress nodes via the DaemonSet with a node selector:

spec:
  template:
    spec:
      nodeSelector:
        node-role.kubernetes.io/ingress: "true"

This gives you focused DDoS detection on the nodes that handle external traffic, while optionally running ftagent on worker nodes as well for internal traffic monitoring.

Cloud vs Bare-Metal Kubernetes

Managed Kubernetes (EKS, GKE, AKS)

On managed Kubernetes services, you do not have access to the underlying host outside of your node pools. The DaemonSet approach works because ftagent runs inside a pod with host network access. The key considerations:

• Cloud providers may have their own DDoS mitigation (AWS Shield, GCP Cloud Armor). ftagent complements these by providing per-node detection visibility that cloud-level mitigations do not expose.
• Some managed services restrict the use of hostNetwork: true or certain capabilities. Check your provider's pod security policies.
• Node autoscaling means new nodes appear and disappear. The DaemonSet handles this automatically because Kubernetes schedules a new ftagent pod on every new node.

Bare-metal Kubernetes

On bare-metal clusters, you have full control over the nodes. ftagent runs with no restrictions. You can also install ftagent directly on the host OS (outside of Kubernetes) if you prefer not to run it as a pod.

Bare-metal is where ftagent's auto-mitigation is most valuable. There is no cloud provider absorbing floods upstream, so local firewall rules and BGP FlowSpec/RTBH mitigation are your primary defenses. ftagent handles all of these automatically.

Getting Started

1. Sign up for Flowtriq (14-day free trial)
2. Pull the image: docker pull flowtriq/ftagent:latest (Docker Hub)
3. Apply the DaemonSet manifest
4. Configure each node's ftagent with your API key

For the full Docker and Kubernetes integration reference, see the Docker/Kubernetes integration page. The ftagent source is on GitHub.

Back to Blog

Related Articles