第 2 章 主网络
2.1. 关于用户定义的网络 复制链接链接已复制到粘贴板!
在实现用户定义的网络(UDN)之前,OpenShift Container Platform 的 OVN-Kubernetes CNI 插件仅在主或 主 网络上支持第 3 层拓扑。由于 Kubernetes 设计原则:所有 pod 都附加到主网络,所有 pod 都通过其 IP 地址相互通信,并且 pod 间的流量会根据网络策略的限制。
虽然 Kubernetes 设计对简单部署很有用,但此第 3 层拓扑限制自定义主网络段配置,特别是用于现代多租户部署。
UDN 通过启用自定义第 2 层、第 3 层网络段来提高 Kubernetes pod 网络的默认层 3 拓扑的灵活性和分段功能,其中所有这些片段默认被隔离。这些片段充当容器 pod 和使用默认 OVN-Kubernetes CNI 插件的虚拟机的主网络。UDN 启用广泛的网络架构和拓扑,提高网络灵活性、安全性和性能。
在创建用户定义的网络前,使用 cgroupv1
Linux Control Groups (cgroup)的节点必须从 cgroupv1
重新配置为 cgroupv2
。如需更多信息,请参阅配置 Linux cgroup。
集群管理员可以通过利用 ClusterUserDefinedNetwork
自定义资源(CR),使用 UDN 创建并定义跨集群级别多个命名空间的主或二级网络。另外,集群管理员或集群用户可以使用 UDN 使用 UserDefinedNetwork
CR 在命名空间级别定义二级网络。
以下章节进一步强调了用户定义的网络的好处和限制、创建 ClusterUserDefinedNetwork
或 UserDefinedNetwork
CR 时的最佳实践、如何创建 CR 以及与部署相关的其他配置详情。
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。
2.1.2. 用户定义的网络的限制 复制链接链接已复制到粘贴板!
虽然用户定义的网络 (UDN) 提供了高度可自定义的网络配置选项,但集群管理员和开发人员在实施和管理这些网络时应了解其中的一些限制。在实施 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 在默认网络中是健康的,但在主接口中存在连接问题的情况。
- 网络策略限制 :启用连接到不同用户定义的主网络的命名空间之间的流量的网络策略无效。这些流量策略不会生效,因为这些隔离的网络之间没有连接。
-
创建和编辑限制 :在创建后无法修改
ClusterUserDefinedNetwork
CR 和UserDefinedNetwork
CR。 -
默认网络服务访问 :用户定义的网络 pod 与默认网络隔离,这意味着无法访问大多数默认网络服务。例如,用户定义的网络 pod 目前无法访问 OpenShift Container Platform 镜像 registry。由于这个限制,source-to-image 构建无法在用户定义的网络命名空间中工作。另外,其他功能无法正常工作,包括基于 Git 存储库中的源代码创建应用程序的功能,如
oc new-app <command>
,以及从使用 source-to-image 构建的 OpenShift Container Platform 模板创建应用程序的功能。这个限制可能会影响其他openshift channel.svc
服务。 - 连接限制 :用户定义的网络上的 NodePort 服务无法保证隔离。例如,无法从 pod 到同一节点上的服务访问 NodePort 流量,而不同节点上的 pod 的流量会成功。
-
IP 地址耗尽的不明确错误消息 :当用户定义的网络的子网没有可用 IP 地址时,新 pod 无法启动。当发生这种情况时,会返回以下错误:
Warning: Failed to create pod sandbox
。这个错误消息没有明确地指定 IP 独立性是原因。要确认这个问题,您可以检查 OpenShift Container Platform Web 控制台上 pod 命名空间中的 Events 页面,其中报告了有关子网耗尽的明确消息。
2.1.3. 第 2 层和第 3 层拓扑 复制链接链接已复制到粘贴板!
扁平第 2 层拓扑会创建一个虚拟交换机,该交换机分布到集群中的所有节点上。虚拟机和 pod 连接到此虚拟交换机,以便所有这些组件都可以在同一子网内相互通信。扁平第 2 层拓扑可用于在集群中存在的节点间实时迁移虚拟机。下图显示了一个扁平第 2 层拓扑,其中有两个节点使用虚拟交换机进行实时迁移:
图 2.1. 使用虚拟交换机进行组件通信的平面第 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 处理节点流量,以便将虚拟机从一个节点实时迁移到另一个节点。
图 2.2. 使用第 2 层拓扑的用户定义的网络(UDN)
第 3 层拓扑为集群中的每个节点创建一个唯一的第 2 层片段。第 3 层路由机制会连接这些片段,以便在不同节点上托管的虚拟机和 pod 可以相互通信。第 3 层拓扑可以通过将每个域分配给特定节点来有效地管理大型广播域,以便广播流量的范围减少。要配置第 3 层拓扑,您必须配置 cidr
和 hostSubnet
参数。
2.1.4. 关于 ClusterUserDefinedNetwork CR 复制链接链接已复制到粘贴板!
ClusterUserDefinedNetwork
(UDN)自定义资源(CR)仅为管理员提供集群范围的网络分段和隔离。
下图显示了集群管理员如何使用 ClusterUserDefinedNetwork
CR 在租户之间创建网络隔离。此网络配置允许网络跨越多个命名空间。在图中,通过创建两个用户定义的网络( udn-1
和 udn
-2)来实现网络隔离。这些网络没有连接,并且 spec.namespaceSelector.matchLabels
字段用于选择不同的命名空间。例如,udn-1
配置和隔离 namespace-1
和 namespace-2
的通信,而 udn-2
配置和隔离 namespace-3
和 namespace-4
。隔离的租户(Tenants 1 和 Tenants 2)是通过分离命名空间来创建的,同时允许同一命名空间中的 pod 进行通信。
图 2.3. 使用 ClusterUserDefinedNetwork CR 的租户隔离
2.1.4.1. ClusterUserDefinedNetwork CR 的最佳实践 复制链接链接已复制到粘贴板!
在设置 ClusterUserDefinedNetwork
自定义资源(CR)前,用户应考虑以下信息:
-
ClusterUserDefinedNetwork
CR 供集群管理员使用,非管理员用户不应该使用。如果错误地使用,可能会导致部署出现安全问题,从而导致中断或破坏集群网络。 -
ClusterUserDefinedNetwork
CR 不应该选择default
命名空间。这可能导致没有隔离,因此可能会给集群带来安全风险。 -
ClusterUserDefinedNetwork
CR 不应该选择openshift channel
命名空间。 OpenShift Container Platform 管理员应该注意,当满足以下条件之一时,选择集群的所有命名空间:
-
matchLabels
选择器为空。 -
matchExpressions
选择器留空。 -
namespaceSelector
被初始化,但没有指定matchExpressions
或matchLabel
。例如:namespaceSelector: {}
。
-
对于主网络,用于
ClusterUserDefinedNetwork
CR 的命名空间必须包含k8s.ovn.org/primary-user-defined-network
标签。此标签无法更新,只能在创建命名空间时添加。以下条件适用于k8s.ovn.org/primary-user-defined-network
命名空间标签:-
如果命名空间缺少
k8s.ovn.org/primary-user-defined-network
标签并创建 pod,则 pod 会将自身附加到 default 网络。 -
如果命名空间缺少
k8s.ovn.org/primary-user-defined-network
标签,并且创建与命名空间匹配的主ClusterUserDefinedNetwork
CR,则会报告错误,且不会创建网络。 -
如果命名空间缺少
k8s.ovn.org/primary-user-defined-network
标签,且主ClusterUserDefinedNetwork
CR 已存在,则会创建命名空间中的 pod 并附加到 default 网络。 -
如果命名空间有标签,并且不存在主
ClusterUserDefinedNetwork
CR,则在创建ClusterUserDefinedNetwork
CR 前不会创建命名空间中的 pod。
-
如果命名空间缺少
2.1.4.2. 使用 CLI 创建 ClusterUserDefinedNetwork CR 复制链接链接已复制到粘贴板!
以下流程使用 CLI 创建 ClusterUserDefinedNetwork
自定义资源 (CR)。根据您的用例,使用 cluster-layer-two-udn.yaml
示例(Layer2
拓扑类型)或 cluster-layer-three-udn.yaml
示例(Layer3
拓扑类型)创建您的请求。
-
ClusterUserDefinedNetwork
CR 供集群管理员使用,非管理员用户不应该使用。如果错误地使用,可能会导致部署出现安全问题,从而导致中断或破坏集群网络。 -
OpenShift Virtualization 只支持
Layer2
拓扑。
先决条件
-
您已以具有
cluster-admin
权限的用户身份登录。
流程
可选: 对于使用主网络的
ClusterUserDefinedNetwork
CR,请输入以下命令创建带有k8s.ovn.org/primary-user-defined-network
标签的命名空间:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 为
Layer2
或Layer3
拓扑类型集群范围的用户定义的网络创建请求:创建 YAML 文件,如
cluster-layer-two-udn.yaml
,为Layer2
拓扑定义请求,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
CR 的名称。- 2
- 集群 UDN CR 应用到的命名空间集合上的标签查询。使用标准 Kubernetes
MatchLabel
选择器。不得指向default
或openshift channel
命名空间。 - 3
- 使用
matchLabels
选择器类型,其中使用AND
关系评估术语。 - 4 5
- 因为使用了
matchLabels
选择器类型,因此会置备包含<label_1_key>=<label_1_value>
和<label_2_key>=<label_2_value>
标签的命名空间。 - 6
- 描述网络配置。
- 7
topology
字段描述了网络配置;接受的值是Layer2
和Layer3
。指定Layer2
拓扑类型会创建一个逻辑交换机,它被所有节点共享。- 8
- 此字段指定拓扑配置。它可以是
layer2
或layer3
。 - 9
- 指定
Primary
或Secondary
。Primary
是 4.18 中唯一支持的role
规格。 - 10
- 对于
Layer2
拓扑类型,以下指定subnet
字段的配置详情:- subnets 字段是可选的。
-
subnets 字段的类型是
字符串
,接受 IPv4 和 IPv6 的标准 CIDR 格式。 -
subnets 字段接受一个或多个项。如果是两个项,它们必须属于不同的系列。例如,子网值
10.100.0.0/16
和2001:db8::/64
。 -
可以省略
Layer2
子网。如果省略,用户必须为 pod 配置静态 IP 地址。因此,端口安全性只能阻止 MAC 欺骗。如需更多信息,请参阅"使用静态 IP 地址配置 pod"。
创建 YAML 文件,如
cluster-layer-three-udn.yaml
,为Layer3
拓扑定义您的请求,如下例所示:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
CR 的名称。- 2
- 集群 UDN 应用到的命名空间集合上的标签查询。使用标准 Kubernetes
MatchLabel
选择器。不得指向default
或openshift channel
命名空间。 - 3
- 使用
matchExpressions
选择器类型,其中使用OR
关系评估术语。 - 4
- 指定要匹配的标签键。
- 5
- 指定 operator。有效值包括:
In
,NotIn
,Exists
, 和DoesNotExist
。 - 6
- 因为使用了
matchExpressions
类型,因此置备命名空间与<example_namespace_one>
或<example_namespace_two>
匹配。 - 7
- 描述网络配置。
- 8
topology
字段描述了网络配置;接受的值是Layer2
和Layer3
。指定Layer3
拓扑类型会为每个节点创建一个第 2 层段,各自具有不同的子网。第 3 层路由用于互连节点子网。- 9
- 此字段指定拓扑配置。有效值为
layer2
或layer3
。 - 10
- 指定
Primary
或Secondary
角色。Primary
是 4.18 中唯一支持的role
规格。 - 11
- 对于
Layer3
拓扑类型,以下指定subnet
字段的配置详情:-
subnets
字段是必需的。 subnets
字段的类型是cidr
和hostSubnet
:-
cidr
是集群子网,它接受一个字符串值。 -
hostSubnet
指定集群子网分割的节点子网前缀。 -
对于 IPv6,
hostSubnet
仅支持/64
长度。
-
-
运行以下命令来应用您的请求:
oc create --validate=true -f <example_cluster_udn>.yaml
$ oc create --validate=true -f <example_cluster_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<example_cluster_udn>.yaml
是Layer2
或Layer3
配置文件的名称。运行以下命令验证您的请求是否成功:
oc get clusteruserdefinednetwork <cudn_name> -o yaml
$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 其中
<cudn_name>
是您创建集群范围的用户定义的网络的名称。输出示例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.4.3. 使用 Web 控制台创建 ClusterUserDefinedNetwork CR 复制链接链接已复制到粘贴板!
您可以在 OpenShift Container Platform Web 控制台中使用 Layer2
拓扑创建 ClusterUserDefinedNetwork
自定义资源(CR)。
目前,在使用 OpenShift Container Platform Web 控制台时不支持使用 Layer3
拓扑创建 ClusterUserDefinedNetwork
CR。
先决条件
-
您可以使用具有
cluster-admin
权限的用户访问 OpenShift Container Platform Web 控制台。 -
您已创建了命名空间,并应用
k8s.ovn.org/primary-user-defined-network
标签。
流程
-
从 Administrator 视角中,点 Networking
UserDefinedNetworks。 - 点 ClusterUserDefinedNetwork。
- 在 Name 字段中,为集群范围的 UDN 指定名称。
- 在 Subnet 字段中指定一个值。
- 在 Project (s) Match Labels 字段中,添加适当的标签以选择集群 UDN 应用到的命名空间。
- 点 Create。集群范围的 UDN 充当位于命名空间中 pod 的默认主网络,其中包含在第 5 步中指定的标签。
2.1.5. 关于 UserDefinedNetwork CR 复制链接链接已复制到粘贴板!
UserDefinedNetwork
(UDN)自定义资源(CR)为用户和管理员提供高级网络分段和隔离。
下图显示了四个集群命名空间,其中每个命名空间都有一个分配的用户定义的网络(UDN),每个 UDN 都有一个用于其 pod IP 分配的自定义子网。OVN-Kubernetes 处理任何重叠的 UDN 子网。如果不使用 Kubernetes 网络策略,附加到 UDN 的 pod 可以与 UDN 中的其他 pod 通信。默认情况下,这些 pod 与其他 UDNs 中存在的 pod 通信。对于微分段,您可以在 UDN 中应用网络策略。您可以将一个或多个 UDN 分配给命名空间,限制为命名空间一个主 UDN,并将一个或多个命名空间分配给 UDN。
图 2.4. 使用 UserDefinedNetwork CR 进行命名空间隔离
2.1.5.1. UserDefinedNetwork CR 的最佳实践 复制链接链接已复制到粘贴板!
在设置 UserDefinedNetwork
自定义资源(CR)前,您应该考虑以下信息:
-
openshift-*
命名空间不应用于设置UserDefinedNetwork
CR。 -
UserDefinedNetwork
CR 不应在 default 命名空间中创建。这可能导致没有隔离,因此可能会给集群带来安全风险。 对于主网络,用于
UserDefinedNetwork
CR 的命名空间必须包含k8s.ovn.org/primary-user-defined-network
标签。此标签无法更新,只能在创建命名空间时添加。以下条件适用于k8s.ovn.org/primary-user-defined-network
命名空间标签:-
如果命名空间缺少
k8s.ovn.org/primary-user-defined-network
标签并创建 pod,则 pod 会将自身附加到 default 网络。 -
如果命名空间缺少
k8s.ovn.org/primary-user-defined-network
标签,并且创建一个与命名空间匹配的主UserDefinedNetwork
CR,则会报告状态错误,且不会创建网络。 -
如果命名空间缺少
k8s.ovn.org/primary-user-defined-network
标签和主UserDefinedNetwork
CR,则会创建命名空间中的 pod 并附加到 default 网络。 -
如果命名空间有标签,并且不存在主
UserDefinedNetwork
CR,则在创建UserDefinedNetwork
CR 前不会创建命名空间中的 pod。
-
如果命名空间缺少
用户定义的网络需要 2 个伪装 IP 地址。您必须重新配置伪装子网,使其足够大,以容纳所需的网络数量。
重要-
对于 OpenShift Container Platform 4.17 及更新的版本,集群使用
169.254.0.0/17
(IPv4),或fd69::/112
(IPv6)作为默认的伪装子网。用户应避免这些范围。对于更新的集群,默认 masquerade 子网没有变化。 -
在为项目配置了用户定义的网络后,不支持更改集群的伪装子网。在设置
UserDefinedNetwork
CR 后尝试修改伪装子网可能会破坏网络连接并导致配置问题。
-
对于 OpenShift Container Platform 4.17 及更新的版本,集群使用
-
确保租户使用
UserDefinedNetwork
资源,而不是NetworkAttachmentDefinition
(NAD) CR。这可以在租户之间造成安全风险。 -
在创建网络分段时,只有在无法使用
UserDefinedNetwork
CR 完成用户定义的网络分段时,才应使用NetworkAttachmentDefinition
CR。 -
UserDefinedNetwork
CR 的集群子网和服务 CIDR 无法与默认集群子网 CIDR 重叠。OVN-Kubernetes 网络插件使用100.64.0.0/16
作为网络的默认加入子网。您不能使用该值来配置UserDefinedNetwork
CR 的joinSubnets
字段。如果在网络中为集群使用默认地址值,则必须通过设置joinSubnets
字段来覆盖默认值。如需更多信息,请参阅"为用户定义的项目添加配置详情"。
2.1.5.2. 使用 CLI 创建 UserDefinedNetwork CR 复制链接链接已复制到粘贴板!
以下流程创建有命名空间范围的 UserDefinedNetwork
CR。根据您的用例,创建您的请求,使用 my-layer-two-udn.yaml
示例用于 Layer2
拓扑类型,或使用 my-layer-three-udn.yaml
示例用于 Layer3
拓扑类型。
前提条件
-
您已使用
cluster-admin
权限登录,或者您有view
和edit
基于角色的访问控制(RBAC)。
流程
可选: 对于使用主网络的
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
2.1.5.3. 使用 Web 控制台创建 UserDefinedNetwork CR 复制链接链接已复制到粘贴板!
您可以使用 OpenShift Container Platform Web 控制台创建具有 Layer2
拓扑和 Primary
角色的 UserDefinedNetwork
自定义资源(CR)。
目前,在使用 OpenShift Container Platform Web 控制台时不支持使用 Layer3
拓扑或 Secondary
角色创建 UserDefinedNetwork
CR。
先决条件
-
您可以使用具有
cluster-admin
权限的用户访问 OpenShift Container Platform Web 控制台。 -
您已创建了命名空间,并应用
k8s.ovn.org/primary-user-defined-network
标签。
流程
-
从 Administrator 视角中,点 Networking
UserDefinedNetworks。 - 点 Create UserDefinedNetwork。
- 从 Project name 列表中,选择您之前创建的命名空间。
- 在 Subnet 字段中指定一个值。
- 点 Create。用户定义的网络充当您在此命名空间中创建的 pod 的默认主网络。
2.1.6. 用户定义的网络的其他配置详情 复制链接链接已复制到粘贴板!
下表解释了 ClusterUserDefinedNetwork
和 UserDefinedNetwork
自定义资源(CR)的额外配置,它们是可选的。不建议在不明确需要和了解 OVN-Kubernetes 网络拓扑的情况下设置这些字段。
- 用户定义的网络的可选配置
CUDN 字段 | UDN 字段 | 类型 | 描述 |
|
| object |
如果省略,平台为
|
|
| object |
只有在 |
|
| object |
Enabled:
Disabled: |
|
| 整数 |
最大传输单元 (MTU)。默认值为 |
其中:
<topology>
-
是
第 2 层或第
3 层
之一。
2.1.7. 用户定义的网络状态条件类型 复制链接链接已复制到粘贴板!
下表解释在描述资源时为 ClusterUserDefinedNetwork
和 UserDefinedNetwork
CR 返回的状态条件类型。这些条件可用于对您的部署进行故障排除。
状况类型 | Status | 原因和消息 | |
---|---|---|---|
|
|
为 | |
原因 | 消息 | ||
| 'NetworkAttachmentDefinition 在以下命名空间中创建:[example-namespace-1, example-namespace-2, example-namespace-3]' | ||
|
|
当 | |
原因 | 消息 | ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
|
状况类型 | Status | 原因和消息 | |
---|---|---|---|
|
|
为 | |
原因 | 消息 | ||
|
| ||
|
|
当 | |
原因 | 消息 | ||
|
|
2.1.8. 在用户定义的网络 pod 中打开默认网络端口 复制链接链接已复制到粘贴板!
默认情况下,用户定义的网络上的 pod 与默认网络隔离。这意味着默认网络 pod (如运行监控服务(Prometheus 或 Alertmanager)或 OpenShift Container Platform 镜像 registry 等无法启动到 UDN pod 的连接。
要允许默认网络 pod 连接到用户定义的网络 pod,您可以使用 k8s.ovn.org/open-default-ports
注解。此注解在用户定义的网络 pod 上打开特定的端口,以便从默认网络访问。
以下 pod 规格允许从默认网络端口 53
上的端口 80
和 UDP 流量进入 TCP 连接:
打开端口可在 pod 的默认网络 IP 上访问,而不是其 UDN 网络 IP。