Kubernetes 架构原理

Kubernetes Cluster （集群）由【Master】和【Node】组成，节点上运行着若干 Kubernetes  服务。

【k8s 架构原理图】：

 

架构原理解析：

1.【Master 节点】

Master 是Kubernetes Cluster 的大脑，运行着的 Daemon 服务包括 kube-apiserver、 kube-scheduler 、 kube-controller-manager、etcd 和 Pod 网络（例如：flannel）;

1.1【API Server (kube-apiserver)】

API Server 提供 HTTP/HTTPS RESTful API, 即 Kubernetes AРI.。API Server  是 Kubernetes Cluster 的前端接口，各种客户端工具(CLI或UI)以及Kubermetes 其他组件可以通过它管理 Cluster 的各种资源。

1.2【Scheduler ( kube -scheduler )】

Scheduler 负责决定将 Pod 放在哪个Node 上运行。 Scheduler 在调度时会充分考虑 Cluster 的拓扑结构，当前各个节点的负载，以及应用对高可用、性能、数据亲和性的需求。

1.3【Controller Manager ( kube- controller- manager )】

Contoller Manager 负责管理 Cluster 各种资源，保证资源处于预期的状态。ContollerManager 由多种 controller 组成，包括replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。

不同的 contoller 管理不同的资源。例如：replication controller 管理Deployment 、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。

1.4【etcd】

etcd 负责保存 Kubernetes Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会快速地通知Kubernetes 相关组件。

1.5【Pod网络】

Pod 是 Kubernetes 调度的最小单元。一个Pod可以包含一个或多个容器，因此它可以被看作是内部容器的逻辑宿主机。Pod的设计理念是为了支持多个容器在一个Pod中共享网络和文件系统。因此处于一个Pod中的多个容器共享以下资源：

• PID命名空间：Pod中不同的应用程序可以看到其他应用程序的进程ID。
• network命名空间：Pod中多个容器处于同一个网络命名空间，因此能够访问的IP和端口范围都是相同的。也可以通过localhost相互访问。
• IPC命名空间：Pod中的多个容器共享Inner-process Communication命名空间，因此可以通过SystemV IPC或POSIX进行进程间通信。
• UTS命名空间：Pod中的多个容器共享同一个主机名。
• Volumes：Pod中各个容器可以共享在Pod中定义分存储卷（Volume）。

Pod要能够相互通信，Kubernetes Cluster必须部署Pod网络，flannel 是其中一个可选方案。

以上是【K8s-Master】上运行的组件，下面我们接着讨论【K8s-Node】。

 

2.【Node 节点】

Node 是 Pod 运行的地方，Kubernetes 支持 Docker、rkt 等容器 Runtime。Node 上运行的 Kubernetes 组件有 kubelet、kube-proxy 和 Pod 网络（例如：flannel）。

2.1【kubelet】

kubelet 是 Node 的 agent，当 Scheduler 确定在某个 Node 上运行 pod 后，会将 Pod 的具体配置信息（imager、volume 等）发送给该节点的 kubelet，然后 kubelet 根据这些信息创建和运行容器，并向 Master 报告运行状态。

2.2【kube-proxy】

service 在逻辑上代表了后端的多个 Pod, 外界通过 service 访问 Pod。 service 接收到的请求是如何转发到 Pod 的呢?这就是 kube-proxy 要完成的工作。

每个 Node 都会运行 kube-proxy 服务，它负责将访问 service 的 TCP/UPD 数据流转发到后端的容器。如果有多个副本，kube-proxy 会实现负载均衡。

2.3【Pod网络】

Pod 要能够相互通信，Kubernetes Cluster 必须部署 Pod 网络，flannel 是其中一个可选方案。

以上是【K8s-Node】上运行的组件。

 

3.【Etcd架构简介】

从etcd的架构图中我们可以看到，etcd主要分为四个部分：

• HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求；
• Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现；
• Raft：Raft 强一致性算法的具体实现，是etcd的核心；
• WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容；

通常情况，一个用户的请求发送过来，会经由【HTTP Server】转发给【Store】进行具体的事务处理，如果涉及到节点的修改，则交给【Raft】模块进行状态的变更、日志的记录，然后再同步给别的【etcd节点】以确认数据提交， 最后进行数据的提交，再次同步。

注：推荐在 k8s 集群中使用 Etcd v3.0 版本，v2 版本已经在 k8s v1.11 中弃用。

 

4.【k8s 其他组件】

 

【简单总结】

• k8s 官方组件：

1. API Server ：所有服务访问的统一入口（压力繁重）；
2. ControllerManage：维持Pod副本期望数目；
3. Scheduler：调度器，负责接收任务，选择合适的 Node 节点进行任务分配；
4. ETCD：C/S 结构体系的分布式KV存储系统（键值对数据库），存储 k8s 集群中所有重要信息（数据持久化，恢复数据即可恢复 k8s 集群）；
5. Kubelet：直接跟容器引擎交互，实现容器的生命周期管理；
6. Kube-proxy：负责写入规则致 IPTABLES、IPVS 实现服务映射访问；

• k8s 其他组件：

1. CoreDNS：可以为集群中的 SVC 创建一个域名 IP 的对应关系解析；
2. Dashboard：给 k8s 集群提供一个 B/S 结构访问体系；
3. Ingress Controller：k8s 官方默认只能实现四层代理，INGRESS 可以实现七层代理；
4. Federation：提供一个可以跨集群中心多 k8s 统一管理功能；
5. Prometheus：提供 k8s 集群监控能力；
6. ELK：提供 k8s 集群日志统一分析介入平台；

【ETCD参考】

• 【深入浅出etcd系列】1. 架构概览 =》https://zhuanlan.zhihu.com/p/73659512

• 【etcd：从应用场景到实现原理的全方位解读】=》https://www.infoq.cn/article/etcd-interpretation-application-scenario-implement-principle/

• 【ETCD原理】=》https://www.cnblogs.com/panpanwelcome/p/8242418.html

• 推荐书籍：【etcd 技术内幕】=》https://item.jd.com/43174660318.html