问题征象
由于最近在测试k8s集群，QA同学创造访问一个接口时不稳定，通信一会正常、一会后不正常、交替进行，并且报错为 503 Service Temporarily Unavailable 缺点，由于利用的是ingress nginx controlller，其它业务没有此问题，报错信息如下。
报错图
环境解释
1. 问题发生在测试环境；
2. 每个deplpoyment副本数为1；
3. 配置了就绪性探针；
知识梳理
目前之以是选择 Kubernetes 作为容器编排引擎，最紧张的是由于它具有强大的自愈能力，默认情形下，一台宿主机故障后，它会自动把无状态运用迁移到其它宿主机上面，或者Pod发生故障后，也会重启单独的Pod。除此之外，kubernetes 还供应了 Liveness 和 Readiness 探测机制，有了这两种机制之后，可以实现零停机支配、滚动更新、并且可在探测做事可用性等，实在 kubernetes 里面供应的两种探测机制，都是对运用程序康健状态进行检讨，让 kubernetes 能够感知到运用程序是否正常事情等，如果做事不正常，流量就不应该再向其发送要求，相应的，如果运用程序做事规复后，流量能够自动接入。
Liveness存活性探针
存活性探针紧张是监控Pod是否康健，如果没有配置 livenessProbe，探针返回Success，但会判断Pod内容器是否正常启动，正常启动即为Running状态，如果配置了存活性探针，就根据探针定期进行探测，如果探测成功，则Pod状态可以剖断为Running，如果探测失落败，kubectl 会根据Pod的重启策略来重启容器。
这里须要把稳一点，Pod 处于Running状态，并不代表能正常供应做事，只能解释 Pod 内的容器是存活的，做事是否正常，是否能供应做事，须要利用 Readiness 就绪性探针进行判断。
Readiness就绪性探针
就绪性探针是判断 Pod 是否可以接管要乞降访问的依据，并且也是容器是否处于可用 Ready 状态的标志，达到 Ready 状态的 Pod 可以接管要求、调度（尤其是 HTTP 流量接口的，很有必要配置此探针）。Kubernetes 只有在 Readiness 探针检测通过后，才许可做事将流量发送到 Pod，如果探针失落败，Kubernetes将停滞向该容器发送流量，直到配置的 Readiness 探针通过，如果 Readiness 探针失落败，还会直接从 service 的后端 endpoint 列表中把 pod 删除，至到规复后，再加到 service 后真个 endpoint 列表中（kubectl describe svc 做事名 -n 名称空间）。
livenessProbe 探针失落败， kubectl 会根据Pod的重启策略来重启容器，readinessProbe 探针失落败不会重启操作，但Service 后端会从 endpoint 列表中把 pod 删除。
就绪性、存活性探针配置参数
探针办法readinessProbe/livenessProbe备注httpGethttpGet: host: (默认为pod的IP) path: /index.html port: 8080 （可以指定暴露端口的名称） scheme: HTTP根据状态码进行判断execexec: command: - cat - /data/healthy在容器内实行某命令，命令实行成功（通过命令退出状态码为0判断）则确定Pod就绪；tcpSockettcpSocket: host: (默认为pod的IP) port: 80打开一个TCP连接到容器的指定端口，连接成功建立则确定Pod就绪其它参数failureThreshold探测几次都失落败，认为就失落败了，默认是3initialDelaySeconds初始化延迟探测韶光，如果不定义，容器一启动就探测，我们知道容器启动，不代表容器中的主进程已经运行起来；periodSeconds周期间隔时长，定期探测successThreshold失落败后检讨成功的最小连续成功次数。默认为1.生动度必须为1。最小值为1。timeoutSeconds探测超时时间，默认是1s
问题排查
初步预判
由于是通过ingress规则注册到ingress controller中，然后通过域名进行访问，为什么会时好时坏呢，根据503 Service Temporarily Unavailable ，第一觉得是nginx controller有访问次数限定，并且通过多次测试创造时好时坏，仔细剖析，并没有次数的限定，比如1分钟10次，20次，没有规律可偱，它与nginx limit策略还不是很符合，一样平常如果配置了limit_req策略的话，相对有规律一些，登录ingres controller，通过查看配置，创造没有limit_req 干系配置，也证明了不是 limit_req 造成 503缺点，接下来，查看ingress controller日志。
nginx ingress controller 日志
创造日志中并没有转发过去，nginx只是作为反向代理，一样平常情形下5xx缺点都是后端产生的，但这次并没有转发到后端，后端做事器也没有日志，难道 nginx 规则注册到 ingress controller掌握器有问题，其它业务没有反馈。
测试比拟
此时跳过nginx ingress controller，直接访问 Pod 进行测试，创造做事正常，然后编写脚本同时通过ingress访问和Pod访问测试，创造通过ingress的时好时坏，直连到Pod的通信一贯是好的，解释后面Pod做事正常，此时更加确信是前端ingress controller的问题了，真的那么有信心确认是它的问题吗？
ingress 规则是利用service名称，把转发规则注册到 ingress controller，那现在通过 service 访问是否正常呢，修正上面的脚本，同时通过 ignress controller 访问、Pod IP 直连访问、service ClusterIP 访问，此时可以创造接口正常通信时，三个接口都正常，涌现503时，创造通过 Service Cluster IP 也不正常，到这里基本可以打消 nginx ingress controller了。
Pod 状态检讨
之前查看过Pod的状态，存活性探针、就绪性探针都是正常的（实在是一会正常，一会非常），只是之前查看的时候恰好正常而已，须要长期不雅观察下，尤其是接口通信非常时。
问题定位及办理
为什么这里 Service Cluster IP 无法供应做事了，通过kubectl describe svc 做事名 -n 名称空间，创造Endpoints: 后面的IP时有时无，解释 Pod 一会处于 Ready 状态，一会无法正常Ready，再遐想下 readiness 就绪性探针就会创造，很随意马虎创造是康健检测时好时坏，导致探针一会正常，一会失落败，进入 pod查看日志，也证明了这一点，health_check时好时坏。
这里还创造超时时间是1秒，我们是有配置readinessProbe的，配置如下
readinessProbe:failureThreshold: 1httpGet:port: 80scheme: HTTPinitialDelaySeconds: 30periodSeconds: 30successThreshold: 1timeoutSeconds: 1
这里超时时间为1秒，与上面缺点日志中health_check时1秒超时相互应，问题到这里基本上找到根了，和ingress controller 没有关系。进一步排查为什么health_check失落败呢？
通过time curl可以很随意马虎的创造，是常常涌现超过3秒的情形，利用strace 跟踪了下，如下图
创造确实是非常的卡，由于是php项目，php项目中有慢查询日志，查询慢查询日志中该当有记录才对，通过查看日志创造
创造checkMQ()时出错，终极创造是访问 (这里域名进行了更换)
[root@passport ~]# curl http://k8s.vip:8080/mqagent/healthcheckfail[root@passport ~]#[root@passport ~]#
这个接口会耗时很大，reponse 有时非常快，有时很慢有3秒、1秒的情形，正常接口该当很快就有相应。
[root@passport ~]# curl http://k8s.vip:8080/mqagent/healthchecksuccess[root@passport ~]#[root@passport ~]#
末了，去MQ机器去排查问题，创造一个配置缺点，导致相应很慢，至此，问题办理。
总结
本次问题点便是当 Pod 的 readinessProbe 探针失落败时，Service 后端会从 endpoint 列表中把 pod 删除，由于是测试环境，后端只有一台 Pod，以是问题非常随意马虎复现。
在处理问题时，须要结合 kubernetes 实现事理一步步排查，大部分可以很快办理。现在知道了却果，觉得排查很大略，实在每每办理一个问题后，都有类似的觉得，走了不少弯路，只有日积月累后，才能更好的办理问题，共勉。
