Agones在EKS集群中的TLS证书配置问题解析与解决方案

问题背景

在使用Helm将Agones游戏服务器编排系统部署到Amazon EKS集群（Kubernetes 1.30版本）时，开发者遇到了两个关键问题：

1. 默认安装后API服务发现失败，具体表现为v1.allocation.agones.dev的APIService处于FailedDiscoveryCheck状态
2. 尝试使用cert-manager替代默认证书方案时，出现Helm模板合并冲突和证书挂载异常

核心问题分析

API服务发现失败的根本原因

系统日志显示，Kubernetes控制平面无法通过HTTPS访问Agones控制器的分配API端点。虽然非TLS的HTTP连接可以正常工作，但HTTPS连接出现超时。这表明：

1. 证书验证环节存在问题
2. 网络策略可能阻止了安全端口的通信

进一步排查发现，问题的根源在于EKS节点组的安全组配置。默认情况下，节点组没有附加集群的主安全组，导致控制平面组件无法与节点上的Agones控制器建立安全连接。

cert-manager集成问题

当尝试使用cert-manager替代Agones的默认证书方案时，出现了Helm模板合并冲突。具体表现为：

1. Helm无法正确处理customCertSecretPath字段的类型转换（表格与非表格值的冲突）
2. 控制器和扩展Pod仍然尝试挂载不存在的默认证书agones-cert

这表明Helm chart的values.yaml结构定义与cert-manager集成方案存在兼容性问题。

解决方案与实践

方案一：修复EKS节点组配置

通过修改Terraform配置，确保节点组附加了集群的主安全组：

eks_managed_node_groups = {
  general_purpose = {
    name_prefix = "general-purpose"
    attach_cluster_primary_security_group = true  # 关键配置
    instance_types = ["t3.small"]
    desired_size = 3
    # 其他配置...
  }
}

这一修改确保了控制平面组件能够与节点上的Agones控制器建立安全连接，解决了API服务发现失败的问题。

方案二：cert-manager集成的正确方法

对于需要使用cert-manager的场景，建议：

1. 确保使用Agones 1.45+版本
2. 正确配置values.yaml中的证书相关参数
3. 预先创建好cert-manager所需的证书Secret
4. 验证Helm模板合并时customCertSecretPath字段的结构一致性

最佳实践建议

1. 网络配置检查清单：

   • 验证节点安全组规则
   • 检查网络策略是否允许控制平面到节点的通信
   • 确认VPC路由表配置正确

2. 证书管理策略：

   • 生产环境推荐使用cert-manager等专业证书管理工具
   • 开发环境可使用Agones内置的证书方案
   • 定期轮换证书并监控过期时间

3. 版本兼容性：

   • 注意不同Agones版本对Kubernetes版本的要求
   • Helm chart的values结构可能随版本变化

总结

在EKS上部署Agones时，安全组配置是经常被忽视但至关重要的环节。通过正确配置节点组的安全组附加属性，可以解决大多数服务发现和证书验证问题。对于需要更高级证书管理的场景，应仔细研究cert-manager集成方案并确保版本兼容性。这些经验不仅适用于Agones部署，对于其他需要在EKS上运行的服务网格和自定义控制器也有参考价值。