Kubernetes集群部署

一、Kubernetes概述

1.1、什么是Kubernetes

• kubernetes是一个可移植、可扩展的开源容器编排系统，主要用于自动化部署、扩展和管理容器应用，提供资源调度、部署管理、服务发现、扩容缩容、监控等功能。对于负载军均衡、服务发现、高可用、滚动升级、自动伸缩等容器云平台的功能要求有原生支持。由于kubernetes在K和s间有8个字母，因此常简称为K8S。2015年7月，kubernetes V1.0正式发布，截至到目前最新稳定版本是V1.18.
• 实际上，随着对K8S系统架构与设计理念的深入了解，可以发现K8S系统正在处处为运行云原生应用而设计考虑的。随着对K8S系统使用的加深和推广，也会有越来越多有关云原生应用的设计模式产生，使得K8S系统架构和开发生产级的复杂云原生应用，变得像启动一个单击版容器服务那样简单易用
• kubernetes可以调度计算集群节点、动态管理节点上作业，并保证它们按用户期望状态运行。通过使用[Labels （标签）] 和 [Pods （荚）]的概念，kubernetes将应用按逻辑单元进行分组，方便管理和服务发现

1.2、为什么要用Kubernetes

使用kubernetes具有以下好处

• 具备微服务架构

微服务架构的核心是将一个巨大的单元应用分解为很多小的相互连接的微服务。一个微服务背后可能有多个实例副本支撑，副本的数量可能会根据系统负荷而进行调整，而K8S平台中内嵌的负载均衡器发挥着重要作用。微服务器使得每个服务都可以由专门的开发团队来开发，开发者可以自由选择开发技术，这对于大规模团队来说很有价值。另外，每个微服务独立开发、升级、扩展，使得系统具备很高的稳定性和快速迭代进化能力

• 具备超强的横向扩容能力

kubernetes系统架构具备超强的横向扩容能力。对于互联网公司来说，用户规模等价于资产，谁拥有更多的用户，谁就能在竞争中胜出，因此超强的横向扩容能力是互联网业务系统的关键指标之一。一个kubernetes集群从只包含几个Node的小集群，平滑扩展到拥有成百上千个Node的大规模集群，利用kubernetes提供的工具，甚至可以在线完成集群的扩容。只要为服务器设计的合理，结合硬件或者公有云资源的线性增加，系统就能够承受大量用户并发访问所带来的压力

二、Kubernetes组件

• 为了理解Kubernetes工作原理，先来分析一下Kubernetes的结构。kubernetes主要包括以下组件

2.1、Master组件

• master组件提供集群的管理控制中心，对于集群进行全局决策（如调度），并检测和相应集群的事件，例如当复制控制器的“副本”字段不满足时启动新的Pod。基本上kubernetes所有的控制命令都是发给master，master负责具体的执行过程。master组件可以在集群中的任何计算机上运行，但建议master节点独占一台独立的服务器。因为master是整个集群的大脑。如果master所在的节点宕机或不可用，那么所有的控制命令都将失效

Master组件运行的节点一般称之为Master节点，在Master节点上运行着以下关键进程。

• kube-apiserver：用于暴露kubernetes API，任何资源请求/调度操作都是通过kube-apiserver提供的接口进行。提供了HTTP Rest接口的关键服务进程，是kubernetes中所有资源的增、删、改、查等操作的唯一入口，也是季芹控制入口的进程
• Etcd：是kubernetes提供的默认存储，所有集群数据都保存在Etcd中，使用时建议为Ectd数据提供备份计划
• kube-scheduler：是负责资源调度的进程，监视新创建且没有分配到Node的Pod，为Pod选择一个Node
• kube-controller-manager：运行管理控制器，是集群中处理常规任何的后台进程，是kubenetes里所有资源对象的自动化控制中心。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。这些控制器主要包括：

节点控制器（Node controller）：负责在节点出现故障时发现和响应；

复制控制器（Replication Controller）：负责为系统中的每个复制控制器对象维护正确数量的Pod；

端点控制器（Endpoints Controller）：填充端点对象（即连接Services和Pods）；

服务账户和令牌控制器（Service Account & Token Controllers）：为新的命令空间创建默认账户和API访问令牌

2.2、Node组件

• 除了master，kubernetes集群中的其他机器被称为Node节点。与master节点一样，Node节点可以是一台物理主机，也可以是一台虚拟机。Node节点是kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载。当某个Node宕机时，其上的工作负载会被master自动转移到其他节点上

每个Node节点上都运行着以下关键进程：

• kubelet：负载Pod对用容器的创建、启停等任务，同时与master节点密切协作，实现集群管理的基本功能

• kube-proxy：用于实现kubernetes Service之间的通信与负载均衡机制

• Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作。

Node节点可以在运行期间动态增加到kubernetes集群中，提前是这个节点上已经正确安装、配置和启动了上述关键进程。在默认情况下，kubelet会向master注册自己，这也是kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet进程会定时向master汇报自身的情况，例如操作系统、Docker版本、机器的CPU和内存情况，以及之前有哪些Pod在运行等。这样master可以获知每个Node的资源使用情况，并实现高效负载均衡资源调度策略。而某一个Node超过指定事件不上报信息时，会被master判定为失聪（坏的状态，大白话就是不能用了）的状态，被标记为不可用，随后master会触发节点转移进程

三、Kubernetes资源对象

• kubernetes包含多种类型的资源对象：Pod、Replication Controller、Service、Deployment、Job、DaemonSet等。所有的资源对象都可以通过kubernetes提供的kubectl工具进行增、删、改、查等操作，并将其保存在Etcd中持久化存储。从这个角度来看，kubernets其实是一个高度自动化的资源控制系统，通过跟踪对比Ectd存储里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能，下面对常用的资源对象分别进行介绍

3.1、Pod

• Pod（豆荚）是kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。一个Pod由一个或多个容器组成，Pod中容器共享存储和网络，在同一台Docker主机上运行。每个Pod都有一个特俗的被称为“根容器”的Pause容器，Pause容器对象的镜像属于kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器

3.2、Label

• Label（标签）是kubernetes系统中另一个核心概念。一个Label是一个key-value的键值对，其中key与value由用户自己指定。Label可以附加到各种资源对象上，例如Node、Pod、Service、RC（命名空间）等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象中，也可以在对象创建后动态添加或者删除
• 另外可以通过给指定的资源对象捆绑一个或多个不同Label，来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。给某个资源对象定义一个Label，就相当于给他打了一个标签；随后可以通过Label selector标签选择器查询和筛选拥有某些Label的资源对象，kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制

3.3、Replication Controller

• Replication Controller（复制控制器，RC）是kubernetes集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是1个或多个；如果少于指定数目，RC就会运行新的Pod副本。如果多余指定数目，RC就会杀死多余的Pod副本。即使在数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8S较早期的技术概念，只适用于长期的业务类型，比如控制小机器人提供高可用的Web服务

3.4、Deployment

• Deployment（部署）表示用户对K8S集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建或更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际上创建一个新的RS，然后逐渐将新的RS中副本数量增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，需要用一个更通用的Deployment来描述。未来对所有长期服务型业务的管理，都会通过Deployment来管理

3.5、Service

• RC和Deployment只是保证了支撑Service（服务）的微服务Pod的数量，但是没有解决如果访问这些服务的问题。一个Pod是一个运行服务的实例，随时可能在一个节点上停止、在另一个节点以新的IP地址启动一个新的Pod，因此不能固定的IP地址和端口号提供服务。要稳定地提供服务，需要服务发信啊和负载均衡能力。服务发现完成的工作，针对客户端访问的服务，找到对应的后端服务实例
• 在K8S集群中，客户端需要访问的服务就是Service对象。每个Service会对用一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8S集群中微服务的负载均衡是由kube-proxy实现的。kube-proxy是K8S集群内部的负载均衡器。它是一个分布式代理服务器，在K8S的每个节点上都会运行一个kube-proxy组件；这一设计体现了他的伸缩性优势，需要访问服务的节点越多，提供负载据呢胡歌你能力的kube-proxy就越多，高可用节点也会随之增多。与之相比，通过在服务器端部署反向代理做负载均衡，还需要进一步解决反向代理的负载均衡和高可用问题

3.6、Job计划任务

• Job是kubernetes用来控制批量处理型任务的API对象。批处理业务于长期服务业务的主要区别是批处理业务的运行有头有尾，而长期业务在用户不停止的情况下永远运行。根据用户的设置，job管理的Pod吧任务成功完成后就自动退出了。成功完成的标志根据不同的spec.completins策略而不同：单Pod型任务有一个Pod成功就标志完成；定数成功型任务保证有N个任务全部成功；工作队列任务根据应用确认的全局成功而标识成功

3.7、DaemonSet

• 后台支撑型服务的核心关注点在kubernetes集群中的节点（物理机或虚拟机），DamemonSet（守护程序集）确保所有或某些节点运行同一个Pod，要保证每个节点上都有一个此类Pod运行。节点可能是所有集群节点也可能是通过nodeSelector选定的一些特定节点。典型的后台支撑服务包括，存储，日志和监控等在每个节点上支持K8S集群运行的服务
• 上述组件于资源对象是kubernetes系统的核心，它们共同构成了kubernetes系统的框架和计算模型。通过对它们进行灵活的配置，用户就可以快速、方便地对容器集群进行配置和管理。除了刚刚所介绍的核心组件与资源对象之外，在kubernetes系统中还有很多辅助的资源对象，例如LimitRange、ResourceQuota。另外，一些系统内部使用的对象参考kubernetes的API文档
  

四、什么是kubadm

• kubeadm是谷歌推出的一个专门快速不舒服kubernetes集群的工具。在集群部署的过程中，可以通过kubeadm init来初始化master节点，然后使用kubeadm join将其他的节点加入到集群中
• kubeadm通过简答配置可以快速将一个最小可用的集群运行起来。它在设计之初关注点是快速部署安装并将集群运行起来，而不是一步一步关于各节点环境的准备工作。同样的，kubernetes集群在使用过程中的各种插件也不是kubeadm关注的重点，比如kubernetes集群Web Dashboard、prometheus监控集群业务等。kubeadm应用的目的是作为所有部署的基础，并通过kubeadm使得部署kubernetes集群更加容器

kubeadm的简单快捷的部署可以应用到如下三方面：

• 新用户可以从kubeadm开始快速搭建kubernetes并了解
• 熟悉kubernetes的用户可以使用kubeadm快速搭建集群并测试他们的应用
• 大型的项目可以将kubeadm配合其他的安装工具一起使用，形成一个比较复杂的系统