Why a DaemonSet
A Kubernetes DaemonSet runs one pod per node automatically. When a new node joins the cluster, the DaemonSet scheduler places an ftagent pod on it. When a node is drained or removed, the pod is cleaned up. You never have to manually install or uninstall the agent.
This is the correct deployment pattern for DDoS detection because attacks arrive at the node level. An attack targeting a NodePort service, a LoadBalancer, or even the node's IP directly is only visible from that specific node's kernel counters. A single centralized detection pod cannot see what is happening at each node.
Full DaemonSet Manifest
Save this as ftagent-daemonset.yaml and apply with kubectl apply -f ftagent-daemonset.yaml:
apiVersion: v1
kind: Namespace
metadata:
name: ftagent
---
apiVersion: v1
kind: ConfigMap
metadata:
name: ftagent-config
namespace: ftagent
data:
FTAGENT_AUTO_MITIGATE: "true"
FTAGENT_FIREWALL_CHAIN: "KUBE-FTAGENT"
FTAGENT_PCAP_ENABLED: "true"
FTAGENT_METRICS_PORT: "9101"
---
apiVersion: v1
kind: Secret
metadata:
name: ftagent-secret
namespace: ftagent
type: Opaque
stringData:
deploy-token: "your-deploy-token-here"
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ftagent
namespace: ftagent
labels:
app: ftagent
spec:
selector:
matchLabels:
app: ftagent
template:
metadata:
labels:
app: ftagent
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9101"
spec:
hostNetwork: true
hostPID: true
tolerations:
- effect: NoSchedule
operator: Exists
containers:
- name: ftagent
image: flowtriq/ftagent:latest
envFrom:
- configMapRef:
name: ftagent-config
env:
- name: FTAGENT_DEPLOY_TOKEN
valueFrom:
secretKeyRef:
name: ftagent-secret
key: deploy-token
- name: FTAGENT_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
volumeMounts:
- name: proc
mountPath: /host/proc
readOnly: true
- name: sys
mountPath: /host/sys
readOnly: true
- name: ftagent-data
mountPath: /var/lib/ftagent
securityContext:
capabilities:
add:
- NET_ADMIN
- NET_RAW
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 200m
memory: 128Mi
livenessProbe:
exec:
command: ["ftagent", "--health"]
initialDelaySeconds: 30
periodSeconds: 30
readinessProbe:
httpGet:
path: /health
port: 9101
initialDelaySeconds: 10
periodSeconds: 10
volumes:
- name: proc
hostPath:
path: /proc
- name: sys
hostPath:
path: /sys
- name: ftagent-data
hostPath:
path: /var/lib/ftagent
type: DirectoryOrCreate
Key Configuration Decisions
hostNetwork: true
Required. The agent must see traffic on the node's physical interfaces, not the pod network. Without host networking, it only sees pod-to-pod traffic on the CNI bridge.
hostPID: true
Allows the agent to read kernel counters from the host's /proc filesystem. Without this, /proc inside the container shows the container's own metrics, not the node's.
Tolerations
The NoSchedule toleration ensures ftagent runs on all nodes including control plane nodes and nodes with taints. Remove this if you only want detection on worker nodes.
Node name injection
The spec.nodeName field ref injects the Kubernetes node name as the Flowtriq node name. Each node appears in the Flowtriq dashboard with its Kubernetes name, making it easy to correlate alerts with specific cluster nodes.
Prometheus Integration
The DaemonSet includes Prometheus annotations for automatic scraping. If you use the Prometheus operator or kube-prometheus-stack, create a ServiceMonitor:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: ftagent
namespace: ftagent
spec:
selector:
matchLabels:
app: ftagent
endpoints:
- port: metrics
interval: 15s
Metrics available include per-node PPS, bandwidth, protocol breakdown, incident count, and detection latency. See the Prometheus metrics documentation for the full catalog.
Mitigation in Kubernetes
On-node mitigation works differently in Kubernetes than on bare metal. The agent creates its own iptables chain (KUBE-FTAGENT by default) and inserts rules there. It does not modify kube-proxy chains, Calico policies, or Cilium eBPF rules.
For clusters using Calico as the CNI, you can also configure Flowtriq to push GlobalNetworkPolicy resources via the Kubernetes API instead of raw iptables rules. This integrates with Calico's existing policy engine.
For severe attacks, configure upstream escalation to BGP FlowSpec or cloud scrubbing. This is especially important for clusters behind cloud load balancers where on-node rules cannot prevent link saturation at the cloud provider level.
Rolling Updates
The DaemonSet uses the default RollingUpdate strategy. When you update the ftagent image tag, pods are replaced one node at a time. During the update, the old pod on a node stops and the new pod starts, creating a brief gap in monitoring (typically under 30 seconds per node).
The agent persists baseline data to /var/lib/ftagent on the host. The new pod picks up the existing baseline immediately, so there is no 5-minute learning period after an update.
FAQ
Does this work with managed Kubernetes (EKS, GKE, AKS)?
Yes, with caveats. Managed K8s services handle some DDoS protection at the load balancer level (AWS Shield, GCP Cloud Armor, Azure DDoS Protection). ftagent adds per-node visibility that those services do not provide: which node is targeted, what the attack vector is, PCAP capture, and on-node response.
What about resource consumption?
The agent uses 50-200m CPU and 64-128Mi memory per node. On a 20-node cluster, total overhead is about 1-4 CPU cores and 1.3-2.5 GB memory across all nodes.
Can I exclude specific nodes?
Yes. Use node selectors or anti-affinity rules to exclude nodes. For example, add a nodeSelector to only deploy on nodes labeled ftagent=enabled.
Protect your cluster. Apply the DaemonSet manifest and have DDoS detection running on every node in minutes. Image available on Docker Hub. Start your free 14-day trial.