xinshuyang / antrea Goto Github PK

View Code? Open in Web Editor NEW

This project forked from antrea-io/antrea

0.0 1.0 4.0 69.26 MB

Kubernetes networking based on Open vSwitch

Home Page: https://antrea.io

License: Apache License 2.0

Makefile 0.26% Shell 4.63% Go 94.13% Dockerfile 0.14% HCL 0.05% PowerShell 0.60% Smarty 0.05% Jinja 0.09% Python 0.04%

antrea's Introduction

Antrea

Overview

Antrea is a Kubernetes networking solution intended to be Kubernetes native. It operates at Layer 3/4 to provide networking and security services for a Kubernetes cluster, leveraging Open vSwitch as the networking data plane.

Open vSwitch is a widely adopted high-performance programmable virtual switch; Antrea leverages it to implement Pod networking and security features. For instance, Open vSwitch enables Antrea to implement Kubernetes Network Policies in a very efficient manner.

Prerequisites

Antrea has been tested with Kubernetes clusters running version 1.19 or later.

NodeIPAMController must be enabled in the Kubernetes cluster.
When deploying a cluster with kubeadm the --pod-network-cidr <cidr> option must be specified. Alternately, NodeIPAM feature of Antrea Controller should be enabled and configured.
Open vSwitch kernel module must be present on every Kubernetes node.

Getting Started

Getting started with Antrea is very simple, and takes only a few minutes. See how it's done in the Getting started document.

Contributing

The Antrea community welcomes new contributors. We are waiting for your PRs!

Before contributing, please get familiar with our Code of Conduct.
Check out the Antrea Contributor Guide for information about setting up your development environment and our contribution workflow.
Learn about Antrea's Architecture and Design. Your feedback is more than welcome!
Check out Open Issues.
Join the Antrea community and ask us any question you may have.

Community

Join the Kubernetes Slack and look for our #antrea channel.
Check the Antrea Team Calendar and join the developer and user communities!
- The Antrea community meeting, every two weeks on Tuesday at 5AM GMT+1 (United Kingdom time). See Antrea team calendar for localized times.
  - Meeting minutes
  - Meeting recordings
- Antrea live office hours archives.
Join our mailing lists to always stay up-to-date with Antrea development:
- projectantrea-announce for important project announcements.
- projectantrea for updates about Antrea or provide feedback.
- projectantrea-dev to participate in discussions on Antrea development.

Also check out @ProjectAntrea on Twitter!

Features

Kubernetes-native: Antrea follows best practices to extend the Kubernetes APIs and provide familiar abstractions to users, while also leveraging Kubernetes libraries in its own implementation.
Powered by Open vSwitch: Antrea relies on Open vSwitch to implement all networking functions, including Kubernetes Service load-balancing, and to enable hardware offloading in order to support the most demanding workloads.
Run everywhere: Run Antrea in private clouds, public clouds and on bare metal, and select the appropriate traffic mode (with or without overlay) based on your infrastructure and use case.
Comprehensive policy model: Antrea provides a comprehensive network policy model, which builds upon Kubernetes Network Policies with new features such as policy tiering, rule priorities, cluster-level policies, and Node policies. Refer to the Antrea Network Policy documentation for a full list of features.
Windows Node support: Thanks to the portability of Open vSwitch, Antrea can use the same data plane implementation on both Linux and Windows Kubernetes Nodes.
Multi-cluster networking: Federate multiple Kubernetes clusters and benefit from a unified data plane (including multi-cluster Services) and a unified security posture. Refer to the Antrea Multi-cluster documentation to get started.
Troubleshooting and monitoring tools: Antrea comes with CLI and UI tools which provide visibility and diagnostics capabilities (packet tracing, policy analysis, flow inspection). It exposes Prometheus metrics and supports exporting network flow information to collectors and analyzers.
Network observability and analytics: Antrea + Theia enable fine-grained visibility into the communication among Kubernetes workloads. Theia provides visualization for Antrea network flows in Grafana dashboards, and recommends Network Policies to secure the workloads.
Network Policies for virtual machines: Antrea-native policies can be enforced on non-Kubernetes Nodes including VMs and baremetal servers. Project Nephe implements security policies for VMs across clouds, leveraging Antrea-native policies.
Encryption: Encryption of inter-Node Pod traffic with IPsec or WireGuard tunnels.
Easy deployment: Antrea is deployed by applying a single YAML manifest file.

To explore more Antrea features and their usage, check the Getting started document and user guides in the Antrea documentation folder. Refer to the Changelogs for a detailed list of features introduced for each version release.

Adopters

For a list of Antrea Adopters, please refer to ADOPTERS.md.

Roadmap

We are adding features very quickly to Antrea. Check out the list of features we are considering on our Roadmap page. Feel free to throw your ideas in!

License

Antrea is licensed under the Apache License, version 2.0

antrea's People

Contributors

Watchers

Forkers

contfire zgy0817 johnzhao2023 contenfire2

antrea's Issues

I want to set a SDN controller for br-int, but I can't find br-int

Describe what you are trying to do
A description of what you are trying to achieve, what you have tried so far and the issues you are facing.
Hi, I want to use an OvS-based network plugin for my k8s cluster so that I can use an SDN controller to control all OvS and realize Service Function Chain forwarding. I have deployed a k8s cluster(v1.16.1 with 1 master node and 1 work node), and applied Antrea (v0.1.1) on the master node. And both node is in Ready status.
My question is: How to find the OvS on the work node and set my SDN controller.

test failed due to pull rate limit issue from docker

Describe the bug
When triggering IPv6 CI tests frequently, pulling docker images could result in a rate limit issue.

To Reproduce
Trigger ipv6 related tests frequently.

Expected
Image should be pulled normally.

Actual behavior
Successfully built e94b32f7fe96
Successfully tagged antrea/openvswitch-debs:antrea-v1.10
Sending build context to Docker daemon 24.06kB

Step 1/11 : FROM ubuntu:22.04 as ovs-debs
toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Additional context
Pulling related images from harbor should be supported to avoid rate limit problem.

Random Failures When Unpacking Antrea Image on Windows Testbed

Describe the bug
Describe the bug
When attempting to unpack the Antrea Windows image docker.io/antrea/antrea-windows:latest, I encountered the following error randomly:

unpacking docker.io/antrea/antrea-windows:latest (sha256:9b3c707aabd24d5190afedcd6e6301aa7ffd65a21488550d1b8b771a5c5d7cbb)...
time="2023-10-31T22:55:35-07:00" level=info msg="apply failure, attempting cleanup" error="failed to extract layer sha256:30baeec5d6941292f9e7d22617d5d707b32016e8f936fb75184fa135ac3238bd: hcsshim::ImportLayer failed in Win32: The system cannot find the path specified. (0x3): unknown" key="extract-995477400--Seg sha256:07085b3fdcb4afbf8907934ab6b2483733f12ed6050e5616d44cb9b21d08aaaf"
time="2023-10-31T22:55:37-07:00" level=warning msg="extraction snapshot removal failed" error="snapshot extract-995477400--Seg sha256:07085b3fdcb4afbf8907934ab6b2483733f12ed6050e5616d44cb9b21d08aaaf does not exist: not found" key="extract-995477400--Seg sha256:07085b3fdcb4afbf8907934ab6b2483733f12ed6050e5616d44cb9b21d08aaaf"

To Reproduce
Windows CI pipeline error

Test iisue

Describe the problem/challenge you have

Describe the solution you'd like

Anything else you would like to add?

Random Failures When Unpacking Antrea Image on Windows Testbed

Describe the bug
When attempting to unpack the Antrea Windows image docker.io/antrea/antrea-windows:latest, I encountered the following error randomly:

unpacking docker.io/antrea/antrea-windows:latest (sha256:9b3c707aabd24d5190afedcd6e6301aa7ffd65a21488550d1b8b771a5c5d7cbb)...
time="2023-10-31T22:55:35-07:00" level=info msg="apply failure, attempting cleanup" error="failed to extract layer sha256:30baeec5d6941292f9e7d22617d5d707b32016e8f936fb75184fa135ac3238bd: hcsshim::ImportLayer failed in Win32: The system cannot find the path specified. (0x3): unknown" key="extract-995477400--Seg sha256:07085b3fdcb4afbf8907934ab6b2483733f12ed6050e5616d44cb9b21d08aaaf"
time="2023-10-31T22:55:37-07:00" level=warning msg="extraction snapshot removal failed" error="snapshot extract-995477400--Seg sha256:07085b3fdcb4afbf8907934ab6b2483733f12ed6050e5616d44cb9b21d08aaaf does not exist: not found" key="extract-995477400--Seg sha256:07085b3fdcb4afbf8907934ab6b2483733f12ed6050e5616d44cb9b21d08aaaf"
ctr: failed to extract layer sha256:30baeec5d6941292f9e7d22617d5d707b32016e8f936fb75184fa135ac3238bd: hcsshim::ImportLayer failed in Win32: The system cannot find the path specified. (0x3): unknown

To Reproduce
Windows CI pipeline error

Improve NodePortLocal unit test coverage

We can improve the unit test from below two parts for both linux and windows.

[iptable_rule.go]
[netnat_rule.go]

loadBalancerSourceRanges not supported in AntreaProxy

Describe the bug

As of now antrea doesnt support loadBalancerSourceRanges in the antreaProxy. Since this is also not supported in the kube-proxy, we have no way to provdide this to Windows users.

To Reproduce

Similar to kubernetes/kubernetes#120033 ...

Expected

AntreaProxy would fully support the Kubernetes service spec...

Actual behavior

LoadbalancerSourceRanges that are outside of an packet's IP are allowed into antrea clusters where antreaproxy is used.

Note this isnt a HUGE bug b/c alas, even the windows service proxy doesnt yet implement this

QUESTION:

Could this be done by reusing HNS packet filtering from the HNS ACLs ? Or does it require OVS?

aclPolicy := hns.ACLPolicy{
	Type:            hns.ACL,
	Action:          hns.Block,
	Direction:       hns.In,
	RemoteAddresses: loadBalancerSourceRanges
}
```?

Long-Term Tracking of Testbed Kubernetes Versions

Describe the problem/challenge you have
Currently, we are using various testbeds such as CAPV, Multicast, Multicluster, VMAgent, Kind, and Windows for Antrea CI pipeline. The Kubernetes versions used in these testbeds may not always align with the latest Kubernetes releases. This misalignment can lead to issues, test failures, or missed opportunities to take advantage of new Kubernetes features.

Describe the solution you'd like
We would like to create a long-term tracking mechanism to keep our testbed Kubernetes versions up to date. This involves the following steps:

Maintain a record of the current Kubernetes version in use for each testbed.
Periodically check for new Kubernetes releases.
Plan and execute the upgrade of Kubernetes versions for each testbed as needed.
Document the process, any issues encountered, and the outcome.

Anything else you would like to add?
It's essential to maintain our testbeds with the latest Kubernetes versions to align with the Kubernetes releases and to provide the best quality testing for Antrea. This long-term tracking task can help us stay on top of Kubernetes updates and ensure our testing environment remains robust and effective.

Testbed Name	Current Kubernetes Version	Latest Kubernetes Version (if different)
CAPV	v1.28.0	v1.28.3
Multicast	v1.27.2	v1.28.3
Flexible-IPAM	v1.27.1	v1.28.3
Multicluster	v1.27.1	v1.28.3
VMAgent	v1.27.2	v1.28.3
IPv6	v1.27.1	v1.28.3
Windows	v1.28.2(with ginkgo flaky issue)	v1.28.3