Kubernetes 应用的自动水平扩容|学习笔记(二)

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
简介: 快速学习Kubernetes 应用的自动水平扩容

开发者学堂课程【Kubernetes 云原生管理实践Kubernetes 应用的自动水平扩容】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/751/detail/13221


Kubernetes 应用的自动水平扩容

 

内容介绍:

二、KEDA 的介绍


二、KEDA 的介绍

1、微软做的一个开源项目叫做 KEDAKEDA Kubernetes-based Event Driver Autoscaler,是对原生 HPA 的扩展,是基于原生 HPAAPI 还是符合 HPA API 的。但是他进行了扩展,为什么进行扩展?是因为很多业务比较复杂,扩缩容的原理或原则不是靠 CPU,或者是靠内存可以解决的。比如说有些应用,用义务通信的方式,反应式的编辑造成了他本身的 CPU、内存上面看不出来它有多大的变化,但是他响应的速度和时间会有很大的差异。在这种情况下,用原生的 HPA 是不够的。

 

2、例子用的是在 scaler 里面有一个,基于普罗米修斯收集应用。

 image.png

 

这是普罗米修斯可收集的一些数据,进行采样,然后设置一些策略进行扩容。怎么把 scaler 作为 OAM trait 用,把它绑定到应用上。在这个过程中,这种操作或这种应用定义的方式,跟传统的或经常看到的 Kubernetes 对于应用的定义或者介绍是有巨大的不同的。例子如下。

 

3##Install Keda

helm install keda keda/keda

##Install OAM

kubectl create namespace oam-system

helm install oam--namespace oam-system crossplane-master/oam-kubernetes-runtime--devel

##Install prometheus

kubectl apply-f prometheus. yaml

##Create application

kubectl apply-f Components/go-prom. yaml

kubectl apply-f definitions/kedahpa. yaml

kubectl apply-f appconfig/demo1. yaml

##Generate load

kubectl apply-f frontend. yaml

kubectl exec--stdin--tty front-end-xxxxx--/bin/bash

curl-o hey https://storage.googleapis.com/hey-release/hey _ linux _ and 64&&chmod a+x hey ./hey-n 2000 http://go-prom-app-v1:8080/test

kubect1 get pods-w

 

第一步装 keda,然后装 oam。这有一个 minikube,可以用任何集群,只要是标准的 Kubernetes 集群。在安装过程中看一下 keda 项目,项目叫 Event driven


image.png

业务会产生一些事件驱动的流量,根据事件的驱动来进行扩缩容,道理很简单,关键是生态的建设。keda 做很多小的组件,给用户使用,这与 OAM 的设计是非常契合的。OAM 希望大家有自己的 trait,绑定到应用的组件上,用这种方式扩展云原生的功能和能力。keda 社区有很多 scaler,基于流量事件来进行监听。


image.png

4keda 安装完成,下一步装 OAM OAM分两步,第一步是创建一个 namespace。有一个 runtime,大项目叫 crossplanecrossplan CNCF 里面的 send boxOAM是在 crossplane 下的实现。crossplane 最早提出对 OAM 概念进行实现,OAM 现在是 crossplane 的一部分。大家可以吧 runtime 想成 SDK,在 SDK 的基础上开发一些新的功能,这些应用和组件在 OAM 的项目下,不是在 crossplane 的下。现在 OAM runtime 也部署完成,接下来安装 prometheusprometheus 在云上有各种不同的版本,我们使用的是比较基础、为这个项目定制的版本。下一步安装 components trait definition

image.png

 

这是 KEDA CRD,他的名字叫 scaledobjects.keda ,给它定义了一个 trait。给大家演示的例子相当于是搬运来的,没有进行任何改造。trait 在定义上有一定要求,一般要按照 OAM 的规范开发 trait,用户的清澈度各方面都会好很多。但是为了保证 trait 最大化的兼容,已有的 CRD,也有照搬的能力。

 

5component 在这个文件里,我把两个放在了一起,一个是先定义 workload,定义 containerizedworkload,就是把 deployment service 放在一起,这样就不用写两遍了,写两遍很麻烦,这两个放在一起是非常好的。

image.png

 

定义 containerizedworkload 以后,下面定义 componentComponents 引用他的 kind,类型是 containerizedworkload,在 spec 定义下,只有业务代码关心的内容。

spec:

containers:

-name:go-prom-app

image:szihai/okod:v1

imagePullPolicy:Always

ports:

-name:http

containerPort: 8080

其他运维的内容没有写在这里,跟 deployment 相比, components 定义简单很多。名字 go-prom-app-v1 只用了一次,这个也很重要,如果名字对不上,是一件很麻烦的事情。这就是 trait component 这两部分。

 

6、下一步是把他们绑在一起,Components 名字是 go-prom-app-v1 ,定义完以后,把 trait 放在下面,trait 有好几个,不只是一个,下面是他的定义。

traits:

-trait:

apiVersion:keda.k8s. io/v1alpha1

kind:Scaled0bject

metadata:

name:prometheus-scaledobject

namespace:default

labels:

deploymentName:go-prom-app-v1

因为这个定义是搬运过来的,效果不是很好,如果他经过改造或包装,声明的内容可以都不要了。只剩下核心的 spec 这部分。

image.png

 

这部分是策略,是没办法舍弃的。先声明一下 components trait,接下来再来定义应用 demo1Workload 包括两部分 deployment Service,因为现在没有流量,他只是创建完成了。keda abletoscale 也是符合 HPA API 的,

image.png

 

但他只是注册上去,并没有逻辑,真正的业务逻辑是在这个 CRD 运行,这就是基本的情况。

image.png

 

7、接下来加载流量,用另外一个容器进行操作。有一个叫做 fronted 的小容器,在集群里面操作。为什么用这种方式?实验里面都会创建一个 ingress 等,但很多时候,应用并不一定非有这些东西,做演示的那些软件往往为了显示自己的功能,会把所有的东西拉满,但实际应用的时候没有这么多东西,在这种情况下尽量缩减。这是非常简单的例子,现在进入 forn- end 里面,把ID 7b949dd5f4-bnt7s 复制进去。进来以后需要下载一个工具叫 hey,他会在短期内产生流量,接下来用 hey 对它进行操作。启用之后它会不断地对流量进行扩容。

image.png

 

keda 这个项目已经测试过,不是测扩容和缩容这件事,

以上内容主要是用 OAM,用 touchtraitcomponent 的方式来进行扩容或缩容,比传统的以平台或集群的角度来做这件事情容易很多。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
1月前
|
缓存 Kubernetes Docker
GitLab Runner 全面解析:Kubernetes 环境下的应用
GitLab Runner 是 GitLab CI/CD 的核心组件,负责执行由 `.gitlab-ci.yml` 定义的任务。它支持多种执行方式(如 Shell、Docker、Kubernetes),可在不同环境中运行作业。本文详细介绍了 GitLab Runner 的基本概念、功能特点及使用方法,重点探讨了流水线缓存(以 Python 项目为例)和构建镜像的应用,特别是在 Kubernetes 环境中的配置与优化。通过合理配置缓存和镜像构建,能够显著提升 CI/CD 流水线的效率和可靠性,助力开发团队实现持续集成与交付的目标。
|
1天前
|
Kubernetes 持续交付 开发工具
阿里云协同万兴科技落地ACK One GitOps方案,全球多机房应用自动化发布,效率提升50%
阿里云协同万兴科技落地ACK One GitOps方案,全球多机房应用自动化发布,效率提升50%
|
29天前
|
存储 监控 对象存储
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
针对本地存储和 PVC 这两种容器存储使用方式,我们对 ACK 的容器存储监控功能进行了全新升级。此次更新完善了对集群中不同存储类型的监控能力,不仅对之前已有的监控大盘进行了优化,还针对不同的云存储类型,上线了全新的监控大盘,确保用户能够更好地理解和管理容器业务应用的存储资源。
117 21
|
1月前
|
存储 监控 对象存储
ACK容器监控存储全面更新:让您的应用运行更稳定、更透明
介绍升级之后的ACK容器监控体系,包括各大盘界面展示和概要介绍。
|
2月前
|
人工智能 Kubernetes 安全
赋能加速AI应用交付,F5 BIG-IP Next for Kubernetes方案解读
赋能加速AI应用交付,F5 BIG-IP Next for Kubernetes方案解读
82 13
|
2月前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
|
3月前
|
存储 运维 Kubernetes
K8s业务迁移最佳实践: 灵活管理资源备份与调整策略,实现高效简便的应用恢复
在当今快速变化的云原生领域,Kubernetes(K8s)集群的运维面临着诸多挑战,其中灾备与业务迁移尤为关键。ACK备份中心支持丰富的资源调整策略,在数据恢复阶段即可自动适配目标集群环境,确保业务无缝重启。
|
3月前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
3月前
|
Kubernetes 监控 安全
容器化技术:Docker与Kubernetes的实战应用
容器化技术:Docker与Kubernetes的实战应用
|
3月前
|
Java Docker 微服务
利用Docker容器化部署Spring Boot应用
利用Docker容器化部署Spring Boot应用
72 0

热门文章

最新文章