Tigera Logo

Guides: KubeVirt

Complete Guide to KubeVirt: Features, Architecture, and Security

What Is KubeVirt?

KubeVirt is an open-source project that extends Kubernetes by adding virtual machine (VM) management capabilities on top of container orchestration. By integrating virtualization workloads alongside container workloads, KubeVirt allows IT teams to run and manage both VMs and containers using standard Kubernetes primitives, APIs, and workflow patterns.

This approach bridges the divide between cloud-native container applications and traditional VM-based workloads, making it simpler for organizations to adopt Kubernetes without leaving existing applications behind. KubeVirt leverages the underlying Kubernetes infrastructure, meaning organizations can benefit from Kubernetes scheduling, scalability, and operational consistency while also supporting legacy applications that require virtualization.

KubeVirt works within a Kubernetes cluster, making the transition between virtualization and containerization smoother for both operators and developers. Its design philosophy emphasizes minimal disruption, aiming to modernize infrastructure at an incremental pace.

This is part of an extensive series of guides about Kubernetes.

In this article:

Why KubeVirt Matters in Modern Cloud Native Infrastructure

Unified Management of VMs and Containers

KubeVirt treats virtual machines as Kubernetes resources, enabling administrators and developers to manage them using the same tools, APIs, and workflows they use for containers. VMs are defined with custom resource definitions (CRDs), scheduled with Kubernetes controllers, and monitored through standard observability tools.

Declarative, Infrastructure-as-Code VM Management

With KubeVirt, VMs are described in YAML manifests just like other Kubernetes resources. This declarative model allows infrastructure to be versioned, reviewed, and managed as code. VM specifications include CPU, memory, disk, and network interfaces, along with boot order and cloud-init scripts.

Consistency Across Environments

KubeVirt helps standardize environments across development, testing, and production by enabling consistent deployment models for both VMs and containers. This is especially valuable in hybrid or edge scenarios where certain workloads require virtualization due to hardware dependencies or legacy constraints.

Leverages Kubernetes Ecosystem

KubeVirt is designed to integrate seamlessly with the broader Kubernetes ecosystem. It works with existing tools such as Prometheus for monitoring, Istio or other service meshes for networking, and OpenShift or Rancher for enterprise management. This compatibility allows teams to extend VM capabilities with features like autoscaling, logging, and RBAC.

Because KubeVirt runs VMs inside Kubernetes pods, the same container security practices used for traditional workloads—image scanning, runtime protection, network policy, and least-privilege RBAC—apply directly to virtualized workloads as well.

Cost Optimization and Simplified Infrastructure Footprint

Running VMs and containers on the same Kubernetes cluster reduces infrastructure sprawl. Organizations can consolidate workloads onto fewer platforms, improving resource utilization and cutting operational costs. By avoiding separate virtualization stacks, teams reduce licensing fees, management overhead, and hardware requirements.

Enhanced Automation and Scheduling

KubeVirt leverages Kubernetes’ native scheduling and automation capabilities, enabling fine-grained control over where and how VMs run. This includes affinity rules, taints and tolerations, and resource quotas, which allow for intelligent placement and efficient use of cluster resources.

Key KubeVirt Features

KubeVirt includes a set of features that make it possible to run and manage virtual machines using the same declarative, API-driven approach used for containers in Kubernetes. These features ensure VM workloads are first-class citizens within the Kubernetes ecosystem.

  • VM as a custom resource: Virtual machines in KubeVirt are defined using Kubernetes custom resources (CRDs). This allows VMs to be created, managed, and versioned declaratively, similar to other Kubernetes objects.
  • Integration with Kubernetes scheduler: KubeVirt uses the native Kubernetes scheduler to place VMs based on resource requirements, node availability, and affinity rules, ensuring consistent scheduling across containers and VMs.
  • Live migration support: KubeVirt supports live migration of VMs across nodes, allowing workloads to move with minimal downtime during maintenance or scaling operations.
  • Persistent storage support: KubeVirt integrates with Kubernetes storage classes and CSI drivers to provide persistent storage to VMs, enabling support for stateful workloads.
  • Network configuration: KubeVirt supports multiple networking models, including bridge and masquerade modes. It integrates with Kubernetes CNI plugins to enable networking consistency across pods and VMs.
  • Cloud-init and user data injection: Initialization data can be injected into VMs using cloud-init or custom user data, allowing automation of configuration and bootstrapping tasks.
  • VM snapshot and restore: The platform supports creating snapshots of VMs for backup and restore operations, helping with data protection and recovery scenarios.
  • Monitoring and observability: KubeVirt exposes metrics through Prometheus-compatible endpoints, enabling detailed monitoring and alerting for VM lifecycle events and resource usage.
  • RBAC and namespace isolation: KubeVirt leverages Kubernetes-native role-based access control and namespace isolation to enforce security and multi-tenancy policies for VM resources.

Related content: Read our guide to KubeVirt live migration

KubeVirt Use Cases

Legacy VM Workload Modernization

Many organizations have business-critical applications that remain locked into traditional virtualization platforms, often due to operating system dependencies or software vendor support requirements. KubeVirt enables these workloads to migrate from dedicated hypervisor environments into Kubernetes clusters, allowing organizations to consolidate infrastructure management.

Teams can maintain legacy applications in their existing VM formats but operate them through the same Kubernetes workflows used for newer containerized services. This modernization approach does not force a rip-and-replace migration, which can be costly and risky. Instead, KubeVirt lets IT teams bring VMs under the same umbrella as their containerized workloads.

Mixed VM and Container Workloads

Certain business solutions demand integration between VM-based and containerized services, especially when dealing with proprietary software, legacy databases, or tightly-coupled system components. With KubeVirt, organizations can orchestrate both workload types within the same Kubernetes cluster. This enables new cloud-native microservices to interact directly with legacy VMs, fostering predictable integration patterns and simplifying inter-process communication.

Such mixed environments make it easier to adopt cloud-native strategies without rewriting entire application stacks. Developers can incrementally containerize parts of an application while retaining others as VMs, running both side-by-side and leveraging shared infrastructure. Kubernetes-native networking and storage support mean consistent policies are enforceable, making operational management and security more straightforward across disparate workloads.

Dev/Test and Environment Parity

Development and testing environments frequently experience configuration drift and parity issues, leading to bugs or failures in production. KubeVirt enables the recreation of production environments, including legacy VMs and modern containers, within developer and QA clusters. This uniformity ensures that testing and validation occur against the same combinations of OS versions, middleware, and runtime dependencies as in the production environment.

By offering Kubernetes-based automation for provisioning both VMs and containers, KubeVirt reduces manual intervention and makes CI/CD processes more robust. Teams can automate spin-up and teardown of complex environments, making development, staging, and testing processes efficient and reliable.

Core Architecture and Components of KubeVirt

KubeVirt is built on a layered, service-oriented architecture that integrates tightly with Kubernetes while introducing components to support virtualization. It follows a choreography pattern where components operate in coordination, rather than being centrally controlled. This design allows virtualization workloads to be managed similarly to native Kubernetes workloads.

KubeVirt relies on the existing Kubernetes stack: scheduling, container runtime, and orchestration. Above this, KubeVirt adds its own API and virtualization services. The core idea is to treat virtual machines as first-class Kubernetes objects using custom resource definitions (CRDs). This lets users manage VMs the same way they manage pods: declaratively and through standard Kubernetes APIs.

To implement this functionality, KubeVirt introduces three critical layers:

  1. Custom resource definitions (CRDs): These define new Kubernetes object types, such as VirtualMachine, VirtualMachineInstance (VMI), and VirtualMachineInstanceReplicaSet. These CRDs let users describe VM workloads in a familiar Kubernetes format.
  2. Controllers: These run as Kubernetes pods and manage the lifecycle of VM resources across the cluster. The primary controller is virt-controller, which watches for new or updated VM-related resources and coordinates actions like scheduling or deletion.
  3. Node-level daemons: The virt-handler runs on each node and manages VM lifecycle operations locally. It works alongside the Kubernetes kubelet, launching and monitoring VMIs to ensure they match the declared state. The actual VM process runs inside a virt-launcher pod, and the KVM hypervisor is used underneath.

Together, these components allow VM workloads to be scheduled, started, and monitored using the Kubernetes control plane. Networking, storage, and scheduling are delegated to Kubernetes-native systems (like CNI plugins and CSI drivers), ensuring consistency across both VMs and containers.

High-level management is handled through the VirtualMachine resource, which wraps a VirtualMachineInstance and adds features like start/stop control, offline configuration changes, and lifecycle tracking. This makes the VM management experience closer to Kubernetes StatefulSets, offering stability and persistence when needed.

All KubeVirt components: controllers, daemons, and the virtualization stack are deployed as Kubernetes-managed pods, making the solution fully self-contained within the cluster. This design ensures KubeVirt respects existing security models: users managing VMs do not gain any additional privileges beyond those they already have for managing containers.

Additional Services and Integrations

Networking Integrations for VM-to-Pod Communication

KubeVirt uses Kubernetes-native networking through Container Network Interface (CNI) plugins to provide connectivity between VMs, pods, and external networks. Each virtual machine instance (VMI) gets its own pod network interface, typically bridged into the cluster network. This allows seamless communication between VMs and pods using standard Kubernetes service discovery and DNS.

KubeVirt supports advanced networking features through integrations with projects like Multus CNI, which enables multiple interfaces per VMI. This is useful for scenarios like separating management and data traffic or supporting SR-IOV for high-performance networking. By relying on Kubernetes CNI and compatible plugins, KubeVirt ensures that network policies, service meshes, and traffic control mechanisms apply consistently to containers and virtual machines.

Security, Observability, and Policy Ecosystem Integrations

KubeVirt integrates with Kubernetes-native security tools and models, ensuring VM workloads adhere to the same RBAC, PodSecurityPolicies (or newer replacements like Pod Security Standards), and admission controllers as containers. VMs can be isolated at the pod level using namespaces, network policies, and runtime constraints. Since VMs run inside pods, Kubernetes-level controls like seccomp profiles, SELinux labels, and AppArmor also apply.

For observability, KubeVirt exposes metrics through Prometheus-compatible endpoints and integrates with logging systems like Fluentd and Loki. VMI events and lifecycle logs can be collected using standard Kubernetes tooling, allowing unified visibility across workload types.

KubeVirt also supports audit trails and integrates with Kubernetes-native policy engines like Gatekeeper (OPA) to enforce governance rules on VM specifications. This helps enforce compliance and operational standards without requiring separate tooling for VM management.

Learn more in our detailed guide to KubeVirt architecture

Network and Security Challenges in KubeVirt

Networking Complexity Across Pods and VMs

Managing networking for mixed workloads adds complexity due to differences in how containers and VMs handle network interfaces and protocols. While containers often rely on simple overlay networks and pod-to-pod communication models, VMs typically expect direct interfaces and traditional L2/L3 networking.

KubeVirt abstracts VM networking using Kubernetes pod networks, but mapping these expectations without breaking existing services can be challenging. For example, ensuring DHCP, static IPs, or legacy L2 protocols work as expected in a CNI-based environment requires careful plugin selection and configuration.

Multi-Tenancy and Microsegmentation Challenges

While Kubernetes supports basic multi-tenancy through namespaces and RBAC, adding VMs introduces new layers of complexity. VM workloads might carry higher sensitivity, run legacy OSes with weaker controls, or require segmentation that goes beyond typical pod-level isolation.

KubeVirt supports Kubernetes network policies, but enforcing fine-grained microsegmentation across VM and pod traffic often demands enhanced CNI features or service mesh integration. Handling scenarios like tenant isolation, dedicated network interfaces per VM, or VLAN tagging may require Multus, SR-IOV, or external firewalls. These solutions increase operational overhead and often require deep networking knowledge.

Ensuring Consistent Security Posture Across Mixed Workloads

KubeVirt enables VMs to run in pods, inheriting many Kubernetes-native security controls. However, ensuring VMs follow the same security baseline as containers isn’t automatic. Containers benefit from modern runtime protections, regular base image scanning, and tight syscall control via seccomp. VMs, on the other hand, may run outdated OSes, expose unused services, or lack hardening.

Aligning security postures requires integrating VM lifecycle controls with existing security pipelines. This includes image scanning for VM disk images, enforcing runtime constraints via AppArmor/SELinux, and ensuring cloud-init scripts don’t bypass security policies. Without proper tooling, visibility gaps and inconsistent enforcement can emerge.

Need for Deep Observability into VM and Pod Traffic

Unified monitoring across VM and pod traffic is critical for troubleshooting and performance tuning, but also difficult to achieve. While container observability tools are well-integrated with Kubernetes (e.g., Prometheus, Grafana, OpenTelemetry), VMs introduce a separate layer with potentially different logging and metric formats.

KubeVirt helps bridge this gap by exposing metrics for VM lifecycle events and resource usage, but deep traffic inspection (like flow-level analysis, packet captures, or latency tracing across VM-pod boundaries) often requires external tools. Achieving parity in observability between VMs and containers remains an ongoing challenge.

Managing Compliance, Audits, and Threat Detection

VM workloads often fall under stricter compliance regimes due to legacy system requirements or data handling regulations. Ensuring auditability and traceability for VMs managed through KubeVirt requires extending Kubernetes’ existing audit pipelines to capture VM events, cloud-init actions, image provenance, and runtime behaviors.

Integrating with Kubernetes-native policy engines like OPA Gatekeeper can enforce rules on VM definitions, but deeper controls (like OS-level auditing, configuration drift detection, or malware scanning) require separate security agents inside the VMs.

Cross-Cluster or Hybrid Cluster/VM Mobility

Live migration of VMs within a cluster is supported by KubeVirt, but moving VMs across clusters, or between Kubernetes and traditional virtualization platforms, remains complex. Cross-cluster mobility is limited by differences in storage backends, network configurations, and persistent volume availability.

Achieving hybrid portability (e.g., moving a VM from KubeVirt to VMware or vice versa) requires standardized disk formats, compatible cloud-init configurations, and coordinated infrastructure between environments. Without robust orchestration layers, this mobility is typically manual and error-prone, complicating DR, scaling, or edge deployments that span multiple zones or clouds.

Tutorial: Getting Started with KubeVirt

This tutorial walks through deploying KubeVirt locally with kind and managing virtual machines using Kubernetes-native tooling. Instructions are adapted from the Kubevirt documentation.

Step 1: Set Up a Local Kubernetes Cluster With kind

First, install kubectl and kind using their official instructions. Then, create your local Kubernetes cluster:

kind create cluster

This starts a local cluster using Docker containers.

Step 2: Deploy KubeVirt

Deploy the KubeVirt Operator and custom resource:

export VERSION=$(curl -s https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt)
kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml"

kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml"

If nested virtualization is not supported (common in VMs), enable emulation:

kubectl -n kubevirt patch kubevirt kubevirt --type=merge --patch '{"spec":{"configuration":{"developerConfiguration":{"useEmulation":true}}}}'

Step 3: Verify KubeVirt Installation

Check if the deployment succeeded:

kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.phase}"
kubectl get all -n kubevirt

Step 4: Install virtctl

virtctl is a CLI for VM operations like start, stop, and console access.

Install it:

VERSION=$(kubectl get kubevirt.kubevirt.io/kubevirt -n kubevirt -o=jsonpath="{.status.observedKubeVirtVersion}")
ARCH=$(uname -s | tr A-Z a-z)-$(uname -m | sed 's/x86_64/amd64/')
curl -L -o virtctl https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/virtctl-${VERSION}-${ARCH}
sudo install -m 0755 virtctl /usr/local/bin

Alternatively, install it as a kubectl plugin using krew:

kubectl krew install virt

Step 5: Create and Run a Virtual Machine

Download and apply a simple VM manifest:

wget https://kubevirt.io/labs/manifests/vm.yaml
kubectl apply -f vm.yaml

Start the VM:

virtctl start testvm

Check the instance:

kubectl get vmis

Access its console:

virtctl console testvm

Exit the console using Ctrl + ].

To stop or delete the VM:

virtctl stop testvm
kubectl delete vm testvm

Best Practices for Using KubeVirt

Here are some useful practices to consider when working with KubeVirt.

1. Design for Scalability and Performance

When architecting KubeVirt clusters, design for scalability by choosing nodes with sufficient CPU, memory, and storage throughput to accommodate both VMs and containers under peak load. Leverage Kubernetes node pools to assign dedicated resources to VM-heavy workloads, and utilize horizontal scaling to handle surges in demand.

Monitor resource consumption closely using Kubernetes metrics and adjust cluster sizing and autoscaling rules accordingly to maintain performance and availability. Performance tuning should include optimizing hypervisor overhead, scheduling affinity, and network policies specific to VM traffic. Use dedicated storage classes for VM workloads and enable features like CPU pinning and NUMA-aware scheduling.

2. Standardize VM Templates and Storage Classes

Creating and maintaining standardized VM templates guarantees consistency across deployments and simplifies troubleshooting. Define base VM images and common configuration patterns (CPU, memory, network interfaces) as Kubernetes custom resources or leverage existing community images vetted for production use.

Implement version control and regular updates for these templates to incorporate security patches and changes in organizational standards. Storage classes should be chosen to meet the performance and durability requirements of your VMs, whether using local disks, NFS, or cloud block storage. Clearly document and apply storage class choices per use case to guarantee predictable IOPS and latency.

3. Secure Networking Between VMs and Pods

Networking in KubeVirt clusters should be designed with segmentation, encryption, and policy enforcement in mind. Use Kubernetes CNI plugins that support advanced NetworkPolicy constructs to restrict communication between VMs, pods, and external networks. Implement firewalls and security groups at both the Kubernetes and VM layers, and consider overlay networks for stronger traffic isolation where needed.

Beyond segmentation, encrypt traffic between nodes (including VM-to-VM and VM-to-pod connections) using mutual TLS or similar mechanisms. This protects sensitive data against interception or tampering within the cluster. Periodically audit network policies and update them as services evolve, ensuring only required ports and protocols remain exposed.

4. Implement Unified Network Policy for Mixed Workloads

To maintain consistent security across KubeVirt environments, implement unified network policies that apply to both VMs and pods. Native Kubernetes NetworkPolicy resources only govern pod traffic, leaving VMs without the same level of enforcement unless additional tools are introduced. To close this gap, use CNI plugins or network security platforms that extend identity-aware policy controls to VM interfaces.

Standardize on labels and namespaces across both VM and pod resources to ensure policy selectors remain effective and maintainable. Define ingress and egress rules in a centralized manner, avoiding separate policies for different workload types. This unified approach simplifies policy management, reduces human error, and ensures all east-west and north-south traffic is subject to the same governance framework.

Where possible, integrate VM metadata (such as VM labels or service ownership) into the network policy engine. This enables more granular control, supports dynamic workloads, and aligns policy enforcement with organizational boundaries or compliance requirements.

5. Address Observability and Auditing Gaps

VMs often introduce blind spots in Kubernetes observability workflows due to differences in how traffic, metrics, and logs are exposed. To bridge this gap, extend your observability stack to include VM-level insights alongside container metrics. Use exporters and agents that run inside VMs to forward system metrics, or leverage hypervisor telemetry provided by KubeVirt and the underlying node.

Ensure all workloads—VMs and pods—generate consistent logs and expose relevant metrics to Prometheus-compatible endpoints. Normalize log formats and labels to streamline aggregation and correlation in systems like Loki, ELK, or Splunk.

On the auditing side, collect Kubernetes audit logs and enrich them with VM-specific lifecycle events such as creation, migration, or snapshotting. This combined audit trail supports security investigations, compliance validation, and operational forensics across the full spectrum of workloads.

6. VM Identity and MicroSegmentation

Establishing workload identity is crucial for enforcing security in mixed environments. While Kubernetes service accounts and pod labels are standard for container identity, VMs require similar mechanisms to integrate into policy engines. Assign labels and annotations to VM resources, and, where possible, integrate external identity providers (e.g., LDAP, Kerberos) to align VM identity with organizational systems.

Use these identities to implement microsegmentation: enforce strict, least-privilege communication rules between individual workloads. Leverage network policy engines that support identity-based segmentation across VM and container interfaces. This prevents lateral movement, contains breaches, and ensures that each workload can only access the services it explicitly needs.

Microsegmentation policies should be declarative, version-controlled, and monitored for drift or violations. Regularly review and refine identity mappings to account for evolving workloads and organizational structure.

7. Automate Deployments with GitOps

GitOps practices allow you to declaratively manage VM and container infrastructure, driving reproducible environments from source control. Define VM manifests, storage resources, and network policies as code, stored in version-controlled repositories. Deploy changes via automated pipelines that synchronize cluster state with the repository, using tools like Argo CD or Flux for observability and rollback capabilities.

Automation minimizes manual errors, accelerates recovery from misconfigurations, and standardizes the deployment process across teams. GitOps approaches also provide a clear change history, making audits and troubleshooting easier.

8. Monitor and Audit Continuously

Continuous monitoring is vital for detecting issues, tuning performance, and maintaining security in KubeVirt clusters. Leverage Kubernetes-native observability tools like Prometheus, Grafana, or OpenTelemetry to aggregate and visualize real-time metrics for both VMs and containers. Integrate logs and events into centralized solutions (such as ELK stacks or cloud logging services) for detailed forensics and trend analysis.

Additionally, implement automated auditing to track configuration changes, access, and policy enforcement across all workloads. Combine Kubernetes audit logs with hypervisor-level analytics to ensure compliance and early detection of anomalous activity. Regular reviews of monitoring and audit data help satisfy security standards and operational SLAs.

Evaluation Criteria for KubeVirt Networking and Security Solutions

Support for Both Pod and VM Workloads (Networking + Policy)

A comprehensive KubeVirt networking and security solution must enforce consistent policies across both pods and virtual machines. This includes support for standard Kubernetes NetworkPolicy resources and extensions that enable enforcement on VM interfaces. Tools should recognize and operate on VM-level metadata, such as labels and namespaces, in the same way they do for pods.

Solutions that rely solely on pod identity will leave VMs unmanaged or only partially covered. To be effective, the solution must support CNI plugins or overlays that expose and control VM interfaces, apply ingress and egress rules, and integrate with service discovery across both workload types.

Zero Trust / Microsegmentation Capabilities

Solutions should implement identity-aware policies that enforce strict communication boundaries between workloads, regardless of whether they are VMs or containers. This includes support for microsegmentation using workload identity, namespaces, and label selectors.

Capabilities like dynamic policy enforcement, automatic identity assignment, and support for encryption in transit (e.g., mutual TLS) are essential to implementing zero trust architectures. The system must ensure that policy enforcement is not bypassable by VM-specific behavior and that rules are verifiable and audit-ready.

Real-Time Observability of VM and Pod Flows

Deep visibility into traffic flows between VMs and pods is critical for performance tuning, debugging, and security monitoring. The solution should offer flow-level insights, connection tracing, and packet-level visibility across the full workload spectrum.

Observability tools must correlate VM activity with Kubernetes-native telemetry. Integration with Prometheus, OpenTelemetry, and flow collectors (e.g., eBPF-based tools) ensures consistent monitoring. The ability to visualize VM and pod interactions in real time is vital for detecting bottlenecks, misconfigurations, and anomalous behavior.

Threat Detection and Anomaly Identification

Security tooling must detect suspicious activity in both container and VM workloads. This includes behavior analysis, signature-based intrusion detection, and anomaly detection based on baseline profiles.

Solutions should ingest audit logs, flow records, and system-level telemetry from both workload types. Support for workload-aware threat intelligence( correlating events across pods and VMs) is key. Runtime protection (e.g., syscall filtering, process monitoring) should extend to VMs through guest agents or hypervisor-level hooks.

Multi-Cluster and Hybrid-Cloud Support

Networking and security solutions should work across multiple Kubernetes clusters and support hybrid environments that include both on-prem and cloud infrastructure. This includes federated policy management, cross-cluster service discovery, and secure communication between VMs and pods across environments.

Solutions must support consistent network identity and policy enforcement across clusters, regardless of workload type. This is especially important in edge and disaster recovery scenarios, where VMs may need to migrate or replicate between clusters while maintaining security posture.

Compliance Reporting and Auditability

Organizations need detailed, actionable logs and reports to demonstrate compliance with industry standards (e.g., PCI-DSS, HIPAA). Solutions must capture VM and pod lifecycle events, policy changes, and access logs in a centralized, tamper-proof audit trail.

Integration with Kubernetes audit logs, KubeVirt events, and external log collectors is essential. The system should support exporting compliance reports and allow custom rule definitions to enforce internal governance policies across all workloads.

Performance and Scalability for VM Workloads

Networking and security layers must scale without degrading VM performance. The solution should handle high-throughput traffic, large numbers of VMs, and concurrent policy evaluations without introducing bottlenecks.

Support for CPU pinning, SR-IOV, DPDK, and NUMA-aware scheduling is important for low-latency or high-bandwidth VM applications. Networking infrastructure must be tested and validated for VM-specific workloads, especially in scenarios involving live migration, large stateful services, or sustained heavy traffic.

See Additional Guides on Key Kubernetes Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of Kubernetes.

Container Security

Authored by Tigera

Kubernetes Networking

Authored by Tigera

Kubernetes Security

Authored by Tigera

X