Running Kubernetes networking at scale works best when everyday operations are predictable. Platform teams need routing that reflects the approved fabric design, policy decisions they can explain, egress behaviour that survives node and agent changes, and observability that connects a flow back to the policy and process behind it. Isovalent Networking for Kubernetes 1.19 focuses on that day-two operating model. Policy-controlled BGP route import makes learned routes explicit. IsovalentNetworkPolicy tiers and pass verdicts give platform and application teams a clearer policy model. FQDN HA offline mode keeps DNS-derived policy state available during agent restarts. Selective encryption makes plaintext exceptions visible in policy. Hubble Timescape becomes the supported UI path for flow investigation, policy editing, and process context. Kube-Proxy Replacement and netkit continue their path toward becoming the expected baseline for more environments. Network policy gains Kubernetes ClusterNetworkPolicy support, while Isovalent Network Policy adds tiers and pass verdicts for layered guardrails. BGP route import and connected-route advertisement expand how clusters participate in existing routing fabrics. FQDN HA offline mode improves resilience for name-based egress policy. Hubble Timescape gives teams a more capable place to investigate flows, policy, process context, and multicast traffic. Whether this is your next upgrade or your first look at Isovalent Networking for Kubernetes, read 1.19 as a release about production habits. The details matter because they touch the parts of Kubernetes networking that usually decide whether a platform feels predictable under pressure: service handling, routing, policy, DNS-aware egress, encryption, and observability. The question running through the release is simple: how much of that day-two work can become easier to standardise, easier to verify, and easier to troubleshoot? Highlights at a glance Connectivity and datapath Policy-controlled BGP route import: Cilium can be configured to deny incoming BGP routes and imports only the prefixes configured in the new IsovalentBGPPolicy. Advertise local interface addresses over BGP: Interface advertisements publish selected routable /32 or /128 addresses, such as an address assigned to lo, to BGP peers. Egress Gateway HA graduates to stable maturity: Egress Gateway now provides Gateway selection, health, Egress IP advertisement, locality-aware steering, and connection drain, to support your egress connectivity requirements. Kube-Proxy Replacement and netkit continue to mature: Both features continue hardening in 1.19 ahead of becoming enabled by default in 1.20, (with fallback validations in place). Network Policy and DNS resilience Policy tiers, pass verdicts, and ordering: IsovalentNetworkPolicy expresses platform-owned guardrails and team-owned rules with deterministic evaluation order and explicit IngressPass and EgressPass delegation. CIDR Groups at scale: Shared CIDR definitions cut duplication across policy libraries and stay performant when the same external ranges show up everywhere. FQDN HA offline mode: The DNS HA proxy keeps writing IP-to-identity mappings into the BPF ipcache while cilium-agent restarts, so toFQDNs policy keeps enforcing through maintenance windows. Selective encryption with WireGuard: A default-encrypt posture with explicit plaintextPeers exemptions, backed by a regeneration fence that keeps the BPF policy map consistent across agent restarts. Observability and investigation Hubble Timescape UI improvements: with Hubble UI Enterprise now deprecated. CEL-based query support for Timescape visualization: Build filters with dropdowns, then refine in CEL. Edit the CEL and the controls update. Policy editor enhancements: improved historical compare functionality. Flows Table is linked to policy context. Support for new Cilium Network Policy Features, including Cluster wide policies, enable default deny, policy log. Process ancestry provided by Isovalent Runtime Security: Support to visualize and trace historical Process ancestry logs with search capabilities. OpenShift operator support: new operator deployment model for Timescape for Red Hat OpenShift platforms. Platform delivery and operations Authenticated image delivery: Software artifacts to be made available via new authenticated Isovalent Registry. Connectivity: making the datapath easier to standardise The connectivity updates in INK 1.19 are about reducing variation across clusters. Many customers already run Kube-Proxy Replacement, BGP, Egress Gateway, or advanced datapath options in production. The release does not change that history. It gives platform teams more confidence to turn proven patterns into standard build guidance. BGP: fitting Kubernetes into the routing fabric BGP remains one of the places where Kubernetes meets the rest of the network most directly. In self-managed Kubernetes environments, platform teams often need clusters to participate in existing data centre routing rather than hide behind a single ingress or load balancer pattern. INK 1.19 adds two BGP capabilities that help with that integration: route import and connected-route advertisement. Policy-Controlled BGP Route Import Most Kubernetes clusters sit inside a larger routing design. Operators need to know what the cluster advertises out to the fabric, which routes it is allowed to learn back, who approved those routes, and whether the running state matches the intended design. Without an explicit import policy, learned routes can become part of the cluster routing table simply because a peer advertised them. Without a Kubernetes-native way to express that policy, each change depends on manual coordination between the platform and network teams. INK 1.19 answers that with an explicit model. Route import keeps a default deny policy when no import policy is referenced. Operators define the approved prefixes and communities in an IsovalentBGPPolicy, then attach that policy to the relevant peer configuration. Enable route import through the enterprise BGP control plane Helm values enterprise.bgpControlPlane.routeImport.enabled=true. The example below rejects blackhole routes, accepts a bounded IPv4 range, and accepts routes carrying a specific community. Attach that policy to the relevant peer family with importPolicyRef: The peer config is then referenced from IsovalentBGPClusterConfig for the relevant node selector and peer. Network teams who use communities to encode routing intent get a richer model than a flat prefix list. Standard and large BGP community matching, Or, And, and Not match types, and explicit Accept and Reject actions are all expressible. See a live example of BGP Route Import feature in the recording below Interface advertisements Interface advertisements publish selected local interface IPs to BGP peers. Use them when the fabric needs a stable, per-node address that is already assigned to an interface. A minimal advertisement looks like this: With an address such as 1.2.3.4/32 assigned to lo, Cilium can advertise that local interface address to the configured BGP peers. Together, policy-controlled route import and interface advertisement make Cilium fit more naturally into routing designs that already exist outside the cluster. Network teams keep familiar BGP patterns, while platform teams express the cluster side through Kubernetes APIs. Watch the technical walk-through of this new BGP feature. Kube-Proxy Replacement as a standard cluster choice Kube-Proxy Replacement uses Cilium's eBPF datapath to implement Kubernetes service handling without kube-proxy and its iptables or IPVS rules. That matters because kube-proxy is responsible for translating Kubernetes Services to the pods behind them. In a busy cluster, that service table changes constantly as pods start, stop, scale, and move between nodes. The traditional kube-proxy model keeps that translation in a separate component, often backed by long chains of iptables rules. Cilium's model keeps service load balancing in the same eBPF datapath that already handles policy enforcement, routing decisions, and Hubble visibility. In kube-proxy-free mode, Cilium handles ClusterIP, NodePort, LoadBalancer, services with external IPs, and HostPort through its eBPF service load-balancing implementation. This is why Kube-Proxy Replacement is more than a component swap. It is the path that lets Cilium take full responsibility for service handling, including socket-level load balancing, direct service translation in the datapath, observability around service-to-backend translation, and advanced load-balancing options such as DSR, hybrid forwarding, XDP acceleration, and Maglev where those modes fit the environment. In 1.19, the practical question is whether kube-proxy still needs to be part of the cluster design. If there is a technical constraint, keep it in the upgrade plan and validate the supported path. If there is not, this is the release to test Cilium's service load-balancing path deliberately: map the service types you rely on, compare behaviour before and after the change, and make Kube-Proxy Replacement part of your standard cluster build criteria. netkit: Moving The Pod Datapath Forward Netkit is the next container networking device path for Cilium. Traditional Kubernetes networking attaches a pod to the host through a veth pair, effectively a virtual Ethernet cable between namespaces. That model works, but it carries Layer 2 and ARP overhead and can push traffic through parts of the host networking stack that add latency under pressure. Netkit replaces that veth pair with a newer Linux device that is built for BPF-driven networking. Cilium can attach BPF programs directly to the pod-side path, make forwarding decisions earlier, run in L3 mode by default, and avoid unnecessary ARP work. The practical goal is simple: bring pod networking much closer to host-network performance while keeping Cilium in control of the datapath programs that enforce policy and routing behaviour. In 1.19, the focus is rollout confidence. This release carries the packet headroom that encapsulation, policy enforcement, and L7 redirects need through the daemon and CNI configuration, tightens L7 redirect behaviour on the netkit path, and adds a startup check that fails fast if restored endpoints do not match the configured datapath mode. Netkit is planned to become the default datapath mode for new cluster installations in Isovalent Networking for Kubernetes 1.20, with an automatic option to fall back to veth when the platform does not support netkit. Network policy: guardrails for the platform, flexibility for teams Network policy in INK 1.19 moves in two useful directions at once. It aligns more closely with upstream Kubernetes policy APIs, and it keeps the Cilium capabilities that teams use for segmentation for their mission critical applications. Kubernetes ClusterNetworkPolicy support INK 1.19 supports Kubernetes ClusterNetworkPolicy, the active upstream Network Policy API direction for cluster-wide policy. Earlier upstream admin and baseline policy work has evolved into ClusterNetworkPolicy, which combines those concepts into a single resource with tiered evaluation. ClusterNetworkPolicy lets platform and security teams define cluster-wide guardrails while application teams continue using namespace-scoped policies. It introduces Admin and Baseline tiers, plus a Pass action that delegates evaluation to the next tier. This is not a reason to make every policy design more complex. Many customers can keep using Cilium network policies and or even standard Kubernetes NetworkPolicy for day-to-day segmentation. ClusterNetworkPolicy matters most where teams are using Kubernetes Network Policies in their environment, and need explicit cluster-wide guardrails, multi-tenant isolation, if you need a migration path from policy models that already rely on ordered tiers, then Isovalent policy tiers and pass verdict In the 1.19 release, the Isovalent policy model defines Admin, Normal, and Baseline tiers. IsovalentClusterwideNetworkPolicy can use every tier, including Admin; namespaced IsovalentNetworkPolicy is restricted to Normal and Baseline. Tier order determines which layer evaluates first, while policy order determines precedence within that tier. An Admin tier in a IsovalentClusterwideNetworkPolicy can enforce platform-wide decisions and use a pass rule to delegate selected traffic to the next tier. Security teams retain control of the early guardrail layer, while application teams can own workload-specific IsovalentNetworkPolicy rules in the Normal tier. This is especially relevant for customers migrating from policy systems with tiered rule models, including Calico-style policy designs. For simpler environments, the right answer may still be standard NetworkPolicy plus Cilium or Isovalent policy where extra expressiveness is needed. The tier field sets the evaluation layer and order to control precedence within it. ingressPass and egressPass select traffic without allowing or denying it, skip the remaining lower-priority policies in the current tier, and resume evaluation in the next tier. A platform team can therefore place an IsovalentClusterwideNetworkPolicy in Admin, then hand selected traffic to a team-owned, namespaced IsovalentNetworkPolicy in the Normal tier. The example below applies that model to a payments workload. It matches traffic from the frontend and to the orders service, then passes those matches to the next tier instead of making the final allow or deny decision in this policy. A pass verdict is neither an allow nor a deny. If no policy in a later tier selects the traffic, the configured policy-enforcement mode determines the result. The application team that owns the payments service can add the expected allow rule in a namespaced IsovalentNetworkPolicy in the Normal tier: See this new feature in action as Dean Lewis walks through a live example in the below recording. CIDR Groups and port ranges CIDR Groups help policy authors avoid repeating the same long lists of external CIDRs across many policies. Define the group once, reference it from policy, and update the group when an external provider changes its ranges. Policies can then select that group by name or label instead of repeating the same CIDRs in every rule. This example allows traffic from the partner ranges into the selected workload: When a partner changes its ranges, the platform team updates one CIDR Group. Application policies keep the same labelled reference. Port ranges through the upstream Kubernetes endPort field solve a similar maintainability problem. Instead of enumerating a large contiguous range, policy can express intent directly: L7 HTTP policy and WebSocket support In INK 1.19, we add support for WebSocket connections through L7 HTTP policy. Teams can apply source identity, port, method, and path rules to the HTTP request that opens the connection. A WebSocket session starts with an HTTP GET request. The client then asks the server to upgrade that request into a long-lived, bidirectional connection. An L7 proxy has to recognise and pass the upgrade for the WebSocket session to begin. INK 1.19 configures Envoy to handle this upgrade on the L7 policy path. The opening request still has to match policy; after the server accepts it, Envoy passes the upgraded connection to the application. WebSocket upgrade support is available by default, with no WebSocket-specific CNI setting or policy resource to configure. This policy allows web-frontend pods in the realtime namespace to open GET /ws on the websocket-api workload over TCP port 8080: In this example, only web-frontend pods in the same namespace can send GET /ws to the websocket-api workload on port 8080. The policy controls the opening HTTP request, not individual WebSocket messages. A normal HTTP request matching GET /ws is also allowed. For wss://, Cilium must be able to see the HTTP handshake to match the method and path. Terminate TLS before the enforcement point or configure TLS interception. WebSocket sessions can stay open much longer than ordinary HTTP requests. Envoy's default stream idle timeout is 300 seconds, so applications need keepalives or a different timeout for quiet connections that must remain open longer. DNS-Aware Egress: Keeping Name-Based Policy Stable During Maintenance Name-based egress policy is one of the most useful enterprise policy patterns because applications often depend on external services identified by DNS names, not static IP addresses. The operational challenge is that Cilium needs DNS-derived state to enforce those policies correctly. During maintenance, restarts, or temporary resolver problems, that state must remain available enough for the policy engine to keep doing the right thing. FQDN HA offline mode improves that path. It allows the DNS proxy side of the workflow to continue preserving DNS responses while the Cilium agent is unavailable, then replay the required state once the agent is ready again. For teams that rely on toFQDNs policy, this reduces the chance that routine maintenance turns into either an enforcement gap or an application connectivity incident. Selective Encryption Encryption is only useful if operators can describe, in one sentence, when traffic is encrypted and what happens at the edges. Selective encryption lays that out clearly. WireGuard transparent encryption provides the datapath, and policy defines which peers should use it. Two operating modes cover most needs: default-encrypt, where pod-to-pod traffic is encrypted unless a plaintextPeers rule exempts it, and opt-in, where only traffic selected by policy is encrypted. A common use case is a default-encrypted cluster with a small number of approved plaintext exceptions. For example, a platform team may require encryption for normal application-to-application traffic, while allowing a specific workload path to remain plaintext for a legacy appliance, packet inspection point, or performance-sensitive integration that has been reviewed separately. In that model, encryption stays on by default and the exception is captured in policy rather than hidden in a node or application configuration. This is configured in the values for Isovalent Networking for Kubernetes as per the example: fallbackBehavior: encrypt keeps the default posture conservative: traffic remains encrypted unless policy finds a more specific plaintext exception. plaintextPeers is where those approved exceptions live, so operators can review which peers are intentionally allowed to bypass encryption. On agent restart, the encryption policy BPF map is recreated behind a regeneration fence, so endpoint regeneration waits for the reconciler to repopulate the map before forwarding resumes. Lookups perform forward and reverse longest-prefix matches and pick the more specific entry. In a tie, encrypt wins. We’ve prepared a technical walk-through recording, showing this new feature in action, diving into configuration, through to proving which workloads traffic is plaintext sent across the cluster. Hubble Timescape Configuration is only the beginning. Once a service cannot reach a dependency, or a policy change starts dropping traffic, teams need the history around the event: the flow, the verdict, the policy version, the Kubernetes change, and, where available, the process context behind the connection. For this release, we’ve refreshed one of our most popular labs “Isovalent Enterprise: Connectivity Visibility with Hubble Timescape”. Take the lab today and get hands on with the latest Hubble Timescape 1.19 release and the updates we detail below Make the Query Unfold Like a Trail of Evidence The Flow page moves to a CEL-based filtering model. Common filters such as cluster, namespace, and verdict (and other common fields) are still available through UI controls, but the underlying query is an expression that can be edited, reused, and extended. That matters because real troubleshooting rarely stops at one field. A platform engineer starts with a namespace, narrows to dropped traffic, adds a time range, then asks whether the same pattern appears for a specific workload label or destination CIDR. The examples below show the kind of investigation pattern this enables: one expression can combine Kubernetes context, network verdict, and flow fields. Let’s see this feature in action, as Dean shows you the new filter selectors, and advanced CEL query capabilities; Policy Editor Enhancements The policy editor view in Timescape receives several important updates in this release, with a focus on the troubleshooting workflows shared by application and platform teams. Policy authoring, review, and traffic evidence now sit closer together, helping teams move from observed behaviour to safer, more explainable network policy changes. The policies homepage has now been simplified with a quick view option, ability to quickly download the latest active policy applied to your kubernetes cluster. Clicking the Pencil icon of an existing policy takes you into a dedicated editor window, where you will find a number of new features. To cover the many enhancements in this release, Dean Lewis has created a technical runthrough video to show these in action. Here is a summary of those enhancements: Creating a new policy, you can select CiliumNetworkPolicy or CiliumClusterwideNetworkPolicy When editing policies, you can download the policy to YAML or copy directly to clipboard In Policy diff mode (the ability to check changes between different policy changes), the policy editor is read-only, exit this mode via the time selector Add log field to policy; introduced in Cilium OSS 1.18, a new key/value pair, log:value was added to Cilium Network Policies, that places a plain text log field into Hubble flow verdict outputs. When editing an existing network policy, change network policy between CiliumNetworkPolicy or CiliumClusterwideNetworkPolicy Support for EnableDefaultDeny|ingress/egress Support for Deny Policies In the last of our technical recordings for this release, Dean shows you all the latest enhancements in Hubble Timescape 1.19 Policy editor: Return of the Process Ancestry Process tree support brings Tetragon-derived process context back into the Timescape investigation surface, so an operator can inspect the process model behind a connection and decide whether it matches expected application behaviour. That is useful for unexpected outbound traffic, late-running debug sessions, and application behaviour that looks normal at the Service level but odd at the process level. To access this level of detail, users can navigate their nodes and workload objects in both the “Explorer” and “Enforcement Points” views in Timescape. When the process tree is opened up, historical logs (Purple arrow, captured from Isovalent Runtime Security) can be browsed. Each snapshot shows an object tree of processes running on the Kubernetes node, that are expandable for manual browsing using breadcrumbs. Alternatively, users can search (red arrow) captured process information, with results showing both workload objects and domain name information for traffic flows. Returned results for search queries will also use coloured breadcrumbs linked to the object tree. Connections are marked as: Inner - Reserved IPs (127.0.0.0/8, 192.0.0.0/24, etc, see all), DNS starting with ip- ending with .internal or ending with .svc.cluster.local Outer - External (outbound/inbound to cluster) Kubernetes - Traffic that transits within Kubernetes cluster OpenShift Operator for Timescape Deployment In 1.19, we have released a Red Hat OpenShift Operator for the deployment of Hubble Timescape supporting all deployment modes (Integrated Timescape remains deployed as part of the Cilium OpenShift operator). This aligns with the Red Hat OpenShift lifecycle operations model for deployments of platform components. The operator deploys Timescape through a TimescapeConfig resource. Corresponding chart values remain available under spec, so OpenShift teams can manage the deployment declaratively and still see the underlying chart settings. The following minimal Lite configuration shows the TimescapeConfig resource shape. Standalone and multi-cluster deployments use the same resource with the topology-specific values documented for those paths. Platform updates: image delivery, AI infrastructure, and GitOps Availability through the authenticated Isovalent Registry For Isovalent customers, Isovalent Networking for Kubernetes 1.19 is available from the new authenticated Isovalent Registry. Authentication and image-pull instructions are in the enterprise documentation and customers can also work with Isovalent Customer Success when planning the registry change. A common networking foundation for AI infrastructure AI clusters expand across clouds and bare metal as new GPU capacity comes online. Kubernetes still needs consistent IPAM, service connectivity, network policy, and troubleshooting across those environments. The OpenAI customer story is one example. OpenAI uses Isovalent Networking for Kubernetes as its default Kubernetes networking stack across multiple environments and platforms, with a common CNI and IPAM foundation, L4/L7 policy, and Hubble flow visibility. As GPU capacity moves or expands, that shared stack avoids a separate Kubernetes networking design for each environment. A recent Cisco perspective on OpenAI and AI infrastructure describes AI workloads moving while their IP addresses change. Isovalent Networking for Kubernetes keeps policy tied to workload identity and gives operators the flow records needed to investigate that traffic. From tickets to governed pull requests Our recent From Tickets to Pull Requests: Running Cilium in a GitOps Platform article and companion lab apply GitOps to INK configuration. Application teams propose routes and network policies through Git, while platform teams retain ownership of shared infrastructure and guardrails. The lab follows a change from pull request to runtime: isopolicy analyses selected changes in CI, Kyverno applies admission controls, Argo CD reconciles the approved state and can correct drift when self-heal is enabled, Cilium enforces policy, and Hubble Timescape verifies the result. Summary Isovalent Networking for Kubernetes 1.19 gives platform teams a network design they can carry across cluster builds. BGP routes are imported only when policy accepts them, egress paths have explicit selection and health controls, policy ownership follows defined tiers, and encryption exceptions are declared. When traffic does not behave as expected, Timescape connects the flow to the policy decision and process behind it. BGP peers, external dependencies, policy ownership, and upgrade constraints differ between environments. Isovalent works with customers to fit these controls to their infrastructure, backed by tested enterprise releases and support from the engineers who build Cilium.