Helm Upgrade 后 hostAliases 配置异常问题排查

本文记录一次在使用 helm upgrade 更新 Workload 时，命令返回成功，但实际 hostAliases 配置未按预期生效 的问题排查与解决过程。

---

问题现象

在 Helm Chart 的 values.yaml 中定义了 hostAliases 配置。修改该配置并执行 helm upgrade 后，出现以下异常现象：

• helm upgrade 命令执行成功
• 实际 Workload 中的 hostAliases 配置未发生变化，或为按预期发生变化
• 最终结果与预期配置不一致

修改前的配置示例：

修改后的配置示例：

执行 helm upgrade 后，Workload 中的实际配置：

进一步使用 helm upgrade --dry-run 验证，渲染出的配置内容是正确的：

这表明 Helm 在模板渲染阶段没有问题，但配置在应用到 Kubernetes 资源时出现了异常。

---

根因分析

在排查过程中，从 kube-apiserver 日志中发现如下错误信息：

E0126 07:06:28.501573       1 fieldmanager.go:186] [SHOULD NOT HAPPEN] failed to update managedFields for /, Kind=: failed to convert new object (apps/v1, Kind=ReplicaSet) to smd typed: errors:
  .spec.template.spec.hostAliases: duplicate entries for key [ip="10.88.96.193"]
  .spec.template.spec.hostAliases: duplicate entries for key [ip="10.88.96.193"]

结合日志信息以及 helm get values 等结果可以确认：

• helm upgrade 本身执行成功
• 新配置在写入 ReplicaSet 阶段失败，或者写入了错误的新配置
• Deployment 因底层 ReplicaSet 原因，最终配置不符合预期

进一步查阅 Kubernetes 社区 Issue 后发现，该行为与 Kubernetes 对 hostAliases 字段的合并逻辑有关：

• https://github.com/kubernetes/kubernetes/issues/107668
• https://github.com/kubernetes/kubernetes/issues/58477

---

根本原因

hostAliases 在 Kubernetes 中属于列表型字段，其合并策略是 以 ip 作为唯一合并键。

当配置中存在多个 hostAliases 条目使用相同的 ip 时：

• Kubernetes 在合并新旧配置时无法唯一识别对象
• 最终导致更新失败，并在 kube-apiserver 中抛出上述错误
• Helm 不会感知该失败，从而表现为“配置不符合预期”

---

解决方案

将相同 ip 对应的域名合并到同一个 hostAliases 条目中：

需要注意，在首次应用该修正配置并执行 helm upgrade 时，可能会观察到：

• 原有 ip 相同的多条 hostAliases 配置被全部删除

这是 Kubernetes 的预期行为，原因在于：

• Kubernetes 会将旧配置中重复 ip 的条目视为需要删除
• 同时又以 ip 作为合并键，导致第一次执行会将对应的条目全部删除

因此，在完成上述配置调整后，需要 连续执行两次 helm upgrade：

1. 第一次：清理旧的重复 ip 配置
2. 第二次：正确写入新的合并后配置

第二次执行完成后，hostAliases 配置即可按预期生效：

后续再次修改配置并执行 helm upgrade，行为也将符合预期：