關鍵字: GKE, conntrack, HAProxy
影響: 網路重度服務遇見大量錯誤
今天這個案例的重點非常簡單，Kubernetes(GKE) 會根據每個節點上面的記憶體大小去設定相關的 conntrack_max 的數值。因此對於一個小記憶體的節點上運行一個有網路重度的服務，非常容易踩到 conntrack_max 的上限最後導致連線 reset 以及 timeout.
conntrack 是 Linux Kernel 非常重要的網路功能，透過 conntrack (connection tracking) 可以實現非常多的功能，kernel 會去追蹤與監控系統上看到的所有連線，每個連線都包含兩個方向的封包。
根據作者的測試，於 GKE 觀察的結果是大概每 MB 可提升5條 connection的上限。
團隊的應用程式是一個類似於 proxy 的角色，這個應用程式大概每秒要處理一萬個以上的 rquest，而這個現象是當團隊針對整個架構進行一番改正後，開始注意到有網路連線出現問題。
針對這個問題作者提出了幾個解決思路
1. 針對網路連線非常重度的應用程式，將其給配置到比較強力效能的機器人，才可以獲得更高數值的 conntrack_max
2. 透過 init-container/daemonset 等方式，手動執行 sysctl 去修改節點上的 conntrack_max
3. 透過 Prometheus 去監控系統上目前所有節點 conntrack 使用的數量，藉此提醒團隊這個數值也很重要，需要監控
4. 1.15 以後的 kubernetes 有一些小的修復可以幫忙移除一些不合法的 conntrack，勁量讓 conntrack pool 留給有用的連線
https://deploy.live/blog/kubernetes-networking-problems-due-to-the-conntrack/
connection pool設定 在 Backend 台灣(Backend Tw) | 前言： 上回路邊酸酸在噴鋼針時 ... 的推薦與評價
而到底會有多少是idle，其很看connection pool內部怎麼寫和具體設定；所以現在有多少db connection，只反映出你開了多少個docker container，而不是 ... ... <看更多>