阿里云Kubernetes平台构建和管理实践（上）

2021-08-13 04:54:02

本专题主要对整个阿里云产品的概览、集群规划创建、核心组件配置及优化、集群运维四个部分进行介绍。

想看精彩直播回放，请点击这里。

以下为精彩直播内容整理：

k8s已经逐渐的成为了一个新的基础设施的实施标准，越来越多的包括一些传统行业、互联网行业以及金融、证券等各行各业都在面向云原生，同时阿里云的容器产品团队也一直在致力于打造一个安全的、稳定的、支持超大规模的生产化ready的云原生容器平台。

基于目前的趋势，针对管理和构建云原生k8s的基础设施平台，主要从产品概览，集群规划创建，组建规划及优化和集群运维四个部分进行展开。第一部分对整个的阿里云k8s产品的概览进行介绍，第二部分是针对如何更好的创建和规划k8s集群，第三部分主要介绍核心组件的配置及优化，第四部分对运维方面介绍一些相关的说明。

一、产品概览

阿里云Kubernetes服务

由上图所示，为阿里云Kubernetes服务体系的整体结构，最底层为整个阿里云基础的AIS设施，其中包含计算、网络和存储。从计算资源来看，常见的各种型号和规格的ECS（包括神龙机器）、GPU、FPGA以及弹性容器实例等都可以被k8s统一的作为资源收纳馆。在网络部分包含VPC及VPC下的网络、ENI、SLB、DNS等基础核心部件。阿里云提供的存储部分直接可以与k8s进行无缝对接。根据业务的场景不同可以提供基本的云盘，像NAS以及块存储、文件存储等的不同存储类型。

中间层是阿里的两个核心产品，左边为标准的k8s（简称为ACK），右边为一个无服务器节点的serverless k8s。阿里在整个k8s平台上提供一些生产化ready需要的各种能力，包括自动伸缩的弹性、日志的解决方案、监控、智能运维、安全合规等能力，基本上这些能力都可以在Kubernetes平台上直接的被使用。两个绿色框为镜像仓库的服务，阿里也提供一些镜像仓库企业版的支持能力，包括Helm Chart仓库的存储能力。

最顶层承载了企业里各种各样的服务形态，包括目前最流行的微服务架构、微服务网格都可以很好的在k8s下进行无缝的运行。DevOps功能包括自动化的与CI/CD平台打通，代码平台以及阿里云提供的云效产品也直接可以在容器服务上使用。传统的应用包括做.net框架等，不仅可以实现容器化，而且还能更好的发挥出容器的特性。此外，前沿的创新业务包括AI、区块链、IoT。

如上图所示，阿里在全球18个区都有开服容器服务Kubernetes，使得有一些需要出海的业务可以更方便的在海外的各个区使用k8s服务。

容器服务Kubernetes集群形态

通常，不同的形态对业务的适用性会有区别，同时对运维管理带来差异。以下介绍三种形态的异同点：

Dedicated Kubernetes：作为标准版的k8s。其中标准是指可以完全的掌控k8s里所有的部分，包含Master和Worker部分。Master节点可以完全开放给客户，能够统一的集中管理。后面部分会重要介绍多可用区。这样的产品形态与自建的k8s是完全等同的，只不过自建的过程有阿里云的k8s产品可以帮助一键化的创建，创建完成后，可以得到完整的k8s以及完整Master上的各种权限。
Managed Kubernetes：作为托管版的k8s。具体托管的部分在集群的管控层面、Master节点、 API 及核心系统平面的组建，这些都由阿里云平台方帮助托管，自己所能看到的只是创建的一个集群，记忆集群里有多少Worker节点，这些Worker节点是可以被自己所掌控，节点的ECS是面向客户的。由此可以得到的好处是不用管理整个k8s集群的管控层面，比如API的性能是否不够、运行的状态及稳定性等。这些问题都不需要客户去管理和维护，只需要负责把各种应用的workload等发布到平台上。与第一种形态的区别是没有三台Master的管理权限，不能去做一些自己想要的定制和修改。但其优点在于可以不用管理集群。针对这样的形态大家在选择上会有取舍，取舍的关键在于是否需要去关注整个Master的管控层面，是否需要主动知道系统的运行状态或者是否需要灵活的控制它。
Serverless Kubernetes：与前两种不同的是，在这个的形态下看不到 k8s node节点的概念，同样也看不到Master和Worker部分，这些会被ECI所取代。当在Serverless k8s上运行一个Pod时，每一个Pod会对应一个轻量级的ECI容器实例，并且Pod与Pod之间是完全独立的，每起一个Pod会提供一个ECI实例，当Pod运行结束时，ECI资源会被收回，真正的做到按量去申请资源及按量付费。

三种Kubernetes集群对比

通过对比这三个集群，标准版k8s中的Master和 Worker均由用户创建，由用户完全的去管理。需要说明的是，现在整个k8s是完全免费的，不需要额外支付产品的费用，只是收取相应的云资源的费用，包括ECS资源、SOB资源及存储资源。相对托管版的集群少一个Master的成本，也不需要管理Master，整个Master是由平台方帮助托管的，用户只要承担Worker的资源费用。Serverless Kubernetes是无需创建和管理Master和 Worker的，只是针对时长（秒）及CPU内存的使用和规格进行计费。真正做到了按需使用资源量，比较适合一些突发的作业或者CI/CD测试的场景。

三种集群的用户画像

由上图可知为三种集群的用户画像，标准版的k8s有完整的技术能力，并且每做一个操作都能预期到可能带来的影响，同时也可能会带来一些不稳定的因素。对于托管版的集群，更多地是关注业务应用，对整个k8s不需要运维，也不需要做Master的各种管控。从未来角度考虑，可能更推荐中小客户使用托管版的集群。Serverless更多的是从业务场景上考虑决定是否要用此形态，在技术上与前面两种没有区别，也完全兼容k8s的各种语法，包括Serverless的各种SOB以及所有k8s的标准API。

阿里云容器平台-Serverless K8S Cluster

Serverless k8s所支持的部分与标准k8s是完全一样的，包括各种Workload、Pod、Service等资源，并且在Serverless中全部能够正常使用，唯一的区别在于，每一个Pod就是ECI的容器实例，那么整个集群的整体水位就会受限于阿里云的售卖区下有多少个售卖资源，这些资源不需要预先的购买，完全等同于阿里云售卖区的售卖资源，可以理解为极致的弹性，不需要按照容量来规划。当作业每天运行不超过48个小时的情况下，使用ECI实例会有成本优势。

多可用区的Kubernetes

阿里云的可用区相当于某一个地域里的机房，例如上海A、上海B、上海C，其实就是在上海这个区域下面的A、B、C不同点的机房，之所以需要提供这么多的可用区概念，是因为传统的单可用区里的Master节点只存在一个可用区里面，万一出现异常的现象，可用区整体就会不可用，同时存在平台上整体不可用的潜在风险。如果把Master节点分布在不同的可用区里面，相当于将Master节点在同城中的多机房里做一个容灾，就可以最大限度的避免因为某个可用区整体不可用从而影响系统稳定性的问题。对于Worker节点，无论是单可用区还是多可用区架构都是可以加入到不同的可用区里面，比如上图中的AZ1有几台机器，AZ2、AZ3都会有不同的机器，共同构建应用workload负载，也都可以跨不同的可用区去部署。如果采用的是托管版的集群，整体的稳定性SLA是由阿里的平台方负责。

应用跨多可用区高可用

阿里建议在做运用部署时，加上一个反亲和策略，使业务均匀的分布在可用区的Worker节点上。如上图所示的label，在不同的可用区节点有个重的标识。假如是单可用区的k8s集群，Master平面全部不可用，但是应用是在不同可用区的机器上的，相当于是保证了运行的业务能够正常的提供服务，最大限度的避免服务的整体中断。

容器网络：Flannel VPC

针对云散的VPC网络特性，有一些自建的客户只能选择封包解包的方案，其中会有一些性能的损失。阿里云针对此方案做出了一些优化，称为Flannel VPC网络插件。传统的Flannel是需要有一个隧道进行封包和解包的过程，而在Flannel VPC下面，这一步通过路由表直接去实现跨主机的容器访问。这样做的好处是Pod IP可以在整个VPC内直达。在VPC内的意思是不光在集群内Pod与Pod是相通的，而且在VPC内的一些ECS节点上也都能够直接访问IP。这一特性在某些早期的dubbo服务注册的场景下有很好的利用价值。因为dubbo里的服务注册都是用IP直接注册，如果使用Flannel容器Pod IP注册，外部的非容器化的应用直接不能访问容器IP，如果使用Flannel VPC方案，整个Pod在所有的VPC主机里都可以直达，好处是省掉了封包和解包的过程，性能会提升10%到15%。但有一个潜在的问题是，当集群的节点数很多时，可能需要扩充路由表的路由条目限制，默认条目是比较小的，为50条，所以当集群的节点超过50个以上，就要主动的联系产品方将条目限制调大。

容器网络：Terway

除Flannel VPC之外，还有一个高性能的容器网络：Terway。可以理解为是一个Pod里面的网卡，与ECS里面的网卡属于同网络平面，都是从VSwitch上分配IP，相当于Pod与ECS是同样的处于一个VSwitch的网络平台面上，每一个Pod就是一个ENI的网卡。通过这样的做法，相当于Pod完全等同于ECS外面的网络平面，从而提供一个很高性能的网络方案。相比前面的Flannel VPC网络方案要强20%到30%，并且支持Kubernetes Network Policy，以及限制出入带宽同时限制网络流量。从未来引进方向上来看，会主推Terway高性能网络方案。但是需要注意的一点是，ENI的网卡在某台ECS上是有数量限制的，不同规格的ECS所能挂载的ENI网卡是不一样的，像最顶配的神龙可以支持32块ENI网卡。由此带来的潜在的影响是所有的Pod不是每个都需要使用ENI，这里就需要加上resources的声明，当需要使用ENI网卡时，加limit阿里云ENI的配置，通知Pod是需要ENI的，这样做会更大的兼容了Flannel VPC的能力，以及ENI规格受限的问题。

二、集群规划创建

在构建和规划之前，有一些需要提前考虑的点，这些点直接影响后续创建的K8S是否为安全的、可伸缩的及稳定的形态。其中包含以下四个评估点：
（1）需要什么样的集群类型？是专有版的集群、托管版的或者是Serverless ？可能会根据企业对整个K8S的掌控要求及业务特性选择集群类型。
（2）在创建集群时要确定相应的网络规划，例如VPC下面要建的多少集群数量、K8S群是否跨可用区、每个可用区的VSwitch应该怎样规划、容器的Pod CIDR怎样与其他不冲突。
（3）集群里应选择什么样的ECS规格、Master节点规格及Worker节点规格，系统盘及Docker存储选用大小，整个ECS的续费方式。
（4）针对整个集群的基本配置，包括K8S的版本选择，IPtables和IPVS转发方式的选择，网络插件的选择等。
以下配置创建选定后，不支持修改的情况如下:

集群类型，不支持切换
系统盘 & Docker存储类型不支持修改
容器Pod/Svc CIDR不支持更改
Kube-proxy转发策略不支持修改（IPtables & IPVS）

创建集群-开始之前，容量规划

在开始创建集群之前，要通过上图中的公式计算容量。包括需要多少个服务，每个服务是有多少实例，每个实例需要多少规格，整体的规格需要给系统提供部分的冗余量。其中系统的冗余量是指k8s本身就是一套复杂的软件架构，每一个组建都占用系统的资源，在建整个k8s时，系统默认会预留一些资源给组件使用，如图中所示的系统预留资源部分，从而保证系统的稳定性。在算整个集群的总容量时，推荐预留20%的冗余相对来说是比较安全的。每个集群创建时有个最大支持节点数，由创建集群指定的Pod CIDR以及每节点分配Pod地址段共同决定。例如，Pod CIDR的配置为：172.16.0.0/16（256个C段地址），每节点Pod地址数128（半个C段），则集群最大可支持 256*2=512节点。由此决定以后的集群可能随着业务的不断增长最大能承载的集群节点数。

创建集群-开始之前，集群规划
在创建集群之前需要确定具体的使用规格、机型及存储容量。以下几点作为集群的规划原则：

ECS规格选型：不可以使用共享型机器作为生产使用，根据部署应用的特性，选择不同。CPU:MEM的机型(通用型、计算型和内存型)，Master节点最低要求4C/8G
机型最好确保是在包年包月中有的，避免后续无法转计费模型
Master机型的建议选择：100节点以内8core/32g，100-200节点16core/64g，尽量预留。多点资源，系统盘选择SSD云盘（ETCD数据存储在这之上）
Worker容量预留：确保剩余的可用容量能承担任意一台ECS掉线带来的容器漂移
Worker节点Dokcer存储空间：存放images以及Pod empty dir等临时数据，如更新发布。频繁、单镜像空间较大，建议空间配置500GB以上SSD云盘

创建集群-多可用区配置

上图为集群创建的Pod界面，首先建议配置多可用区的架构，最大限度的保证管控层面的稳定性。这就需要提前在VPC下面建好可用区以及Vswitch的规划，需要不同区中的每个区里会有不同Vswitch，Vswitch IP地址段与其他区是不能冲突的，并且确定每个区的Vswitch IP段规划大小（比如24位掩码，则最大支持255个节点）。如果希望区承载的节点数更大，那么掩码就需要更小，则能够容忍更多的机器。Master节点建议选择“包年包月”，避免到期未续费而被删除。Master实例个数，一般3个即可。Master实例规格建议选择一致。如果规格不一致，系统组件和资源消耗会不一样，会产生一些疑惑。