The rate is the part that transfers. Adyen reports a maximum of 200,000 entries per second through the connection tracking table [4], which prices one entry at roughly five microseconds [16]. Seven million entries at that rate is 35 seconds, and sixteen million is up to 80 [4][5]. Entry count grew 2.29x between those two measurements and time grew 2.29x [17], so across the range they measured there is no amortisation, no early exit, no index. It is a walk.
That walk sits in front of the API the CNI plugin calls. On affected nodes, the durations of PUT /v1/endpoint and DELETE /v1/endpoint climbed linearly from 4:20pm and never recovered, meaning endpoint creation and deletion never finished [6]. The plugin gave up with a client timeout [2], and once one pod failed that way, every subsequent pod on that node failed too [3]. The connections being enumerated belong to pods that exited hours earlier [15].
What the published excerpt does not show is the serialization point: which lock, or which single-threaded loop, puts a garbage collection pass ahead of an endpoint create. Adyen says the agent logs had nothing even at debug level [7], and that the finding came from tracing syscalls, reading codebases and analysing eBPF internals [8], against Kubernetes 1.31.7 and Cilium 1.16.5 [9]. Read the causal chain as the authors' reading of their own traces.
The tuning list is the uncomfortable part. Before hitting this, Adyen had already raised DNS proxy timeouts, expanded the connection tracking table capacity, raised API rate limits and streamlined security labels [13]. Expanding the table is the standard answer to eviction under connection churn. On a linear scan it is also an increase in the worst-case stall, because maximum scan time is entries divided by 200,000 [19]. The knob that stops connections being dropped raises the ceiling on how long a node can refuse to start pods.
For the numbers to transfer you need Adyen's shape. Their Trino pods pull files from more than 500 HDFS datanodes, one connection per file, about 50,000 connections a minute per pod at peak [11], which is roughly 833 a second [18]. Batch pods live anywhere from a second to a couple of hours [12]. Nodes are 64 physical cores with 512GB of RAM, or 128 cores with 2TB [10], so many of those pods share one kernel's table. If your pods hold pooled connections to a dozen services and your nodes have eight cores, your table stays small and the walk is milliseconds. This failure needs a large node plus a workload that treats a TCP connection as disposable.
In my context I would cap the table and accept eviction rather than raise it and accept a minute-plus window where a node cannot admit pods [5]. That preference depends entirely on having retry-tolerant clients. If a reset means lost data on your path, the trade runs the other way, and you are back to sizing nodes so that no single kernel table gets large enough to matter.
