AWS Load Balancer Controller 配置 NLB 时常见问题解析

在 Kubernetes 环境中使用 AWS Load Balancer Controller 配置 Network Load Balancer (NLB) 时，可能会遇到几个典型问题。本文将深入分析这些问题及其解决方案，帮助用户更好地理解和配置 NLB。

子网自动发现失败问题

当尝试在私有子网中配置 NLB 时，控制器可能无法自动发现子网，并报错提示无法解析匹配的子网。这通常是由于子网标签配置不当导致的。

AWS Load Balancer Controller 通过特定标签来识别可用于负载均衡器的子网。除了标准的 kubernetes.io/role/internal-elb=1 标签外，在某些版本中还需要 kubernetes.io/cluster/${cluster-name} 标签来标识集群关联的子网。

解决方案有两种：

1. 为子网添加集群名称标签
2. 在控制器配置中设置 SubnetsClusterTagCheck=false 参数来禁用集群名称检查

证书验证失败问题

当尝试为 NLB 配置 SSL/TLS 证书时，可能会遇到证书验证错误，提示证书必须包含完全限定域名、支持签名和密钥大小。

这是由于 AWS NLB 对证书有特定要求：

• 不支持 RSA 4096 位密钥的证书
• 必须使用符合 ELB TLS 要求的证书类型

如果必须使用 RSA 4096 位证书，应考虑改用 Application Load Balancer (ALB)，因为 ALB 支持更广泛的证书类型。

Helm 卸载后资源残留问题

在卸载 AWS Load Balancer Controller 的 Helm Chart 时，可能会发现某些资源未被完全删除，特别是 Custom Resource Definitions (CRDs) 和 Ingress 资源。

这是因为：

1. CRDs 通常不会被 Helm 自动删除以防止数据丢失
2. Ingress 资源可能包含 finalizers 阻止其被删除

解决方法：

• 手动删除 CRDs（谨慎操作）
• 移除 Ingress 资源的 finalizers 后再删除

最佳实践建议

1. 始终检查 AWS Load Balancer Controller 版本对应的文档，了解确切的子网标签要求
2. 在生成证书前，确认 AWS NLB 支持的证书类型和密钥大小
3. 在卸载前，备份重要配置并了解 Helm 的资源清理行为
4. 考虑使用基础设施即代码工具管理这些资源，以确保一致性

通过理解这些常见问题及其解决方案，用户可以更顺利地在 Kubernetes 环境中配置和管理 AWS NLB，构建可靠的服务负载均衡架构。