NODEIP_HINT=192.0.2.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
服务可能会在重新引导后选择不同的网卡。在某些情况下,您可以通过查看oc get nodes -o wide
命令输出中的INTERNAL-IP
列来检测是否选择了不同的网卡。
如果由于选择了不同的网卡而导致网络通信中断或配置错误,您可能会收到以下错误:EtcdCertSignerControllerDegraded
。您可以创建一个包含NODEIP_HINT
变量的提示文件来覆盖默认的 IP 选择逻辑。有关更多信息,请参见可选:覆盖默认节点 IP 选择逻辑。
要覆盖默认的 IP 选择逻辑,您可以创建一个包含NODEIP_HINT
变量的提示文件来覆盖默认的 IP 选择逻辑。创建提示文件允许您从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 选择逻辑。
将提示文件添加到您的/etc/default/nodeip-configuration
文件中,例如:
NODEIP_HINT=192.0.2.1
|
运行以下命令生成base-64
编码的内容:
$ echo -n 'NODEIP_HINT=192.0.2.1' | base64 -w0
Tk9ERUlQX0hJTlQ9MTkyLjAuMCxxxx==
在部署集群之前,为master
和worker
角色创建机器配置清单来激活提示
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== 。请注意,逗号后和编码内容前不允许有空格。 |
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== 。请注意,逗号后和编码内容前不允许有空格。 |
将清单保存到您存储集群配置的目录中,例如~/clusterconfigs
。
部署集群。
您可以创建一个额外的或辅助的 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 网桥为节点配置的网络接口的名称。
创建并编辑清单文件后,机器配置操作员将按以下顺序完成任务:
基于选择的机器配置池,按单个顺序排出节点。
将 Ignition 配置文件注入到每个节点中,以便每个节点接收额外的br-ex1
网桥网络配置。
验证br-ex
MAC 地址是否与br-ex
用于网络连接的接口的 MAC 地址匹配。
执行引用新接口定义的configure-ovs.sh
shell 脚本。
将br-ex
和br-ex1
添加到主机节点。
取消隔离节点。
在所有节点返回到 |
有关附加br-ex1
网桥的有用情况以及始终需要默认br-ex
网桥的情况的更多信息,请参见“本地网拓扑的配置”。
可选:通过完成以下步骤,创建一个您的附加网桥br-ex1
可以使用的接口连接。示例步骤显示了新绑定及其所有在机器配置清单文件中定义的依赖接口的创建。附加网桥使用MachineConfig
对象来形成附加绑定接口。
不要使用 Kubernetes NMState 运算符或 还要确保在定义 |
创建以下接口定义文件。这些文件将添加到机器配置清单文件中,以便主机节点可以访问定义文件。
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
运行以下命令将定义文件转换为 Base64 编码字符串:
$ base64 <directory_path>/en01.config
$ base64 <directory_path>/eno2.config
$ base64 <directory_path>/bond1.config
准备环境变量。将<machine_role>
替换为节点角色,例如worker
,并将<interface_name>
替换为您附加的br-ex
网桥名称。
$ export ROLE=<machine_role>
在机器配置清单文件中定义每个接口定义
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
# ...
通过在终端中输入以下命令创建用于配置网络插件的机器配置清单文件:
$ oc create -f <machine_config_file_name>
使用 OVN-Kubernetes 网络插件在节点上创建一个 Open vSwitch (OVS) 桥接器 br-ex1
,方法是创建一个 extra_bridge
文件。确保将文件保存在主机的 /etc/ovnk/extra_bridge
路径下。该文件必须指定支持附加桥接器的接口名称,而不是支持 br-ex
的默认接口(该接口持有节点的主 IP 地址)。
extra_bridge
文件(/etc/ovnk/extra_bridge
)的示例配置,引用了附加接口。bond1
创建一个机器配置清单文件,该文件定义了在集群中重新启动的任何节点上承载 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
将机器配置应用于您选择的节点。
$ oc create -f <machine_config_file_name>
可选:您可以通过创建一个机器配置文件来覆盖节点的 br-ex
选择逻辑,该文件又会创建一个 /var/lib/ovnk/iface_default_hint
资源。
该资源列出了 |
在主机节点上创建一个机器配置文件以覆盖默认接口。
仅出于更改 |
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 。 |
在将配置应用于集群中的所有新节点之前,请重新引导主机节点以验证 br-ex
是否选择了预期的接口,并且不会与您在 br-ex1
上定义的新接口冲突。
将机器配置文件应用于集群中的所有新节点。
$ oc create -f <machine_config_file_name>
识别集群中带有 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\"],
通过查看主机节点上的网络接口名称来观察目标节点上是否存在附加桥接器。
$ 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
可选:如果您使用 /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 (OVS) 问题,您可能需要配置日志级别以包含更多信息。
如果您临时修改节点上的日志级别,请注意您可能会收到来自节点上的机器配置守护程序的日志消息,例如以下示例。
E0514 12:47:17.998892 2281 daemon.go:1350] content mismatch for file /etc/systemd/system/ovs-vswitchd.service: [Unit]
为避免与不匹配相关的日志消息,请在完成故障排除后恢复日志级别的更改。
对于短期故障排除,您可以临时配置 Open vSwitch (OVS) 日志级别。以下过程不需要重新引导节点。此外,无论何时重新引导节点,配置更改都不会持久存在。
执行此过程以更改日志级别后,您可能会收到来自机器配置守护程序的日志消息,指示 ovs-vswitchd.service
的内容不匹配。为避免日志消息,请重复此过程并将日志级别设置为原始值。
您可以作为具有 cluster-admin
角色的用户访问集群。
您已安装 OpenShift CLI (oc
)。
为节点启动一个调试 pod。
$ oc debug node/<node_name>
将 /host
设置为调试 shell 中的根目录。调试 pod 将主机上的根文件系统安装在 pod 内的 /host
中。通过将根目录更改为 /host
,您可以运行来自主机文件系统的二进制文件。
# chroot /host
查看 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
...
在 /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
日志级别会过滤掉所有日志消息。
重新启动服务。
# systemctl daemon-reload
# systemctl restart ovs-vswitchd
对于 Open vSwitch (OVS) 日志级别的长期更改,您可以永久更改日志级别。
您可以作为具有 cluster-admin
角色的用户访问集群。
您已安装 OpenShift CLI (oc
)。
创建一个文件,例如 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> 值。日志级别为 off 、emer 、err 、warn 、info 或 dbg 。将值设置为 off 会过滤掉所有日志消息。 |
应用机器配置。
$ oc apply -f 99-change-ovs-loglevel.yaml