背景
大型单体应用正被逐渐分解成小的、可独立运行的组件，我们称之为微 服务。 微服务彼此之间解祸， 所以它们可以被独立开发、 部署、升级、伸缩。
单体应用中的组件与独立的微服务:
每个微服务能被单独扩容:
当组件数量增加时，部署相关的决定就变得越来越困难。因为不仅组件部署的 组合数在增加，而且组件问依赖的组合数也在以更大的因素增加，配置工作变得冗杂且易错。 微服务还带来其他问题，比如因为跨了多个进程和机器 ，使得调试代码和定位异常调用变得困难。幸运的是，这些问题现在己经被诸如 Zipkin 这样的分布式定位系统解决。
容器技术
一个容器里运行的进程实际上运行在宿主机的操作系统上，就像所有其他进程一样(不像虚拟机，进程是运行在不同的操作系统上的)。 但在容器里的进程仍然是和其他进程隔离的。对于容器内进程本身而言，就好像是在机器和操作系统上运行的唯一一个进程。
使用虚拟机来隔离—组应用程序与使用容器隔离单个应用程序:
容器更加轻量级，每个虚拟机需要运行自己的一组系统进程，这就产生了除组件进程消耗,以及的额外计算资源损耗。虚拟机里的应用程序会执行虚拟机操作系统的系统调用，然后虚拟机内核会通过管理程序在宿主机上的物理来CPU执行x86指令。而容器则会完全执行运行在宿主机上的同一个内核的系统调用，此内核是唯一一个在宿主机操作系统上执行x86指令的内核。
容器实现隔离机制介绍
- namespace，Linux的命名空间，它使每个进程只看到它自己的系统视图(文件、进程、网络接口、主机名等);
- cgroups，Linux控制组，它限制了进程能使用的资源量 (CPU、 内存、 网络带宽等)。 命名空间类型： | 名称 | 解释 | | --- | --- | | Mount | 磁盘挂载目录 | | ProcessID | pid，进程ID | | Network | 网络服务 | | Inter-processcommunication | IPC,进程间通讯 | | UTS | 对容器HOSTNAME和domain的隔离,同时保存内核名称、版本、以及底层体系结构类型等信息 | | User ID | 用户 |
Docker容器平台介绍
Docker是一个打包、分发和运行应用程序的平台。它不仅简化了打包应用的流 程， 也简化了打包应用的库和依赖， 甚至整个操作系统的文件系统能被打包成一个 简单的可移植的包， 这个包可以被用来在任何其他运行Docker的机器上使用。应用程序不会关心它所在服务器上的任何东西，所以生产服务器上是否安装了和你开发机完全相同的一组库是不需要关心的。
例如，如果你用整个红帽企业版 Linux(RHEL) 的文件打包了你的应用程序，不管在装有 Fedora 的开发机上运行它，还是在装有 Debian 或者其他 Linux 发行版的 服务器上运行它， 应用程序都认为它运行在 RHEL 中。 只是内核可能不同。
- 镜像 —— Docker镜像里包含了你打包的应用程序及其所依赖的环境。它包含应用程序可用的文件系统和其他元数据，如镜像运行时的可执行文件路径。不同镜像可能包含完全相同的层， 因为这些Docker镜像都是基千另一个镜像之上构建的。这提升了镜像在网络上的分发效率，当传输某个镜像时，因为相同的层已被之前的镜像传输那么这些层就不需要再被传输。
- 镜像仓库 —— Docker镜像仓库用于存放Docker镜像。
- 容器 —— Docker容器通常是一个Linux容器，它基于Docker镜像被创建。
Docker镜像、 镜像仓库和容器：
需要注意的是，如果一个容器化的应用需要一个特定的内核版本，那它可能不能在每台机器上都工作。虚拟机没有这些局限性， 因为每个虚拟机都运行自己的内核。
Kubernetes介绍
Kubernetes 暴露整个数据中心作为单个开发平台：
Kubemetes 内部提供包括服务发现、扩容、负载均衡、自恢复，甚至领导者的选举。
应用程序开发者因此能集中精力实现应用本身的功能而不用浪费时间思索怎样集成应用与基础设施。
能在任何时间迁移应用并通过混合和匹配应用来获得比手动调度高很多的资源利用率。
Kubernetes集群架构
一 个 Kubernetes 集群由很多节点组成， 这些节点被分成 以下两种类型 :
- 主节点，它承载着 Kubernetes控制和管理整个集群系统的控制面板
- 工作节点，它们运行用户实际部署的应用
组成一个 Kubernetes 集群的组件：
控制面板
- Kubernetes API 服务器，你和其他控制面板组件都要和它通信
- Scheculer，它调度你的应用（为应用的每个可部署组件分配一个工作节点）
- Controller Manager，它执行集群级别的功能，如复制组件、持续跟踪工作节点、处理节点失败等
- etcd，一个可靠的分布式数据存储，它能持久化存储集群配置，控制面板的组件持有井控制集群状态。
工作节点
工作节点是运行容器化应用的机器。运行、监控和管理应用服务的任务是由以下组件完成的 :
- Docker，或其它容器类型
- Kubelet，它与 Kubernetes API 服务器通信，并管理它所在节点的容器
- Kubernetes Service Proxy (kube-proxy)，它负责组件之间的负载均衡网络流量
在Kubernetes中运行容器
Kubernetes 体系结构的基本概述和在它之上运行的应用程序:
应用描述符列出了四个容器，并将它们分为三组(这些集合被称为 pod ) 。 前两个 pod 只包含一个容器，而最后一个包含两个。这意味着两个容器都需要协作运行不应该相互隔离。在每个 pod 旁边还可以看到一个数字，表示需要并行运行的每个 pod 的 副本数量。在向 Kubernetes 提交描述符之后，它将把每个 pod 的指定副本数量调度到可用的工作节点上。 节点上的 Kubelets将告知 Docker 从镜像仓库中拉取 容器镜像井运行容器。一旦应用程序运行起来， Kubernetes 就会不断地确认应用程序的部署状态始终与你提供的描述相匹配。
标注 描述符，是为了说明，本质上我们是在 Kubernetes 描述我们所需要的运行效果，之后交由平台调度执行
小结
- 单体应用程序更容易部署，但随着时间的推移更难维护，并且有时难以扩展。
- 基于微服务的应用程序体系结构使每个组件的开发更容易，但是很难配置和部署它们作为单个系统工作。
- Linux 容器提供的好处与虚拟机差不多，但它们轻量许多，并且允许更好地利用硬件（cgroups）。
- 通过允许更简单快捷地将容器化应用和其操作系统环境一起管理，Docker 改进了现有的 Linux 容器技术，形成平台化。
- Kubernetes 将整个数据中心暴露为用于运行应用程序的单个计算资源。
- 开发人员可以通过Kubernetes部署应用程序，而无须系统管理员的帮助。
- 通过让 Kubernetes 自动地处理故障节点，系统管理员可以睡得更好。
