当前位置： 首页 > news >正文

手机网站模板更改,wordpress无法跳转正确的404,广东省住房和城乡建设厅官网查证,西宁网站搭建专业公司应用在发布或重启的期间会出现少量的 5xx 异常#xff0c;应该如何解决#xff1f; 我们发现导致流量有损的原因有很多#xff0c;比如#xff1a; 上线时#xff0c;应用在就绪前收到流量#xff0c;导致请求无法被处理#xff1b; 下线时#xff0c;应用没有做优雅…应用在发布或重启的期间会出现少量的 5xx 异常应该如何解决 我们发现导致流量有损的原因有很多比如 上线时应用在就绪前收到流量导致请求无法被处理 下线时应用没有做优雅退出导致请求中断应用没有正确监听到终止信号导致优雅退出无效平台路由规则更新不及时导致流量转发到已经销毁的副本等
传统的解决方式是通过将应用更新流程划分为手工摘流量、停应用、更新重启三个步骤由人工操作实现客户端不对更新感知这种方式简单而有效但是限制较多。不仅需要使用借助网关的支持来摘流量还需要在停应用前人工判断来保证在途请求已经处理完毕。 滚动更新机制 在容器上线时 ReplicaSet 控制器会向 kube-apiserver 组件发送创建 Pod 的请求kube-scheduler 组件负责选择合适的节点的节点来运行新的 Pod并将选择的节点写入 Pod 对象的 spec.nodeName 字段中。 部署在每个节点中的 kubelet 组件会监听 Pod 对象的变化当新的 Pod 被调度到所在的节点时kubelet 组件会使用 CRI 来启动容器并在启动后对 Pod 内每个容器执行启动探测。 在启动探测通过后再分别对每个容器周期性地执行存活探测和就绪探测在 Pod 内所有容器都通过就绪探测之后kubelet 组件会把 Pod 标记为 Ready 状态同时上报给 kube-apiserver 组件。 而 Endpoint 控制器会监听 Pod 的变化当 Pod 的状态变为Ready状态时会将 Pod 的 IP 和端口添加到 Endpoint 对象中 kube-proxy 组件在监听 Endpoint 对象的变化后会使用 ipvs 或 iptables 在节点中生成流量转发的规则。 在容器下线时ReplicaSet 控制器会向 kube-apiserver 组件发送删除 Pod 的请求kube-apiserver 不会立即删除 Pod而是在 Pod 的metadata 中添加 deletionTimestamp 字段将 Pod 的状态标记为 Terminating。 当 kubelet 组件监听到 Pod 对象的 deletionTimestamp 被设置时就会调用 CRI 向容器发起停止容器的请求如果容器设置了 PreStop 钩子kubelet 会在发送 SIGTERM 信号之前先执行 PreStop 钩子等待 PreStop 钩子执行完成后再发送 SIGTERM 信号接着在 terminationGracePeriodSeconds 后发送 SIGKILL 信号去杀死所有容器进程完成容器的停止过程。 在 kubelet 停止容器的同时Endpoint 控制器监听到 Pod 的状态变化会将 Pod 的 IP 从相应的 Endpoint 对象中移除kube-proxy 组件监听到 Endpoint 对象的变化后会移除 Pod IP 的转发规则。kube-proxy 在不同的模式下移除转发规则的方式会有所不同比如 ipvs 模式下会把规则的权重修改为0iptable 模式下则是直接删除转发规则。 流量有损情况 1、没有配置就绪探测导致服务上线有损 如果没有配置就绪探测Pod 在启动完成后会立即被视为Ready就绪状态然后开始接收流量如果此时容器内的进程还在初始化资源的状态就会造成流量有损。 2、就绪探测配置不当导致服务上线有损 就绪探测提供了三种探测方式HTTP 探测、命令行探测、TCP 探测对于常规的 Web 服务我们应该首选 HTTP 探测、备选命令行探测尽量避免使用 TCP 探测。 在使用 TCP 探测时kubelet 组件会向指定端口发送 TCP SYN 包如果 Pod 响应 TCP ACK包则表明监听的端口处于打开状态则探测成功。但TCP 探测只能检测网络连接是否建立、服务端口是否打开无法反应服务的真实健康状态比如程序的端口虽然已经打开但如果内部正在初始化资源或者出现了死锁等问题的话也就无法正常处理流量即流量打到表面健康但实际不健康的 Pod 上造成流量有损。 3、没有配置优雅退出导致服务下线有损 服务下线过程中已进入容器的流量如果没有被处理完容器就被杀死导致调用方收到502。 服务下线的过程中Kubernetes 的 kubelet 和 kube-proxy 组件会同时监听 Pod 的变化然后分别去清理容器和网络的路由转发规则这个过程是同时进行的。在某些情况下kubelet 有可能在 kube-proxy 更新完路由转发规则前就已经销毁了容器这时新的流量被转发进来时就会出现异常。 优雅退出可以让程序在退出前执行的一系列保证应用正常关闭的操作这些操作往往包括等待已有请求执行完成、等待尚未完成的事务处理、清理资源比如关闭文件描述符、关闭socket、持久化内存数据比如将内存中的数据落盘到文件中等同时能够让 kubelet 组件在等待一段时间后在执行回收容器的操作给 kube-proxy 留够清理的时间。 优雅退出本质上是JVM即将关闭前执行的一些额外的处理代码。 4、监听SIGTERM信号但业务程序不是作为1号进程启动 如下代码程序监听了SIGTERM信号在收到SIGTERM信号时执行清理工作。 package mainimport (fmtosos/signalsyscalltime )func main() {c : make(chan os.Signal)signal.Notify(c, syscall.SIGTERM, syscall.SIGINT)go func() {for s : range c {switch s {case syscall.SIGINT, syscall.SIGTERM:fmt.Println(退出, s)ExitFunc()default:fmt.Println(other, s)}}}()fmt.Println(进程启动…)time.Sleep(time.Duration(200000)*time.Second) }func ExitFunc() {fmt.Println(正在退出…)fmt.Println(执行清理…)fmt.Println(退出完成…)os.Exit(0) } 1使用启动脚本启动 业务程序在容器中没有作为1号进程启动而是作为启动脚本start.sh的子进程启动容器中的 1 号进程 start.sh 收到了 SIGTERM 信号但并没有转发给它的子进程导致业务程序没有办法做优雅退出最后只能因为 SIGKILL 信号而被强制杀掉。

构建

FROM golang:alpine as buildWORKDIR /demoADD . .RUN GOOSlinux CGO_ENABLED0 GOARCHamd64 go build -o app main.go# 运行 FROM ubuntu:22.04 as prodCOPY –frombuild /demo/app /demo/ COPY –frombuild /demo/start.sh /demo/# 启动服务 CMD [/demo/start.sh] 启动脚本 #!/bin/sh# start.sh

do something

/demo/app 2使用shell模式启动 在Dockerfile中CMD和ENTRYPOINT用来启动应用有shell模式和exec模式。使用shell模式PID为1的进程为shell使用exec模式PID为1的进程为业务本身。 shell模式 CMD ./app exec模式 CMD [./app] 需要注意的是 exec模式无法读取环境变量仅shell模式能够读取环境变量。 3解决方式 1配置prestop 容器在下线时的流程 deletionTimestamp - prestop - SIGTERM - SIGKILL(terminationGracePeriodSeconds) 2在 Dockerfile 中移除启动脚本 start.sh让业务程序作为1号进程被启动。

让业务程序作为1号进程被启动

CMD [/demo/app] 3保留启动脚本start.sh使用 exec 命令启动业务程序exec 用于执行新的命令同时替换掉当前进程即覆盖掉原来启动脚本 start.sh 的进程。 #!/bin/sh# do something exec /demo/app