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 定义额外网络的功能。

以下章节进一步强调了用户定义的网络的好处和限制、创建 ClusterUserDefinedNetworkUserDefinedNetwork 自定义资源、如何创建自定义资源以及可能与您的部署相关的其他配置详情。

18.2.1.1. 用户定义的网络的好处

用户定义的网络具有以下优点:

  1. 增强了用于安全性的网络隔离

    • 租户隔离 :命名空间可以有自己的隔离主网络,类似于在 Red Hat OpenStack Platform (RHOSP) 中隔离租户的方式。这通过降低跨租户流量的风险来提高安全性。
  2. 网络灵活性

    • Layer 2 和 layer 3 的支持:集群管理员可以将主网络配置为 Layer 2 或 layer 3 网络类型。这为主网络提供了二级网络所具有的灵活性。
  3. 简化网络管理

    • 降低网络配置复杂性:使用用户定义的网络,可以通过对不同网络中的工作负载进行分组来实现隔离。从而消除了对复杂网络策略的需求。
  4. 高级功能

    • 一致且可选择的 IP 寻址 :用户可以在不同的命名空间和集群间指定并重复使用 IP 子网,从而提供一致的网络环境。
    • 支持多个网络:用户定义的网络功能允许管理员将多个命名空间连接到单个网络,或者为不同的命名空间组创建不同的网络。
  5. 简化了从 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 后尝试修改伪装子网可能会破坏网络连接并导致配置问题。
  • 确保租户使用 UserDefinedNetwork 资源,而不是 NetworkAttachmentDefinition (NAD) 资源。这可以在租户之间造成安全风险。
  • 在创建网络分段时,只有在无法使用 UDN 资源完成用户定义的网络分段时,才应使用 NAD 资源。
  • UDN 的集群子网和服务 CIDR 无法与默认集群子网 CIDR 重叠。OVN-Kubernetes 网络插件使用 100.64.0.0/16 作为默认网络加入子网,不得使用该值来配置 UDN JoinSubnets 字段。如果在集群网络的任何位置使用默认地址值,则必须通过设置 joinSubnets 字段来覆盖它。如需更多信息,请参阅 "UserDefinedNetworks CR 的附加配置详情"。

18.2.1.4. 创建 UserDefinedNetwork 自定义资源

以下流程创建命名空间范围的用户定义网络。根据您的用例,创建您的请求,使用 my-layer-two-udn.yaml 示例用于 Layer2 拓扑类型,或使用 my-layer-three-udn.yaml 示例用于 Layer3 拓扑类型。

流程

  1. Layer2Layer3 拓扑类型用户定义的网络创建请求:

    1. 创建一个 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 字段描述了网络配置;接受的值是 Layer2Layer3。指定 Layer2 拓扑类型会创建一个逻辑交换机,它被所有节点共享。
      3
      此字段指定拓扑配置。它可以是 layer2layer3
      4
      指定 PrimarySecondary。在 4.17 中,Primary 是唯一支持的 role 规格。
      5
      对于 Layer2 拓扑类型,以下指定 subnet 字段的配置详情:
      • subnets 字段是可选的。
      • subnets 字段的类型是字符串,接受 IPv4 和 IPv6 的标准 CIDR 格式。
      • subnets 字段接受一个或多个项。如果是两个项,它们必须属于不同的系列。例如,子网值 10.100.0.0/162001:db8::/64
      • 可以省略 Layer2 子网。如果省略,用户需要为 pod 配置 IP 地址。因此,端口安全性只能阻止 MAC 欺骗。
      • 当指定 ipamLifecycle 字段时,Layer2 subnets 字段是必须的。
    2. 创建一个 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 字段描述了网络配置;接受的值是 Layer2Layer3。指定 Layer3 拓扑类型会为每个节点创建一个第 2 层段,各自具有不同的子网。第 3 层路由用于互连节点子网。
      3
      此字段指定拓扑配置。有效值为 layer2layer3
      4
      指定 PrimarySecondary 角色。Primary 是 4.17 中唯一支持的 role 规格。
      5
      对于 Layer3 拓扑类型,以下指定 subnet 字段的配置详情:
      • subnets 字段是必需的。
      • subnets 字段的类型是 cidrhostSubnet

        • cidr 是集群子网,它接受一个字符串值。
        • hostSubnet 指定集群子网分割的节点子网前缀。
        • 对于 IPv6,hostSubnet 仅支持 /64 长度。
  2. 运行以下命令来应用您的请求:

    $ oc apply -f <my_layer_two_udn.yaml>

    其中 <my_layer_two_udn.yaml>Layer2Layer3 配置文件的名称。

  3. 运行以下命令验证您的请求是否成功:

    $ 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 网络拓扑的情况下设置这些字段。

表 18.1. UserDefinedNetworks 可选配置
字段类型描述

spec.joinSubnets

object

如果省略,平台为 joinSubnets 设置默认值 100.65.0.0/16(IPv4)和 fd99::/64(IPv6)。如果在集群网络的任何位置使用默认地址值,则必须通过设置 joinSubnets 字段来覆盖它。如果您选择设置此字段,请确保它与集群中的其他子网没有冲突(如集群子网、default 网络集群和 masquerade 子网)。

joinSubnets 字段配置一个用户定义的网络中的不同段之间的路由。双栈集群可以设置 2 个子网,每个 IP 系列一个;否则,只设置 1 个子网。此字段仅适用于 Primary 网络。

spec.IPAMLifecycle

object

IPAMLifecycle 字段配置 IP 地址管理系统 (IPAM)。对于虚拟工作负载,您可以使用此字段来确保持久的 IP 地址。当 topologylayer2 时,允许此字段。在指定此字段时,必须指定 subnets 字段。设置 Persistent 值可确保您的虚拟工作负载在重启后 IP 地址不会有变化(具有持久性)。由容器网络接口 (CNI) 分配,并由 OVN-Kubernetes 使用来编程 pod IP 地址。对于 pod 注解,不得更改它。

spec.layer2.mtuspec.layer3.mtu

整数

最大传输单元 (MTU)。默认值为 1400。IPv4 的边界是 574,IPv6 为 1280

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 特权的用户身份登录。

流程

  1. 可选:为额外网络创建命名空间:

    $ oc create namespace <namespace_name>
  2. 要编辑 CNO 配置,请输入以下命令:

    $ oc edit networks.operator.openshift.io cluster
  3. 通过为您要创建的额外网络添加配置来修改您要创建的 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"
                }
              ]
            }
          }
  4. 保存您的更改,再退出文本编辑器以提交更改。

验证

  • 运行以下命令确认 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 的配置:

表 18.2. NetworkAttachmentDefinition API 字段
字段类型描述

metadata.name

string

额外网络的名称。

metadata.namespace

string

与对象关联的命名空间。

spec.config

string

JSON 格式的 CNI 插件配置。

18.2.2.3. 通过应用 YAML 清单来创建额外网络附加

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 使用额外网络配置创建 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"
          }
        }
  2. 运行以下命令来创建额外网络:

    $ oc apply -f <file>.yaml

    其中:

    <file>
    指定包含 YAML 清单的文件名。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.