从一个HTTP请求完整链路分析到K8S配置的原理
我们在做请求的时候，客户端或者web端发送请求给到后端，具体完整的链路请求是怎么到后端的，以及后端怎么做负载均衡，扩缩容，这里跟大家分析下具体过程。看这篇文章需要有K8S的基础，如果没有，建议可以先去看一下作者的K8S系列相关文章，了解下K8S基本概念。
二. 一个完整的HTTP请求链路我们在使用域名请求的时候，首先要通过域名解析，一般是在GSLB（类似dnspod等平台）配置CNAME或A记录指向接入服务。接入服务可以是ias或者其他开源组件，接入服务可以配置各种路由规则，根据路由规则转发到名字服务（一般是北极星和IPPORT，由于历史原因也有TAF、L5），最后由名字服务去查找绑定的集群的对应的podip。
为什么要通过北极星呢？这里比如你绑定了3个pod，某1个失效了，就不会被访问了。北极星在注册的时候会和k8s的service绑定起来，知道pod的情况。
可参考视频DNS域名的解析过程（简单易懂）
-
PreStop:["/bin/sh","-c","sleep 15"],一般我们会在停止之前有一段时间做缓冲，preStop，保证缓存的请求处理完毕，没有流量进来了，开始重建
存活检查：检查容器是否正常，不正常则重启实例
就绪检查: 检查容器是否就绪，不就绪则停止转发流量到当前实例，查看健康检查和就绪检查使用指引
2.1. 检查方法:TCP端口检查/执行命令检查/HTTP请求检查
2.2. 启动延时，响应超时，间隔时间，健康阈值，不健康阈值
这里建议用PVC，否则pod重建过程会有日志丢失。申请大小一般10G就够了，可以自己在代码中控制几个日志文件，多少大小。
四. 分批更新策略 1. 自动更新策略这里是说比如我有10个pod，我分两批。自动可以用来做灰度
我制定某一个想更新的pod，一个个来就行
一般用不上，对实例进行逐个更新，这种方式可以让您不中断业务实现对服务的更新
五. 扩缩容这里看自己业务，如果你的业务很紧张，极限值建议45%就够了，如果业务不紧张，60%，80%都行。
- github 北极星
- 全局负载均衡GSLB之“部署篇”
- DNS域名的解析过程（简单易懂）
原文地址：https://cloud.tencent.com/developer/article/2151226