共计 3663 个字符,预计需要花费 10 分钟才能阅读完成。
最近一段时间始终在跟客户探讨 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
) 与我交换