摘要： 声明 本文主要介绍如何在阿里云上构建一个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呢？
原文链接请添加链接描述
本文为云栖社区原创内容，未经允许不得转载
原文地址：http://blog.51cto.com/13866390/2145981