容器化Java程序秒级弹性伸缩实践

HelloGeekCsdn

已于 2024-04-18 14:50:29 修改

阅读量295

点赞数 5

分类专栏： Kubernetes 文章标签：云原生微服务 kubernetes 容器弹性伸缩

于 2024-04-18 14:47:21 首次发布

本文链接：https://blog.csdn.net/happy_85/article/details/137921391

版权

Kubernetes 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

当前许多数字化转型企业都会将自己的系统微服务化、容器化，这些技术和策略可以帮助企业更有效地利用资源、提高开发运维效率，并且在处理不同流量场景下保证系统的稳定性和性能。

弹性扩缩容

在虚拟机时代，资源的占用和维护成本较高，因为承载容量是固定的，导致了大量资源的闲置。而在容器时代，借助开源的Kubernetes等方案，我们可以更灵活地利用资源，根据需要动态调整资源的分配。弹性伸缩涉及到的相关技术解决方案：HPA、无损上线、无损下线、秒级启动。

水平Pod自动伸缩（HAP Horizontal Pod Autoscaling）

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: your-java-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: your-java-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 50

上面的例子，是将CPU利用率配置为50%，根据应用程序的负载情况，Kubernetes将自动调整Pod的副本数，最小1个，最大10个pod。除了CPU，还可以使用内存和一些结合监控扩展的自定义指标。

通过HPA技术，不需要那么谨慎的为业务系统分配固定资源。比如之前的业务系统分配的CPU有为4核，但日常使用率仅20%，那这时我们可以给他分配2核，理论上CPU使用率就提升到了40%左右，当遇到CPU升高时可以通过扩容解决，这样能有效解决资源利用率使用过低问题。

无损上线

在小流量场景下，一般不会在调⽤时出现 Connection refused 和 No instance 等现象，但在流量高峰需要扩容时类似问题会比较明显。一般的解决方式是小流量预热。⼩流量预热⽅法主要是通过在服务消费端根据各个服务提供者实例的启动时间计算权重，结合负载均衡算法控制刚启动应⽤流量，随启动时间逐渐递增到正常⽔平，如下图所示。

将⾃身的预热时⻓和服务启动时长为参数，通过⼩流量服务预热模型计算公式进行权重流量分配，感兴趣的可以参考开源Dubbo的技术实现。

无损下线

虚机场景

虚机场景下的无损下线只需要注意服务下线时新流量不在进入和已进入系统流量处理完毕，就能保证服务下线流量无损，具体步骤见下图。

• 主动注销我们应用服务下线前，主动通知注册中心注销该实例；

• 通知下线信息我们会在服务端实例下线前主动通知客户端，该服务节点下线的信息

• 调用其他提供者我们在客户端增强其负载均衡能力，在服务端下线后，客户端主动调用其他服务提供者节点。

容器场景

服务的启停不只是系统进程启停，涉及到Pod的生命周期，下面是一个pod的简单生命周期。

1. 新建pod：通过Kubernetes调度器，调度到合适的服务器中，并准备所需的算力、存储和网络等基础资源；

2. 拉取业务系统镜像：拉取业务系统Docker镜像，拉取镜像的时间取决于网络、镜像大小和是否用到P2P加速镜像拉取技术；

3. 启动业务系统：启动业务服务进程，目前行内微服务采用的是基于Java语言的Spring Cloud微服务技术，为了提升开发效率，Spring Cloud集成了大量的开源组件，加之业务系统代码及其所依赖的大量第三方组件，Web容器启动时需要加载大量上述组件，并通过Spring维护其复杂的关联关系；

4. 启动健康检查：主要目的是确保pod健康，若业务应用配置为1分钟，则在容器启动1分钟后开始进行Liveness健康检查，如果探测连续超过一定的失败次数，Kubernetes会认为服务不可用，pod会被销毁并重建。在滚动发布场景下，当一个pod的Liveness探活成功后，才能开始下一个节点的发布，可以把健康检查-启动时间改为第1分钟（具体要结合各个业务系统自身的启动时间来定），增加每30秒探活一次，失败3次后重启（结合业务系统测试而定），这样可以缩短整个版本滚动发布时长。

5. 容器优雅终止：当接到删除pod命令时，Kubernetes会给pod中容器一定的时间优雅停止，并触发preStop钩子执行微服务无损下线脚本（适用于配置有无损下线脚本微服务），实现流量无损下线。目前默认是30秒，设定时间越长越能保证流量完全无损下线，但整体滚动发版时间会被拉长，具体还需要根据业务自身情况设定；

6. 销毁pod：Kubernetes对算力、存储和网络等基础资源的释放。若应用配置固定IP，销毁pod则需要约8秒。

所以在基于Kubernetes的容器场景下，关闭一个系统是关闭一个pod，并且还需要在容器中添加钩子配置，调用系统优雅下线功能，需要注意的是容器最终宽限期terminationGracePeriodPeriods的时长大于优雅下线的时长，否则会被强制销毁。