学习 Kubernetes，第三部分 扩展我的应用程序

在Twitter上关注我，很高兴接受您对主题或改进的建议/Chris

第三部分旨在展示如何扩展应用程序。我们可以轻松设置某个应用程序所需的副本数量，并让 Kubernetes 自行决定如何实现。这就是我们定义所谓的“期望状态”。

当流量增加时，我们需要扩展应用程序以满足用户需求。我们已经讨论了部署和服务，现在让我们来谈谈扩展。

• 第一部分 - 从头开始​​，第一部分，基础知识、部署和 Minikube在这一部分中，我们将介绍为什么使用 Kubernetes、一些历史和一些基本概念，如部署、节点、Pod。
• 第二部分 - 介绍服务和标签在本部分中，我们将加深对 Pod 和节点的了解。我们还将介绍如何使用标签来查询我们的工件。
• 第三部分 - 扩展，我们来了
• 第四部分 - 自动扩展在本部分中，我们将了解如何设置自动扩展，以便处理突然大量增加的传入请求

在 Kubernetes 环境中，扩展意味着什么？

我们得到了更多的 Pod，更多的 Pod 被调度到节点。

现在是时候再次讨论我们在前面部分提到过的理想状态了。

这时，我们将控制权移交给 Kubernetes。我们需要做的就是告诉 Kubernetes 我们需要多少个 Pod，剩下的就交给 Kubernetes 处理。

那么，我们告诉 Kubernetes 我们想要的 Pod 数量，这意味着什么？Kubernetes 能帮我们做什么？

这意味着我们获得了应用程序的多个实例。这也意味着流量被分配到所有 Pod 上，即负载均衡。

此外，Kubernetes，或者更具体地说，Kubernetes 内的服务将监视哪些 Pod 可用并将流量发送到这些 Pod。

资源

• 免费 Azure 帐户如果您想试用 AKS、Azure Kubernetes 服务，您将需要一个免费的 Azure 帐户
• Kubernetes.io了解 Kubernetes 的最佳资源之一是 Google 的官方 Kubernetes 网站。
• Kubernetes 概述Kubernetes 概述、其各个部分以及其工作原理
• 云端 Kubernetes你是否觉得自己已经了解 Kubernetes 的方方面面，只想学习如何使用托管服务？那么这个链接正适合你
• AKS、Azure Kubernetes 服务文档Azure Kubernetes 服务，托管 Kubernetes
• AKS 的最佳实践您已经了解 AKS 并想学习如何更好地使用它？

扩展演示实验室

如果您还没有阅读前两部分，我建议您回去读一读。要使以下内容生效，您至少需要一个部署。如果您还没有创建部署，请按照以下步骤操作：

kubectl run kubernetes-first-app --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080

让我们看一下我们的部署：

kubectl get deployments

让我们仔细看看我们得到的回应：

我们有三条信息对我们很重要。首先，我们有一个READY列，其中的值应该按以下方式读取：CURRENT STATE/DESIRED STATE。接下来是UP_TO_DATE显示已更新以达到所需状态的副本数量的列。
最后，我们有一个AVAILABLE列，显示有多少个副本可用于工作。

让我们扩大规模

现在，让我们进行一些缩放。为此，我们将使用scale如下命令：

kubectl scale deployments/kubernetes-first-app --replicas=4 

正如我们上面所看到的，副本数量已增加到4，因此 Kubernetes 已准备好对任何传入请求进行负载平衡。

接下来让我们看看我们的 Pod：

当我们请求4副本时，我们得到了4Pod。

我们可以看到，使用以下describe命令进行了此缩放操作，如下所示：

kubectl describe deployments/kubernetes-first-app

在上图中，我们获得了有关我们的大量信息Replicas，但其中还有一些其他信息，我们将在稍后解释。

它能负载平衡吗？

扩展的目的是为了均衡传入请求的负载。这意味着不会用同一个 Pod 来处理所有请求，而是会用到不同的 Pod。现在我们已经将应用程序扩展至包含其自身的副本，
可以轻松地尝试这一点。4

到目前为止，我们使用describe命令来描述部署，但我们也可以用它来描述 IP 和端口。一旦我们获得了 IP 和端口，就可以向其发送不同的 HTTP 请求。

kubectl describe services/kubernetes-first-app

特别看一下NodePort和Endpoints。NodePort是我们想要通过 HTTP 请求到达的端口值。

现在，我们将实际调用 cURL 命令，并确保它每次都访问不同的端口，从而证明我们的负载均衡功能正常。具体操作如下：

NODE_PORT=30450

接下来是 cURL 调用：

curl $(minikube ip):$NODE_PORT

如上所示，我们进行了 4 次调用。根据输出和实例名称判断，我们发现每个请求都命中了不同的 Pod。由此可见，负载均衡正在发挥作用。

缩小规模

到目前为止，我们已经完成了扩展。借助该scale命令，我们成功地从一个 Pod 扩展到了 4 个 Pod。我们可以使用相同的命令进行缩减，如下所示：

kubectl scale deployments/kubernetes-first-app --replicas=2 

现在，如果我们快速添加下一个命令，我们就可以看到 Kubernetes 尝试调整到所需状态时 Pod 是如何被删除的。

4 个 Pod 中有 2 个表示Terminating只需要 2 个 Pod 即可维持新的理想状态。

再次运行我们的命令，我们看到只剩下 2 个 Pod，因此已经达到了我们新的期望状态：

我们还可以查看我们的部署，看看我们的scale指令是否已被正确解析：

自我修复

自我修复是 Kubernetes 确保维持所需状态的一种方式。Pod 无法自我修复，因为 Pod 可能会死亡。由于 Kubernetes，一个新的 Pod 会取代它。

那么我们如何测试这一点呢？

很高兴你问到这个问题，我们可以删除一个 Pod，看看会发生什么。那么该怎么做呢？我们使用delete命令。不过我们需要知道 Pod 的名称，所以我们需要调用get pods它。那么我们就从这个开始吧：

kubectl get pods

然后让我们从两个 Pod 中选择一个kubernetes-first-app-669789f4f8-6glpx并将其分配给一个变量：

POD_NAME=kubernetes-first-app-669789f4f8-6glpx

现在将其删除：

kubectl delete pods $POD_NAME

让我们快速检查一下 Pod 的状态get pods。它应该显示Terminating，如下所示：

等待一段时间，然后输出我们的变量，$POD_NAME然后输出get pods。这样应该会得到类似下面的结果。

那么上图告诉我们什么呢？它告诉我们，我们删除的 Pod 确实被删除了，但它也告诉我们，通过启动一个新的 Pod，两个副本的期望状态已经实现。我们看到的是“自我修复”在发挥作用。

不同的扩展方式

好的，我们研究了一种通过明确说明我们希望某个部署有多少个副本来实现扩展的方法。然而，有时我们可能需要一种不同的扩展方式，即自动扩展。自动扩展是指您不必设置所需的确切副本数量，而是依靠 Kubernetes 创建它认为需要的副本数量。那么 Kubernetes 如何知道这一点呢？它可以查看多项指标，但一个常见的指标是 CPU 利用率。假设您有一个预订网站，突然有人发行了 Bruce Springsteen 的门票，您很可能想要依靠自动扩展，因为第二天当门票全部售罄时，您希望 Pod 的数量恢复正常，而您不想手动执行此操作。

自动缩放是我计划在以后的文章中更详细地介绍的一个主题，所以如果你真的好奇它是如何实现的，我建议你看看这里

概括

好的。我们成功了。我们通过创建应用程序的副本成功实现了应用程序的扩展。这并不难。我们展示了如何只需为 Kubernetes 提供所需的状态，它就会尽力保持该状态，这也称为“自我修复”。此外，我们还提到了另一种扩展方式，即自动扩展，但我们决定将这个话题留到另一篇文章中讨论。希望您现在能够更加惊叹 Kubernetes 的强大功能以及应用程序扩展的便捷性。