现如今,Kubernetes 已经完全改变了软件开发方式。Kubernetes 作为一个管理容器化工作负载及服务的开源平台,其拥有可移植、可扩展的特性,并促进了声明式配置和自动化,同时它还证明了自己是管理复杂微服务的主要参与者。而 Kubernetes 之所以能够在业界被广泛采用,究其原因是 Kubernetes 迎合了以下需求:
企业想要在不断地增长的同时维持低成本
DevOps 想要一个可以大规模运行应用程序的稳定平台
开发人员希望有一个可靠并且可复制的流程来编写、测试和 debug 代码
但是,你是否考虑过如何在使用实际需要的资源的同时获得强大的容器编排平台?最佳资源利用的关键是知道需要扩展什么应用程序以及何时需要扩展应用程序。因此,在本文中,我们将讨论和学习如何扩展 Kubernetes 容器,并且我们将特别关注两类服务:kubectl 和 Horizontal Pod Autoscaler(HPA)。
kubectl
在绝大部分情况下和 Kubernetes 交互是通过一个名为 kubectl 的命令行工具。kubectl 主要用于和 Kubernetes API 进行通信来创建、更新以及删除在 Kubernetes 内的工作负载。在下文中,我们将提供一些常见的命令,你可以利用它们开始管理 Kubernetes。
大部分常见的 kubectl 命令都提供了要执行的特定操作或动作,比如创建、删除等。这一方法通常涉及解释描述 Kubernetes 中的对象(pod、服务、资源等)的文件(YAML 或 JSON)。这些文件可用于模板以及环境中的持续文件,并且帮助保持 Kubernetes 对声明式配置的关注。命令行所指定的操作将会传递到 API Server,然后根据需要与 Kubernetes 中的后端服务进行通信。下方的表格可以帮助你安装 kubectl:
请注意:随着新版本的发布,适用于 Windows 的 kubectl 的最佳版本会有所变化。想要找到目前最合适的二进制文件,请访问以下网址:
https://storage.googleapis.com/kubernetes-release/release/stable.txt
并根据需要调整上述 URL。
kubectl 句法
kubectl 句法如下:
Command: 指你想要执行的动作(创建、删除等)
Type: 指你要针对其执行命令的资源类型(Pod、Service 等)
Name: 资源对象的名称(区分大小写),如果你不指定一个名称,它会获取所有与你命令匹配的资源信息。
Flags: 这部分在句法中不是必要的,但是当需要查找指定资源时,十分有用。例如,-namespace 可以让你指定一个特定的命名空间,以在其中执行操作。
kubectl 操作
以下示例可以帮助你熟悉运行常用的 kubectl 操作:
以上都是 kubectl 中常用的操作,如果你想了解更多,可以查阅 kubectl 的官方指南。此外,我们在往期的文章中也有介绍:
Horizontal Pod Autoscaler(HPA)
Pod 水平自动伸缩(HPA)是 Kubernetes 的一个重要功能,它可以让你配置集群以自动伸缩正在运行的服务。HPA 实现为一种 Kubernetes API 资源和 controller。资源决定 controller 的行为,controller 会定期调整 replication controller 或部署中的副本数量,使观察到的平均 CPU 利用率与用户指定的目标相匹配。
同时,HPA 实现为控制回路,其周期由 controller manager 的–horizontal-pod-autoscaler-sync-period 标志控制(默认值为 30 秒)。
在每个周期期间,controller manager 会根据每个 HPA 定义中指定的指标来查询资源利用率。Controller manager 会从资源指标 API(针对 per-pod 资源指标)或自定义指标 API(针对所有其他指标)中获得指标。
针对 per-pod 资源指标(如 CPU),controller 会从资源指标 API 中为 HPA 定位的每个 Pod 获取指标。然后,如果设置了目标利用率值,则 controller 将会把利用率值计算为每个 pod 中容器的同等资源请求的百分比。如果设置了目标原始值,则直接使用原始指标值。然后,controller 将所有目标 pod 的利用率或原始值(取决于指定的目标类型)取平均值,并产生一个用于伸缩所需副本数量的比率。
针对 per-pod 自定义指标,controller 的功能类似于 per-pod 资源指标,但它适用于原始值,而非利用率值。
对于对象指标,将会获取单个指标(该指标描述了所讨论的对象),并将其与目标值进行比较,以产生用于伸缩所需副本数量的比率。
HPA controller 将会通过两种不同的方式获取指标:direct Heapster access 和 REST client access。当使用 direct Heapster access 时,HPA 将会通过 API server 的服务代理子资源直接查询 Heapster。请注意,Heapster 需要部署在集群上并在 kube-system 命名空间中运行。
HPA 的工作流程包含以下四个步骤,如图所示:
在设置默认 30 秒间隔期间,HPA 会持续检查你所配置的指标值
如果达到指定阈值,则 HPA 尝试增加 pod 的数量
HPA 主要更新在部署中或 replication controller 中的副本数量
然后,部署/replication controller 将会添加任何额外所需的 pod
当你推出 HPA 时请考虑以下因素:
默认的 HPA 检查间隔是 30 秒,这个默认值可以通过 controller manager 的— horizontal-pod-autoscaler-sync-period 标志进行配置。
默认的 HPA 相关指标容差为 10%。
在上一次扩展事件之后,HPA 将会等待 3 分钟,以使指标稳定下来。这一等待事件同样可以通过— horizontal-pod-autoscaler-upscale-delay 标志进行配置。
从上一次缩小事件开始,HPA 将会等待 5 分钟,以避免 autoscaler 抖动。同样可以通过— horizontal-pod-autoscaler-downscale-delay 标志进行配置。
与 replication controller 相比,HPA 最适合与部署对象或 Pod 指标配合使用,不适用于使用直接操作的 replication controller 的滚动更新。当你进行部署时,需要根据部署对象来管理底层副本集的大小。
当 HPA 与自定义指标(如 Pod 指标或对象指标)一起使用时,你需要决定何时进行伸缩。由于 Kubernetes 支持多种指标,因此你可以同时使用多种指标来决定伸缩的时间。请注意,Kubernetes 会依照次序来考虑每个指标。更多示例请查阅:
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale
结论
在本文中,我们讨论了两种扩展 Kubernetes 应用程序的主要工具,两者都是所有 Kubernetes 服务的关键组件。我们看到了如何安装并且使用不同的功能,如应用、获取、删除、描述以及 kubectl 的日志等。同时,我们回顾并了解有关 Horizontal Pod Autoscaler 的信息,例如它是如何工作的以及它对任意 Kubernetes 服务的重要性。在扩展微服务应用程序时,kubectl 和 HPA 都是 Kubernetes 的重要功能。
在上个月发布的 Rancher 2.3 中,已经集成了 HPA 功能,可以在 Rancher 中通过 UI 使用。目前,Rancher 2.3 也已经 stable,如果想要更全面地了解 Rancher 2.3 关注我们下周三晚上的Rancher K8S云课堂吧!
评论