您可以创建 Antrea 组,并将其用作分布式防火墙策略中的源或目标,以保护 Antrea Kubernetes 集群内 Pod 之间的流量。
仅当 NSX 环境中注册了一个或多个 Antrea Kubernetes 集群时,才支持 Antrea 组功能。如果检测到注册的 Antrea Kubernetes 集群,则 NSX Manager 在 UI 的添加组页面上显示一种名为 Antrea 的单独组类型。您必须选择该组类型才能添加 Antrea 组。
如果您的目标是保护 Antrea Kubernetes 集群和 NSX 覆盖网络中虚拟机之间的流量,则必须在动态成员资格条件中创建具有 Kubernetes 成员类型的常规组,并在防火墙规则中使用这些组。有关详细信息,请参见在动态成员资格条件中使用 Kubernetes 成员类型的通用组。
Antrea 组可以包含静态 IP 地址和/或成员资格条件。IP 地址可以是 Pod IP 或服务 IP 地址。
当 Antrea 组包含成员资格条件时,根据该成员资格条件计算的有效成员只能是 Pod。
- 仅当在分布式防火墙规则中使用 Antrea 组时,才会计算 Antrea 组的有效成员。
如果添加了具有成员资格条件的 Antrea 组,但没有在任何分布式防火墙规则中使用这些组,则不会在 NSX 中计算或评估这些 Antrea 组的有效成员。换句话说,这些 Antrea 组的有效成员页面为空。
- 在 Antrea 组中添加静态 IP 地址时,无论是否在分布式防火墙规则中使用这些组,UI 中当前都不会显示有效成员。
- 命名空间
- 服务
- Pod
成员资格条件概述
- 成员类型
- 成员类型的名称或附加到成员类型的标记
- 标记运算符和值(仅在使用标记时)
- 范围运算符和值(仅在使用标记时)
默认情况下,NSX 会在成员资格条件中的每个条件后使用逻辑 AND 运算符。不支持使用其他逻辑运算符来连接成员资格条件中的条件。
- 示例:
-
成员资格条件 描述 成员资格条件 1:
Pod 标记等于 App,范围等于“服务器”
成员资格条件仅包含一个基于 Pod 的条件。未使用多个条件。此 Antrea 组的有效成员包括具有 App 标记的所有 Pod。
成员资格条件 2:
Pod 标记等于 App,范围等于“服务器”
Pod 标记等于 DB,范围等于“服务器”
Pod 标记等于 Web,范围等于“服务器”
成员资格条件包含三个条件。成员资格条件中的所有条件均基于 Pod。此 Antrea 组的有效成员包括具有 App、DB 和 Web 标记的所有 Pod。
成员资格条件 3:
命名空间名称等于“生产”
服务名称等于“缓存”
成员资格条件包含两个混合使用“命名空间”和“服务”的条件。此 Antrea 组的有效成员包括与“生产”命名空间中“缓存”服务关联的所有 Pod。
使用 OR 或 AND 运算符连接成员资格条件
- 两个成员资格条件使用相同的成员类型。
- 这两个成员资格条件都使用单个条件。
- 示例:
-
- 成员资格条件 1、成员资格条件 2 和成员资格条件 3 均基于 Pod,并且都不包含多个条件。在这种情况下,可以使用 OR 或 AND 运算符来连接成员资格条件 1 和成员资格条件 2。同样,也可以使用 OR 或 AND 运算符来连接成员资格条件 2 和成员资格条件 3。
- 成员资格条件 1 基于 Pod,而成员资格条件 2 使用两个条件:一个条件基于“服务”,另一个条件基于“命名空间”。在这种情况下,仅支持使用 OR 运算符来连接成员资格条件 1 和成员资格条件 2。不允许使用 AND 运算符。
- 成员资格条件 1 和成员资格条件 2 都基于 Pod,而成员资格条件 3 使用两个条件:一个条件基于“服务”,另一个条件基于“命名空间”。在这种情况下,可以使用 AND 或 OR 运算符来连接成员资格条件 1 和成员资格条件 2。但是,只能使用 OR 运算符来连接成员资格条件 2 和成员资格条件 3。不允许使用 AND 运算符。
支持和不支持的功能
成员类型 | 对象属性 | 标记运算符 | 范围运算符 | 示例成员资格条件 |
---|---|---|---|---|
命名空间 |
名称 |
等于 |
不适用 |
命名空间名称等于“生产” |
命名空间 |
标记 |
等于 不等于 |
等于 |
命名空间标记等于 DB,范围等于“服务器” |
服务 |
名称 |
不受支持 |
不受支持 |
服务名称等于“缓存” |
Pod |
标记 |
等于 不等于 |
等于 |
Pod 标记等于 App,范围等于“服务器” |
- “命名空间”和 Pod 成员类型当前不支持以下标记运算符:
- 包含
- 开头为
- 结尾为
- 在成员资格条件中,基于“服务”的条件必须与基于“命名空间”的“名称”属性的条件结合使用。换句话说,不允许仅使用“服务”成员类型的条件。
- 在成员资格条件中,基于“服务”的条件不能与基于 Pod 的条件结合使用。但是,您可以在两个单独的成员资格条件中添加基于“服务”和基于 Pod 的条件,然后使用 OR 运算符将它们连接起来。
- 在 Antrea 组中静态添加成员时,支持使用“仅限 IP 地址”。不能在 Antrea 组中将“命名空间”、Pod 和“服务”静态添加为成员。
- 在添加 Antrea 组时,如果尝试将组类型从 NSXAntrea 更改为常规,或者从 Antrea 更改为仅限 IP 地址, 将显示一条信息消息。在确认更改后,组中的所有成员资格条件将会丢失。仅在组中保留 IP 地址。
在 NSX 中实现(保存)Antrea 组后,您无法更改组类型。常规和仅限 IP 地址组类型将灰显。
适用于 Kubernetes 版本 1.20 或更低版本的解决办法
Antrea 组条件“命名空间名称等于 Value”适用于 Kubernetes 版本 1.21 或更高版本。
Kubernetes 1.21 或更高版本会自动向所有命名空间添加一个特殊标签,条件“命名空间名称等于值”将在内部使用此特殊标签。但是,对于 Kubernetes 版本 1.20 或更低版本,需要一种解决方法。您必须在用于创建事件的命名空间上注册 Antrea 控制器 Webhook。调用 Antrea 控制器 Webhook 时,Antrea 控制器 会向新命名空间添加一个特殊标签,以便条件“命名空间名称等于 Value”可以使用此标签。有关注册 Antrea 控制器 Webhook 的详细信息,请参见将 YAML 文件提交到 Kubernetes API 服务器中的步骤 3。
kube-system
和
default
)不会获取特殊标签,条件“命名空间名称等于
Value”也无法用于这些命名空间。