# Kubernetes架构

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 注册和发现等机制;

用户通过 Kubctldashboardsdk 等方式来操作 Kubernetes,背后都是通过 Api server 和集群进行交互的。

集群中的其他组件,比如 Kubletkub-proxykube-controller-managerkube-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 RegistryDocker 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 的流程为

Kubernetes 组件通信

  • 用户通过 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 应用运行在容器中,资源隔离的单位

# 参考

更新时间: 8/17/2020, 3:11:33 PM