管理防火墙端口
每个节点的主机防火墙都已预先配置了平台所需的端口。你无需管理这些端口,也不应直接修改平台预配置的端口列表。
当某个工作负载需要额外打开一个主机端口时——例如,某个直接在节点上监听的组件——你可以通过使用 MachineConfig 对象安装一个小型 systemd unit 来打开该端口。该 unit 会在运行时使用 firewall-cmd --add-port 打开端口,同时保持平台的预配置端口不受影响。
为什么使用运行时 unit,而不是重新加载 Firewalld
重新加载或重启 firewalld(firewall-cmd --reload、systemctl restart firewalld)会从头重建主机防火墙。在集群节点上,这可能会删除其他组件直接编程设置的包过滤规则,例如 Istio 的流量重定向规则、kube-proxy 或 CNI,从而导致间歇性的连接丢失。为避免这种情况,此操作步骤不会重新加载或重启 firewalld。
相反,一个 oneshot systemd unit 会通过 firewall-cmd --add-port 将端口添加到正在运行的 firewalld 中。这一操作只是增量添加,不会清除任何内容。该 unit 在 firewalld 之后执行,并声明为 PartOf=firewalld.service,因此如果 firewalld 未来被重启,unit 会再次运行并重新添加这些端口(运行时的 --add-port 本身不会在 firewalld 重启后自动保留)。
打开额外端口
以下示例会打开 TCP 端口 9141(ZooKeeper)和 9308(cpaas-kafka),这两个端口通常是日志栈所需的。请将 --add-port 列表改为你的工作负载所需的端口。
-
创建一个
MachineConfig,安装一个会在运行时打开端口的 oneshot unit: -
配置一个节点中断策略,使对此 unit 的更改重启该 unit——重新执行
firewall-cmd——而不是重启节点。将open-app-ports.service条目添加到cpaas-system命名空间中clusterMachineConfiguration对象的nodeDisruptionPolicy.units列表中,并在应用MachineConfig之前确认它已反映在status.nodeDisruptionPolicyStatus中:
在这两个对象都应用之后,该 unit 会在每个目标节点上打开端口,而不会重新加载 firewalld,也不会重启节点;平台的预配置端口以及其他组件的规则都会保持不变。
cluster 对象是单例,可能已经包含其他 unit 或文件策略。请将 open-app-ports.service 添加到现有的 nodeDisruptionPolicy.units 列表中,而不是替换整个策略。如果某个受管 unit 未列在这里,那么它将回退到 unit 的默认操作,即在 unit 发生更改时重启节点。
更改或移除端口
- 要添加端口,请在 unit 中扩展
--add-port列表,并重新应用MachineConfig。节点中断策略会重启该 unit,并在运行时添加新端口。 - 要移除端口,仅仅从
--add-port列表中删除它还不够:firewall-cmd --add-port只会添加,因此已在运行时打开的端口会一直保持打开状态,直到 firewalld 被重启。先从 unit 中移除该端口,然后在受影响的节点上重启 firewalld——或者重启这些节点——以将其关闭。
注意事项
- 端口会被添加到 firewalld 的默认 zone。如果相关接口绑定到了非默认 zone,请在
firewall-cmd命令中添加--zone=<zone>。 firewall-cmd --add-port是幂等的:重新添加一个已打开的端口会返回警告,但仍然会成功,因此该 oneshot unit 可以安全地重复执行。- 该 unit 需要 firewalld 正在运行。在不运行主机 firewalld 的节点上,该 unit 不会启动,也不会打开任何端口。
- 运行时的
--add-port不会写入 firewalld 的永久配置。如果 firewalld 被外部重新加载(firewall-cmd --reload),这些端口会被移除,并且只会在下次 firewalld 或节点重启时重新添加。