深入剖析Kubernetes系列连载(七) Kubernetes要解决的问题是什么?编排 >> 调度

Kubernetes的学习往往让人摸不着头脑,很难理解其中的原理。

深入剖析Kubernetes系列连载是学习《深入剖析Kubernetes》课程的笔记和总结,记录学习的过程,并且传递知识。

对于大多数用户来说,他们希望 Kubernetes 项目带来的体验是确定的:现在我有了应用的容器镜像,请帮我在一个给定的集群上把这个应用运行起来。

更进一步地说,我还希望 Kubernetes 能给我提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。

这些功能听起来好像有些耳熟?这不就是经典 PaaS(比如,Cloud Foundry)项目的能力吗?

而且有了 Docker 之后,我根本不需要什么KubernetesPaaS,只要使用 Docker 公司的 Compose+Swarm 项目,就完全可以很方便地 DIY 出这些功能了!

所以说,如果 Kubernetes 项目只是停留在拉取用户镜像、运行容器,以及提供常见的运维功能的话,那么别说跟“原生”的Docker Swarm 项目竞争了,哪怕跟经典的 PaaS 项目相比也难有什么优势可言

其中,控制节点,即 Master 节点,由三个紧密协作的独立组件组合而成,它们分别是负责API 服务的 kube-apiserver、负责调度的 kube-scheduler,以及负责容器编排的kubecontroller-manager。整个集群的持久化数据,则由 kube-apiserver 处理后保存在 Etcd

kubelet 主要负责同容器运行时(比如 Docker 项目)打交道。

而这个交互所依赖的,是一个称作 CRIContainer Runtime Interface)的远程调用接口,这个接口定义了容器运行时的各项核心操作,比如:启动一个容器需要的所有参数。

这也是为何,Kubernetes 项目并不关心你部署的是什么容器运行时、使用的什么技术实现,只要你的这个容器运行时能够运行标准的容器镜像,它就可以通过实现 CRI 接入到Kubernetes 项目当中。

而具体的容器运行时,比如 Docker 项目,则一般通过 OCI 这个容器运行时规范同底层的Linux 操作系统进行交互,即:把 CRI 请求翻译成对 Linux 操作系统的调用(操作 Linux Namespace Cgroups 等)

kubelet 还通过 gRPC 协议同一个叫作 Device Plugin 的插件进行交互。这个插件,是 Kubernetes 项目用来管理 GPU 等宿主机物理设备的主要组件,也是基于Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能kubelet 的另一个重要功能,则是调用网络插件和存储插件为容器配置网络和持久化存储。这两个插件与 kubelet 进行交互的接口,分别是 CNIContainer Networking Interface)和 CSIContainer Storage Interface

(完)