建站
咨詢
售后
建站咨詢
新聞中心
> Photo by Jessica Lewis on Unsplash
七里河網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,七里河網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為七里河上1000家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)公司要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的七里河做網(wǎng)站的公司定做！
我們于2017年開始構(gòu)建第一個(gè)Kubernetes集群1.9.4版本。 我們有兩個(gè)集群，一個(gè)集群在裸機(jī)RHEL VM上運(yùn)行，另一個(gè)集群在AWS EC2上運(yùn)行。
今天，我們的Kubernetes基礎(chǔ)架構(gòu)團(tuán)隊(duì)由分布在多個(gè)數(shù)據(jù)中心的400多個(gè)虛擬機(jī)組成。 該平臺(tái)托管高度可用的關(guān)鍵任務(wù)軟件應(yīng)用程序和系統(tǒng)，以管理具有近四百萬(wàn)個(gè)活動(dòng)設(shè)備的大型實(shí)時(shí)網(wǎng)絡(luò)。
Kubernetes最終使我們的生活變得更輕松，但是這一旅程是艱難的，是一種范式轉(zhuǎn)變。 不僅我們的技能和工具有了徹底的轉(zhuǎn)變，而且我們的設(shè)計(jì)和思維也得到了徹底的轉(zhuǎn)變。 我們必須采用多種新技術(shù)并進(jìn)行大量投資，以提高和提高我們的團(tuán)隊(duì)和基礎(chǔ)架構(gòu)的技能。
回顧三年來(lái)，Kubernetes在生產(chǎn)中運(yùn)行了三年，這是我們?nèi)沼浿械闹匾n程。
1. Java應(yīng)用程序的奇怪案例
在微服務(wù)和容器化方面，工程師傾向于避免使用Java，這主要是由于Java臭名昭著的內(nèi)存管理。 但是，現(xiàn)在情況發(fā)生了變化，多年來(lái)Java的容器兼容性得到了改善。 畢竟，無(wú)所不在的系統(tǒng)（例如Apache Kafka和Elasticsearch）在Java上運(yùn)行。
回顧2017-18年度，我們有一些應(yīng)用程序在Java版本8上運(yùn)行。這些應(yīng)用程序通常很難理解Docker等容器環(huán)境，并因堆內(nèi)存問(wèn)題和異常的垃圾收集趨勢(shì)而崩潰。 我們了解到，這是由于JVM無(wú)法使用Linux cgroup和命名空間（它們是容器化技術(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)，但無(wú)可否認(rèn)的是，與Python或Go等同行相比，Java在占用內(nèi)存和啟動(dòng)速度慢方面仍然享有不良聲譽(yù)。 這主要是由JVM的內(nèi)存管理和類加載器引起的。
今天，如果我們必須選擇Java，請(qǐng)確保它的版本為11或更高。 并且我們的Kubernetes內(nèi)存限制在JVM最大堆內(nèi)存（-Xmx）之上設(shè)置為1GB，以留有余量。 也就是說(shuō)，如果JVM使用8GB的堆內(nèi)存，則我們對(duì)該應(yīng)用程序的Kubernetes資源限制為9GB。 這樣，生活會(huì)更好。
2. Kubernetes生命周期升級(jí)
Kubernetes生命周期管理（例如升級(jí)或增強(qiáng)功能）非常繁瑣，尤其是如果您已在裸機(jī)或VM上構(gòu)建了自己的集群。 對(duì)于升級(jí)，我們已經(jīng)意識(shí)到，最簡(jiǎn)單的方法是使用最新版本構(gòu)建新集群，并將工作負(fù)載從舊版本過(guò)渡到新版本。 就地節(jié)點(diǎn)升級(jí)所做的努力和計(jì)劃是不值得的。
Kubernetes具有多個(gè)移動(dòng)部件，需要與升級(jí)保持一致。 從Docker到Calico或Flannel之類的CNI插件，您都需要仔細(xì)地將它們拼湊在一起才能正常工作。 盡管像Kubespray，Kubeone，Kops和Kubeaws這樣的項(xiàng)目使它變得更容易，但它們都有缺點(diǎn)。
我們?cè)赗HEL VM上使用Kubespray構(gòu)建了集群。 Kubespray非常棒，它具有用于構(gòu)建，添加和刪除新節(jié)點(diǎn)，升級(jí)版本的手冊(cè)，以及我們?cè)谏a(chǎn)環(huán)境中操作Kubernetes所需的幾乎所有內(nèi)容。 但是，升級(jí)手冊(cè)附帶了免責(zé)聲明，可防止我們跳過(guò)次要版本。 因此，必須經(jīng)過(guò)所有中間版本才能達(dá)到目標(biāo)版本。
要點(diǎn)是，如果您打算使用Kubernetes或已經(jīng)在使用Kubernetes，請(qǐng)考慮生命周期活動(dòng)以及您的解決方案如何解決這一問(wèn)題。 構(gòu)建和運(yùn)行集群相對(duì)容易一些，但是生命周期維護(hù)是一個(gè)全新的游戲，具有多個(gè)活動(dòng)部分。
3.構(gòu)建和部署
準(zhǔn)備重新設(shè)計(jì)整個(gè)構(gòu)建和部署管道。 我們的構(gòu)建過(guò)程和部署必須經(jīng)歷Kubernetes世界的完整轉(zhuǎn)型。 不僅在Jenkins管道中進(jìn)行了大量的重組，而且還使用了諸如Helm之類的新工具，對(duì)新的git流和構(gòu)建進(jìn)行了策略化，標(biāo)記了docker映像，并對(duì)helm部署chart進(jìn)行了版本控制。
您不僅需要維護(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)行版本控制。 （語(yǔ)義版本控制）
· 然后，我們將Chart版本的映射與應(yīng)用程序版本一起保存，并使用它來(lái)跟蹤發(fā)布。 因此，例如，app-1.2.0部署有Charts-1.1.0。 如果僅更改Helm值文件，則僅更改Chart的補(bǔ)丁程序版本。 （例如，從1.1.0到1.1.1）。 所有這些版本均由每個(gè)存儲(chǔ)庫(kù)RELEASE.txt中的發(fā)行說(shuō)明規(guī)定。
· 我們未構(gòu)建或修改其代碼的Apache Kafka或Redis等系統(tǒng)應(yīng)用程序的工作方式有所不同。 也就是說(shuō)，我們沒(méi)有兩個(gè)git存儲(chǔ)庫(kù)，因?yàn)镈ocker標(biāo)簽只是Helm chart版本控制的一部分。 如果我們更改了docker標(biāo)簽以進(jìn)行升級(jí)，則會(huì)在圖表標(biāo)簽中增加主要版本。
4.Liveness和Readiness就緒探針（雙刃劍）
Kubernetes的活躍性和就緒性探查是自動(dòng)解決系統(tǒng)問(wèn)題的出色功能。 他們可以在發(fā)生故障時(shí)重新啟動(dòng)容器，并從不正常的實(shí)例轉(zhuǎn)移流量。 但是，在某些故障情況下，這些探測(cè)可能會(huì)變成一把雙刃劍，并會(huì)影響應(yīng)用程序的啟動(dòng)和恢復(fù)，尤其是有消息的應(yīng)用程序，例如消息平臺(tái)或數(shù)據(jù)庫(kù)。
我們的Kafka系統(tǒng)就是這個(gè)受害者。 我們運(yùn)行了一個(gè)3 Broker 3 Zookeeper狀態(tài)集，該狀態(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í)間，生動(dòng)性探針將不斷失敗，從而向Kafka發(fā)出終止信號(hào)以重新啟動(dòng)。 這阻止了Kafka修改索引并完全啟動(dòng)。
唯一的解決方案是在實(shí)時(shí)探針設(shè)置中配置initialDelaySeconds，以在容器啟動(dòng)后延遲探針評(píng)估。 但是，當(dāng)然，問(wèn)題在于很難對(duì)此加以說(shuō)明。 有些恢復(fù)甚至需要一個(gè)小時(shí)，因此我們需要提供足夠的空間來(lái)解決這一問(wèn)題。 但是，增加initialDelaySeconds的次數(shù)越多，彈性的速度就越慢，因?yàn)樵趩?dòng)失敗期間Kubernetes需要更長(zhǎng)的時(shí)間來(lái)重新啟動(dòng)容器。
因此，中間的目的是評(píng)估initialDelaySeconds字段的值，以使其在您在Kubernetes中尋求的彈性與應(yīng)用程序在所有故障情況（磁盤故障，網(wǎng)絡(luò)故障，系統(tǒng)崩潰等）下成功啟動(dòng)所花費(fèi)的時(shí)間之間取得更好的平衡 ）
更新：如果您使用的是最新的最新版本，Kubernetes引入了第三種探針類型，稱為"啟動(dòng)探針"，以解決此問(wèn)題。 從1.16版開始提供alpha版本，從1.18版開始提供beta版本。
啟動(dòng)探針會(huì)禁用就緒性和活動(dòng)性檢查，直到容器啟動(dòng)為止，以確保應(yīng)用程序的啟動(dòng)不會(huì)中斷。
5.公開外部IP
我們了解到，使用靜態(tài)外部IP公開服務(wù)會(huì)對(duì)內(nèi)核的連接跟蹤機(jī)制造成巨大損失。 除非進(jìn)行徹底計(jì)劃，否則它只會(huì)按比例分解。
我們的集群在Kubernetes內(nèi)的路由協(xié)議上運(yùn)行在Calico for CNI和BGP上，并與邊緣路由器對(duì)等。 對(duì)于Kubeproxy，我們使用IP Tablesmode。 我們?cè)贙ubernetes中托管著龐大的服務(wù)，該服務(wù)通過(guò)每天處理數(shù)百萬(wàn)個(gè)連接的外部IP公開。 由于來(lái)自軟件定義網(wǎng)絡(luò)的所有SNAT和偽裝，Kubernetes需要一種機(jī)制來(lái)跟蹤所有這些邏輯流。 為此，它使用內(nèi)核的Conntrack和netfilter工具管理與靜態(tài)IP的這些外部連接，然后將其轉(zhuǎn)換為內(nèi)部服務(wù)IP，然后轉(zhuǎn)換為您的pod IP。 這全部通過(guò)conntrack表和IP表完成。
但是，此conntrack表有其局限性。 一旦達(dá)到限制，您的Kubernetes集群（位于下面的OS內(nèi)核）將不再能夠接受新連接。 在RHEL上，您可以通過(guò)這種方式進(jìn)行檢查。
$ sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_maxnet.netfilter.nf_conntrack_count = 167012
net.netfilter.nf_conntrack_max = 262144
解決此問(wèn)題的一些方法是使用邊緣路由器對(duì)等多個(gè)節(jié)點(diǎn)，以使到您的靜態(tài)IP的傳入連接遍及整個(gè)群集。 因此，如果您的集群中有大量的計(jì)算機(jī)，則累積起來(lái)，您可以擁有一個(gè)大的conntrack表來(lái)處理大量的傳入連接。
早在2017年成立之初，這一切就讓我們望而卻步，但最近，Calico在2019年對(duì)此進(jìn)行了詳細(xì)研究，標(biāo)題為"為什么conntrack不再是您的朋友"。
您絕對(duì)需要Kubernetes嗎？
三年過(guò)去了，我們?nèi)匀幻刻炖^續(xù)發(fā)現(xiàn)和學(xué)習(xí)新知識(shí)。 它是一個(gè)復(fù)雜的平臺(tái)，具有自己的一系列挑戰(zhàn)，尤其是在構(gòu)建和維護(hù)環(huán)境方面的開銷。 它將改變您的設(shè)計(jì)，思維，架構(gòu)，并需要提高技能和擴(kuò)大團(tuán)隊(duì)規(guī)模以適應(yīng)轉(zhuǎn)型。
但是，如果您在云上并且能夠?qū)ubernetes用作"服務(wù)"，則可以減輕平臺(tái)維護(hù)帶來(lái)的大部分開銷，例如"如何擴(kuò)展內(nèi)部網(wǎng)絡(luò)CIDR？"。 或"如何升級(jí)我的Kubernetes版本？"
今天，我們意識(shí)到，您需要問(wèn)自己的第一個(gè)問(wèn)題是"您是否絕對(duì)需要Kubernetes？" 這可以幫助您評(píng)估您所遇到的問(wèn)題以及Kubernetes解決該問(wèn)題的重要性。
Kubernetes轉(zhuǎn)型并不便宜。 您為此支付的價(jià)格必須確實(shí)證明"您的"用例及其如何利用該平臺(tái)。 如果可以，那么Kubernetes可以極大地提高您的生產(chǎn)力。
記住，為了技術(shù)而技術(shù)是沒(méi)有意義的。
本文翻譯自Komal Venkatesh Ganesan的文章《3 Years of Kubernetes in Production–Here's What We Learned》
文章標(biāo)題：在生產(chǎn)環(huán)境使用Kubernetes三年后我學(xué)到的東西
文章位置：http://www.5511xx.com/article/dheidjg.html
