Kubernetes 曾经是 Google 的一个内部项目,如今已经改变了软件开发的方式。蓝色背景上的白色方向盘现在似乎无处不在。业务想要增长并减少支付,DevOps 想要一个可以大规模运行应用程序的稳定平台,开发人员想要可靠和可重复的流程来编写、测试和调试代码。 Kubernetes 承诺了这一切。现在 Jelastic 提供托管 Kubernetes,启动集群再简单不过了。

但是,您有没有想过如何获得如此强大的容器编排平台并只为您实际需要的资源付费?本文将阐明 Jelastic(基础设施)和 Kubernetes(应用程序)级别的水平和垂直扩展。

在基础设施级别扩展 Kubernetes

Kubernetes 集群通常由一个 master(或其中几个)和多个调度应用程序 pod 的节点组成。这里的数学很简单:您在集群中运行的应用程序越多,您需要的资源(节点)就越多。假设您有一个由 3 个服务组成的微服务应用程序,每个服务都作为一个单独的 pod 启动,它请求 1GiB 的 RAM。这意味着您将需要一个 4 GiB 节点(K8s 组件和操作系统也需要一些 RAM)。如果在高负载、潜在内存泄漏或向集群部署更多服务的情况下需要额外的 RAM,该怎么办?正确,您要么需要一个更大的节点,要么向集群添加一个额外的节点。通常在这两种情况下,您都需要为虚拟机附带的确切资源量付费(例如,您需要为 3GiB 的 RAM 付费,即使其中一半未使用)。不过,Jelastic 并非如此。

Kubernetes节点垂直伸缩

让我们回到数学。如果应用程序大约需要 3GiB 的 RAM,并且集群中没有太多的事情发生,那么您只需要一个节点。当然,拥有一些额外的可用 RAM 总是一个好主意,因此 5GiB 节点很有意义。

同样,不是 Jelastic。您可以做的是请求一个 3GiB 节点并存储一个 2GiB。当您的应用程序(K8s pod)开始消耗更多(也在 K8s 端配置)或者您只是部署更多 pod(如下图所示)时,这 2 个额外的 GiB 立即可用,并且您仅在以下情况下才开始为这些资源付费它们被使用。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--Ho2ywD0W--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic.com /blog/wp-content/uploads/2019/08/vertical-scaling-kubernetes.png)

因此,您可以进行一些简单的数学运算并找出最佳集群拓扑:例如,3 个节点,4 GiB 的预留 RAM 和 3GiB 的动态资源。

Kubernetes节点水平自动伸缩

在 Kubernetes 集群中拥有一个巨大的节点并不是一个好主意,因为一旦发生中断或任何其他重大事件,所有部署都会受到影响。让多个节点处于待机模式并不具有成本效益。 Kubernetes 是否有可能在需要时添加节点?是的,Jelastic 中的 Kubernetes 集群可以配置水平节点自动缩放。当 RAM、CPU、I/O 或磁盘使用率达到一定水平时,将向集群添加新节点。不用说,只有在使用额外资源时,您才会为它们付费。将根据当前拓扑创建新添加的节点,即将应用现有的垂直扩展配置。一旦资源消耗恢复到预期水平,系统就会缩小规模。您的 Kubernetes 集群不会饿死,但您不会为未使用的资源付费。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--vXHUCa0p--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic.com /blog/wp-content/uploads/2019/08/horizontal-scaling-kubernetes.png)

在应用程序级别扩展 Kubernetes

Kubernetes 有自己的水平pod 自动缩放器(HPA)。简而言之,HPA 将根据 CPU 的利用率复制选择的部署。如果所有 Pod 的 CPU 消耗增长超过 70%,HPA 将调度更多 Pod,当 CPU 消耗恢复正常时,部署将缩减到原始副本数。

为什么这很酷?它如何与 Kubernetes 节点的自动水平扩展一起工作?比如说,你有一个节点和几个正在运行的 pod。突然之间,pod 中的某个特定服务开始收到大量请求并执行一些 CPU 开销很大的操作。 RAM 利用率不会增长,因此此时没有任何机制来扩展应用程序,这将很快变得无响应。 Kubernetes HPA 将扩展 pod,内部 K8s 负载均衡器会将请求重定向到健康的 pod。这些新的 pod 将需要更多资源,这就是 Jelastic 水平和垂直扩展发挥作用的地方。新的 Pod 要么放置在同一个节点上并利用动态 RAM,要么添加一个新节点(以防现有节点上没有足够的资源)。

Kubernetes 横向扩展

[](https://res.cloudinary.com/practicaldev/image/fetch/s--It6k1Bba--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic.com /blog/wp-content/uploads/2019/08/scaling-kubernetes-out.png)

Kubernetes 扩展 _

[中扩展 kubernetes ](https://res.cloudinary.com/practicaldev/image/fetch/s--Yd_pvkFm--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic.com /blog/wp-content/uploads/2019/08/scaling-kubernetes-in.png)

最重要的是,您可以在 Kubernetes pod 上设置资源上限。例如,如果您确定某个特定服务的消耗不应超过 1GiB,并且如果这样做存在内存泄漏,则您指示 Kubernetes 在 RAM 利用率达到 1GiB 时终止 pod。一个新的 pod 将自动启动。这使您可以控制 Kubernetes 部署使用的资源。

在 Kubernetes 中托管 WordPress 的生活证明

现在,让我们将现实生活中的应用程序部署到 Kubernetes 集群中,以展示上述所有扩展功能。 WordPress 网站就是一个很好的例子。庞大的 Kubernetes 社区是其最大的优势和采用因素之一,因此很容易找到有关如何部署流行应用程序的教程。来看看官方的WordPress教程(本文为了简单起见选择了非生产部署,您可以使用helm图表部署WordPress)。

完成后,还有一件事要做。我们需要创建一个绑定到 WordPress 服务的 Ingress,因为对 Jelastic Kubernetes 集群中正在运行的应用程序的访问是由 Traefik 反向代理提供的。

创建一个名为 wp-ingress.yaml 的文件,其内容如下:

apiVersion:扩展/v1beta1

种类:入口

元数据:

标签:

应用程序:wordpress

名称:wp

注释:

kubernetes.io/ingress.class:流量

ingress.kubernetes.io/secure-backends:“真”

traefik.frontend.rule.type:PathPrefixStrip

规格:

规则:

• http:路径:

• 路径:/后端:serviceName:wordpress servicePort:80

创建 ingress 后,可以在 https://. 访问 WordPress 站点

[](https://res.cloudinary.com/practicaldev/image/fetch/s--AZ_0JyJF--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic. com/blog/wp-content/uploads/2019/08/scaling-kubernetes-welcome-wordpress.png)

太好了,我们在 Kubernetes 集群中有一个正在运行的 WordPress 实例。让我们为 WordPress 部署创建水平 pod 自动缩放器 (HPA),以确保服务在高负载的情况下始终响应。在您的终端中,运行:

kubectl 自动缩放部署 wordpress --cpu-percentu003d30 --minu003d1 --maxu003d10 -n wp

现在,如果 WordPress pod 开始为所有 pod 使用超过 30% 的 CPU,自动缩放器将修改部署以添加更多 pod 副本,以便内部负载均衡器将请求路由到不同的 pod。当然,选择的值仅用于演示目的,可以根据您的需要进行调整。

下一步是查看 Jelastic Kubernetes 环境的垂直和水平扩展选项。这里有两个主要目标:

• 只为实际使用的资源付费

• 确保 Kubernetes 集群在需要时有备用节点

为了使演示更简单(即更快地耗尽 RAM),让我们将节点配置为使用高达 1.5GiB RAM 和 4.8GHz CPU。单击 Change Environment Topology 并为每个节点设置 Scaling Limit。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--tKJoivoC--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic .com/blog/wp-content/uploads/2019/08/scaling-kubernetes-wordpress-topology-edit.png)

配置自动水平缩放是最后一步。与垂直缩放类似,值被设置为迅速触发以适应此演示的目的。让我们指示 Jelastic 何时添加和删除 Kubernetes 节点。打开_设置>自动水平缩放_和_添加_一组所需的触发器。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--suYWGtG9--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic .com/blog/wp-content/uploads/2019/08/scaling-kubernetes-wordpress-horizontal-scaling.png)

我们来看看内存消耗。 Kubernetes 节点(Workers)使用 8 个小云和另外 4 个可以动态添加的小云,即有一些 RAM 可以调度更多的 pod。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--tarbEEeS--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic. com/blog/wp-content/uploads/2019/08/scaling-kubernetes-workers-added.png)

是时候给 WordPress 网站施加压力了。有多种方法可以发起 HTTP GET 请求。我们将在 WordPress pod 本身执行的 while-true 循环中使用最简单的 wget(wordpress 是一个服务名称,将解析为只能从集群访问的内部 IP):

虽然是真的;做 wget -q -O-http://wordpress;完毕

片刻之后,我们可以从 HPA 中观察到以下数据:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--SIygyqlh--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic.com /blog/wp-content/uploads/2019/08/scaling-kubernetes-hpa.png)

Kubernetes 自动缩放器已修改 WordPress 部署以添加更多副本。预计集群没有足够的 RAM,因此正如 Kubernetes Dashboard 建议的那样,剩余的 5 个 Pod 无法调度:

[](https://res.cloudinary.com/practicaldev/image/fetch/s--IcKVHCcU--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic. com/blog/wp-content/uploads/2019/08/scaling-kubernetes-workers-required.png)

不过,一些 pod 能够启动,因为 Jelastic 将 cloudlets (RAM&CPU) 动态添加到节点。然而,剩下的 2 个小云不足以让至少一个 pod 启动。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--XMFmTLai--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:/ /jelastic.com/blog/wp-content/uploads/2019/08/scaling-kubernetes-lack-resources.png)

这就是魔术开始的地方。由于我们已经配置了自动节点自动伸缩,Jelastic 现在正在添加一个新节点。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--o5OokCFZ--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic .com/blog/wp-content/uploads/2019/08/scaling-kubernetes-automatic-workers-adding.png)

让我们通过运行一个简单的命令_kubectl get nodes_来检查一个新节点是否注册到master

[](https://res.cloudinary.com/practicaldev/image/fetch/s--LPGoIJL7--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic .com/blog/wp-content/uploads/2019/08/scaling-kubernetes-kubectl-get-nodes.png)

片刻之后:

[](https://res.cloudinary.com/practicaldev/image/fetch/s---nWC3rp6--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// jelastic.com/blog/wp-content/uploads/2019/08/scaling-kubernetes-new-workers-added.png)

极好的!所有 pod 都已启动,这意味着 WordPress 可以处理我们几分钟前发起的所有传入请求。现在,让我们中止这个while true命令并等待一分钟左右。副本数再次回到 1,这意味着我们不需要额外的节点。

[中扩展 kubernetes 工作人员](https://res.cloudinary.com/practicaldev/image/fetch/s--H9UR77c5--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic .com/blog/wp-content/uploads/2019/08/scaling-kubernetes-workers-scaled-in.png)

内存利用率数字表明可以删除该节点。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--Xjn47Ir2--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /jelastic.com/blog/wp-content/uploads/2019/08/scaling-kubernetes-have-resources.png)

Jelastic 确实在大约一分钟内将其移除。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--pVRl19Wv--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /jelastic.com/blog/wp-content/uploads/2019/08/scaling-kubernetes-remove-worker.png)

我们刚刚见证了什么?让我们回顾一下。为 WordPress 部署创建 HPA 会启动更多 pod 副本的调度以处理高负载。由应用程序管理员配置触发器。接下来,Jelastic 在节点内动态分配 RAM。如果 RAM 用完,则会将一个新节点添加到集群中。当资源利用率恢复正常时,HPA 将副本计数设置回 1,并且 Jelastic 删除一个节点。当 HPA 再次扩大部署时,Jelastic 会做出相应的反应。任何时候都不会使用额外的 RAM!没有停机时间!

[](https://res.cloudinary.com/practicaldev/image/fetch/s--pDzenhM9--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://jelastic.com /blog/wp-content/uploads/2019/08/scaling-kubernetes-summary.png)

Jelastic 中的 Kubernetes 集群在集群(基础架构)和应用程序(部署/Pod)级别有如此多的扩展选项,它成为一个智能平台,可以根据您的应用程序工作负载增长或缩小。 Kubernetes 甚至会检查您的应用程序是否启动并运行,并在必要时重新部署应用程序,并在使用新映像更新应用程序时以零停机时间重新部署它,这使得持续交付成为现实,而不仅仅是流行语。在Jelastic 公共云服务提供商之一尝试自己或请求使用 Kubernetes 集群安装私有云。