生产上mysql pod容器发生重启，describe pod查看到readiness检查失败：
Readniness probe failed: mysqladmin: connect to server at 'localhost' failed error: 'Lost connection to MySQL server at 'reading initial communication packet', system error: 104
网上查看该失败信息，发现当WEB服务器负载高的时候，经常会出现这种错误，原因：MySQL默认connect_timeout是5秒，超过了这个时间MySQL的server端就会返回“Bad handshake”。解决办法：
1.大多数时候设置"set global connect_timeout=60"是可以解决问题的；我们可以通过执行“SHOW STATUS LIKE ‘aborted%’”，可以查看到：
| Variable_name | Value |
|---|---|
| Aborted_clients | 6 |
| Aborted_connects | 15010 |
觉得是否要增加connect_timeout的时间，“Aborted_connects"将会随着服务端放弃客户端初始连接而增加。如果"Aborted_connects"很大，并且不断增加，就需要增加"connect_timeout”.
2.在MySQL的配置文件中[mysqld]添加"skip-name-resolve",减少域名解析的时间
3.部署服务器端的网络要好，至少大于100Mbps/s
4.如果是在调用mysql_query的时候出现的问题，那就需要把"net_read_timeout"的时间调成30秒，或者60秒，或者更大的值
5.如果还不能解决问题，那估计是你的SQL语句中含有BLOB这种大类型，我们就需要增加"max_allowed_packet"的值了。
下面的event事件显示容器发生重启，get pod看到的restart count数加1，奇怪的是Readiness失败本来是不会导致容器重启的。
去pod所在宿主机上看/var/log/message日志，发现mysqld被系统oom_killer杀掉了。而且时间也能匹配上。
可以猜到，当时是因为mysql pod压力大，内存暴增，导致Readiness健康检查失败。而kubelet没有及时探测到oom（kubelet如果探测到，会有event事件输出），而是被系统直接kill掉。
参考
ERROR 2013 (HY000): Lost connection to MySQL server at ‘reading authorization packet’, system error: 104原因和解决办法
RDS连接报错: Lost connection to MySQL server, system error: 104
Kubernetes 针对资源紧缺处理方式的配置
Linux Cgroup系列（04）：限制cgroup的内存使用（subsystem之memory）