喜憂參半的 Kubernetes 生產之路

來自專欄 KubernetesMeetup 社區4 人贊了文章

原文作者：Oliver Thylmann

翻譯：夏天

校對：燈神

生而知之者，上也；學而知之者，次也；困而學之，又其次也——孔子（公元前 551 - 479年）

孔子認為，得上等智慧靠天賦，不學而懂；得二等智慧靠學習，一學即懂；得三等智慧靠磨練，歷經時移勢易，艱難險阻之後才有領悟。今天這篇文章，展示了一群 K8S 實施人員在 Kubernetes 生產之路上習得智慧的苦辣酸甜。

我們在生產環境下運營 Kubernetes 已經有一段時間了，也與像 Global traffic，Black Friday 和 Christmas sales 這樣的大公司有合作。這些公司都有嚴格的安全規則和多國協同工作的團隊。我們 7 * 24 全天候為每一個公司管理這些集群。可以說我們就是客戶專屬的 SRE 團隊。

這讓我們有了一個獨特視角，可以與大家分享我們經歷過的一些嘗試和挑戰。有些很苦澀，但是有些因為一開始就站在巨人和其他人的肩膀上，進展得很順利。然而無論苦澀還是開心，我們已經歷過了，回首往事都是件很有意思的事。

安全性問題

安全性是我們關注的重點，我們曾經參與編寫了 Kubernetes CIS Benchmarks，現在與許多其他一些 CIS Benchmarks（AWS 和 Docker）標準保持一致。雖然 RBAC 在 Kubernetes 1.6 和 1.7 中都只是測試版，但經過測試我們最終確定使用 Kubernetes 1.7 這個版本。由於我們將所有基礎架構組件託管在容器中，並且其中許多容器，例如 Calico Networking 作為 Kubernetes 管理的 pod 運行，所以「關閉特權容器」這條舊規則對我們來說是不可行的。（就像它不適用於大多數嚴肅的生產環境一樣）

我們將 RBAC 和 Pod 安全策略（PSP）結合起來，通過限制擴展安全上下文 ( security contexts）的使用來解決這個問題。一開始，我們以為這是一個合理的解決方案，直到開始嘗試，我們發現了一些小 bug（PSP 當時仍然處於 alpha 階段）。此外，沒有恰當的預設規則意味著之前幾乎沒有人使用過它。但這就是使用最新功能必須付出的代價。實踐證明，它對我們來說非常有效，其中社區關鍵人物的幫助也起到了重要作用。

最終我們解決了這個問題。從那時起，每個集群都被完全加固了。甚至有客戶使用 Calico 網路策略為不同團隊根據 namespace 來限制容器對外流向 NFS 的流量。

其實，我們也有點討厭安全掃描儀。所有集群 etcds 都完全加密，但在未加密的 EBS volume 上運行。理論上，這是沒有問題的，因為所有的內容都是加密的。但是安全掃描儀會注意到未加密的 EBS，並且會一直提醒你在安裝之前設置是不安全的。這是令人討厭的小問題之一。如果你知道 etcd，你肯定知道它的實時遷移有多麻煩。

更新問題

我們將基礎架構視為代碼，這意味著我們有完整的 CI / CD 來管理基礎架構組件，尤其是我們自己構建的組件。實際上，我們有一個補丁系統和一些小的和主要的更新，針對不同部署都有不同規則。但隨著時間的推移，我們了解到其實大部分規則都是為了確保部署。

現在我們的合同中甚至有一部分內容是，如果你的集群已經超過三個月沒有更新，我們的管理將不再適用。這是由一位客戶提出的，現在他自己就可以告訴他的團隊集群需要升級了，不然就麻煩了。這個內容特別有用，因為很多客戶團隊都不會特別重視更新工作，他們只會懵懂地說：「它還在工作呢，為什麼要更新？」

通用電氣 CEO Jack Welch 曾說過：「我一直相信，當一個機構內部的變化速度比外面的變化速度慢時，它的「死期」就在眼前，唯一的問題是什麼時候。」

這真是一個問題。我們發現大部分生產問題都存在於比較老的集群中。我們會針對所有客戶集群中的每個生產事件進行復盤，直到找到並修復根本問題，隨後把經驗推廣到所有客戶集群中。我們確定一定以及肯定我們只能有一種產品，就是用戶喜歡的那一種。也許客戶作為個體看到的問題會很少，但我們要讓他們跟我們一起升級。

安裝問題

試圖預測未來，就像在暗夜開著車賓士在沒有路燈的鄉間小路上，還一直往後窗看。——Peter F. Drucker（1909-2005）

我們可以在兩小時內在 AWS 上完成整個 Giant Swarm 安裝，在 Azure 上也差不多是這個時間，因為我們最近在 Azure 上推出了適用於生產的 Kubernetes。我們的客戶可以創建任意數量的集群。我們的優勢在於，我們可以在本地完成同樣的任務，但可悲的是我們仍然不得不說，在本地安裝設備需要一些時間。對於這件事，我總是開玩笑說：「安裝大約需要六個小時到六個月之間……那是不可能的。」

內部部署的問題關鍵是他們的內部環境都是不同的。比如 VPN 如何工作？跳轉主機怎麼樣？伺服器是否正確聯網？有 ILO access 嗎？對我們的許多客戶來說，內部部署具有實際價值，但客戶情況不同，內部部署就會完全不同，不能複製。如果你沒有集成 Load Balancer API（你可以根據規則獲得自己的 F5 網路 BIG-IP space 嗎？），也沒有適當標準化和支持 Kubernetes 的存儲解決方案，那就更一言難盡了。我們連接過 iSCSI，這對 Docker 和 NFS 來說有一些穩定性問題，並不能一直表現良好。現在，我們正在考慮 EMC Ipsilon 和 Rex-Ray 或 Rook，但它們都有各自的問題。如果有一個雲服務提供商能在上游提供一個好的動態提供商，那就可以說是很完美了。

負載測試問題

講講我們曾與客戶進行的一次負載測試吧。在測試一開始我們就嚇了一大跳，因為當進入負載測試時，什麼都還沒有做，集群就集體死亡了。儘管如此，我們的客戶團隊仍然習慣於舊的工作方式，他們表示已經知道「負載測試失敗」這個結果了，並說他們以後會再測一次……

一開始，我們不知道如何解決這個問題，直到我們刨根問底，揪出問題所在。首先，負載測試配置錯誤，並沒有產生 100,000 個並發用戶。相反，它每個地點產生了 100,000 個並發用戶，由於使用了三個源地點，導致出現了 300,000 個並發用戶。然後我們繼續深「挖」，發現在這個小集群中使用的 EC2 機器有 1Gbit 網卡，幾秒鐘後它們就飽和並死亡，流量從未到達集群層面。

身份驗證問題

從前有 ___。每天， ___。有一天 ___。因為，___。因為，___。直到最後___。——皮克斯講故事經典套路

我們的設置默認為證書身份驗證，由我們的 API 和 cert-operator 自動執行，後端基於 Vault。現在，很多公司都在用 Active Directory，它確實挺好用。我們希望讓客戶能通過它來進行身份驗證。

我們想通過 Kubernetes 支持的 OIDC 介面進行集成。所以首先，我們需要客戶升級到比較新版本的 ADFS，因為舊版本不提供任何 OIDC 端點。但是，當我們開始測試時，就遇到了自簽名證書的問題，所以我們開始用 Dex 進行測試。經過一段時間後，我們克服了這個問題，但是我們仍然遇到了 OIDC 端點的擴展 claims/scopes 問題。而且其實 Dex 並不關心用戶體驗 （如果你沒有運行 Tectonic 的話）。然後我們靈光一現，決定嘗試第三條路徑：Azure AD。

客戶在其本地 ADFS 和 Azure AD 之間進行了同步。通過與我們在微軟的朋友交談（很高興可以直接與他們在我們的 Slack 中交流）並檢查一些上游文檔，我們發現這是一個值得嘗試的解決方案。藉助微軟的一些幫助，解決了上游文檔中的一些開放問題，迅速有了思路。從那時起，我們所有客戶的集群都預先設置了 Azure AD 身份驗證。

共同成長

正如上面這些故事講的那樣，在 Kubernetes 生產的道路上，需要克服技術和組織方面存在的很多問題和挑戰。有些來得早，有些來得晚，有些因為規模，有些因為資源壓力。如果我們只與客戶建立最簡單的供應商與客戶的關係，就不會有這些喜憂參半的過往。我們很高興能與我們的客戶建立真正的夥伴關係，讓我們能夠陪伴彼此，共同成長。

我們希望通過分享我們的經驗，可以讓你感受下我們日常工作的苦樂，讓你也開始嘗試與客戶建立這樣的戰友感情。我想，等下次你見到我們時，我們會講更多 Kubernetes 生產戰線上奮鬥的故事給你聽吧。

原文鏈接：

https://thenewstack.io/the-bittersweet-road-to-kubernetes-production/