This summer we returned with the Kubernetes Summer School series, guiding practitioners through four focused workshops on networking, observability, and traffic control with Cilium and the Isovalent Enterprise Platform. Each session combined a live lab with expert commentary, and the Q&A produced some excellent product-focused discussions. If you missed them live, the recordings and labs are available on demand. Below is a recap of what each session covered and the questions that stood out most. Session 1: Introducing the Isovalent Load Balancer This session opened the series by introducing the Isovalent Load Balancer, a cloud-native approach to service connectivity that uses eBPF and XDP in the Linux kernel for high-performance packet processing. Instead of relying on external hardware or cloud-specific appliances, Isovalent Load Balancer is software-defined offering that can be run as virtual appliances, as bare metal nodes, or as part of your existing Kubernetes clusters, providing both L4 and L7 capabilities managed by a familiar Kubernetes control plane. Attendees saw how Isovalent Load Balancer simplifies multi-environment deployments: it can advertise VIPs via BGP, support TLS passthrough, and integrate directly with Kubernetes Services. The hands-on lab walked through deploying the load balancer with T1 and T2 nodes, showing how traffic distribution and scale-out can be handled natively in Kubernetes without external dependencies. Top questions asked How does Isovalent Load Balancer compare with AWS or F5 load balancers?Isovalent Load Balancer isn’t an appliance or a cloud-specific service. It’s fully software-based and designed to run anywhere: in Kubernetes clusters, on VMs, or on bare metal. Where AWS and F5 load balancers are tied to their respective ecosystems, ILB is cloud-neutral and API-driven, with the added benefit that its configuration model is Kubernetes-native (CRDs, GitOps-ready) Is it fully software-based or tied to hardware? Isovalent Load Balancer is entirely software-based. It runs on commodity infrastructure and doesn’t require proprietary hardware. Scaling is horizontal: add more Tier 1 or Tier 2 nodes as needed. What are some of the key features Isovalent Load Balancer supports? Isovalent Load Balancer built to cover the core traffic management needs of modern platforms, from L4 speed to L7 intelligence. At the transport layer, it handles TCP and UDP with TLS offload and fastpath processing. At Layer 7, it supports HTTP, HTTPS, HTTP/2, gRPC, and Websockets, with routing decisions based on host headers, URI paths, or SNI. On the security side, ILB offers client authentication with mTLS or OIDC/JWT, flexible TLS policies with configurable ciphers and curves, and full support for TLS offload, passthrough, and re-encryption. For network reachability, Isovalent Load Balancer integrates with a rich BGP stack, including BFD for fast convergence and community support, so VIPs can be announced seamlessly into your environment. Do the backends need to be Kubernetes workload based or can they be any accessible network endpoint? Backends can be any reachable endpoint; Kubernetes pods, VM instances, physical servers, or even public cloud services. Isovalent Load Balancer’s LBBackendPool resources simply require an IP and port; they’re not tied to Kubernetes service discovery. Watch the session on-demand and also try with the Isovalent Load Balancer Lab today, and finally check out our deep dive blog post covering the load balancer architecture and packet-walk! Session 2: Gateway API in action The second session focused on the Gateway API, the successor to Kubernetes Ingress, designed to bring consistency and extensibility to service connectivity. With Cilium acting as the implementation, Gateway API enables routing decisions based on hostnames, headers, paths, or even protocols, while standardizing the API surface across different environments. The lab highlighted how teams can consolidate multiple ingress controllers into a unified Gateway API deployment. Features such as header-based routing, path matching, and external access were demonstrated, along with the operational benefits of using Envoy under the hood. Attendees saw how Gateway API integrates with Hubble for observability and how it reduces complexity compared to traditional ingress controllers. Top questions asked Do I need to enable the Kube-Proxy Replacement feature to enable Gateway API?Yes. To use the Cilium Gateway API, you must enable either NodePort mode (nodePort.enabled=true) or fully replace kube‑proxy by setting kubeProxyReplacement=true. Additionally, the L7 proxy (l7Proxy=true) must be enabled, although that’s the default configuration. How does it compare to Istio or Apache/Nginx reverse proxies? Cilium’s Gateway API implementation runs Envoy per node and ties it directly into the eBPF datapath. This means network policies are consistently enforced alongside routing decisions, giving both application-level control and kernel-level visibility. Unlike Istio or NGINX, there are no sidecars or iptables dependencies, which simplifies operations. For a deeper dive into the benefits of this model, see our blogs on modernizing ingress with Cilium Gateway API and advanced HTTP traffic control. Can traffic be routed while applying header modifications? Cilium’s Gateway API uses Envoy, which supports advanced HTTP features such as header rewriting, redirection, and mirroring, as shown in our blog post “Tutorial: Redirect, Rewrite, and Mirror HTTP with Cilium Gateway API” Can you support Blue/Green Deployment methodology with Gateway API? The Gateway API doesn’t include explicit Blue/Green deployment constructs, but you can achieve the pattern using Gateway API routing features like session persistence, header‑based routing, or path rewrites to direct traffic between service versions. Are regex path matches supported, and how are logical AND/OR conditions handled? Cilium supports regex path matching. In the context of Kubernetes Ingress, Cilium treats ImplementationSpecific path types as regex, and programs Envoy accordingly. That behavior extends to Gateway API setups using Envoy underneath. Within CiliumNetworkPolicy (L7 policy rules), you can also use extended POSIX regex on paths, headers, methods, etc., offering granular control over request matching. In CiliumNetworkPolicy expressions, multiple label keys within a single matchExpressions block are treated as logical AND. To express a logical OR across different keys, you must use multiple matchExpressions, each specifying its own key and values. Jump into watching Session 2 on-demand, and get hands-on with the Cilium Gateway API & Advanced Gateway API Use Cases labs Session 3: observability with Hubble Session three turned the spotlight to Hubble, Cilium’s observability layer that provides real-time visibility into all network flows. Using eBPF, Hubble captures data directly at the kernel level without sidecars, giving teams the ability to trace connections, enforce policies, and correlate flows with Kubernetes identities. The lab walked participants through visualizing flows, identifying dropped packets, and exploring how policy decisions are enforced. There was also a focus on tracing, showing how Hubble can be used alongside or compared with OpenTelemetry and distributed tracing systems like Jaeger or Tempo. This session was particularly valuable for anyone looking to combine observability and security in a Kubernetes-native way. Top questions asked What is the performance overhead of enabling Hubble? Enabling Hubble observability can introduce a performance overhead, typically we see this being only a small % of additional CPU usage, depending on the intensity of network traffic and event aggregation settings. To mitigate overhead, there is the capability to tune Cilium and Hubble to alleviate any impacts, such as adjusting the aggregation interval and rate limiting events. Isovalent customers can work with our customer success architects to help define a tuning strategy that works for their environments and use cases. How does Hubble tracing compare to tools like OpenTelemetry or Jaeger? How are trace IDs injected into applications? Hubble brings network-level visibility into the same world where application-level tracing tools like OpenTelemetry, Jaeger, or Grafana Tempo operate. While those frameworks focus on spans generated inside applications, Hubble adds the missing link: tracing data that comes directly from the network flows themselves. When applications are already emitting trace spans, Hubble can correlate those traces with detailed flow data, policy decisions, and connectivity insights from the datapath. This creates true end-to-end observability, where you can follow a request from the application code through to the underlying network behavior, and visualize it together in platforms such as Grafana Tempo. We wrote about these use-cases with examples in our Hubble Blog post series. Can I use the Hubble data in my other platforms such as splunk, grafana, and beyond? Hubble exposes metrics in Prometheus (OpenMetrics) format. You can enable hubble.metrics.enableOpenMetrics in the Helm chart, and Prometheus, or another similar tooling of your choice, can scrape Hubble metrics (including exemplars which contain trace IDs) if properly configured (see above). Hubble supports exporting flow logs via its Hubble Exporter, which can write logs to files with filtering and field masking capabilities. This allows external platforms; such as Splunk, ELK, or other log aggregation tools, to consume that data. Catch-up on how the observability layer provided by Cilium and Hubble provides real-time visibility and helps your application teams troubleshoot quicker with less instrumention! Dive into using Hubble Timescape for troubleshooting network connectivity and changes with Kubernetes Network Policies in our connectivity visibility hands-on lab. Session 4: Egress Gateway and Traffic Control The final session focused on Egress Gateway, a feature that allows precise control over outbound traffic from Kubernetes clusters. Rather than pods sending traffic with arbitrary node IPs, Egress Gateway ensures requests exit the cluster through defined nodes or IP ranges. This enables compliance, simplifies firewall integration, and provides consistency for external systems. Participants explored both open source and enterprise capabilities, including standalone deployment modes, IPv6 support, and integration with external policy engines. The lab demonstrated how to direct traffic through specific gateways, set up high availability, and understand trade-offs between dedicated nodes and standalone gateways. Top questions asked How can I configure Egress Gateway for high availability? Egress Gateway High Availability is a feature available in Isovalent Networking for Kubernetes, the enterprise-grade, hardened offering of Cilium. High availability is achieved by defining multiple gateway nodes in an IsovalentEgressGatewayPolicy. Cilium continuously probes these nodes for health and automatically removes any that become unavailable, ensuring traffic is redirected without disruption. Policies can limit the number of active gateways (maxGatewayNodes) to create hot-standby setups, distribute traffic across availability zones (azAffinity), or define egress IPs and interfaces explicitly. Additional safeguards such as socket termination prevent long-running connections from hanging if a gateway node fails. Together, these capabilities make it possible to build resilient egress paths that continue operating even during node outages or maintenance. How does it handle multi-VRF or data center boundary use cases? Egress Gateway supports advanced network topologies by tying pod traffic to specific, predictable IPs on designated gateway nodes. In multi-VRF or cross–data-center scenarios, this means you can configure gateway nodes with multiple interfaces and IPs sourced from secondary subnets or VRF-specific ranges. Traffic is then steered using Cilium policies while the underlying routing and isolation is enforced by the network fabric (for example, Cisco ACI ESGs or security groups). You can read about common design patterns such as advanced network topologies combined with Isovalent features in our design guide “Designing Isovalent Enterprise for Cisco ACI & Nexus” What is the benefit of standalone versus node-dedicated deployments? The difference lies in topology, scalability, and isolation: Node-dedicated gateways are part of the Kubernetes cluster. They run Cilium alongside workloads, making setup and upgrades straightforward since they follow the normal cluster lifecycle. This is the typical deployment mode when using Egress Gateway. Standalone gateways, available in Isovalent Networking for Kubernetes, introduced in the 1.17 release, are nodes outside the Kubernetes cluster, dedicated solely to egress traffic. This provides strong isolation and predictable performance, but upgrades must be managed separately from the cluster, which decouples the upgrades of Cilium within the cluster, and the Egress Gateway nodes. This distinction helps align your cluster architecture with operational priorities, whether that’s resource segregation or simplicity of management. Are IPv6 egressCIDRs supported, and can they be bound to specific interfaces? The egress gateway feature routes all IPv4 and IPv6 (from Cilium 1.18connections originating from pods and destined to specific cluster-external CIDRs. For interface binding, the gateway policy supports two approaches: using egressIP, where you choose a specific IP that is already assigned to a node interface, or using interface, where Cilium automatically selects the first IPv4 and IPv6 addresses from the specified interface as egress addresses How does it integrate with other policy systems like Kyverno? Whilst there are no direct integrations built for combination with policy systems such as Kyverno or OPA, users are able to build their own workflows, such as using Kyverno to validate or mutate Egress Policy objects. Catch up on the last summer school session on-demand, and learn how to address the challenges of oubound connectivity in Kubernetes. Load up our hands-on lab and test out the Egress Gateway capabilities with Isovalent Networking for Kubernetes yourself! If you are thinking about a wider traffic engineering and management scenario across your Kubernetes platform, we have just the eBook for you! "Kubernetes Traffic Engineering for Network Engineers: Cilium Best Practices" covers how to optimize traffic flow, enhance security, and boost performance with our 30+ page guide. Closing thoughts Kubernetes Summer School 2025 attracted more than a thousand registrants across four sessions. The labs gave practitioners real hands-on experience, while the Q&A highlighted the kinds of challenges teams face as they adopt modern Kubernetes networking. The feedback also showed us where the community wants to go next. Attendees asked for deeper dives into topics like Kubernetes Network Policies, multi-cluster networking, eBPF and XDP, advanced BGP, and how to integrate Cilium with cloud provider platforms or service meshes. Others expressed interest in seeing more around observability with Hubble, security features, production deployment practices, and detailed comparisons between open source Cilium and Isovalent Enterprise. We love this kind of feedback! It helps us continue to curate our content for the community as a whole, and whilst today I want to point everyone to our fantastic blogs and labs that cover a number of these areas already, I also can wait to see you at the next seasonal school series where we’ll definitely tackle some of these areas. I’ll sign off by reminding you, whether you are evaluating Cilium, already running it, or exploring the Isovalent Enterprise Platform for enterprise use cases, the recordings and labs remain available for you to dive in at your own pace.