17.2. 主网络
17.2.1. 关于用户定义的网络 复制链接链接已复制到粘贴板!
UserDefinedNetwork
只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
在实现用户定义的网络(UDN)之前,OpenShift Container Platform 的 OVN-Kubernetes CNI 插件仅在主或 主 网络上支持第 3 层拓扑。由于 Kubernetes 设计原则:所有 pod 都附加到主网络,所有 pod 都通过其 IP 地址相互通信,并且 pod 间的流量会根据网络策略的限制。
UDN 通过启用自定义第 2 层和第 3 层网络段来提高 Kubernetes pod 网络的默认层 3 拓扑的灵活性和分段功能,其中所有这些片段默认被隔离。这些片段充当容器 pod 和使用默认 OVN-Kubernetes CNI 插件的虚拟机的主网络。UDN 启用广泛的网络架构和拓扑,提高网络灵活性、安全性和性能。
以后的 OpenShift Container Platform 版本中将添加对主网络和二级网络上的 Localnet 拓扑的支持。
集群管理员可以通过利用 ClusterUserDefinedNetwork
自定义资源(CR),使用 UDN 创建并定义跨集群级别多个命名空间的主或次要网络。另外,集群管理员或集群用户可以使用 UDN 使用 UserDefinedNetwork
CR 在命名空间级别定义二级网络。
下图显示了四个集群命名空间,其中每个命名空间都有一个分配的用户定义的网络(UDN),每个 UDN 都有一个用于其 pod IP 分配的自定义子网。OVN-Kubernetes 处理任何重叠的 UDN 子网。如果不使用 Kubernetes 网络策略,附加到 UDN 的 pod 可以与 UDN 中的其他 pod 通信。默认情况下,这些 pod 与其他 UDNs 中存在的 pod 通信。对于微分段,您可以在 UDN 中应用网络策略。您可以将一个或多个 UDN 分配给命名空间,限制为命名空间一个主 UDN,并将一个或多个命名空间分配给 UDN。
图 17.1. 使用 UserDefinedNetwork CR 进行命名空间隔离
以下章节进一步强调了用户定义的网络的好处和限制、创建 UserDefinedNetwork
自定义资源、如何创建自定义资源以及可能与您的部署相关的其他配置详情。
17.2.1.1. 用户定义的网络的好处 复制链接链接已复制到粘贴板!
用户定义的网络具有以下优点:
增强了用于安全性的网络隔离
- 租户隔离 :命名空间可以有自己的隔离主网络,类似于在 Red Hat OpenStack Platform (RHOSP) 中隔离租户的方式。这通过降低跨租户流量的风险来提高安全性。
网络灵活性
- Layer 2 和 layer 3 的支持:集群管理员可以将主网络配置为 Layer 2 或 layer 3 网络类型。
简化网络管理
- 降低网络配置复杂性:使用用户定义的网络,可以通过对不同网络中的工作负载进行分组来实现隔离。从而消除了对复杂网络策略的需求。
高级功能
- 一致且可选择的 IP 寻址 :用户可以在不同的命名空间和集群间指定并重复使用 IP 子网,从而提供一致的网络环境。
- 支持多个网络:用户定义的网络功能允许管理员将多个命名空间连接到单个网络,或者为不同的命名空间组创建不同的网络。
简化了从 Red Hat OpenStack Platform (RHOSP) 迁移应用程序的过程
- 网络奇偶校验:通过提供类似网络隔离和配置选项,简化了应用程序从 OpenStack 迁移到 OpenShift Container Platform 的过程。
开发人员和管理员可以创建用户定义的网络,该网络使用自定义资源是命名空间范围。进程概述如下:
-
管理员使用
k8s.ovn.org/primary-user-defined-network
标签为用户定义网络创建一个命名空间。 -
UserDefinedNetwork
CR 由集群管理员或用户创建。 - 用户在命名空间中创建 pod。
17.2.1.2. UserDefinedNetwork 自定义资源的限制 复制链接链接已复制到粘贴板!
虽然用户定义的网络 (UDN) 提供了高度可自定义的网络配置选项,但集群管理员和开发人员在实施和管理这些网络时应了解其中的一些限制。在实施用户定义的网络前,请考虑以下限制。
DNS 限制 :
- DNS 中对 pod 的查询会被解析为集群默认网络上的 pod IP 地址。即使 pod 是用户定义的网络的一部分,DNS 查询也不会解析到用户定义的网络上的 pod IP 地址。但是,服务和外部实体的 DNS 查找将按预期工作。
- 当 pod 分配给主 UDN 时,它可以访问集群的默认网络上的 Kubernetes API (KAPI) 和 DNS 服务。
- 初始网络分配:您需要在创建 pod 前创建命名空间和网络。OVN-Kubernetes 不接受将带有 pod 的命名空间分配到一个新的网络,或在现有命名空间中创建一个 UDN。
- 健康检查限制:Kubelet 健康检查由集群默认网络执行,这不会确认 pod 上主接口的网络连接。因此,在用户定义的网络中可能会出现 pod 在默认网络中是健康的,但在主接口中存在连接问题的情况。
- 网络策略限制 :启用连接到不同用户定义的主网络的命名空间之间的流量的网络策略无效。这些流量策略不会生效,因为这些隔离的网络之间没有连接。
-
创建和编辑限制 :在创建后无法修改
Cluster
CR 和 UserDefinedNetwork CR。UserDefinedNetwork
17.2.1.3. 第 2 层和第 3 层拓扑 复制链接链接已复制到粘贴板!
扁平第 2 层拓扑会创建一个虚拟交换机,该交换机分布到集群中的所有节点上。虚拟机和 pod 连接到此虚拟交换机,以便所有这些组件都可以在同一子网内相互通信。扁平第 2 层拓扑可用于在集群中存在的节点间实时迁移虚拟机。下图显示了一个扁平第 2 层拓扑,其中有两个节点使用虚拟交换机进行实时迁移:
图 17.2. 使用虚拟交换机进行组件通信的平面第 2 层拓扑
如果您决定不指定第 2 层子网,则必须为集群中的每个 pod 手动配置 IP 地址。当您没有指定第 2 层子网时,端口安全性仅限于防止介质访问控制(MAC)欺骗,且不包含 IP 欺骗。第 2 层拓扑创建了一个在大型网络环境中具有挑战性的广播域,拓扑可能会导致广播功能降低网络性能。
要访问更多可配置的选项,您可以将第 2 层拓扑与用户定义的网络(UDN)集成。下图显示了使用 UDN 和第 2 层拓扑的两个节点,其中包含每个节点上存在的 pod。每个节点包含两个接口:
- 节点接口,这是将网络组件连接到节点的计算节点。
-
Open vSwitch (OVS)网桥(如
br-ex
)创建第 2 层 OVN 交换机,以便 pod 能够相互通信并共享资源。
外部交换机连接这两个接口,而网关或路由器处理外部交换机和第 2 层 OVN 交换机之间的路由流量。节点上的虚拟机和 pod 可以使用 UDN 相互通信。第 2 层 OVN 交换机通过 UDN 处理节点流量,以便将虚拟机从一个节点实时迁移到另一个节点。
图 17.3. 使用第 2 层拓扑的用户定义的网络(UDN)
第 3 层拓扑为集群中的每个节点创建一个唯一的第 2 层片段。第 3 层路由机制会连接这些片段,以便在不同节点上托管的虚拟机和 pod 可以相互通信。第 3 层拓扑可以通过将每个域分配给特定节点来有效地管理大型广播域,以便广播流量的范围减少。要配置第 3 层拓扑,您必须配置 cidr
和 hostSubnet
参数。
17.2.1.4. UserDefinedNetwork 的最佳实践 复制链接链接已复制到粘贴板!
在设置 UserDefinedNetwork
(UDN) 资源前,用户应考虑以下信息:
-
openshift-*
命名空间不应用于设置 UDN。 用户定义的网络需要 2 个伪装 IP 地址。您必须重新配置伪装子网,使其足够大,以容纳所需的网络数量。
重要-
对于 OpenShift Container Platform 4.17 及更新的版本,集群使用
169.254.0.0/17
(IPv4),或fd69::/112
(IPv6)作为默认的伪装子网。用户应避免这些范围。对于更新的集群,默认 masquerade 子网没有变化。 - 在为项目配置了用户定义的网络后,不支持更改集群的伪装子网。在设置了 UDN 后尝试修改伪装子网可能会破坏网络连接并导致配置问题。
-
对于 OpenShift Container Platform 4.17 及更新的版本,集群使用
-
确保租户使用
UserDefinedNetwork
资源,而不是NetworkAttachmentDefinition
(NAD) 资源。这可以在租户之间造成安全风险。 - 在创建网络分段时,只有在无法使用 UDN 资源完成用户定义的网络分段时,才应使用 NAD 资源。
-
UDN 的集群子网和服务 CIDR 无法与默认集群子网 CIDR 重叠。OVN-Kubernetes 网络插件使用
100.64.0.0/16
作为默认网络加入子网,不得使用该值来配置 UDNJoinSubnets
字段。如果在网络的任何地方使用默认地址值,则必须通过设置joinSubnets
字段来覆盖它。如需更多信息,请参阅 "UserDefinedNetworks CR 的附加配置详情"。 -
UDN 的集群子网和服务 CIDR 无法与默认集群子网 CIDR 重叠。OVN-Kubernetes 网络插件使用
100.64.0.0/16
作为网络的默认加入子网,您不能使用该值来配置 UDNjoinSubnets
字段。如果在网络中为集群使用默认地址值,则必须通过设置joinSubnets
字段来覆盖默认值。如需更多信息,请参阅 "UserDefinedNetworks CR 的附加配置详情"。
17.2.1.5. 创建 UserDefinedNetwork 自定义资源 复制链接链接已复制到粘贴板!
以下流程创建命名空间范围的用户定义网络。根据您的用例,创建您的请求,使用 my-layer-two-udn.yaml
示例用于 Layer2
拓扑类型,或使用 my-layer-three-udn.yaml
示例用于 Layer3
拓扑类型。
Perquisites
-
您已使用
cluster-admin
权限登录,或者您有查看和编辑
流程
可选: 对于使用主网络的
UserDefinedNetwork
CR,请输入以下命令创建带有k8s.ovn.org/primary-user-defined-network
标签的命名空间:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为
Layer2
或Layer3
拓扑类型用户定义的网络创建请求:创建一个 YAML 文件,如
my-layer-two-udn.yaml
,为Layer2
拓扑定义您的请求,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
UserDefinedNetwork
资源的名称。这不应该是default
或重复 Cluster Network Operator (CNO) 创建的任何全局命名空间。- 2
topology
字段描述了网络配置;接受的值是Layer2
和Layer3
。指定Layer2
拓扑类型会创建一个逻辑交换机,它被所有节点共享。- 3
- 此字段指定拓扑配置。它可以是
layer2
或layer3
。 - 4
- 指定
Primary
或Secondary
角色。 - 5
- 对于
Layer2
拓扑类型,以下指定subnet
字段的配置详情:- subnets 字段是可选的。
-
subnets 字段的类型是
字符串
,接受 IPv4 和 IPv6 的标准 CIDR 格式。 -
subnets 字段接受一个或多个项。如果是两个项,它们必须属于不同的系列。例如,子网值
10.100.0.0/16
和2001:db8::/64
。 -
可以省略
Layer2
子网。如果省略,用户需要为 pod 配置 IP 地址。因此,端口安全性只能阻止 MAC 欺骗。 -
当指定
ipamLifecycle
字段时,Layer2
subnets
字段是必须的。
创建一个 YAML 文件,如
my-layer-three-udn.yaml
,为Layer3
拓扑定义您的请求,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
UserDefinedNetwork
资源的名称。这不应该是default
或重复 Cluster Network Operator (CNO) 创建的任何全局命名空间。- 2
topology
字段描述了网络配置;接受的值是Layer2
和Layer3
。指定Layer3
拓扑类型会为每个节点创建一个第 2 层段,各自具有不同的子网。第 3 层路由用于互连节点子网。- 3
- 此字段指定拓扑配置。有效值为
layer2
或layer3
。 - 4
- 指定
Primary
或Secondary
角色。 - 5
- 对于
Layer3
拓扑类型,以下指定subnet
字段的配置详情:-
subnets
字段是必需的。 subnets
字段的类型是cidr
和hostSubnet
:-
CIDR
等同于集群的clusterNetwork
配置设置。CIDR 中的 IP 地址分布到用户定义的网络中的 pod。此参数接受字符串值。 -
hostSubnet
定义每个节点子网的前缀。 -
对于 IPv6,
hostSubnet
仅支持/64
长度。
-
-
运行以下命令来应用您的请求:
oc apply -f <my_layer_two_udn.yaml>
$ oc apply -f <my_layer_two_udn.yaml>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<my_layer_two_udn.yaml>
是Layer2
或Layer3
配置文件的名称。运行以下命令验证您的请求是否成功:
oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
some_custom_namespace
是您为用户定义的网络创建的命名空间。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.1.5.1. UserDefinedNetworks CR 的其他配置详情 复制链接链接已复制到粘贴板!
下表解释了 UDN 的其他配置,它们是可选的。不建议在不明确需要和了解 OVN-Kubernetes 网络拓扑的情况下设置这些字段。
- 用户定义的网络的可选配置
CUDN 字段 | UDN 字段 | 类型 | 描述 |
|
| object |
如果省略,平台为
|
|
| object |
只有在 |
|
| object |
Enabled:
Disabled: |
|
| 整数 |
最大传输单元 (MTU)。默认值为 |
其中:
<topology>
-
是
第 2 层或第
3 层
之一。
17.2.2. 使用 NetworkAttachmentDefinition 创建主网络 复制链接链接已复制到粘贴板!
以下小节解释了如何使用 NetworkAttachmentDefinition
(NAD)资源创建和管理主要网络。
17.2.2.1. 管理主网络的方法 复制链接链接已复制到粘贴板!
您可以使用以下两种方法之一管理由 NAD 创建的主网络的生命周期:
-
通过修改 Cluster Network Operator (CNO) 配置。使用此方法时,CNO 会自动创建和管理
NetworkAttachmentDefinition
对象。除了管理对象生命周期外,CNO 还可确保 DHCP 可用于使用 DHCP 分配 IP 地址的主网络。 -
通过应用 YAML 清单。使用此方法,您可以通过创建
NetworkAttachmentDefinition
对象直接管理主网络。此方法可以调用多个 CNI 插件,以便在 pod 中附加主网络接口。
每种方法都是相互排斥的,您一次只能使用一种方法来管理主网络。对于任一方法,主网络由您配置的 Container Network Interface (CNI)插件管理。
当使用 OVN SDN 在 Red Hat OpenStack Platform (RHOSP) 中使用多个网络接口部署 OpenShift Container Platform 节点时,二级接口的 DNS 配置可能会优先于主接口的 DNS 配置。在这种情况下,运行以下命令删除附加到二级接口的子网 ID 的 DNS 名称服务器:
openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
$ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
17.2.2.2. 使用 Cluster Network Operator 创建主网络附加 复制链接链接已复制到粘贴板!
Cluster Network Operator (CNO) 管理额外网络定义。当您指定要创建的主网络时,CNO 会自动创建 NetworkAttachmentDefinition
CRD。
请勿编辑 Cluster Network Operator 所管理的 NetworkAttachmentDefinition
CRD。这样做可能会破坏主网络上的网络流量。
先决条件
-
安装 OpenShift CLI(
oc
)。 -
以具有
cluster-admin
特权的用户身份登录。
流程
可选:为主网络创建命名空间:
oc create namespace <namespace_name>
$ oc create namespace <namespace_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要编辑 CNO 配置,请输入以下命令:
oc edit networks.operator.openshift.io cluster
$ oc edit networks.operator.openshift.io cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过为您要创建的主网络添加配置来修改您要创建的 CR,如下例所示。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 保存您的更改,再退出文本编辑器以提交更改。
验证
运行以下命令确认 CNO 创建了
NetworkAttachmentDefinition
CRD。CNO 创建 CRD 之前可能会有延迟。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<namespace>
- 指定添加到 CNO 配置中的网络附加的命名空间。
输出示例
NAME AGE test-network-1 14m
NAME AGE test-network-1 14m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.2.2.2.1. 配置主网络附加 复制链接链接已复制到粘贴板!
主网络通过使用 k8s.cni.cncf.io
API 组中的 NetworkAttachmentDefinition
API 来配置。
下表中描述了 API 的配置:
字段 | 类型 | 描述 |
---|---|---|
|
| 主网络的名称。 |
|
| 与对象关联的命名空间。 |
|
| JSON 格式的 CNI 插件配置。 |
17.2.2.3. 通过应用 YAML 清单来创建主网络附加 复制链接链接已复制到粘贴板!
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
您已以具有
cluster-admin
权限的用户身份登录。 - 您在要部署 NAD 的命名空间中工作。
流程
使用主网络配置创建 YAML 文件,如下例所示:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 可选:您可以指定 NAD 应用到的命名空间。如果您在要部署 NAD 的命名空间中工作,则不需要此规格。
运行以下命令来创建主网络:
oc apply -f <file>.yaml
$ oc apply -f <file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中:
<file>
- 指定包含 YAML 清单的文件名。