K8s+Nacos实现应用的优雅上下线【生产实践】

已于 2024-03-24 12:49:39 修改
阅读量1.4k 收藏 31
点赞数 30
分类专栏： Kubernetes学习分享； 文章标签： kubernetes 容器 云原生
于 2024-03-22 15:33:57 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_44930876/article/details/136898977
版权

`

文章目录

前言

我们在使用k8s部署应用的时候，虽然k8s是使用滚动升级的，先启动一个新Pod 等这个新Pod运行成功后，再干掉旧Pod；在这个过程中Pod会一直接收请求的，如果在Pod被干掉的那一刻正好有一部分请求打进来了，那么Pod被杀死了，就不会给这个请求返回结果，就会导致客户端出现请求500错误，这样就做不到平滑升级了，我们要做的就是在Pod升级的时候不能或者尽量避免这种情况；

我们公司使用的是java，中间件用的是nacos，应用在启动时会注册到nacos，然后走应用之间的内部调用，服务会不间断的向注册中心nacos发送自己的心跳(3s) 以及在每个 Pod 服务里本地也有一份缓存映射表（也有一个窗口时间更新30s），服务在停止的时候，自然也会在nacos中进行下线 但是如果有请求在应用下线的这个窗口期发起的话，就会出现K8s Pod 服务已下线，但是 Nacos 在窗口期之内注册列表未更新，导致请求达到一个根本不存在的旧服务里导致请求返回404或者旧请求已经打到旧服务里，但是高峰期时，程序处理较慢，还没来及返回响应体，服务就被关闭了返回500；

我们使用的解决方案是，在应用下线的第一时间(Pod被删除)先进行在nacos的下线操作不让其接受新的请求，然后等待Pod已接收的请求处理完成后 再进行删除Pod；
这里会使用到的知识以及需要自身考虑的点有：

  • k8s的prestop钩子(容器关闭前执行操作)
  • 需要判断自己应用处理的请求的时间(基本上30s内都能处理完成 如果不放心的话调整成50s 但是这样的话也会相应的增加上线时长，需要注意)
  • 需要在nacos(v2.x)中配置Nacos自动清理过期服务的过期时间(删除服务的元数据信息)，防止请求过多/代码问题导致Pod的cpu打满 触发Pod的健康检查后 Pod重启以后依然是下线状态(不可用) 这样就出大问题了；
    在这里插入图片描述

一、环境描述

名称版本部署方式
kubernetesv1.20.11二进制
nacosv2.0.3集群模式

二、模拟请求报错

模拟请求报错就是不加任何配置直接使用测试脚本(这里用的是jmeter)不间断的去调用我们的应用，然后发布我们的新应用会有失败的请求

##现在的deployment文件为如下##
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: data-center
  name: energy-order-api
  labels:
    app: energy-order-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: energy-order-api
  template:
    metadata:
      labels:
        app: energy-order-api
    spec:
      imagePullSecrets:
        - name: harbor-secret
      containers:
      - name: energy-order-api
        image: registry.xxxx/hqt-registry-pro/energy-order-api:P-1391-2023xxxx-15.47.45
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh"]
        args: ["-c","java -jar 
              -Xmx2688m 
              -Xms2688m 
              -Xmn961m 
              -XX:MaxMetaspaceSize=512m 
              -XX:MetaspaceSize=512m 
              -Xloggc:/logs/gc-%t.log 
              -XX:+HeapDumpOnOutOfMemoryError  
              -XX:HeapDumpPath=/data/logs/heapdump_$MY_POD_NAME.hprof
              -XX:+PrintGCDetails 
              -XX:+UnlockExperimentalVMOptions 
              -XX:+UseCGroupMemoryLimitForHeap 
              -XX:NativeMemoryTracking=detail 
              -javaagent:/data/skywalking/skywalking-agent.jar=agent.service_name=energy-order-api,agent.instance_name=$MY_POD_NAME,collector.backend_service=internal-skywalking.xxxx.xxm:11800 
              -Dapollo.meta=http://apollo-configservice.infrastructure.svc.cluster.local:8080 
              -Denv=pro /data/app.jar;/sbin/tini -s"]
        env:
        #获取pod实例名称，因为一个pod可能会有多个副本，所以需要根据名称来进行区分；
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        resources:
          requests:
            memory: "4Gi"
            cpu: "2000m"
          limits:
            memory: "4Gi"
            cpu: "2000m"
        volumeMounts:
        - name: energy-order-api-logs
          mountPath: /data/logs
          subPathExpr: $(MY_POD_NAME)
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /actuator/info
            port: 80
          initialDelaySeconds: 70 #pod启动多长时间后开始去探测;
          periodSeconds: 5 #每隔多长时间去探测一次；
          failureThreshold: 6
        readinessProbe:
          httpGet:
            path: /actuator/info
            port: 80
          initialDelaySeconds: 70
          periodSeconds: 5
          failureThreshold: 6
      affinity:
        #节点亲和性
        nodeAffinity:
          #硬策略
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              #标签键
              - key: ResourcePool
                operator: In
                #标签值
                values:
                - core
        #pod反亲和性配置
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - energy-order-api
            topologyKey: kubernetes.io/hostname        
 
      volumes:
      - name: energy-order-api-logs
        persistentVolumeClaim:
          claimName: energy-order-api-logs

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: energy-order-api-logs
  namespace: data-center
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: alicloud-nas-subpath
  resources:
    requests:
      storage: 1Gi

Pod启动成功如下：
在这里插入图片描述

在这里插入图片描述
设置30个线程开始去请求我们服务的接口
可以看到目前的请求都是成功的，此时我们修改镜像apply可以模拟下我们的服务发布，当新Pod启动后 删除旧Pod时注意观察请求是否有报错！

在这里插入图片描述

在这里插入图片描述
可以发现在删除pod时的这个动作会出现错误请求，随后就会正常
在这里插入图片描述
以上就是发版(新Pod替换旧Pod)的过程中会出现的问题；

三、配置优雅上下线

1.修改nacos配置

[root@iZbp1iz5ayf044rk5cqq26Z ~]# vim /hqtbj/hqtwww/nacos_workspace/conf/application.properties
#打开注释并修改
### The interval to clean expired metadata, unit: milliseconds.
nacos.naming.clean.expired-metadata.interval=5000
### The expired time to clean metadata, unit: milliseconds.
nacos.naming.clean.expired-metadata.expired-time=5000

保存后重启nacos

2.修改depolyment配置

需要添加k8s的prestop钩子，以及设置强制关闭pod的时间要比sleep的时间长
'curl -X PUT "http://my-nacos.xxx.com/nacos/v1/ns/instance?serviceName=服务名称&ip=服务IP&port=服务端口&weight=0" && sleep 30 && PID= && kill -SIGTERM $PID && while ps -p $PID > /dev/null; do sleep 1; done'
terminationGracePeriodSeconds: 40
如上命令的作用：

  1. 使用curl将注册到nacos的实例权重设置为0，设置为0后就不会再接受请求了，也可以调用nacos的下线接口，只需要将weight=0改为enabled=false即可；
  2. 不接受请求后sleep睡眠30秒 用于处理已经发送过来的请求；
  3. 然后再kill -SIGTERM进行优雅的关闭服务；
  4. 等待Pod中的服务完全停止，如果在 terminationGracePeriodSeconds 40s内 (默认 30s) 还未完全停止，就发送 SIGKILL 信号强制杀死进程(kill -9)。
#添加prestop钩子
lifecycle:
          preStop:
            exec:
              command: ["/bin/sh","-c",'curl -X PUT "http://my-nacos.xxx.com/nacos/v1/ns/instance?serviceName=energy-order-api&ip=${POD_IP}&port=80&weight=0" && sleep 30 && PID=`pidof java` && kill -SIGTERM $PID && while ps -p $PID > /dev/null; do sleep 1; done']  
#设置强制杀死Pod(kill -9)的时间，默认为30s   
terminationGracePeriodSeconds: 40

完整deployment内容如下

---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: data-center
  name: energy-order-api
  labels:
    app: energy-order-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: energy-order-api
  template:
    metadata:
      labels:
        app: energy-order-api
    spec:
      imagePullSecrets:
        - name: harbor-secret
      containers:
      - name: energy-order-api
        image: registry.xxxx/hqt-registry-pro/energy-order-api:P-1391-2023xxxx-15.47.45
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh"]
        args: ["-c","java -jar 
              -Xmx2688m 
              -Xms2688m 
              -Xmn961m 
              -XX:MaxMetaspaceSize=512m 
              -XX:MetaspaceSize=512m 
              -Xloggc:/logs/gc-%t.log 
              -XX:+HeapDumpOnOutOfMemoryError  
              -XX:HeapDumpPath=/data/logs/heapdump_$MY_POD_NAME.hprof
              -XX:+PrintGCDetails 
              -XX:+UnlockExperimentalVMOptions 
              -XX:+UseCGroupMemoryLimitForHeap 
              -XX:NativeMemoryTracking=detail 
              -javaagent:/data/skywalking/skywalking-agent.jar=agent.service_name=energy-order-api,agent.instance_name=$MY_POD_NAME,collector.backend_service=internal-skywalking.xxxx.xxm:11800 
              -Dapollo.meta=http://apollo-configservice.infrastructure.svc.cluster.local:8080 
              -Denv=pro /data/app.jar;/sbin/tini -s"]
        env:
        #获取pod实例名称，因为一个pod可能会有多个副本，所以需要根据名称来进行区分；
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        resources:
          requests:
            memory: "4Gi"
            cpu: "2000m"
          limits:
            memory: "4Gi"
            cpu: "2000m"
        volumeMounts:
        - name: energy-order-api-logs
          mountPath: /data/logs
          subPathExpr: $(MY_POD_NAME)
        ports:
        - containerPort: 80
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh","-c",'curl -X PUT "http://nacos.wonxxxnk.cc/nacos/v1/ns/instance?serviceName=energy-order-api&ip=${POD_IP}&port=80&weight=0" && sleep 30 && PID=`pidof java` && kill -SIGTERM $PID && while ps -p $PID > /dev/null; do sleep 1; done']
        terminationGracePeriodSeconds: 40
        livenessProbe:
          httpGet:
            path: /actuator/info
            port: 80
          initialDelaySeconds: 70 #pod启动多长时间后开始去探测;
          periodSeconds: 5 #每隔多长时间去探测一次；
          failureThreshold: 6
        readinessProbe:
          httpGet:
            path: /actuator/info
            port: 80
          initialDelaySeconds: 70
          periodSeconds: 5
          failureThreshold: 6
      affinity:
        #节点亲和性
        nodeAffinity:
          #硬策略
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              #标签键
              - key: ResourcePool
                operator: In
                #标签值
                values:
                - core
        #pod反亲和性配置
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - energy-order-api
            topologyKey: kubernetes.io/hostname        
 
      volumes:
      - name: energy-order-api-logs
        persistentVolumeClaim:
          claimName: energy-order-api-logs

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: energy-order-api-logs
  namespace: data-center
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: alicloud-nas-subpath
  resources:
    requests:
      storage: 1Gi

3.重新apply deployment后测试

在这里插入图片描述
在这里插入图片描述
如上，现在Pod已经启动成功并且在nacos中也是可用状态

开始测试
在这里插入图片描述
如上当开始停止旧pod时， 会先调用我们配置的prestop钩子 如下 先把nacos中旧pod的权重改为0 不让其接受请求，然后再处理已接受的请求最后彻底关闭pod

在这里插入图片描述
可以看到整个流程下来是没有发现有请求失败的！
在这里插入图片描述

这是单对这一个order服务进行的测试，接下来需要走一遍整体下单的流程，调用多个服务进行测试的同时重新发布这个order服务看是否有失败的请求

4.整体(下单)测试流程验证是否生效

已启动的pod以及nacos状态如下：
在这里插入图片描述
在这里插入图片描述
开始测试
在这里插入图片描述
在这里插入图片描述
如上可以发现在停止Pod时，跟上面的结果是一样的，都是先把nacos中旧pod的权重改为0，然后等待处理请求再彻底关闭pod；

如下测试，整体一个下单流程再发布期间也是不回受到影响的，无报错
在这里插入图片描述

四、期间遇到的问题

如果不配置nacos清理元数据信息的话，会导致当cpu/内存使用超过限制而导致健康检查重启时(Pod实例自身重启而不是会起一个新pod)，会出现即使pod重启完nacos里注册的服务权重是0/下线，导致服务直接不可用，只能手动再去启用！！所以下面在nacos的配置一定要进行使用！
在这里插入图片描述

如下：
服务因健康检查失败开始重启
在这里插入图片描述
在这里插入图片描述
此时的请求开始报错
在这里插入图片描述
服务的权重变为0，不接收请求
在这里插入图片描述
pod重启完成
在这里插入图片描述
发现nacos里注册的服务权重依然为0，并没进行接收请求
在这里插入图片描述
请求依旧报错
在这里插入图片描述

不知名运维:
关注
  • 30
    点赞
  • 踩
  • 31
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
SpringCloud服务的平滑上下线的方法
08-25
主要介绍了SpringCloud服务的平滑上下线的方法,小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
k8s安装Nacos集群
05-21
k8s搭建Nacos集群，制作Nacos镜像 Nacos版本是：2.0.2
在Kubernetes中实现优雅退出
念念不忘，必有回响
06-08 2171
随着持续部署（Continously Deployment）在项目中的使用，之前定期或者固定时间的发布节奏变为了随时高频率的发布。这就要求每次发布都应该是零停机部署（Zero Downtime Deployment），否则将会引入bug。k8s中有一套完整的机制保证我们的应用能够实现零停机部署，本文将重点分析其中的优雅退出部分。对于Kubernetes Deployment的每次部署过程，都是新版本的Pod创建、老版本的Pod删除的过程。 在这个过程中如果不使用优雅退出，则会引发两个问题：在Kubernet
【Spring】优雅上下线
机智的路易
08-30 2555
粗鲁下线应该绝对禁止 在停止的那一霎那，应用中正在处理的业务逻辑会被中断，导致产生业务异常情形。在 Spring Boot 2.3 中增加了新特性优雅停止。下面都支持优雅停止 （1）Spring Boot 内置的四钟嵌入式 Web 服务器（Jetty、Reactor Netty、Tomcat 和 Undertow） （2）反应式况下 （3）基于 Servlet 的 Web 应用程序application.yml 中添加一些配置来启用优雅停止 实现原理自定义EndPoint - gitee.com原理：执行
SpringCloud - Nacos 结合 K8s 优雅关闭服务（平滑升级）
牧码的博客
08-17 7300
SpringCloud - Nacos 结合 K8s 优雅关闭服务（平滑升级）
K8S的pod的优雅下线步骤
jiangxiaocan123的博客
07-23 659
在Kubernetes中，滚动更新是一种更新Deployment的策略，用于无缝地将新版本的Pod逐步引入到集群中，同时逐步删除旧版本的Pod。这样可以确保应用程序持续可用，避免中断服务。滚动更新的策略由Deployment对象的strategy字段定义。在Deployment中，可以使用以下两种滚动更新策略之一滚动更新的策略在Deployment的配置中通过strategy字段进行指定。
阿里云k8s 部署vue2+nginx+springboot2.5+nacos2.0.3
01-10
阿里云k8s 部署vue2+nginx+springboot2.5+nacos2.0.3
k8s搭建Nacos集群
05-26
k8s搭建Nacos集群，制作Java运行容器镜像，再制作Nacos镜像 Nacos版本是：2.1.0 说明： 如果想搭建：2.2.0也根据文档步骤操作即可
阿里云k8s 一键部署nacos2.0.3
01-10
阿里云k8s 一键部署nacos2.0.3
calm-cloud:实践搭建：springcloud + nacos +网关+ springsecurity
03-30
平静的云 ...冷静的父母包括：swagger，redis，jasypt，email，jwt，nacos，openfeign，springboot-admin 冷静-常见包括：言行，安全 镇静核心包括：mysql，mybatis-plus，mybatis-plus-dynamic-dataso
docker/k8s容器优雅退出(python，go，java)
全栈工程师开发手册（原创）https://github.com/tencentmusic/cube-studio
02-29 7152
docker kill 直接杀死容器进程 docker stop是向容器进程发送SIGTERM信号，本文介绍 容器中的进程捕获 SIGTERM 信号，优雅的退出。 先来了解一下信号 SIGINT 程序终止(interrupt)信号, 在用户键入INTR字符(通常是Ctrl-C)时发出，用于通知前台进程组终止进程。 SIGQUIT 和SIGINT类似, 但由QUIT字符(通常是Ctrl-)来控制. ...
Nacos 实现服务平滑上下线(Ribbon 和 LB)
最新发布
庄周de蝴蝶的博客
09-28 2219
不知道各位在使用的时候有没有遇到过服务刚上线偶尔会出现一段时间的，或者服务下线后，下线服务仍然被调用的问题。而以上问题都是由于Ribbon或者的默认处理策略有关，其中Ribbon默认是 30s 更新一次服务信息，则是默认 35s 更新一次缓存。接下来本文讲解则如何通过监听Nacos的服务变更事件来实时进行相关服务的更新，以实现服务的平滑上下线。
python实现k8s的pod服务从nacos上自动上下线
XMYX-0
03-22 798
根据prometheus 监控pod的cpu,然后实现nacos自动上下线
微服务架构：Nacos本地缓存 PK 微服务优雅下线
LoveSummer
04-13 5850
在上篇文章《》中讲了当微服务突然挂掉的解放方案调整健康检查周期和故障请求重试。朋友看了文章，建议再聊聊正常关闭服务时如何让微服务优雅下线。为什么说是优雅下线？我们知道在分布式应用中为了满足CAP原则中的A（可用性），像Nacos、Eureka等注册中心的客户端都会进行实例列表的缓存。当正常关闭应用时，虽然可以主动调用注册中心进行注销，但这些客户端缓存的实例列表还是要等一段时间才会失效。...
优雅停机之主动从Nacos下线实例
qq_30062385的博客
03-02 6854
问题场景 服务提供方采用了 SpringCloud Alibaba 框架，将服务注册到 Nacos 上，部署采用的是 k8s + docker 容器部署。当服务升级发布时，新的 pod 被创建——Nacos 上服务实例加 1，旧的 pod 被关闭——Nacos 上服务实例减 1。 Nacos 通过心跳检测机制，将旧的 pod 实例下线。 在关闭旧的 pod 到下线 pod 之间，存在一定的时间差，导致服务消费方调用接口会发生报错的情况，对业务操作造成一定影响。 向 Nacos 上注册服务实例流程
Spring——项目优雅停机
CHIKA2333的博客
07-29 2496
当我们停止正在运行的应用程序或进程时，底层操作系统会向进程发送终止信号。在没有启用任何优雅关闭机制的情况下（如：kill -9），Spring Boot 应用程序将在收到信号后立即终止。此时一些没有执行完的程序就会直接退出，可能导致业务逻辑执行失败，在一些业务场景下：会出现数据不一致的情况，事务逻辑不会回滚。
k8s 和 nacos 如何优雅的停止 不宕机
ccnn_yanan的博客
08-16 2167
k8s 和 nacos 如何优雅的停止 不宕机
springboot + tomcat + nacos 实现服务注册
05-11
要实现服务注册，你需要在 Spring Boot 项目中引入 Nacos 客户端依赖，然后在 application.properties 或 application.yml 中配置 Nacos 服务的地址和端口以及服务名等信息。 下面是一个示例的 application.yml 文件： ```yaml server: port: 8080 spring: application: name: demo-service cloud: nacos: discovery: server-addr: localhost:8848 ``` 这里我们使用了 Spring Cloud Alibaba Nacos 的客户端依赖 spring-cloud-starter-alibaba-nacos-discovery，并在配置文件中指定了 Nacos 服务的地址和端口，以及当前服务的名字为 demo-service。 接着，在启动类中加上 @EnableDiscoveryClient 注解，启用服务注册和发现功能。示例代码如下： ```java @SpringBootApplication @EnableDiscoveryClient public class DemoServiceApplication { public static void main(String[] args) { SpringApplication.run(DemoServiceApplication.class, args); } } ``` 最后，可以在控制台或者 Nacos 管理界面中查看服务是否注册成功。 以上就是基于 Spring Boot、Tomcat 和 Nacos 实现服务注册的简单流程。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不知名运维:

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值