使用Kubernetes兩年來的經驗教訓

在Ridecell公司管理基礎設施團隊幾年後，我想在停下來休息時記錄下我的一些想法和經驗教訓。

Kubernetes不僅僅是炒作

我在Kubernetes領域裡活躍了很久，是以這并不出乎我的意料，但當某件事情被大肆宣傳的時候，仔細檢查一下總是好的。在兩年多的時間裡，我的團隊完成了從Ansible+Terraform到純Kubernetes的全面遷移，在這個過程中，我們的部署率增加了三倍多，同時将部署錯誤減少到“我都不記得上次是什麼時候發生的”的水準。我們還提高了操作可見性，大量無趣卻很重要的自動化任務，以及基礎設施中斷時的平均恢複時間。

Kubernetes并不是魔法，但如果被一個懂它的團隊使用，那它就是一個非常強大的工具。

Traefik + Cert-Manager + Ext-DNS組合很棒

Traefik作為Ingress控制器，Cert-Manager通過LetsEncrypt生成證書，External-DNS管理邊緣DNS記錄，這三個組合使得HTTP路由和管理像黃油一樣順暢。我一直對Traefik 2.0中删除了很多1.x注釋功能的選擇頗有微詞，但它們終于在2.2中回歸了，盡管以不同的形式。作為一個邊緣代理，Traefik是一個可靠的選擇，它具有出色的名額內建，是所有Ingress控制器中管理部件最少的，以及有一個反應迅速的開發團隊。Cert-Manager配合任意Ingress方案都是一個神奇的工具，如果你在Kubernetes叢集中做了TLS，但還沒開始使用，那現在就去了解下吧。External-DNS沒有其他兩個那麼受歡迎，但是對于自動化DNS記錄和實際比對的步驟來說，它的重要性不亞于其他兩個。

如果有什麼不同的話，這些工具實際上可能使得設定新的HTTPS端點變得太容易。多年來，我們最終使用了幾十個獨特的證書，這在Cert Transparency搜尋和LetsEncrypt自己的證書到期警告等方面産生了很多噪音。以後我将會仔細考慮哪些主機名可以作為全局配置的通配符證書的一部分，以減少正在使用的證書總數。

Prometheus很震撼，Thanos并非大材小用

這是我第一次使用Prometheus作為主要的度量系統，它不愧為該領域的首要工具。我們選擇Prometheus-Operator來管理它，這不失為一個好的選擇，讓我們更容易将抓取和規則配置分發到需要它們的應用中。（如果重來的話，）我會在一開始就使用Thanos。我原本以為使用它會過于大材小用，沒想到它是那麼容易配置，而且在跨區域查詢和減少Prometheus資源使用方面起了很大幫助，即使我們沒有直接使用主-主互備高可用的設定。

在使用該技術棧時我遇到的最大困擾是Grafana的資料管理，如何存儲群組合儀表闆。管理儀表闆的工具有了巨大的增長，例如YAML檔案、JSON檔案、Kubernetes自定義對象，以及你能想到的其他任何東西。但根源問題還是任何一個工具都很難從頭開始編寫一個儀表盤，因為Grafana有一百萬種不同的配置選項和面闆模式等等。我們最終将它作為一個有狀态的系統來處理，将所有的儀表闆進行分組管理，但我并不喜歡這種解決方案。這裡是否有一個更好的工作流程呢？

GitOps才是正道

如果你使用Kubernetes，那麼你應該使用GitOps。關于工具選擇有很多，最簡單的就是在你現有的CI系統中添加運作kubectl apply的作業，一直到使用專用的系統例如ArgoCD和Flux。不過我堅定地站在ArgoCD陣營，它是一個可作為開始的可靠的選擇，而且在過去的這些年裡它越來越好。就在這周，GitOps-engine的第一個版本已經上線，其将ArgoCD和Flux放在一個共享的底層系統上，是以現在更快更好了。如果你不喜歡這些工具的工作流，你現在甚至可以更容易建構新的。在幾個月前我們遇到了一次意外的災難恢複遊戲日，因為有人不小心删除了測試叢集中的大部分命名空間，多虧了GitOps，我們的恢複方式是在bootstrap庫中執行make apply，然後等待系統自行重建。話說回來，對于一些不能在Git中生存的有狀态資料的Velero備份也是很重要的（比如cert-manager的證書，它雖然可以重新簽發，但你可能會遇到LetsEncrypt的速率限制）。

我們遇到最大的問題就是選擇将所有核心基礎設施儲存在一個存儲庫中。我依然認為使用一個單一的庫是正确的設計，但我将會将不同的事物劃分到不同的ArgoCD執行個體中，而不是像現在将所有都放在一個“infra”的執行個體中。使用單個執行個體導緻更長的收斂時間和嘈雜的UI，而且如果我們習慣了正确地分割我們的Kustomize定義的話，它就沒有多大益處了。

我們應用建立更多的Operator

我從一開始就積極發展自定義Operator，且我們在這方面取得了巨大的成功。我們從一個自定義資源和控制器開始，用于部署我們的主要網絡應用，并慢慢擴充到該應用和其他應用所需的所有其他自動化。使用普通的Kustomize和ArgoCD進行簡單的基礎架構服務效果很好，但是當我們想要控制外部事物時（例如從Kubernetes建立AWS IAM角色，通過kiam來使用），或者當我們需要某種級别的狀态機來控制這些事物時（例如帶有SQL遷移的Django應用部署），我們都會需要用到Operator。作為其中的一部分，我們還為我們所有的自定義對象和控制器建立了一個非常徹底的測試套件，這極大地提高了操作的穩定性和我們自己對系統正确工作的确定性。

目前有越來越多的方式來建構Opeator，但我仍然對kubebuilder相當滿意（盡管公平地說，我們确實随着時間的推移大幅修改了項目結構，是以說它使用的是controller-runtime和controller-tools比kubebuilder本身更公平）。無論你最喜歡使用哪種語言和架構，都可能有可用的Operator工具包，你絕對應該使用它。

Secret管理仍是難題

Kubernetes有自己的Secret對象，用于在運作時管理秘密資料，與容器或與其他對象一起使用，而且這個系統工作得很好。但是Secret的長期工作流程還是有點亂。把一個原始的Secret送出到Git是很糟糕的，原因有很多，希望我不需要列舉，那麼我們如何管理這些對象呢？我的解決方案是開發一個自定義的EncryptedSecret類型，它使用AWS KMS對每個值進行加密，同時在Kubernetes中運作的控制器像往常一樣将其解密回正常的Secret，還有一個用于解密-編輯-再加密循環的指令行工具。使用 KMS意味着我們可以通過IAM規則限制KMS密鑰的使用來做通路控制，并且隻加密值，讓檔案有合理的差異性。現在有一些基于Mozilla Sops的社群Operator提供了大緻相同的工作流，盡管Sops在本地編輯工作流程上有點令人沮喪。總的來說，這個領域還需要很多努力，人們應該期待一個可審計、可版本化、可代碼審查的工作流，就像在GitOps世界裡的所有事情一樣。

作為一個相關的問題，Kubernetes的RBAC模型的弱點在Secrets上表現得最為明顯。幾乎在所有情況下，被用于一個事物的Secret必須和使用它的事物在同一個命名空間中，這往往意味着很多不同僚物的Secret最終會在同一個命名空間中（資料庫密碼、廠商API令牌、TLS證書），如果你想給某人（或某事，同樣的問題适用于Operator）通路其中一個，他們就會獲得所有的通路權限。讓你的命名空間盡可能的小，任何可以放在它自己的命名空間的東西，都去做吧。你的RBAC政策會感謝你現在的做法。

原生CI和日志分析仍是開放性問題

我遇到的兩大生态系統坑就是CI和日志分析。有很多部署在Kubernetes的CI系統，例如Jenkins、Concourse、Buildkite等。但感覺完全類原生的解決方案很少。JenkinsX可能是最接近原生體驗的，但它是建立在非常大的複雜性上，我覺得非常可惜。Prow本身也是非常原生的，但定制化很多，是以也不是一個容易上手的工具。Tekton Pipelines和Argo Workflows都有原生CI系統的低級管道，但是找到一種方法将其暴露給我的開發團隊從來沒有超出理論操作人員的範圍。Argo-CI似乎已經被放棄了，但Tekton團隊似乎正在積極地追蹤這個用例，是以我對它的一些改進充滿希望。

日志收集基本上是一個已解決的問題，社群集中在Fluent Bit上，将其作為一個DaemonSet發送給一些Fluentd pods，然後再發到你用來存儲和分析的任何系統上。在存儲方面，我們有ElasticSearch和Loki作為主要的開放競争者，每個都有自己的分析前端（Kibana和Grafana）。似乎主要還是最後一部分是我的挫敗感的來源。Kibana出現的時間更久，分析功能也很豐富，但你必須使用商業版來獲得基本的操作，比如使用者身份驗證和使用者權限仍然非常模糊。Loki要新得多，分析工具就更少了（子字元串搜尋和每行标簽搜尋），至今沒有任何針對權限的設計。如果你小心翼翼地確定所有的日志輸出是安全的，可以讓所有的工程師看到，這沒問題，但你要準備好在SOC/PCI等審計中遇到一些尖銳的問題。

結語

Kubernetes并不是很多人所說的那種可全套傳遞的解決方案，但是通過一些精心的工程設計和非凡的社群生态系統，它可以成為一個無與倫比的平台。花點時間學習每個底層元件，你将會在通往容器幸福的道路上走得很好，希望你在此過程中能避免我的一些錯誤。

原文連結：https://coderanger.net/lessons-learned/