基于 Kubernetes 的云原生 DevOps 第 1 章 云革命

🏷️ 《基于 Kubernetes 的云原生 DevOps》

Alan Watts：

There was never a time when the world began, because it goes round and round like a circle, and there is no place on a circle where it begins.

1.1 云的诞生

一种新的商业模式：用户可以共享由第三方提供和运行的远程机器的计算能力。

云的中心思想：购买计算能力，而不是计算机。

在裸金属时代（又称为铁器时代），计算能力是一项资本输出。如今这属于一项运营费用，而这一点是两者的根本区别。

云服务，有时称为软件即服务或 SaaS 。

当你使用云基础设施来运行自己的服务时，你所购买的就是基础设施即服务（Infrastructure as a Service, IaaS）。
云计算是企业与其 IT 基础设施之间关系的一场革命。

1.2 开发运维拉开序幕

在此之前，软件的开发和运维本质上是两种完全不同的工作，由两组不同的人执行。这种分工源于 20 世纪中叶，两者之间几乎没有交集。

云出现后，分布式系统非常复杂，很难将系统运维（故障恢复、处理超时、顺利地升级版本）与系统地设计、体系结构以及实现分离开来。编写软件地工作人员必须了解软件与系统其余部分地关系，而负责运维系统地工作人员则必须了解软件如何工作或为何会发生故障。

开发运维运动的初衷是设法将这两个团队组织到一起：写作、共享知识，共同为系统的可靠性和软件的正确性负责，并改善软件系统与开发团队双方的可扩展性。

理解开发运维的关键在于理解它主要是组织上的人为问题，而不是技术的问题。

咨询第二法则（The Second Law of Consulting）

无论乍看之下如何，问题一定出在人身上。
-- Gerald M. Weinberg, Secrets of Consulting

采用开发运维时，企业需要进行深刻的文化变革，首先从管理以及战略层面开始，然后逐步传播到组织的各个部分。速度、敏捷、协作、自动化和软件质量是开发运维的主要目标，对于许多公司而言，这意味着思维方式的重大转变。

与开发运维密不可分的乃是基础设施即代码的概念。

云的巨大规模，以及开发运维运动的协作性和以代码为中心的本质已将运维转变为软件问题。同时，这也将软件变成了运维问题。

1.3 容器的到来

容器格式包含运行应用程序所需的所有文件，可以打包到一个镜像文件中，然后由容器运行时执行。

这与虚拟机镜像有何不同？虚拟机镜像也包含运行应用程序所需的所有文件，但是它还包含了很多其它东西。常见的虚拟机镜像大约为 1 GB，而设计良好的容器镜像很可能要小一百倍。

更糟糕的是，虚拟机是虚拟的：底层的物理 CPU 需要实现一个虚拟的 CPU，共虚拟机运行。该虚拟曾会对性能产生巨大的负面影响：在测试中，虚拟工作负载的运行速度比同等的容器慢 30% 。

相比之下，容器可以像普通的二进制可执行文件一样直接在实际的 CPU 上运行，没有虚拟开销。
此外，由于容器仅保存所需的文件，因此比虚拟机镜像小很多。而且它们还巧妙地使用了分层地可寻址文件系统，这些层可在容器之间共享和重用。
容器在运行时集合了所有必需层，你只需下载本地尚未缓冲地层。因此可以非常有效地利用磁盘空间和网络带宽。

容器不仅是部署与打包地单位，也是重用、伸缩以及资源分配的单位。

开发人员无需担心不同版本的软件需要在不同的 Linux 发行版上运行，也无需担心不同的库和语言版本等。容器唯一的依赖只有操作系统内核。

你只需将应用程序放在容器镜像中，就可以在任何支持标准容器格式且拥有兼容内核的平台上运行。

1.4 容器的编排

容器还能大大减轻运维团队的负担。他们只需运行一个容器编排器即可。

容器编排器是一种能够将多个不同的机器组合成一个集群的软件；而集群指的是一种统一的计算基底，从用户的角度看，集群就像是一台可以运行容器且功能非常强大的计算机。

编排指的是协调和排序不同的活动，以实现共同的目标。
调度指的是管理可利用的资源，并将工作负载分配到最能有效运行的地方。
集群管理则是将多个物理或虚拟的服务器联合成一个统一、可靠、容错且看似像一个整体的小组中。

术语“容器编排器”通常指的是负责计划、编排和管理集群的单个服务。

1.5 Kubernetes

为了解决在全球百万台服务器上运行大量服务的问题，Google 开发了一款私有的内部容器编排系统：Borg 。

Borg 是一个集中式管理系统，用于将容器分配和调度到服务器池中运行，但它与 Google 自己的内部技术和专有技术紧密耦合，难以扩展，也无法公开发布。

2014 年，Google 建立了一个名为 Kubernetes 的开源项目（源于希腊语，意思是“舵手，飞行员”），该项目的目标是根据 Borg 及后来 Omega 的经验，开发出每个人都可以使用的容器编排器。

到 2017 年末，编排之战结束，最终 Kubernetes 赢得了胜利。

Kelsey Hightower：

Kubernetes 完全可以胜任系统管理员的工作：自动化、故障转移、集中式日志记录、监控。它吸收了我们在开发运维社区中积累的经验，并转化成了开箱即用的功能。

Kubernetes 核心内置了负载均衡以及自动伸缩等功能，其它功能则由使用 Kubernetes API 的附加组件、扩展和第三方工具提供。Kubernetes 生态系统非常庞大，并且还在不断地发展壮大。

Kubernetes 大大减少了部署的时间和工作量。零停机时间部署很容易实现，因为 Kubernetes 会默认执行滚动更新（启动新版本的容器，等到它们正常工作后，再关闭旧的容器）。

Kubernetes 还提供了工具来辅助实施持续部署实践：如金丝雀部署、蓝绿部署，支持自动伸缩，拥有内置的冗余和故障转移功能。

Kubernetes 并非万能。
首先，有些工作并不适合 Kubernetes（如 数据库）。
其次，有些东西实际上并不需要 Kubernetes，完全可以在服务器（serverless）平台上运行，这种平台也成为 函数即服务（Functions as a Service） 平台。

Faas 模型非常适合仅在需要时才运行的计算。

函数和容器的结合有时称为函数容器。

1.6 云原生

云原生计算基金会（Cloud Native Computing Foundationg，CNCF）成立于 2015 年，旨在“围绕一系列高质量项目促进社区的发展，确保容器称为微服务架构编排的基础之一。”

CNCF 是 Linux 基金会的一部分，其汇集了开发人员、最终用户以及包括主流公共云提供商在内的各个供应商。CNCF 旗下最有名的项目就是 Kubernetes 本身，此外，该基金会还孵化并推广了云原生生态系统的其它关键组件：Prometheus、Envoy、Helm、Fluente、gRPC 等。

云原生系统的一些特征：

• 可自动化
• 广泛性和灵活性
• 弹性和可扩展性
• 动态
• 可观察性
• 分布式

1.7 运维的未来

每个开发团队需要一名运维专家，负责团队提供的系统或服务的健康状况。他/她也是一名开发人员，同时还是多个领域的专家：网络、Kubernetes、性能、弹性，并为其他开发人员提供工具和系统，方便他们将代码交付到云。

开发人员生产力工程（Developer Productivity Engineering，DPE）团队会采取一切必要措施来帮助开发人员更快更好地完成工作：运维基础设施、构建工具、解决问题。

Lyft 的工程师 Matt Klein 认为，尽管对于创业公司和小型公司来说，纯开发运维模型是不错地选择，但随着组织地发展，基础设施和可靠性专家自然地向中央团队靠拢。但是他也认为团队不能无限扩展：

Matt Klein：

当工程组织的规模扩大到 75 名员工时，必然会出现一个中央基础设施团队来建立构建微服务产品团队所需的通用基础功能。
但是到了某个时间点，我们就会发现中央基础设施团队无法一面继续构建和运维对业务成功至关重要的基础设施，另一面还要承担起帮助产品团队完成运营任务的负担。

并非每个开发人员都能称为基础设施专家，而仅凭一支基础设施专家团队也无法为日益增长的开发人员提供服务。对于大型组织而言，尽管仍然需要一个中央基础设施团队，但同时也需要在每个开发或产品团队中加入 网站可靠性工程师（Site Reliability Engineer，SRE） 。他们通过自己的专业知识为每个团队提供咨询，并在产品开发和基础设施之间架起一座桥梁。

1.8 小结

• 云计算可以帮助你节省购买硬件的费用以及日常管理的开销，方便你构建弹性、灵活、可扩展的分布式系统。
• 开发运维代表了人们意识到现代软件开发并非止步于发布代码，我们需要在编写代码的人和使用代码的人之间建立闭合的反馈循环。
• 开发运维还为基础设施和运维世界带来了以代码为中心的方法以及良好的软件工程实践。
• 你可以通过容器，在小规模、标准化、自包含的单元中部署和运行软件。通过将容器化的微服务连接在一起，你可以更轻松、以更低的代价构建大型多样化的分布式系统。
• 编排系统负责以自动化、可编程的方式来完成部署容器、调度、扩展、联网以及优秀的系统管理员所需承担的所有工作。
• Kubernetes 是标准的容器编排系统，随时随刻都可以在生产中使用。
• 云原生是人们谈论基于云、容器化分布式系统时频繁提及的术语，这些系统由互相协作的微服务组成，并由自动化的基础设施即代码动态管理。
• 运维以及基础设施技术根本不会被云原生革命所淘汰，而且将来还会越来越重要。
• 中央团队的工作仍然是通过构建和维护平台与工具，帮助所有其他团队实现开发运维。
• 软件工程师与运维工程师之间的明显界限会逐渐消失。如今只有软件，而我们都是工程师。