# eBPF eBPF is a technology for dynamically programming the kernel for networking, observability, tracing, and security. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Cilium 1.20: Gateway API ExternalAuth, TCPRoute/UDPRoute, ENI IPAM for IPv6, and more DevFeed: [Cilium 1.20: Gateway API ExternalAuth, TCPRoute/UDPRoute, ENI IPAM for IPv6, and more]() Original publisher: [Read original article]() Author: Nico Vibert and Donia Chaiehloudj, Cilium Published: 2026-09-14T10:45:49Z Content type: article Language: en Sources: [Cloud Native Computing Foundation]() Topics: [Cilium](), [Open Source](), [API](), [networking](), [Kubernetes](), [Amazon Web Services](), [eBPF](), [VPC](), [nginx]() Tags: [2026](), [api](), [authentication](), [authorization](), [aws](), [blog](), [cilium](), [cloud](), [cni](), [ebpf](), [google](), [ingress-nginx](), [ipv4](), [ipv6](), [kubernetes](), [microsoft](), [network](), [networking](), [nginx](), [open-source](), [release]() ### AI overview Cilium 1.20 expands Gateway API support with ExternalAuth, CORS filters, ListenerSets, TCPRoute, and UDPRoute. The release also introduces extensible datapath plugins, advances networking standardization with Kubernetes, and adds beta IPv6 support for AWS ENI IPAM. ### Source excerpt Cilium 1.20, the second major open source Cilium release of 2026 after Cilium 1.19, is finally here. Three themes stand out in this release: Thank you to every contributor, reviewer and maintainer who made Cilium 1.20... ## Profiling a Yandex Food PHP monolith to identify CPU usage and reduce allocated cores DevFeed: [Profiling a Yandex Food PHP monolith to identify CPU usage and reduce allocated cores]() Original publisher: [Read original article]() Author: m03r (Яндекс) Published: 2026-09-08T07:31:51Z Content type: article Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [PHP](), [cpu](), [eBPF](), [Linux]() Tags: [cpu](), [ebpf](), [haproxy](), [linux](), [perforator](), [php](), [postgresql]() ### AI overview A backend developer describes investigating unexpectedly high CPU usage in a legacy PHP monolith at Yandex Food. By profiling the application with Perforator and its PHP support, the investigation examined why CPU consumption was unusually high and how the allocated capacity could be reduced. ### Source excerpt Всем привет, меня зовут Миша, и я бэкенд-разработчик в платформе Яндекс Еды. Я уже рассказывал, как мы анализировали наш PHP-монолит и вынесли из него процессинг заказов, и с тех пор роль этого легаси заметно уменьшилась. Заодно туда стали писать гораздо меньше нового кода, релизы стали реже, и он спокойненько себе работал, не привлекая лишнего внимания. Так оно бы и продолжалось, но тут случилась повышенная нагрузка и необходимость зарезервировать побольше мощностей для беспроблемной обработки повышенного спроса. Монолит справился на отлично, но самое интересное случилось потом: возвращая выделение ресурсов к прежним значениям, я случайно обратил внимание, что RPS в пиковые вечерние часы как-то подозрительно совпадает с количеством ядер CPU, выделенных на весь монолит. Количество выделенных ядер, конечно, ещё ничего не означает, поэтому я полез смотреть реальное потребление процессорного времени, сложив CPU usage по всем подам. С помощью нехитрой арифметики я обнаружил, что 100% загрузки одного ядра приходятся на 2,5 RPS. Какое-то время я находился в состоянии глубокого изумления, после чего решил, что это никуда не годится, и отправился в увлекательное приключение на 20 минут. Немного спойлеров: дело оказалось далеко не только в PHP. Читать далее ## Beeline: Enforcing application-layer policies in eBPF DevFeed: [Beeline: Enforcing application-layer policies in eBPF]() Original publisher: [Read original article]() Author: Brandner Laurin Published: 2026-09-01T23:30:00Z Content type: article Language: en Sources: [APNIC Blog]() Topics: [eBPF](), [Cloud Native Ecosystem](), [Latency](), [networking]() Tags: [applications](), [cilium](), [ebpf](), [guest-post](), [http](), [latency](), [networking](), [tech-matters]() ### AI overview The article presents Beeline, a system that enforces application-layer (L7) policies directly in the kernel using eBPF. It explains the latency overhead of user-space service proxies and reports that Beeline improves request latency by 46%, while eliminating the service proxy from the critical path for 89% of L7 policies in the wild. ### Source excerpt Guest Post: While many L7 protocols are complex to parse, the logic needed to enforce L7 policies tends to be simple. For the vast majority (89%) of L7 policies in the wild, Beeline can eliminate the service proxy from the critical path. ## Introducing Nirmata Runtime for Kyverno: Kernel-Level Enforcement for AI Workloads DevFeed: [Introducing Nirmata Runtime for Kyverno: Kernel-Level Enforcement for AI Workloads]() Original publisher: [Read original article]() Author: Jim Bugwadia Published: 2026-08-17T01:27:43Z Content type: release Language: en Sources: [Nirmata]() Topics: [Kyverno](), [Security](), [eBPF](), [configuration](), [Kubernetes]() Tags: [agent](), [ai](), [ai-agents](), [ai-governance](), [configuration](), [ebpf](), [kubernetes](), [kyverno](), [policy](), [product](), [security]() ### AI overview Nirmata introduces Nirmata Runtime for Kyverno, which extends workload controls beyond admission-time configuration checks by enforcing selected runtime behaviors in the kernel. The article describes BPF-LSM and cgroup-scoped eBPF enforcement for process execution, file access, network egress, and application protocols, plus DNS observation and reporting. ### Source excerpt Nirmata created Kyverno and donated it to the CNCF in 2020. Kyverno is now a graduated CNCF project and is widely used for enforcing and automating configuration security and best practices. However, admission control answers one question: does this spec look right? It cannot... The post Introducing Nirmata Runtime for Kyverno: Kernel-Level Enforcement for AI Workloads first appeared on Nirmata. ## 【Istio 控制面】选型收束与开放问题：CRD、Gateway API 与 eBPF L4 的排除树 DevFeed: [【Istio 控制面】选型收束与开放问题：CRD、Gateway API 与 eBPF L4 的排除树]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-11T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [istio](), [gateway](), [eBPF]() Tags: [ambient](), [cilium](), [ebpf](), [experimental](), [gamma](), [gateway](), [gateway-api](), [istio](), [kubernetes](), [mesh](), [network](), [open-problems](), [selection](), [xds]() ### AI overview The concluding article in an Istio control-plane series presents a mechanism-based decision tree for choosing among Istio CRDs, Gateway API/GAMMA, and eBPF L4 networking. It explains that Istio CRDs and Gateway API are alternative configuration inputs compiled by istiod into xDS resources, while eBPF L4 avoids xDS entirely. It also identifies open questions around configuration-activation SLOs, Ambient maturity, and coexistence between configuration models. ### Source excerpt 用机制排除树收束 Istio CRD 翻译、Gateway API/GAMMA 与 eBPF L4 的选型边界，回收系列阅读路径，并列出推送 SLO、Ambient 成熟度、GAMMA 双轨等开放问题；不做延迟排行榜。 ## Detection primitives for eBPF rootkits DevFeed: [Detection primitives for eBPF rootkits]() Original publisher: [Read original article]() Author: Lorenzo Susini, Matt Muir Published: 2026-07-27T00:00:00Z Content type: article Language: en Sources: [Datadog Security Labs]() Topics: [eBPF](), [Malware](), [Linux](), [tracing](), [Network](), [Protocol (disambiguation)](), [debug](), [Processes]() Tags: [debug](), [ebpf](), [kernel](), [linux](), [malware](), [payload](), [processes](), [tracing]() ### AI overview The article analyzes how Linux malware families use eBPF rootkits and helpers to evade defenses, focusing on detection primitives and VoidLink's method for hiding active connections. It explains how VoidLink manipulates user-space memory and processes socket statistics obtained through Netlink. ### Source excerpt We analyze how VoidLink, LinkPro, and Atomic Arch abuse eBPF helpers to hide from defenders, and show how to detect them at load time, before they can act. ## What Is Cilium? DevFeed: [What Is Cilium?]() Original publisher: [Read original article]() Author: Christian Hernandez Published: 2026-07-23T07:01:00Z Content type: tutorial Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Cilium](), [eBPF](), [Kubernetes networking](), [observability](), [Security](), [Cloud]() Tags: [cilium](), [cloud-native](), [ebpf](), [infrastructure](), [kubernetes](), [kubernetes-networking](), [observability](), [security]() ### AI overview An introductory article explains Cilium and describes how it uses eBPF for Kubernetes networking, security, and observability in cloud-native infrastructure. ### Source excerpt Learn what Cilium is, how it uses eBPF to power Kubernetes networking, security, and observability, and why organizations choose it for modern cloud-native infrastructure. ## Runtime security monitoring and threat detection: Protecting production without slowing developers DevFeed: [Runtime security monitoring and threat detection: Protecting production without slowing developers]() Original publisher: [Read original article]() Author: Ajay Chankramath Published: 2026-07-23T05:40:01Z Content type: article Language: en Sources: [Platform Engineering Blog]() Topics: [threat detection](), [Platform Engineering](), [Monitoring](), [Security](), [Containers](), [internal developer platform](), [eBPF](), [Network](), [Processes]() Tags: [blog-post](), [containers](), [developer](), [ebpf](), [firewalls](), [internal-developer-platform](), [monitoring](), [network](), [platform](), [platform-engineering](), [processes](), [security](), [threat-detection]() ### AI overview This article explains how runtime security monitoring protects production workloads from threats that static scans may miss, including privilege escalation, container escapes, unexpected processes, sensitive file access, and suspicious network connections. It presents kernel-level monitoring, including eBPF, as a way to provide continuous protection while embedding security policies into the platform and minimizing developer friction. ### Source excerpt Runtime security monitoring detects zero-days, container escapes, and privilege escalations in production. Discover how eBPF enables 'invisible, always-on' protection for platform engineers ## Inside Cilium CNI: solving mysterious Kubernetes pod setup timeouts DevFeed: [Inside Cilium CNI: solving mysterious Kubernetes pod setup timeouts]() Original publisher: [Read original article]() Author: Adyen Published: 2026-07-13T09:17:40Z Content type: article Language: en Sources: [Adyen Tech]() Topics: [Cilium](), [Kubernetes](), [Kubernetes networking](), [networking](), [eBPF](), [Latency](), [hdfs](), [Apache Spark](), [big-data](), [cpu]() Tags: [big-data](), [cilium](), [cni](), [cpu](), [data](), [devops](), [ebpf](), [hdfs](), [kubernetes](), [kubernetes-networking](), [latency](), [spark](), [speed](), [tracing]() ### AI overview An Adyen engineer investigates Cilium CNI timeouts that prevented new Kubernetes pods from starting. The article attributes the issue to sequential connection-tracking-table garbage collection, which became a bottleneck under workloads involving HDFS, Trino, and short-lived Spark jobs. ### Source excerpt By Jorrick Sleijster - Senior Data Platform Engineer, Adyen I was fully aware a year ago that a single configuration line could break the Kubernetes networking stack. But if they told me that leftovers from Kubernetes pods which terminated hours prior could block new ones from starting, I would have thought they were joking. In high-performance networking, 35 seconds is a lifetime. This was the latency required to iterate through our connection tracking table of 7 million entries at a maximum speed of 200,000 entries per second. At our 16-million-entry peak, this sequential lookup could take up to 80 seconds, leading to Cilium CNI timeouts preventing new pods from starting on affected nodes. We uncovered this linear-time behavior at Adyen by tracing syscalls, inspecting codebases, and analyzing eBPF internals. This investigation revealed how our varied workloads turned the connection tracking table's garbage collection algorithm into a critical bottleneck. Our setup: why we're different At Adyen, we run Cilium CNI across all our 100+ Kubernetes clusters. When we switched from Calico to Cilium, we knew we'd face challenges adapting it to our production workloads. Our production big data Kubernetes clusters have a unique usage pattern compared to the other Kubernetes environments within Adyen: Data extraction from HDFS. Our infrastructure relies on more than 500 datanodes. Trino represents one of our most demanding HDFS workloads, processing analytical queries against data stored on HDFS. Due to the distributed nature of HDFS, each file you download requires a new connection to any of these 500 nodes. Therefore, during peak hours, a single pod can produce approximately 50,000 connections every minute. Pod churn. Many pods we spawn on the Kubernetes cluster run batch jobs, such as Spark jobs. They stay around for anywhere from a second to a couple of hours. Wide variety of workloads. Some workloads are very CPU-intensive, like Spark pods executing complex joins and tra ## 【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器 DevFeed: [【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-06-12T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [eBPF](), [Linux](), [JIT](), [Benchmark](), [clang](), [hash](), [benchmarking](), [RISC-V](), [ast-matchers]() Tags: [arm](), [array](), [benchmark](), [bpf-jit](), [bpf-maps](), [bpf-verifier](), [btf](), [clang](), [co-re](), [cpu](), [ebpf](), [fentry](), [hash](), [jit](), [kernel](), [libbpf](), [linux](), [linux-kernel](), [precision](), [risc-v](), [sched-ext](), [trampoline](), [x86](), [xdp]() ### AI overview This Chinese-language series systematically explains eBPF's Linux kernel implementation, covering the BPF instruction set and registers, verifier algorithms, JIT compilation, map data structures and concurrency, helper type checking, BTF and CO-RE relocation, libbpf loading, trampolines, and sched_ext interfaces. It is aimed at engineers who want to understand eBPF kernel source code and build production BPF programs. ### Source excerpt eBPF 内核虚拟机内部实现系统讲解：BPF 指令集与寄存器机器、验证器的抽象解释与状态裁剪、JIT 编译器后端、Map 各类型的并发与内存模型、helper 函数注册与类型检查、BTF 格式规范与 CO-RE 重定位引擎、libbpf 加载器工程、fentry/fexit 蹦床机制、sched_ext 调度器内核接口。面向想读懂 eBPF 内核源码、写生产级 BPF 程序的系统工程师。 ## Blog: Introducing Falco 0.44.0 DevFeed: [Blog: Introducing Falco 0.44.0]() Original publisher: [Read original article]() Published: 2026-05-26T00:00:00Z Content type: release Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [eBPF](), [Kernel](), [Command-line interface](), [Kubernetes]() Tags: [cli](), [deprecated](), [ebpf](), [falco](), [kernel](), [kubernetes](), [release](), [version]() ### AI overview Falco 0.44.0 removes the legacy eBPF probe, gVisor engine, and gRPC output and server. The release adds rule-language list modifiers, a hard capture-file size limit, stricter schema validation, JSON output for listing commands, faster process-tree lookups, and multi-thread safety fixes. It also includes updated libraries, drivers, plugins, and rules. ### Source excerpt Dear Falco Community, we are happy to announce the release of Falco 0.44.0 today! This release completes the deprecation cycle started in 0.42.0 and 0.43.0: the legacy eBPF probe, the gVisor engine, and the gRPC output (along with the gRPC server) are now fully removed from the entire stack. On top of that, 0.44.0 brings new rule-language capabilities, a long-requested safety knob for the capture feature, JSON output for the --list family of commands, a substantial round of performance work on process tree lookups, and a wave of multi-thread safety fixes that lay the groundwork for the upcoming multi-threaded Falco architecture. During this release cycle, we merged: 60 PRs on Falco, including 14 release note-worthy changes 160 PRs on Falco libs, including 54 release note-worthy changes 16 PRs on Falco drivers, including 3 release note-worthy changes We upgraded libs to version 0.25.2 and drivers to 10.2.0+driver. We also ship falcoctl 0.13.0, the container plugin 0.7.1, and the falco-rules ruleset 5.1.0. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication! To learn everything about the changes, read on! What's new? TL;DR Major features and improvements: Comparison operator list modifiers (oneof/anyof/allof) Hard limit on capture file size Stricter rule schema validation Backslash escaping in -o dotted key paths JSON output for the listing CLI commands Faster process tree lookups Multi-thread safety hardening Drivers: The kernel module pre-builds for this release are still being produced and will be available within a couple of days from the release. In the meantime, falcoctl can build the kernel module locally on the host. Drivers: new syscall, kernel 7.0, and BPF iterators Plugins: Container plugin fix for containerd v2.3.0 Plugin library path traversal hardening Event generator: Event generator: HTTP output and new suite namespace Rules: Updated ruleset (falco-rules 5.1.0) Kubernetes: Kubernetes Oper ## Stop guessing in production: Full fidelity tracing at scale with ClickHouse and Odigos DevFeed: [Stop guessing in production: Full fidelity tracing at scale with ClickHouse and Odigos]() Original publisher: [Read original article]() Author: Will Searle Published: 2026-05-05T00:00:00Z Content type: article Language: en Sources: [ClickHouse Blog]() Topics: [tracing](), [Instrumentation](), [observability](), [telemetry](), [clickhouse](), [OpenTelemetry](), [eBPF](), [Scalability](), [Kafka]() Tags: [clickhouse](), [ebpf](), [instrumentation](), [kafka](), [observability](), [opentelemetry](), [scalability](), [telemetry](), [tracing]() ### AI overview The article explains how combining ClickStack, a ClickHouse-native observability backend, with Odigos, a zero-code OpenTelemetry instrumentation platform, can reduce observability gaps. It focuses on capturing complete, contextual telemetry across distributed and asynchronous systems, including trace context crossing Kafka and background-processing boundaries, while addressing the operational overhead and scalability risks of OpenTelemetry pipelines. ### Source excerpt How ClickStack and Odigos eliminate observability gaps with zero-code eBPF instrumentation and full-fidelity distributed tracing at scale. ## Technology Short Take 194 DevFeed: [Technology Short Take 194]() Original publisher: [Read original article]() Author: Scott Lowe Published: 2026-04-17T13:00:00Z Content type: article Language: en Sources: [Scott's Weblog]() Topics: [datacenter](), [networking](), [Cryptography](), [Security](), [Vulnerabilities](), [eBPF](), [Kubernetes](), [Claude Code](), [TLS (Transport Layer Security)](), [ChaCha]() Tags: [article](), [aws](), [blog](), [cilium](), [claude-code](), [cli](), [cloud](), [cni](), [containers](), [cri-o](), [critical-infrastructure](), [cryptography](), [devops](), [docker](), [go](), [iac](), [k8s](), [kubernetes](), [linux](), [networking](), [oci](), [security](), [vulnerabilities]() ### AI overview Technology Short Take 194 curates data center technology links covering Reticulum, IPv6 networking, security exploits and vulnerabilities, TLS and QUIC diagrams, Kubernetes security, Claude Code advisories, AWS emulation, and developer tools. ### Source excerpt This is Technology Short Take #194, the latest in my semi-regular series of posts sharing data center technology-related links and articles from around the web. What have I gathered for readers this time? Key topics in Tech Short Take 194 include a new cryptography-based network stack, a look at why folks are revolting against AI, and an in-depth comparison of microVM technologies. On to the content! Networking This is cool. Longtime reader Todd Smith pointed me to Reticulum, a new cryptography-based network stack. Todd also spent some time messing around with Reticulum and shared his findings in two blog posts: first, an initial/introductory post, followed by a post sharing his experience with some Reticulum experiments. Scott Hogg examines building an IPv6 training and testing lab. Security eBPF is taking hold in security exploits, like the tool named "BPFdoor" that is penetrating critical infrastructure networks. Paul Meyer discusses reproducing and mitigating BadAML, an ACPI-based attack vector that can be used to potentially gain access to confidential VMs. Meyer admits that the model in the article assumes the attacker has full control over the host, at which point I would assume "game over" and move on. This site provides not only an illustrated TLS 1.2 connection diagram, but also offers diagrams for QUIC, DTLS, and TLS 1.3 (see the links in the upper right corner). Rory McCune continues his series on unpatchable Kubernetes vulnerabilities. David Chisnall posted a scathing analysis of Mythos on Mastodon (hat tip to Bruce Davie for boosting it into my timeline), and shared a link to an advisory on critical command injection vulnerabilities in Claude Code. Cloud Computing/Cloud Management I recently found this alternative to LocalStack for AWS emulation. How to hide regions and services in the AWS console is a useful thing to know about. Operating Systems/Applications Chris Down breaks down the differences between zswap and zram. Micah Kepe introduces his new ## Kubernetes 网络深度系列 DevFeed: [Kubernetes 网络深度系列]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-04-03T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [Linux](), [eBPF](), [VXLAN](), [gateway](), [nginx](), [traefik](), [Grafana]() Tags: [ebpf](), [gateway](), [grafana](), [index](), [k8s](), [kubernetes](), [linux](), [net-11](), [networking](), [nginx](), [return](), [series](), [service-mesh](), [traefik](), [vxlan]() ### AI overview A Chinese tutorial series explains Kubernetes networking from the Linux network stack through virtual devices, routing, tunnels, eBPF, CNI plugins, Services, security policies, service discovery, traffic management, performance tuning, and troubleshooting. It includes packet captures, code, and kernel-source references, with comparisons of major CNI and ingress approaches. ### Source excerpt 从 Linux 网络栈的第一个字节到多集群联邦网络的最后一跳----用代码、抓包和内核源码把 Kubernetes 网络讲透 ## Blog: Introducing Falco 0.43.0 DevFeed: [Blog: Introducing Falco 0.43.0]() Original publisher: [Read original article]() Published: 2026-01-26T00:00:00Z Content type: release Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [eBPF](), [Kernel](), [Maintainability]() Tags: [ebpf](), [falco](), [improvements](), [kernel](), [legacy](), [maintainability](), [race-condition](), [release](), [version]() ### AI overview Falco 0.43.0 is a stabilization release that consolidates changes from 0.42.0, adds deprecations, and fixes issues across Falcoctl, plugins, and libraries. It includes updates to Falco libraries and drivers, signature verification fixes, plugin fixes, and the reintroduction of the evt.arg.filename field. The release deprecates the legacy eBPF probe and gVisor engine while directing users toward modern alternatives. ### Source excerpt Dear Falco Community, we are happy to announce the release of Falco 0.43.0 today! This is a stabilization release that consolidates the changes introduced in 0.42.0, including the drop-enter initiative and the capture recording feature. It also introduces several deprecations to improve maintainability and fixes minor issues across falcoctl, plugins, and libs. During this release cycle, we merged: 31 PRs on Falco, including 11 release note-worthy changes 48 PRs on Falco libs, including 17 release note-worthy changes 8 PRs on Falco drivers, including 3 release note-worthy changes We upgraded libs to version 0.23.1 and drivers to 9.1.0+driver. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication! To learn everything about the changes, read on! What's new? TL;DR Deprecations GPG key rotation Container plugin improvements Falcoctl tweaks and improvements Key fixes: evt.arg.filename field reintroduction Falcoctl signature verification fixes overflow and NULL pointer dereferences fixes for the container plugin, shipped with plugins/container/0.6.1 race condition fix for the k8smeta plugin, shipped with plugins/k8smeta/0.4.1 This release also comes with breaking changes that you should be aware of before upgrading. Latest updates Deprecations In Falco 0.43.0, we are announcing the deprecation of three significant components to streamline the project, reduce maintenance burden, and focus on modern, more efficient alternatives. All these components are stable, and considering that the deprecation is first enforced in this version, they could be removed at any future version starting from 0.44.0. Legacy eBPF probe deprecation The "legacy" eBPF probe (configured via engine.kind=ebpf) was the original eBPF implementation in Falco. It required compiling a specific probe for each kernel version, often necessitating the dynamic usage of the falco-driver-loader or pre-built drivers. The Modern eBPF probe (engine.kind=m ## Leveling Up Kubernetes: Key DigitalOcean Managed Kubernetes Releases in 2025 DevFeed: [Leveling Up Kubernetes: Key DigitalOcean Managed Kubernetes Releases in 2025]() Original publisher: [Read original article]() Author: Nicole Ghalwash Published: 2025-12-15T18:30:03Z Content type: article Language: en Sources: [DigitalOcean]() Topics: [Digital Ocean](), [Kubernetes](), [releases](), [networking](), [Cilium](), [eBPF](), [VPC](), [Latency](), [autoscaling](), [observability]() Tags: [2025](), [autoscaling](), [cilium](), [digitalocean](), [ebpf](), [improvements](), [kubernetes](), [latency](), [networking](), [observability](), [performance](), [releases](), [scalability](), [updates](), [vpc]() ### AI overview A recap of DigitalOcean Managed Kubernetes releases in 2025, covering cluster-capacity increases, VPC-native networking, eBPF-powered routing, Managed Cilium with Hubble, and related security, autoscaling, and ecosystem improvements. The updates aim to simplify Kubernetes operations and support larger, more efficient workloads. ### Source excerpt 2025 was a busy and transformative year for DigitalOcean Managed Kubernetes, marked by a series of releases that make DigitalOcean Kubernetes simpler, more secure, and more scalable for developers and growing businesses. Across engine upgrades, networking and security enhancements, autoscaling improvements, and new ecosystem integrations, this year's updates aimed to give teams more power with less operational overhead. Whether users are running production workloads, experimenting with microservices, or scaling customer-facing applications, the enhancements launched throughout 2025 make it easier than ever to deploy, manage, and optimize Kubernetes on DigitalOcean. In this recap, we'll walk through the major releases that shaped the platform over the past year and how they help developers move faster with confidence. Next Evolution of DigitalOcean Kubernetes [March] In March, we rolled out four major upgrades to DigitalOcean Kubernetes (DOKS) that make it easier to run larger and more efficient workloads: increased cluster capacity, VPC-native networking, eBPF-powered routing, and Managed Cilium. Here's a look at each one: Cluster capacity has doubled from 500 to 1,000 worker nodes, allowing bigger applications to run on a single cluster without the overhead of managing multiple environments. VPC-native Kubernetes now assigns IPs directly from your VPC, improving performance and simplifying communication with other cloud resources. Replacing kube-proxy with eBPF-based networking and routing delivers faster packet processing and lower latency, benefiting high-traffic and real-time workloads. Managed Cilium with Hubble for observability adds stronger security, modern networking, and easier troubleshooting. Together, these features significantly boost scalability, performance, and reliability while reducing operational complexity of DOKS, so developers gain clearer visibility and a simpler networking stack, while businesses benefit from lower overhead and the ability t ## Leaving Intel DevFeed: [Leaving Intel]() Original publisher: [Read original article]() Published: 2025-12-04T13:00:00Z Content type: opinion Language: en Sources: [Brendan Gregg's Blog]() Topics: [intel](), [Artificial Intelligence](), [GPU](), [eBPF](), [Cloud](), [cloud-computing](), [Linux](), [Open Source](), [Monitoring]() Tags: [ai](), [blog](), [cloud-computing](), [cpu](), [ebpf](), [gpu](), [intel](), [leaving](), [linux](), [monitoring](), [open-source](), [performance]() ### AI overview The author announces his departure from Intel after 3.5 years and reflects on his work there, including open-source AI flame graphs, GPU performance visualization, Linux stack walking, eBPF security monitoring, conference leadership, customer meetings, and a company-wide cloud strategy. ### Source excerpt InnovatiON 2022 AI Flame Graphs GPU Flame Scope Harshad Sane SREcon APAC Cloud strategy Last day I've resigned from Intel and accepted a new opportunity. If you are an Intel employee, you might have seen my fairly long email that summarized what I did in my 3.5 years. Much of this is public: AI flame graphs and released them as open source GPU subsecond-offset heatmap Worked with Linux distros to enable stack walking Was interviewed by the WSJ about eBPF for security monitoring Provided leadership on the eBPF Technical Steering Committee (BSC) Co-chaired USENIX SREcon APAC 2023 Gave 6 conference keynotes It's still early days for AI flame graphs. Right now when I browse CPU performance case studies on the Internet, I'll often see a CPU flame graph as part of the analysis. We're a long way from that kind of adoption for GPUs (and it doesn't help that our open source version is Intel only), but I think as GPU code becomes more complex, with more layers, the need for AI flame graphs will keep increasing. I also supported cloud computing, participating in 110 customer meetings, and created a company-wide strategy to win back the cloud with 33 specific recommendations, in collaboration with others across 6 organizations. It is some of my best work and features a visual map of interactions between all 19 relevant teams, described by Intel long-timers as the first time they have ever seen such a cross-company map. (This strategy, summarized in a slide deck, is internal only.) I always wish I did more, in any job, but I'm glad to have contributed this much especially given the context: I overlapped with Intel's toughest 3 years in history, and I had a hiring freeze for my first 15 months. My fond memories from Intel include meeting Linus at an Intel event who said "everyone is using fleme graphs these days" (Finnish accent), meeting Pat Gelsinger who knew about my work and introduced me to everyone at an exec all hands, surfing lessons at an Intel Australia and HP offsite ( ## On "AI Brendans" or "Virtual Brendans" DevFeed: [On "AI Brendans" or "Virtual Brendans"]() Original publisher: [Read original article]() Published: 2025-11-27T13:00:00Z Content type: opinion Language: en Sources: [Brendan Gregg's Blog]() Topics: [Artificial Intelligence](), [eBPF](), [systems]() Tags: [ai](), [ai-agents](), [blog](), [ebpf](), [opinions](), [performance]() ### AI overview Brendan Gregg discusses AI performance-engineering agents and "virtual Brendan" systems trained on his publications. He distinguishes agents that interpret flame graphs and eBPF metrics from systems intended to emulate his expertise, and argues that these tools have limited scope, may become outdated, and are difficult to price and evaluate. ### Source excerpt There are now multiple AI performance engineering agents that use or are trained on my work. Some are helper agents that interpret flame graphs or eBPF metrics, sometimes privately called AI Brendan; others have trained on my work to create a virtual Brendan that claims it can tune everything just like the real thing. These virtual Brendans sound like my brain has been uploaded to the cloud by someone who is now selling it (yikes!). I've been told it's even "easy" to do this thanks to all my publications available to train on: >90 talks, >250 blog posts, >600 open source tools, and >3000 book pages. Are people allowed to sell you, virtually? And am I the first individual engineer to be AI'd? (There is a 30-year-old precedent for this, which I'll get to later.) This is an emerging subject, with lots of different people, objectives, and money involved. Note that this is a personal post about my opinions, not an official post by my employer, so I won't be discussing internal details about any particular project. I'm also not here to recommend you buy any in particular. Summary There are two types: AI agents. I've sometimes heard them called an AI Brendan because it does Brendan-like things: systems performance recommendations and interpretation of flame graphs and eBPF metrics. There are already several of these and this idea in general should be useful. Virtual Brendan can refer to something not just built on my work, but trained on my publications to create a virtual me. These would only automate about 15% of what I do as a performance engineer, and will go out of date if I'm not training it to follow industry changes. Pricing is hard, in-house is easier. With a typical pricing model of $20 per instance per month, customers may just use such an agent on one instance and then copy-and-paste any tuning changes to their entire fleet. There's no practical way to keep tuning changes secret, either. These projects are easier as internal in-house tools. Some claim a lot but ## SwiNOG 40: Application-Based Source Routing with SRv6 DevFeed: [SwiNOG 40: Application-Based Source Routing with SRv6]() Original publisher: [Read original article]() Published: 2025-08-27T06:28:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [SRv6](), [networking](), [eBPF](), [Routing (disambiguation)]() Tags: [ebpf](), [network](), [networking](), [routing](), [sdn](), [srv6]() ### AI overview This commentary examines an application-based traffic-steering design that uses SRv6, an intent-based system, and eBPF on client hosts to add per-application SRv6 headers. It highlights potentially better scalability than RSVP-based traffic engineering because the design avoids host-to-network signaling, periodic path refreshes, and extra network state, while noting unresolved path-liveness and failure-recovery concerns. ### Source excerpt The we should give different applications different paths across the network idea never dies (even though in many places the residential Internet gives you enough bandwidth to watch 4K videos), and the Leveraging Intent-Based Networking and SRv6 for Dynamic End-to-End Traffic Steering (video) by Severin Dellsperger was an interesting new riff on that ancient grail hunt. Their solution uses SRv6 for traffic steering1, an Intent-Based System2 that figures out paths across the network, and eBPF on client hosts3 to add per-application SRv6 headers to outgoing traffic. Read more ... ## Blog: Introducing Falco 0.41.0 DevFeed: [Blog: Introducing Falco 0.41.0]() Original publisher: [Read original article]() Published: 2025-05-29T00:00:00Z Content type: release Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [eBPF](), [Kubernetes](), [configuration](), [container](), [JSON](), [Prometheus](), [bug](), [Code Modularity]() Tags: [bug-fixes](), [capabilities](), [changes](), [code-modularity](), [configuration](), [container](), [ebpf](), [falco](), [json](), [kubernetes](), [prometheus](), [release](), [ux]() ### AI overview Falco 0.41.0 introduces revised container engine support, an early Kubernetes operator, configurable merge strategies, expanded eBPF driver behavior, new field access options, and JSON output controls. The release also includes fixes for kernel-module crashes, Prometheus metrics, RPM scripts, and configuration overrides. ### Source excerpt Dear Falco Community, today we are happy to announce the release of Falco 0.41.0! This version brings several new features, performance enhancements, and bug fixes that streamline Falco's detection capabilities. During this release cycle, we merged more than 50 PRs on Falco and around 130 PRs for libs and drivers, version 0.21.0 and version 8.1.0, respectively. Thank you to our maintainers and contributors. This would not have been possible without your support and dedication! To learn everything about the changes, read on! What's new? TL;DR Key features: Reimplemented container engines support from scratch; A Kubernetes operator is taking shape; Falco's config_files configuration gained support to specify the merge strategy; Modern eBPF driver is now capable of trying to load multiple programs for each event; consequently, sendmmsg and recvmmsg will now make use of bpf_loop eBPF helper where available, boosting their performances; New proc.aargs field available, ie: a lookup for an ancestor args field; proc.args gained support for indexed access, to only check a certain argument; json_include_output_fields configuration key for Falco to control whether output fields are included in the JSON message; Ongoing work to improve libs code modularity; Key fixes: Avoid kmod crashing when a CPU gets enabled at runtime; Fixed Falco Prometheus metrics with multiple event sources enabled; Fixed RPM packages evaluation of RPM scripts; -o options do now correctly override included config_files; This release also comes with breaking changes that you should be aware of before upgrading. Major features and improvements The 0.41.0 release contains a number of features and UX improvements. Here is a list of some of the key new capabilities. Reimplemented container engines support In the Falco 0.41.0 release, the Falco team has completely revised its support for container engines. Key improvements include: Container support is now a plugin; The plugin will attach a listener to the eng ## Blog: Introducing Falco 0.39.2 DevFeed: [Blog: Introducing Falco 0.39.2]() Original publisher: [Read original article]() Published: 2024-11-21T00:00:00Z Content type: release Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [eBPF](), [Kernel](), [Gke](), [Docker](), [Process]() Tags: [aws](), [container-images](), [docker](), [ebpf](), [falco](), [gke](), [kernel](), [release]() ### AI overview Falco 0.39.2 is a small patch release that fixes modern eBPF driver issues, including compatibility with GKE and kernel versions 6.11.4 and later. ### Source excerpt Today we announce the release of Falco 0.39.2 🦅! Fixes Falco's 0.39.2 is a small patch release that includes some important bugfixes for modern eBPF driver: check cred field is not NULL before the access; this enables Falco back with modern eBPF driver to work on GKE address verifier issues on kernel versions >=6.11.4: there was a kernel-breaking change in the tail call ebpf API merged into the 6.11.4 to fix a CVE. Adapt our code to work again on these new versions. Thanks to everyone in the community for helping us spot these annoying bugs and improving Falco every day 🐛! You make Falco successful 🦅! Thanks as always to the Falco maintainers for their support and effort during the entire release process. Try it! 🏎 As usual, in case you just want to try out the stable Falco 0.39.2, you can install its packages following the process outlined in the docs: CentOS/Amazon Linux Debian/Ubuntu openSUSE Linux binary package Prefer to use a container image? No problem at all! 🐳 You can read more about running Falco with Docker in the docs. You can also find the Falcosecurity container images on the public AWS ECR gallery: falco falco-no-driver falco-driver-loader Let's meet 🤝 We meet every Wednesday in our community calls, if you want to know the latest and the greatest, you should join us there! If you have any questions Join the #falco channel on the Kubernetes Slack Join the Falco mailing list Thanks to all the amazing contributors! Enjoy 😎, Federico ## AI Flame Graphs DevFeed: [AI Flame Graphs]() Original publisher: [Read original article]() Published: 2024-10-28T13:00:00Z Content type: article Language: en Sources: [Brendan Gregg's Blog]() Topics: [Artificial Intelligence](), [GPU](), [intel](), [telemetry](), [Instrumentation](), [eBPF](), [C++](), [Code]() Tags: [ai](), [blog](), [c-plus-plus](), [ebpf](), [flame-graph](), [flamegraph](), [gpu](), [instrumentation](), [intel](), [performance](), [profiling](), [svg](), [visualization]() ### AI overview The article presents AI Flame Graphs, an Intel analyzer that visualizes AI accelerator or GPU instruction activity together with the software stack. It explains how the profiler uses Intel EU stall profiling and eBPF instrumentation to identify costly code paths, illustrating optimization differences in a SYCL matrix-multiply benchmark. ### Source excerpt Imagine halving the resource costs of AI and what that could mean for the planet and the industry -- based on extreme estimates such savings could reduce the total US power usage by over 10% by 20301. At Intel we've been creating a new analyzer tool to help reduce AI costs called AI Flame Graphs: a visualization that shows an AI accelerator or GPU hardware profile along with the full software stack, based on my CPU flame graphs. Our first version is available to customers in the Intel Tiber AI Cloud as a preview for the Intel Data Center GPU Max Series (previously called Ponte Vecchio). Here is an example: Simple example: SYCL matrix multiply microbenchmark (Click for interactive SVG.) The green frames are the actual instructions running on the AI or GPU accelerator, aqua shows the source code for these functions, and red (C), yellow (C++), and orange (kernel) show the CPU code paths that initiated these AI/GPU programs. The gray "-" frames just help highlight the boundary between CPU and AI/GPU code. The x-axis is proportional to cost, so you look for the widest things and find ways to reduce them. Layers This flame graph shows a simple program for SYCL (a high-level C++ language for accelerators) that tests three implementations of matrix multiply, running them with the same input workload. The flame graph is dominated by the slowest implementation, multiply_basic(), which doesn't use any optimizations and consumes at 72% of stall samples and is shown as the widest tower. On the right are two thin towers for multiply_local_access() at 21% which replaces the accessor with a local variable, and multiply_local_access_and_tiling() at 6% which also adds matrix tiling. The towers are getting smaller as optimizations are added. This flame graph profiler is a prototype based on Intel EU stall profiling for hardware profiling and eBPF for software instrumentation. It's designed to be easy and low-overhead, just like a CPU profiler. You should be able to generate a flame gr ## Blog: Deploy Falco on a Talos cluster DevFeed: [Blog: Deploy Falco on a Talos cluster]() Original publisher: [Read original article]() Published: 2024-07-22T00:00:00Z Content type: tutorial Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Tutorial](), [Kubernetes](), [eBPF](), [audit](), [Containers](), [Docker](), [Command-line interface](), [Deployment](), [Kernel]() Tags: [audit](), [blog](), [cli](), [containers](), [deploy](), [docker](), [ebpf](), [falco](), [kernel](), [kubernetes](), [tools](), [tutorial]() ### AI overview A tutorial showing how to deploy Falco on a local Talos Linux Kubernetes cluster created with Docker containers. It covers cluster setup, kubeconfig retrieval, patching Talos nodes for the eBPF probe, Helm installation, and forwarding Kubernetes audit logs to Falco. ### Source excerpt Talos Linux is an OS designed for Kubernetes, with in mind to be secure, immutable and minimal. It offers a solution for having secure nodes for your Kubernetes cluster. Running Falco on them requires some configurations we'll see in this blog post. The good news is everything is available to collect the syscalls with eBPF and also the audit logs from the Kubernetes control plane. In this tutorial we'll use a local Talos cluster created with Docker containers for convenience, adapt the configurations to your own context. Requirements For this tutorial, you'll need several tools installed: Docker Helm talosctl kubectl Set up the Talos cluster We'll start with a 2 workers cluster: talosctl cluster create --workers 2 --wait-timeout 5m After a few minutes, your containers and so your cluster should be up and running. You can check the status with: talosctl cluster show --nodes 10.5.0.2,10.5.0.3,10.5.0.4 Output: PROVISIONER docker NAME talos-default NETWORK NAME talos-default NETWORK CIDR 10.5.0.0/24 NETWORK GATEWAY NETWORK MTU 1500 NODES: NAME TYPE IP CPU RAM DISK talos-default-controlplane-1 controlplane 10.5.0.2 - - - talos-default-worker-1 worker 10.5.0.3 - - - talos-default-worker-2 worker 10.5.0.4 - - - Get the kubeconfig The talosctl CLI allows to easily set up your kubeconfig file for managing the apps in your fresh new cluster: talosctl kubeconfig -n 10.5.0.2 -f Check you have access to the cluster: kubectl cluster-info Output: Kubernetes control plane is running at https://10.5.0.2:6443 CoreDNS is running at https://10.5.0.2:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Patch the cluster When you deploy Falco with Helm in a Kubernetes cluster, an initContainer is bootstrapped to inject the eBPF probe into the kernel of each node. This behavior requires some privileges but Talos, designed to be secured, doesn't allow that by default. It's possible anyway by patching ## How eBPF Could Prevent Kernel Crashes from Security Software Updates DevFeed: [How eBPF Could Prevent Kernel Crashes from Security Software Updates]() Original publisher: [Read original article]() Published: 2024-07-21T14:00:00Z Content type: opinion Language: en Sources: [Brendan Gregg's Blog]() Topics: [eBPF](), [Security](), [Linux](), [Kernel](), [Windows](), [browsers]() Tags: [blog](), [browsers](), [ebpf](), [kernel](), [linux](), [outage](), [outages](), [security](), [windows]() ### AI overview This opinion article examines a major Windows outage caused by a security software configuration update that made a kernel driver read invalid memory. It argues that eBPF's verifier and sandboxed execution model could reduce the risk of kernel crashes, including for Windows once Microsoft's eBPF support is production-ready. ### Source excerpt In the future, computers will not crash due to bad software updates, even those updates that involve kernel code. In the future, these updates will push eBPF code. Friday July 19th provided an unprecedented example of the inherent dangers of kernel programming, and has been called the largest outage in the history of information technology. Windows computers around the world encountered blue-screens-of-death and boot loops, causing outages for hospitals, airlines, banks, grocery stores, media broadcasters, and more. This was caused by a config update by a security company for their widely used product that included a kernel driver on Windows systems. The update caused the kernel driver to try to read invalid memory, an error type that will crash the kernel. For Linux systems, the company behind this outage was already in the process of adopting eBPF, which is immune to such crashes. Once Microsoft's eBPF support for Windows becomes production-ready, Windows security software can be ported to eBPF as well. These security agents will then be safe and unable to cause a Windows kernel crash. eBPF (no longer an acronym) is a secure kernel execution environment, similar to the secure JavaScript runtime built into web browsers. If you're using Linux, you likely already have eBPF available on your systems whether you know it or not, as it was included in the kernel several years ago. eBPF programs cannot crash the entire system because they are safety-checked by a software verifier and are effectively run in a sandbox. If the verifier finds any unsafe code, the program is rejected and not executed. The verifier is rigorous -- the Linux implementation has over 20,000 lines of code -- with contributions from industry (e.g., Meta, Isovalent, Google) and academia (e.g., Rutgers University, University of Washington). The safety this provides is a key benefit of eBPF, along with heightened security and lower resource usage. Some eBPF-based security startups (e.g., Oligo, Uptycs) [Next page]()