關鍵字: conntrack, DNS, CoreDNS-autoscaler
影響: 部分正式生產環境崩壞

整個問題是簡單來說就是正式叢集再不預期的情況下，發生了 DNS 的問題，導致內部服務大概有 15000 筆 query 失敗。造成錯誤的原因是因為 kube-proxy 沒有順利地去移除過期的 conntrack，導致有些 DNS封包被導向到一個已經不存在的Pod。

這個問題的發生前提是，因為某些情境的發生，譬如系統負載過低， CoreDNS-autoscaler 就被觸發起來，將運行的 Pod 數量從三個降為兩個。所以系統上能夠處理 DNS 的Pod剩下兩個，但是如果有節點上的 conntrack 沒有順利清理乾淨，導致所有的封包都被導向那個被刪除的 CoreDNS，問題就這樣發生了。

詳細的過程跟一些學習重點可以參考原文

註:想要掌握 kubernetes 網路，對於 conntrack 的認識絕對不可以少，有太多太多的問題都跟 conntrack 有關，從 race condition, max 等眾多選項都牽扯所有運行的封包。有時間的話一定要好好的複習一下 conntrack 的概念

https://medium.com/preply-engineering/dns-postmortem-e169efd45afd

關鍵字: 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/

本篇文章要來探討 Kubernetes/Docker 一些關於 connection timeout 的事情，文章非常長，這邊幫大家重點整理

1. 跟我之前分享的 DNS timeout 問題類似，都會踩到 Kernel 的 race condition，都是 __ip_conntrack_confirm 這個人丟掉大家封包的
2. 本文著重於怎麼發現這個問題，如何減緩這個問題。對於喜歡研究細節的人值得一看。
3. 2017年底作者團隊開始將服務遷移到 Kubernetes (v1.8), Flannel(1.9.0)，開始發現團隊中基於 Scala 的應用程式出現封包 timeout 的問題，這導致部分請求回應都延遲1-3秒
4. 決定認真調查網路問題，經由研究與錄製封包後發現 TCP 重送(SYN)的現象，該現象導致第一個封包會特別慢
5. 接下來要縮小範圍，使用環境中的一個VM作為基底，上面安裝 docker，開始觀察相關的網路流量與封包，發現可以重製這個行為，第一個封包從容器出去後，宿主機上面的真實網卡卻看不到，直到下次第二個封包就可以。藉由這個行為他們判斷，問題出在VM上，跟底層其餘硬體架構無關，藉此縮小問題範圍。
6. 介紹 iptalbes + SNAT + conntrack
7. 問題發生在 Kernel 裡面針對 SNAT 去選擇對外 source IP 時會出錯，因為(1)挑選一個適當的 source port, (2)將該紀錄寫到 conntrack 這兩個步驟中間會有落差，因此如果兩個封包同時進入(1)，選到一樣的結果，後續要跑(2)就會有一個人寫不進去，導致封包被丟棄
8. 一種解決方法是告訴 kernel 請隨機幫我挑選對外的 source port, 這樣就算大家同時執行(1)，有很大的機會會挑到不同的 source port，藉此減少衝突的機會。
9. iptables 執行 --masquerate 的時候可以下 --random-fully 這個參數
10. 團隊當時客製化 Flannel 來解決這個問題

註: 對 SNAT 有興趣瞭解的可以參考我之前撰寫的 SNAT Kernel 原始碼閱讀文章
https://www.hwchiu.com/iptables-masquerade.html
https://www.hwchiu.com/iptables-masquerade-handson.html

https://tech.xing.com/a-reason-for-unexplained-connection-timeouts-on-kubernetes-docker-abd041cf7e02