Blue Matador 使用 Terraform 从自托管的 Kubernetes 迁移到 AWS EKS

阅读数:4538 2019 年 6 月 20 日

Blue Matador 在比较了各种特性之后,将他们的 Kubernetes 基础设施从 AWS 实例上的kops托管集群迁移到了 AWS 的托管 Kubernetes 服务EKS。他们选择 EKS 是因为它有更好的安全模型、托管控制平面,而且可以降低他们特定用例的成本。在创建一个新的 Kubernetes 集群方面,kops 是赢家,而 EKS 在集群管理和安全性方面得分更高。InfoQ 联系了 Blue Matador 的软件工程师Keilan Jackson,进一步了解他们的经验。

EKS 的共享责任模型及其托管控制平面是迁移的主要原因。在 EKS 之前,Blue Matador 团队在 3 个 c4.large AWS 实例上运行他们自己的 Kubernetes 主节点。Kubernetes 的升级——包括 Bug 修复和安全补丁——都由团队负责。因为基础设施在 AWS 内部,所以 AWS 仍然提供了一个安全层,但是他们必须自己管理 Kubernetes 的特定安全问题。在私有网络、加密根卷和安全组控制等资源方面,Jackson 写道:“使用 kops 创建的 Kubernetes 集群的默认设置和 EKS 非常类似。”使用 EKS 设置一个新的集群需要做一些准备工作,但是,初始设置完成后,EKS 使集群管理更容易。

Blue Matador 主要使用 Terraform来管理他们的 AWS 资源。Terraform 实现了跨云提供商的多种资源类型,但现实世界的使用情况揭示了其中的挑战。Jackson 谈到了他们面临的 EKS 特有的挑战:

我尽量利用社区构建的EKS 模块。我遇到的主要问题是使用了 AWS 提供程序和 Terraform 的过期版本,然后将这个模块中的托管资源连接到我的外部托管资源,比如我们的主 ALB、RDS 实例等等。我建议从配置 EKS 的模块中输出一些 Terraform 变量,这样就可以在其他模块中引用它们,如下所示:

output “worker_role_arn” {

value = “${module.eks_cluster.worker_iam_role_arn}”

}

虽然 Terraform 可以很好地创建和管理 EKS 集群,但是后者依赖于相互关联的外围资源。Jackson 提供了详细的阐述:

除了运行 EKS 集群本身之外,EKS 还需要大量的资源。您必须配置工作节点、安全组、VPC 网络,并计划好在 EKS 提供新版本 Kubernetes 支持时进行更新。如果可能的话,一定要使用社区模块,因为它有助于正确连接这其中的许多基本资源,但是请记住,务必要按照您的安全需求仔细检查设置。例如,确保安全组只对需要它们的东西开放,确保工作节点不会获得公共 IP 地址,确保使用加密的 AMI 作为根设备。

在谈到集群规模时,Jackson 说,“集群的总大小还没有达到我们不得不在 kops 集群中使用超过 3 个主节点的程度,但重要的是,我们能够快速、轻松地扩展节点,并在 Kubernetes 新版本发布时更新到新版本。”

托管 Kubernetes 服务通常与他们平台的监控解决方案集成在一起。Jackson 解释了他们如何监控他们的集群:

我们主要依靠自己的产品 Blue Matador 实现 Kubernetes 集群报警。它会发现一些不健康的部署、关键节点事件、pod 内存耗尽等问题,并帮助我们监视集群的利用率。我们还使用 Datadog,但仅用于绘制几个自定义指标。我们关注 Amazon EKS 的 CloudWatch 容器洞察,但通常,CloudWatch 对 Kubernetes 而言不够活跃,因此,我不会依赖它来进行生产环境报警。

迁移还降低了团队的基础设施和监控成本。

查看英文原文Migrating From Self-Managed Kubernetes to AWS EKS Using Terraform at Blue Matador

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论