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 发表评论