- Container Networking with Antrea 1.3.2 is based off the Antrea v1.2.4 open-source release
- Support for VXLAN and Geneve (*) when IPSec is enabled
- (*): VXLAN can be used if the Linux Kernel version of the Node is recent enough
- antctl now uses less memory when collecting support bundle
- Ability to collect partial support bundle when some Nodes fail to respond
- Antrea-agent can now work with distros that lack the iptables kernel module of "legacy" mode (ip_tables) with the help of iptables-wrapper
- Use uplink MAC as source MAC when transmitting packets to underlay network from Windows Nodes. With this change, "Forged transmits" in VMware vSphere doesn't need to be enabled
- Egress feature and Antrea-Interworking are configured to use different ports allowing both features to be used together
Compatibility Testing Matrix
| K8S Distribution | K8S Versions | OS | Encapsulation |
| K8s | 1.18, 1.19, 1.20, 1.21 | Ubuntu 18.04, PhotonOS 3, Debian10, Photon OS3 | Geneve, NoEncap, Hybrid |
| AWS EKS | 1.17 | Amazon Linux 2 | Policy Only Mode |
| Azure AKS, AKS Engine | 1.18 | Ubuntu 18.04 | Policy Only Mode |
| GKE (Google Kubernetes Engine) | 1.18 | Ubuntu 18.04, Windows | NoEncap, Policy Only Mode |
| OpenShift | OCP 4.7 & 4.8 | RHCOS and RHEL | Geneve, NoEncap, Hybrid |
Change Logs 1.2.4 - 2022-04-29
Includes all the changes from 1.2.4
Changed
- Use iptables-wrapper in Antrea container. Now antrea-agent can work with distros that lack the iptables kernel module of "legacy" mode (ip_tables). (#3276, @antoninbas)
- Reduce permissions of Antrea ServiceAccount for updating annotations. (#3393, @tnqn)
- [Windows] Use uplink MAC as source MAC when transmitting packets to underlay network from Windows Nodes. Therefore, MAC address spoofing configuration like "Forged transmits" in VMware vSphere doesn't need to be enabled. (#3516, @wenyingd)
Fixed
- Fix DNS resolution error of antrea-agent on AKS by using ClusterFirst dnsPolicy. (#3701, @tnqn)
- Fix status report of Antrea-native policies with multiple rules that have different AppliedTo. (#3074, @tnqn)
- Upgrade Go version to 1.17 to pick up security fix for CVE-2021-44716. (#3189, @antoninbas)
- Fix NetworkPolicy resources dump for Agent's supportbundle. (#3083, @antoninbas)
- Fix ClusterGroup realization status (#3030, @dyanngg)
- Fix gateway interface MTU configuration error on Windows. (#3043, @lzhecheng) [Windows]
- Fix initialization error of antrea-agent on Windows by specifying hostname explicitly in VMSwitch commands. (#3169, @XinShuYang) [Windows]
- Ensure that the Windows Node name obtained from the environment or from hostname is converted to lower-case. (#2672, @shettyg) [Windows]
- Fix typos in the example YAML in antrea-network-policy doc. (#3079#3092, @antoninbas@Jexf)
- Fix ipBlock referenced in nested ClusterGroup not processed correctly. (#3383, @Dyanngg)
- Fix NetworkPolicy may not be enforced correctly after restarting a Node. (#3467, @tnqn)
- Fix antrea-agent crash caused by interface detection in AKS/EKS with NetworkPolicyOnly mode. (#3219, @wenyingd)
- Fix locally generated packets from Node net namespace might be SNATed mistakenly when Egress is enabled. (#3430, @tnqn)
- Images
Antrea to NSX Integration
- projects.registry.vmware.com/antreainterworking/interworking-debian:0.2.1
- projects.registry.vmware.com/antreainterworking/interworking-ubuntu:0.2.1
- projects.registry.vmware.com/antreainterworking/interworking-photon:0.2.1
- Antrea
- projects.registry.vmware.com/antreainterworking/antrea-ubi:v1.2.4_vmware.1
- projects.registry.vmware.com/antreainterworking/antrea-standard-debian:v1.2.4_vmware.1
- projects.registry.vmware.com/antreainterworking/antrea-advanced-debian:v1.2.4_vmware.1
- Antrea Operator
- projects.registry.vmware.com/antreainterworking/antrea-operator:vmware-1.2.4
Known Issues
Container Network Traffic Throughput Drops to Zero on Buggy Physical NIC
Antrea enables Geneve tunnel checksum offload by default. However, sometimes the container networking traffic throughput drop to nearly zero. In packet capture we see that TCP 3-way handshake is successful but the first data packet in MTU size gets wrong checksum and it's dropped in the receiver side. This can happen when the K8s node VMs are running on overlay network and the underlay network cannot correctly process checksum offloading in double encapsulation scenario, or the physical NIC has bug in checksum offloading.
Workaround:
We introduced the following ConfigMap antrea-agent-tweaker-g56hc6fh8t in antrea.yml to allow disabling tunnel checksum offloading.
apiVersion: v1
data:
antrea-agent-tweaker.conf: |-
# Enable disableUdpTunnelOffload will disable udp tunnel offloading feature on kubernetes node's default interface.
# By default, no actions will be taken.
disableUdpTunnelOffload: false
kind: ConfigMap
metadata:
labels:
app: antrea
name: antrea-agent-tweaker-g56hc6fh8t
namespace: kube-systemThis is only for Linux. You can use kubectl to edit the live ConfigMap on K8s API to disable tunnel checksum offload, then restart all Antrea agents (usually run the command kubectl delete pod -l component=antrea-agent -n kube-system) to make the option effective. You can also edit this ConfigMap in antrea.yml before deploying Antrea.We suggest not to set it to true only if you hit tunnel checksum offloading issue. Disabling tunnel checksum offloading drops container networking throughput by about 50%.
Realization of Network Policies takes longer after upgrade to 1.3.0-1.2.2 with large number (10,000+) of Antrea-Network Policy Custom Resources.
When Antrea is upgraded to 1.3.0-1.2.2 from an older release (1.2.0-0.13.x or older), Antrea controller automatically mirrors Antrea Network Policy to new API group 'antrea.io'. So when a large number of ANP CRs are present, the Antrea Network policies are enforced slowly as the ANP CR is being mirrored to the new API. This is observed with more than 10,000+ ANPs.
Workaround:
Manually mirror old API group to new API group before upgrade.
- Create the new CRDs of tiers.crd.antrea.io, networkpolicies.crd.antrea.io, clusternetworkpolicies.crd.antrea.io, clustergroups.crd.antrea.io. The CRDs can be fetched from the manifest yaml that you will use for upgrade.
- Dump the resources of the deprecated CRDs (with *.antrea.tanzu.vmware.com suffix), create the same resources with new CRDs (with *.antrea.io suffix):
kubectl get tiers.security.antrea.tanzu.vmware.com -o yaml -A | sed "s/security.antrea.tanzu.vmware.com/crd.antrea.io/g" |kubectl apply -f -
kubectl get networkpolicies.security.antrea.tanzu.vmware.com -o yaml -A | sed "s/security.antrea.tanzu.vmware.com/crd.antrea.io/g" | kubectl apply -f -
kubectl get clusternetworkpolicies.security.antrea.tanzu.vmware.com -o yaml -A | sed "s/security.antrea.tanzu.vmware.com/crd.antrea.io/g" | kubectl apply -f -
kubectl get clustergroups.core.antrea.tanzu.vmware.com -o yaml -A | sed "s/core.antrea.tanzu.vmware.com/crd.antrea.io/g" | kubectl apply -f -Note, if there are no resources for a CRD, the command will get an error output "error: no objects passed to apply", which can be ignored.
