阿里云上弹性伸缩kubernetes集群 - autoscaler

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 阿里云Kubernetes服务简化了K8S集群的创建、升级和手动扩缩容。然而使用Kubernetes集群经常问到的一个问题是,我应该保持多大的节点规模来满足应用需求呢? Autoscaler的出现解决了这个问题,它可以自动的根据部署的应用所请求的资源量来动态的伸缩集群。

阿里云Kubernetes服务简化了K8S集群的创建、升级和手动扩缩容。然而使用Kubernetes集群经常问到的一个问题是,我应该保持多大的节点规模来满足应用需求呢? Autoscaler的出现解决了这个问题,它可以自动的根据部署的应用所请求的资源量来动态的伸缩集群。

tips: 一个好的实践是显示的为你的每个应用指定资源请求的值request.

前置条件

为了实现集群规模的自动扩展,需要完成以下工作。

    1. 使用阿里云Kubernete服务在阿里云某个Region创建一个kubernetes集群,这里以杭州Region为例。
    1. 在相应的Region(示例杭州)创建ESS弹性伸缩实例,并配置。

获取kubernetes集群的添加节点命令

为了使得ESS实例节点可以动态加入Kubernetes集群,我们需要获取Kubernetes集群添加节点命令作为,ESS伸缩组的userdata数据。
进入上一步创建好的Kubernetes集群的管理控制台,选择刚刚创建的集群,点击[更多]->[添加已有节点]:
image

拷贝黑框中的内容备用:

curl http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/pkg/run/attach/attach_node.sh | bash -s -- --docker-version 17.06.2-ce-1 --token 9e3606.1de6xxxxxxxx9a9 --endpoint 192.168.223.87:6443 --cluster-dns 172.19.0.10

ESS 需要这段脚本来初始化新扩展出来的节点。

创建ESS实例。

自动扩展kubernetes集群需要阿里云ESS(弹性伸缩组)的支持,因此需要先创建一个ESS。
进入ESS控制台. 选择杭州Region(和kubernetes集群所在region保持一致),点击【创建伸缩组】,在弹出的对话框中填写相应信息,注意网络类型选择专有网络,并且专有网络选择前置条件1中的Kubernetes集群的vpc网络名,然后选择一个vswitch,然后提交。如下图:

image

注意:
这里的VPC网络的选择一定要是前面创建的kubernetes集群所使用的VPC网络,可以进入容器服务kubernetes集群控制台,选择该集群,点击管理,查看该VPC信息,如下图:
image

最后记录刚刚创建的伸缩组的名字,格式为regionid.ess_group_name, eg. cn-hangzhou.kubernetes-hangzhou-group,这个名字在配置autoscaler的时候会用上。

创建伸缩配置项

选择刚才创建的伸缩组,点击添加[伸缩配置], 选择实例规格、安全组(和kubernetes集群同属于一个安全组)、带宽峰值选择0(不分配公网IP)、公共镜像选择centos 7.4、设置云盘大小, 最后设置用户数据。
image

image

注意用户数据选择【使用文本形式】,同时将获取kubernetes集群的添加节点命令粘贴到该文本框中,并在之前添加#!/bin/bashyum clean all。 下面是一个用户数据的示例,替换成你自己的:

#!/bin/bash
yum clean all
curl http://aliacs-k8s-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/public/pkg/run/attach/attach_node.sh | bash -s -- --docker-version 17.06.2-ce-1 --token 9e3606.1de6xxxxxxxx9a9 --endpoint 192.168.223.87:6443 --cluster-dns 172.19.0.10

然后完成创建,启用配置。

部署Autoscaler到kubernetes集群中

由于autoscaler会调用阿里云ESS api来触发集群规模调整,因此需要配置api 访问的accesskey。 同时需要手动指定上面刚刚创建伸缩组,格式为regionid.ess_group_name, 上面示例:cn-hangzhou.kubernetes-hangzhou-group

创建AutoScaler kubernetes deployment。 所有命令均在其中一台master上面执行。

[root@iZbuZ autoscale]# export ACCESS_KEY=<replace with your own key> \
                            ACCESS_SECRET=<replace with your own>
[root@iZbuZ autoscale]# export AUTO_SCALER_GROUP=<replace with above group name>
[root@iZbuZ autoscale]# kubectl create secret generic cloud-config \
                            -n kube-system \
                            --from-literal=access-key-id="${ACCESS_KEY}" \
                            --from-literal=access-key-secret="${ACCESS_SECRET}"
[root@iZbuZ autoscale]#            
[root@iZbuZ autoscale]# cat <<EOF | kubectl apply -f -
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
  labels:
    app: cluster-autoscaler
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cluster-autoscaler
  template:
    metadata:
      labels:
        app: cluster-autoscaler
    spec:
      serviceAccountName: admin
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/google-containers/cluster-autoscaler:v1.1.0
          name: cluster-autoscaler
          resources:
            limits:
              cpu: 100m
              memory: 300Mi
            requests:
              cpu: 100m
              memory: 300Mi
          command:
            - ./cluster-autoscaler
            - --v=4
            - --stderrthreshold=info
            - --cloud-provider=alicloud
            - --skip-nodes-with-local-storage=false
            - --nodes=1:100:${AUTO_SCALER_GROUP}
          env:
          - name: ACCESS_KEY_ID
            valueFrom:
              secretKeyRef:
                name: cloud-config
                key: access-key-id
          - name: ACCESS_KEY_SECRET
            valueFrom:
              secretKeyRef:
                name: cloud-config
                key: access-key-secret
          imagePullPolicy: "Always"
EOF

[root@iZbuZ autoscale]# kubectl get deploy -n kube-system cluster-autoscaler
NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
cluster-autoscaler   1         1         1            1           17h

完成创建。

测试自动扩展节点效果

Autoscaler根据用户应用的资源静态请求量来决定是否扩展集群大小,因此请设置好应用的资源请求量。

测试前节点数量如下,配置均为2核4G ECS,其中两个节点可调度。

[root@iZbuZ ~]# kubectl get no
NAME                                 STATUS    ROLES     AGE       VERSION
cn-hangzhou.i-bp12xhp8qv06m48u6j6q   Ready     <none>    1d        v1.8.4
cn-hangzhou.i-bp13sdsyk6zszfotf49x   Ready     master    1d        v1.8.4
cn-hangzhou.i-bp16808sbruko78l8j96   Ready     <none>    1d        v1.8.4
cn-hangzhou.i-bp1bb7xjnbyxmxska58u   Ready     master    1d        v1.8.4
cn-hangzhou.i-bp1bhan5nqzh8vfk08qb   Ready     master    1d        v1.8.4

接下来我们创建一个副本nginx deployment, 指定每个nginx副本需要消耗1核1G内存。

[root@iZbuZ ~]# cat <<EOF | kubectl apply -f -
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  replicas: 1
  template:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        resources:
          requests:
            cpu: "1"
            memory: 1Gi
EOF

[root@iZbuZ ~]# kubectl get po
NAME                    READY     STATUS    RESTARTS   AGE
http-svc-wpxgj          1/1       Running   0          1d
http-svc-z9hjv          1/1       Running   0          1d
nginx-9d9b56898-xvkkm   1/1       Running   0          18h

看到由于有足够的cpu内存资源,所以pod能够正常调度。接下来我们使用kubectl scale 命令来扩展副本数量到4个。

[root@iZbuZ ~]# kubectl scale deploy nginx --replicas 4 
[root@iZbuZ ~]# kubectl get po
NAME                    READY     STATUS    RESTARTS   AGE
http-svc-wpxgj          1/1       Running   0          1d
http-svc-z9hjv          1/1       Running   0          1d
nginx-9d9b56898-jphgw   1/1       Running   0          18h
nginx-9d9b56898-p92lk   1/1       pending   0          20s
nginx-9d9b56898-sbrp6   1/1       pending   0          20s
nginx-9d9b56898-xvkkm   1/1       Running   0          18h
[root@iZbuZ ~]# kubectl describe po nginx-9d9b56898-p92lk |grep -A 4 Event

发现由于没有足够的cpu内存资源,该pod无法被调度(pod 处于pending状态)。这时候autoscaler会介入,尝试创建一个新的节点来让pod可以被调度。接下来我们执行一个watch kubectl get no的命令来监视node的添加。大约几分钟后,就有新的节点添加进来了

[root@iZbuZ ~]# watch kubectl get no
Every 2.0s: kubectl get no                                                                                                                                       
NAME                                 STATUS    ROLES     AGE       VERSION
cn-hangzhou.i-bp12xhp8qv06m48u6j6q   Ready     <none>    1d        v1.8.4
cn-hangzhou.i-bp13sdsyk6zszfotf49x   Ready     master    1d        v1.8.4
cn-hangzhou.i-bp16808sbruko78l8j96   Ready     <none>    1d        v1.8.4
cn-hangzhou.i-bp17cnn1s5fxh5aeujii   Ready     <none>    1m        v1.8.4
cn-hangzhou.i-bp1bb7xjnbyxmxska58u   Ready     master    1d        v1.8.4
cn-hangzhou.i-bp1bhan5nqzh8vfk08qb   Ready     master    1d        v1.8.4

[root@iZbuZ ~]# kubectl get po
NAME                    READY     STATUS    RESTARTS   AGE
http-svc-wpxgj          1/1       Running   0          1d
http-svc-z9hjv          1/1       Running   0          1d
nginx-9d9b56898-jphgw   1/1       Running   0          18h
nginx-9d9b56898-p92lk   1/1       Running   0          2m
nginx-9d9b56898-sbrp6   1/1       Running   0          2m
nginx-9d9b56898-xvkkm   1/1       Running   0          18h

可以观察到比测试前新增了一个节点,并且pod也正常调度了。

测试自动收缩节点数量

当Autoscaler发现通过调整Pod分布时可以空闲出多余的node的时候,会执行节点移除操作。这个操作不会立即执行,通常设置了一个冷却时间,300s左右才会执行scale down。
通过kubectl scale 来调整nginx副本数量到1个,观察集群节点的变化。

[root@iZbuZ ~]# kubectl scale deploy nginx --replicas 1
[root@iZbuZ ~]# watch kubectl get no
Every 2.0s: kubectl get no                                                                                                                                       
NAME                                 STATUS    ROLES     AGE       VERSION
cn-hangzhou.i-bp12xhp8qv06m48u6j6q   Ready     <none>    1d        v1.8.4
cn-hangzhou.i-bp13sdsyk6zszfotf49x   Ready     master    1d        v1.8.4
cn-hangzhou.i-bp16808sbruko78l8j96   Ready     <none>    1d        v1.8.4
cn-hangzhou.i-bp1bb7xjnbyxmxska58u   Ready     master    1d        v1.8.4
cn-hangzhou.i-bp1bhan5nqzh8vfk08qb   Ready     master    1d        v1.8.4

总结

Autoscaler会作为一个开源工具独立使用,阿里云Kubernetes服务也将进一步简化弹性伸缩的用户体验,将弹性计算和Kubernetes集群管理完美结合在一起。也欢迎您的意见和建议,帮助我们迭代产品能力。

阿里云Kubernetes服务 全球首批通过Kubernetes一致性认证,简化了Kubernetes集群生命周期管理,内置了与阿里云产品集成,也将进一步简化Kubernetes的开发者体验,帮助用户关注云端应用价值创新。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
ACK One 的多集群应用分发,可以最小成本地结合您已有的单集群 CD 系统,无需对原先应用资源 YAML 进行修改,即可快速构建成多集群的 CD 系统,并同时获得强大的多集群资源调度和分发的能力。
151 9
|
4月前
|
资源调度 Kubernetes 调度
从单集群到多集群的快速无损转型:ACK One 多集群应用分发
本文介绍如何利用阿里云的分布式云容器平台ACK One的多集群应用分发功能,结合云效CD能力,快速将单集群CD系统升级为多集群CD系统。通过增加分发策略(PropagationPolicy)和差异化策略(OverridePolicy),并修改单集群kubeconfig为舰队kubeconfig,可实现无损改造。该方案具备多地域多集群智能资源调度、重调度及故障迁移等能力,帮助用户提升业务效率与可靠性。
|
6月前
|
存储 Kubernetes 监控
K8s集群实战:使用kubeadm和kuboard部署Kubernetes集群
总之,使用kubeadm和kuboard部署K8s集群就像回归童年一样,简单又有趣。不要忘记,技术是为人服务的,用K8s集群操控云端资源,我们不过是想在复杂的世界找寻简单。尽管部署过程可能遇到困难,但朝着简化复杂的目标,我们就能找到意义和乐趣。希望你也能利用这些工具,找到你的乐趣,满足你的需求。
596 33
|
6月前
|
Kubernetes 开发者 Docker
集群部署:使用Rancher部署Kubernetes集群。
以上就是使用 Rancher 部署 Kubernetes 集群的流程。使用 Rancher 和 Kubernetes,开发者可以受益于灵活性和可扩展性,允许他们在多种环境中运行多种应用,同时利用自动化工具使工作负载更加高效。
340 19
|
6月前
|
人工智能 分布式计算 调度
打破资源边界、告别资源浪费:ACK One 多集群Spark和AI作业调度
ACK One多集群Spark作业调度,可以帮助您在不影响集群中正在运行的在线业务的前提下,打破资源边界,根据各集群实际剩余资源来进行调度,最大化您多集群中闲置资源的利用率。
|
7月前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
ACK One注册集群已正式支持ACS(容器计算服务)算力,为企业的容器化工作负载提供更多选择和更强大的计算能力。
|
7月前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
218 10
|
7月前
|
Kubernetes 监控 Serverless
基于阿里云Serverless Kubernetes(ASK)的无服务器架构设计与实践
无服务器架构(Serverless Architecture)在云原生技术中备受关注,开发者只需专注于业务逻辑,无需管理服务器。阿里云Serverless Kubernetes(ASK)是基于Kubernetes的托管服务,提供极致弹性和按需付费能力。本文深入探讨如何使用ASK设计和实现无服务器架构,涵盖事件驱动、自动扩展、无状态设计、监控与日志及成本优化等方面,并通过图片处理服务案例展示具体实践,帮助构建高效可靠的无服务器应用。
|
7月前
|
边缘计算 调度 对象存储
部署DeepSeek但IDC GPU不足,阿里云ACK Edge虚拟节点来帮忙
介绍如何使用ACK Edge与虚拟节点满足DeepSeek部署的弹性需求。
|
7月前
|
Kubernetes 持续交付 开发工具
阿里云协同万兴科技落地ACK One GitOps方案,全球多机房应用自动化发布,效率提升50%
阿里云协同万兴科技落地ACK One GitOps方案,全球多机房应用自动化发布,效率提升50%
189 2

相关产品

  • 容器服务Kubernetes版
  • 推荐镜像

    更多