Kubernetes（K8s）_09_Kubernetes架构

Kubernetes架构

Kubernetes架构：去中心化架构，由多个组件构成

1）Kubernetes架构主要由控制平面组件和Node节点组件构成；

2）基于声明性模型运行并实现（不会线性处理任务）；

3）Kubernetes架构也由部分附加组件构成；

//如：Kubernetes DNS服务器、Ingress控制器、Heapster和容器网络接口插件等

//控制平面组件和Node节点组件中均包含容器引擎组件（如：Docker和rkt等）

如：控制平面组件和Node节点组件构成Kubernetes

1）组件均为单独进程运行，且均作为Pod来运行（Kubelet除外）；

2）组件间只能通过API Server通信（不可直接通信）；

3）API Server和组件间的连接大部分是由组件发起的；

控制平面组件

控制平面组件为以下4种（运行在Master节点）：

组件名	说明
API Server （API服务器）	管理Kubernetes集群的入口
Ectd （分布式持久化存储）	存储Kubernets集群的核心数据
Scheduler （调度器）	调度Pod与各个节点进行绑定
Controller （控制器）	保证各个资源对象达到期望状态

1）Master节点上的组件可部署在多台服务器上，且每个组件可有多个；

2）多个Etcd和API Server可同时并行工作；

3）多个Scheduler和Contoler中只有一个在工作，其他处于待命模式；

如：三Master节点的高可用集群

1）通过负载均衡器确保只会连接到健康状态的API Server

2）API Server是无状态的，可同时运行多个；

API Server

API Server：各个组件的通信渠道

1）以RESTful API的形式提供针对集群状态的CURD，并将其存入Etcd；

1）各个组件均通过API Server进行交流，而数据的来源是Etcd；

2）API Server暴露ComponentStatus的API资源；

//显示控制平面组件的状态命令：kubectl get componentstatuses

如：通过JSON文件创建资源的流程

1）API Server需认证发送请求的用户（API Server中一个或多个认证插件完成）

//API Server在有限时间内会轮流调用认证插件，确定该请求的发送者

2）API Server判断认证后的用户是否可资源执行操作

//由API Server中一个或多个认证插件完成

准入控制插件：验证创建、修改和删资源的请求

1）准入控制插件可修改资源信息；

//如：初始化资源定义中漏配的字段，准入控制插件会填写默认值（也可重写）

2）准入控制插件主要为以下4种：

准入控制插件名	说明
AlwaysPullImages	强制每次部署Pod时需拉取镜像 （重写Pod的imagePullPolicy为Always）
ServiceAccount	未明确定义服务账户的使用的默认账户
NamespaceLifecycle	防止在命名空间中创建正在被删除的资源 （或在不存在的命名空间中创建资源）
ResourceQuota	确保指定命名空间中的Pod 只能使用该命名空间已分配的资源
DefaulTolerationSeconds	检测Pod是否设置污点宽容期 若无，则为其设置默认宽容期

3）请求需通过所有的准入控制插件的验证才可被执行；

4）当请求通过验证后API Server会将该请求存储到Etcd，并返回响应；

API Server接受到资源变更的请求时，会执行以下流程：

1）启动Scheduler和Controller或其他组件，去监控已部署的资源变更；

2）组件根据集群元数据的变化执行对应操作；

//kubectl工具也可监听资源变更

如：API Server接受资源变更请求的流程

Etcd

Etcd：高可用的分布式持久存储的键值（Key-Value）数据库

1）各个组件通过API Server间接地读取/写入数据到Etcd；

2）Kubernetes中仅由Etcd存储集群状态和元数据；

Kubernetes的数据存储于Etcd的/registry

1）所有的资源类型均代表一个子目录；

2）资源类型子目录下存储各个命名空间下对应类型的资源；

3）资源中存储对应资源的JSON定义格式；

//API Server将资源的完整JSON形式存储在Etcd中

多个Ectd通过RAFT一致性算法保持一致

1）RAFT算法要求集群大部分节点参与才能修改状态（少数服从多数）；

2）Etcd通常部署为奇数个（建议5或7个节点，避免脑裂和过度选举）；

3）每个连接到Etcd集群的API Server会得到当前Etcd状态（或之前的状态）；

Scheduler

Scheduler（调度器）：调度Pod到指定Node节点上运行

1）Scheduler通过预测函数检测Node节点是否可用于分配；

2）Scheduler再通过调度算法决定Pod如何分配给各个Node节点；

Scheduler调度Pod的流程：

1）Scheduler通过API Server更新Pod的定义；

2）API Server通过Node节点的Kubelet（该Pod已被调度）；

3）目标节点的Kubelet发现Pod被调度到本节点，则会创建并运行Pod的容器；

如：Scheduler调度Pod的流程

默认调度算法：

1）过滤所有Node节点，得出可用于调度Pod的可用节点列表；

2）对可用节点列表进行排序，找出最优节点；

//若多个节点均为最优，则循环分配

预测函数需检测以下要求：

1）Node节点是否能满足Pod对系统资源的需求；

2）Node节点的标签是否符合Pod的节点选择器；

3）Pod需绑定指定的主机端口在Node节点是否已被占用；

5）Node节点是否能满足Pod定义中要求的卷；

4）Pod是否能够容忍Node节点的污点；

//Node节点需满足以上所有要求，才可被记为可用节点

Kubernetes集群中运行多个Scheduler

1）Pod定义中通过schedulerName字段，可指定Scheduler来调度该Pod；

2）未指定的则由默认Scheduler调度（schedulerNamer被设置为default-scheduler）；

Controller

Controller（控制器）：确保集群的真实状态往API Server定义的期望状态收敛

1）Controller实现具体的资源部署（活跃的Kubernetes组件）；

2）Controller之间不会直接通信，且每个Controller均连接到API Server；

3）每个Controller均有一个构造器，内部会创建一个Informer（监听器）；

4）所有的Controller均通过API Server操控对于的API对象；

Controller工作流程：

1）Controller均通过API Server监听资源的变更；

2）对比当前指定资源的当前状态和期望状态；

3）若不满足期望状态，则执行对应的操作；

//资源的期望状态记录在资源的spec字段，实际状态记录在status字段

如：提交Deployment清单至API Server后所发生的事件链

Controller分为以下8种：

（1）Replication Controller

1）通过监听机制监听可能影响期望复制集数量或对应Pod数量的变更事件；

2）监听到对应事件后，会重新检查是否达到期望状态以及实际的复制集数量；

3）若没达到要求，则执行对应的操作；

//Replicaset、DaemonSet和Job同理

如：Replication Controller监听资源对象变更

1）Replication Controller会运行额外的实例，但不会运行Pod；

2）Replication Controller通过创建Pod清单，并发送到API Server；

3）再通过Scheduler和Kubelet实现Pod的创建和运行；

（2）Deployment Controller

1）Deployment被修改后，Deplyment控制器都会滚动升级到新版本；

2）通过Deployment定义策略同时扩缩容新、旧RelicaSet（旧Pod被完全代替）

//不会直接创建任何Pod

（3）StatefulSet Controller

1）初始化并管理每个Pod对象的持久卷声明字段；

//其他Controller只管理Pod

（4）Node Controller

1）确保节点对象列表和集群中实际运行的机器列表保持同步；

2）监控每个节点的健康状态，并删除不可达节点的Pod；

（5）Service Controller

1）LoadBalancer类型服务被创建/删除时，从基础设施请求、释放负载均衡器；

（6）Endpoint Controller

1）同时监听Service和其对应的Pod；

如：Replication Controller监听资源对象变更

1）当监听到Service或Pod被添加、修改或删除时，Controller会选择匹配Service的Pod选择器的Pod，将其IP和端口添加到Endpoint资源中；

//删除Service时，对应的Endpoint也会随之被删除

（7）Namespace Controller

1）当删除Namespace时，Controller实现删除该Namespace下的所有资源；

（8）PersistentVolume Controller

1）Controller会为PVC查找最佳匹配项（声明容量大于需求容量的最小PV）；

2）原理：保存一份有序的PV列表，对于每种访问模式按照容量升序排列，返回列表的第一个卷；

Node节点组件

Node节点组件为以下4种（运行在Node节点）：

组件名	说明
Kubelet	负责Master节点下发到该节点的具体任务 并定时向API Server汇报该节点信息
kube-proxy （Kubelet代理服务）	Node节点中Pod的代理

1）Node节点上的组件需均在同一个节点上运行

Kubelet

Kubelet：负责Master节点下发到该节点的具体任务

1）同时会管理该节点上的Pod和容器，并定时向API Server汇报节点信息；

2）Kubelet一般会从API Server获取Pod清单

3）Kubelet也可基于本地目录下的Pod清单创建/运行Pod

//本地的Pod清单一般用于将控制平面组件以Pod形式运行

如：Kubelet基于API Server和本地文件Pod清单创建Pod

//Kubelet也是运行容器存活探针的组件

Kubelet工作概括：

1）在API Server中创建一个Node资源以注册该节点；

2）持续监控API Server是否分配Pod给该节点（若分配，则创建并运行Pod）；

3）通知容器引擎通过指定的容器镜像运行容器；

4）持续监控运行的容器，并向API Server报告其状态、事件和资源消耗；

//当Pod从API Server中删除时，Kubelet会终止容器并告知API Server已终止

kube-proxy

kube-proxy：确保用户的可通过Kubernetes API连接到指定服务

1）本质：将对Service的IP和端口访问转发至后台的特定Pod；

代理模式分为：userspace代理、iptables代理（默认）

（1）userspace代理：通过实际服务器集成接收连接，同时代理给Pod

1）数据包需传递过kube-proxy，且在用户空间处理（对性能影响较大）；

2）以轮询模式对连接做负载均衡；

（2）iptables代理：通过iptables规则重定向数据包到一个随机选择的后端Pod

1）数据包不经过kube-proxy，且数据包只会在内核空间处理（性能更好）；

2）以随机选择后端Pod对连接做负载均衡；

iptables代理流程：

1）当API Server创建新Service时，会为其分配一个虚拟IP；

2）API Server通知所有Node节点上的kube-proxy，已有一个新Serivce建立；

3）每个kube-proxy会使该Service在其节点变得可寻址（建立iptables规则）；

//确保每个目的地为Service的IP和端口对的数据包可被解析

如：iptables代理的流程

附加组件

附加组件：Kubernetes集群中非核心组件，但可加强集群功能的组件

1）附加组件部署方式：提交YAML清单文件至API Server（以Pod方式部署）；

常见附加组件：

（1）DNS

1）以Pod形式部署在集群中，且附属于kube-dns服务；

2）Kubernetes集群中所有Pod默认使用集群内部的DNS服务器；

//实现Pod可通过名称查询Service（甚至是无头Service下Pod的IP）

3）kube-dns通过API Server监控机制监听Service和Endpoint的变更；

（2）Ingress Controller

1）Ingress Controller需运行一个反向代理服务器（如：Nginx）；

2）Ingress Controller通过API Server监控机制监听Service和Endpoint的变更；

3）Ingress Controller会直接将流量转发到Service的Pod（略过Service的IP）；

4）当外部客户端通过Ingress Controller连接时，会记录该客户端的IP；

Pod网络

Pod网络：确保Kubernetes集群中的Pod可相互通信

1）由系统管理员或CNI（Container Network Interface）插件建立

2）集群中每个Pod都拥有一个具有唯一性的IP

3）当Pod向外部发送数据包时，其源IP会被改成其Node节点的IP

如：Pod内的容器相互通信过程

//Kubernetes集群中Pod必须通过非NAT网络进行连接，Pod到节点或节点到Pod之间也不可使用NAT通信

Pod通信

基础容器：存储集群中所有的网络和命名空间

1）功能：其他容器重启后，仍处于与之前相同的网络和Linux命名空间中；

2）Pod中不论运行多少容器，都会运行一个基础容器；

3）基础容器的生命周期和Pod向绑定；

//基础容器在Pod运行期间被关闭，Kubelet会自动重建以及Pod内的其他容器

Pod通信分为：同节点Pod通信、不同节点Pod通信

（1）同节点Pod通信：基于evth-pair技术（虚拟Ethernet接口对）

1）Pod创建容器时会为每个容器创建虚拟Ethernet接口对；

2）同一节点上的所有Pod都会连接到同一个网桥；

虚拟Ethernet接口对：由连接至两端的两块虚拟网卡构成

1）veth为前缀的虚拟网卡保存至节点的命名空间中；

2）eth0命名的虚拟网卡保存至容器中（eth0的IP从网络地址段中获取）；

//容器内部的程序默认发送数据到eth0虚拟网卡；

如：同一Node节点的Pod通过evth-pair技术通信

（2）不同节点Pod通信：通过连接不同节点的网桥

1）连接网桥的方式分为：overlay、underlay、三层路由

2）不同节点的网络必须使用非重叠的地址段（防止Pod的IP重复）；

如：通过三层路由连接网桥实现不同节点的Pod通信