As OCI Kubernetes Engine (OKE) continues to evolve, the networking requirements of our customers have grown increasingly sophisticated. What started as simple pod-to-pod communication has expanded into complex, multi-network environments requiring precise network isolation, advanced security policies, and granular traffic control.
Today, I’m excited to announce the limited availability of Generic VNIC Attachment (GVA) for OKE, a feature that fundamentally changes how you can configure and manage networking in your OKE clusters.
The Challenge: When One Size Doesn’t Fit All
Networking has always been foundational to Kubernetes infrastructure, but traditionally, managed Kubernetes services have taken an opinionated approach to network configuration. While this simplifies the getting-started experience, it can create significant challenges for enterprises with specific networking requirements.
In OKE’s current networking model, the configuration is prescriptive:
- With Flannel CNI, each node receives a single VNIC
- With VCN Native CNI, nodes get a primary VNIC for node traffic and one secondary VNIC for pod traffic, all with identical configurations
This rigid structure leaves little room for customization. You can’t select the number of VNICs that are allocated, you can’t configure VNICs differently from one another, and you have no control over which pods use which VNICs. For many workloads, this works perfectly fine. But for customers with advanced networking needs, this lack of flexibility has forced the development of custom scripts and complex workarounds.
Enter Generic VNIC Attachment
Generic VNIC Attachment puts you in control. Instead of accepting a one-size-fits-all networking model, GVA allows you to:
- Specify the number of and which VNICs to attach to your worker nodes and pods
- Configure VNIC properties individually, including the number of IPs, IP family, subnet, Network Security Groups (NSGs), and tags
- Schedule specific pods to specific VNICs using the new application Resource property
What Generic VNIC Attachment Enables
Generic VNIC Attachment addresses the real-world requirements we hear from customers every day:
Network Isolation
Attach VNICs from different networks to individual nodes for true network separation. This enables multiple teams or business units to share cluster infrastructure while maintaining complete network-level isolation.
Workload Specific Traffic Routing
Specify which VNIC handles your pod’s traffic (available with VCN Native CNI). Route production workloads through one set of VNICs with stringent security controls, while development or testing workloads use different network paths.
Flexible IP Allocation
Configure IP allocation on each VNIC to match your workload requirements. This provides tighter control in IP-constrained environments and helps prevent unnecessary IP consumption.
Granular Multi-VNIC Networking Control
Configure secondary VNIC properties independently on each worker node, giving you fine-grained control over how each interface is provisioned and used. This per-VNIC flexibility allows you to align each interface with the role it serves and choose the appropriate number of secondary VNICs for each node based on your networking design. On bare-metal worker nodes, this model extends even further, allowing you to take advantage of multiple physical network interface cards for additional throughput and architectural flexibility.
To optimize performance, select the network emulation mode that best matches your workload profile:
- VFIO for maximum throughput in high-performance scenarios
- E1000 (SR IOV) for hardware-accelerated performance with lower CPU overhead
- Paravirtualized for efficient virtualization in standard workloads
We designed this feature around the most frequent customer challenges, but Kubernetes continually uncovers new patterns and possibilities. I expect Generic VNIC Attachment will do the same, with its granular network control opening the door to architectures we have not even imagined yet.
Getting Started
Generic VNIC Attachment is available now in limited availability for OKE enhanced clusters. Here’s what you need to know:
Supported Configurations:
- Both managed and self-managed nodes
- Bare metal and virtual machine instances
- Clusters using VCN Native CNI (Flannel CNI support in the roadmap)
- All OCI regions and realms
Access Methods:
- OKE API
- SDK and CLI
Ready to try Generic VNIC Attachment? Reach out to your Oracle account team.
Learn more
Get started with OCI today with our Oracle Cloud Free Trial