k8s业务故障集锦

问题一、pod服务链接数据库，偶发不可用

问题现象：

测试发聩，服务某些在测试时，偶尔不可用，服务端排查，java服务通过数据库连接池访问数据库，建立的链接有些突然就显示不可以调用

解决方式：

java服务端主机抓包，数据库端抓包，

java服务端分析：

1）当链接池的链接与数据库建立了tcp链接之后，立即发送数据，测试正常
2）当建立的tcp链接，在等待8分钟之后，再发送数据，却迟迟没有收到数据库的返回包，导致java服务端一直在进行包的重传，重传多次，也没有收到数据库的回包

数据库包分析：

1）数据库在于java服务端建立了tcp链接之后，在立即发送数据包的情况下，可以收到从java服务端发送来的数据包
2）当建立tcp链接，在等待8分钟之后，就再也没有收到java服务端发送来的数据包

抓包分析结论：

tcp建立链接之后，立即进行数据的访问，一切正常；当等待8分钟之后，java与mysql直接由于某种原因，导致包一直卡在了java服务端，没有到达mysql端

kubernetes数据包传输链路图：

通过传输链路图分析，pod与mysql之间的snat的映射关系的记录表，出现了问题
关于nf_conntrack模块的tcp链接有几个参数可以参考：
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 3600
net.netfilter.nf_conntrack_tcp_timeout_established = 7200
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
通过观察问题主机的参数，发现net.netfilter.nf_conntrack_tcp_timeout_established的阈值为300，即5分钟后tcp_established的信息将不在记录，从而被nf_conntrack回收

 

解决方式：

1）java客户端保持探活机制
2）增大主机net.netfilter.nf_conntrack_tcp_timeout_established的阈值，防止在使用的tcp链接信息被nf_conntrack快速回收
3）mysql端发起保持探活机制