Glasskube项目在AWS EKS Fargate节点上的部署问题解析

问题背景

Glasskube是一个基于Kubernetes的包管理工具，它使用Flux的helm-controller作为内部组件。在AWS EKS环境中，特别是使用Fargate节点时，用户可能会遇到部署卡在96%进度的问题。

核心问题分析

当在AWS EKS Fargate节点上部署Glasskube时，系统会自动为所有节点添加一个不可调度的污点(taint)："eks.amazonaws.com/compute-type: fargate"。这个污点会阻止标准部署的Pod被调度到这些节点上。

从技术角度看，这会导致以下两个关键Pod无法被调度：

1. glasskube-controller-manager
2. glasskube-webhook-cert-init

这些Pod的状态会显示为"Pending"，事件日志中会明确提示"node(s) had untolerated taint"的错误信息。

解决方案

目前有两种可行的解决方案：

方案一：使用精简模式部署

Glasskube提供了--type=slim参数，这种部署模式不需要helm-controller组件，因此可以绕过Fargate节点的限制。这是目前最直接的解决方案。

方案二：手动添加容忍度

对于需要完整功能的用户，可以采取以下步骤：

1. 导出部署清单
2. 手动为相关资源添加对Fargate污点的容忍度
3. 重新应用修改后的清单

需要特别注意为以下资源添加容忍度：

• Deployment/glasskube-controller-manager
• Job/glasskube-webhook-cert-init

技术建议

对于AWS EKS Fargate环境，建议：

1. 优先考虑使用slim模式部署
2. 如果必须使用完整功能，需要仔细规划容忍度配置
3. 监控Pod调度状态，及时发现问题

未来改进方向

Glasskube团队已经意识到这个问题，计划在文档中添加"常见问题"章节来专门说明Fargate环境的部署注意事项。同时，也在考虑在未来的版本中提供更灵活的调度配置选项。

总结

在云原生环境中，不同平台的特性差异可能导致部署问题。理解底层调度机制和平台特定限制是解决这类问题的关键。Glasskube在AWS EKS Fargate上的部署问题就是一个典型的例子，通过了解污点和容忍度机制，用户可以找到合适的解决方案。