【編者的話】Kubernetes之旅的主要收獲。

我們?cè)?017年開始創(chuàng)建我們的第一個(gè)Kubernetes集群，當(dāng)時(shí)版本為1.9.4。我們有兩個(gè)集群，一個(gè)是運(yùn)行在裸金屬RHEL虛機(jī)上，一個(gè)是跑在AWS EC2上。

如今，我們的Kubernetes基礎(chǔ)設(shè)施由400多臺(tái)分布在多個(gè)數(shù)據(jù)中心的虛機(jī)組成。該平臺(tái)承載了很多高可用的關(guān)鍵任務(wù)的應(yīng)用和系統(tǒng)，以管理一個(gè)擁有近4000萬臺(tái)活躍設(shè)備的大規(guī)模實(shí)時(shí)網(wǎng)絡(luò)。

[[416051]]

Kubernetes最終使我們的生活變得更簡(jiǎn)單，但這是一個(gè)艱難的過程。不僅僅是我們的技能和工具集，我們的設(shè)計(jì)和思維都發(fā)生了徹底的轉(zhuǎn)變。我們必須采用多種新技術(shù)，并大量投入，以提升團(tuán)隊(duì)和基礎(chǔ)設(shè)施的能力。

回顧過去三年Kubernetes在生產(chǎn)環(huán)境的經(jīng)歷，我們總結(jié)了一些重要的經(jīng)驗(yàn)教訓(xùn)。

Java應(yīng)用上奇怪的問題

談到微服務(wù)和容器化，工程師們傾向于避免使用Java棧，主要是因?yàn)樗裘阎膬?nèi)存管理。不過現(xiàn)在情況發(fā)生了變化，多年來Java的容器兼容性得到了改善。畢竟，像Apache Kafka和Elasticsearch這類無處不在的系統(tǒng)都在Java上運(yùn)行。

在2017-18年，我們有一些應(yīng)用運(yùn)行在Java 8版本上。它們通常難以理解像Docker這樣的容器環(huán)境，且常因堆內(nèi)存問題和非尋常的垃圾回收機(jī)制而崩潰。我們了解到，這些都是由JVM的問題以及Linux的cgroups和namespaces引起，而這些都是容器化技術(shù)的核心點(diǎn)。

不過從那時(shí)起，Oracle就開始持續(xù)改善Java在容器領(lǐng)域的兼容性問題，甚至Java 8的后續(xù)補(bǔ)丁也引入了實(shí)驗(yàn)性的JVM標(biāo)志XX:+UnlockExperimentalVMOptions和 XX:+UseCGroupMemoryLimitForHeap來解決這些問題。

但是盡管有了這些改進(jìn)，不可否認(rèn)的是，與Python或Go等同行相比，Java仍然在內(nèi)存占用和啟動(dòng)時(shí)間慢等方面存在壞名聲。這主要是由JVM的內(nèi)存管理和類加載器造成的。

現(xiàn)在，如果我們不得不選擇Java，那么我們要確保其是在Java 11版本或以上。我們的Kubernetes內(nèi)存限制是在JVM的最大堆內(nèi)存(-Xmx)的基礎(chǔ)上配置多1GB用于預(yù)留。例如，如果JVM使用8GB用于堆內(nèi)存，那么我們?yōu)樵搼?yīng)用在Kubernetes上的資源限制將為9GB。有了這個(gè)后，應(yīng)用穩(wěn)定了很多。

Kubernetes生命周期升級(jí)

Kubernetes生命周期管理例如升級(jí)或特性增強(qiáng)過程是很麻煩的，尤其是當(dāng)你的集群構(gòu)建在裸金屬設(shè)備或VM上。對(duì)于升級(jí)，我們意識(shí)到最簡(jiǎn)單的方法就是使用最新的版本搭建一個(gè)新的集群并將工作負(fù)載從就集群遷移到新集群。為原地節(jié)點(diǎn)升級(jí)所做的努力和規(guī)劃是不值得的。

Kubernetes有多個(gè)活動(dòng)組件需要配合升級(jí)。從Docker到CNI插件，例如Calico或Flannel，你必須小心翼翼將其拼湊在一起以使其正常工作。雖然有像Kubespray，Kubeone，Kops，Kubeaws這類工具使它更容易，但它們都有各自的短板。

我們使用Kubespray在RHEL虛機(jī)上搭建我們的集群。Kubespray很不錯(cuò)，它有用于搭建集群，添加和移除節(jié)點(diǎn)，版本更新，以及幾乎所有我們需要在生產(chǎn)環(huán)境上操作Kubernetes的操作的playbook。但是，用于升級(jí)的playbook附帶了一個(gè)免責(zé)聲明，其阻止我們跳過小版本。因此要完成目標(biāo)版本升級(jí)需要經(jīng)歷所有中間的各個(gè)版本升級(jí)。

如果你計(jì)劃使用或者是已經(jīng)在使用Kubernetes，思考下生命周期活動(dòng)以及你的解決方案如何解決這個(gè)問題。構(gòu)建和運(yùn)行集群相對(duì)容易，但是生命周期管理是一個(gè)全新的問題，其中包含了很多活動(dòng)的組件。

構(gòu)建和部署

準(zhǔn)備好重新設(shè)計(jì)你的整個(gè)構(gòu)建和部署流水線。我們的構(gòu)建流程和部署必須經(jīng)過一個(gè)完整的轉(zhuǎn)變以適應(yīng)Kubernetes環(huán)境。重構(gòu)的工作不僅包含Jenkins流水線，還有使用Helm等新工具，調(diào)整新的Git流程和構(gòu)建策略，給Docker鏡像打標(biāo)簽，還有版本化Helm部署charts。

你將需要策略用于維護(hù)的不僅僅是代碼，還有Kubernetes部署文件，Dockerfiles，Docker鏡像，Helm charts，并設(shè)計(jì)一個(gè)新的方式將它們聯(lián)系起來。

經(jīng)過幾次迭代，我們確定了以下設(shè)計(jì)。

• 應(yīng)用代碼和對(duì)應(yīng)的helm chart存放在不同的Git倉庫，這允許我們來分別對(duì)它們進(jìn)行版本管理。
• 我們保存了一個(gè)包含應(yīng)用版本的chart版本的組合，用來跟蹤發(fā)布。例如，app-1.2.0使用charts-1.1.0部署。如果只有Helm values文件發(fā)生變更，那么只有chart的patch版本會(huì)發(fā)生改變(例如從1.1.0升級(jí)到1.1.1)。所有的這些版本號(hào)都由每個(gè)倉庫中的版本說明文件RELEASE.txt決定。
• 像Apacha Kafka或Redis這類無需我們構(gòu)建和修改其代碼的系統(tǒng)應(yīng)用，其工作方式有所不同。也就是說，我們沒有使用兩個(gè)Git倉庫，因?yàn)镈ocker標(biāo)簽就是Helm chart版本管理的一部分。如果我們因升級(jí)修改了Docker的標(biāo)簽，那么我們將升級(jí)chart標(biāo)簽中的主版本號(hào)。 ### 存活探針和就緒探針(這是一把雙刃劍)

Kubernetes的就緒探針和存活探針是其自動(dòng)解決系統(tǒng)問題的極好的功能。它們能在失敗時(shí)重啟容器并將流量從非健康實(shí)例上移除。但在某些特定故障條件下，這些探針將成為一個(gè)雙刃劍，會(huì)影響你的應(yīng)用程序的啟動(dòng)和恢復(fù)，特別是有狀態(tài)的應(yīng)用例如消息平臺(tái)或者是數(shù)據(jù)庫。

我們的Kafka系統(tǒng)就是這個(gè)問題的受害者。我們跑了一個(gè)3 Broker 3 ZooKeeper的有狀態(tài)集群，用了replicationFactor: 3和minInSyncReplica: 2的配置。問題發(fā)生在Kafka在意外的系統(tǒng)故障和崩潰后啟動(dòng)的時(shí)候。這導(dǎo)致它在啟動(dòng)過程中執(zhí)行額外的腳本來修改損壞的索引，根據(jù)不同的嚴(yán)重程序?qū)⒑馁M(fèi)10-30分鐘時(shí)間。由于這個(gè)額外的啟動(dòng)時(shí)間，存活探針將會(huì)不斷失敗，引發(fā)一個(gè)Kill信號(hào)讓Kafka發(fā)生重啟。由此阻礙Kafka修復(fù)索引，也無法完全啟動(dòng)。

唯一的解決方法就是配置存活探針檢測(cè)中的initialDelaySeconds配置來延遲容器啟動(dòng)后的評(píng)估。但是問題是很難假定一個(gè)具體的數(shù)值。有時(shí)恢復(fù)過程甚至需要一個(gè)小時(shí)，而且我們需要提供足夠的空間來考慮這個(gè)問題。但是initialDelaySeconds值設(shè)置越高，你的服務(wù)的恢復(fù)能力就越慢，因?yàn)镵ubernetes在啟動(dòng)失敗時(shí)將需要更長(zhǎng)的時(shí)間來完成啟動(dòng)容器。

所以折中路線就是為initialDelaySeconds字段評(píng)估一個(gè)值，以便更好地平衡你在Kubernetes中尋求的彈性和應(yīng)用程序在所有故障條件(磁盤故障、網(wǎng)絡(luò)故障、系統(tǒng)崩潰等)下成功啟動(dòng)的時(shí)間。

如果你使用了較新版本的Kubernetes，那么你可以使用第三類探針類型，即“Startup探針”。其會(huì)在容器啟動(dòng)成功之前禁用存活和就緒探針，以確保容器的啟動(dòng)過程不會(huì)被中斷。

使用外部IP暴露

我們了解到，使用靜態(tài)外部IP暴露服務(wù)會(huì)對(duì)內(nèi)核的連接跟蹤機(jī)制造成巨大的損失。除非有很周密的計(jì)劃，否則它在大規(guī)模時(shí)很容易發(fā)生崩潰。

我們的集群使用了Calico CNI并使用BGP作為Kubernetes中的路由協(xié)議，同時(shí)與邊緣路由器對(duì)等。對(duì)于Kube-proxy，我們使用IPTables模式。我們?cè)贙ubernetes中托管了一個(gè)通過外部IP暴露的大規(guī)模服務(wù)，每天處理了數(shù)百萬個(gè)請(qǐng)求。由于所有來自SDN的SNAT和偽裝(masquerading)，Kubernetes需要一個(gè)機(jī)制來跟蹤所有這些邏輯流。為了實(shí)現(xiàn)這一點(diǎn)，它使用了內(nèi)核中的Conntrack

和netfilter工具來管理這些連接到靜態(tài)IP的外部連接，然后轉(zhuǎn)換成內(nèi)部服務(wù)IP，然后到你的Pod IP。這都是通過conntrack表和IPTables實(shí)現(xiàn)的。

然而conntrack表有所限制，當(dāng)你觸發(fā)限制時(shí)，你的Kubernetes集群(OS內(nèi)核底層)將不再能接收新的連接。在RHEL系統(tǒng)上，你能通過以下命令檢查。

$ sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxnet.netfilter.nf_conntrack_count = 167012  
net.netfilter.nf_conntrack_max = 262144 

一些解決這個(gè)問題的方法是將多個(gè)節(jié)點(diǎn)和邊緣路由器對(duì)等，這樣連接到你的靜態(tài)IP的連接可以分散到你的集群上。所以如果你的集群有大量的機(jī)器，累積起來你看似可以有一個(gè)大的conntrack表來處理大量傳入的連接。

早在2017年我們開始的時(shí)候，這問題就使我們感到非常困惑，但最近Calico在2019年發(fā)表了一份關(guān)于這個(gè)問題的詳細(xì)研究報(bào)告，題目說的很貼切，“為什么conntrack不再是你的朋友”。

靈魂拷問：你絕對(duì)需要Kubernetes嗎?

三年來，我們?nèi)匀幻刻於荚诶^續(xù)發(fā)現(xiàn)和學(xué)習(xí)新的東西。這是一個(gè)復(fù)雜的平臺(tái)，有它自己的一些問題，特別是在建設(shè)和維護(hù)環(huán)境方面的開銷。它將改變你的設(shè)計(jì)、思維和架構(gòu)，并需要提高你的團(tuán)隊(duì)技能和規(guī)模，以滿足轉(zhuǎn)型的需要。

然而，如果你在云上，并且能將Kubernetes作為一種“服務(wù)”來使用，它可以減輕你的大部分開銷，主要是由平臺(tái)維護(hù)工作這方面，比如“我如何擴(kuò)大我的內(nèi)部網(wǎng)絡(luò)CIDR?”或“我如何升級(jí)我的Kubernetes版本?”

現(xiàn)在，我們已經(jīng)意識(shí)到，你需要問你自己的第一個(gè)問題就是“你絕對(duì)需要Kubernetes嗎”。這可以幫助評(píng)估你的問題，以及Kubernetes在多大程度上解決了這個(gè)問題。

Kubernetes改造并不容易。你為它付出的代價(jià)必須能對(duì)得上你的使用范例以及它真的能正面影響提升你的平臺(tái)。如果答案是肯定的，那么可以說Kubernetes可以極大地提高你的生產(chǎn)力。

請(qǐng)記住，為技術(shù)而技術(shù)是沒有意義的。