# Kubernetes架构
Kubernetes 集群主要包含两大角色。一个角色是 Master 节点。另一个角色是 Worker（Node） 节点。
在一个高可用的 Kubernetes 集群中，Master 和 Worker（Node）节点一般是由多节点构成的。这些节点可以是物理机或虚拟机。
Worker（Node）节点提供的资源单位是 Pod，可以将 Pod 理解为 Kubernetes 云平台提供的虚拟机。
Pod 是 Kubernetes 最基本的部署调度单元。⼀个 Pod 表示某个应⽤的⼀个实例。一般情况下，一个 Pod 里面只运行一个应用容器。但是，某些场景下，一个 Pod 里面可以运行多个应用容器。其中一个称为 主容器，其他的称为 辅助容器。
Kubernetes 主要解决集群的调度问题，当有应用发布请求过来的时候，Kubernetes 需要根据集群资源的空闲状况。将这个应用的 Pod 合理的分配到空闲的 Worker（Node） 节点上。同时 Kubernetes 还要时刻监控集群，如果有节点或者 Pod 挂了，需要重新协调和启动 Pods。保证应用的高可用性。这个技术也加自愈。另外，Kubernetes 还要管理集群的网络。保证 Pod 和服务之间的互联互通。
# Master 节点
Master 节点是 Kubernetes 集群的控制节点，负责整个集群资源的管理和控制。Master 节点上包含以下组件：
- Etcd
- kube-apiserver
- kube-controller-manager
- kube-scheduler
# Etcd
集中的状态存储，保存集群的整个状态，数据。比如：节点，Pods，配置，发布 等等都是保存在 Etcd 中。
Etcd 是一个分布式的 KV 数据库。它采用 Raft 分布式一致性算法。
高可用的 Etcd 集群部署，一般需要至少三个节点。
Etcd 集群可以独立部署，也可以和 Master 节点部署在一起。
# Api server
它是 Kubernetes 集群的 接口和 通讯总线。提供 HTTP REST 服务。并提供认证、授权、访问控制、API 注册和发现等机制；
用户通过 Kubctl，dashboard，sdk 等方式来操作 Kubernetes，背后都是通过 Api server 和集群进行交互的。
集群中的其他组件，比如 Kublet，kub-proxy，kube-controller-manager，kube-scheduler 等等。都是通过 Api server 才能和集群进行交互的。
可以将 Api server 认为是 Etcd 的一个代理。并且它是唯一可以直接访问和操作 Etcd 数据库的组件。其他组件都必须通过 Api server 才能间接访问和操作 Etcd 数据库。
Api server 不仅可以接受其他组件的API请求，它还是集群的 事件总线（EventBus）。其他的组件可以订阅在 Api server 上，当订阅的事件发生时，Api server 会将相关的事件通知到感兴趣的这些组件。
# Scheduler
它是 Kubernetes 集群负责 调度决策 的组件。
Scheduler 掌握当前集群的资源使用情况，当有的应用请求发布到 Kubernetes 集群时，Scheduler 会决策，相应的 Pods 应该被分布到哪些空闲的节点上去。
# Controller Manager
它是保证 Kubernetes 集群 状态最终一致 的组件。
负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
它通过 Api server 确保实际状态和期望状态是最终一致的。
Kubernetes 采用的是最终一致性策略。
如果一个应用，期望发布5个Pods，Controller Manager 会保证这个应用最终启动5个Pods。如果运行过程中有Pods挂了，它会协调重新启动Pods。如果Pods启动多了，它会协调关闭多余的Pods。它是集群自愈背后的实现机制。
# Worker（Node）节点
Node 节点是 Kubernetes 集群中的⼯作节点，它们是提供集群资源的。
Node 上的工作负载由 Master 节点分配，⼯作负载主要是运⾏容器应⽤。Node 节点上包含以下组件：
- Kubelet
- Container Runtime
- kube-proxy
# Kubelet
它是 Worker 节点的资源管理者。相当于一个Agent角色。
它维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；
它监听 Master 节点上 Api server 产生的事件，根据 Master 节点的指示，启动或关闭Pod等资源。同时也将本节点的状态数据汇报给 Master 节点。与 Master 节点协作，实现集群管理的基本功能。
# Container Runtime
它是 Worker 节点 容器资源 的直接管理者。
如果采用 Docker 容器，那么它就是 Docker 引擎。
Kubelet 不会直接管理节点的容器资源，而是委托给 Container Runtime 进行管理。比如启动，关闭容器，收集容器状态等等。
Container Runtime 在启动容器时，如果本地没有相应的镜像缓存，则会从 Dokcer Registry 或 Docker Hub 上去拉取相应的镜像，然后缓存在本地。
# kube-proxy
它是管理 Kubernetes 集群中的 服务 Service 的组件。负责为 Service 提供 cluster 内部的服务发现和负载均衡。
Pod 是 Kubernetes 集群中一个不固定的概念，Pod的PodIP属性会随着发布，更新而变化。同时Pod的PodIP属性由于非预期的挂了，而重新调度，也会变化。
为了屏蔽PodIP的变换，Kubernetes 中引入了 Service 这个概念。它可以屏蔽应用PodIP的变换，并且可以在调用的时候进行负载均衡。
kube-proxy 就是实现 Kubernetes 集群中的 服务 Service 背后的机制。
另外，当需要把 Kubernetes 集群中的服务暴露给外网时，也是通过 kube-proxy 进行代理转发的。
# 组件通信
Kubernetes 多组件之间的通信原理为
- API Server 负责 etcd 存储的所有操作，且只有 API Server 才直接操作 etcd 集群
- API Server 对内（集群中的其他组件）和对外（用户）提供统一的 REST API，其他组件均通过 API Server 进行通信
- Controller Manager、Scheduler、Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况，并对资源作相应的操作
- 所有需要更新资源状态的操作均通过 API Server 的 REST API 进行
- API Server 也会直接调用 Kubelet API（如 logs, exec, attach 等），默认不校验 Kubelet 证书，但可以通过 --kubelet-certificate-authority 开启（而 GKE 通过 SSH 隧道保护它们之间的通信）
比如典型的创建 Pod 的流程为
- 用户通过 REST API 创建一个 Pod
- API Server 将其写入 etcd
- Controller Manager 会通过 API Server watch API监测资源变化情况，然后它会比较当前的集群状态和期望的集群状态。它发现不一致，所以创建新的Pods。
- Scheduluer 检测到未绑定 Node 的 Pod，开始调度并更新 Pod 的 Node 绑定
- Kubelet 检测到有新的 Pod 调度过来，通过 Container Runtime 运行该 Pod
- Kubelet 通过 Container Runtime 取到 Pod 状态，并更新到 API Server 中
# 总结
| 组件 | 节点 | 作用 |
|---|---|---|
| Etcd | Master or 独立的集群 | 集群状态的集中管理 |
| API Server | Master | 集群接口和通信总线 |
| Scheduler | Master | 调度决策组件（决定将Pod发布到哪些空闲节点） |
| Controller Manager | Master | 协调发布状态最终一致性组件 |
| Kubelet | Worker | Worker节点资源管理 |
| Container Runtime | Worker | 容器资源管理 |
| Kube-Proxy | Worker | 实现服务（Service）抽象组件，屏蔽PodIP变化和负载均衡 |
| Pod | Worker | 可以理解为K8s云平台提供的虚拟机，K8s基本调度单位 |
| Container | Worker | 应用运行在容器中，资源隔离的单位 |