生产环境中，如何将Kubernetes部署到AWS？

这份文档简述了我们在Zalando所学习到的关于如何在生产环境下将Kubernetes部署到AWS的经验。由于我们只是刚开始迁移到Kubernetes，因此我们并不认为我们是这个领域的专家。这个文档是共享的，希望社区中的其他人可以从我们的经验中获益。

背景

我们一个由基础设施工程师组成的团队，并且为Zalando技术交付团队提供Kubernetes集群服务。我们规划有超过30个生产环境的Kubernetes集群。以下目标可能有助于理解文档的其余部分、我们的Kubernetes设置以及我们的具体挑战：

• 无需手动操作：所有集群的更新和操作都必须是完全自动化的

• 不能有特例集群：所有的集群都应该是完全一致的，不需要任何特定的配置或调整

• 可靠性：基础设施应该是坚如磐石的，我们的交付团队委托我们的集群管理他们最关键的应用程序

• 弹性伸缩：集群应该能够自动适应已部署应用的工作负载，并且按照预期进行伸缩

• 无缝迁移：目前在AWS/STUPS[1]上已经部署的容器化的满足（云原生）12要素的应用，可以不做任何修改的情况迁移到Kubernetes

集群自动化

现在已经有很多工具可以提供Kubernetes集群。我们选择采用kube-aws[2]工具，因为它与我们当前在AWS的工作方式相相似：使用cloud-init和CloudFormation定义基础结构，并且配置这些不可变节点。CoreOS提供的容器Linux完全符合我们对于集群节点系统的理解：只提供运行容器所需要的内容，没有任何其他东西。

每一个AWS账号下面我们只创建一个Kubernetes集群。我们为生产和测试环境讽创建了独立的AWS账号和集群，同时我们会立即创建两个AWS弹性伸缩组：

• 一个主弹性绳索组，用于确保始终有两个节点用于运行API Server和Controller Manager

• 一个副弹性伸缩组，用于确保始终有2个或2个以上的节点用于运行应用Pod

这两个自动弹性伸缩组都是跨可用区（AZ）的。API Server通过一个“经典”TCP/SSL的弹性负载均衡器（ELB）与TLS一起对外公开。

我们自己构建了一个集群注册的REST服务，用于管理所有的Kubernetes集群。另外一个组件（集群生命周期管理器，CLM）定期轮训集群注册表，并且将更新到所需状态。其中所需状态是通过CloudFormation以及Kubernetes配置是存储在Git当中[3]。

不同的集群使用了不同的通道配置（分支）。举例来说，一些非关键性的集群可能使用了具有最新特性的“alpha"通道（分支），而其它集群则使用了“Stable”通道（分支）。通道的概念类似于CoreOS管理容器linux发布的方式。

一旦有任何变更被合并到对应的分支中，集群就会自动更新。配置变更首先会在一个独立的特性分支进行测试，完成验证后向dev分支发起pull request，并且自动运行端到端测试（包含官方的Kubernetes一致性测试）。

AWS集成

我们在AWS上提供集群，因此希望在可能的情况下与AWS的服务进行集成。kube2iam[4]守护进程可以允许我们通过添加注解（annotation）的方式将AWS IAM角色分配给Pod。我们的基础设施组件（如Autoscaler）使用了相同的机制使用IAM角色来访问AWS API（受限制API）。

Ingress