在使用 Kubernetes 集群作为一个容器编排平台的时候, 如何规划好这个资源池的使用是一个非常有意义的事情. 结合 kubernetes 的标签管理以及 ACK 提供的节点多规格及多可用区支持, 好的集群规划能够给应用部署带来更好的体验. 本文主要指导如何选择需要创建的集群及集群节点规划.
一 , 集群选择
1, 产品类型
当前产品包括三大类型的产品形态:
1)用户可以拿到 master 和 worker:dedicated kubernetes 和多可用区 kubernetes;
2)托管版 kubernetes;
3)Serverless kubernetes
2, 产品类型主要区别
3, 各产品类型的优劣势
1)kubernetes / 多可用区 kubernetes
优势:
a,master 和 worker 都归用户所有, 用户可以对 master 节点和 worker 节点上的任何组件进行管理;
b, 可以最大限度的了解 ACK 各组件的部署方式;
劣势:
a,master 节点 (三个) 需要收费, 并且随着集群规模变大, master 节点需要不断升级配置, 费用较高;
b,ACK 集群中的所有管控组件, 也就是除了用户的应用外, 原则上不建议用户进行修改, 该种模式下用户可以修改任何管控组件, 风险较高;
2)托管版 kubernetes
优势:
a,master 节点由阿里云托管并保证其功能及性能; 在功能上与前面的 kubernetes 集群保持一致, 体验一致;
b,master 节点不收费, 并且节点增加无需关心 master 节点是否需要扩容;
c,master 节点不收费的情况下, 可以允许用户创建集群不需考虑集群节点个数, 创建集群更加灵活, 打个比方(但是不建议这么做): 用户可以一种类型的应用创建一个集群;
d,master 节点上的组件用户不能操作, 减少了用户误操作的可能性;
劣势:
a,master 节点组件日志需要后台阿里云同学来查看;
b, 对于初级用户完整的掌握 ACK 的部署有阻碍;
3)Serverless kubernetes
适用于特殊场景, 不会长期占有资源, 对资源的使用方式为按需使用, 比如离线计算的场景, 在计算的时候需要根据实时负载扩容资源, 当计算完成后所有的资源及时回收, 做到资源利用率最高;
4, 推荐类型
除非业务类型非常适用于 serverless, 其他情况下都是推荐:
推荐使用托管版 kubernetes.
二, 节点选择
在这里不讨论节点规格的问题, 节点规格可以参考文档: https://yq.aliyun.com/articles/602932
在确定了节点规格后, 建议后续的节点除了必须选择的节点外, 其他的都是通过手动添加进来, 这样做有以下好处:
1, 避免所有的节点都在一个可用区;
2, 后续可以通过添加多可用区的节点配合反亲和性实现 pod 在部署时的跨可用区高可用;
3, 用户对节点进行规划管理;
三, 添加不同可用区的节点的注意事项
1, 检查 networkgateway
需要检查加入的节点与原集群是否正确配置路由
2, 与其他相关云产品的白名单
需要检查其他云产品是否开启了白名单, 比如 RDS 等;
3, 存储
检查使用到的存储是否可以跨可用区访问;
4, 检查安全组相关配置
5, 延时
如果部署的应用对延时敏感, 需要测试跨可用区的节点延时是否能够接受;
四, 使用标签进行节点规划
Kubernetes 集群无论使用 ECS 还是神龙服务器作为 worker 节点, 从应用调度角度来看, 一个集群就是一个大的资源池, worker 节点规格越大, 个数越多, 这个资源池越大.
如果不对 worker 节点不做任何的标签管理, 并且在部署应用的时候不指定任何的节点标签, 那么对于所有的应用来说, 整个集群的所有节点都是可以调度的. 随着集群和应用规模的不断扩大, 这样会对节点及应用的管理是很麻烦的, 在这里推荐这样的集群管理及应用部署方式, 示意图如下:
1, 首先要了解集群中的节点类型, 比如内存型的, IO 型的等等; 因为在前面推荐手动添加进来, 所以在添加前要做合理的规划;
下面这个图只是 ECS 创建的一个分类方式, 具体的配置在各个组合下面会有更详细的内容;
2, 其次要能够对自己的应用做一个归类, 找到适合应用的机型, 在这里不一定是一个应用, 可以是有共同特征的一类应用;
3, 根据应用类型对不同的节点打标签, 然后在部署应用的时候将应用部署在最合适的节点上面; 比如有些应用是流量的出入口, 我们可以将该应用部署在网络增强型的机器上;
4, 同一种类型的节点在购买的时候也可以多可用区购买, 这样在 pod 部署的时候配合亲和性和反亲和性可以做到一个应用的多个 pod 部署在不同的可用区;
标签管理的好处:
1, 通过标签管理可以将应用在大的资源池中分配到有限可知的几个节点上, 能够做到在应用出现问题或者节点出现问题时能够快速定位并缩小影响范围;
2, 由于应用正在部署的时候是需要拉取镜像的, 拉取镜像需要用到本地盘的空间, 如果在所有节点上都拉取镜像的话, 当存储空间达到 80% 时会触发 kubelet 对镜像的清理, 造成应用部署时间延长; 通过标签进行管理后, 能够防止应用在所有节点上调度, 也就避免了在所有节点上拉取镜像, 缩短应用的启动时间;
3, 多可用区高可用变得简单;
4, 可以提前在应用部署的目标主机上进行 docker image 的预热, 而不用在所有的节点上进行;
来源: https://yq.aliyun.com/articles/694620