生產上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）