K8S—理论知识

一、概述

全称： Kubernetes

1.1 作用

负责自动化运维管理多个容器化的程序的集群，也是一个容器编排工具
主要和docker搭配

1.2 搭配docker使用

可以完美解决docker的以下几个弱点

• 单机使用，无法有效集群
• 容器数量上升，管理成本上升
• 没有有效的容灾，自愈机制
• 没有编排模板，无法实现快速，大规模容器调度
• 没有统一配置管理中心工具
• 没有容器生命周期管理工具
• 没有图形化管理工具

总而言之，K8S提供了了容器编排、资源调度、弹性伸缩、部署管理和服务发现等等功能

1.3 特性

弹性伸缩

使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务

自我修复

在节点故障时重新启动失败的容器，替换和重新部署；杀死失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断

服务发现和负载均衡

K8s为多个容器提供一个统一访问入口(内部IP地址和一个DNS名称)，并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题

自动发布(默认滚动发布模式)和回滚

K8S采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务

集中化配置管理和密钥管理

管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用

存储编排，支持外挂存储并对外挂存储资源进行编排

挂载外部存储系统，无论是来自本地存储，公有云，还是网络存储都作为集群资源的一部分使用，极大提高存储使用灵活性

任务批处理运行

提供一次性任务，定时任务，满足批量数据处理和分析的场景

二、K8S架构

K8S属于主从设备模型，如图所示master节点负责集群的调度、管理和运维，slave节点负责集群的运算工作负载

master组件可以在集群中的任何计算机上运行，不过一般建议单独用一台独立的服务器，因为master是整个集群的大脑，如果master宕机了，那么所有的控制命令就会失效

某个节点宕机时，master会把工作负载转移到其他节点

2.1 master 组件

API server

任何的资源请求或者调用操作都是通过 API 提供的接口进行，所有对象的增删改查和监听操作也都是API处理后交给etcd存储

API就是k8s的请求入口服务，负责接收所有请求，然后再根据用户的需求通知其他组件干活

controller manager

运行管理控制器：k8s中处理常规任务的后台线程，所有资源对象的自动化控制中心

在k8s中，一个资源对应一个控制器，controller manager 就是负责管理这些控制器的

通过API监控状态，如果某个node宕机，controller manager会执行自动化修复流程，确保整个集群都是正常的工作状态

主要有一下几个控制器

• Node Controller (节点控制器) :负责在节点出现故障时发现和响应
• Replication Controller (副本控制器) :负责保证集群中一个RC (资源对象Replication Controller) 所关联的Pod副本数始终保持预设值。可以理解成确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量
• Endpoints Controller (端点控制器) :填充端点对象(即连接Services 和Pods) ，负责监听Service 和对应的Pod副本的变化。可以理解端点是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道它的endpoint
• Service Account & Token Controllers (服务帐户和令牌控制器) :为新的命名空间创建默认帐户和API 访问令牌
• ResourceQuotaController(资源配额控制器):确保指定的资源对象在任何时候都不会超量占用系统物理资源
• Namespace Controller (命名空间控制器) :管理namespace 的生命周期
• Service Controller (服务控制器) :属于K8S 集群与外部的云平台之间的一个接口控制器

scheduler

负责资源调度的进程，根据调度算法为新的pod选择一个合适的node节点

也就是说这个组件是所有node节点的调度器，当用户要部署服务时，scheduler根据调度算法选择合适的节点来部署pod

2.2 配置存储中心

ETCD

分布式键值存储系统，存储了k8s的关键配置和用户配置

k8s里只有API有读写权限，其他组件想要读取ETCD必须通过API才可以

2.3 Node 组件

Kubelet

Node节点的监视器，以及与master节点的通讯器，定时向API回报自己这边node节点的状态

从master节点上获取自己这边pod的期望状态，如果不一样，就调用对应的容器平台接口到这个状态

管理镜像和容器的清理工作，保证节点不会被占满空间，退出的容器又不会占用太多资源

总结：kubelet负责node节点大大小小的一切事务，也是和API组件相互通讯的一个重要部分

proxy

在每个node节点上实现pod网络代理，负责维护网络规则和四层负载均衡工作

proxy本身不提供网络，pod的网络其实是kubelet提供的，proxy实际上只是维护虚拟的pod集群网络

API通过监控proxy来进行对k8s的更新和端点的维护

proxy是k8s的负载均衡器，也是一个分布式代理服务器，在每个节点上都会有proxy组件

三、核心概念

k8s有着多种类型的资源对象：
pod、label、service、replication、contreller 等等
所有的资源对象都可以通过k8s里的 kubectl 来进行增删改查，并保存在 etcd 中持久化存储

k8s是一个高度自动化的资源控制系统，通过对比etcd里保存的资源期望状态和当前环境的差异来实现自动纠错、控制等高级功能

3.1 pod

pod 是k8s创建的最小基本单位，一个pod代表集群上正在运行的一个进程

• 一个pod有一个或多个容器组成，pod内容器共享网络、存储等资源
• 一个pod运行多个容器叫做边车模式，在生成环境中一般都是单个容器或者有着强关联互补的多个容器组成一个pod
• 同一个pod之间的容器可以通过localhost互相访问，并且挂载pod内所有的数据卷，但是不同的pod之间的容器不能用localhost访问，也不能挂载

3.2 pod控制器

Pod控制器是Pod启动的一种模版，用来保证在K8S里启动的Pod 应始终按照用户的预期运行(副本数、生命周期、健康状态检查等)

K8S内提供了众多的Pod控制器，有以下几种:

Deployment：无状态应用部署
Deployment 的作用是管理和控制Pod 和ReplicaSet， 管控它们运行在用户期望的状态中

Replicaset：确保预期的Pod 副本数量
ReplicaSet 的作用就是管理和控制Pod，管控他们好好干活。但是，ReplicaSet 受控于Deployment

也就是说deployment是老大，监督pod干活的
如果有pod出现问题，就会重新找个新pod顶替，replicaset就是负责这个
资源对象Replication Controller 是ReplicaSet 的前身，官方推荐用Deployment 取代Replication Controller 来部署服务

Daemonset：确保所有节点运行同一类Pod, 保证每个节点上都有一个此类Pod 运行，通常用于实现系统级后台任务

Statefulset ：有状态应用部署

Job：一次性任务
根据用户的设置，Job 管理的Pod把任务成功完成就自动退出了

cronjob：周期性计划性任务

3.3 label

标签

k8s的特色管理方式，用于分类管理资源对象

label可以附加到各种资源对象上，用于关联对象、查询和筛选

一个资源对象可以定义多个label，同一个label也可以被添加到多个资源对象

可以通过给指定资源对象绑定一个或多个不同的label来实现多维度的资源分组管理功能

3.4 label 选择器

给某个资源对象定义一个label，相当于给他打了个标签，然后就通过这个选择器来查询筛选有label的资源对象

标签选择器有两种：基于等值关系和基于集合关系

3.5 service

虽然每个Pod会被分配一个单独的IP地址，但由于Pod是有生命周期的(它们可以被创建，而且销毁之后不会再启动)，随时可能会因为业务的变更，导致这个IP地址也会随着Pod 的销毁而消失

Service就是用来解决这个问题的核心概念

K8S中的service像是网关层，可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器

Service作用于哪些Pod是通过标签选择器来定义的

每个Service都有一个固定的虚拟ip (这个ip也被称为Cluster IP) ，自动并且动态地绑定后端的Pod, 所有的网络请求直接访问Service 的虚拟ip，Service会自动向后端做转发

Service除了提供稳定的对外访问方式之外，还能起到负载均衡(Load Balance) 的功能，自动把请求流量分布到后端所有的服务.上，Service可以做到对客户透明地进行水平扩展(scale)

而实现service 这一功能的关键，就是kube-proxy。 kube-proxy 运行在每个节点上，监听API Server中服务对象的变化，可通过以 下三种流量调度模式: userspace (废弃)、iptables (濒临废弃) 、ipvs (推荐，性能最好)来实现网络的转发

Service是K8S 服务的核心，屏蔽了服务细节，统一对外暴露服务接口

优势非常明显:一方面外部用户不需要感知因为Pod上服务的意外崩溃、K8S 重新拉起Pod 而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化

3.6 ingress

service主要负责k8s集群的网络拓扑，访问集群内部就要靠ingress了，作为k8s集群的接入层，也负责集群内外通讯

ingress是七层应用，访问方式 http/https

service是四层流量调度

比如客户端请求一个网址 → ingress → service → pod 这样一个顺序

3.7 name

k8s内部使用资源定义每一种逻辑概念，但是这些资源也有自己的名称

资源有 api版本（apiversion）、类别（kind）、元数据（metadata）、定义清单（spec）、状态（status）等信息

名称就是定义在资源的元数据信息里，并且在同一个空间内是唯一的

3.8 namespace

随着项目增多，人员增多，集群扩大，需要一个逻辑上隔离k8s内部各种资源的方法，就是namespace

namespace是为了把k8s集群划分成若干个资源不共享的虚拟集群组

不同的namespace内资源名称可以一样，但是同空间内资源和名称不能一样

k8s默认的namespace有：default、kube-system、kube-public等等

四、总结

k8s集群分为两个节点，master节点和node节点

master节点里有API、Controller-manager、Scheduler、etcd组件
node节点有kubelet、proxy、pod组件

集群的框架概述

API组件接收到请求后创建一批 Pod ，API会让 Controller-manager 按照所预设的模板去创建 Pod，Controller-manager 会通过 API 去找 Scheduler 为新创建的 Pod 选择最适合的 Node 节点

比如运行这个 Pod 需要 2C4G 的资源，Scheduler 会通过预算策略在所有 Node 节点中挑选最优的。

Node 节点中还剩多少资源是通过汇报给 API Server 存储在 etcd 里，API Server 会调用一个方法找到 etcd 里所有 Node 节点的剩余资源，再对比 Pod 所需要的资源，在所有 Node 节点中查找哪些 Node 节点符合要求

如果都符合，预算策略就交给优选策略处理，优选策略再通过 CPU 的负载、内存的剩余量等因素选择最合适的 Node 节点，并把 Pod 调度到这个 Node 节点上运行。