×

如何选择网络接口

对于裸机安装或具有多个网络接口控制器 (NIC) 的虚拟机,OpenShift Container Platform 用于与 Kubernetes API 服务器通信的 NIC 由 systemd 在节点启动时运行的nodeip-configuration.service 服务单元确定。nodeip-configuration.service 选择与默认路由关联的接口中的 IP。

nodeip-configuration.service 服务确定正确的 NIC 后,它会创建/etc/systemd/system/kubelet.service.d/20-nodenet.conf 文件。20-nodenet.conf 文件将KUBELET_NODE_IP 环境变量设置为服务选择的 IP 地址。

kubelet 服务启动时,它会从20-nodenet.conf 文件读取环境变量的值,并将 IP 地址设置为--node-ip kubelet 命令行参数的值。因此,kubelet 服务使用选定的 IP 地址作为节点 IP 地址。

如果在安装后重新配置了硬件或网络,或者网络布局中节点 IP 不应来自默认路由接口,则nodeip-configuration.service 服务可能会在重新引导后选择不同的网卡。在某些情况下,您可以通过查看oc get nodes -o wide命令输出中的INTERNAL-IP列来检测是否选择了不同的网卡。

如果由于选择了不同的网卡而导致网络通信中断或配置错误,您可能会收到以下错误:EtcdCertSignerControllerDegraded。您可以创建一个包含NODEIP_HINT变量的提示文件来覆盖默认的 IP 选择逻辑。有关更多信息,请参见可选:覆盖默认节点 IP 选择逻辑。

可选:覆盖默认节点 IP 选择逻辑

要覆盖默认的 IP 选择逻辑,您可以创建一个包含NODEIP_HINT变量的提示文件来覆盖默认的 IP 选择逻辑。创建提示文件允许您从NODEIP_HINT变量中指定的 IP 地址子网中的接口中选择特定的节点 IP 地址。

例如,如果一个节点有两个接口,eth0 的地址为10.0.0.10/24eth1 的地址为192.0.2.5/24,并且默认路由指向eth0 (10.0.0.10),则节点 IP 地址通常会使用10.0.0.10 IP 地址。

用户可以配置NODEIP_HINT变量指向子网中的已知 IP,例如子网网关,例如192.0.2.1,以便选择另一个子网192.0.2.0/24。结果,eth1上的192.0.2.5 IP 地址将用于节点。

以下步骤显示了如何覆盖默认节点 IP 选择逻辑。

步骤
  1. 将提示文件添加到您的/etc/default/nodeip-configuration文件中,例如:

    NODEIP_HINT=192.0.2.1
    • 不要使用节点的精确 IP 地址作为提示,例如192.0.2.5。使用节点的精确 IP 地址会导致使用提示 IP 地址的节点无法正确配置。

    • 提示文件中的 IP 地址仅用于确定正确的子网。它不会因为出现在提示文件中而接收流量。

  2. 运行以下命令生成base-64编码的内容:

    $ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0
    示例输出
    Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==
  3. 在部署集群之前,为masterworker角色创建机器配置清单来激活提示

    99-nodeip-hint-master.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-nodeip-hint-master
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<encoded_content> (1)
            mode: 0644
            overwrite: true
            path: /etc/default/nodeip-configuration
    1 <encoded_contents>替换为/etc/default/nodeip-configuration文件的base64编码内容,例如Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==。请注意,逗号后和编码内容前不允许有空格。
    99-nodeip-hint-worker.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
       name: 99-nodeip-hint-worker
    spec:
     config:
       ignition:
         version: 3.2.0
       storage:
         files:
         - contents:
             source: data:text/plain;charset=utf-8;base64,<encoded_content> (1)
           mode: 0644
           overwrite: true
           path: /etc/default/nodeip-configuration
    1 <encoded_contents>替换为/etc/default/nodeip-configuration文件的base64编码内容,例如Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==。请注意,逗号后和编码内容前不允许有空格。
  4. 将清单保存到您存储集群配置的目录中,例如~/clusterconfigs

  5. 部署集群。

配置 OVN-Kubernetes 使用辅助 OVS 网桥

您可以创建一个额外的或辅助的 Open vSwitch (OVS) 网桥br-ex1,OVN-Kubernetes 管理该网桥,并且多外部网关 (MEG) 实现使用该网桥来定义 OpenShift Container Platform 节点的外部网关。您可以在AdminPolicyBasedExternalRoute自定义资源 (CR) 中定义 MEG。MEG 实现为 pod 提供对多个网关、等价代价多路径 (ECMP) 路由和双向转发检测 (BFD) 实现的访问。

考虑一下受多外部网关 (MEG) 功能影响的 pod 的用例,您希望将流量传出到节点上的另一个接口,例如br-ex1。对于不受 MEG 影响的 pod 的传出流量将路由到默认的 OVS br-ex 网桥。

目前,MEG 不支持与其他传出功能一起使用,例如传出 IP、传出防火墙或传出路由器。尝试将 MEG 与传出 IP 等传出功能一起使用可能会导致路由和流量冲突。这是因为 OVN-Kubernetes 如何处理路由和源网络地址转换 (SNAT)。这会导致路由不一致,并可能破坏某些环境中的连接,在这些环境中,返回路径必须修补传入路径。

您必须在机器配置清单文件的接口定义中定义附加网桥。机器配置操作员使用清单在主机上的/etc/ovnk/extra_bridge创建一个新文件。新文件包含附加 OVS 网桥为节点配置的网络接口的名称。

创建并编辑清单文件后,机器配置操作员将按以下顺序完成任务:

  1. 基于选择的机器配置池,按单个顺序排出节点。

  2. 将 Ignition 配置文件注入到每个节点中,以便每个节点接收额外的br-ex1网桥网络配置。

  3. 验证br-ex MAC 地址是否与br-ex用于网络连接的接口的 MAC 地址匹配。

  4. 执行引用新接口定义的configure-ovs.sh shell 脚本。

  5. br-exbr-ex1添加到主机节点。

  6. 取消隔离节点。

在所有节点返回到Ready状态并且 OVN-Kubernetes 运算符检测并配置br-exbr-ex1后,运算符会将k8s.ovn.org/l3-gateway-config注释应用于每个节点。

有关附加br-ex1网桥的有用情况以及始终需要默认br-ex网桥的情况的更多信息,请参见“本地网拓扑的配置”。

步骤
  1. 可选:通过完成以下步骤,创建一个您的附加网桥br-ex1可以使用的接口连接。示例步骤显示了新绑定及其所有在机器配置清单文件中定义的依赖接口的创建。附加网桥使用MachineConfig对象来形成附加绑定接口。

    不要使用 Kubernetes NMState 运算符或NodeNetworkConfigurationPolicy (NNCP) 清单文件来定义附加接口。

    还要确保在定义bond接口时,附加接口或子接口不被现有的br-ex OVN Kubernetes 网络部署使用。

    1. 创建以下接口定义文件。这些文件将添加到机器配置清单文件中,以便主机节点可以访问定义文件。

      名为eno1.config的第一个接口定义文件的示例
      [connection]
      id=eno1
      type=ethernet
      interface-name=eno1
      master=bond1
      slave-type=bond
      autoconnect=true
      autoconnect-priority=20
      名为eno2.config的第二个接口定义文件的示例
      [connection]
      id=eno2
      type=ethernet
      interface-name=eno2
      master=bond1
      slave-type=bond
      autoconnect=true
      autoconnect-priority=20
      名为bond1.config的第二个绑定接口定义文件的示例
      [connection]
      id=bond1
      type=bond
      interface-name=bond1
      autoconnect=true
      connection.autoconnect-slaves=1
      autoconnect-priority=20
      
      [bond]
      mode=802.3ad
      miimon=100
      xmit_hash_policy="layer3+4"
      
      [ipv4]
      method=auto
    2. 运行以下命令将定义文件转换为 Base64 编码字符串:

      $ base64 <directory_path>/en01.config
      $ base64 <directory_path>/eno2.config
      $ base64 <directory_path>/bond1.config
  2. 准备环境变量。将<machine_role>替换为节点角色,例如worker,并将<interface_name>替换为您附加的br-ex网桥名称。

    $ export ROLE=<machine_role>
  3. 在机器配置清单文件中定义每个接口定义

    包含为bond1eno1en02添加的定义的机器配置文件示例
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: ${worker}
      name: 12-${ROLE}-sec-bridge-cni
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:;base64,<base-64-encoded-contents-for-bond1.conf>
            path: /etc/NetworkManager/system-connections/bond1.nmconnection
            filesystem: root
            mode: 0600
          - contents:
              source: data:;base64,<base-64-encoded-contents-for-eno1.conf>
            path: /etc/NetworkManager/system-connections/eno1.nmconnection
            filesystem: root
            mode: 0600
          - contents:
              source: data:;base64,<base-64-encoded-contents-for-eno2.conf>
            path: /etc/NetworkManager/system-connections/eno2.nmconnection
            filesystem: root
            mode: 0600
    # ...
  4. 通过在终端中输入以下命令创建用于配置网络插件的机器配置清单文件:

    $ oc create -f <machine_config_file_name>
  5. 使用 OVN-Kubernetes 网络插件在节点上创建一个 Open vSwitch (OVS) 桥接器 br-ex1,方法是创建一个 extra_bridge 文件。确保将文件保存在主机的 /etc/ovnk/extra_bridge 路径下。该文件必须指定支持附加桥接器的接口名称,而不是支持 br-ex 的默认接口(该接口持有节点的主 IP 地址)。

    extra_bridge 文件(/etc/ovnk/extra_bridge)的示例配置,引用了附加接口。
    bond1
  6. 创建一个机器配置清单文件,该文件定义了在集群中重新启动的任何节点上承载 br-ex1 的现有静态接口。

    一个机器配置文件示例,该文件将 bond1 定义为承载 br-ex1 的接口。
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: ${worker}
      name: 12-worker-extra-bridge
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
            - path: /etc/ovnk/extra_bridge
              mode: 0420
              overwrite: true
              contents:
                source: data:text/plain;charset=utf-8,bond1
              filesystem: root
  7. 将机器配置应用于您选择的节点。

    $ oc create -f <machine_config_file_name>
  8. 可选:您可以通过创建一个机器配置文件来覆盖节点的 br-ex 选择逻辑,该文件又会创建一个 /var/lib/ovnk/iface_default_hint 资源。

    该资源列出了 br-ex 为您的集群选择的接口名称。默认情况下,br-ex 基于引导顺序和机器网络中的 IP 地址子网为节点选择主接口。某些机器网络配置可能需要 br-ex 继续为主机节点选择默认接口或绑定。

    1. 在主机节点上创建一个机器配置文件以覆盖默认接口。

      仅出于更改 br-ex 选择逻辑的目的创建此机器配置文件。不支持使用此文件更改集群中现有节点的 IP 地址。

      覆盖默认接口的机器配置文件示例。
      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: ${worker}
        name: 12-worker-br-ex-override
      spec:
        config:
          ignition:
            version: 3.2.0
          storage:
            files:
              - path: /var/lib/ovnk/iface_default_hint
                mode: 0420
                overwrite: true
                contents:
                  source: data:text/plain;charset=utf-8,bond0 (1)
                filesystem: root
      1 在将机器配置文件应用于节点之前,请确保节点上存在 bond0
    2. 在将配置应用于集群中的所有新节点之前,请重新引导主机节点以验证 br-ex 是否选择了预期的接口,并且不会与您在 br-ex1 上定义的新接口冲突。

    3. 将机器配置文件应用于集群中的所有新节点。

      $ oc create -f <machine_config_file_name>
验证
  1. 识别集群中带有 exgw-ip-addresses 标签的节点的 IP 地址,以验证节点是否使用附加桥接器而不是默认桥接器。

    $ oc get nodes -o json | grep --color exgw-ip-addresses
    示例输出
    "k8s.ovn.org/l3-gateway-config":
       \"exgw-ip-address\":\"172.xx.xx.yy/24\",\"next-hops\":[\"xx.xx.xx.xx\"],
  2. 通过查看主机节点上的网络接口名称来观察目标节点上是否存在附加桥接器。

    $ oc debug node/<node_name> -- chroot /host sh -c "ip a | grep mtu | grep br-ex"
    示例输出
    Starting pod/worker-1-debug ...
    To use host binaries, run `chroot /host`
    # ...
    5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    6: br-ex1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
  3. 可选:如果您使用 /var/lib/ovnk/iface_default_hint,请检查 br-ex 的 MAC 地址是否与所选主接口的 MAC 地址匹配。

    $ oc debug node/<node_name> -- chroot /host sh -c "ip a | grep -A1 -E 'br-ex|bond0'
    显示 br-ex 的主接口为 bond0 的示例输出。
    Starting pod/worker-1-debug ...
    To use host binaries, run `chroot /host`
    # ...
    sh-5.1# ip a | grep -A1 -E 'br-ex|bond0'
    2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ovs-system state UP group default qlen 1000
        link/ether fa:16:3e:47:99:98 brd ff:ff:ff:ff:ff:ff
    --
    5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
        link/ether fa:16:3e:47:99:98 brd ff:ff:ff:ff:ff:ff
        inet 10.xx.xx.xx/21 brd 10.xx.xx.255 scope global dynamic noprefixroute br-ex

排查 Open vSwitch 问题

要排查某些 Open vSwitch (OVS) 问题,您可能需要配置日志级别以包含更多信息。

如果您临时修改节点上的日志级别,请注意您可能会收到来自节点上的机器配置守护程序的日志消息,例如以下示例。

E0514 12:47:17.998892    2281 daemon.go:1350] content mismatch for file /etc/systemd/system/ovs-vswitchd.service: [Unit]

为避免与不匹配相关的日志消息,请在完成故障排除后恢复日志级别的更改。

临时配置 Open vSwitch 日志级别

对于短期故障排除,您可以临时配置 Open vSwitch (OVS) 日志级别。以下过程不需要重新引导节点。此外,无论何时重新引导节点,配置更改都不会持久存在。

执行此过程以更改日志级别后,您可能会收到来自机器配置守护程序的日志消息,指示 ovs-vswitchd.service 的内容不匹配。为避免日志消息,请重复此过程并将日志级别设置为原始值。

先决条件
  • 您可以作为具有 cluster-admin 角色的用户访问集群。

  • 您已安装 OpenShift CLI (oc)。

步骤
  1. 为节点启动一个调试 pod。

    $ oc debug node/<node_name>
  2. /host 设置为调试 shell 中的根目录。调试 pod 将主机上的根文件系统安装在 pod 内的 /host 中。通过将根目录更改为 /host,您可以运行来自主机文件系统的二进制文件。

    # chroot /host
  3. 查看 OVS 模块的当前 syslog 级别。

    # ovs-appctl vlog/list

    以下示例输出显示 syslog 的日志级别设置为 info

    示例输出
                     console    syslog    file
                     -------    ------    ------
    backtrace          OFF       INFO       INFO
    bfd                OFF       INFO       INFO
    bond               OFF       INFO       INFO
    bridge             OFF       INFO       INFO
    bundle             OFF       INFO       INFO
    bundles            OFF       INFO       INFO
    cfm                OFF       INFO       INFO
    collectors         OFF       INFO       INFO
    command_line       OFF       INFO       INFO
    connmgr            OFF       INFO       INFO
    conntrack          OFF       INFO       INFO
    conntrack_tp       OFF       INFO       INFO
    coverage           OFF       INFO       INFO
    ct_dpif            OFF       INFO       INFO
    daemon             OFF       INFO       INFO
    daemon_unix        OFF       INFO       INFO
    dns_resolve        OFF       INFO       INFO
    dpdk               OFF       INFO       INFO
    ...
  4. /etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf 文件中指定日志级别。

    Restart=always
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /var/lib/openvswitch'
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /etc/openvswitch'
    ExecStartPre=-/bin/sh -c '/usr/bin/chown -R :$${OVS_USER_ID##*:} /run/openvswitch'
    ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg
    ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg

    在前面的示例中,日志级别设置为 dbg。通过将 syslog:<log_level> 设置为 offemererrwarninfodbg 来更改最后两行。off 日志级别会过滤掉所有日志消息。

  5. 重新启动服务。

    # systemctl daemon-reload
    # systemctl restart ovs-vswitchd

永久配置 Open vSwitch 日志级别

对于 Open vSwitch (OVS) 日志级别的长期更改,您可以永久更改日志级别。

先决条件
  • 您可以作为具有 cluster-admin 角色的用户访问集群。

  • 您已安装 OpenShift CLI (oc)。

步骤
  1. 创建一个文件,例如 99-change-ovs-loglevel.yaml,其中包含如下示例所示的 MachineConfig 对象。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master  (1)
      name: 99-change-ovs-loglevel
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - dropins:
            - contents: |
                [Service]
                  ExecStartPost=-/usr/bin/ovs-appctl vlog/set syslog:dbg  (2)
                  ExecReload=-/usr/bin/ovs-appctl vlog/set syslog:dbg
              name: 20-ovs-vswitchd-restart.conf
            name: ovs-vswitchd.service
    1 在执行此过程以配置控制平面节点后,请重复此过程并将角色设置为 worker 以配置工作节点。
    2 设置 syslog:<log_level> 值。日志级别为 offemererrwarninfodbg。将值设置为 off 会过滤掉所有日志消息。
  2. 应用机器配置。

    $ oc apply -f 99-change-ovs-loglevel.yaml

显示 Open vSwitch 日志

使用以下步骤显示 Open vSwitch (OVS) 日志。

先决条件
  • 您可以作为具有 cluster-admin 角色的用户访问集群。

  • 您已安装 OpenShift CLI (oc)。

步骤
  • 运行以下命令之一。

    • 使用集群外部的 oc 命令显示日志。

      $ oc adm node-logs <node_name> -u ovs-vswitchd
    • 登录集群中的节点后显示日志。

      # journalctl -b -f -u ovs-vswitchd.service

      登录节点的一种方法是使用 oc debug node/<node_name> 命令。