从容器到容器云
容器的组成
一个“容器”，实际上是一个由 Linux Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境
容器的结构
- 一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分我们称为“容器镜像”（Container Image），是容器的静态视图；
- 一个由 Namespace+Cgroups 构成的隔离环境，这一部分我们称为“容器运行时”（Container Runtime），是容器的动态视图。
开发者关心哪部分呢?
开发者关心的是静态视图。一名开发者，并不关心容器运行时的差异。因为，在整个“开发 - 测试 - 发布”的流程中，真正承载着容器信息进行传递的，是容器镜像，而不是容器运行时
通过容器镜像，可以和潜在用户（即，开发者）直接关联起来。
容器是云计算领域的绝对主角
而能够定义容器组织和管理规范的“容器编排”技术，就坐上了容器技术领域的“头把交椅”。
这其中，最具代表性的容器编排工具，当属 Docker 公司的 Compose+Swarm 组合，以及 Google 与 RedHat 公司共同主导的 Kubernetes 项目。
K8S解决的问题是什么？
K8S架构
分为控制节点和计算节点：
- 控制节点，master节点：由三个组件组成，分别是负责API服务的kube-apiserver、负责调度的kube-scheduler、以及负责容器编排的kube-controller-manager组成。整个集群的持久化数据，则是由kube-apiserver 处理后保存在Etcd中
- 计算节点：核心组件kubelet重要功能一是同容器运行时打交道，交互依赖于CRI，远程调用接口，这个接口定义了容器运行时候的各项核心操作，比如启动一个容器所需要的素有参数。重要功能二是调用网络插件和存储插件为容器配置网络和持久化存储
重要解决方案思路
- 运行在大规模集群中的各种任务之间，实际上存在这个各种各样的关系。这些关系的处理，才是作业编排的关系系统最困难的地方。比如应用和数据库之间的访问关系，负载均衡和后端服务器之间的代理关系。
- K8S设计思想：从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。
- 之前的做法：在容器技术普及之前，传统虚拟机环境对于这种关系的处理方法很粗粒度，不相关的应用功能被一股脑的部署在同一台虚拟机中，只是因为偶尔的几个请求。而且还需要各种手动维护工作。
- 容器的细粒度优势：原本拥挤在同一个虚拟机的各个应用功能、组件、守护进程都被分别做成镜像，然后运行在一个一个专属的容器中。
- 没有像其他项目，为每一个管理功能穿件一个指令，然后在项目中实现，这种做法在面对更多问题时候会力不从心。
K8S的方法
- 首先退给你过一个”编排对象“，比如job、pod 等来描述管理的应用
- 然后，再为它定义一些服务对象，比如service\secres等，这些对象，会服务具体的平台即功能
- 上述的方法就是所谓的声明式API，这种API对应的编排对象和服务对象，就是K8S项目中的API对象。API Object.
调度和编排
- 把一个容器或者POD按照某种规则，放置在某个最佳节点运行起来的，这种功能为”调度“
- 按照用户的意愿和整个系统的规则没完全自动化的处理好容器之间的关系，这种功能为”编排”
总结
- 容器可以分为两个部分，容器运行时和容器镜像
- K8S项目的架构
- 如何使用声明式API来描述容器化业务和荣期间关系的设计思想