Kubernetes in action-机理
Kubernetes机理
- 1、整体架构
- 1.1 了解etcd
- 1.2 了解API服务器
- 1.3 了解调度器
- 1.4 了解控制器管理器中运行的控制器
- 1.5 了解Kubelet
- 1.6 了解Kube-proxy
- 2、整体时间链
如有侵权，请联系～
如有错误，也欢迎批评指正～
本篇文章大部分是来自学习《Kubernetes in action》的笔记
1、整体架构
k8s主要分为两部分：控制平面组件和工作节点。
控制平面组件主要有：
| 组件 | 作用 |
|---|---|
| kube-apiserver(API服务器) | 提供 REST API 接口，是整个集群的核心接口服务；所有操作都通过它进行 |
| kube-scheduler(调度器) | 负责将新创建的 Pod 分配到某个可用的工作节点上 |
| kube-controller-manager(控制器管理器) | 运行控制器（Controller），如 Node Controller、Replication Controller、Endpoint Controller 等，确保集群状态符合期望 |
| cloud-controller-manager（可选） | 处理云平台特定的功能，如负载均衡、存储等 |
| etcd | 分布式键值数据库，保存整个集群的状态信息 |
工作节点组件主要有：
| 组件 | 作用 |
|---|---|
| kubelet | 在每个节点上运行，负责管理 Pod 生命周期、与 kube-apiserver 通信 |
| kube-proxy | 实现 Kubernetes 的网络规则，维护本机的 iptables 或 IPVS 规则，实现 Service 的负载均衡和网络代理 |
| container runtime | 容器运行时，负责运行容器，常见有 Docker、containerd、CRI-O 等 |
| CoreDNS / kube-dns | 提供 DNS 解析服务，用于解析 Pod、Service 的名称为 IP 地址 |
组件之间通信完全通过API服务器进行通信，他们之间不会互相通信，API服务器也是与etcd通信的唯一组件。
为了保证可用性，每个组件都会有多个实例，例如etcd、API服务器同时会有多个实例进行并行运行，但是管理器控制器和调度器同一时间只有一个实例运行，其他实例处于待命状态。
1.1 了解etcd
etcd主要是保存整个集群的状态信息，创建的所有对象例如pod、replicationController等manifest都会保存到etcd上，这样重启才不会丢失。
etcd V2是把key存储到一个层级键空间中，类似于文件系统，etcd V3不支持目录形式，都是键值对存储，但是key可以有/。所有的数据都是存储到/registry下。
1.2 了解API服务器
API服务器作为中心组件，其他组件或者客户端 (如kubectl)都会去调用它。以RESTfulAPI的形式提供了可以查询、修改集群状态的CRUD(Create、Read、Update、Delete)接口。 它将状态存储到etcd中。
客户端在调用API服务器的时候，会经过一系列的认证、授权、准入校验。
API服务器除了负责将数据存储到etcd中，还有就是启动控制器和一些组件来监控已经部署的资源变更。
1.3 了解调度器
宏观来看，调度器就是指定pod去哪个工作节点上运行，调度器会利用API服务的监听功能监听新创建的pod，然后给每个新创建的、还没有分配工作节点的pod分配工作节点。
如果调度器根据调度算法得到该pod指定的工作节点，调度器不会直接与工作节点或者工作节点上的kubelet通信去运行pod，而是通知API服务器更新pod定义。kubelet会利用API服务器的监听机制监听到pod变化并且被分配到该目标节点，则这个目标节点的kubelet就会创建和运行容器。
默认调度算法：
找出可用的节点 -> 对可用的节点进行优先级排序
1.4 了解控制器管理器中运行的控制器
控制器主要是执行一个调和循环，将真实的状态调整为期望的状态。也是基于API服务器的监听机制。
Replication管理器：
Replication管理器检查符合pod标签的pod数量是否和期望的一致。Replication管理器并不是时时刻刻扫描所有的pod，也是根据API服务器的监控，会监听replication controller资源和pod资源，一旦replication controller资源和pod资源发生变更，Replication管理器就会检查符合pod标签的pod数量是否和期望的一致，如果少了，就会想API服务器发送pod清单，让调度器和kubelet来做调度任务。
ReplicaSet、DaemonSet、Job控制器和Replication管理器工作几乎一样。
Deployment控制器：
Deployment控制器负责使 deployment的实际状态与对应 DeploymentAPI对象的期望状态同步 。
每次 Deployment 对象修改后(如果修改会影响到部署的 pod), Deployment 控制器都会滚动升级到新的版本。通过创建一个ReplicaSet，然后按照 Deployment中定义的策略同时伸缩新、旧RelicaSet， 直到旧 pod 被新的代替。并不会直接创建任何pod。
Node控制器：
Node控制器管理Node资源，使节点对象列表与实际运行的机器保持一致，他会监控每个节点的健康情况，删除不可大的节点。
除了上述的控制器管理器，还有Service控制器、EndPoint控制器【service会把请求转发到endpoint资源上，这个保存了机器的IP和port】、NameSpace控制器、PersistentVolume控制器【为持久卷声明查找最合适的持久卷】、唤醒控制器等等。
1.5 了解Kubelet
Kubelet就是负责所有运行在工作节点上内容的组件。在API服务器中创建一个Node资源来注册该节点。 然后需要持续监控API服务器是否把该节点分配给 pod，然后启动 pod 容器。Kubelet 也是运行容器存活探针的组件，当探针报错时它会重启容器。
1.6 了解Kube-proxy
kube-proxy的目的就是将客户端的请求负载均衡的转发到相应的pod上。 kube-proxy 的两种核心实现方式：iptables模式和 ipvs模式。
2、整体时间链
这个是以Deployment资源提交为例子：
- Deployment控制器监听到有新的Deployment资源，Deployment控制器会按照Deployment定义创建一个新的ReplicaSet对象。
- ReplicaSet控制器监听到ReplicaSet资源，就会按照ReplicaSet资源要求的创建新的pod资源
- 新建的pod资源会保存到etcd中，调度器收到新的pod通知，就会为pod分配合适的工作节点。
- 当调度器为pod分配好了工作节点之后，API服务器就会通知相应的节点上的kubelet，然后kubelet会检查pod的定义，并启动docker容器。
这些注册通知都是通过事件event资源来实现的，将事件发送给API服务器。