【生产环境K8S从搭建到运维的实录（四）】Kubernetes Cluster

【生产环境K8S从搭建到运维的实录（四）】Kubernetes Cluster的设计

1.前言

Kubernetes Cluster无疑是我们系统里的主角了，毕竟最终我们的服务都是要运行在它上边。所以在搭建kubernetes Cluster前 ，做好规划是非常重要的。这次我们就说一说设计Kubernetes Cluster的时候要考虑哪些东西。

2.一个简单的Kubernetes Cluster

首先我们先来看一个建党的Kubernetes Cluster构成。

在这个Cluster中，很明显有3台Master和5台Node所组成，都是奇数台，为什么采用奇数台的理由在这里就不解释了，不知道的话可以网上搜索一下。还可以看到有很多运行在Master和Node上最基本的Kubenetes Resource。下面我们就稍微详细的分析一下。

2-1.Master和Node的构成

• Master：3台
  Master作为整个集群的控制中心至关重要，在生产环境中必须是集群构成。至于台数的话，至少是3太以上的奇数台构成。

• Node：5台
  Node作为我们提供服务Pod的载体，也是不可以出现任何闪失的，在生产环境中必须是集群构成。至于太数的话就根据自己实际需求来决定了，有可能是3台，也可以是几十台。

2-2.Kubenetes Resource

运行Master和Node上的Resource我分为3大类：

• Application Resource
  Application Resource 主要是指我们提供服务Pod Resource和暴露服务用的Service Resource。他们通过Deployment，daemonset等控制器，调度到各个Node上运行，对外提供我们的服务。
  Application Resource建议不要运行在Master上面，因为Master的功能不是用来运行我们的服务，它是用来管理我们整个Kubenetes Cluster的，保证Kubenetes Cluster能够正常的运转。通常Master的配置并不是很高，所以也不适合作为我们服务的载体来使用。通俗一点说就是：Master主内，Node主外。

• Control Resource
  Control Resource主要是作用是，通过HPA，quota，limitaRange等Resource提高Pod服务的可靠性，而不至于因为高负荷的时候我们服务挂掉，也不至于因为我们程序Bug导致的大量使用CPU，内存等资源导致Node挂掉。另外还可以通过ServiceAccount，Role等Resource进行权限管理，防止权限乱用导致操作失误，间接的保护了我们的服务。同样这些Resource也不要运行在Master上。

• Monitor Resource
  Monitor Resource这个很容易理解，就是对我们Kubenetes Cluster，Node，Pod进行监控和信息收集。监控是为了我们能够在出现系统故障或服务故障的时候及时的通知相关人员，信息收集是为了我们通过对这些信息的分析，判断系统的健康和预测系统将来会发生的问题，另外对业务信息进行分析，可以创造出商业价值。

上面只是一个简单的Kubernetes Cluster的结构图，那么我们如何才能整整设计出一个生产环境用的系统呢，我们在设计Kubenetes Cluster的时候必须要考虑的事情有哪些呢，接下来我们就来说一说。

3.Kubenetes Cluster设计要素

主要还是从非功能需求出发，整理从所有的非功能需求，针对每个需求找到应对方案，然后反应到设计当中去。