kubernetes学习实践（五）-kubernetes的本质

经过前面四章的学习，我们了解了容器，一个正在运行的Linux容器，可以分为两个视角来看：

• 容器的静态视图：一组联合挂载在/var/lib/docker/aufs/mnt/上的rootfs，即容器镜像。
• 容器的动态视图：一个由Namespace+Cgroups，构成的隔离环境，即容器运行时。

作为一名开发者，并不关心运行时的差异，因为在整个“开发-测试-发布”的流程中，真正承载着容器信息进行传递的，是容器镜像，而不是运行时。

用户需求

现在我有了应用的容器镜像，需要在指定的集群上把这个应用运行起来。提供如：路由网关，水平扩展，监控，备份，灾难恢复等运维能力。当然这是经典PaaS的能力。如果kubernetes仅仅是停留在拉取用户镜像，运行容器，以及以上能力，跟经典PaaS相比并没有任何优势。

kubernetes架构

由master和node两种节点组成，分别对应控制节点和计算节点。

控制节点，master由三个紧密协作的独立组件组合而成，分别是：

• 负责API服务的kube-API server
• 负责调度的kube-scheduler
• 负责容器编排的kube-controller-manager

整个集群的持久化数据，则由kube-API server处理后保存在Etcd中。

在kubernetes项目中，kubelet主要负责同容器运行时（如：docker等）进行交互。

kubernetes对交互的抽象

kubernetes不关心你部署的是什么容器，并且定义了容器调用的规范

• CRI（Container Runtime Interface），kubelet与Container Runtime交互的规范，定义了容器运行时的各项核心操作，如：启动一个容器的所有参数等。
• gPRC协议，在kubernetes中作为kubelet与Device Plugin交互的规范，进行宿主机物理设备管理的组件。
• CNI（Container Networking Interface），kubelet与Networking交互的规范，调用网络插件，配置容器网络。
• CSI（Container Storage Interface），kubelet与Volume Plugin交互的规范，调用存储插件，配置持久化存储。

kubernetes解决任务与任务之间的关系

任务与任务之间往往存在各种各样的关系，如：一个web应用与数据库之间的访问关系，一个负载均衡器和它的后端服务之间的代理关系，一个门户应用与授权组件之间的调用关系。
经典PaaS处理关系的粒度是粗的，是一个VM级别的，是依靠手工运维的。

Pod

pod中的容器共享同一个namespace，同一组数据volume，从而达到高效率交换信息的目的。

//todo