中企动力建的网站如何,如何运用网站做推广,越秀微网站建设,凌晨三点播放的视频叫什么1. 概述
kubernetes滚动升级的过程#xff1a; 集群Deployment 或者 Statefulset 发生变化#xff0c;触发部署滚动升级#xff1b; 根据 Deolyement 等配置#xff0c;K8S集群首先启动新的POD来替代老 POD#xff1b; Deployemnt 根据配置调度 POD,拉取镜像#xff0c;…1. 概述
kubernetes滚动升级的过程 集群Deployment 或者 Statefulset 发生变化触发部署滚动升级 根据 Deolyement 等配置K8S集群首先启动新的POD来替代老 POD Deployemnt 根据配置调度 POD,拉取镜像此时 POD 进入 Pending 状态 POD 绑定到Node上启动容器在就绪检查readinessProbe 探针通过后新的POD进入Ready状态 K8S集群创建Endpoint将新的POD纳入Service 的负载均衡 K8S集群移除与老POD相关的Endpoint并且将老POD状态设置为Terminating此时将不会有新的请求到达老POD同时调用PreStop Hook执行配置的脚本 K8S集群会给老POD发送SIGTERM信号并且等待 terminationGracePeriodSeconds 这么长的时间。(默认为30秒可以根据优雅下线服务需要消耗时间调整) 超过terminationGracePeriodSeconds等待时间后 K8S集群会强制结束老POD在这个时间段内要将老 POD 资源释放掉否则可能残留无用资源被占用。
从以上过程可以看到如果在terminationGracePeriodSeconds 没有及时释放服务注册等资源信息Service 负载均衡的健康检查又没有检查到老 POD服务已经挂掉导致请求分发到这些 POD 上从而触发一系列的请求错误因而需要配置优雅下线脚本在terminationGracePeriodSeconds 时间段内执行完毕。 2.优雅启动
kubernetes 集群提供了探针类似健康检查只有该请求通过新的 POD 才能进入 Ready 状态kubernetes集群才会将新的 POD 纳入 Service 的负载均衡。
因而如果该应用(POD)仅仅提供 service 配置的服务不需要配置探针就可以优雅启动但是实际 POD 往往还有 HSF,LWPDubbo等注册于配置服务其实现负载均衡的服务所以需要确保这些服务都已经启动所以需要配置相应的探针。
同时任何一个服务可能在运行中因为某种原因不稳定导致服务中断这个时候还需要配置livenessProbe探针确保服务出故障时及时止损。
我们的应用主要有HSF,LWP 和 Https 服务对于三种服务都有的应用要求应用提供健康检查的接口能即时检查三种服务都正常与否然后做以下配置
livenessProbe:failureThreshold: 3initialDelaySeconds: 30periodSeconds: 30successThreshold: 1tcpSocket:port: 5084timeoutSeconds: 1
readinessProbe:failureThreshold: 3initialDelaySeconds: 30periodSeconds: 30successThreshold: 1tcpSocket:port: 5084timeoutSeconds: 1
restartPolicy: Always
readinessProbe配置表示只有5804端口请求正常返回pod 才会进入 ready 状态确保各种服务 ok 。
livenessProbe 表示每10s 探一下5804端口如果返回失败达到阈值后pod 会重启对于服务出问题的 POD 及时止损。
注意readinessProbe探针的 探测频率和延时时间不健康阈值等数据要合理部分应用启动时间本身较长如果设置的时间过短会导致 POD 反复无效重启。
3. 优雅下线
我们的应用云上主要有 HSF,LWP 和 Https 服务在 pod prestop里设置执行摘除服务注册信息脚本来完成优雅下线。
https 服务基于 kubernetes 服务 Service 来实现服务暴露在老 POD 状态设置为Terminating后就不会有请求达到因而已经优雅下线
lwp 服务通过注册 vipserver 来提供负载均衡需要在下线前先摘除该服务注册防止 老POD 下线后还有请求达到老 POD
HSF 服务通过注册 configserver 来提供负载均衡需要在下线前先摘除该服务注册防止 老POD 下线后还有请求达到老 POD。
yaml
lifecycle:preStop:exec:command:- sudo- -u- admin- /home/admin/shutdown.sh- {app_name}
preStop在 pod 终止之前执行脚本 appctl.sh {app_name} stop。
终止 HSF 与 LWP 脚本
#!/bin/bashAPP_NAME$1## HEALTH_URLhttp://localhost:7002/healthoffline() {echo INFO: ${APP_NAME} try to offline...offline_lwpoffline_hsfecho INFO: ${APP_NAME} offline successreturn $?
}offline_lwp() {echo offline lwptimes3for e in $(seq 3); docurl -s --connect-timeout 3 --max-time 5 ${offline_lwp_url}${APP_NAME} -o /dev/nullsleep 1done
}offline_hsf() {check_hsf(/usr/sbin/ss -ln4 sport :12200; /usr/sbin/ss -ln6 sport :12200) | grep -c :12200check_pandora(/usr/sbin/ss -ln4 sport :12201; /usr/sbin/ss -ln6 sport :12201) | grep -c :12201echo try to offline hsf...if [ $check_hsf -ne 0 -a $check_pandora -ne 0 ]; thenecho start to offline hsf....ret_strcurl --max-time ${HSF_ONLINE_TIMEOUT} -s http://localhost:12201/hsf/offline?khsf 21if echo $ret_str | grep server is unregistered on cs(dr) /dev/null; thenecho hsf offline success.return 0elseecho hsf offline failed.exit 9 # hsf offline failedfielseif [ $check_hsf -eq 0 ]; thenecho WARN: port 12200 cannot be detected.fiif [ $check_pandora -eq 0 ]; thenecho WARN: port 12201 cannot be detected.fiecho WARN: hsf offline failed.# DO NOT exit herefi
}echo [stop 1] before call offline hsf,lwp ...
原文链接 本文为云栖社区原创内容未经允许不得转载。
