-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update ROADMAP #5807
Update ROADMAP #5807
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,73 +8,118 @@ not listed now does not mean it will not be considered for Antrea. We definitely | |
welcome suggestions and ideas from everyone about the roadmap and Antrea | ||
features. Reach us through Issues, Slack and / or Google Group! | ||
|
||
## Planned Features | ||
|
||
The following features are considered for the near future: | ||
|
||
* **Windows support improvements** | ||
Antrea [supports Windows K8s Node](docs/windows.md) since version 0.7.0. | ||
However, a few features including: Egress, NodePortLocal, IPsec encryption are | ||
not supported for Windows Node yet. We will continue to add more features for | ||
Windows, and improve Antrea Agent and OVS installation on Windows Nodes. | ||
|
||
* **Antrea NetworkPolicy enhancements** | ||
Antrea added support for [Antrea-native policies](docs/antrea-network-policy.md) | ||
in addition to K8s NetworkPolicy since version 0.8.0, and already supports | ||
Antrea (Namespace scoped) NetworkPolicy, ClusterNetworkPolicy, ClusterGroup, | ||
Tier, and features including traffic statistics, traffic logging, policy | ||
realization status, `Drop` and `Reject` actions, policy priority, `AppliedTo` | ||
at rule level, Namespace isolation, FQDN and Service as egress rule destination. | ||
We will continue to add more advanced NetworkPolicy features. | ||
|
||
* **Network diagnostics and observability** | ||
Network diagnostics and observability is one area we want to focus on. Antrea | ||
already implements some useful features on this front, including the [Antrea | ||
UI](https://github.com/antrea-io/antrea-ui), [CLI](docs/antctl.md), | ||
[Traceflow](docs/traceflow-guide.md), [network flow export and | ||
visualization](docs/network-flow-visibility.md), [Prometheus | ||
metrics](docs/prometheus-integration.md), [OVS flow | ||
dumping](docs/antctl.md#dumping-ovs-flows) and [packet | ||
tracing](docs/antctl.md#ovs-packet-tracing), [NetworkPolicy | ||
diagnostics](docs/antctl.md#networkpolicy-commands). We will continue to enhance | ||
existing features and add new features to help diagnose K8s networking and | ||
NetworkPolicy implementation, and to provide good visibility into the Antrea | ||
network. | ||
|
||
* **NFV and Telco use cases** | ||
We plan to explore and provide support for NFV and Telco use cases. We will add | ||
native Pod multi-interface support in Antrea, and support Pod interfaces on | ||
SRIOV devices, OVS DPDK bridge, overlay network, and Network Service Chaining. | ||
|
||
* **L7 security policy and visibility** | ||
Enhance Antrea to provide application level security and visibility to K8s | ||
workloads. This includes extending Antrea-native NetworkPolicies to support L7 / | ||
application protocols (HTTP, DNS, etc.), and extending Antrea diagnostics and | ||
observability features to get into application level visibility. | ||
|
||
* **Multi-cluster networking** | ||
We would extend Antrea from CNI of a single Kubernetes cluster to multi-cluster | ||
networking, and implement multi-cluster features like multi-cluster Services, | ||
cross-cluster connectivity, multi-cluster NetworkPolicies. Antrea multi-cluster | ||
functionalities are under active development. Check the [Antrea Multi-cluster | ||
user guide](docs/multicluster/user-guide.md) to learn what features are already | ||
supported. | ||
|
||
* **Analytics** | ||
With the network flows exported by Antrea, we plan to further build an analytics | ||
solution that consumes the network flows, and provides traffic analysis, | ||
NetworkPolicy recommendation, security and network performance monitoring. We | ||
already started a sub-project of Antrea - [Theia](https://github.com/antrea-io/theia) - | ||
for network flow visibility and analytics. Stay tunned! | ||
|
||
* **K8s Node security** | ||
So far Antrea focuses on K8s Pod networking and security, but we would like to | ||
extend Antrea-native NetworkPolicies to cover protection of K8s Nodes too. | ||
|
||
* **NetworkPolicy scale and performance tests** | ||
Evaluate and benchmark the NetworkPolicy implementation performance at a large | ||
scale, including the policy computation performance of Antrea Controller and the | ||
OVS datapath performance. | ||
|
||
* **OVS with DPDK or AF_XDP** | ||
Leverage OVS with DPDK or AF_XDP for high performance. | ||
## Roadmap Items | ||
|
||
### Antrea v2 | ||
|
||
Antrea [version 2](https://github.com/antrea-io/antrea/issues/4832) is coming in | ||
2024. We are graduating some popular features to Beta or GA, deprecating some | ||
legacy APIs, dropping support for old K8s versions (< 1.19) to improve support | ||
for newer ones, and more! This is a big milestone for the project, stay tuned! | ||
|
||
### K8s Node security | ||
|
||
So far Antrea has focused on K8s Pod networking and security, but we would like | ||
to extend Antrea-native NetworkPolicies to cover protection of K8s Nodes | ||
too. There is ongoing work for this, so expect this feature very soon! | ||
|
||
### Quality of life improvements for installation and upgrade | ||
|
||
We have a few things planned to improve basic usability: | ||
|
||
* provide separate container images for the Agent and Controller: this will | ||
reduce image size and speed up deployment of new Antrea versions. | ||
* support for installation and upgrade using the antctl CLI: this will provide | ||
an alternative installation method and antctl will ensure that Antrea | ||
components are upgraded in the right order to minimize workload disruption. | ||
* CLI tools to facilitate migration from another CNI: we will take care of | ||
provisioning the correct network resources for your existing workloads. | ||
|
||
### Core networking features | ||
|
||
We are currently working on supporting VLAN tagging for Egress traffic. In the | ||
long term, we plan to add BGP support to the Antrea Agent, as it is a much | ||
requested feature. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @antoninbas , Do we support pods in different subnets and vlan tagged(different vlans) traffic in IPAM to communicate to each other There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We do, but flexible IPAM is orthogonal to this (VLAN tagging for Egress) |
||
### Windows support improvements | ||
|
||
Antrea [supports Windows K8s Nodes](docs/windows.md). However, a few features | ||
including: Egress, NodePortLocal, IPsec encryption are not supported for Windows | ||
yet. We will continue to add more features for Windows (starting with Egress) | ||
and aim for feature parity with Linux. We encourage users to reach out if they | ||
would like us to prioritize a specific feature. While the installation procedure | ||
has improved significantly since we first added Windows support, we plan to keep | ||
on streamlining the procedure (more automation) and on improving the user | ||
documentation. | ||
|
||
### More robust FQDN support in Antrea NetworkPolicy | ||
|
||
Antrea provides a comprehensive network policy model, which builds upon | ||
Kubernetes Network Policies and provides many additional capabilities. One of | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. K8s is used elsewhere in this doc. |
||
them is the ability to define policy rules using domain names (FQDNs). We think | ||
there is some room to improve user experience with this feature, and we are | ||
working on making it more stable. | ||
|
||
### Implementation of new upstream NetworkPolicy APIs | ||
|
||
[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network) | ||
is working on [new standard APIs](https://network-policy-api.sigs.k8s.io/) to | ||
extend the base K8s NetworkPolicy resource. We are closely monitoring the | ||
upstream work and implementing these APIs as their development matures. | ||
|
||
### Better network troubleshooting with packet capture | ||
|
||
Antrea comes with many tools for network diagnostics and observability. You may | ||
already be familiar with Traceflow, which lets you trace a single packet through | ||
the Antrea network. We plan on also providing users with the ability to capture | ||
live traffic and export it in PCAP format. Think tcpdump, but for K8s and | ||
through a dedicated Antrea API! | ||
|
||
### Multi-network support for Pods | ||
|
||
We recently added the SecondaryNetwork feature, which supports provisioning | ||
additional networks for Pods, using the same constructs made popular by | ||
[Multus](https://github.com/k8snetworkplumbingwg/multus-cni). However, at the | ||
moment, options for network "types" are limited. We plan on supporting new use | ||
cases (e.g., secondary network overlays, network acceleration with DPDK), as | ||
well as on improving user experience for this feature (with some useful | ||
documentation). | ||
luolanzone marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### L7 security policy | ||
|
||
Support for L7 NetworkPolicies was added in version 1.10, providing the ability | ||
to select traffic based on the application-layer context. However, the feature | ||
currently only supports HTTP and TLS traffic, and we plan to extend support to | ||
other protocols, such as DNS. | ||
|
||
### Multi-cluster networking | ||
|
||
Antrea can federate multiple K8s clusters, but this feature (introduced in | ||
version 1.7) is still considered Alpha today. Most of the functionality is | ||
already there (multi-cluster Services, cross-cluster connectivity, | ||
and multi-cluster NetworkPolicies), but we think there is some room for | ||
improvement when it comes to stability and usability. | ||
|
||
### NetworkPolicy scale and performance tests | ||
|
||
We are working on a framework to empower contributors and users to benchmark the | ||
performance of Antrea at scale. | ||
|
||
### Investigate better integration with service meshes | ||
|
||
As service meshes start introducing alternatives to the sidecar approach, | ||
we believe there is an opportunity to improve the synergy between the K8s | ||
network plugin and the service mesh provider. In particular, we are looking at | ||
how Antrea can integrate with the new Istio ambient data plane mode. Take a look | ||
at [#5682](https://github.com/antrea-io/antrea/issues/5682) for more | ||
information. | ||
|
||
### Investigate multiple replicas for the Controller | ||
|
||
While today the Antrea Controller can scale to 1000s of K8s Nodes and 100,000 | ||
luolanzone marked this conversation as resolved.
Show resolved
Hide resolved
|
||
Pods, and failover to a new replica in case of failure can happen in under a | ||
minute, we believe we should still investigate the possibility of deploying | ||
multiple replicas for the Controller (Active-Active or Active-Standby), to | ||
enable horizontal scaling and achieve high-availability with very quick | ||
failover. Horizontal scaling could help reduce the memory footprint of each | ||
Controller instance for very large K8s clusters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"K8s" was not used in this document.