好看的课外书,穿越小说完本

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Kubernetes網(wǎng)絡(luò)運(yùn)維

最近我一直在研究 Kubernetes 網(wǎng)絡(luò)。我注意到一件事情就是，雖然關(guān)于如何設(shè)置 Kubernetes 網(wǎng)絡(luò)的文章很多，也寫得很不錯(cuò)，但是卻沒有看到關(guān)于如何去運(yùn)維 Kubernetes 網(wǎng)絡(luò)的文章、以及如何完全確保它不會給你造成生產(chǎn)事故。

主要從事網(wǎng)頁設(shè)計(jì)、PC網(wǎng)站建設(shè)（電腦版網(wǎng)站建設(shè)）、wap網(wǎng)站建設(shè)（手機(jī)版網(wǎng)站建設(shè)）、成都響應(yīng)式網(wǎng)站建設(shè)公司、程序開發(fā)、微網(wǎng)站、小程序開發(fā)等，憑借多年來在互聯(lián)網(wǎng)的打拼，我們在互聯(lián)網(wǎng)網(wǎng)站建設(shè)行業(yè)積累了豐富的成都網(wǎng)站制作、網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷經(jīng)驗(yàn)，集策劃、開發(fā)、設(shè)計(jì)、營銷、管理等多方位專業(yè)化運(yùn)作于一體，具備承接不同規(guī)模與類型的建設(shè)項(xiàng)目的能力。

在本文中，我將盡力讓你相信三件事情（我覺得這些都很合理 :)）：

避免生產(chǎn)系統(tǒng)網(wǎng)絡(luò)中斷非常重要
運(yùn)維聯(lián)網(wǎng)軟件是很難的
有關(guān)你的網(wǎng)絡(luò)基礎(chǔ)設(shè)施的重要變化值得深思熟慮，以及這種變化對可靠性的影響。雖然非?！芭”的谷歌人常說“這是我們在谷歌正在用的”（谷歌工程師在 Kubernetes 上正做著很重大的工作！但是我認(rèn)為重要的仍然是研究架構(gòu)，并確保它對你的組織有意義）。

我肯定不是 Kubernetes 網(wǎng)絡(luò)方面的專家，但是我在配置 Kubernetes 網(wǎng)絡(luò)時(shí)遇到了一些問題，并且比以前更加了解 Kubernetes 網(wǎng)絡(luò)了。

運(yùn)維聯(lián)網(wǎng)軟件是很難的

在這里，我并不討論有關(guān)運(yùn)維物理網(wǎng)絡(luò)的話題（對于它我不懂），而是討論關(guān)于如何讓像 DNS 服務(wù)、負(fù)載均衡以及代理這樣的軟件正常工作方面的內(nèi)容。

我在一個(gè)負(fù)責(zé)很多網(wǎng)絡(luò)基礎(chǔ)設(shè)施的團(tuán)隊(duì)工作過一年時(shí)間，并且因此學(xué)到了一些運(yùn)維網(wǎng)絡(luò)基礎(chǔ)設(shè)施的知識?。@然我還有很多的知識需要繼續(xù)學(xué)習(xí)）在我們開始之前有三個(gè)整體看法：

聯(lián)網(wǎng)軟件經(jīng)常重度依賴 Linux 內(nèi)核。因此除了正確配置軟件之外，你還需要確保許多不同的系統(tǒng)控制（sysctl）配置正確，而一個(gè)錯(cuò)誤配置的系統(tǒng)控制就很容易讓你處于“一切都很好”和“到處都出問題”的差別中。
聯(lián)網(wǎng)需求會隨時(shí)間而發(fā)生變化（比如，你的 DNS 查詢或許比上一年多了五倍！或者你的 DNS 服務(wù)器突然開始返回 TCP 協(xié)議的 DNS 響應(yīng)而不是 UDP 的，它們是完全不同的內(nèi)核負(fù)載?。?。這意味著之前正常工作的軟件突然開始出現(xiàn)問題。
修復(fù)一個(gè)生產(chǎn)網(wǎng)絡(luò)的問題，你必須有足夠的經(jīng)驗(yàn)。（例如，看這篇由 Sophie Haskins 寫的關(guān)于 kube-dns 問題調(diào)試的文章）我在網(wǎng)絡(luò)調(diào)試方面比以前進(jìn)步多了，但那也是我花費(fèi)了大量時(shí)間研究 Linux 網(wǎng)絡(luò)知識之后的事了。

我距離成為一名網(wǎng)絡(luò)運(yùn)維專家還差得很遠(yuǎn)，但是我認(rèn)為以下幾點(diǎn)很重要：

對生產(chǎn)網(wǎng)絡(luò)的基礎(chǔ)設(shè)施做重要的更改是很難得的（因?yàn)樗鼤a(chǎn)生巨大的混亂）
當(dāng)你對網(wǎng)絡(luò)基礎(chǔ)設(shè)施做重大更改時(shí)，真的應(yīng)該仔細(xì)考慮如果新網(wǎng)絡(luò)基礎(chǔ)設(shè)施失敗該如何處理
是否有很多人都能理解你的網(wǎng)絡(luò)配置

切換到 Kubernetes 顯然是個(gè)非常大的更改！因此，我們來討論一下可能會導(dǎo)致錯(cuò)誤的地方！

Kubernetes 網(wǎng)絡(luò)組件

在本文中我們將要討論的 Kubernetes 網(wǎng)絡(luò)組件有：

覆蓋網(wǎng)絡(luò)overlay network的后端（像 flannel/calico/weave 網(wǎng)絡(luò)/romana）
kube-dns
kube-proxy
入站控制器 / 負(fù)載均衡器
kubelet

如果你打算配置 HTTP 服務(wù)，或許這些你都會用到。這些組件中的大部分我都不會用到，但是我盡可能去理解它們，因此，本文將涉及它們有關(guān)的內(nèi)容。

最簡化的方式：為所有容器使用宿主機(jī)網(wǎng)絡(luò)

讓我們從你能做到的最簡單的東西開始。這并不能讓你在 Kubernetes 中運(yùn)行 HTTP 服務(wù)。我認(rèn)為它是非常安全的，因?yàn)樵谶@里面可以讓你動(dòng)的東西很少。

如果你為所有容器使用宿主機(jī)網(wǎng)絡(luò)，我認(rèn)為需要你去做的全部事情僅有：

配置 kubelet，以便于容器內(nèi)部正確配置 DNS
沒了，就這些！

如果你為每個(gè) pod 直接使用宿主機(jī)網(wǎng)絡(luò)，那就不需要 kube-dns 或者 kube-proxy 了。你都不需要一個(gè)作為基礎(chǔ)的覆蓋網(wǎng)絡(luò)。

這種配置方式中，你的 pod 們都可以連接到外部網(wǎng)絡(luò)（同樣的方式，你的宿主機(jī)上的任何進(jìn)程都可以與外部網(wǎng)絡(luò)對話），但外部網(wǎng)絡(luò)不能連接到你的 pod 們。

這并不是最重要的（我認(rèn)為大多數(shù)人想在 Kubernetes 中運(yùn)行 HTTP 服務(wù)并與這些服務(wù)進(jìn)行真實(shí)的通訊），但我認(rèn)為有趣的是，從某種程度上來說，網(wǎng)絡(luò)的復(fù)雜性并不是絕對需要的，并且有時(shí)候你不用這么復(fù)雜的網(wǎng)絡(luò)就可以實(shí)現(xiàn)你的需要。如果可以的話，盡可能地避免讓網(wǎng)絡(luò)過于復(fù)雜。

運(yùn)維一個(gè)覆蓋網(wǎng)絡(luò)

我們將要討論的第一個(gè)網(wǎng)絡(luò)組件是有關(guān)覆蓋網(wǎng)絡(luò)的。Kubernetes 假設(shè)每個(gè) pod 都有一個(gè) IP 地址，這樣你就可以與那個(gè) pod 中的服務(wù)進(jìn)行通訊了。我在說到“覆蓋網(wǎng)絡(luò)”這個(gè)詞時(shí)，指的就是這個(gè)意思（“讓你通過它的 IP 地址指向到 pod 的系統(tǒng)）。

所有其它的 Kubernetes 網(wǎng)絡(luò)的東西都依賴正確工作的覆蓋網(wǎng)絡(luò)。更多關(guān)于它的內(nèi)容，你可以讀這里的 kubernetes 網(wǎng)絡(luò)模型。

Kelsey Hightower 在 kubernetes 艱難之路中描述的方式看起來似乎很好，但是，事實(shí)上它的作法在超過 50 個(gè)節(jié)點(diǎn)的 AWS 上是行不通的，因此，我不打算討論它了。

有許多覆蓋網(wǎng)絡(luò)后端（calico、flannel、weaveworks、romana）并且規(guī)劃非?；靵y。就我的觀點(diǎn)來看，我認(rèn)為一個(gè)覆蓋網(wǎng)絡(luò)有 2 個(gè)職責(zé)：

確保你的 pod 能夠發(fā)送網(wǎng)絡(luò)請求到外部的集群
保持一個(gè)到子網(wǎng)絡(luò)的穩(wěn)定的節(jié)點(diǎn)映射，并且保持集群中每個(gè)節(jié)點(diǎn)都可以使用那個(gè)映射得以更新。當(dāng)添加和刪除節(jié)點(diǎn)時(shí)，能夠做出正確的反應(yīng)。

Okay! 因此！你的覆蓋網(wǎng)絡(luò)可能會出現(xiàn)的問題是什么呢？

覆蓋網(wǎng)絡(luò)負(fù)責(zé)設(shè)置 iptables 規(guī)則（最基本的是 iptables -A -t nat POSTROUTING -s $SUBNET -j MASQUERADE），以確保那個(gè)容器能夠向 Kubernetes 之外發(fā)出網(wǎng)絡(luò)請求。如果在這個(gè)規(guī)則上有錯(cuò)誤，你的容器就不能連接到外部網(wǎng)絡(luò)。這并不很難（它只是幾條 iptables 規(guī)則而已），但是它非常重要。我發(fā)起了一個(gè) 拉取請求，因?yàn)槲蚁氪_保它有很好的彈性。
添加或者刪除節(jié)點(diǎn)時(shí)可能會有錯(cuò)誤。我們使用 flannel hostgw 后端，我們開始使用它的時(shí)候，節(jié)點(diǎn)刪除功能尚未開始工作。
你的覆蓋網(wǎng)絡(luò)或許依賴一個(gè)分布式數(shù)據(jù)庫（etcd）。如果那個(gè)數(shù)據(jù)庫發(fā)生什么問題，這將導(dǎo)致覆蓋網(wǎng)絡(luò)發(fā)生問題。例如，https://github.com/coreos/flannel/issues/610 上說，如果在你的 flannel etcd 集群上丟失了數(shù)據(jù)，最后的結(jié)果將是在容器中網(wǎng)絡(luò)連接會丟失。（現(xiàn)在這個(gè)問題已經(jīng)被修復(fù)了）
你升級 Docker 以及其它東西導(dǎo)致的崩潰
還有更多的其它的可能性！

我在這里主要討論的是過去發(fā)生在 Flannel 中的問題，但是我并不是要承諾不去使用 Flannel —— 事實(shí)上我很喜歡 Flannel，因?yàn)槲矣X得它很簡單（比如，類似 vxlan 在后端這一塊的部分只有 500 行代碼），對我來說，通過代碼來找出問題的根源成為了可能。并且很顯然，它在不斷地改進(jìn)。他們在審查拉取請求方面做的很好。

到目前為止，我運(yùn)維覆蓋網(wǎng)絡(luò)的方法是：

學(xué)習(xí)它的工作原理的詳細(xì)內(nèi)容以及如何去調(diào)試它（比如，F(xiàn)lannel 用于創(chuàng)建路由的 hostgw 網(wǎng)絡(luò)后端，因此，你只需要使用 sudo ip route list 命令去查看它是否正確即可）
如果需要的話，維護(hù)一個(gè)內(nèi)部構(gòu)建版本，這樣打補(bǔ)丁比較容易
有問題時(shí)，向上游貢獻(xiàn)補(bǔ)丁

我認(rèn)為去遍歷所有已合并的拉取請求以及過去已修復(fù)的 bug 清單真的是非常有幫助的 —— 這需要花費(fèi)一些時(shí)間，但這是得到一個(gè)其它人遇到的各種問題的清單的好方法。

對其他人來說，他們的覆蓋網(wǎng)絡(luò)可能工作的很好，但是我并不能從中得到任何經(jīng)驗(yàn)，并且我也曾聽說過其他人報(bào)告類似的問題。如果你有一個(gè)類似配置的覆蓋網(wǎng)絡(luò)：a) 在 AWS 上并且 b) 在多于 50-100 節(jié)點(diǎn)上運(yùn)行，我想知道你運(yùn)維這樣的一個(gè)網(wǎng)絡(luò)有多大的把握。

運(yùn)維 kube-proxy 和 kube-dns？

現(xiàn)在，我有一些關(guān)于運(yùn)維覆蓋網(wǎng)絡(luò)的想法，我們來討論一下。

這個(gè)標(biāo)題的最后面有一個(gè)問號，那是因?yàn)槲也]有真的去運(yùn)維過。在這里我還有更多的問題要問答。

這里的 Kubernetes 服務(wù)是如何工作的！一個(gè)服務(wù)是一群 pod 們，它們中的每個(gè)都有自己的 IP 地址（像 10.1.0.3、10.2.3.5、10.3.5.6 這樣）

每個(gè) Kubernetes 服務(wù)有一個(gè) IP 地址（像 10.23.1.2 這樣）
kube-dns 去解析 Kubernetes 服務(wù) DNS 名字為 IP 地址（因此，my-svc.my-namespace.svc.cluster.local 可能映射到 10.23.1.2 上）
kube-proxy 配置 iptables 規(guī)則是為了在它們之間隨機(jī)進(jìn)行均衡負(fù)載。Kube-proxy 也有一個(gè)用戶空間的輪詢負(fù)載均衡器，但是在我的印象中，他們并不推薦使用它。

因此，當(dāng)你發(fā)出一個(gè)請求到 my-svc.my-namespace.svc.cluster.local 時(shí)，它將解析為 10.23.1.2，然后，在你本地主機(jī)上的 iptables 規(guī)則（由 kube-proxy 生成）將隨機(jī)重定向到 10.1.0.3 或者 10.2.3.5 或者 10.3.5.6 中的一個(gè)上。

在這個(gè)過程中我能想像出的可能出問題的地方：

kube-dns 配置錯(cuò)誤
kube-proxy 掛了，以致于你的 iptables 規(guī)則沒有得以更新
維護(hù)大量的 iptables 規(guī)則相關(guān)的一些問題

我們來討論一下 iptables 規(guī)則，因?yàn)閯?chuàng)建大量的 iptables 規(guī)則是我以前從沒有聽過的事情！

kube-proxy 像如下這樣為每個(gè)目標(biāo)主機(jī)創(chuàng)建一個(gè) iptables 規(guī)則：這些規(guī)則來自這里）

-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.20000000019 -j KUBE-SEP-E4QKA7SLJRFZZ2DD[b][c]  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.25000000000 -j KUBE-SEP-LZ7EGMG4DRXMY26H  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-RKIFTWKKG3OHTTMI  
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CGDKBCNM24SZWCMS 
-A KUBE-SVC-LI77LBOOMGYET5US -m comment --comment "default/showreadiness:showreadiness" -j KUBE-SEP-RI4SRNQQXWSTGE2Y

因此，kube-proxy 創(chuàng)建了許多 iptables 規(guī)則。它們都是什么意思？它對我的網(wǎng)絡(luò)有什么樣的影響？這里有一個(gè)來自華為的非常好的演講，它叫做支持 50,000 個(gè)服務(wù)的可伸縮 Kubernetes，它說如果在你的 Kubernetes 集群中有 5,000 服務(wù)，增加一個(gè)新規(guī)則，將需要 11 分鐘。如果這種事情發(fā)生在真實(shí)的集群中，我認(rèn)為這將是一件非常糟糕的事情。

在我的集群中肯定不會有 5,000 個(gè)服務(wù)，但是 5,000 并不是那么大的一個(gè)數(shù)字。為解決這個(gè)問題，他們給出的解決方案是 kube-proxy 用 IPVS 來替換這個(gè) iptables 后端，IPVS 是存在于 Linux 內(nèi)核中的一個(gè)負(fù)載均衡器。

看起來，像 kube-proxy 正趨向于使用各種基于 Linux 內(nèi)核的負(fù)載均衡器。我認(rèn)為這只是一定程度上是這樣，因?yàn)樗麄冎С?UDP 負(fù)載均衡，而其它類型的負(fù)載均衡器（像 HAProxy）并不支持 UDP 負(fù)載均衡。

但是，我覺得使用 HAProxy 更舒服！它能夠用于去替換 kube-proxy！我用谷歌搜索了一下，然后發(fā)現(xiàn)了這個(gè) thread on kubernetes-sig-network，它說：

kube-proxy 是很難用的，我們在生產(chǎn)系統(tǒng)中使用它近一年了，它在大部分的時(shí)間都表現(xiàn)的很好，但是，隨著我們集群中的服務(wù)越來越多，我們發(fā)現(xiàn)它的排錯(cuò)和維護(hù)工作越來越難。在我們的團(tuán)隊(duì)中沒有 iptables 方面的專家，我們只有 HAProxy & LVS 方面的專家，由于我們已經(jīng)使用它們好幾年了，因此我們決定使用一個(gè)中心化的 HAProxy 去替換分布式的代理。我覺得這可能會對在 Kubernetes 中使用 HAProxy 的其他人有用，因此，我們更新了這個(gè)項(xiàng)目，并將它開源：https://github.com/AdoHe/kube2haproxy。如果你發(fā)現(xiàn)它有用，你可以去看一看、試一試。

因此，那是一個(gè)有趣的選擇！我在這里確實(shí)沒有答案，但是，有一些想法：

負(fù)載均衡器是很復(fù)雜的
DNS 也很復(fù)雜
如果你有運(yùn)維某種類型的負(fù)載均衡器（比如 HAProxy）的經(jīng)驗(yàn)，與其使用一個(gè)全新的負(fù)載均衡器（比如 kube-proxy），還不如做一些額外的工作去使用你熟悉的那個(gè)來替換，或許更有意義。
我一直在考慮，我們希望在什么地方能夠完全使用 kube-proxy 或者 kube-dns —— 我認(rèn)為，最好是只在 Envoy 上投入，并且在負(fù)載均衡&服務(wù)發(fā)現(xiàn)上完全依賴 Envoy 來做。因此，你只需要將 Envoy 運(yùn)維好就可以了。

正如你所看到的，我在關(guān)于如何運(yùn)維 Kubernetes 中的內(nèi)部代理方面的思路還是很混亂的，并且我也沒有使用它們的太多經(jīng)驗(yàn)?？傮w上來說，kube-proxy 和 kube-dns 還是很好的，也能夠很好地工作，但是我仍然認(rèn)為應(yīng)該去考慮使用它們可能產(chǎn)生的一些問題（例如，”你不能有超出 5000 的 Kubernetes 服務(wù)“）。

入口

如果你正在運(yùn)行著一個(gè) Kubernetes 集群，那么到目前為止，很有可能的是，你事實(shí)上需要 HTTP 請求去進(jìn)入到你的集群中。這篇博客已經(jīng)太長了，并且關(guān)于入口我知道的也不多，因此，我們將不討論關(guān)于入口的內(nèi)容。

有用的鏈接

幾個(gè)有用的鏈接，總結(jié)如下：

Kubernetes 網(wǎng)絡(luò)模型
GKE 網(wǎng)絡(luò)是如何工作的：https://www.youtube.com/watch?v=y2bhV81MfKQ
上述的有關(guān) kube-proxy 上性能的討論：https://www.youtube.com/watch?v=4-pawkiazEg

我認(rèn)為網(wǎng)絡(luò)運(yùn)維很重要

我現(xiàn)在的計(jì)劃是，繼續(xù)不斷地學(xué)習(xí)關(guān)于它們都是如何工作的，以盡可能多地減少對我動(dòng)過的那些部分的擔(dān)憂。

一如繼往，我希望這篇文章對你有幫助，并且如果我在這篇文章中有任何的錯(cuò)誤，我非常喜歡你告訴我。

本文名稱：Kubernetes網(wǎng)絡(luò)運(yùn)維
本文地址：http://fisionsoft.com.cn/article/dpeeeih.html