Kubernetes 架构

前言

作为云原生时代的当红人物，一直想精读一下 k8s 的源码，本篇文章会从其架构，源码来深入剖析 k8s 的设计思路。

K8S组件与职责

我们可以看到K8S主要是由，API server、Cloud controller manage（可选）、Controller manager、etcd、kubelet、kube-proxy、Scheduler。可以分为Control Plane组件、和Node组件两个大类，Control Plane组件一般在单独的机器上，也就是说生产环境不会把业务Pod和它们放一起，Node组件每台运行Pod的机器都要有的，一方面是维持Pod正常运行，还有就是提供K8S运行时环境。

Control Plane 组件

• Kube-APIserver：k8S暴露出来给用户使用API的组件，其它各组件之间的交互都是要经过它的。所以考虑到高频地调用，它是可以部署多个来负载的

• etcd：一个高性能的键值数据库，K8S的持久化数据都放在这里

• kube-scheduler： 持续监听有没有未分配节点的Pod，并根据各种条件（节点情况、Pod配置亲和性）等给它分配一个节点

• kube-controller-manager：正常来说每个控制器都是一个单独的进程，不过K8S为了降低复杂性就把它们把包成一个二进制文件并运行在一个进程中，其中比较常见的控制器有

  • Node controller： 负责监听Node是否正常
  • Job controller： 负责监听K8S的一次性运行的Job，并创建Pod去跑Job
  • EndpointSlice controller：负责EndpointSlice的创建，EndpointSlice 可以理解是 Service和Endpoint之间的一个映射关系
  • ServiceAccount controller：为新的Namespace创建默认的 ServiceAccounts

Node 组件

上边有提到，Node组件是每个节点都会运行的

• kubelet： 它负责确保Pod中的容器正常运行，并确保按照PodSpecs（比如ServiceAccount，Pod调试策略，标签）等条件运行的。
• kube-proxy： 是Node中的网络代理，pod与pod间的通信要经由它，实现了k8s service 概念的部分功能
• Container runtime： 容器器运行时就如它的名字一样，负责运行容器的。常见的容器运行时除了我们熟知的 docker还有containerd，CRI-O等。