Amazon EKS都是怎么托管Kubernetes集群的

最近一段时间一直在跟客户讨论Kubernetes和对应的AWS托管服务EKS. 很多时候都被问到EKS这个黑盒子里面究竟是怎么做的。自己其实也挺好奇这个问题的，在官方文档上这块的描述的并不是太多，于是翻来翻去找到了这个re:Invent 2019的一个演讲：

听了一下这个演讲小哥的介绍，是EKS团队的Principle Engineer，从EKS这个服务一开始就在了。照例先到Linkedin上八卦一下：

翻了一下工作的经历，一直做研发，来AWS之前是在 Samsung SDS 做k8s的开发。一般能在re:Invent上讲 XXX under the hood 的应该都是比较有料的，先厚着脸皮申请加个好友先 :)

EKS 的介绍从一个非常简单的架构图开始：

EKS是一个区域服务（中间那个黄色的图标），客户通过 EKS Endpoint 来与 EKS 服务进行交互。 EKS 会帮客户创建 K8s 集群，这个k8s是与上流社区 100% 代码兼容的，客户可以在这个 K8s 集群上运行自己的应用，这个K8s集群也可以与AWS的其他服务无缝地集成，比如说身份认证，负载均衡等

接着再展开一下：

K8s集群相关的有几个使用者，第一是集群的管理员，或是Infra团队，会通过刚才提到的 EKS Endpoint 来进行 K8s集群的管理（部分的操作也会通过k8s的 API Server Endpoint来进行）；第二是开发团队，或是CICD的自动化工具，会通过 K8s 的 API Server Endpoint 来进行应用的部署；最后一个是应用的最终使用者，直接通过k8s对外暴露的服务接口来访问应用（他们也不需要知道应用是不是部署在K8s上面）

继续展开：

在这里可以看到 EKS Control Plane，也就是 k8s 的 Master ，是托管在EKS管理的VPC里面的。注意到这里写 Single Tenant，也就是单租户，即每个集群有自己的独立的资源，而不与其他的集群共享。这个 Control Plane 是部署在三个可用区的，确保跨可用区的高可用。在下面是 Data Plane，也就是 k8s 的 Node . 这块是部署在客户自己的VPC里面，可以选择EC2，也可以选择 Fargate。

接着再展开讲一下 Control Plane:

Control Plane 里相关的几个组件，比如 API Server, Controller Manager 和 Scheduler 等会部署在一个Auto Scaling Group中(2个EC2实例)，另外 etcd 会部署在另一个单独的ASG中(3个EC2实例)，这两个ASG都是在EKS托管的VPC中，实例的水平伸缩和垂直伸缩都是由EKS来自动管理。
Control Plane的实例都部署在私有子网，API Server对外是通过NLB来提供访问。

看完这几张最基本的架构图，接下来才开始是 under the hood:

这里开始介绍 EKS 这个托管服务自身的设计架构。整体来说这是个 Cellular Architecture ( 蜂窝架构），先划分出 Failure Domain(失效域）：最高一级的隔离级别是 Region(区域) ，然后是Avalability Zone(可用区）。看到这里有点意外的是 AWS Account 是在区域下面划分出来的，每个AWS Account 就是一个最基本的Cell(单元），运行一个区域内的一个软件组件的一个实例，不过想想也是，一个AWS Account就是安全的隔离边界，对某个软件组件的变更只会限制在某个区域，而不会出现同时对多个区域进行变更的情况。可以脑补下一个AWS Region下，有N多个这样的 Cell 运行着 EKS 这个服务背后不同的软件组件。正如前面提到的，就像一个蜂窝一样。这个架构思路不是EKS特有的，其他AWS的服务也是按照这个思路进行设计。

那继续再展开，看看这些Cell都运行着什么软件组件：

中间这一坨黄色框框里的就是EKS背后的组件了。看起来是一个典型的微服务架构：首先从最左边的 Frontend 开始，这里提供了EKS API，用户可以通过 AWS CLI/SDK 来发起相应的API操作，比如查询或创建集群等。Console，也就是UI，是有一个单独的 Console Server，然后调用 Frontend. 所以说 AWS 的服务都是先有API，然后才有UI 。各种的事件汇聚后，会由两个状态管理服务来分别对集群的Control Plane和Data Plane（如果使用托管节点组）进行管理。

接下来就挑了三个组件(Frontend, Cluster Events和 Contol Plane Management)来进一步讲解其背后的实现：

可以看到EKS背后使用了大量的AWS原生的服务来进行构建，特别是Serverless相关的服务。比如说Frontend这个组件，就是使用了API Gateway和Lambda来实现的，这个经典的模式还在其他的组件那里大量地被使用，此外Step Function, DynamodDB等也被大量地使用。

这里值得一提的是，EKS使用到的这些AWS服务，同样也是客户一直在使用的服务，按这位小哥的原话，就是Eat our own dog food 。就像搭积木一样，在已有的积木的基础上，搭建出新的服务出来。这个新的服务也成为一个积木，供其他服务所使用。

在这里还回答了一个问题，就是为什么不使用kubernetes而是API Gateway/Lambda等服务来构建EKS。其实很简单，就是个鸡和蛋的问题，因为一开始就没有kubernetes相关的服务，只能先把kubernetes托管服务，也就是EKS做出来之后，其他的AWS服务才能在EKS的基础上进行搭建。这里没有提到具体哪个AWS的服务是使用EKS来构建，倒是举了个例子，就是Amazon.com的首页大量在使用EKS。

回到刚才提到的 Cellular Architecture ，这里提到一个好处，就是可以根据需要对不同的组件进行扩容:

比如说Frontend, Cluster Event这些组件相对资源需求少一些，Cell的部署数量也会比较少。但针对Control Plane的管理组件，则会要求更多的资源，因此需要部署更多的Cell. 在每个AWS Region，都会按照上述图示来进行部署。

接下来讨论的是如何对EKS这个服务进行运维：

如果EKS这个服务有升级，如何安全地进行部署呢？这里以 Control Plane Management 这个组件为例，EKS的研发工程师会往 Git 仓库上提交代码，在 code review 后触发 Deployment Pipeline 进行测试和部署，这部分的工作就完全是自动化的而无须人工干预了。 在PPT上面没有显示出来，在实际的环境中是有Beta, Gamma等独立的环境。EKS团队使用了开源的 Prow 来进行一系列的端到端的测试，还有一个独立的系统来进行集成测试和金丝雀测试等。在相关的测试完全通过后才会进行实际的部署。

部署的时候有一些原则：比如说在一个Region内，会以指数递增的方式来部署Cell，即先部署1个Cell，没问题再部署2个，再部署4个... 另外也不会同时部署多个Region，防止多个Region同时出现问题。

实际环境下有超过50条这样的Deployment Pipeline ( 该演讲在2019年11月，相关数据也是基于当时的环境 ):

Pipeline 不只是用来做代码的部署，其他的任务像制作 EKS 相关的AMI，往ECR推送相关镜像等等可以自动完成的基础架构相关的动作都通过 Pipeline 来自动完成的。这里拿一个典型的 Pipeline 列举了一下相关的数字：在过去一个季度，这个pipeline一个有 17,000 个原子操作，算下来大概每个月5到6000次操作，那每周大概就是1500次操作。这种情况下不可能让人工来完成这些操作，必须是自动化完成，除非中间有异常情况，才需要人工介入进行处理。

看到这里还是挺有感慨的，Kubernetes还是挺重的一个平台，在云上来进行托管并不是一件容易的事情。EKS 从 Control Plane 的托管开始做起，然后是 Data Plane ( Fargate, Managed Node Group 等），在这个微服务的框架后面再继续演进，增加新的功能，还是挺令人期待的。毕竟对于绝大部分的客户来说，Kubernetes实在是太难管理和维护了，托管服务还是很有价值的。

大概20分钟的演讲多少还是把EKS服务背后的设计原则，涉及的组件以及实现的方式还有服务运维的思路都做了一些介绍，后面还有两部分，一个是深入介绍了刚发布的 Fargate for EKS，另一个是客户 Snap 分享他们在 EKS 上部署 Service Mesh 的情况。我把这个视频搬到了 B 站，如果你感兴趣的话，你可以在B站上观看这个完整的演讲：
https://www.bilibili.com/video/BV1Ag411E7nX/

---

本文最早发表在个人的微信公众号，对云技术感兴趣的朋友也可以关注我的微信公众号(CloudBuilder)与我交流