【生产环境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设计要素

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

下面就说一说再Kubernetes系统设计的时候，针对每个非功能需求该如何设计。

1. 【可靠性】易恢复性、容错性；
   一个健壮的系统必须要具有容错能力和恢复能力。当系统的某一部分发生故障时，系统整体的服务并不会因此而停止；并且可以通过我们提前准备好的恢复方案，迅速的恢复故障点，在整个过程中不会让系统使用者感知到发生的这一切。要想实现系统的可靠性需求，通常采取的对策有冗长化、备份还原、监控报警、24小时对应体制。
   那在Kubernetes Cluster生产环境中这些可靠性对策如何实现呢，让我们在逐一分析一下。

• 冗长化
  从上文中的构成图上能够直观看到Master和Node都是采用了集群方式的构成，运行在Cluster上的Pod也是冗长构成，但是仅这些还是不够的。我们要把所有有可能发生单点故障的地方全部找出来，然后通过相应的技术方案实现冗长，通常容易忽略的地方所有网路线路的冗长，交换机等网络设备的冗长，负荷分散装置的冗长等等，只要是跟我们系统相关的任何地方和设备，我们都应该考虑是否需要实现冗长。如果是使用云服务的话，运营商会替我们实现基础设施的冗长化，这样我们会减少很多工作量。另外就是我们业务的拆分和解耦也可以在一定程度上间接提高系统的可靠性。

分类	冗长构成部分
服务器	Master
	Node
基础设施	网络线路
	网络设备（交换机，负荷分散）
	存储设备
业务服务	Kubernetes 中通常是pod
其他	所有跟系统相关的部分

• 备份还原
  很多故障都是我们人为操作所造成的，比如数据误删除，发布内容的错误，这样的故障通常是很容易定位原因，我们只需要通过数据还原和版本回滚的方法就可以实现故障恢复。但这些都是建立在我们有高瞻远瞩的目光和准备——即备份和版本管理，它对系统的保护起着至关重要的作用。通常需要备份的有OS整体的备份，数据库数据备份，重要的业务文件备份。在Kubernetes Cluster生产环境中需要对保存着Cluster重要信息的etcd进行备份，还有就Master和Node的备份，如果你使用之前我们在Control System那章里讲到的Kubernetes管理工具的话，可以不用备份Master和Node自体，因为工具记录着你的Cluster的完整信息，在需要的时候它可以恢复整个Cluster。另外还有就是我Docker image和Helm chart等等

分类	备份部分
Cluster	Master
	Node
	etcd数据
业务服务	Docker image
	Helm chart
	业务数据、业务文件等等
	日志

• 监控报警
  在系统出现故障的时候，第一时间发现并通知给相关人员至关重要，这样技术人员可以及时介入，防止故障进一步扩大，关于监控系统我们在第三章中已经详细介绍了。这里就不在多做说明。

• 24小时对应体制
  故障出现后，技术人员必须第一时间介入，第一时间解决故障，那么我们就需要组建一个24小时待命的运维团队。运维团队时时刻刻为我们的系统保驾护航。

2 【性能需求】响应时间、吞吐量、资源利用率；
响应时间和吞吐量是衡量一个系统的主要指标，常说“没有那金刚钻就别揽瓷器活”，我们在设计系统的时候必须要事情弄清楚我们系统将来要面对的压力，比如单个处理的响应时间要求、单位时间最大访问量的要求、单位时间最大处理量的要求等等这样的性能需求。把这些需求整理清楚之后，在设计系统的时候根据这些需求决定我们的服务器台数、服务器配置、网络带宽、存储容量、负荷分散算法、以及是否使用缓存等技术，这样我们搭建出来的系统才是一个能达到性能要求的健康系统。

3 【安全性】保密性、防泄漏、权限控制、防攻击；
安全性就是要求系统有一个有效的安全防御解决方案和权限控制策略，防止系统敏感信息泄露和不正当访问。在做设计的时候通常我愿意把它分为外部和内部来考虑，不论是内部还是外部对策都是基本类似的，下表就是通常采取的安全性对策。

分类	对策	说明
外部	病毒安全工具	防止来自外部的病毒和攻击
	认证	防止来自外部的不正当访问
	网络隔离	把敏感的部分隐藏起来
内部	病毒安全工具	防止来自内部的病毒
	权限控制	权限分级，避免权限过大导致信息泄露或误操作
	唯一入口服务器	内部隔离的一种形式，只能通过入口服务器才能接触的系统中的其他服务器，方便操作监控和权限管理

4 【可扩展性】水平扩展，垂直扩展
这个通常是很容易理解，包括服务器的台数的扩展，CPU、内存、存储的扩展、服务的扩展等等，但在Kubernetes Cluster中不同的地方是，所有的扩张要求必须自动完成，不需要人工介入。这样才能体现出Kubenetes的优势。我们在设计Kubernetes Cluster的时候至少要考虑到下表中的扩展需求。

分类	扩张内容	自动/非自动
Cluster Autoscaler	水平Cluster扩展	自动（需要云服务等第三方支持）
	垂直Cluster扩展	自动（需要云服务等第三方支持）
pod Autoscaler	水平扩张	HPA自动
	垂直扩张	VPA自动 （但不建议使用）

5 【可维护性】模块性、可复用性、易分析性；
系统正式上线以后，就会进去运维阶段，这个阶段会一直伴随着系统的整个生命周期，所以一个容易维护的系统，可以减少运维人员的工作量和误操作的几率，等于间接提高了系统的可靠性。因为Kubenetes系统的构成基本是固定的，都是Master和Node的这种形式，那么对于今后能方便的维护Kubernetes系统，主要是可复用和易分析这两方面考虑。下表就是为了达到可复用和易分析的对策。

分类	设计对策	说明
可复用	搭建测试用环境	同生产环境同样的环境，等同于复用了生产环境，是减少生产环境故障的重要保障
	使用第三方的管理工具	前几章我们提到的Pivotal这样的工具，可以很方变帮我们完成重复的KubernetesCluster管理工作
	丰富的说明书	重复出现或类似的问题故障，编写到说明书中，今后可以直接使用
易分析	详细易懂的设计资料	系统框架图等等设计资料都是日后运维时候重要参考资料
	收集有效的日志信息	通过日志信息收集系统，为我们收集有效完整的日志信息，以供分析时使用

4.总结

不管是设计什么样的系统，都需要在设计前整理分析非功能需求，针对每个非功能需求找到相应的解决方案，然后再把这些解决方案反应到你设计中去，这样设计出来的系统肯定是一个健康的系统。当然整理分析非功能需求和找到相应的解决方案不是一件容易的事情，需要要求设计人员既要有技术知识，又要有足够的设计经验，只有通过长时间的项目经验和技术知识的积累才能达到一个真正的系统框架设计师。

作者：rm * 小组
日期：2020年9月12日