[[342001]]

我們于2017年開始構(gòu)建第一個Kubernetes集群1.9.4版本。 我們有兩個集群，一個集群在裸機RHEL VM上運行，另一個集群在AWS EC2上運行。

今天，我們的Kubernetes基礎(chǔ)架構(gòu)團隊由分布在多個數(shù)據(jù)中心的400多個虛擬機組成。 該平臺托管高度可用的關(guān)鍵任務(wù)軟件應(yīng)用程序和系統(tǒng)，以管理具有近四百萬個活動設(shè)備的大型實時網(wǎng)絡(luò)。

Kubernetes最終使我們的生活變得更輕松，但是這一旅程是艱難的，是一種范式轉(zhuǎn)變。 不僅我們的技能和工具有了徹底的轉(zhuǎn)變，而且我們的設(shè)計和思維也得到了徹底的轉(zhuǎn)變。 我們必須采用多種新技術(shù)并進行大量投資，以提高和提高我們的團隊和基礎(chǔ)架構(gòu)的技能。

回顧三年來，Kubernetes在生產(chǎn)中運行了三年，這是我們?nèi)沼浿械闹匾n程。

1. Java應(yīng)用程序的奇怪案例

在微服務(wù)和容器化方面，工程師傾向于避免使用Java，這主要是由于Java臭名昭著的內(nèi)存管理。 但是，現(xiàn)在情況發(fā)生了變化，多年來Java的容器兼容性得到了改善。 畢竟，無所不在的系統(tǒng)（例如Apache Kafka和Elasticsearch）在Java上運行。

回顧2017-18年度，我們有一些應(yīng)用程序在Java版本8上運行。這些應(yīng)用程序通常很難理解Docker等容器環(huán)境，并因堆內(nèi)存問題和異常的垃圾收集趨勢而崩潰。 我們了解到，這是由于JVM無法使用Linux cgroup和命名空間（它們是容器化技術(shù)的核心）造成的。

但是，從那時起，Oracle一直在不斷提高Java在容器領(lǐng)域的兼容性。 甚至Java 8的后續(xù)補丁都引入了實驗性JVM標志來解決這些問題，XX：+ UnlockExperimentalVMOptions和XX：+ UseCGroupMemoryLimitForHeap

但是，盡管有了所有的改進，但無可否認的是，與Python或Go等同行相比，Java在占用內(nèi)存和啟動速度慢方面仍然享有不良聲譽。 這主要是由JVM的內(nèi)存管理和類加載器引起的。

今天，如果我們必須選擇Java，請確保它的版本為11或更高。 并且我們的Kubernetes內(nèi)存限制在JVM最大堆內(nèi)存（-Xmx）之上設(shè)置為1GB，以留有余量。 也就是說，如果JVM使用8GB的堆內(nèi)存，則我們對該應(yīng)用程序的Kubernetes資源限制為9GB。 這樣，生活會更好。

2. Kubernetes生命周期升級

Kubernetes生命周期管理（例如升級或增強功能）非常繁瑣，尤其是如果您已在裸機或VM上構(gòu)建了自己的集群。 對于升級，我們已經(jīng)意識到，最簡單的方法是使用最新版本構(gòu)建新集群，并將工作負載從舊版本過渡到新版本。 就地節(jié)點升級所做的努力和計劃是不值得的。

Kubernetes具有多個移動部件，需要與升級保持一致。 從Docker到Calico或Flannel之類的CNI插件，您都需要仔細地將它們拼湊在一起才能正常工作。 盡管像Kubespray，Kubeone，Kops和Kubeaws這樣的項目使它變得更容易，但它們都有缺點。

我們在RHEL VM上使用Kubespray構(gòu)建了集群。 Kubespray非常棒，它具有用于構(gòu)建，添加和刪除新節(jié)點，升級版本的手冊，以及我們在生產(chǎn)環(huán)境中操作Kubernetes所需的幾乎所有內(nèi)容。 但是，升級手冊附帶了免責聲明，可防止我們跳過次要版本。 因此，必須經(jīng)過所有中間版本才能達到目標版本。

要點是，如果您打算使用Kubernetes或已經(jīng)在使用Kubernetes，請考慮生命周期活動以及您的解決方案如何解決這一問題。 構(gòu)建和運行集群相對容易一些，但是生命周期維護是一個全新的游戲，具有多個活動部分。

3.構(gòu)建和部署

準備重新設(shè)計整個構(gòu)建和部署管道。 我們的構(gòu)建過程和部署必須經(jīng)歷Kubernetes世界的完整轉(zhuǎn)型。 不僅在Jenkins管道中進行了大量的重組，而且還使用了諸如Helm之類的新工具，對新的git流和構(gòu)建進行了策略化，標記了docker映像，并對helm部署chart進行了版本控制。

您不僅需要維護代碼，還需要維護Kubernetes部署文件，Docker文件，Docker映像，Helm chart的策略，并設(shè)計一種將所有這些鏈接在一起的方法。

經(jīng)過幾次迭代，我們決定采用以下設(shè)計。

· 應(yīng)用程序代碼及其Helm Chart位于單獨的git存儲庫中。 這使我們可以分別對它們進行版本控制。 （語義版本控制）

· 然后，我們將Chart版本的映射與應(yīng)用程序版本一起保存，并使用它來跟蹤發(fā)布。 因此，例如，app-1.2.0部署有Charts-1.1.0。 如果僅更改Helm值文件，則僅更改Chart的補丁程序版本。 （例如，從1.1.0到1.1.1）。 所有這些版本均由每個存儲庫RELEASE.txt中的發(fā)行說明規(guī)定。

· 我們未構(gòu)建或修改其代碼的Apache Kafka或Redis等系統(tǒng)應(yīng)用程序的工作方式有所不同。 也就是說，我們沒有兩個git存儲庫，因為Docker標簽只是Helm chart版本控制的一部分。 如果我們更改了docker標簽以進行升級，則會在圖表標簽中增加主要版本。

4.Liveness和Readiness就緒探針（雙刃劍）

Kubernetes的活躍性和就緒性探查是自動解決系統(tǒng)問題的出色功能。 他們可以在發(fā)生故障時重新啟動容器，并從不正常的實例轉(zhuǎn)移流量。 但是，在某些故障情況下，這些探測可能會變成一把雙刃劍，并會影響應(yīng)用程序的啟動和恢復(fù)，尤其是有消息的應(yīng)用程序，例如消息平臺或數(shù)據(jù)庫。

我們的Kafka系統(tǒng)就是這個受害者。 我們運行了一個3 Broker 3 Zookeeper狀態(tài)集，該狀態(tài)集的ReplicationFactor為3，而minInSyncReplica為2。當Kafka在意外的系統(tǒng)故障或崩潰后啟動時，就會發(fā)生此問題。 這導致它在啟動期間運行其他腳本來修復(fù)損壞的索引，根據(jù)嚴重性，此過程可能需要10到30分鐘。 由于增加了時間，生動性探針將不斷失敗，從而向Kafka發(fā)出終止信號以重新啟動。 這阻止了Kafka修改索引并完全啟動。

唯一的解決方案是在實時探針設(shè)置中配置initialDelaySeconds，以在容器啟動后延遲探針評估。 但是，當然，問題在于很難對此加以說明。 有些恢復(fù)甚至需要一個小時，因此我們需要提供足夠的空間來解決這一問題。 但是，增加initialDelaySeconds的次數(shù)越多，彈性的速度就越慢，因為在啟動失敗期間Kubernetes需要更長的時間來重新啟動容器。

因此，中間的目的是評估initialDelaySeconds字段的值，以使其在您在Kubernetes中尋求的彈性與應(yīng)用程序在所有故障情況（磁盤故障，網(wǎng)絡(luò)故障，系統(tǒng)崩潰等）下成功啟動所花費的時間之間取得更好的平衡 ）

更新：如果您使用的是最新的最新版本，Kubernetes引入了第三種探針類型，稱為"啟動探針"，以解決此問題。 從1.16版開始提供alpha版本，從1.18版開始提供beta版本。

啟動探針會禁用就緒性和活動性檢查，直到容器啟動為止，以確保應(yīng)用程序的啟動不會中斷。

5.公開外部IP

我們了解到，使用靜態(tài)外部IP公開服務(wù)會對內(nèi)核的連接跟蹤機制造成巨大損失。 除非進行徹底計劃，否則它只會按比例分解。

我們的集群在Kubernetes內(nèi)的路由協(xié)議上運行在Calico for CNI和BGP上，并與邊緣路由器對等。 對于Kubeproxy，我們使用IP Tablesmode。 我們在Kubernetes中托管著龐大的服務(wù)，該服務(wù)通過每天處理數(shù)百萬個連接的外部IP公開。 由于來自軟件定義網(wǎng)絡(luò)的所有SNAT和偽裝，Kubernetes需要一種機制來跟蹤所有這些邏輯流。 為此，它使用內(nèi)核的Conntrack和netfilter工具管理與靜態(tài)IP的這些外部連接，然后將其轉(zhuǎn)換為內(nèi)部服務(wù)IP，然后轉(zhuǎn)換為您的pod IP。 這全部通過conntrack表和IP表完成。

但是，此conntrack表有其局限性。 一旦達到限制，您的Kubernetes集群（位于下面的OS內(nèi)核）將不再能夠接受新連接。 在RHEL上，您可以通過這種方式進行檢查。

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

解決此問題的一些方法是使用邊緣路由器對等多個節(jié)點，以使到您的靜態(tài)IP的傳入連接遍及整個群集。 因此，如果您的集群中有大量的計算機，則累積起來，您可以擁有一個大的conntrack表來處理大量的傳入連接。

早在2017年成立之初，這一切就讓我們望而卻步，但最近，Calico在2019年對此進行了詳細研究，標題為"為什么conntrack不再是您的朋友"。

您絕對需要Kubernetes嗎？

三年過去了，我們?nèi)匀幻刻炖^續(xù)發(fā)現(xiàn)和學習新知識。 它是一個復(fù)雜的平臺，具有自己的一系列挑戰(zhàn)，尤其是在構(gòu)建和維護環(huán)境方面的開銷。 它將改變您的設(shè)計，思維，架構(gòu)，并需要提高技能和擴大團隊規(guī)模以適應(yīng)轉(zhuǎn)型。

但是，如果您在云上并且能夠?qū)ubernetes用作"服務(wù)"，則可以減輕平臺維護帶來的大部分開銷，例如"如何擴展內(nèi)部網(wǎng)絡(luò)CIDR？"。 或"如何升級我的Kubernetes版本？"

今天，我們意識到，您需要問自己的第一個問題是"您是否絕對需要Kubernetes？" 這可以幫助您評估您所遇到的問題以及Kubernetes解決該問題的重要性。

Kubernetes轉(zhuǎn)型并不便宜。 您為此支付的價格必須確實證明"您的"用例及其如何利用該平臺。 如果可以，那么Kubernetes可以極大地提高您的生產(chǎn)力。

記住，為了技術(shù)而技術(shù)是沒有意義的。

本文翻譯自Komal Venkatesh Ganesan的文章《3 Years of Kubernetes in Production–Here's What We Learned》