k8s本质概述
容器技术的本质是通过Namespace、CGroups和rootfs构建的线程隔离环境，解决了用户在不同机器环境下都能无障碍启动应用的需求。也因此，在拥有了容器镜像之后，用户需要在自己的服务器集群上快速部署镜像，自动化处理各个容器之间的关系，以及更多的类似路由网关、应用水平扩展、监控、备份、灾难恢复等运维能力，这些都是k8s所能提供到的支持。
一、整体架构
k8s整体由控制节点master和计算节点node组成。
master节点中有三个独立组件：
- kube-controller-manager：负责容器编排
- kube-scheduler：负责调度
- kube-apiserver：负责api服务
node节点的核心是kubelet组件。这个组件负责通过CRI远程调用接口与容器运行时（docker项目）交互，而容器运行时（docker项目）通过OCI规范同底层的Linux 操作系统进行交互。
kubelet 还通过grpc协议同一个叫作Device Plugin 的插件进行交互，这个插件主要用于k8s管理宿主机物理设备。
kubelet 的另一个重要功能，则是调用网络插件（Networking）和存储插件(Volume Plugin)为容器配置网络和持久化存储。这两个插件与 kubelet 进行交互的接口，分别是 CNI和CSI。
二、核心功能
是什么让k8s和docker swarm等功能拉开差距？重点就在于k8s对大规模集群中各种任务之间的关系有着统一的方式进行定义。
k8s对容器间的“访问”进行了分类，一些常见的紧密关系：彼此之间需要频繁的交互和访问，或者，会直接通过本地文件进行信息交换。在k8s中，这些应用被划分为一个Pod，Pod里的容器共享同一个 Network Namespace、同一组数据卷，从而达到高效率交换信息的目的。
对于另外一种类型，类似于web应用和数据库之间的访问关系，部署在不同机器，虽然互相访问，但是宕机也不互相影响的关系，k8s提供一直Service服务。Service服务的主要作用，就是作为 Pod 的代理入口，从而代替 Pod 对外暴露一个固定的网络地址。
k8s的核心功能可以从以下全景图来加深理解：
- 容器是最基础概念，容器间紧密协作关系定义为一个Pod。
- 有Pod之后，希望能一次性启动多个应用的实例，所以有了Deployment，也就是多实例管理器。
- 存在一组相同的Pod，就又需要通过一个固定的IP地址和端口以负载均衡的方式访问它，所以有了 Service。
- 如果不同Pod直接的访问需要授权信息，比如数据库，就有了Secret对象。k8s可以在Pod启动前，将Secret中的数据以Volume的方式挂载到容器里。
上面描述的应用之间的关系，那应用运行的形态又要如何描述呢？
- 类似大数据任务之类的一次性运行的Pod，k8s将这种运行状态定义为Job对象。
- DaemonSet对象，用来描述每个宿主机上必须且只能运行一个副本的守护进程服务。
- CronJob对象，用于描述定时任务。
全景图中的种种都是k8s定义容器间关系和形态的主要方法。
总结一下：k8s对于定义容器间关系和形态的主要方法是通过定义编排对象，比如Pod，Job等来描述你试图管理的应用；再定义服务对象Service、Secret等来负责具体的平台级功能。这种方法就是k8s所谓的‘声明式 API’。这些定义的编排对象和服务对象就是k8s中的API对象。
k8s的价值在于为用户提供了一套基于容器构建分布式系统的基础依赖。
