三年時間，這家公司最終承認Kubernetes太難

科技 01-24

作者 | Lisa

編輯 | 小智

雖然 Kubernetes 很火，但這家公司卻用三年時間親證：部署 Kubernetes 太難了，且很可能不建議其他人嘗試。

事件經過

Atlassian 是一家位於澳大利亞悉尼的企業，這家企業最初沒有銷售團隊，不靠融資就做到了市值百億美元，兩位創始者本來也是開發者出身，這家企業的技術實力起初就不弱，但卻在嘗試了 Kubernetes 三年後公開表示：「過去三年，部署 Kubernetes 的過程非常艱難，並且不推薦大家嘗試」。

眾所周知，Kubernetes 是谷歌開源的容器編排引擎，支持自動化部署、大規模可伸縮、應用容器化管理，很多細節不需要運維人員進行複雜的手工配置和處理，這是現在非常流行的容器管理和編排工具，幾乎好評如潮。這樣一款讓部署容器化應用更加簡單高效的工具，為什麼會讓這家企業給出如此評價呢？

這一切要從 Atlassian 的 Kubernetes 團隊首席工程師 Nick Young 近日接受媒體採訪說起。

不久前，Nick Young 曾在採訪中表示，雖然當初選擇 Kubernetes 的戰略是正確的（至少到現在也沒有發現其他可能的選擇），解決了現階段遇到的許多問題，但部署過程異常艱辛。

三年前，Kubernetes 還是一種非常新的技術，Atlassian 希望在 PaaS 平台做一些工作，重點在於讓開發人員不必關心底層應用部署細節，只需想好要什麼即可，比如要一個 Docker 鏡像和 PostgreSQL，PaaS 團隊將所有內容通過翻譯轉換為 Kubernetes 事務，編寫內容並生成 PostgreSQL，確保 Postgres 字元串和詳細信息都連接到 Kubernetes 的 pod，最終達到使用體驗儘可能接近筆記本電腦上運行內容的體驗。

準備階段

在決定使用 Kubernetes 之後，這家公司就開始進入準備階段，包括基礎知識儲備和團隊建設等。

子集管理

團隊建設工作並沒有耗費太多精力，由於整個團隊之前具備容器化經驗，因此在基礎知識學習方面相對輕鬆。在設計 Kubernetes 時，整個團隊首先將關注點放在基礎設施之上，考慮到未來業務增長的可能，整個團隊建議如果希望管理一個完整堆棧，那麼子集管理是非常重要的，這可以確保在某些需求出現時，只針對局部進行修改即可。

隔離

如果希望各層之間的修改和運行互不干擾，就需要保證層之間具有非常明確的邊界，也就是通常所說的隔離性，這也被列入整個團隊的準備工作之中。

過程受阻

在實際搭建中，Atlassian 遇到了各種問題。目前，該公司運行了大約 20 個 Kubernetes 集群，最大集群約有 14,000 個 vCPU 和 50TB 左右 RAM，運行了一大堆內部 CI 工具。

問題 1：etcd 限制

etcd 是 Kubernetes 提供的默認存儲系統，保存所有集群數據，使用時需要為 etcd 數據提供備份計劃。在這個過程中，Atlassian 首先遇到了 etcd 大小限制問題，etcd 存儲了每個 Kubernetes 集群配置和其他數據關鍵組件。如果 etcd 資料庫大小達到 2.1GB，那麼集群將轉為只讀模式。基本上，8 萬命名空間 100％將佔用 2.1GB 內存。

事實上，當命名空間達到 5 萬時，etcd 就開始放慢速度。最終，整個團隊的解決方法是將流量轉移到另一個集群，好在轉移過程相對比較順利。

問題 2：安全

Kubernetes 就像多年前的資料庫，如果沒有幾年最佳實踐經驗，恐怕難以部署到位。Nick Young 表示，解決安全問題非常重要且非常難，雖然 Kubernetes 有很多功能可供選擇，但默認設置不是很安全。

事實上，Kubernetes 系統提供三種認證方式：CA 認證、Token 認證和 Base 認證。雙向認證配置是最為嚴格和安全的集群安全配置方式，但這種方式在保證系統不受攻擊的情況下會帶來額外的性能損耗，因此一般都建議用非安全方式訪問 API Server，這種方式效率更高。所以，企業通常需要在安全和性能之間找到一個很好的平衡點。

建議

不要完全 DIY

回顧整個搭建過程，這家公司發現有很多工具可以代替曾經那些痛苦的過程。如今，主流雲供應商提供非常棒的管理和運維工具。在確保安全的前提下，企業可以考慮這些現成工具，這可以大大簡化整個搭建過程。

如果技術實力尚可，也有很多開源工具可以選擇，完全的 DIY 設計需要投入大量精力和資金，因此不建議完全自主搭建。

查驗失敗

除此之外，在 Kubernetes 的部署中，我們經常可以碰到容器鏡像沒有更新、集群資源不足、校驗錯誤、持久化卷掛載失敗等問題，開發人員可以使用一些簡單命令進行快速定位，比如，kubectl describe deployment/；kubectl describe replicaset/；kubectl get pods；kubectl describe pod/

；kubectl logs

--previous 等命令可以被用來定位常見的大部分失敗問題。

如果技術能力允許，也可以自己編寫一些 bash 腳本，自動化查驗失敗原因，顯示一些問題相關的 Kubernetes 信息，幫助開發者迅速定位問題原因。

總結

雖然 Kubernetes 部署很難，但只要開始就很難放棄，這家公司最終決定繼續使用 Kubernetes，並持續優化建設。

參考鏈接：

https://www.itnews.com.au/news/atlassian-admits-it-did-kubernetes-the-hard-way-517984