It’s here: Project Antrea 1.0

Antrea delivers key advantages for Kubernetes: cluster-wide security policy, observability, and live traffic tracing with rich ecosystem support

Delivering on a major milestone with the 1.0 release, Antrea continues to add both new features to enhance Kubernetes-native networking and granularity and consistency in policy enforcement. Our latest feature release includes Egress policy, cluster-wide security policies, enhanced ecosystem support from Prometheus, ELK, and Octant, and live traffic tracing.

The integration with Antrea enables the following:

  • The Prometheus server can provide observations into the Antrea Controller and Agent components.
  • The Octant plugin can monitor components and trace packets in the UI
  • The ELK stack can provide visualization of the flow maps for the cluster network

Originally launched in November 2019, Project Antrea is a purpose-built Kubernetes networking solution for public and private clouds. It’s built on Open vSwitch, the open-source technology optimized for distributed, multi-layer switching performance. In a short span, Project Antrea has become feature-rich while gaining significant traction with contributions and interoperability support from both the user and the partner communities.

What are the key features in Project Antrea 1.0?

Cluster-wide Security Policies and Policy Tiering

Infrastructure and operations admins are broadly responsible for IT management; they want to implement unified control across their Kubernetes deployment along with the balance of technology, information and data. However, developers need their own control to define policies for the clusters they consume.

Both IT and developer objectives can be met when Antrea acts as the container networking interface. Antrea enables infrastructure operators to define global policies while providing flexibility for developers to define policies for their particular clusters.

Along with standard Kubernetes Network Policies, Antrea Cluster Network Policy (ACNP) and Antrea Network Policy (ANP) CRDs are now marked beta. They are enabled by default and deliver robust security functionality. The ACNP allows a cluster admin to define cluster-wide security policy. The ANP allows the admin to apply policies within a Namespace to complement Kubernetes Network Policies. Meanwhile, developers can continue using Network Policies for their apps.

A further possibility with Antrea is the option to group security policies as tiers. Multiple tiers with varying priorities can be created. This allows for a true production-grade security stance, where the admin defines cluster-level and Namespace-level security policies and developers can continue to define application-level security using standard Kubernetes Network Policies. Some other unique possibilities with Project Antrea include the ability to:

• Specify a different set endpoint to apply a rule;
• Define Cluster Groups that can be referenced by multiple policies;
• Implement traffic logging and traffic statistics at policy granularity;
• Reject action;
• Diagnose policy realization and extended matching criteria

Graphical user interfaceDescription automatically generated
Figure 1: Antrea NetworkPolicy Model

With multiple tiers and policies within each tier, Antrea allows more granular policies that can be enforced in a controlled order, recognizing different personas interacting with the cluster.

ChartDescription automatically generated with medium confidence
Figure 2: Antrea NetworkPolicy Eva

Egress policy

With Project Antrea, you can control the Egress Node and SNAT IP of Pod Egress Traffic (from Pod to External Network). This provides a deterministic way to calculate the SNAT IP, which can be used by external services to identify the source of the traffic.

Observability and diagnostics

The inherent scale and dynamism in Kubernetes workloads require visibility into the network flow. Antrea monitors the flows in a Linux conntrack module that provides rich flow data from Pod-to-Pod, Pod-to-Service and Pod-to-External, along with associated statistics such as data throughput, packet throughput and packet counts. Information like Node names, Pod names and Namespace name are added to the flow records. With the help of a Flow Aggregator, flows can be correlated between source and destination nodes to get visualization data. See a demo on flow visualization in action.

The Flow Aggregator and Flow Exporter use IPFix, allowing the flows the be consumed by any IPFix solution. The illustration below shows some of the flow data collected through Antrea.

FlowVisualization Network Policy Dashboard

Antrea also supports using Traceflow for network diagnosis: it generates tracing requests for traffic in the data plane by OVS flows that are generated by antrea-agent. In addition, live traffic between Pods can be traced. Traceflow is a powerful tool for troubleshooting, and when combined with flow data, provides a wealth of information to ascertain network policy, routing and encapsulation effects on traffic performance between pods. Not only can the Traceflow data be viewed directly via CRD status, Antrea can also be integrated with the Octant plugin to view Traceflow results through a trace graph.

Show Failing Trace

Third-party ecosystem enhancements

Antrea supports running in Windows worker Nodes — by setting up an overlay network to forward packets between nodes — and implements Network Policies. Using transparent mode in the Host Networking Service (HNS), containers are directly connected to the physical network through an external Hyper-V switch. Antrea also extends its Traceflow support to Windows nodes. Watch a video demonstration showcasing the Traceflow feature and Antrea-native policies for Linux and Windows nodes.

One of the goals of Project Antrea is to be able to run anywhere Kubernetes runs including on-premises and public clouds. Antrea can also run on AWS EKS cluster, Azure AKS cluster and Google GKE clusters.

Starting with release 1.0, Antrea Docker images for both arm/v7 and arm64 architectures are available.

Overlay Encap modes and encryption

Project Antrea allows for different overlay encapsulation modes, and it includes GRE, GENEVE, VXLAN, and STT tunnel types. Encap mode is enabled by default: Pod traffic across Nodes is encapsulated and sent over the chosen tunnel type. In cases where encapsulation is not desired, or if double encapsulation is not needed, Antrea allows for a noEncap mode. In this case Antrea relies on the Node network to route traffic. Project Antrea also allows for a Hybrid mode, in which Pod traffic is not encapsulated when the source and destination Nodes are on the same subnet. In addition, Project Antrea supports encrypting tunnel traffic for much more secure Node traffic communication.

Project Antrea release 1.0 is a robust CNI that meets the requirements for a flexible, scalable and agile Kubernetes network and security infrastructure. Antrea supports both IPv4 and IPv6/dual-stack traffic essential for most telco workloads. As a feature-rich, production-ready CNI, there is no better time to try Antrea.



Get involved:

Join the Kubernetes Slack and look for the #antrea channel

Attend Antrea Community Meetings every two weeks on Tuesday at 5AM UTC (9PM PDT, 6AM CET, 10.30AM IST, 1PM China)

@ProjectAntrea on Twitter

VMware Container Networking with Antrea. Enterprise Support from VMware.


Leave a Reply

Your email address will not be published.