简介 P2


Kubernetes 能自动调度、配置、监管和故障处理，使开发者可以自主部署应用，并且控制部署的频率，完全脱离运维团队的帮助。 Kubernetes 同时能让运维团队监控整个系统，并且在硬件故障时重新调度应用。 P2


Kubernetes 抽象了数据中心的硬件基础设施，使得对外暴露的只是一个巨大的资源池。 在部署多组件应用时， Kubernetes 会为每个组件都选择一个合适的服务器，部署之后它能够保证每个组件可以轻易地发现其他组件，并彼此之间实现通信。 P2


Kubernetes 系统的需求 P2


近年来，应用程序的开发部署的变化原因： P2


大型单体应用被拆解为更多的小型微服务

应用运行所依赖的基础架构的变化

从单体应用到微服务 P2


单体应用由很多个组件组成，这些组件紧密地耦合在一起，并且在同一个操作系统进程中运行，所以在开发、部署、管理的时候必须以同一个实体进行。 P2


单体应用通常需要一台能为整个应用提供足够资源的高性能服务器，有两种方法可以应对不断增长的系统负荷： P3


垂直扩展：提升单机性能 —— 增加 CPU 、内存或其他系统资源

优点：不需要应用程序做任何变化

缺点：成本很快会越来越高，并且通常会有瓶颈

水平扩展：增加服务器数量

优点：能线性扩充系统性能

缺点：需要在架构层面支持水平扩展，部分组件难于甚至不太可能去做水平扩展（像关系型数据库）

所思


垂直扩展总会达到单机性能的极限，所以终极解决方案是水平扩展，同时也可以通过垂直扩展进行辅助。


仔细回想一下，发现我们平时也是这样处理的。由于历史原因，我们项目核心功能的大部分代码在同一个应用中，导致启动就会占用大量资源，单机处理能力较差。在经历各种配置下压测后，选择了合适的配置，然后就直接水平扩展，并且逐渐将一些压力大的接口拆成微服务提供接口或者直接处理各种请求。


如果单体应用的任何一个部分不能扩展，整个应用就不能扩展，除非我们想办法把它拆分开。 P3


将应用拆解为多个微服务 P3


服务之间可以通过类似 HTTP 这样的同步协议通信，也可以通过像 AMQP 这样的异步协议通信，并且微服务也可以选用最适合的开发语言来实现。 P3



图 1.1 单体应用中的组件与独立的微服务

每个微服务都是独立的，可以独立开发和部署。只要 API 不变或者向前兼容，改动一个微服务，并不会要求对其他微服务进行改动或者重新部署。 P3


微服务的扩容 P3


单体系统必须要对整个系统扩容，而微服务只需针对单个服务扩容。因此，我们可以选择仅扩容那些需要更多资源的服务而保持其他的服务仍然维持在原来的规模。当单体应用因为其中一部分无法扩容而整体被限制扩容时，可以把应用拆分成多个微服务，将能扩容的服务进行水平扩展，不能进行扩容的组件进行垂直扩展。 P4



图 1.2 每个微服务能被多带带扩容

部署微服务 P4


当组件数量增加时，部署相关的决定就变得越来越困难。因为不仅组件部署的组合数在增加，而且组件间依赖的组合数也在以更大的因素增加，并且配置工作变得冗杂易错，同时因为跨了多个进程和机器，调试代码和定位异常调用变得困难。 P4


环境需求的差异 P5


因为组件之间依赖的差异性，应用程序需要同一个库的不同版本是不可避免的。当多个应用在同一个主机上运行就有可能会有依赖冲突。 P5



图 1.3 多个应用在同一主机上运行可能会有依赖冲突

为应用程序提供一个一致的环境 P5


开发和运维团队需要解决的一个最大的问题是程序运行环境的差异性： P5


开发环境和生产环境之间

各个生产机器之间

生产机器环境随时间的推移而变化

为了减少会在生产环境才暴露的问题，最理想的做法就是让应用在开发和生产阶段可以运行在完全一样的环境下，它们有完全一样的操作系统、库、系统配置、网络环境和其他所有条件。这个环境不会随着时间的推移而变化，并且在一台服务器上部署新的应用时，不会影响机器上已有的应用。 P6


迈向持续交付： DevOps 和无运维 P6


在过去，开发团队的任务是创建应用并交付给运维团队，然后运维团队部署应用并使它运行。 P6


而现在，让一个团队参与应用的开发、部署、运维的整个生命周期更好。这意味着开发者、 QA 和运维团队彼此之间的合作需要贯穿整个流程。这种实践被称为 DevOps 。 P6


带来的优点 P6


开发者更多地在生产环境中运行应用，能更好地理解用户的需求和问题、运维团队维护应用所面临的困难

开发者更趋向于尽快发布上线，能进行快速迭代

简化部署流程，开发者自己部署应用上线

让开发者和系统管理员做他们最擅长的 P6


Kubernetes 通过对实际硬件做抽象，然后将自身暴露成一个平台，用于部署和运行应用程序。它允许开发者自己配置和部署应用程序，而不需要系统管理员的任何帮助，让系统管理员聚焦于保持底层基础设施运转正常的同时，不需要关注实际运行在平台上的应用程序。 P7


介绍容器技术 P7


Kubernetes 使用 Linux 容器技术来提供应用的隔离，需要先通过熟悉容器的基本知识来更深入地理解 Kubernetes 。 P7


什么是容器 P7


用 Linux 容器技术隔离组件 P7


容器允许你在同一台机器上运行多个服务，不仅提供不同的环境给每个服务，而且将它们相互隔离。容器类似虚拟机，但开销小很多。 P7


一个容器里运行但进程实际上运行在宿主机的操作系统上，但容器里的进程仍然是和宿主机的其他进程隔离的。对容器内的进程本身而言，就好像是在机器和操作系统上运行的唯一一个进程。 P7


比较虚拟机和容器 P8


容器更加轻量级，它允许在相同的硬件上运行更多数量的组件。一个容器仅仅是运行在宿主机上被隔离的单个进程，仅消耗应用容器消耗的资源，不会有其他进程的开销。虚拟机则需要运行自己的一组系统进程，会产生除了组件进程消耗以外的额外计算资源损耗。 P8


因为虚拟机有额外开销，所以没有足够的资源给每个应用开一个专用的虚拟机，最终会将多个应用程序分组塞进每个虚拟机。而容器能够（也应该）让每个应用有一个容器，最终可以让同一台裸机上运行更多的应用程序。 P8