Release Antrea v1.0

[antoninbas]

At the 01/04 community meeting, we started the discussing the possibility of promoting Antrea to v1.0 in early 2021 (v0.14 timeframe?).

I propose that we use this issue to discuss, list and document the tasks that we believe are required before we can release Antrea v1.0. I will start a list, but I expect it to evolve over time based on discussions below, at meetings and on Slack. If we do intend to make that release early this year, it would be good to reach agreement sooner rather than later.

• API renaming from *.antrea.tanzu.vmware.com to *.antrea.io (Rename Antrea APIs from *.antrea.tanzu.vmware.com to *.antrea.io #1715) - it wouldn't make sense to make such a big change post v1.0 and IMO we should keep a buffer of one minor release between introduction of the new API groups and promotion to v1.0
• Graduate Antrea-native policy APIs to beta (currently the API group is security.antrea.tanzu.vmware.com and the version is v1alpha1) - some K8s / Antrea users will not use alpha APIs and policies are a major feature
• Graduate the AntreaPolicy Feature Gate to beta - even though the APIs will remain alpha for the v1.0 release, the implementation itself has been stable for a while and we plan to enable Antrea-native policies by default
• AntreaProxy should be able to replace kube-proxy - we get a lot of questions around this and users can be confused as to why 2 proxy implementations coexist
  • NodePort support in AntreaProxy (Antrea Proxy NodePort Service Support #1463)
  • EndpointSlice support in AntreaProxy (Support EndpointSlices in AntreaProxy #1164) --- done in v0.13
• Containerd support for Windows Nodes (Windows Containerd Support short-term proposal #1679) - even if it is a "workaround" and not the long-term solution, we get a lot of interest in Antrea because of Windows support and dockershim is being deprecated --- done in v0.13

03/22/2021 edit:

• we will not graduate security API until after release v1.0, to avoid confusion due to API renaming (from *.antrea.tanzu.vmware.com to *.antrea.io)
• NodePort support in AntreaProxy (Linux & Windows) is a stretch goal, not strictly required for v1.0 release
• kube-proxy removal (Linux & Windows) is also a stretch goal, and is likely to be postponed to after the v1.0 release - we should prioritize Windows here to stop relying on userspace kube-proxy

03/25/2021 edit:

• add AntreaPolicy Feature Gate graduation to beta

[vicky-liu]

I think we can make ANP as Beta because VMware quality engineering team already verified it on 500 nodes.
@Dyanngg , any comments on item of ANP version?

[antoninbas]

@vicky-liu I think Alpha vs Beta here should be more about the stability of the API and less about the robustness of the implementation. @Dyanngg do we still have changes planned to the policy API in the short term, and are any of them non backwards compatible?

[vicky-liu]

@antoninbas @jianjuns , I'm afraid we cannt make Antrea proxy totally replace kube-proxy for Windows as the design is not ready for now. Regarding linux, the design and PoC is ready, but the work breakdown and effort estimation still need time to clarify. I think for Antrea 1.0, we can allow Antrea proxy co-exist with Kube-proxy?

[jianjuns]

That is fine in my mind. Anyway, I do not think we can remove kube-proxy for the majority of deployments.

[Dyanngg]

@vicky-liu I think Alpha vs Beta here should be more about the stability of the API and less about the robustness of the implementation. @Dyanngg do we still have changes planned to the policy API in the short term, and are any of them non backwards compatible?

As discussed with @antoninbas offline, there is a namespaceSelector -> namespaces upgrade we want to introduce to the Antrea ClusterNetworkPolicy peers, which would be a breaking change and a rather sizable effort. This is to keep parity with our ClusterNetworkPolicy KEP proposal, as well as giving user to ability to specify a per-namespace rule in a single policy. The goal is captured by #1642 but the approach is out of date. I will open a new issue to track this.
I would prefer we wait until this change is merged before declaring beta for Antrea-native policies.

[jianjuns]

I think we should revise AppliedTo of NetworkPolicy, which will be an incompatible change. But I agree it might not really impact 1.0.