支持控制台（Console）开发人员开始试用联系人

7.5. 网络问题故障排除

7.5.1. 如何选择网络接口

对于在裸机上安装，或在具有多个网络接口控制器（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 服务可能会在重启后选择不同的 NIC。在某些情况下，oc get nodes -o wide 命令的输出中的 INTERNAL-IP 列中可能会看到选择了一个不同的 NIC。

如果因为选择了不同的 NIC 而导致网络通信中断或错误配置，您可能会收到以下错误： EtcdCertSignerControllerDegraded。您可以创建一个提示文件，其中包含 NODEIP_HINT 变量来覆盖默认的 IP 选择逻辑。如需更多信息，请参阅 可选：覆盖默认节点 IP 选择逻辑。

7.5.1.1. 可选：覆盖默认节点 IP 选择逻辑

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

例如，如果某个节点有两个接口，eth0 地址为 10.0.0.10/24，而 eth1 地址为 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 地址作为 hint，例如 192.0.2.5。使用节点的确切 IP 地址会导致节点使用 hint IP 地址无法正确配置。
    • hint 文件中的 IP 地址仅用于确定正确的子网。它不会因为提示文件中出现的结果而接收流量。

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

    $ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0

    输出示例

    Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==

  3. 在部署集群前，为 master 和 worker 角色创建机器配置清单来激活提示：

    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. 部署集群。

7.5.1.2. 配置 OVN-Kubernetes 以使用从 OVS 网桥

您可以创建额外的或 从（secondary） 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、出口防火墙或出口路由器。尝试使用带有出口 IP 等出口功能的 MEG 可能会导致路由和流量流冲突。这是因为 OVN-Kubernetes 如何处理路由和源网络地址转换 (SNAT)。这会导致路由不一致，并可能会在返回路径必须修补传入路径的一些环境中中断连接。

您必须在机器配置清单文件的接口定义中定义额外的网桥。Machine Config Operator 使用清单，在主机上的 /etc/ovnk/extra_bridge 中创建一个新文件。新文件包含额外为节点配置的 OVS 网桥的网络接口名称。

创建并编辑清单文件后，Machine Config Operator 按照以下顺序完成任务：

  1. 根据所选机器配置池，以 singular 顺序排空节点。
  2. 将 Ignition 配置文件注入每个节点，以便每个节点接收额外的 br-ex1 网桥网络配置。
  3. 验证 br-ex MAC 地址是否与 br-ex 用于网络连接的接口的 MAC 地址匹配。
  4. 执行 configure-ovs.sh shell 脚本以引用新接口定义。
  5. 将 br-ex 和 br-ex1 添加到主机节点。
  6. 取消记录节点。
注意

在所有节点都返回 Ready 状态后，OVN-Kubernetes Operator 会检测到并配置 br-ex 和 br-ex1，Operator 会将 k8s.ovn.org/l3-gateway-config 注解应用到每个节点。

有关其他 br-ex1 网桥的有用情况以及始终需要默认 br-ex 网桥的情况，请参阅" localnet 拓扑配置"。

流程

  1. 可选：通过完成以下步骤，创建一个额外网桥 br-ex1 的接口连接。示例步骤演示了创建新绑定及其依赖接口，这些接口都在机器配置清单文件中定义。额外网桥使用 MachineConfig 对象来形成额外的绑定接口。

    重要

    不要使用 Kubernetes NMState Operator 来定义或 NodeNetworkConfigurationPolicy (NNCP)清单文件来定义额外的接口。

    另外，请确保在定义绑定接口时，额外的接口或子接口不会被现有的 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. 在机器配置清单文件中定义每个接口定义：

    为 bond1, eno1, 和 en02 添加了定义的机器配置文件示例

    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. 将 machine-configuration 应用到所选节点： 

    $ 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

其他资源

7.5.2. 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]

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

7.5.2.1. 临时配置 Open vSwitch 日志级别

对于短期故障排除，您可以临时配置 Open vSwitch (OVS) 日志级别。以下流程不需要重启该节点。另外，每当您重新引导节点时，配置更改都不会保留。

执行此步骤更改日志级别后，您可以接收来自机器配置守护进程的日志消息，该守护进程指出 ovs-vswitchd.service 的内容不匹配。要避免日志消息，请重复此步骤，并将日志级别设置为原始值。

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 为节点启动 debug pod: 

    $ oc debug node/<node_name>

  2. 将 /host 设置为 debug shell 中的根目录。debug pod 从 pod 中的 /host 中的主机挂载 root 文件系统。将根目录改为 /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> 设置为 off、emer、err、warn、info 或 dbg。off 日志级别会过滤掉所有日志消息。

  5. 重启服务： 

    # systemctl daemon-reload
    # systemctl restart ovs-vswitchd

7.5.2.2. 永久配置 Open vSwitch 日志级别

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

先决条件

  • 您可以使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift CLI(oc)。

流程

  1. 使用类似以下示例的 MachineConfig 对象创建一个文件，如 99-change-ovs-loglevel.yaml ： 

    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
    执行此步骤以配置 control plane 节点后，重复这个过程，并将角色设置为 worker 以配置 worker 节点。
    2
    设置 syslog:<log_level> 值。日志级别为 off、emer、err、warn、info 或 dbg。将值设置为 off 会过滤掉所有日志消息。

  2. 应用机器配置： 

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

其他资源

7.5.2.3. 显示 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> 命令。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.