Add AntreaNodeConfig CRD

[luolanzone]

Introduce a new cluster-scoped CRD, AntreaNodeConfig, that allows
users to define Antrea agent configuration on a per-Node basis using
a nodeSelector.

The CRD currently supports secondaryNetwork configuration only.
Additional Agent configuration fields may be added in the future.

The spec fields are:

• nodeSelector: selects Nodes to which the config applies; if
  multiple AntreaNodeConfigs match a Node, the one with the earliest
  creation timestamp (or lowest name if equal) wins.
• secondaryNetwork.ovsBridges[]: list of OVS bridges (max 1) for
  secondary networks, each with:
  • bridgeName: name of the OVS bridge (optional, default to br1,
    immutalbe after setting)
  • physicalInterfaces[]: physical NICs to attach, each with:
    • name: interface name (required)
    • allowedVLANs[]: VLAN IDs or ranges (e.g. "100", "200-300");
      defaults to all VLANs if unset
  • enableMulticastSnooping: forward multicast only to interested
    ports instead of flooding; defaults to false

Changes include:

• New Go types and deepcopy functions in pkg/apis/crd/v1alpha1
• CRD OpenAPI manifest in build/charts/antrea/crds
• Role permission update in build/charts/antrea/templates/agent/clusterrole.yaml
• Auto-generated clientset, lister, and informer code for v1alpha1

[Copilot]

Pull request overview

This PR introduces a new cluster-scoped CRD AntreaNodeConfig that allows users to define per-Node Antrea agent configuration using a nodeSelector. The CRD currently supports secondaryNetwork configuration (OVS bridges with physical uplinks and VLAN filters). It includes the full Go API types, deepcopy functions, and auto-generated clientset/lister/informer code, along with the Kubernetes CRD manifest and RBAC updates.

Changes:

• New Go API types (AntreaNodeConfig, AntreaNodeConfigSpec, NodeSecondaryNetworkConfig, OVSBridgeConfigWithUplinks, PhysicalInterfaceConfig) in pkg/apis/crd/v1alpha1, plus their deepcopy implementations and scheme registration
• Auto-generated clientset, lister, and informer code in pkg/client/ for the new v1alpha1 type
• CRD OpenAPI manifest (build/charts/antrea/crds/antreanodeconfig.yaml), agent ClusterRole RBAC update, and regenerated bundled YAML files

Reviewed changes

Copilot reviewed 21 out of 21 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
pkg/apis/crd/v1alpha1/types.go	Defines AntreaNodeConfig Go API types
pkg/apis/crd/v1alpha1/register.go	Registers new types in the scheme
pkg/apis/crd/v1alpha1/zz_generated.deepcopy.go	Auto-generated DeepCopy functions for new types
pkg/client/clientset/versioned/typed/crd/v1alpha1/antreanodeconfig.go	Generated typed client for AntreaNodeConfig
pkg/client/clientset/versioned/typed/crd/v1alpha1/crd_client.go	Adds AntreaNodeConfigsGetter to CRD client interface
pkg/client/clientset/versioned/typed/crd/v1alpha1/generated_expansion.go	Adds AntreaNodeConfigExpansion interface
pkg/client/clientset/versioned/typed/crd/v1alpha1/fake/fake_antreanodeconfig.go	Fake client for testing
pkg/client/clientset/versioned/typed/crd/v1alpha1/fake/fake_crd_client.go	Wires fake client to AntreaNodeConfigs
pkg/client/informers/externalversions/crd/v1alpha1/antreanodeconfig.go	Generated informer for AntreaNodeConfig
pkg/client/informers/externalversions/crd/v1alpha1/interface.go	Adds AntreaNodeConfigInformer to the informer interface
pkg/client/informers/externalversions/generic.go	Registers AntreaNodeConfigs in the generic informer switch
pkg/client/listers/crd/v1alpha1/antreanodeconfig.go	Generated lister for AntreaNodeConfig
pkg/client/listers/crd/v1alpha1/expansion_generated.go	Adds AntreaNodeConfigListerExpansion interface
build/charts/antrea/crds/antreanodeconfig.yaml	CRD OpenAPI manifest for AntreaNodeConfig
build/charts/antrea/templates/agent/clusterrole.yaml	Grants agent read access to antreanodeconfigs
build/yamls/antrea*.yml	Regenerated bundled deployment YAMLs including new CRD and RBAC

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[luolanzone]

@jianjuns @antoninbas For AntreaNodeConfig, I plan to let the oldest CR win if multiple CRs applies to a Node. Which means for any AntreaNodeConfig, there should be only one valid config CR per Node and any new CR after that would be ignored. Let me know if you have any thought about this. Thanks.

[luolanzone]

Just checked CiliumNodeConfig, it seems they are using overridden way:

If multiple overrides apply to the same node, they will be ordered by name with later Overrides overwriting any conflicting keys.

I am not sure if "ordered by name" is a good way. Probably we can order AntreaNodeConfig by creationstamp and later Overrides overwriting any conflicting keys?

[antoninbas]

Maybe we can be consistent with what we have for BGPPolicy? Do we do anything specific there?

[luolanzone]

For secondary network, we will create the secondary bridge and corresponding client for Pods. Rethinking about it, It's probably better to be consistent as BGPPolicy to use the one with the earliest creation time. Which would be stable for Pod's underlay network without recreating a new bridge and client.