管理防火墙端口
每个节点的主机防火墙已预先配置了平台所需的端口。您无需管理这些端口,也不应直接修改平台的预配置端口列表。
当工作负载需要开放额外的主机端口时——例如某个直接在节点上监听的组件——您可以通过 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条目添加到名为cluster的集群范围MachineConfiguration单例的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 或节点重启时才会重新添加。