【深入剖析K8s】第三章 核心设计与架构

容器实际上是由LinuxNamespace、LinuxCgroups和rootfS这3种技术构建出来的进程的隔离环境°
不难看出,＿个正在运行的Linux容器’其实可以被“＿分为二’’地看待:
（l）—组联合挂载在／var／lib／dockeⅣaufS／mnt上的rootfS’这＿部分称为容器镜像（container
image）,是容器的静态视图;
（2）＿个由Namespace＋Cgroups构成的隔离环境’这＿部分称为容器运行时（contajner
mntime）’是容器的动态视图。

核心设计与架构

Kubemetes项目要着重解决的问题，则来自Borg的研究人员在论文中提到的—个非常重要的观点:

• 在大规模集群中的各种任务之间运行’实际上存在各种各样的关系。这些关系的处理才是作业编排和管理系统最困难的地方。

控制节点即Master节点, 由3个紧密协作的独立组件组合而成.

• 分别是负责API服务的kube-apjserver
• 负责调度的kube-scheduler
• 负责容器编排的kube-controller-manager。
  整个集群的持久化数据,则由kube-aplserver处理后保存在etcd中

计算节点上最核心的部分是一个名为kubelet的组件。 在Kubemetes项目中’kubelet主要负责同容器运行时（比如Docker项目）交互。而这种交互所依赖的是—个称作CRl（container runtime interface）的远程调用接口, 该接口定义了容器运行时的各项核心操作,比如启动一个容器需要的所有参数。

kubelet的另—个重要功能,则是调用网络插件和存储插件为容器配置网络和持久化存储。这两个插件与kubelet进行交互的接口，分别是CNI（container networking interface）和CSI
（container storage interlace）。

核心能力与项目定位

Kubemetes项目最主要的设计思想就是,以统—的方式抽象底层基础设施能力（比如计算、存储、网络）,定义任务编排的各种关系（比如亲密关系｀访问关系｀代理关系）。
将这些抽象以声明式API的方式对外暴露,从而允许平台构建者基于这些抽象进—步构建自己的PaaS乃至任何上层平台。

可以看到,Kubemetes项目并没有像其他项目那样’为每—个管理功能创建—条指令,然后在项目中实现其中的逻辑.这种做法的确可以解决当前的问题,但是在更多的问题出现之后往往会力不从心。

我们推崇的使用方法是（声明式AP）：

• 首先通过一个任务编排对象’比如Pod、 Job、CronJob等描述你试图管理的应用
• 然后’为它定义—些运维能力对象,比如Service、Ingress、HorizomalPodAutoscaler（自动水平扩展器）等。这些对象会负责具体的运维能力侧功能。

声明式API是Kubemetes最核心的设计理念,正因为有了它’我们基于Kubemetes构建的上层平台才有了一致的编程范式和交互编程界面。