You can create Antrea groups only when your NSX-T Data Center has one or more Antrea container clusters registered to it.

If registered Antrea container clusters are detected, NSX Manager shows a separate group type called Antrea on the Add Group page of the UI. You must select this group type to add Antrea groups.

An Antrea group can include static IP addresses, membership criteria, or both. IP addresses can be Pod or Service IP addresses.

When an Antrea group contains membership criteria, the effective members computed by that membership criteria can only be Pods.

Note:
  • Effective members are computed for Antrea groups only when the Antrea groups are used in Distributed Firewall rules.

    When you add Antrea groups with membership criteria, but do not use these groups in any of the Distributed Firewall rules, the effective members of these Antrea groups are not computed or evaluated in NSX-T. In other words, the Effective Members page of these Antrea groups is empty.

  • When you add static IP addresses in Antrea groups, effective members are currently not displayed in the UI, regardless of whether the groups are used in Distributed Firewall rules.
To add membership criteria in an Antrea group, the following container cluster objects (member types) are currently supported:
  • Namespace
  • Service
  • Pod

Overview of Membership Criteria

You can add Antrea groups with a single membership criterion or multiple criteria. A membership criterion consists of one or multiple conditions. A condition in a membership criterion consists of the following properties:
  • Container cluster object (also called member type)
  • Either name of the container cluster object or a tag that is attached to the container object
  • Tag operator and value (only when tag is used)
  • Scope operator and value (only when tag is used)
The conditions in a membership criterion can use the same container cluster object or a mix of different container cluster objects. For example, if the membership criterion consists of three conditions, the first two conditions can use the Pod object, whereas the third condition can use the Namespace object. However, some restrictions exist for adding multiple conditions in a membership criterion. See the ''Supported and Unsupported Features'' section later in this topic.

By default, NSX-T uses the logical AND operator after each condition in a membership criterion. Other logical operators are not supported to join conditions in a membership criterion.

Examples:
Membership Criteria Description

Criterion 1:

Pod Tag Equals App Scope Equals Servers

Membership criterion consists of only a single condition that is based on the Pod object. Multiple conditions are not used. The effective members of this Antrea group include all Pods with the App tag.

Criterion 2:

Pod Tag Equals App Scope Equals Servers

Pod Tag Equals DB Scope Equals Servers

Pod Tag Equals Web Scope Equals Servers

Membership criterion consists of three conditions. All conditions in the criterion are based on the Pod object. The effective members of this Antrea group include all Pods with the App, DB, and Web tags.

Criterion 3:

Namespace Name Equals Production

Service Name Equals Cache

Membership criterion consists of two conditions with a mix of Namespace and Service objects. The effective members of this Antrea group include all Pods that are associated with the Service named Cache in the Production Namespace.

Joining Membership Criteria with OR, AND Operators

An Antrea group supports multiple membership criteria. To join the criteria, OR and AND operators are available. By default, NSX-T selects the OR operator to join multiple criteria. AND operator is supported between two criteria only when:
  • Both criteria use the same container cluster object.
  • Both criteria use a single condition.
Examples:
  • Criterion 1, Criterion 2, and Criterion 3 are all based on the Pod object, and they do not contain multiple conditions. In this case, Criterion 1 and Criterion 2 can be joined with either OR or AND operator. Similarly, Criterion 2 and Criterion 3 can also be joined with either OR or AND operator.
  • Criterion 1 is based on the Pod object, whereas Criterion 2 uses two conditions: one with the Service object and the other with the Namespace object. In this case, only OR operator is supported for joining Criterion 1 and 2. AND operator is not allowed.
  • Criterion 1 and Criterion 2 are based on the Pod object, whereas Criterion 3 uses two conditions: one with the Service object and the other with the Namespace object. In this case, Criterion 1 and Criterion 2 can be joined with either AND or OR operator. However, Criterion 2 and Criterion 3 can be joined only with OR operator. AND operator is not allowed.

Supported and Unsupported Features

The following table lists the container cluster objects, Tag operator, and Scope operator that are supported for adding membership criteria in Antrea groups.
Container Cluster Object Object Attribute Tag Operator Scope Operator Example Criteria

Namespace

Name

Equals

Not applicable

Namespace Name Equals Production

Namespace

Tag

Equals

Not Equals

Equals

Namespace Tag Equals DB Scope Equals Servers

Service

Name

Not supported

Not supported

Service Name Equals Cache

Pod

Tag

Equals

Not Equals

Equals

Pod Tag Equals App Scope Equals Servers
  • The following Tag operators are currently not supported for Namespace and Pod objects:
    • Contains
    • Starts With
    • Ends With
  • In a membership criterion, a condition based on the Service object must be combined with a condition based on the Name attribute of the Namespace object. In other words, a criterion with only the Service object is not allowed.
    Example:
    Supported Not Supported

    Criterion:

    Service Name Equals My-Service

    Namespace Name Equals Staging

    Criterion:

    Service Name Equals My-Service

  • In a membership criterion, a condition based on the Service object cannot be combined with a condition based on the Pod object. However, you can add the Service and Pod objects in two separate membership criteria and join them with the OR operator.
    Example:
    Supported Not Supported

    Criterion 1: Service Name Equals My-Service

    OR

    Criterion 2: Pod Tag Equals DB Scope Equals Servers

    Criterion:

    Service Name Equals My-Service

    Pod Tag Equals DB Scope Equals Servers
  • For adding static members in an Antrea group, only IP addresses are supported. Container cluster objects cannot be added as static members in an Antrea group.
  • When you are adding an Antrea group, NSX-T shows an information message if you try to change the group type from Antrea to Generic, or from Antrea to IP Addresses Only. On confirming the change, all the membership criteria in the group are lost. Only the IP addresses are retained in the group.

    After an Antrea group is realized (saved) in NSX-T, you cannot change the group type. The Generic and IP Addresses Only group types are dimmed.

Workaround for Kubernetes Version ≤ 1.20

Antrea group criterion "Namespace Name Equals Value" works with Kubernetes version ≥ 1.21.

Kubernetes 1.21 or later automatically adds a special label to all namespaces, and criterion "Namespace Name Equals Value" internally uses this special label. However, for Kubernetes version ≤ 1.20, a workaround is required. You must register the Antrea Controller webhook on namespace creating events. When the Antrea Controller webhook is called, Antrea Controller adds a special label to the new namespace, so criterion "Namespace Name Equals Value" can use this label. For details about registering the Antrea Controller webhook, see step 3 in Submit the YAML Files to the Kubernetes API Server.

Note: Antrea Controller webhook is effective only for new namespaces that you create after registering the webhook. In other words, existing namespaces, such as kube-system and default do not get the special label, and criterion "Namespace Name Equals Value" does not work with these namespaces.