你必知的 Kubernetes 自动缩放-低调大师

你必知的 Kubernetes 自动缩放

2019-09-29 707

作者：Juan Ignacio Giro 译者：段访审校：罗广明原文： https://caylent.com/kubernetes-autoscaling

编者按

许多Kubernetes用户，特别是那些企业级用户，很快就遇到了对环境自动缩放的需求。幸运的是，Kubernetes Horizontal Pod Autoscaler（HPA）允许您将部署配置为以多种方式水平扩展。使用Kubernetes Autoscaling的最大优势之一是您的集群可以跟踪现有Pod的负载能力，并计算是否需要更多的Pod。

Kubernetes Autoscaling

通过协调内置的两层可扩展性，可以充分利用高效的Kubernetes Autoscaling：

Pod级别的自动缩放：包括Horizontal Pod Autoscaler（HPA）和Vertical Pod Autoscaler（VPA）; 两者都可以扩展容器的可用资源。
集群级别的自动缩放：集群自动调节器（CA）通过在必要时向上或向下扩展集群内的节点数来管理这种可扩展性平面。

Kubernetes Autoscaling 详情

Horizontal Pod Autoscaler（HPA）

HPA会在集群中缩放Pod副本的数量。该操作由CPU或内存触发，以根据需要向上或向下扩展。但是，也可以根据各种外部的和自定义指标（metrics.k8s.io，external.metrics.k8s.io和custom.metrics.k8s.io）来配置HPA以扩展Pod。

Vertical Pod Autoscaler（VPA）

VPA主要用于有状态服务，它可根据需要为Pod添加CPU或内存——它也适用于无状态的Pod。为了应用这些更改，VPA重新启动Pod以更新新的CPU和内存资源，这些资源可以配置为响应OOM（内存不足）事件而启动。重新启动Pod的时候，VPA始终确保根据Pod分配预算（PDB）确定最小数量，您可以设置该资源分配最大和最小速率。

Cluster Autoscaler（CA）

第二层的自动缩放涉及CA，它在以下情况下自动调整集群的大小：

由于集群中的容量不足，任何Pod/s都无法运行并进入挂起状态（在这种情况下，CA将向上扩展）。
集群中的节点在一段时间内未得到充分利用，并且有可能迁移节点上的Pod（在这种情况下，CA将缩小）。

CA进行例行检查以确定是否有任何pod因等待额外资源处于待定状态，或者集群节点是否未得到充分利用。如果需要更多资源，会相应地调整Cluster节点的数量。CA与云提供商交互以请求其他节点或关闭空闲节点，并确保按比例放大的集群保持在用户设置的限制范围内。它适用于AWS，Azure和GCP。

将HPA和CA与Amazon EKS配合使用的5个步骤

本文提供了通过适用于Kubernetes（Amazon EKS）集群的Amazon Elastic容器服务，通过HPA和CA安装和自动扩展的分步指南。以下指南是两个测试用例示例：

集群要求

满足EKS集群要求的Amazon VPC 和一个安全组。
或者，为免手动创建VPC，AWS提供了创建了VPC和EKS的CloudFormation模板

CloudFormation YAML文件

应用到集群的EKS 角色

1. 根据官方指南创建一个AWS EKS 集群(控制面板和和工作节点). 一旦你把工作节点以auto scaling group的形式启动了，它们会自动向EKS集群注册，你就可以开始部署k8s应用了。

2. 部署度量服务器以便HPA能够根据API提供的CPU/内存数据自动缩放POD副本的数量。 metrics.k8s.io api 通常由metrics-server（负责从summary api收集cpu和内存度量）提供。

3. 把以下策略应用到EKS创建的worker节点的Role上

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "autoscaling:DescribeAutoScalingGroups",
            "autoscaling:DescribeAutoScalingInstances",
            "autoscaling:DescribeLaunchConfigurations",
            "autoscaling:DescribeTags",
            "autoscaling:SetDesiredCapacity",
            "autoscaling:TerminateInstanceInAutoScalingGroup"
         ],
         "Resource": "*"
      }
   ]
}

4. 部署k8s CA特性

根据你使用的linux发行版，你可能需要更新部署文件和证书路径。例如，如果使用AMI Linux，需要用/etc/ssl/certs/ca-bundle.crt替换/etc/ssl/certs/ca-certificates.crt

5. 更新CA的部署YAML文件，找到指定的AWS AG（k8s.io/cluster-autoscaler/<CLUSTER NAME>应该包含真实的集群名称）标签。同时更新AWS_REGION环境变量。

把以下tag添加到 AWS AG，以便 k8s 的 cluster autoscaler 能够自动识别 AWS AG：

k8s.io/cluster-autoscaler/enabled k8s.io/cluster-autoscaler/

Kubernetes Autoscaling 测试用例 #1

测试k8s hpa 特性和k8s ca 特性同时使用

要求:

一个运行中的eks集群
安装好metric server
安装了k8s cluster autoscaler 特性

1. 部署一个测试app，为app部署创建HPA资源。

2. 从不同的地理位置发起请求以增加负载。

3. HPA 应该会随着负载的增加开始缩放pod的数量。它会根据hpa资源指定的进行缩放的。在某一时刻，新的POD在等待其他资源的时候会是等待状态。

$ kubectl get nodes -w
NAME                             STATUS    ROLES     AGE       VERSION
ip-192-168-189-29.ec2.internal   Ready         1h        v1.10.3
ip-192-168-200-20.ec2.internal   Ready         1h        v1.10.3

$ kubectl get Pods -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE
ip-192-168-200-20.ec2.internal
php-apache-8699449574-4mg7w 0/1 Pending 0 17m
php-apache-8699449574-64zkm 1/1 Running 0 1h 192.168.210.90 ip-192-168-200-20
php-apache-8699449574-8nqwk 0/1 Pending 0 17m
php-apache-8699449574-cl8lj 1/1 Running 0 27m 192.168.172.71 ip-192-168-189-29
php-apache-8699449574-cpzdn 1/1 Running 0 17m 192.168.219.71 ip-192-168-200-20
php-apache-8699449574-dn9tb 0/1 Pending 0 17m
...

4. CA 检测到因为容量不足而进入等待状态的pods，调整AWS 自动缩放组的大小。一个新的节点加入了:

$ kubectl get nodes -w
NAME                                       STATUS    ROLES     AGE       VERSION
ip-192-168-189-29.ec2.internal   Ready         2h        v1.10.3
ip-192-168-200-20.ec2.internal   Ready         2h        v1.10.3
ip-192-168-92-187.ec2.internal   Ready         34s       v1.10.3

5. HPA能够把等待状态的POD调度到新的节点上了。平均cpu使用率低于指定的目标，没有必要再调度新的pod了。

$ kubectl get hpa
NAME         REFERENCE                    TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   40%/50%   2                  25                 20               1h $ kubectl get Pods -o wide -w

$ kubectl get Pods -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE
php-apache-8699449574-4mg7w 1/1 Running 0 25m 192.168.74.4 ip-192-168-92-187
php-apache-8699449574-64zkm 1/1 Running 0 1h 192.168.210.90 ip-192-168-200-20
php-apache-8699449574-8nqwk 1/1 Running 0 25m 192.168.127.85 ip-192-168-92-187
php-apache-8699449574-cl8lj 1/1 Running 0 35m 192.168.172.71 ip-192-168-189-29
...

6. 关闭几个terminal，停掉一些负载

7. CPU平均利用率减小了，所以HPA开始更改部署里的pod副本数量并杀掉一些pods

$ kubectl get hpa
NAME         REFERENCE                     TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   47%/50%     2                20                 7                   1h 

$ kubectl get Pods -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE
...
php-apache-8699449574-v5kwf 1/1 Running 0 36m 192.168.250.0 ip-192-168-200-20
php-apache-8699449574-vl4zj 1/1 Running 0 36m 192.168.242.153 ip-192-168-200-20
php-apache-8699449574-8nqwk 1/1 Terminating 0 26m 192.168.127.85 ip-192-168-92-187
php-apache-8699449574-dn9tb 1/1 Terminating 0 26m 192.168.124.108 ip-192-168-92-187
php-apache-8699449574-k5ngv 1/1 Terminating 0 26m 192.168.108.58 ip-192-168-92-187
...

8. CA 检测到一个节点未充分使用，正在运行的pod能够调度到其他节点上。

$ kubectl get nodes
NAME                             STATUS    ROLES     AGE       VERSION
ip-192-168-189-29.ec2.internal   Ready         2h        v1.10.3
ip-192-168-200-20.ec2.internal   Ready         2h        v1.10.3
ip-192-168-92-187.ec2.internal   NotReady       23m       v1.10.3

$ kubectl get nodes
NAME                             STATUS    ROLES     AGE       VERSION
ip-192-168-189-29.ec2.internal   Ready         2h        v1.10.3
ip-192-168-200-20.ec2.internal   Ready         2h        v1.10.3

9. 在向下缩放的时候，terminal中应该没有明显的timeout

Kubernetes Autoscaling 测试用例 #2

测试在如果没有足够的CPU容量调度pod下，CA是否能够自动调整集群的大小

要求:

一个运行中的aws eks集群
Kubernetes ca 特性已安装

1. 创建2个请求小于1vcpu的deployment

$ kubectl run nginx --image=nginx:latest --requests=cpu=200m
$ kubectl run nginx2 --image=nginx:latest --requests=cpu=200m

2. 创建一个新的deployment，请求比剩余的cpu更多的资源

$ kubectl run nginx3 --image=nginx:latest --requests=cpu=1

3. 新的POD会处于等待状态，因为没有可用的资源：

$ kubectl get Pods -w
NAME                      READY     STATUS    RESTARTS   AGE
nginx-5fcb54784c-lcfht    1/1       Running   0          13m
nginx2-66667bf959-2fmlr   1/1       Running   0          3m
nginx3-564b575974-xcm5t   0/1       Pending   0          41s

描述pod的时候，可能会看到没有足够的cpu的事件

$ kubectl describe Pod nginx3-564b575974-xcm5t
…..
…..
Events:
Type     Reason            Age               From               Message
----     ------            ----              ----               -------
Warning  FailedScheduling  32s (x7 over 1m)  default-scheduler  0/1 nodes are available: 1 Insufficient cpu

4. CA自动调整集群的大小，新加了一个节点

$ kubectl get nodes
NAME                              STATUS    ROLES     AGE       VERSION
ip-192-168-142-179.ec2.internal   Ready         1m        v1.10.3  <<
ip-192-168-82-136.ec2.internal     Ready         1h        v1.10.3

5. 集群现在有了足够的资源以运行pod

$ kubectl get Pods
NAME                      READY     STATUS    RESTARTS   AGE
nginx-5fcb54784c-lcfht    1/1       Running   0          48m
nginx2-66667bf959-2fmlr   1/1       Running   0          37m
nginx3-564b575974-xcm5t   1/1       Running   0          35m

6. 两个部署删除了。一段时间后，CA检测到集群中的一个节点未被充分利用，运行的pod可以安置到其他存在的节点上。AWS AG 更新，节点数量减1。

$ kubectl get nodes
NAME                                      STATUS    ROLES     AGE       VERSION
ip-192-168-82-136.ec2.internal   Ready         1h          v1.10.3 

$ kubectl get Pods -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP                       NODE
nginx-5fcb54784c-lcfht   1/1       Running     0                   1h       192.168.98.139   ip-192-168-82-136

清除环境的步骤：

删除添加到eks worker节点上Role的自定义策略
按照这个指南删除这个集群

参考

其他的关于kubernetes autoscaling，可以阅读Stefan Prodan的文章 Kubernetes Horizontal Pod Autoscaler with Prometheus Custom Metrics。

还有这些链接也可以看看 link1, link2, link3。

关于 ServiceMesher 社区

ServiceMesher 社区是由一群拥有相同价值观和理念的志愿者们共同发起，于 2018 年 4 月正式成立。

社区关注领域有：容器、微服务、Service Mesh、Serverless，拥抱开源和云原生，致力于推动 Service Mesh 在中国的蓬勃发展。

社区官网：https://www.servicemesher.com

微信关注我们

原文链接：https://my.oschina.net/u/3089793/blog/3112509

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

如何使用k3s+树莓派在生产中构建轻量K8S裸机集群

Boogie Software是欧洲著名的金融科技公司，多年来致力于为银行提供Fintech、AI、大数据高性能后端、移动应用程序、数据分析及UX等创新服务，帮助银行推动数字化转型。凭借过去十多年在该领域的独特经验，Boogie已成为数字银行服务提供商中的领导者。本文作者是Boogie Software的资深软件架构师Jari Tenhunen。他拥有超过15年的软件开发经验，擅长信息安全和网络协议。并且长期管理项目和团队，在其中主导软件架构和技术，成功将多个产品推向市场。 Boogie Software的IT团队在很多客户银行的核心银行业务数字化的项目中使用到了Kubernetes和容器技术，因此我们始终在想Kubernetes能如何使用更合适的硬件在本地工作。在本文中，我将详细介绍我们如何在树莓派上构建轻量级裸机集群，以在公司网络中运行应用程序和服务。我们之所以这么做，有两个原因：第一，通过建立集群，我们将可以拥有一个平台，来可靠、灵活地运行公司网络内部应用程序和服务；第二，我们可以通过这次机会学习更多关于Kubernetes、微服务以及容器的技能。如果你也想要参照我们的经验来...

2019-09-29

580

JavaScript 从成立之初就已经走了很长一段路，提供了许多新的功能，这些功能是专门设计来使该语言更加人性化和提升效率。以下是我最近发现的一些有趣的JavaScript 新增内容。其中一些功能已在 Node，Chrome，Firefox 和 Safari 中可用，而其他功能仍处于建议阶段。 Optional chaining （可选链） Optional chaining 可选链使用?.操作符来表示，Optional Chaining 使我们能检查一个对象上面是否存在某属性。其它一些语言有类似的特性。例如 C# 有 Null Conditional 操作符。而 JavaScript 的 Optional chaining 在需要深度访问嵌套对象属性时就特别有用。当我们在访问对象的属性前，我们需要用?.操作符来确定该属性是否存在。首先看看下面代码： const users = [ { name: "Olagunju Gbolahan", occupation: "Software Developer", sayName(){ console.log(`my name i...

2019-09-29

774

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。