从一个HTTP请求完整链路分析到K8S配置的原理

一. 前沿

我们在做请求的时候，客户端或者web端发送请求给到后端，具体完整的链路请求是怎么到后端的，以及后端怎么做负载均衡，扩缩容，这里跟大家分析下具体过程。看这篇文章需要有K8S的基础，如果没有，建议可以先去看一下作者的K8S系列相关文章，了解下K8S基本概念。

二. 一个完整的HTTP请求链路

我们在使用域名请求的时候，首先要通过域名解析，一般是在GSLB（类似dnspod等平台）配置CNAME或A记录指向接入服务。接入服务可以是ias或者其他开源组件，接入服务可以配置各种路由规则，根据路由规则转发到名字服务（一般是北极星和IPPORT，由于历史原因也有TAF、L5），最后由名字服务去查找绑定的集群的对应的podip。

为什么要通过北极星呢？这里比如你绑定了3个pod，某1个失效了，就不会被访问了。北极星在注册的时候会和k8s的service绑定起来，知道pod的情况。

可参考视频DNS域名的解析过程（简单易懂）

未命名绘图.drawio (1).png

三. Pod的重建过程

1. Pod重建过程

Pod重建过程.png

1. PreStop: ["/bin/sh","-c","sleep 15"] ,一般我们会在停止之前有一段时间做缓冲，preStop，保证缓存的请求处理完毕，没有流量进来了，开始重建

2. 就绪/存活检查

存活检查：检查容器是否正常，不正常则重启实例

就绪检查: 检查容器是否就绪，不就绪则停止转发流量到当前实例，查看健康检查和就绪检查使用指引

2.1. 检查方法:TCP端口检查/执行命令检查/HTTP请求检查

2.2. 启动延时，响应超时，间隔时间，健康阈值，不健康阈值

image.png

3. PVC/共享目录

image.png

这里建议用PVC，否则pod重建过程会有日志丢失。申请大小一般10G就够了，可以自己在代码中控制几个日志文件，多少大小。

四. 分批更新策略

1. 自动更新策略

这里是说比如我有10个pod，我分两批。自动可以用来做灰度

2.png

2. 手动分批更新策略

我制定某一个想更新的pod，一个个来就行

1.png

3. 滚动更新策略

一般用不上，对实例进行逐个更新，这种方式可以让您不中断业务实现对服务的更新

五. 扩缩容

这里看自己业务，如果你的业务很紧张，极限值建议45%就够了，如果业务不紧张，60%，80%都行。

image.png

参考文章

1. github 北极星
2. 全局负载均衡GSLB之“部署篇”
3. DNS域名的解析过程（简单易懂）