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

创作场景

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