最近一段时间始终在跟客户探讨 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) 与我交换