[[343163]]

本文轉載自微信公眾號「新鈦云服」，作者祝祥 。轉載本文請聯系新鈦云服公眾號。  

我們于2017年開始構建第一個基于1.9.4版本的Kubernetes集群。至今，我們已經有兩個集群，一個集群在裸機RHEL VM上運行，另一個集群在公有云AWS EC2上運行。

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

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

回顧三年來，Kubernetes在我們的生產中運行了三年，這也是本文將會將的重點內容。

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

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

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

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

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

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

2. Kubernetes升級

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

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

以上可得出的結論是，如果您打算使用Kubernetes或已經在使用Kubernetes，請考慮生命周期管理。構建和運行集群相對容易一些，但是Kubernetes的生命周期管理則相對復雜，涉及內容較多。

3.構建和部署

準備重新設計整個構建和部署的pipelines。我們的構建過程和部署必須經歷一個基于Kubernete的完整轉型。不僅在Jenkins pipelines中進行了大量的重組，還使用了諸如Helm這樣的新工具，制定新的git流和構建策略，docker 鏡像的tag標簽，以及版本化Helm chart。

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

經過幾次迭代，我們決定采用以下設計。

應用程序代碼及其helm chart位于單獨的git存儲庫中。這使我們可以分別對它們進行版本控制。

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

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

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

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

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

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

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

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

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

5.對外的External的IP

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

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

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

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

解決這一問題的一些方法是使用邊緣路由器連接多個節點，這樣您的靜態IP的傳入連接遍及整個群集。因此，如果您的集群有大量的機器，那么累積起來就可以有一個大的conntrack表來處理大量傳入的連接。

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

6.您真的需要Kubernetes嗎?

三年過去了，我們仍然每天都在不斷地發現和學習新的東西。kubernetns是一個復雜的平臺，有其自身的一系列挑戰，特別是構建和維護環境方面的。它將改變你的設計、思維、架構，并將需要提高你的團隊能力以滿足架構轉型。

然而，如果你在云端并且能夠將Kubernetes用作“service”，它可以減輕平臺維護帶來的大部分開銷，例如“如何擴展內部網絡CIDR?”。或“如何升級我的Kubernetes版本?”

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

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

記住，為了技術而技術是沒有意義的。

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