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