[[343163]]

本文轉(zhuǎn)載自微信公眾號「新鈦云服」，作者祝祥 。轉(zhuǎn)載本文請聯(lián)系新鈦云服公眾號。  

我們于2017年開始構(gòu)建第一個基于1.9.4版本的Kubernetes集群。至今，我們已經(jīng)有兩個集群，一個集群在裸機(jī)RHEL VM上運(yùn)行，另一個集群在公有云AWS EC2上運(yùn)行。

今天，我們的Kubernetes集群由分布在多個數(shù)據(jù)中心的400多個虛擬機(jī)組成。該平臺承載著高度可用的核心應(yīng)用程序和系統(tǒng)，管理擁有近400萬個活躍用戶的的大型實時系統(tǒng)。

Kubernetes最終使我們的運(yùn)維變得更輕松，但是這一過程是艱辛的，是范式的轉(zhuǎn)變。不僅僅是我們的技能和工具有了徹底的轉(zhuǎn)變，而且我們的設(shè)計和思維也得到了徹底的轉(zhuǎn)變。我們必須采用多種新技術(shù)，并進(jìn)行大量的投入，以提高團(tuán)隊和基礎(chǔ)設(shè)施的檔次和技能。

回顧三年來，Kubernetes在我們的生產(chǎn)中運(yùn)行了三年，這也是本文將會將的重點(diǎn)內(nèi)容。

1. 基于Java的APP容器化問題

當(dāng)涉及微服務(wù)和容器化時，很多人都傾向于避免使用Java，這主要是由Java不太友好的內(nèi)存管理造成的。但是，現(xiàn)在情況發(fā)生了變化，并且Java的容器兼容性在過去幾年中得到了很大的改善。畢竟，當(dāng)前大部分的系統(tǒng)都有使用Java程序的 Apache Kafka作為中間件，另外Elasticsearch通常也是在Java程序上運(yùn)行。

回顧2017-2018年度，我們有一些應(yīng)用程序在Java 8上運(yùn)行。它們常常難以理解像Docker這樣的容器環(huán)境，并且由于堆內(nèi)存問題和異常的垃圾收集而崩潰。我們了解到，這是由于JVM無法支持Linux cgroups和namespaces，后者是容器化技術(shù)的核心。

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

但是，盡管有了這些改進(jìn)，但不可否認(rèn)的是，與Python或Go等同類產(chǎn)品相比，Java仍因占用內(nèi)存和啟動時間慢而名聲不佳。主要是由JVM的內(nèi)存管理引起的。

今天，如果我們必須選擇Java，我們會確保它的版本是11或更高。我們的Kubernetes內(nèi)存限制會在比JVM最大堆內(nèi)存(-Xmx)多1GB，以獲得足夠的空間。也就是說，如果JVM使用8GB作為堆內(nèi)存，我們對應(yīng)用程序的Kubernetes資源限制將是9GB。這樣，應(yīng)用將會更加健康。

2. Kubernetes升級

Kubernetes生命周期管理(如升級或補(bǔ)丁修復(fù))非常麻煩，尤其是在裸機(jī)或虛擬機(jī)上構(gòu)建了自己的集群時。對于升級，我們已經(jīng)意識到最簡單的方法是用最新版本重新構(gòu)建一個集群，并將工作負(fù)載從舊的集群遷移到新的集群。進(jìn)行節(jié)點(diǎn)的升級相對而言會更復(fù)雜，且結(jié)果無法預(yù)料。Kubernetes有多個與其一起協(xié)調(diào)工作的組件需要與Kubernetes升級保持一致。從Docker到像Calico或Flannel這樣的CNI插件，你需要小心地把它們拼湊在一起才能工作。盡管像Kubespray、Kubeone、Kops和Kubeaws這樣的項目使它更容易維護(hù)，但它們都有各自的缺點(diǎn)，且不太通用。

我們在RHEL VM上使用Kubespray構(gòu)建了集群。Kubespray非常不錯，它有基于ansible的構(gòu)建、添加和刪除新節(jié)點(diǎn)、升級版本的playbooks，以及我們在生產(chǎn)中操作Kubernetes所需的幾乎所有內(nèi)容。但是，升級的playbook帶了一個免責(zé)聲明，可防止我們跳過次要版本。因此，必須經(jīng)過所有中間版本才能達(dá)到目標(biāo)版本。簡而言之，Kubespray不支持跨版本升級。

以上可得出的結(jié)論是，如果您打算使用Kubernetes或已經(jīng)在使用Kubernetes，請考慮生命周期管理。構(gòu)建和運(yùn)行集群相對容易一些，但是Kubernetes的生命周期管理則相對復(fù)雜，涉及內(nèi)容較多。

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

準(zhǔn)備重新設(shè)計整個構(gòu)建和部署的pipelines。我們的構(gòu)建過程和部署必須經(jīng)歷一個基于Kubernete的完整轉(zhuǎn)型。不僅在Jenkins pipelines中進(jìn)行了大量的重組，還使用了諸如Helm這樣的新工具，制定新的git流和構(gòu)建策略，docker 鏡像的tag標(biāo)簽，以及版本化Helm chart。

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

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

應(yīng)用程序代碼及其helm chart位于單獨(dú)的git存儲庫中。這使我們可以分別對它們進(jìn)行版本控制。

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

我們與構(gòu)建或修改其代碼的Apache Kafka或Redis之類的系統(tǒng)應(yīng)用程序的工作方式有所不同。也就是說，我們沒有兩個git存儲庫，因為Docker tag只是Helm chart版本控制的一部分。如果我們曾經(jīng)更改了docker tag進(jìn)行升級，我們將在chart標(biāo)簽中增加主要版本號。

4.Liveliness和Readiness探針(雙刃劍)

Kubernetes的liveliness和readiness探測是自動解決系統(tǒng)問題的的優(yōu)秀特性。他們可以在發(fā)生故障時重新啟動容器，并將流量從不正常的實例中轉(zhuǎn)移出去。但在某些故障情況下，這些探測可能成為一把雙刃劍，影響應(yīng)用程序的啟動和恢復(fù)，尤其是消息中間件或數(shù)據(jù)庫等有狀態(tài)應(yīng)用程序。

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

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

因此，擇優(yōu)的方法是評估initialDelaySeconds字段的值，以便更好地平衡您在Kubernetes中尋求的彈性和應(yīng)用程序在所有故障情況下(磁盤故障、網(wǎng)絡(luò)故障、系統(tǒng)崩潰等)成功啟動所需的時間

更新*：如果您使用的是最新版本，Kubernetes引入了第三種探針類型，稱為“啟動探針”，以解決此問題*](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)*。在1.16的alpha版本和1.18的beta版本后是可用的。

在容器啟動之前，啟動探針將禁用readiness與liveliness檢查，以確保應(yīng)用程序的啟動不會中斷。

5.對外的External的IP

我們了解到，使用external IP暴露服務(wù)會對內(nèi)核的連接跟蹤機(jī)制造成巨大負(fù)荷。除非規(guī)劃詳細(xì)，考慮周全，否則一旦規(guī)模上去，那么它只會崩潰。

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

然而，這個conntrack表有其局限性。一旦達(dá)到這個限制，Kubernetes集群(底層的操作系統(tǒng)內(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é)點(diǎn)，這樣您的靜態(tài)IP的傳入連接遍及整個群集。因此，如果您的集群有大量的機(jī)器，那么累積起來就可以有一個大的conntrack表來處理大量傳入的連接。

早在2017年成立之初，這一切就讓我們望而卻步，但最近，Calico在2019年對此進(jìn)行了詳細(xì)研究(https://www.projectcalico.org/when-linux-conntrack-is-no-longer-your-friend/)。

6.您真的需要Kubernetes嗎?

三年過去了，我們?nèi)匀幻刻於荚诓粩嗟匕l(fā)現(xiàn)和學(xué)習(xí)新的東西。kubernetns是一個復(fù)雜的平臺，有其自身的一系列挑戰(zhàn)，特別是構(gòu)建和維護(hù)環(huán)境方面的。它將改變你的設(shè)計、思維、架構(gòu)，并將需要提高你的團(tuán)隊能力以滿足架構(gòu)轉(zhuǎn)型。

然而，如果你在云端并且能夠?qū)ubernetes用作“service”，它可以減輕平臺維護(hù)帶來的大部分開銷，例如“如何擴(kuò)展內(nèi)部網(wǎng)絡(luò)CIDR?”。或“如何升級我的Kubernetes版本?”

今天，我們意識到你需要問自己的第一個問題是“你真的需要Kubernetes嗎?”。這可以幫助您評估您所遇到的問題以及Kubernetes解決該問題的重要性。

Kubernetes轉(zhuǎn)型并沒有想象中的那么簡單，那么廉價。您為此付出的代價必須真正證明“您的”應(yīng)用及其如何利用該平臺。如果滿足這些條件，那么Kubernetes可以極大地提高您的生產(chǎn)力。

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

原文：https://medium.com/better-programming/3-years-of-kubernetes-in-production-heres-what-we-learned-44e77e1749c8