Note: The survey is closed as of 2025-09-29. Stay tuned and watch this place for the report with the insights we gathered! What does your Kubernetes networking stack look like? Most clusters start simple, with a CNI and a service proxy. Then comes an Ingress controller. A load balancer. Maybe a service mesh for observability. A BGP daemon to integrate with existing networks. A sidecar proxy for encryption. Before long, your networking setup looks less like a stack and more like a tangled web of overlapping tools and configurations. Each layer solves a specific need, but often introduces new tradeoffs in visibility, manageability, and scale. At Isovalent, we speak with teams deploying Kubernetes across a wide range of environments. One pattern keeps coming up: most production setups include at least four distinct networking components. With over 70 networking tools in the Cloud Native Computing Landscape, there are thousands of possible combinations in the wild. So what does “normal” look like? Which tools are most commonly used together? What features are widely adopted and which remain niche? What challenges are teams still struggling to solve? That’s what this survey is here to uncover. Why we're doing this Think of this as a census for Kubernetes networking. Just as national censuses have uncovered infrastructure gaps or health needs, this survey can reveal what’s working and what’s not in the cloud-native world. We want to see how networking is actually being deployed, not just in polished reference architectures but in the clusters powering everyday applications. This isn’t just about which CNI you use. It’s about understanding the broader Kubernetes networking adoption path: Where you run - EKS, AKS, OpenShift, or something else? What you run - microservices, VMs in Kubernetes, or AI workloads? Which CNI(s) you use - are you using whatever CNI came out with your managed Kubernetes service? Or are you using a specific one and if so, why? What other tools are in play - which combination of CNIs, service meshes, load balancers, and proxies are you juggling? How far along you are - are you using Gateway API or still using Ingress? Are you enforcing network policies? Is pod-to-pod encryption or mTLS in place? Who’s running the show - who owns networking and security, and what’s getting in the way of progress? The results will surface common setups and blockers, and give everyone a clearer picture of what Kubernetes networking actually looks like today. What’s in it for you? The results of this survey will only be as good as the input we receive. The more responses we get, the more accurate and useful the insights will be for everyone working with Kubernetes networking. To thank you for your time - ten minutes tops - you can also enter a raffle to win some fun prizes (if you choose to opt-in). Isovalent swag (eBees Lego Sets and Cilium T-shirts) A free all-access ticket to KubeCon North America 2025 (including co-located events) Your answers will help us make sense of the vast number of networking combinations out there, and help others understand how their environment compares to industry trends. The survey will close mid-September and the results will be published later this year - ahead of KubeCon North America, where I’ll hopefully be able to make a bit more sense of it all. Until then, here’s a photo of me looking confused in front of the CNCF landscape at KubeCon London. A fitting reminder of just how many moving parts there are, and why we’re running this survey in the first place - to find the patterns behind the complexity.