Kubernets(K8S)启动和运行 01-02 Kubernetes的速度非常快

Kubernetes的速度非常快

简介（Intoduction）

Velocity is the key component in nearly all software development today. The software industry has evolved from shipping products as boxed CDs or DVDs to software that is delivered over the network via web-based services that are updated hourly. This changing landscape means that the difference between you and your competitors is often the speed with which you can develop and deploy new components and features, or the speed with which you can respond to innovations developed by others.

速度是当今几乎所有软件开发的关键要素。软件行业已经从以盒装 CD 或 DVD 的形式提供产品，发展到通过网络提供软件，并每小时更新一次。这种不断变化的格局意味着，您与竞争对手之间的差距往往在于您开发和部署新组件和功能的速度，或者您响应他人开发的创新的速度。

It is important to note, however, that velocity is not defined in terms of simply raw speed. While your users are always looking for iterative improvement, they are more interested in a highly reliable service. Once upon a time, it was OK for a service to be down for maintenance at midnight every night. But today, all users expect constant uptime, even if the software they are running is changing constantly.

不过，需要注意的是，速度并不是简单的原始速度。虽然用户一直在寻求迭代改进，但他们更感兴趣的是高度可靠的服务。曾几何时，服务在每晚午夜因维护而停机是没有问题的。但如今，所有用户都希望有稳定的正常运行时间，即使他们运行的软件在不断变化。

Consequently, velocity is measured not in terms of the raw number of features you can ship per hour or day, but rather in terms of the number of things you can ship while maintaining a highly available service.

因此，衡量速度的标准不是每小时或每天可交付的原始功能数量，而是在维持高可用性服务的同时可交付的功能数量。

In this way, containers and Kubernetes can provide the tools that you need to move quickly, while staying available. The core concepts that enable this are:

• Immutability
• Declarative configuration
• Online self-healing systems

这样，容器和 Kubernetes 就能提供快速移动所需的工具，同时保持可用性。实现这一点的核心概念是：

• 不变性

• 声明式配置

• 在线自愈系统

These ideas all interrelate to radically improve the speed with which you can reliably deploy software.

这些理念相互关联，从根本上提高了可靠部署软件的速度。

不变性（The Value of Immutability）

Containers and Kubernetes encourage developers to build distributed systems that adhere to the principles of immutable infrastructure.

容器和 Kubernetes 鼓励开发人员构建遵循不可变基础设施原则的分布式系统。

With immutable infrastructure, once an artifact is created in the system it does not change via user modifications.

有了不可变基础架构，工件一旦在系统中创建，就不会因为用户的修改而改变。

Traditionally, computers and software systems have been treated as mutable infrastructure. With mutable infrastructure, changes are applied as incremental updates to an existing system. These updates can occur all at once, or spread out across a long period of time. A system upgrade via the apt-get update tool is a good example of an update to a mutable system.

传统上，计算机和软件系统被视为可变基础设施。在可变基础设施中，变化是作为增量更新应用于现有系统的。这些更新可以一次性完成，也可以在很长一段时间内分散进行。通过 apt-get update 工具进行的系统升级就是对可变系统进行更新的一个很好的例子。

Running apt sequentially downloads any updated binaries, copies them on top of older binaries, and makes incremental updates to configuration files. With a mutable system, the current state of the infrastructure is not represented as a single artifact, but rather an accumulation of incremental updates and changes over time. On many systems these incremental updates come from not just system upgrades, but operator modifications as well.

运行 apt 会按顺序下载任何更新的二进制文件，将其复制到旧的二进制文件之上，并对配置文件进行增量更新。在可变系统中，基础架构的当前状态并不是以单一工件的形式呈现，而是随着时间的推移不断累积的增量更新和变化。在许多系统中，这些增量更新不仅来自系统升级，也来自操作员的修改。

Furthermore, in any system run by a large team, it is highly likely that these changes will have been performed by many different people, and in many cases will not have been recorded anywhere.

此外，在任何由大型团队运行的系统中，这些更改极有可能是由许多不同的人执行的，而且在许多情况下不会记录在任何地方。

In contrast, in an immutable system, rather than a series of incremental updates and changes, an entirely new, complete image is built, where the update simply replaces the entire image with the newer image in a single operation. There are no incremental changes.

与此相反，在不可变系统中，建立的不是一系列增量更新和更改，而是一个全新的、完整的映像，更新只需一次操作就能用较新的映像替换整个映像。没有增量变化。

As you can imagine, this is a significant shift from the more traditional world of configuration management.

可以想象，与传统的配置管理相比，这是一个重大转变。

To make this more concrete in the world of containers, consider two different ways to upgrade your software:

• You can log in to a container, run a command to download your new software, kill the old server, and start the new one.
• You can build a new container image, push it to a container registry, kill the existing container, and start a new one.

为了在容器世界中更具体地说明这一点，可以考虑两种不同的软件升级方式：

• 你可以登录容器，运行命令下载新软件，杀死旧服务器，然后启动新服务器。

• 你可以构建一个新的容器映像，将其推送到容器注册表，杀死现有容器，然后启动一个新容器。

At first blush, these two approaches might seem largely indistinguishable. So what is it about the act of building a new container that improves reliability?

乍一看，这两种方法似乎没什么区别。那么，建造新集装箱的行为究竟是如何提高可靠性的呢？

The key differentiation is the artifact that you create, and the record of how you created it. These records make it easy to understand exactly the differences in some new version and, if something goes wrong, to determine what has changed and how to fix it.

关键的区别在于你创建的人工制品，以及如何创建的记录。有了这些记录，就很容易准确理解新版本的不同之处，如果出了问题，也很容易确定哪些地方发生了变化以及如何修复。

Additionally, building a new image rather than modifying an existing one means the old image is still around, and can quickly be used for a rollback if an error occurs. In contrast, once you copy your new binary over an existing binary, such a rollback is nearly impossible.

此外，构建新镜像而不是修改现有镜像意味着旧镜像仍然存在，如果出现错误，可以迅速用于回滚。相比之下，一旦将新的二进制文件复制到现有的二进制文件上，这种回退几乎是不可能的。

Immutable container images are at the core of everything that you will build in Kubernetes. It is possible to imperatively change running containers, but this is an anti-pattern to be used only in extreme cases where there are no other options (e.g., if it is the only way to temporarily repair a mission-critical production system). And even then, the changes must also be recorded through a declarative configuration update at some later time, after the fire is out.

不可变的容器映像是在 Kubernetes 中构建一切的核心。强制更改运行中的容器是可能的，但这是一种反模式，只有在没有其他选择的极端情况下才使用（例如，如果这是临时修复关键任务生产系统的唯一方法）。即便如此，也必须在熄火后的某个时间通过声明式配置更新来记录更改。

声明式配置（Declarative Configuration）

Immutability extends beyond containers running in your cluster to the way you describe your application to Kubernetes. Everything in Kubernetes is a declarative configuration object that represents the desired state of the system. It is the job of Kubernetes to ensure that the actual state of the world matches this desired state.

不变性不仅包括在集群中运行的容器，还包括向 Kubernetes 描述应用程序的方式。Kubernetes 中的一切都是一个声明性的配置对象，代表着系统的理想状态。Kubernetes 的工作就是确保世界的实际状态与这一理想状态相匹配。

Much like mutable versus immutable infrastructure, declarative configuration is an alternative to imperative configuration, where the state of the world is defined by the execution of a series of instructions rather than a declaration of the desired state of the world.

就像可变基础设施与不可变基础设施一样，声明式配置是命令式配置的另一种选择，在命令式配置中，世界的状态是通过执行一系列指令来定义的，而不是通过声明所期望的世界状态。

While imperative commands define actions, declarative configurations define state.

命令式命令定义动作，而声明式配置定义状态。

To understand these two approaches, consider the task of producing three replicas of a piece of software. With an imperative approach, the configuration would say “run A, run B, and run C.” The corresponding declarative configuration would be “replicas equals three.”

要理解这两种方法，请考虑制作一个软件的三个副本的任务。如果采用命令式方法，配置会是 “运行 A、运行 B 和运行 C”。相应的声明式配置则是 “副本等于三个”。

Because it describes the state of the world, declarative configuration does not have to be executed to be understood. Its impact is concretely declared.

由于声明式配置描述的是世界的状态，因此无需执行即可理解。它的影响是具体声明的。

Since the effects of declarative configuration can be understood before they are executed, declarative configuration is far less error-prone. Further, the traditional tools of software development, such as source control, code review, and unit testing, can be used in declarative configuration in ways that are impossible for imperative instructions. The idea of storing declarative configuration in source control is often referred to as “infrastructure as code.”

由于声明式配置的效果可以在执行之前就被理解，因此声明式配置的错误率要低得多。此外，软件开发的传统工具，如源代码控制、代码审查和单元测试，都可以用于声明式配置，这是命令式指令所无法做到的。在源代码控制中存储声明式配置的理念通常被称为 “基础架构即代码”。

The combination of declarative state stored in a version control system and the ability of Kubernetes to make reality match this declarative state makes rollback of a change trivially easy. It is simply restating the previous declarative state of the system. This is usually impossible with imperative systems, because although the imperative instructions describe how to get you from point A to point B, they rarely include the reverse instructions that can get you back.

版本控制系统中存储的声明状态与 Kubernetes 使现实与声明状态相匹配的能力相结合，使得回滚变更变得轻而易举。只需重述系统之前的声明状态即可。这在命令式系统中通常是不可能的，因为尽管命令式指令描述了如何从 A 点到达 B 点，但它们很少包含能让你返回的反向指令。

在线自愈系统（Self-Healing Systems）

Kubernetes is an online, self-healing system. When it receives a desired state configuration, it does not simply take a set of actions to make the current state match the desired state a single time. It continuously takes actions to ensure that the current state matches the desired state. This means that not only will Kubernetes initialize your system, but it will guard it against any failures or perturbations that might destabilize the system and affect reliability.

Kubernetes 是一个在线自愈系统。当它收到所需的状态配置时，它不会简单地采取一系列行动，使当前状态与所需状态一次性匹配。它会持续采取措施，确保当前状态与所需状态相匹配。这意味着，Kubernetes 不仅会初始化你的系统，还会防范任何可能破坏系统稳定和影响可靠性的故障或扰动。

A more traditional operator repair involves a manual series of mitigation steps, or human intervention performed in response to some sort of alert.

更传统的操作员修复涉及一系列手动缓解步骤，或根据某种警报进行人工干预。

Imperative repair like this is more expensive (since it generally requires an on-call operator to be available to enact the repair). It is also generally slower, since a human must often wake up and log in to respond. Furthermore, it is less reliable because the imperative series of repair operations suffers from all of the problems of imperative management described in the previous section.

像这样的紧急维修成本较高（因为通常需要值班操作员来实施维修）。一般来说，它的速度也较慢，因为人工必须经常唤醒并登录才能做出响应。此外，它的可靠性也较低，因为命令式修复操作存在上一节所述的命令式管理的所有问题。

Selfhealing systems like Kubernetes both reduce the burden on operators and improve the overall reliability of the system by performing reliable repairs more quickly.

像 Kubernetes 这样的自愈系统既能减轻操作员的负担，又能更快地进行可靠的修复，从而提高系统的整体可靠性。

As a concrete example of this self-healing behavior, if you assert a desired state of three replicas to Kubernetes, it does not just create three replicas—it continuously ensures that there are exactly three replicas. If you manually create a fourth replica, Kubernetes will destroy one to bring the number back to three. If you manually destroy a replica, Kubernetes will create one to again return you to the desired state.

这种自愈行为的一个具体例子是，如果你向 Kubernetes 提出三个副本的理想状态，它不会直接创建三个副本，而是会持续确保有三个副本。如果你手动创建第四个副本，Kubernetes 会销毁一个副本，使数量恢复到三个。如果你手动销毁一个副本，Kubernetes 会创建一个副本，再次让你回到所需的状态。

Online self-healing systems improve developer velocity because the time and energy you might otherwise have spent on operations and maintenance can instead be spent on developing and testing new features.

在线自修复系统可提高开发人员的开发速度，因为您原本可能要花费在运行和维护上的时间和精力，可以转而用于开发和测试新功能。

In a more advanced form of self-healing, there has been significant recent work in the operator paradigm for Kubernetes. With operators, more advanced logic needed to maintain, scale, and heal a specific piece of software (MySQL, for example) is encoded into an operator application that runs as a container in the cluster. The code in the operator is responsible for more targeted and advanced health detection and healing than can be achieved via Kubernetes’s generic self-healing. Often this is packaged up as “operators,” which are discussed in a later section.

在更高级的自愈形式中，Kubernetes 的操作员范例最近取得了重大进展。通过操作员，维护、扩展和修复特定软件（例如 MySQL）所需的更高级逻辑被编码到操作员应用程序中，作为集群中的一个容器运行。与 Kubernetes 的通用自愈功能相比，操作员中的代码负责更有针对性的高级健康检测和修复。这通常被打包成 “操作员”，将在后面的章节中讨论。