關鍵字: 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
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「kube-proxy」的推薦目錄:
- 關於kube-proxy 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於kube-proxy 在 矽谷牛的耕田筆記 Facebook 的精選貼文
- 關於kube-proxy 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於kube-proxy 在 コバにゃんチャンネル Youtube 的最佳解答
- 關於kube-proxy 在 大象中醫 Youtube 的最讚貼文
- 關於kube-proxy 在 大象中醫 Youtube 的精選貼文
- 關於kube-proxy 在 kubernetes-sigs/kpng: Reworking kube-proxy's architecture 的評價
- 關於kube-proxy 在 Kubernetes 之Service 與kube-proxy 深入理解 - 歐里丸Blog 的評價
- 關於kube-proxy 在 How to find which mode kube-proxy is running in - Stack ... 的評價
- 關於kube-proxy 在 Kubernetes Without Kube-proxy - YouTube 的評價
- 關於kube-proxy 在 Cilium github - Vo Zenaide 的評價
kube-proxy 在 矽谷牛的耕田筆記 Facebook 的精選貼文
這是一篇幻想文,幻想如果你可以重新設計 Kubernetes,你會希望有什麼樣的改動。也因為是幻想文,所以以下所提的東西不一定真的可以實作,也沒有考慮實作上可能會有什麼困難。原文非常的長,所以這邊就稍微列出一些內容
# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜,從 MetalLB 的開發經驗來看,幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速,一些不相容的修改也很難除錯,往往導致這些整合應用程式一起壞掉。
此外,作者使用 GKE 的經驗讓他覺得就算是這些k8s專家,也很難大規模環境中平安順利的使用 k8s.
作者認為 k8s 就像是管理平台內的 c++,功能非常強大,什麼都可以做,但是它會一直傷害你,直到你奉獻餘生該領域內。
作者期盼有一天,可以出現一個像是 go 語言的管理平台,簡單,優雅,容易學習
接下來就來看一下如果時光倒流,作者會希望 k8s 有哪些功能
# Mutable Pod
不像其他的資源一樣, Pod 這個資源基本上是不能修改的,有任何的更動都需要先刪除,後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說,我透過 kubectl edit 修改了 Pod Image,然後只要透過 SIGTERM 送給 Runc 底層容器,然後當該 Container 被重啟,就會使用新的設定。這一切的發生都在同一個 Pod 的資源內,而不是重新產生一個新的 Pod
# Version control all the things
當 Pod 可以修正後,下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化
為了實現這個功能,可能每個節點上面也要去紀錄過往的所有 image 版本資訊,並且加上 GC 等概念來清除過期或是太舊的內容
# Replace Deployment with PinnedDeployment
相對於 Deployment, PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。
舉例來說,我今天要將 Nginx 從 1.16 升級到 1.17,我可以透過 PinnedDeployment 去部署 Nginx,其中 1.16 佔了 60% ,而新版本 1.17 佔了 40%。
當一切轉移都沒有問題後,可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。
# IPv6 only, mostly
作者期望能的話,想要把 k8s networking 內的東西全部移除,什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。
k8s 全面配置 IPv6,而且也只有 IPv6,通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6,這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故,所有的存取都採用 Routing 的方式,封裝之類的玩法也不需要了。
文章內還提了很多東西,譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上,可以怎麼做,如何設計 NAT64 等,算是非常有趣的想法
# Security is yes
作者認為安全性方面要最大強化,預設情況下要開啟 AppArmor, seccomp profile 等控管機制,同時也要全面禁止用 Root 來運行容器, 基本上就是用非常嚴格的方式來設定安全性方面的規則。
目前 Kubernetes 內的資源, Pod Security Policy 非常類似作者想要完成的東西,通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。
# gVisor? Firecracker?
從安全性考量出發,是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc,同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境
# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine,也許就會像是將 kubevirt 變成一個內建的功能,讓 kubernetes 更加靈活的使用
除了上面之外,文章內還有許多其他的想法,但是內容都滿長的,如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/
kube-proxy 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
最近跟大家分享一個 2020 年初左右的問題,這個問題的徵狀使用者透過 service 去存取相關服務時,會一直遲遲連接不上,直到 63 秒後服務才會通。
這個問題有兩種類型,一個是 63 秒後服務會通,一個則是 1 秒後會通,兩個背後的原因都一樣,這邊就來稍微簡介一下這個問題
# 發生條件
1. 使用 VXLAN 作為底層 Overlay Network,最常見的就是 Flannel 這套 CNI
2. Kubernetes 的版本不能太舊,至少要 1.16 以後,不過目前這個問題已經修復,所以現在要撞到除非特別指定版本
3. 使用的 Linux Kernel 版本也不能太新,目前該問題已經修復於大部分的 upstream
# 發生原因
1. VXLAN 本身是一個基於 UDP 的封裝協議,有一個已知的 bug 會使得其 checksum 發生錯誤,導致封包不會被遠端接收方給接收
2. kube-proxy 內關於 iptables 的設定沒有妥善,導致 VXLAN 封包會進行二次 SNAT
3. 第二次的 SNAT 就會觸發(1) 的 bug(當然還有其他條件,但是那些條件也剛好符合)
,最後導致封包的 checksum 不同,因此送到遠方就被拒絕
4. 底層的 TCP 建立連線時,會不停地嘗試,每次失敗都會等待更多時間,分別是1,2,4,8,16,32秒
5. 五次都失敗後, TCP 就會觸發重傳機制,下一次的重傳就不會進入到第二次的 SNAT,因此封包就不會踩到問題,因此通過
# 解決方法
1. 基本上這個問題要踩到要各方一起努力才會踩到,也因此修復方式也是多元化
2. Kernel 本身修復了關於 UDP 封裝的 Checksum 計算
3. Kubernetes 這邊則是針對 kube-proxy 進行強化,其使用的 iptables 規則會避免二次 SNAT 的情況
# 其他問題
1. 為什麼 TCP 重送後就不會踩到二次 SNAT? 這部分我看了相關的 issue 以及諸多文章都沒有看到解釋,都在探討 SNAT 後產生的 checksum,至於為什麼 TCP 重送後就通則是一個謎底
2. 為了解決這個謎體,我特別指定 kubernetes 版本並且重新編譯 Ubuntu 的 Linux Kernel 版本,盼望從 Kernel 中來觀察並且理解這個問題,目前已經有一些初步的進度。之後完成後會在撰寫文章跟大家分享這個問題
這個問題我認為非常有趣,也許自己的環境剛好沒有踩到,但是可以透過觀察不同的 issue 來研究各式各樣問題,也藉由這些過程來學習
相關 PR: https://github.com/kubernetes/kubernetes/pull/92035
kube-proxy 在 Kubernetes 之Service 與kube-proxy 深入理解 - 歐里丸Blog 的推薦與評價
Kubernetes 之Service 與kube-proxy 深入理解 · 前言 · 初識Service 原理 · 問題情境 · K8s cluster 系統環境描述 · 分析不同請求iptables flow chart 的流程. ... <看更多>
kube-proxy 在 kubernetes-sigs/kpng: Reworking kube-proxy's architecture 的推薦與評價
First, make sure you understand the basics of K8s networking. · CNI providers (i.e. calico, antrea, cillium, and so on) · Service Proxies (i.e. kube-proxy, ... ... <看更多>