K8s自动扩缩容工具KEDA该怎么用

今天就跟大家聊聊有关K8s自动扩缩容工具KEDA该怎么用，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

红帽和微软共同发布了Kubernetes自动扩缩容工具KEDA 1.0，而现在官方强化KEDA的扩缩容器，发布第2个主要更新KEDA 2.0，能支持更多种类的触发器，更方便地自动扩展Kubernetes部署。在今年3月的时候，有越来越多厂商加入对KEDA项目贡献，因此发起厂商决定将KEDA贡献给云原生基金会（Cloud Native Computing Foundation，CNCF），现为CNCF沙盒项目。

KEDA的出现，是要解决Kubernetes自动扩缩容的需求。Kubernetes虽然提供了一个容器调度平台，但是在预设的情况，Kubernetes只能根据CPU等系统指标进行扩缩容，而无视来自Azure、AWS、GCP、Redis和Kafka等大量外部指标，这代表系统响应事件的时间，可能存在大量的延迟，使得扩展不够灵敏，赶不上流量的变化。

而KEDA能够解决这个问题，KEDA是一个以Kubernetes为基础的事件驱动自动扩缩容器，用户可以根据需要处理的事件数量，来驱动Kubernetes中容器的扩展，KEDA提供用户通过使用简单一致的API，就能进行自动扩展部署。

KEDA为一个单一用途的轻量组件，可以被加到Kubernetes集群中，与Horizontal Pod Autoscaler（HPA）等标准Kubernetes组件一起使用，扩展功能不会互相覆盖或是重复，官方提到，用户可以指定要使用事件驱动的应用，而不会影响其他应用，这使得KEDA可以灵活并安全地，与其他Kubernetes应用和框架共同使用。

在KEDA 1.0发布一年之后，现在发布了主要更新2.0正式版，更新重点在于KEDA支持更多的触发器，并且也增加许多新的模式和功能。KEDA 2.0现在可以自动扩展部署负载（Deployment）和作业（Jobs）工作负载，过去在KEDA 1.x的时候，用户需要通过ScaledObject资源，来指定要扩展的工作负载类型，且只能指定扩展Kubernetes部署或是资源其中一种。

而在KEDA 2.0，这两个选项被分开，并且引入独立的资源，除了之前就有的ScaledObject，现在还为Kubernetes增加ScaledJob自定义资源，以满足不同的需求。

另外，用户现在可以在ScaledObject和ScaledJob上，设定多个触发器，并根据例如Kafka和Prometheus等不同的触发器，自动缩放工作负载，KEDA会从扩展器中，挑选像是目标副本数等最大的值，来定义扩展决策。

KEDA 2.0还加入多个新的扩展器，用户除了能使用Azure Log Analytics和IBM MQ扩展器之外，还可应用新的CPU扩展器，不再需要混用HPA和ScaledObjects，KEDA能够完全替用户处理HPA。而且新的外部推送扩展器，允许用户使用推送模型（Push-Model），构建自己的扩展器和触发器扩展行为，而非使用现有的拉取模型（Pull-Model）。

KEDA 2.0还加入新的Metrics API扩展器，能够自动缩放通过REST API提供的指标，让用户不需要建构自己的扩展器，这项新功能可以根据环境中可用的指标标准来源，诸如内部API或是微软Dynamics CRM API等，来自动化缩放决策。

看完上述内容，你们对K8s自动扩缩容工具KEDA该怎么用有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。