如何在阿里云上构建一个合适的Kubernetes集群

摘要： 声明 本文主要介绍如何在阿里云上构建一个K8S集群的实践，只是作为参考，大家可以根据实际情况做出调整。 集群规划 在实际案例中发现，有不少同学使用了很多的小规格的ECS来构建K8S集群，这样其实即没有达到省钱的目的，也没有很好的发挥K8S集群的优势。

声明

本文主要介绍如何在阿里云上构建一个K8S集群的实践，只是作为参考，大家可以根据实际情况做出调整。

集群规划

在实际案例中发现，有不少同学使用了很多的小规格的ECS来构建K8S集群，这样其实即没有达到省钱的目的，也没有很好的发挥K8S集群的优势。因为通过大量的小型ECS构建集群有几个弊端：

• 小规格Woker ECS的网络资源受限

• 如果一个容器基本能占用掉一个小规格ECS，那么这个的机器的剩余资源就无法利用（构建新的容器或者是恢复失败的容器），在ECS数量多的情况，反而是一种浪费。

那么如何选择Worker ECS的规格呢？

• 确定整个集群的日常使用的总核数以及可用度的容忍度。例如总的核数有160核，同时容忍10%的错误。那么最小选择10台ECS为16核的机器，并且高峰运行的负荷不要超过16090%=144核。如果容忍度是20%，那么最小选择5台32核的机器，并且高峰运行的负荷不要超过16080%=128核。这样确保，就算有一台机器整体crash都可以支持得住业务运行。

• 但是上面这个计算只是理论值，因为规格小的机器，很可能剩余不可利用的资源的比例就高。所以不是越小的机器越好。

• 选择好CPU：Memory的比例。对于使用内存比较多的应用例如java类应用，建议考虑使用1:8的机型。

高规格ECS的一些好处：

• 高规格的好处是，网络带宽大，对于大带宽类的应用，资源利用率也高。

• 在一台机器内容器建通信的比例增大，减少网络的传输

• 拉取镜像的效率更好。因为镜像只需要拉取一次就可以被多个容器使用。而对于小规格的ECS拉取镜像的此时就增多。在需要联动ECS做伸缩的场景，则需要花费的时间更长，反而达不到立即响应的目的

选用神龙服务器

阿里云已经推出了裸金属服务器：神龙，选用神龙服务比较典型的两个场景：

• 如果在集群日常规模能够到1000个核的情况下，建议全部选择神龙服务器。（神龙服务器96核起）这样可以通过10～11台神龙服务器构建一个集群。

• 需要快速扩大比较多的容器的时候，特别是电商类大促的时候，应对流量尖峰，可以考虑使用神龙服务来作为新增的节点，这样增加一台神龙就可以支持很多个容器运行了。

神龙服务作为容器集群的构建基础，还有以下好处：

• 超强网络： 配备RDMA技术。通过Terway容器网络，充分发挥硬件性能跨宿主机容器带宽超过9Gbit/s

• 计算性能零抖动：自研芯片取代Hypervisor，无虚拟化开销，无资源抢占

• 安全：物理级别加密，支持Intel SGX加密，可信计算环境，支持区块链等应用

构建集群选项注意点

在构建k8s集群是，有很多选项需要注意：

网络选择

• 如果需要连接外部的一有服务，如 rds等，则需要考虑复用原有的VPC，而不是取创建一个新的VPC。因为VPC间是隔离的。但是可以通过创建一个新的交换机，把k8s的机器都放在这个交换机，便于管理。

• 网络插件的选择：目前支持两种插件，一种是flannel，直通VPC，性能最高。一种是Terway，提供k8s的网络策略管理。

• POD CIDR，整个集群的POD的网络。这个不能设置太小。因为设置太小，能支持的节点数量就受限了。这个与高级选项中“每个节点POD的数量有关”。例如POD CIDR是/16的网段，那么就有256*256个地址，如果每个几点POD数量是128，则最多可以支持512个节点。

磁盘的选择

• 尽量选择SSD盘

• 对于Worker节点，尽量选择“挂在数据盘”。因为这个盘是专门提供给/var/lib/docker，使用来存放本地镜像的。避免后续如果镜像太多撑爆根磁盘。在运行一段时间后，本地会存在很多无用的镜像。比较快捷的方式就是，先下线这台机器，重新构建这个磁盘，然后再上线。

日常运维设置

• 对于ECS的监控，日常运维一定设置CPU, Memory，磁盘的告警。再次说明一下，尽量将/var/lib/docker放在独立一个盘上

• 一定配置日志收集

是否需要立即构建Worker节点

目前集群的创建方式使用的ECS是按照量计费的模式。如果需要包年包月，则可以考虑先不创建Worker节点，然后创建k8s集群完后，再单独购买ECS后添加进集群里。

K8S稳定性的考虑

参考 https://yq.aliyun.com/articles/599169?spm=a2c4e.11153959.0.0.4eebd55aSdySUm

Serverless Kubernetes

如果管理和维护Kuberntes集群太过于麻烦，为什么不试试我们的Serverless Kubernetes呢？