If you’ve managed traffic in Kubernetes, you’ve likely navigated the world of Ingress controllers. For years, Ingress has been the standard way of getting HTTP/S services exposed. But let’s be honest, it often felt like a compromise. We wrestled with controller-specific annotations to unlock critical features, blurred the lines between infrastructure and application concerns, this complexity didn’t just make portability more difficult, it sometimes led to security vulnerabilities and other complications.
As part of Calico Open Source v3.30, we have released a free and open source Calico Ingress Gateway that implements a custom built Envoy proxy with the Kubernetes Gateway API standard to help you navigate Ingress complexities with style. This blog post is designed to get you up to speed on why such a change might be the missing link in your environment.
The challenge with traditional Ingress wasn’t a lack of effort, since the landscape is full of innovative solutions. However, the problem was the lack of a unified, expressive, and role-aware standard. Existing ingress controllers were capable, implemented advanced features, however at the same time tied you to a specific project/vendor.
This meant:
Jo attempted to follow the vendor Kool-Aid recommendations and use NETCONF/YANG to configure network devices. Here’s what he found (slightly edited):
IMHO, the whole NETCONF ecosystem primarily suffers from a tooling problem. Or I haven’t found the right tools yet.
ncclient is (as you mentioned somewhere else) an underdocumented mess. And that undocumented part is not even up to date. The commit hash at the bottom of the docs page is from 2020… I am amazed how so many people got it working well enough to depend on it in their applications.
This is my second time attending the AutoCon event. The first one I went to was last year in Amsterdam (AutoCon1), and it was absolutely amazing. I decided to attend again this year, and AutoCon3 took place from the 26th to the 30th of May. The first two days were dedicated to workshops, and the conference itself ran from the 28th to the 30th. I only attended the conference. I heard there were around 650 attendees at this event, which is great to see.
In case you’ve never heard of AutoCon, it’s a community-driven conference focused on network automation, organized by the Network Automation Forum (NAF). NAF brings together people from across the industry to share ideas, tools, and best practices around automation, orchestration, and observability in networking.
They typically hold two conferences each year, one in Europe and one in the USA, or at least that’s how it’s been so far. The European event is usually around the end of May, and the US one takes place around November. Tickets are released in tiers, with early bird pricing being cheaper. I grabbed the early bird ticket for 299 euros as soon as it was announced.
This is a guest post by Chris Bell, CTO of Knock
There’s a lot of talk right now about building AI agents, but not a lot out there about what it takes to make those agents truly useful.
An Agent is an autonomous system designed to make decisions and perform actions to achieve a specific goal or set of goals, without human input.
No matter how good your agent is at making decisions, you will need a person to provide guidance or input on the agent’s path towards its goal. After all, an agent that cannot interact or respond to the outside world and the systems that govern it will be limited in the problems it can solve.
That’s where the “human-in-the-loop” interaction pattern comes in. You're bringing a human into the agent's loop and requiring an input from that human before the agent can continue on its task.
In this blog post, we'll use Knock and the Cloudflare Agents SDK to build an AI Agent for a virtual card issuing workflow that requires human approval when a new card is requested.
You can find the complete code for this example in the repository.
Knock is messaging Continue reading
Note to readers: I’m merging the worth reading and weekend reads into a “couple of times a week” worth reading. How often I post these depends on the number of articles I run across, but I’ll try to keep it to around five articles per post
To build a data-driven story, we must use a basic narrative model. Various models exist in the literature, such as the Data-Information-Knowledge-Wisdom (DIKW) Continue reading
Jan Schaumann published an interesting blog post describing the circuitous journey a browser might take to figure out that it can use QUIC with a web server.
Now, if only there were a record in a distributed database telling the browser what the web server supports. Oh, wait… Not surprisingly, browser vendors don’t trust that data and have implemented a happy eyeballs-like protocol to decide between HTTPS over TCP and QUIC.
A reader of my blog pointed out the following minutiae hidden at the very bottom of the Cumulus Linux 5.13 What’s New document:
NVIDIA no longer releases Cumulus VX as a standalone image. To simulate a Cumulus Linux switch, use NVIDIA AIR.
And what is NVIDIA AIR?
Today, we are excited to announce that Forrester has recognized Cloudflare Email Security as a Strong Performer and among the top three providers in the ‘current offering’ category in “The Forrester Wave™: Email, Messaging, And Collaboration Security Solutions, Q2 2025” report. Get a complimentary copy of the report here. According to Forrester:
“Cloudflare is a solid choice for organizations looking to augment current email, messaging, and collaboration security tooling with deep content analysis and processing and malware detection capabilities.”
In this evaluation, Forrester analyzed 10 Email Security vendors across 27 different criteria. Cloudflare received the highest scores possible in nine key evaluation criteria, and also scored among the top three in the current offering category. We believe this recognition is due to our ability to deliver stronger security outcomes across email and collaboration tools. These highlights showcase the strength and maturity of our Email Security solution:
Cloudflare’s advanced sandboxing engine analyzes files, whether directly attached or linked via cloud storage, using both static and dynamic analysis. Our AI-powered detectors evaluate attachment structure and behavior in real time, enabling protection not only against known malware but also emerging threats.
When deep-diving into the confusing terminology of switching, routing, and bridging, I mentioned you could perform packet forwarding at different layers of a networking stack. In this blog post, we’ll explore what happens when we combine packet forwarding on multiple layers within a single network, resulting in multi-layer switching, where edge devices perform Layer n forwarding (usually Layer 3), and core devices perform Layer n-1 forwarding (typically Layer 2).
Each layer can use any forwarding paradigm you choose. However, since we generally use IP at Layer 3, edge devices typically perform hop-by-hop destination-based forwarding, while core devices can use alternative methods.