Kubernetes 架构原理

Kubernetes Cluster (集群)由【Master】和【Node】组成,节点上运行着若干 Kubernetes  服务。

【k8s 架构原理图】

Kubernetes 架构原理_第1张图片

 

架构原理解析:

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架构简介】

Kubernetes 架构原理_第2张图片

从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 其他组件】

Kubernetes 架构原理_第3张图片

 

【简单总结】

  • 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

Kubernetes 架构原理_第4张图片

你可能感兴趣的:(k8s)