18.2. 主网络
18.2.1. 关于用户定义的网络
UserDefinedNetwork
只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
在实现用户定义的网络(UDN)之前,OVN-Kubernetes CNI 插件只支持所有 pod 附加到的主或主要上的第 3 层拓扑。这可用于网络模型,其中集群中的所有 pod 都属于相同的全局第 3 层网络,但限制了自定义主网络配置的能力。
用户定义的网络为集群管理员和用户为主网络类型和二级网络类型提供高度可自定义的网络配置选项。借助 UDN,管理员可以通过增强隔离、用于工作负载的 IP 地址管理和高级网络功能创建定制的网络拓扑。支持第 2 层和第 3 层拓扑类型,UDN 启用广泛的网络架构和拓扑,提高网络灵活性、安全性和性能。
- 以后的 OpenShift Container Platform 版本中将添加对主和二级网络上的 Localnet 拓扑的支持。
与仅拥有命名空间的 NAD 不同,UDN 可让管理员利用 ClusterUserDefinedNetwork
自定义资源(CR)在集群级别创建和定义跨越多个命名空间的额外网络。UDN 还为管理员和用户提供在命名空间级别使用 UserDefinedNetwork
CR 定义额外网络的功能。
以下章节进一步强调了用户定义的网络的好处和限制、创建 ClusterUserDefinedNetwork
或 UserDefinedNetwork
自定义资源、如何创建自定义资源以及可能与您的部署相关的其他配置详情。
18.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 的过程。
开发人员和管理员可以创建用户定义的网络,该网络使用自定义资源是命名空间范围。进程概述包括:创建命名空间、创建和配置自定义资源,在命名空间中创建 pod。
18.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 在默认网络中是健康的,但在主接口中存在连接问题的情况。
- 网络策略限制 :启用连接到不同用户定义的主网络的命名空间之间的流量的网络策略无效。这些流量策略不会生效,因为这些隔离的网络之间没有连接。
18.2.1.3. 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 的附加配置详情"。
18.2.1.4. 创建 UserDefinedNetwork 自定义资源
以下流程创建命名空间范围的用户定义网络。根据您的用例,创建您的请求,使用 my-layer-two-udn.yaml
示例用于 Layer2
拓扑类型,或使用 my-layer-three-udn.yaml
示例用于 Layer3
拓扑类型。
流程
为
Layer2
或Layer3
拓扑类型用户定义的网络创建请求:创建一个 YAML 文件,如
my-layer-two-udn.yaml
,为Layer2
拓扑定义您的请求,如下例所示:apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-1 1 namespace: <some_custom_namespace> spec: topology: Layer2 2 layer2: 3 role: Primary 4 subnets: - "10.0.0.0/24" - "2001:db8::/60" 5
- 1
UserDefinedNetwork
资源的名称。这不应该是default
或重复 Cluster Network Operator (CNO) 创建的任何全局命名空间。- 2
topology
字段描述了网络配置;接受的值是Layer2
和Layer3
。指定Layer2
拓扑类型会创建一个逻辑交换机,它被所有节点共享。- 3
- 此字段指定拓扑配置。它可以是
layer2
或layer3
。 - 4
- 指定
Primary
或Secondary
。在 4.17 中,Primary
是唯一支持的role
规格。 - 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
拓扑定义您的请求,如下例所示:apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: name: udn-2-primary 1 namespace: <some_custom_namespace> spec: topology: Layer3 2 layer3: 3 role: Primary 4 subnets: 5 - cidr: 10.150.0.0/16 hostSubnet: 24 - cidr: 2001:db8::/60 hostSubnet: 64
- 1
UserDefinedNetwork
资源的名称。这不应该是default
或重复 Cluster Network Operator (CNO) 创建的任何全局命名空间。- 2
topology
字段描述了网络配置;接受的值是Layer2
和Layer3
。指定Layer3
拓扑类型会为每个节点创建一个第 2 层段,各自具有不同的子网。第 3 层路由用于互连节点子网。- 3
- 此字段指定拓扑配置。有效值为
layer2
或layer3
。 - 4
- 指定
Primary
或Secondary
角色。Primary
是 4.17 中唯一支持的role
规格。 - 5
- 对于
Layer3
拓扑类型,以下指定subnet
字段的配置详情:-
subnets
字段是必需的。 subnets
字段的类型是cidr
和hostSubnet
:-
cidr
是集群子网,它接受一个字符串值。 -
hostSubnet
指定集群子网分割的节点子网前缀。 -
对于 IPv6,
hostSubnet
仅支持/64
长度。
-
-
运行以下命令来应用您的请求:
$ oc apply -f <my_layer_two_udn.yaml>
其中
<my_layer_two_udn.yaml>
是Layer2
或Layer3
配置文件的名称。运行以下命令验证您的请求是否成功:
$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
其中
some_custom_namespace
是您为用户定义的网络创建的命名空间。输出示例
apiVersion: k8s.ovn.org/v1 kind: UserDefinedNetwork metadata: creationTimestamp: "2024-08-28T17:18:47Z" finalizers: - k8s.ovn.org/user-defined-network-protection generation: 1 name: udn-1 namespace: some-custom-namespace resourceVersion: "53313" uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c spec: layer2: role: Primary subnets: - 10.0.0.0/24 - 2001:db8::/60 topology: Layer2 status: conditions: - lastTransitionTime: "2024-08-28T17:18:47Z" message: NetworkAttachmentDefinition has been created reason: NetworkAttachmentDefinitionReady status: "True" type: NetworkReady
18.2.1.4.1. UserDefinedNetworks CR 的其他配置详情
下表解释了 UDN 的其他配置,它们是可选的。不建议在不明确需要和了解 OVN-Kubernetes 网络拓扑的情况下设置这些字段。
字段 | 类型 | 描述 |
---|---|---|
| object |
如果省略,平台为
|
| object |
|
| 整数 |
最大传输单元 (MTU)。默认值为 |
18.2.2. 使用 NetworkAttachmentDefinition 创建主网络
以下小节解释了如何使用 NetworkAttachmentDefinition
(NAD)资源创建和管理额外的主网络。
18.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>
18.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>
要编辑 CNO 配置,请输入以下命令:
$ oc edit networks.operator.openshift.io cluster
通过为您要创建的额外网络添加配置来修改您要创建的 CR,如下例所示。
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: # ... additionalNetworks: - name: tertiary-net namespace: namespace2 type: Raw rawCNIConfig: |- { "cniVersion": "0.3.1", "name": "tertiary-net", "type": "ipvlan", "master": "eth1", "mode": "l2", "ipam": { "type": "static", "addresses": [ { "address": "192.168.1.23/24" } ] } }
- 保存您的更改,再退出文本编辑器以提交更改。
验证
运行以下命令确认 CNO 创建了
NetworkAttachmentDefinition
CRD。CNO 创建 CRD 之前可能会有延迟。$ oc get network-attachment-definitions -n <namespace>
其中:
<namespace>
- 指定添加到 CNO 配置中的网络附加的命名空间。
输出示例
NAME AGE test-network-1 14m
18.2.2.2.1. 配置额外网络附加
额外网络通过使用 k8s.cni.cncf.io
API 组中的 NetworkAttachmentDefinition
API 来配置。
下表中描述了 API 的配置:
字段 | 类型 | 描述 |
---|---|---|
|
| 额外网络的名称。 |
|
| 与对象关联的命名空间。 |
|
| JSON 格式的 CNI 插件配置。 |
18.2.2.3. 通过应用 YAML 清单来创建额外网络附加
先决条件
-
安装 OpenShift CLI(
oc
)。 -
以具有
cluster-admin
特权的用户身份登录。
流程
使用额外网络配置创建 YAML 文件,如下例所示:
apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: next-net spec: config: |- { "cniVersion": "0.3.1", "name": "work-network", "type": "host-device", "device": "eth1", "ipam": { "type": "dhcp" } }
运行以下命令来创建额外网络:
$ oc apply -f <file>.yaml
其中:
<file>
- 指定包含 YAML 清单的文件名。