筆記翻譯： 這是公司工程部落格的公開事後分析的翻譯 。 描述了 Kubernetes 叢集中 conntrack 的一個問題，導致部分生產服務部分宕機。
對於那些想要更多地了解事後分析或防止將來出現一些潛在 DNS 問題的人來說，本文可能會很有用。
這不是 DNS
不可能是 DNS
原來是DNS
關於 Preply 中的事後分析和流程的一些信息
事後分析描述了生產中的故障或某些事件。 事後分析包括事件時間表、使用者影響、根本原因、採取的行動和吸取的教訓。
在每週與披薩舉行的技術團隊會議上，我們分享各種資訊。 此類會議最重要的部分之一是事後分析，通常伴隨著幻燈片演示和對事件的更深入分析。 儘管我們在事後不會鼓掌，但我們會努力培養一種「不責備」的文化（）。 我們相信，撰寫和展示事後分析可以幫助我們（和其他人）防止未來發生類似事件，這就是我們分享它們的原因。
參與事件的個人應該感到他們可以說出細節而不必擔心受到懲罰或報復。 沒有責怪！ 寫事後分析不是懲罰，而是整個公司的學習機會。
Kubernetes 中的 DNS 問題。 事後剖析
日期： 28.02.2020
作者： 阿梅特 U.、安德烈 S.、伊戈爾 K.、阿列克謝 P.
狀態： 完成的
簡述： Kubernetes 叢集中某些服務的部分 DNS 不可用（26 分鐘）
影響： 服務 A、B 和 C 遺失了 15000 個事件
根本原因： Kube-proxy 無法正確從 conntrack 表中刪除舊條目，因此某些服務仍在嘗試連接到不存在的 pod
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...扳機： 由於 Kubernetes 叢集內部負載較低，CoreDNS-autoscaler 將部署中的 pod 數量從 XNUMX 個減少到 XNUMX 個
解決方案： 應用程式的下一次部署啟動了新節點的創建，CoreDNS-autoscaler 增加了更多 pod 來為叢集提供服務，這引發了 conntrack 表的重寫
檢測： Prometheus監控偵測到A、B、C服務出現大量5xx錯誤，並向值班工程師發起呼叫
Kibana 中的 5xx 錯誤
行動
行為
類型
負責任的
任務
停用 CoreDNS 的自動縮放器
阻止
阿梅特 U.
DEVOPS-695
設定緩存 DNS 伺服器
減少
馬克斯V。
DEVOPS-665
設定conntrack監控
阻止
阿梅特 U.
DEVOPS-674
得到教訓
進展順利的地方：
- 監控效果良好。 反應迅速且有條理
- 我們沒有達到節點的任何限制
什麼問題：
- 仍然未知真正的根本原因，類似 在conntrack中
- 所有操作僅糾正後果，而不糾正根本原因（錯誤）
- 我們知道 DNS 遲早會出現問題，但我們沒有確定任務的優先順序
我們幸運的地方：
- 下一次部署是由 CoreDNS-autoscaler 觸發的，它覆蓋了 conntrack 表
- 此錯誤僅影響部分服務
時間表（歐洲東部時間）
時間
行為
22:13
CoreDNS-autoscaler 將 Pod 數量從三個減少到兩個
22:18
值班工程師開始接到監控系統的電話
22:21
值班工程師開始找出錯誤原因。
22:39
值班工程師開始將一項最新服務回滾到先前的版本
22:40
5xx錯誤不再出現，情況已經穩定下來
- 檢測時間： 4分鐘
- 行動前時間： 21分鐘
- 修復時間： 1分鐘
更多信息
- 核心 DNS 日誌：
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - 連結到 Kibana（已刪減）、Grafana（已刪減）
為了最大限度地減少 CPU 使用率，Linux 核心使用了名為 conntrack 的東西。 簡而言之，這是一個實用程序，其中包含儲存在特殊表中的 NAT 記錄清單。 當下一個封包從同一個 pod 到達與先前相同的 pod 時，最終的 IP 位址將不會重新計算，而是從 conntrack 表中取得。
Conntrack 的工作原理
結果
這是我們事後分析的一個範例，其中包含一些有用的連結。 具體來說，在本文中，我們分享可能對其他公司有用的信息。 這就是為什麼我們不害怕犯錯，也是我們公開事後分析的原因。 以下是一些更有趣的公開事後分析：
- GitLab：
- Dropbox的：
- Spotify的：
- 還有許多其他人來自 和儲存庫
- 還 使用 SRE Book 進行公開事後分析
來源： www.habr.com