Kuma CNI DaemonSet 缺少 Affinity 配置的问题分析与解决方案

Kuma 作为一款优秀的服务网格解决方案，其 CNI 组件负责处理 Kubernetes 集群中的网络流量管理。然而在最新版本 2.9.4 中，用户发现 CNI DaemonSet 的 Helm 模板缺少了一个关键配置项 - affinity（亲和性）设置，这给某些特定环境下的部署带来了挑战。

问题背景

在 Kubernetes 部署中，affinity 配置允许我们精细控制 Pod 应该或不应该调度到哪些节点上。这是一个比简单的 nodeSelector 更强大的机制，可以实现更复杂的调度策略。Kuma 的控制平面、入口和出口组件都提供了 affinity 配置选项，但 CNI 组件却遗漏了这一重要功能。

影响分析

这个问题在 AWS EKS Fargate 这类特殊环境中尤为突出。Fargate 节点与传统 EC2 节点不同，它们由 AWS 完全托管，用户无法直接控制或修改这些节点的标签。在没有 affinity 配置的情况下，CNI Pod 可能会被调度到不兼容的 Fargate 节点上，导致部署失败。

技术细节

Kuma CNI 默认包含了一个特殊的 toleration（容忍）配置：

- effect: NoSchedule
  operator: Exists

这个配置允许 CNI Pod 被调度到任何设置了 NoSchedule taint 的节点上。在之前的版本中，用户可以通过覆盖 tolerations 配置来避免这个问题，但在版本 2.9.4 中这个变通方法被移除了。

解决方案

社区已经意识到这个问题的重要性，并在 2.10 版本中修复了这个问题。修复方案是为 CNI DaemonSet 添加了 affinity 配置支持，允许用户像其他 Kuma 组件一样定义复杂的节点调度策略。

对于暂时无法升级到 2.10 版本的用户，可以考虑以下临时解决方案：

1. 使用 Argo CD 的 kustomized-helm 插件对 Helm 模板进行后处理，手动添加 affinity 配置
2. 为所有非 Fargate 节点添加特定标签，然后使用现有的 nodeSelector 功能

最佳实践

在 Kubernetes 环境部署服务网格时，建议：

1. 始终为关键组件配置适当的 affinity 规则，特别是在混合节点类型的集群中
2. 对于托管服务如 AWS Fargate，提前规划节点调度策略
3. 保持组件版本更新，及时获取最新的功能和修复

这个问题的解决体现了开源社区响应实际需求的敏捷性，也提醒我们在设计 Kubernetes 应用时要考虑各种部署环境的兼容性。