Kubectl scale 命令最佳实践

Posted 2023-05-05

参考技术A

云和安全管理服务专家新钛云服 祝祥翻译

kubectl scale 是帮助我们管理 Kubernetes 部署的众多工具之一。在本文中我们将 了解如何使用此工具以及最佳使用实践 。

kubectl scale 命令通过调整正在运行的容器的数量来立即缩放应用程序。这是增加部署副本数量的最快、最简单的方法，可用于应对服务高峰以及日常维护变更。

在本文中， 我们将了解如何使用 kubectl scale来 扩展一个简单的 Kubernetes Deployment ，同时，我们还将更深入的了解该命令相关的各种参数。最终形成 kubectl scale 的最佳实践，以及一些用于调整 Kubernetes 副`本数的替代方法 。

kubectl scale 用于更改Kubernetes deployment, replica set, replication controller和 statefulset 等对象的副本数码。当我们增加副本数时，Kubernetes将启动新的Pod来扩我们的服务。降低副本数将导致 Kubernetes 优雅地终止一些 pod，从而释放集群资源。

我们可以运行 kubectl scale 来手动调整应用程序的副本数，以响应不断变化的服务容量需求。增加的流量负载可以通过增加副本数来处理，提供更多的应用程序实例来服务用户流量。当业务突发降低的时候，可以减少副本的数量。这有助于通过避免使用不需要的资源来降低成本。

kubectl scale 最基本的用法是这样的：

执行此命令将调整名为demo-deployment 的部署，使其拥有三个正在运行的副本。我们可以通过替换其名称而不是部署来定位不同类型的资源：

现在我们将看一个使用 kubectl scale 扩展部署的完整示例。这是一个定义简单部署的 YAML 文件：

将此 YAML 保存到工作目录中的demo-deployment.yaml 。接下来，使用kubectl将部署添加到我们的集群：

现在运行 kubectl get pods 命令来查看已为部署创建的 pod：

单个副本不足以用于生产应用程序。如果托管 pod 的节点出于任何原因离线，我们可能会遇到停机时间。使用 kubectl scale 增加副本数以提供更多空间：

重复 kubectl get pods 命令以确认部署已成功扩容：

现在有五个 Pod 正在运行。从AGE列可以看到scale命令保留了原来的 pod 并新增了 4 个。

经过进一步思考，我们可能会决定此应用程序不需要五个副本。它只运行一个静态 nginx Web 服务器，因此每个用户请求的资源消耗应该很低。再次使用scale命令来降低副本数并避免浪费集群容量：

重复 kubectl get pods 命令：

Kubernetes 已将两个正在运行的 pod 标记为终止。这会将正在运行的副本计数减少到请求的三个 pod。选择要驱逐的 pod 会被发送一个SIGTERM(https://www.containiq.com/post/sigterm-signal-15-linux-graceful-termination-exit-code-143) 信号并允许优雅地终止(https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace)。停止后，它们将从 pod 列表中删除。

有时我们可能想要扩展资源，但前提是已经有特定数量的副本在运行。这可以避免意外覆盖以前的副本，例如集群中其他用户所做的更改。

在命令中包含 --current-replicas 标志可以达到效果：

此示例将演示deployment扩展到五个副本，但前提是当前有三个副本正在运行。 --current -replicas 值始终完全匹配；我们不能将条件表示为“小于”或“大于”特定计数。

当我们提供多个名称作为参数时， kubectl scale 命令可以一次缩放多个资源。每个资源都将缩放到由 --replicas 标志设置的相同副本计数。

此命令将应用程序和数据库deployment扩展到每个五个副本。

我们可以通过提供 --all 标志来扩展特定类型的每个资源，例如此示例以扩展默认命名空间中的所有部署：

这会选择当前活动命名空间内的每个匹配资源。缩放的对象显示在命令的输出中。

我们可以对使用 --selector 标志缩放的对象进行精细控制。这我们可以使用标准选择语法根据对象的标签(https://www.containiq.com/post/using-kubernetes-labels-selectors-annotations) 过滤对象。这是一个使用 app-name=demo-app 标签扩展所有部署的示例：

--timeout 标志设置 Kubectl 在放弃缩放操作之前将等待的时间。默认情况下，没有等待期。该标志接受可读的时间值，例如5m或1h：

如果无法立即完成缩放更改，这可以让我们避免长时间的终端挂起。尽管 kubectl scale 是一个命令式命令，但在将新 pod 调度到节点时，对缩放的更改有时可能需要几分钟才能完成。

使用 kubectl scale 通常是扩展工作负载的最快、最可靠的方法。但是，为了安全操作，需要记住一些最佳实践。如下所示：

首先将 spec.replicas 字段更改为我们所需的新副本数：

现在对修改后的文件重复 kubectl apply 命令：

kubectl scale 的另一个替代方案是 Kubernetes 对自动缩放的支持。配置此机制允许 Kubernetes 根据 CPU 使用率和网络活动等指标在配置的最小值和最大值之间自动调整副本计数。

kubectl scale命令是扩展 Kubernetes deployments, replica sets, replication controllers以及stateful sets的通用方式。它在每次调用时以一个或多个对象为目标，并对其进行缩放，以便运行指定数量的 pod。

我们可以选择设置条件，因此只有在存在特定数量的现有副本时才会更改比例，从而避免在错误方向上意外调整大小。

同时我们也希望能够遵循一些本文所提到的最佳时实践，从而平稳，可靠的实现资源的扩缩容。

*原文：https://www.containiq.com/post/kubectl-scale

开发命令行工具的 12 个最佳实践

简评：设计良好的命令行应用是极富生产力的工具，本文介绍了开发命令行工具的 12 个最佳实践

CLI 是构建产品的绝佳方式，与 Web 应用不同的是它需要的时间更少，并且功能更强大。使用Web，你可以执行开发人员编写的任何操作，使用 CLI，你可以轻松地将多个工具混合在一起以执行更加高级的任务，而这需要更多的专业知识才能使用，但仍然适用于管理任务、高级用户任务或开发人员产品。

在 Heroku，我们提出了一种称为 「12-factor app」 的方法，这是一套旨在制作易于维护的优秀 Web 应用程序的原则。我们还构建了一个名为 oclif 的 CLI 框架，旨在遵循这些原则使用Node 构建出色的 CLI 应用。

本着这种精神，在构建下一个 CLI 时，请记住以下 12 个因素：

1. 良好的帮助命令是必不可少的（Great help is essential）
2. 倾向于使用选系代替参数 （Prefer flags to args）
3. 明确当前的版本（一般是 --version/-V）（What version am I on?）
4. 关注流处理（输入输出流和重定向）（Mind the streams）
5. 处理错误（Handle things going wrong）
6. 颜控（Be fancy!）
7. 尽量提示（Prompt if you can）
8. 使用表格（Use tables）
9. 唯快不破（Be speedy）
10. 鼓励开源贡献代码（Encourage contributions）
11. 清晰的子命令（Be clear about subcommands）
12. 遵循 XDG 规范（Follow XDG-spec）

原文：12 Factor CLI Apps