持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第8天，点击查看活动详情
1 k8s要解决什么？
编排？调度？容器云？集群管理？至今无标准答案。不同发展阶段，k8s需着力问题不同。
但大多数用户期望的体验是确定的：现在我有应用的容器镜像，请帮我在一个给定的集群上把应用运行起来！还希望能给我提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。
这不就是经典PaaS（eg. Cloud Foundry）项目的能力？有了Docker后，根本不需要什么Kubernetes、PaaS，只要使用Docker公司的Compose+Swarm项目，就完全可以很方便DIY出这些功能！ 所以若k8s只停留在拉取用户镜像、运行容器及提供常见的运维功能，早就没了。实际上，在定义核心功能过程中，正是依托Borg项目的理论优势，才在短短几个月迅速站稳脚跟，进而确定如下的全局架构：
和Borg类似，都由Master、Node两种节点，即控制节点和计算节点。
控制节点
即Master节点，由三个紧密协作的独立组件组合而成：
- 负责API服务的kube-apiserver
- 负责调度的kube-scheduler
- 负责容器编排的kube-controller-manager
整个集群的持久化数据，由kube-apiserver处理后保存在Ectd。
计算节点上最核心的是
2 kubelet组件
kubelet主要负责同容器运行时（如Docker项目）打交道。这个交互所依赖的，是CRI（Container Runtime Interface)的远程调用接口，该接口定义了容器运行时的各项核心操作，如启动一个容器需要的所有参数。 这也是为何k8s不关心部署的是什么容器运行时、使用什么技术实现，只要你的容器运行时能运行标准的容器镜像，就可通过实现CRI接入到K8S项目。
而具体的容器运行时，如Docker项目，一般通过OCI容器运行时规范同底层的Linux交互，即：把CRI请求翻译成对Linux操作系统的调用（操作Linux Namespace和Cgroups等）。
kubelet还通过gRPC协议同一个叫作Device Plugin的插件进行交互。 这插件是Kubernetes项目用来管理GPU等宿主机物理设备的主要组件，也是基于Kubernetes项目进行机器学习训练、高性能作业支持等工作必须关注的功能。
另一重要功能，是调用网络插件和存储插件为容器配置网络和持久化存储。这两个插件与kubelet进行交互的接口：
- CNI（Container Networking Interface）
- CSI（Container Storage Interface）。
kubelet怪名来自Borg里的同源组件Borglet。因为Borg项目，并不支持我们这里所讲的容器技术，而只是简单地使用Linux Cgroups对进程进行限制。 即像Docker这样的“容器镜像”在Borg不存在，Borglet组件也自然不需要像kubelet这样考虑如何同Docker进行交互、如何对容器镜像进行管理的问题，也无需支持CRI、CNI、CSI等诸多容器技术接口。
kubelet完全就是为实现k8s项目对容器的管理能力而重新实现的一个组件，与Borg之间无直接传承关系。
虽不使用Docker，但Google内部确实在使用一个包管理工具，名叫Midas Package Manager (MPM)，其实它可以部分取代Docker镜像的角色。
