Kubernetes实战(第二版)----第1章 Kubernetes简介

关注公众号:登峰大数据，阅读Kubernetes实战(第二版)(完整中文版)，系统学习Kubernetes！

本章涵盖了

• Kubernetes简介和起源

• 为什么Kubernetes被如此广泛地采用

• Kubernetes如何改变数据中心

• Kubernetes体系结构和操作概述

• 如何以及是否应该将Kubernetes集成到你的公司中

在了解使用Kubernetes运行应用程序的细节之前，必须首先对Kubernetes设计用来解决的问题、它是如何产生的以及它对应用程序开发和部署的影响有一个基本的了解。第一章是对这些主题的一个概述。

1.1 Kubernetes简介

Kubernetes这个词在希腊语中是领航员或舵手的意思，指的是掌舵的人。舵手不一定和船长一样。船长对船负责，舵手是掌舵的人。

在了解了更多Kubernetes的工作后，你会发现这个名字非常合适。舵手负责维持船的航向，执行船长下达的命令，并报告船的航向。Kubernetes控制你的应用程序并报告它们的状态，而你——船长——决定你想要的系统去哪里。

KUBERNETES怎么发音，K8S是什么?

Kubernetes的正确希腊发音是Kie-ver-nee-tees，与你通常在技术对话中听到的英语发音不同。最常见的是koober-netties或koober-nay-tace，但你也可能听到koober-nets，尽管很少听到。

在书面和口头对话中，它也被称为Kube或K8s，发音为Kates，其中8表示省略在第一个和最后一个字母之间的字母数量。

1.1.1  Kubernetes概述

Kubernetes是一个软件系统，用于自动化部署和管理由运行在容器中的计算机进程组成的复杂、大规模应用程序系统。让我们来学习它是怎么做的。

抽象基础设施

当软件开发人员或操作人员决定部署应用程序时，他们通过Kubernetes来完成，而不是将应用程序部署到单个计算机上。Kubernetes在底层硬件上为用户和应用程序提供了一个抽象层。

正如您在下图中看到的，底层基础设施(即计算机、网络和其他组件)对应用程序是隐藏的，这使得开发和配置它们更加容易。

图1.1 使用Kubernetes的基础设施抽象

标准化部署应用程序的方式

由于底层基础设施的细节不再影响应用程序的部署，所以将应用程序部署到企业数据中心的方式与在云中的方式相同。描述应用程序的单一清单可用于本地部署和在任何云提供商上部署。底层基础设施中的所有差异都由Kubernetes处理，因此可以将重点放在应用程序及其包含的业务逻辑上。

部署应用程序声明

Kubernetes使用声明式模型定义应用程序，如下图所示。您描述组成应用程序的组件，Kubernetes将此描述转换为运行中的应用程序。然后，根据需要重新启动或重新创建应用程序的某些部分，从而保持应用程序正常运行。

图1.2 应用程序部署的声明模型

每当更改描述信息时，Kubernetes将采取必要的步骤重新配置正在运行的应用程序，以匹配新的描述信息，如下图所示。

图1.3 描述信息的变化反映在运行的应用程序中

负责应用程序的日常管理

一旦将应用程序部署到Kubernetes，它就会接管应用程序的日常管理。如果应用程序失败，Kubernetes将自动重新启动它。如果硬件出现故障或基础结构拓扑发生了变化，需要将应用程序移动到其他机器上，那么Kubernetes会自己完成这一切。负责操作系统的工程师可以专注于大局，而不是在细节上浪费时间。

回到航海的类比：开发和操作工程师是船上的军官，他们舒适地坐在扶手椅上做出高级决策，而Kubernetes则是舵手，负责在应用程序和基础设施驶过的汹涌波涛中操纵系统的低级任务。

图1.4 Kubernetes接管了应用程序的管理

Kubernetes所做的一切以及它所带来的好处都需要一个更长的解释，我们将在后面讨论。在此之前，先了解它是如何开始的以及Kubernetes项目目前处于什么位置。

1.1.2 关于Kubernetes项目

Kubernetes最初是由谷歌开发的。谷歌实际上总是在容器中运行应用程序。早在2014年，就有报道称他们每周启动20亿个容器。这意味着每秒超过3000个容器，今天这个数字还要高得多。它们在分布在世界各地几十个数据中心的数千台计算机上运行这些容器。现在想象一下手动完成这些工作是个什么情形。很明显，你需要自动化，在如此大规模的规模下，自动化更加完美。

Borg和Omega--Kubernetes的前辈

谷歌工作负载的庞大规模迫使他们开发解决方案，以使数以千计的软件组件的开发和管理具有可管理性和成本效益。多年来，谷歌开发了一个名为Borg的内部系统(后来又开发了一个名为Omega的新系统)，帮助应用程序开发人员和运营商管理这数千个应用程序和服务。

除了简化开发和管理之外，这些系统还帮助他们更好地利用基础设施。这在任何组织中都很重要，但当您操作数十万台机器时，即使利用率上的微小改进也意味着节省数百万台机器，因此开发这样一个系统的动机是显而易见的。

注：谷歌的能源使用数据显示，它们运行着大约90万台服务器。

随着时间的推移，基础设施也会增长和发展。每一个新的数据中心都是最先进的。它的基础设施与过去不同。尽管存在差异，但应用程序在一个数据中心中的部署不应与在另一个数据中心中的部署有所不同。

跨多个区域部署应用程序以减少区域故障导致应用程序停机的可能性，这一点尤其重要。为了有效地做到这一点，有必要使用一致的方法部署应用程序。

关于Kubernetes——开源项目——以及由此衍生的商业产品

基于他们在开发Borg、Omega和其他内部系统时获得的经验，谷歌在2014年推出了Kubernetes，一个现在每个人都可以使用并进一步改进的开源项目。

图1.5 Kubernetes开源项目的起源和状态

在Kubernetes正式发布之前很久，其他公司，比如一直走在开源软件前沿的红帽公司(Red Hat)，很快就加入了Kubernetes的行列，帮助开发了这个项目。最终，它的发展远远超出了创始人的期望，如今它可以说是世界上领先的开源项目之一，有几十个组织和数以千计的个人为它做出了贡献。

现在有几家公司正在提供由开源项目构建的企业级Kubernetes产品。这些公司包括Red Hat OpenShift、Pivotal Container Service、Rancher等。

Kubernetes是如何发展出一个全新的云原生生态系统的

Kubernetes还催生了许多其他相关的开源项目，其中大多数现在都在云本地计算基金会(CNCF)的保护伞下，后者是Linux基金会的一部分。

CNCF每年在北美、欧洲和中国组织几次KubeCon - CloudNativeCon会议。2019年，参加人数超过23,000人，其中北美KubeCon达到压倒性的12000人。这些数据表明，Kubernetes对当今世界各地的公司部署应用程序的方式产生了难以置信的积极影响。如果不是这样的话，它不会被如此广泛地采用。

1.1.3 理解为什么Kubernetes如此受欢迎

近年来，我们开发应用程序的方式发生了很大变化。这导致了Kubernetes等新工具的开发，而这些新工具反过来又反馈并推动了应用程序架构和开发方式的进一步改变。让我们来看一些具体的例子。

自动化微服务的管理

在过去，大多数应用都是大型单体。应用程序的组件是紧密耦合的，它们都在一个计算机进程中运行。应用程序是由一个大型开发团队作为一个单元开发的，并且应用程序的部署非常简单。将它安装在一台功能强大的计算机上，并提供了所需的少量配置。水平扩展应用程序几乎是不可能的，因此每当需要增加应用程序的容量时，就必须升级硬件——换句话说，就是垂直扩展应用程序。

然后出现了微服务范式。这些单体应用被分成几十个，有时是几百个独立的进程(服务)，如下图所示。这允许组织将他们的开发部门划分为更小的团队，每个团队只开发整个系统的一部分——只是一些微服务。

图1.6 比较单体应用程序和微服务

每个微服务现在都是一个独立的应用程序，具有自己的开发和发布周期。随着时间的推移，不同微服务的依赖关系将不可避免地出现差异。一个微服务需要库的一个版本，而另一个微服务需要同一库的另一个版本(可能不兼容)。在同一个操作系统中运行这两个应用程序变得很困难。

幸运的是，容器解决了这个问题，其中每个微服务都需要不同的环境，但是每个微服务现在都是一个单独的应用程序，必须单独管理。越来越多的应用程序让这变得更加困难。

整个应用程序的各个部分不再需要在同一台计算机上运行，这使得扩展整个系统变得更容易，但也意味着需要对应用程序进行配置，以便彼此通信。对于只有少量组件的系统，这通常可以手工完成，但是现在通常会看到部署了超过100个微服务。

当系统由许多微服务组成时，自动化管理是至关重要的。Kubernetes提供了这种自动化。它提供的特性使得管理数百个微服务的任务几乎是微不足道的。

连接dev和ops的分歧

随着应用程序架构的这些变化，我们还看到了团队开发和运维软件的方式的变化。通常，开发团队会独立构建软件，然后将完成的产品扔给运维团队，由运维团队进行部署和管理。

随着dev-ops范式的出现，这两个团队现在在软件产品的整个生命周期中更加紧密地合作。开发团队现在更多地参与到部署软件的日常管理中。但这意味着他们现在需要了解它运行的基础设施。

作为一名软件开发人员，主要关注点是实现业务逻辑。而不是处理底层服务器的细节。幸运的是，Kubernetes隐藏了这些细节。

标准化的云

在过去的一二十年里，许多组织已经将他们的软件从本地服务器转移到云上。这样做的好处似乎超过了担心被锁定在特定的云提供商(这是由于依赖提供商的专有api来部署和管理应用程序而造成的)。

任何想要将其应用程序从一个提供商转移到另一个提供商的公司都必须做额外的、不必要的工作，从应用程序中抽象底层云提供商的基础设施和api。这需要用于构建主要业务逻辑的资源。

Kubernetes在这方面也提供了帮助。Kubernetes的流行迫使所有主要的云提供商将Kubernetes集成到他们的产品中。客户现在可以通过Kubernetes提供的一组标准api将应用程序部署到任何云提供商。

图1.7  Kubernetes标准化了在云提供商上部署应用程序的方式

如果应用程序构建在Kubernetes的api上，而不是直接构建在特定云提供商的专有api上，那么它可以相对容易地转移到任何其他云提供商。

1.2 理解Kubernetes

上一节解释了Kubernetes的起源以及它被广泛采用的原因。在这一节中，我们将进一步了解Kubernetes到底是什么。

1.2.1了解Kubernetes如何转换计算机集群

让我们仔细看看在服务器上部署Kubernetes时，数据中心的感知是如何变化的。

Kubernetes类似于计算机集群的操作系统

可以将Kubernetes想象为集群的操作系统。下一幅图演示了运行在计算机上的操作系统与运行在计算机集群上的Kubernetes之间的类比。

图1.8 Kubernetes对于计算机集群就像操作系统对于计算机一样

就像操作系统支持计算机的基本功能一样，比如将进程调度到cpu上，充当应用程序和计算机硬件之间的接口，Kubernetes将分布式应用程序的组件调度到底层计算机集群中的单个计算机上，并充当应用程序和集群之间的接口。它使应用程序开发人员不必在其应用程序中实现与基础设施相关的机制;相反，他们依靠Kubernetes提供这些服务。这包括:

• 服务发现——一种允许应用程序发现其他应用程序并使用它们提供的服务的机制，

• 水平伸缩——复制应用程序以调整负载的波动，

• 负载平衡——在所有应用程序副本上分布负载，

• 自我修复——通过自动重启失败的应用程序，并在它们的节点失败后将它们移动到健康的节点，从而保持系统健康，

• 领导者选举——这是一种机制，它决定应用程序的哪个实例应该处于活动状态，而其他实例保持空闲状态，但在活动实例失败时可以接管。

通过依赖Kubernetes提供这些特性，应用程序开发人员可以专注于实现核心业务逻辑，而不是浪费时间将应用程序与基础设施集成。

Kubernetes如何适应计算机集群

要获得Kubernetes如何部署到计算机集群上的具体示例，请看下图。

图1.9 Kubernetes集群中的计算机被分为控制平面和工作负载平面

首先将机器分为两组——主（Master）节点和工作(Worker)节点。主节点将运行Kubernetes控制平面，它表示系统的大脑并控制集群，而其余节点将运行应用程序(即工作负载)，因此表示为工作负载平面。

注：工作负载平面有时被称为数据平面，但这个术语可能会令人混淆，因为该平面不托管数据，而是托管应用程序。也不要被术语“平面”所迷惑——在这种情况下，您可以将其视为运行应用程序的“表面”。

非生产集群可以使用单个主节点，但是高可用性集群至少使用三个物理主节点来承载控制平面。工作节点的数量取决于要部署的应用程序的数量。

所有集群节点如何成为一个大型部署区域

在计算机上安装了Kubernetes之后，您在部署应用程序时不再需要考虑单个计算机。无论集群中的工作节点数量有多少，它们都将成为部署应用程序的单个空间。您可以使用Kubernetes API来完成此操作，该API由Kubernetes控制平面提供。

图1.10 Kubernetes将集群公开为统一部署区域

当我说所有工作节点成为一个空间时，我不希望您认为可以部署一个分布在几个小机器上的非常大的应用程序。Kubernetes不会做这样的魔术。每个应用程序必须足够小，以适合一个工作节点。

我的意思是，在部署应用程序时，它们最终在哪个工作节点上并不重要。Kubernetes以后甚至可以将应用程序从一个节点移动到另一个节点。当这种情况发生时，你甚至可能都没有注意到，你也不应该在意。

1.2.2 使用Kubernetes的好处

您已经了解了为什么世界各地的许多组织都欢迎Kubernetes进入它们的数据中心。现在，让我们仔细看看它给开发团队和IT运维团队带来的具体好处。

1.2.2 使用Kubernetes的好处

您已经了解了为什么世界各地的许多组织都欢迎Kubernetes进入它们的数据中心。现在，让我们仔细看看它给开发团队和IT运维团队带来的具体好处。

应用程序的自服务部署

因为Kubernetes将其所有工作节点表示为工作负载面，所以将应用程序部署到哪个节点不再重要。这意味着开发人员现在可以自己部署应用程序，即使他们不知道节点的数量或每个节点的特征。

在过去，系统管理员是决定每个应用程序应该放在何处的人。这个任务现在交给了Kubernetes。这允许开发人员部署应用程序，而不需要依赖其他人。当开发人员部署应用程序时，Kubernetes会根据应用程序的资源需求和每个节点上可用的资源来选择运行应用程序的最佳节点。

通过更好地利用基础设施降低成本

如果不关心应用程序落在哪个节点上，这还意味着它可以在任何时候移动到任何其他节点，而不必担心它。Kubernetes可能需要这样做，以便为希望部署的更大应用程序腾出空间。这种移动应用程序的能力允许将应用程序紧密地打包在一起，以便以最佳的方式利用节点的资源。

注：在第17章中，您将了解Kubernetes如何决定将每个应用程序放在何处，以及您如何影响决策。

寻找最佳组合可能是一项挑战和费时的工作，特别是当所有可能选项的数量非常大时，例如当有许多应用程序组件和可以部署它们的许多服务器节点时。计算机可以比人类更好更快地完成这项任务。Kubernetes做得很好。Kubernetes通过在同一台机器上组合不同的应用程序，提高了硬件基础设施的利用率，这样就可以在更少的服务器上运行更多的应用程序。

自动调整，以改变负载

使用Kubernetes管理已部署的应用程序还意味着，运维团队不必经常监视每个应用程序的负载，以响应突然的负载高峰。Kubernetes也处理了这个问题。它可以监视每个应用程序消耗的资源和其他指标，并调整每个应用程序运行实例的数量，以应对增加的负载或资源使用。

当在云基础设施上运行Kubernetes时，它甚至可以通过云提供商的API提供额外的节点来增加集群的规模。通过这种方式，您永远不会耗尽空间来运行应用程序的其他实例。

保持应用程序平稳运行

Kubernetes还会尽一切努力确保应用程序平稳运行。如果您的应用程序崩溃，Kubernetes将自动重启它。因此，即使您的应用程序在运行了几个小时之后就耗尽了内存，Kubernetes也会通过自动重启来确保您的应用程序继续为其用户提供服务。

Kubernetes是一个自愈系统，它处理软件错误，就像刚才描述的那样，但它也处理硬件故障。随着集群规模的增长，节点故障的频率也会增加。例如，在一个有100个节点、每个节点的平均故障间隔时间(MTBF)为100天的集群中，每天都有一个节点发生故障。

当一个节点失败时，Kubernetes自动将应用程序移动到剩余的健康节点。运维团队不再需要手动移动应用程序，而是可以专注于修复节点本身并将其返回到可用硬件资源池中。

如果基础设施有足够的空闲资源来允许系统在没有故障节点(去掉问题节点的情况下)的情况下正常运行，运维团队甚至不必立即对故障作出反应。如果它发生在午夜，运营团队中的任何人都不需要醒来。它们可以在正常工作时间处理故障节点。

简化应用程序开发

上一节中描述的改进主要与应用程序部署有关。但是应用程序开发的过程是怎样的呢?Kubernetes会给他们带来什么吗?它肯定如此。

如前所述，Kubernetes提供了与基础设施相关的服务，否则就必须在应用程序中实现这些服务。这包括分布式应用程序中的服务和/或对等点的发现、领袖选举、集中应用程序配置等。Kubernetes提供了这一点，同时保持应用程序与Kubernetes无关，但是在需要时，应用程序还可以查询Kubernetes API以获取关于其环境的详细信息。他们还可以使用API来改变环境。

1.2.3 Kubernetes集群的架构

正如你已经知道的，一个Kubernetes集群由两组节点组成:

• 承载控制平面组件的一组主节点，它们是系统的大脑，因为它们控制着整个集群。

• 组成工作负载平面的一组工作节点，这是运行工作负载(或应用程序)的地方。

下图显示了这两个平面以及它们所包含的不同节点。

图1.11 组成Kubernetes集群的两个平面

这两个平面以及这两种类型的节点运行不同的Kubernetes组件。书中接下来的两个部分介绍了它们，并对它们的功能进行了总结，但不涉及细节。本书的第三部分将深入介绍这些组件及其内部结构。

控制平面组件

控制平面是控制集群的。它由运行在单个主节点上或跨多个主节点复制的几个组件组成，以确保高可用性。控制平面的组件如下图所示。

图1.12 Kubernetes控制平面的组件

以下是组成部分及其功能：

• Kubernetes API Server公开RESTful Kubernetes API。使用集群和其他Kubernetes组件的工程师通过这个API创建对象。

• etcd分布式数据存储了通过API创建的对象，因为API Server本身是无状态的。Server是唯一与etcd通信的组件。

• Scheduler 调度程序决定每个应用程序实例应该在哪个工作节点上运行。

• Controllers 控制器赋予通过API创建的对象生命。它们中的大多数只是创建其他对象，但有些还与外部系统通信(例如，云提供商通过其API)。

控制平面的组件保持并控制集群的状态，但它们不运行应用程序。这是由(worker)节点完成的。

工作节点组件

工作节点是运行应用程序的计算机。它们构成集群的工作负载平面。除了应用程序之外，几个Kubernetes组件也在这些节点上运行。它们执行在应用程序之间运行、监视和提供连接的任务。如下图所示。

图1.13 运行在每个节点上的Kubernetes组件

每个节点运行以下组件集合:

• Kubelet，一个与API Server对话并管理在其节点上运行的应用程序的代理。它通过API报告这些应用程序和节点的状态。

• 容器运行时环境(Container Runtime)，它可以是Docker或与Kubernetes兼容的任何其他Container Runtime。它按照Kubelet的指示在容器中运行应用程序。

• Kubernetes Service Proxy(Kube代理)在应用程序之间对网络流量进行负载平衡。它的名字暗示着通过它进行通信，但现在情况已经不一样了。你将在第14章中了解原因。

附加组件

大多数Kubernetes集群还包含几个其他组件。这包括一个DNS服务器，网络插件，日志代理和其他组件。它们通常在工作节点上运行，但也可以配置为在主节点上运行。

对架构有更深入的理解

现在，我只希望您对这些组件的名称和它们的功能有一些模糊的了解，因为我将在接下来的章节中多次提到它们。你将在这些章节中学习到关于它们的片段，但是我将在第14章中详细解释它们。

我不喜欢解释事物是如何工作的，除非我先解释事物是做什么的，并教你如何使用它。这就像学开车一样。你不会想知道内幕的。首先，你只想学习如何从A点到达B点。只有这样，你才会对汽车如何使这一切成为可能感兴趣。了解引擎盖下的东西，也许有一天当你的车坏了，被困在路边时，你能帮助你的车再次开动起来。我讨厌这么说，但是由于Kubernetes的复杂性，您在处理Kubernetes时会遇到很多这样的情况。

1.2.4  Kubernetes如何运行应用程序

通过对组成Kubernetes的组件的一般概述，我终于可以解释如何在Kubernetes中部署应用程序。

定义您的应用程序

Kubernetes中的一切都由一个对象表示。可以通过Kubernetes API创建和检索这些对象。应用程序由这些对象的几种类型组成--一种类型表示整个应用程序部署，另一种表示应用程序的运行实例，另一种表示一组这些实例提供的服务，并允许通过单个IP地址访问它们，还有许多其他类型。

所有这些类型在本书的第二部分都有详细的解释。目前，知道通过几种类型的对象定义应用程序就足够了。这些对象通常以YAML或JSON格式在一个或多个清单文件中定义。

定义：YAML最初被认为是“另一种标记语言”的意思，但后来它被改为递归缩略词“YAML Ain’t Markup Language”。这是将对象序列化为人类可读文本文件的方法之一。

定义：JSON是JavaScript对象表示法的缩写。这是序列化对象的另一种方式，但更适合在应用程序之间交换数据。

下图显示了通过创建一个清单(使用两个服务公开两个应用部署)来部署应用程序的示例。

图1.14 将应用程序部署到Kubernetes

当部署应用程序时，会发生以下操作:

• 将应用程序清单提交给Kubernetes API。API Server将清单中定义的对象写入etcd。

• 控制器controller会注意到新创建的对象并创建几个新对象——每个应用程序实例一个。

• 调度器Scheduler为每个实例分配一个节点。

• Kubelet注意到一个实例被分配给Kubelet的节点。它通过容器运行时环境运行应用程序实例。

• Kube Proxy注意到应用程序实例已经准备好接受来自客户端的连接，并为它们配置一个负载均衡器。

• Kubelets和Controllers监视系统并保持应用程序运行。

这个过程在下面的章节中会有更详细的解释，但是完整的解释会在第14章中给出，在你熟悉了所有涉及到的对象和控制器之后。

向API提交应用程序

在创建YAML或JSON文件之后，通常通过Kubernetes命令行工具kubectl将文件提交给API。

注：Kubectl的发音是kube-control，但社区中较温和的人更喜欢称之为kube-cuddle。有些人称之为kube-C-T-L。

Kubectl将文件分割为单个对象，并通过向API发送HTTP PUT或POST请求来创建每个对象，这通常是使用RESTful API的情况。API Server验证对象并将其存储在etcd数据存储中。此外，它通知所有感兴趣的组件这些对象已经创建。下面将介绍控制器，它就是这些组件之一。

关于控制器controllers

大多数对象类型都有一个关联的控制器。控制器对特定的对象类型感兴趣。它等待API Server通知它:一个新对象已经创建，然后执行操作使该对象生效。通常，控制器只是通过相同的Kubernetes API创建其他对象。例如，负责应用程序部署的控制器创建一个或多个表示应用程序的单个实例的对象。控制器创建的对象数量取决于应用程序部署对象中指定的副本数量。

关于调度器Scheduler

调度器是一种特殊类型的控制器，它的唯一任务是将应用程序实例调度到工作节点上。它为每个新的应用程序实例对象选择最佳工作节点，并将其分配给实例--通过API修改对象的方式。

关于Kubelet和容器运行时环境

在每个工作节点上运行的Kubelet也是一种控制器。它的任务是等待应用程序实例被分配到它所在的节点，并运行应用程序。这是通过命令容器运行时环境启动应用程序的容器来实现的。

关于Kube代理

因为应用程序部署可能包含多个应用程序实例，所以负载均衡器需要在单个IP地址公开它们。Kube代理是与Kubelet一起运行的另一个控制器，它负责设置负载均衡器。

保持应用程序的健康运行

应用程序启动并运行后，Kubelet通过在应用程序终止时，重新启动应用程序的方式来保持其健康。它还通过更新表示应用程序实例的对象来报告应用程序的状态。其他控制器监视这些对象，并确保在其节点出现故障时将应用程序移动到正常的节点。

现在，您大致熟悉了Kubernetes的体系结构和功能。此时，您不需要理解或记住所有的细节，因为当您在本书的第二部分中了解到每个单独的对象类型和将它们引入生命周期的控制器时，再消化这些信息会更容易。

1.3 在您的组织/公司中引入Kubernetes

在结束本章之前，让我们看看如果您决定在自己的IT环境中引入Kubernetes，您可以使用哪些选项。

1.3.1在本地和云中运行Kubernetes

如果希望在Kubernetes上运行应用程序，那么必须决定是在本地、在组织自己的基础设施(本地)中运行它们，还是在一个主要的云提供商中运行它们，或者两者都运行——在一个混合云解决方案中

本地运行Kubernetes

如果项目规则要求您在现场运行应用程序，那么在自己的基础设施上运行Kubernetes可能是唯一选择。这通常意味着您将不得不自己管理Kubernetes，但我们将在稍后讨论这个问题。

Kubernetes可以直接在裸机上运行，也可以在数据中心运行的虚拟机中运行。在这两种情况下，您都不能像在云提供商提供的虚拟机中运行集群那样轻松地扩展集群。

在云中部署Kubernetes

如果没有本地基础设施，那么别无选择，只能在云中运行Kubernetes。这样做的好处是，如果需要，可以在短时间内扩展集群。如前所述，当集群的当前大小不再足以运行您想部署的所有应用程序时，Kubernetes本身可以要求云提供商提供额外的虚拟机。

当工作负载减少，一些工作节点没有运行工作负载时，Kubernetes可以要求云提供商销毁这些节点的虚拟机，以降低运营成本。集群的这种弹性当然是在云中运行Kubernetes的主要好处之一。

使用混合云解决方案

一个更复杂的选择是在本地运行Kubernetes，但也允许它溢出到云中。如果超出了自己数据中心的容量，可以配置Kubernetes以在云中提供额外的节点。通过这种方式，你可以两全其美。大多数时候，您的应用程序在本地运行，无需租用虚拟机，但在每年只有几次出现的短时间峰值负载，您的应用程序可以通过使用云中的额外资源来处理额外的负载。

如果您的用例需要它，您还可以跨多个云提供商运行Kubernetes集群，或者使用上述任何一种选项的组合。这可以通过使用单个控制平面或在每个位置使用一个控制平面来完成。

1.3.2 自己管理或不管理Kubernetes

如果您正在考虑在您的组织中引入Kubernetes，您需要回答的最重要的问题是，您是自己管理Kubernetes，还是使用Kubernetes即服务类型的产品，由其他人为您管理它。

自己管理Kubernetes

如果您已经在本地运行了应用程序，并且拥有足够的硬件来运行可用于生产的Kubernetes集群，那么您的第一反应可能是自己部署和管理它。如果你问Kubernetes社区的任何人这是否是一个好主意，你通常会得到一个非常明确的“不”。

图1.14是部署应用程序时Kubernetes集群中所发生的情况的简化表示。即使这个数字也会吓到你。Kubernetes带来了大量额外的复杂性。任何想要运行Kubernetes集群的人都必须非常熟悉它的内部工作方式。

可生产的Kubernetes集群的管理是一个数十亿美元的产业。在您决定自己管理一个项目之前，您必须咨询已经做过该项目的工程师，以了解大多数团队会遇到的问题。如果你不这样做，你可能会注定失败。另一方面，将Kubernetes用于非生产用例或使用托管Kubernetes集群的问题要少得多。

在云中使用托管的Kubernetes集群

使用Kubernetes比管理它容易十倍。大多数主要的云提供商现在都提供Kubernetes-as-a-Service。它们负责管理Kubernetes及其组件，而您只需像云提供商提供的任何其他API一样使用Kubernetes API。

顶级管理的Kubernetes产品包括以下内容:

• 谷歌Kubernetes引擎(GKE)

• Azure Kubernetes服务(AKS)

• Amazon Elastic Kubernetes服务(EKS)

• IBM Cloud Kubernetes服务

• 红帽OpenShift在线和专用

• VMware云战

• 阿里巴巴Kubernetes云容器服务(ACK)

本书的前半部分只关注Kubernetes的使用。您将在一个本地开发集群和一个受管理的GKE集群上运行这些练习，因为我发现它是最容易使用的，并且提供了最好的用户体验。本书的第二部分为您管理Kubernetes提供了坚实的基础，但要真正掌握它，您还需要获得额外的经验。

1.3.3使用普通的或扩展的Kubernetes

最后一个问题是，是使用普通的开源版本的Kubernetes，还是使用扩展的、企业级质量的Kubernetes产品。

使用普通版本的Kubernetes

Kubernetes的开源版本由社区维护，代表了Kubernetes开发的前沿。这也意味着它可能不像其他选项那样稳定。它也可能缺乏良好的安全默认值。部署普通版本需要进行大量的微调，以设置用于生产的所有内容。

使用企业级的Kubernetes发行版

在生产中使用Kubernetes的一个更好的选择是使用企业质量的Kubernetes分发版，如OpenShift或Rancher。除了更好的默认值提供的更高的安全性和性能之外，它们还提供了除了前文Kubernetes API中提供的对象类型之外的其他对象类型。例如，普通的Kubernetes不包含表示集群用户的对象类型，而商业发行版包含。它们还提供了额外的软件工具，用于在Kubernetes上部署和管理知名的第三方应用程序。

当然，扩展和加强Kubernetes需要时间，因此这些商业Kubernetes发行版通常比开源Kubernetes版本落后一到两个版本。这并不像听起来那么糟糕。利通常大于弊。

1.3.4你应该使用Kubernetes吗?

我希望这一章已经让您对Kubernetes感到兴奋，并迫不及待地将它挤进您的it堆栈中。但是为了恰当地结束这一章，我们需要说一两句：何时使用Kubernetes不是一个好主意。

您的工作负载需要自动化管理吗?

首先，您需要诚实地了解是否需要自动化应用程序的管理。如果您的应用程序是一个大型的庞然大物，那么您肯定不需要Kubernetes。

即使您部署了微服务，使用Kubernetes也可能不是最好的选择，尤其是在微服务数量非常少的情况下。很难提供一个确切的数字，因为其他因素也会影响决策。但是，如果您的系统包含的微服务少于5个，那么将Kubernetes放入其中可能不是一个好主意。如果您的系统有20多个微服务，那么您很可能会从Kubernetes的集成中获益。如果您的微服务数量介于两者之间，则应该考虑其他因素，比如下面描述的因素。

你能把你的工程师的时间花在学习Kubernetes上吗?

Kubernetes的设计目的是允许应用程序在不知道它们在Kubernetes中运行的情况下运行。虽然在Kubernetes中运行应用程序本身不需要修改，但开发工程师不可避免地要花费大量时间学习如何使用Kubernetes，即使运维人员是唯一真正需要这些知识的人。

你很难告诉你的团队你正在切换到Kubernetes，并且只期望运维团队开始探索它。开发者喜欢闪亮的新事物。在写这篇文章的时候，Kubernetes仍然是一个非常耀眼的东西。

你准备好应对这期间增加的成本了吗?

虽然Kubernetes降低了长期运营成本，但在组织中引入Kubernetes最初会增加培训、雇佣新工程师、构建和购买新工具以及可能的额外硬件的成本。除了应用程序使用的资源之外，Kubernetes还需要额外的计算资源。

不要相信炒作

虽然在写这本书的时候Kubernetes已经存在好几年了，但我不能说炒作阶段已经结束。最初的兴奋情绪刚刚开始平静下来，但对于Kubernetes的集成是否像看上去那样有必要，许多工程师可能仍无法做出理性的决定。

1.4 总结

在这一章的简介中，你会学到:

• Kubernetes是希腊语的舵手。就像船长在舵手掌舵时监督船一样，你监督你的计算机集群，而Kubernetes执行日常的管理任务。

• Kubernetes的发音是koo-ber-netties。Kubernetes命令行工具Kubectl的发音是kube-control。

• Kubernetes是一个基于谷歌在全球范围内运行应用程序的丰富经验而构建的开源项目。现在有成千上万的人在为它捐款。

• Kubernetes使用声明式模型来描述应用程序部署。在向Kubernetes提供应用程序的描述之后，它将使应用程序具有生命力。

• Kubernetes就像是集群的一个操作系统。它抽象了基础设施，并将数据中心中的所有计算机表示为一个大的、连续的部署区域。

• 基于微服务的应用程序比单片应用程序更难管理。您拥有的微服务越多，就越需要使用Kubernetes之类的系统来自动化它们的管理。

• Kubernetes帮助开发和运维团队做他们最擅长的事情。它将他们从平凡的任务中解放出来，并引入了在本地和任何云中部署应用程序的标准方法。

• 使用Kubernetes允许开发人员在没有系统管理员帮助的情况下部署应用程序。它通过更好地利用现有硬件来降低操作成本，自动调整系统以适应负载波动，并修复自身和运行在其上的应用程序。

• Kubernetes集群由主节点和工作节点组成。主节点运行控制平面，控制整个集群，而工作节点运行部署的应用程序或工作负载，因此代表工作负载平面。

• 使用Kubernetes很简单，但是管理它却很困难。没有经验的团队应该使用Kubernetes即服务产品，而不是自己部署Kubernetes。

到目前为止，你只是在码头上观察这艘船。该上船了。但是在你离开码头之前，你应该检查它所装载的集装箱。接下来您将这样做。