What Kubernetes Means for NetOps and CloudOps Teams

Kubernetes celebrated its 10th anniversary in 2024. It has reason to celebrate – it’s the most popular container orchestration platform in the world. About three-quarters of organizations are running Kubernetes clusters in production, including Netflix, Spotify, Airbnb and Niantic (the company behind Pokemon Go). Increasing numbers of these clusters are in the cloud – 64% in 2025, up from 45% in 2022.  

The growth of Kubernetes has spawned unintended consequences for many network operations and cloud operations teams. It adds another level of complexity to a network that’s already gotten much more complex in the last decade (the cloud, virtualization, remote work, etc.). IT budgets and processes at many enterprises have not kept pace with this complexity. Tracking network traffic from on-prem through the cloud and Kubernetes is complicated, which makes many IT functions more difficult.

I’ll show you what I mean. Here is an example traffic application path for an application run using Kubernetes. 

1. Entry Point: Internet to Cluster – External traffic (like an HTTP request) is first received by a LoadBalancer or NodePort service. 
2. Routing by Ingress or Gateway – The traffic is passed to an Ingress Controller , which uses routing rules defined in Ingress or Gateway resources to determine which backend Kubernetes Service (and then which application) to forward the request to. 
3. Service Abstraction – That Kubernetes Service receives the traffic. 
4. Load Balancing – Next, the Service load-balances requests across all available Pods behind it using kube-proxy and iptables or similar networking mechanisms. 
5. Pod-Level Networking – The request is forwarded by the Service to one of the selected Pods, which each have their own cluster-internal IP address (according to the Container Network Interface layer for that pod). 
6. Application Processing – The application container processes the request and sends a response back along the same path, either to the Service or directly back through the Ingress or load balancer if the response is bound for an external client. 

IT teams have limited visibility into these paths. There are Kubernetes monitoring tools, but most of them stop at the container level. They don’t show how traffic gets to a Pod or what might be broken in the hybrid path. This creates blind spots that can conceal problems. Unintended changes in Kubernetes service configs, policies, or annotations can go unnoticed, possibly setting up future security or performance issues. These issues often metastasize into problems that affect users before they’re detected.  

Security is another issue. Things like Ingress Controllers are often targeted by hackers, and many organizations don’t have a way of detecting insecure configurations. For example, in early 2025, multiple critical vulnerabilities related to “IngressNightmare” like CVE-2025-24514 or CVE-2025-1974, exposed ingress-nginx controllers to unauthenticated configuration injection. The flaw enabled attackers to potentially hijack backend services, compromise the entire cluster, or exfiltrate secrets…without triggering standard alerts. 

Another issue is troubleshooting. When problems like ingress latency, broken paths, or service not reachable occur, everyone is stuck working with incomplete data. This is why many Kubernetes issues still escalate to network teams. The complex layout of modern networks means engineers must use a mishmash of tools — CLI, YAML files, Prometheus, and logs — all of them disconnected. Each group has part of the picture, but no one has the whole thing.  

This all takes time! By my estimates, solving even basic Kubernetes issues involves 45–85 minutes of manual work. That’s $50-$100 worth of a K8s admin’s time. 

Troubleshooting as a Team 

There are two options for reducing this time and cost and making Kubernetes troubleshooting easier for all involved. The first is to use one of a small number of network management platforms that support Kubernetes. They will be able to map out Clusters, Nodes, Pods, Services, and Ingresses, as well as track application traffic as it moves through the network. Using these can shorten MTTR and help bridge DevOps silos. 

Or, Kubernetes admins can work out a process to gather information and then pass off issues to the NetOps or CloudOps team. Automating parts of this and getting everyone on the same page will help greatly. Here’s a rough breakdown of how this should work. 

1. Ticket comes in. 
2. Kubernetes admin runs kubectl commands to check pod status, logs, service configs. 
3. Locate and review YAML config files (keep in mind they may have errors or be out of date). 
4. Review relevant logs and dashboards. 
5. Look at dashboards from monitoring tools like Datadog or Prometheus and correlate with what you’ve found so far. 
6. Admin escalates to network or cloud teams with all the information they’ve gathered. 

As Kubernetes becomes a standard part of the infrastructure at more major enterprises, operations teams must adjust. I hope this gives some insight into how they interact with Kubernetes and how admins and developers can work with them.