[TOC]

一、概述

1.1、什么是Kubernetes

​ Kubernetes是容器集群管理系统，是一个开源平台，可以实现容器集群的自动化部署、自动扩缩容、调度、维护等功能。通过Kubernetes你可以：

• 快速部署应用
• 快速扩展应用
• 无缝对接新的应用功能
• 节省资源，优化硬件资源利用率

1.2、Kubernetes特点

• 可移植：支持公有云、私有云、混合云、多重云
• 可扩展：模块化、插件化、可挂载、可组合
• 自动化：自动部署、自动重启、自动复制、自动伸缩/扩展

1.3、Kubernetes组件

master节点：

• etcd：

  用于共享配置和服务发现，一致性的KV存储系统，保存了整个集群的状态。

• apiserver：

  提供了HTTP Rest接口的关键服务进程，是kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。并提供认证、授权、访问控制、API注册和发现等机制。

• controller manager：

  kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的"大总管"。

• scheduler：

  负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上，相当于公交公司的"调度室"。

node节点：

• kubelet：

  负责Pod对应的容器的创建、启停等任务，同时与master节点密切协作，实现集群管理的基本功能。维护容器的生命周期，同时也负责Volume（CVUI）和网络（CNI）的管理

• kube-proxy：

  负责为Service提供Cluster内部的服务发现和负载均衡

• container runtime：

  负责镜像管理以及Pod和容器的真正运行（CRI）

除了核心组件，还有一些推荐的Add-ons：

• coredns：

  负责为整个集群提供DNS服务

• ingress controller：

  为服务提供外网入口

• heapster：

  提供资源监控，逐步被放弃，被metrics-server代替

• metrics-server：

  metrics Server 是集群范围资源使用数据的聚合器，用来替换heapster

• dashboard：

  提供GUI

• federation：

  提供跨可用区、跨云的多集群管理

• fluentd-elasticsearch：

  提供集群日志采集、存储与查询

• prometheus：

  提供集群的监控采集与查询

1.4、kubernetes架构图

CloudNativeLandscape_latest

1.5、kubernetes分层架构

CloudNativeLandscape_latest

• 核心层：kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
• 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
• 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
• 接口层：kubectl命令行工具、客户端SDK以及集群联邦
• 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以分为两个范畴
  • kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
  • kubernetes内部：CRI、CNI、CVI、registry、Cloud Provider、集群自身的配置和管理等

二、kubernets基本概念

2.1、Master

​ Kubernets里的master指的是集群控制节点，每个kubenetes集群里需要至少有一个master节点来负责整个集群的管理和控制，基本上kubbenetes所有的控制命令都是发给它，它来负责具体的执行过程。master节点是整个集群的"大脑"，如果出现宕机或不可用，那我们所有控制命令都会失效，所以一般会配置master节点高可用。

2.2、Node

​ Node节点可以在运行期间动态的加入到kubernetes集群中，前提是这个节点已经正确安装、配置和启动了相关组件，在默认情况下kubelet会向master注册自己，这也是kubernetes推荐的Node管理方式。

​ 一旦Node被纳入集群管理范围，kubelet进程就会定时向master节点汇报自身的情况，例如操作系统、Docker版本、机器资源（cpu、mem等）情况，以及之前有哪些Pod在运行等，这样master可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。

​ 某个Node超过指定时间不上报信息时，会被master判定为"失联"，Node的状态会被标记为不可用（Not Ready），随后master会触发"工作负载大转移"的自动流程。

2.3、Pod

2.3.1、基本原理

​ Pod是kubernetes最重要最基本的概念，每个Pod都会有一个特殊的被称为"根容器"的Pause容器。Pause容器对应的镜像属于kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

​ 在一组容器作为一个单元的情况下，我们难以对"整体"简单的进行判断及有效的进行处理。比如，一个容器不可用了，此时算是整体不可用吗？是n/m的不可用率吗？引入业务无关并且不容易停止服务的Pause容器作为pod的根容器，以它的状态代表整个容器组的状态，就简单、巧妙的解决了这个问题。

​ Pod里的多个业务容器共享pause容器的IP，共享Pause容器挂载的Volume，这样既简化了密切关联的业务容器之间的通信问题，也解决了容器之间的文件共享问题。

​ Kubernetes为每个Pod都分配了唯一的IP地址，一个Pod里的多个容器共享Pod IP地址。kubernetes要求底层网络支持集群内任意两个pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术来实现，例如Flannel、calico等。在kubernetes里，一个Pod里的容器与不通主机上的Pod容器能够直接通信。

k8s1.jpg

2.3.2、Pod创建过程

• 通过apiserver REST API发起创建Pod请求，也可以是kubectl命令行。

• apiserver接收到创建Pod的请求后，将数据写入etcd中。

• scheduler通过apiserver watch API监测发现新Pod，这个时候Pod还没有和任何Node节点绑定。

• schedule通过指定的资源量等规则过滤掉不符合要求的Node节点（调度预选）

• schedule接着对上一步符合要求的Node节点进行打分，在打分阶段，schedule会考虑整体优化方案，例如将一个Replication Set的副本分布到不同的Node节点上、使用最低负载的Node节点等。

• scheduler经过复杂的调度策略，选择出打分最高的Node节点，将Pod和筛选出的Node进行绑定，同时将信息更新到etcd中。

• kubelet通过apiserver watch API监测到有新的Pod被调度过来了，就将Pod的相关数据传递给容器运行时（container runtime）例如Docker，让它运行此Pod

• kubelet通过container runtime获取Pod的状态，然后通知给apiserver，由apiserver处理写入etcd。

k8s2.png

2.4、Label

2.4.1、基本原理

​ Label是k8s系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己制定。Label可以关联到各种资源对象上，比如Node、Pod、Service等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上，Label通常在资源对象定义时确定，也可以在资源对象创建后添加或删除。

​ 我们可以通过给指定的资源对象关联一个或多个不同的Label来实现多维度的资源分组管理功能，以便于灵活、方便的进行资源分配、调度、配置、部署等管理工作。

2.4.2、Label Selector

2.4.2.1、基本原理

​ 给某个资源对象定义个Label后，就可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，k8s通过这种方式实现了类型SQL的简单又通用的对象查询机制。

​ Label Selector可以被类比为SQl语句中的where查询条件，例如：role=ingress作用于Pod时，可以类比为select * from pod where pod's name='ingress'这样的SQL语句。当前Label Selector分为两种：

• 基于等式（Equality-based）：name=ingress，匹配所有具有标签name=ingress的资源对象；env != prd，匹配所有不具有标签env=prd的资源对象，比如env=qa就满足此条件。
• 基于集合（Set-based）：env in （dev,qa），匹配所有具体标签env=dev或env=qa的资源对象；env notin （prd），匹配所有不具有标签env=prd的资源对象。

​ 可以通过多个Label Selector表达式的组合实现复杂的条件选择，多个表达式之间用"，"分隔，几个条件之间是"AND"的关系。

2.4.2.2、Label Selector重要使用场景

• kube-controller进程通过资源对象RS上定义的Label Selector来筛选要监控的Pod副本数量，从而实现Pod副本的数量始终符合预期设定的全自动控制流程。
• kube-proxy进程通过Servcie的Label Selector来选择对应的Pod，自动建立起每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
• 通过对某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略，kube-scheduler进程可以实现Pod“"定向调度"的特性。

​ 使用Label可以给对象创建多组标签，Label和Label Selector共同构成了k8s系统中最核心的应用模型，使得被管理对象能够被精细分组管理，同时实现了整个集群的高可用性。

2.5、Replica Set

​ Replica Set（后面简称RS）是Replication Controller（后面简称RC）的升级版，唯一的区别是Replica Set支持基于集合的Label Selector（Set-based Selector），而RC只支持基于等式的Label Selector（Equality-based Selector），这使得RS功能更强。实际上，我们很少单独使用RS，它主要被Deployment这个更高层的资源对象所包含，从而形成一整套Pod创建、删除、更新的编排机制。当我们使用Deployment时，无需关系它是如何创建、维护RS的，这一切都是自动发生的。

​ Replica Set是k8s系统中的核心概念之一，它定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，RS的定义包括以下几个部分：

• Pod期待的副本数（replicas）
• 用于筛选目标Pod的Label Selector
• 当Pod的副本数量小于预期数量的话，用于创建新Pod的Pod模版。

​ 当我们定义了一个RS并提交到k8s以后，Master节点上的Controller Manager组件就得到通知，定期巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RS的期望值，如果有过多的Pod副本在运行，系统就会停掉一些Pod，否则，系统就会再自动创建一些Pod。通过RS，k8s实现了用户应用集群的高可用性，并且大大减少了系统管理员在传统IT架构中许多手动运维工作。

​ 通常我们升级应用时，希望更平滑的方式，比如停止一个旧版本Pod，同时升级一个新版本Pod，在整个升级过程中，Pod数量始终不变，也一直有Pod提供服务，不至于服务中断。通过RS机制，k8s很容易实现这种高级实用的特性，被称为"滚动更新（Rolling Update）"。

2.6、Deployment

2.6.1、基本原理

​ Deployment内部使用了Replica Set来实现的，Deployment相对于RC的一个最大升级时我们可以随时知道当前Pod"部署"的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间，所有我们期望系统启动N个Pod副本的目标状态，实际上是一个连续变化的"部署过程"导致的最终状态。

2.6.2、典型场景

• 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程
• 检查Deployment的状态来看部署动作是否完成（Pod副本的数量是否达到预期的值）
• 更新Deployment以创建新的Pod（比如镜像升级）
• 如果当前Deployment不稳定，则回滚到一个早先的Deployment版本
• 挂起或者恢复一个Deployment

2.6.3、Deployment说明

k8s3.png

• NAME：Deployment的名称
• DESIRED：Pod副本数量的期望值，即Deployment里定义的replica。
• CURRENT：当前replica的值，实际上是Deployment所创建的replica set里的replica值，这个值不断增加，直到达到DESIRED为止，表明整个部署过程完成。
• UP-TO-DATE：最新版本Pod的副本数量，用于指示在滚动升级的过程中，有多少个Pod副本已经成功升级。
• AVAILABLE：当前集群中可用的Pod副本数量，即集群中当前存活的Pod数量。
• AGE：Deployment创建时长

k8s4.png

从上图可以看到，Pod的命名以Deployment对应的Reploca Set的名字为前缀，这种命名很清晰的表明了一个Replica Set创建了哪些Pod，对于Pod滚动升级这样复杂的过程来说，很容易排错。

2.7、Horizontal Pod Autoscaler(HPA)

2.7.1、基本原理

​ HPA是Pod的横向自动扩容，与RS、Deployment一样，也是一种kubernetes资源对象。通过追踪分析RS控制的所有目标Pod的负载变化情况，来确定是否需要针对性的调整目标Pod的副本数。HPA不支持无法缩放的对象，比如DaemonSet。从v1.11版本开始，HPA默认已经不在从heapser获取资源指标，通常由metrics-server提供。

2.8、Service