[[343163]]

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

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

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

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

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

1. 基于Java的APP容器化問(wèn)題

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

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

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

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

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

2. Kubernetes升級(jí)

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

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

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

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

準(zhǔn)備重新設(shè)計(jì)整個(gè)構(gòu)建和部署的pipelines。我們的構(gòu)建過(guò)程和部署必須經(jīng)歷一個(gè)基于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ì)一種將所有這些鏈接在一起的方法。

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

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

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

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

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

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

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

唯一的解決方案是配置initialDelaySeconds liveliness探針設(shè)置，以在容器啟動(dòng)后延遲探測(cè)。但是，當(dāng)然，問(wèn)題在于很難對(duì)此加以說(shuō)明。有些恢復(fù)甚至需要一個(gè)小時(shí)，因此我們需要提供足夠的空間來(lái)解決這一問(wèn)題。但是增加的越多initialDelaySeconds，恢復(fù)速度就越慢，因?yàn)樵趩?dòng)失敗期間，Kubernetes需要更長(zhǎng)的時(shí)間來(lái)重新啟動(dòng)容器。

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

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

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

5.對(duì)外的External的IP

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

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

然而，這個(gè)conntrack表有其局限性。一旦達(dá)到這個(gè)限制，Kubernetes集群(底層的操作系統(tǒng)內(nèi)核)將無(wú)法再接受新的連接。在RHEL上，你可以這樣檢查。

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

解決這一問(wèn)題的一些方法是使用邊緣路由器連接多個(gè)節(jié)點(diǎn)，這樣您的靜態(tài)IP的傳入連接遍及整個(gè)群集。因此，如果您的集群有大量的機(jī)器，那么累積起來(lái)就可以有一個(gè)大的conntrack表來(lái)處理大量傳入的連接。

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

6.您真的需要Kubernetes嗎?

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

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

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

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

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

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