Kubernetes實踐

Kubernetes已經成為我們立足于基礎設施降低技術實現門檻的重要手段與組成部分：

• 推動Docker實施
• 簡化容器管理
• 引導開發人員了解基礎設施
• 實現持續集成與交付

為了實現以上目標，我們從根本上采納Kubernetes并將自身DevOps團隊轉化為云平臺團隊，并以容器與微服務作為技術形式。其中包括構建一系列工具以解決自身長期面對的原有技術問題。

問題所在

最大的難題在于，云計算仍是種新生事物，而我們也還非常年輕。我們在起步之初仍然秉持著使用傳統數據中心的心態。我們自行管理全部服務：MySQL、Cassandra、Aerospike、Memcache以及其它種種。我們設置虛擬機的方式與大家使用傳統服務器的方式非常相似，在其中安裝我們的應用程序并利用Nagios或者Ganglia對其加以管理。

遺憾的是，這種思維方式與以云為核心的理念可以說完全對立。相較于云方案以服務為形式的思路，我們一直立足于服務器思考問題。另外，相較于利用自動規模伸縮、微服務或者受管虛擬機等現代云方案，我們更多使用腳本化設置、服務器部署并盡可能避免供應商鎖定狀況的發生。

這些方式本身并不是不好，只是往往效率不甚理想。這類方式并不能充分發揮變更所能帶來的優勢，而云卻能夠快速實現變更并將其納入業務流程。這同時也意味著在必須做出變更時，這些變化因素對我們來說可謂數據中心正常運行的天敵，但在云端來看它們卻僅僅處于能夠小規模快速起效的調整舉措。

解決方案

以Kubernetes為工具促進Docker實施

隨著Docker逐步成為技術行業中的一大重要力量，ShareThis公司的工程師們也開始對其進行測試并取得了良好的收效。事實很快證明，我們需要在企業中為每款應用部署與之相匹配的容器，從而顯著簡化開發環境下的測試工作。

某些應用能夠更快融入到Docker環境當中，這是因為它們本身比較簡單并且與其它系統組件的關聯性較弱。對這些關聯性不強的應用，我們得以利用Fig（Fig正是Docker Compose的初始名稱）對其加以管理。當然，我們的大部分數據通道或者關聯性應用還是太過粗糙，并不能夠直接實現Docker化。在這種情況下，單憑Docker的力量顯然無法解決問題。

2015年年末，我們對于原有基礎設施的不滿情緒終于積累到了臨界點。為了徹底獲得應對能力，我們開始評估Docker工具、ECS、Kubernetes以及Mesosphere。我們很快得出結論，發現Kubernetes擁有更為穩定的運行表現，而且能夠為我們的基礎設施帶來較競爭對手更出色的用戶友好度。作為一家企業，我們得以輕松實現將全部基礎設施遷移至Kubernetes之上的目標，并以此為基礎進一步實現基礎設施與Docker間的合并。

工程師們最初對抱有懷疑態度。然而在親眼見證了應用程序規模能夠輕松達到每應用數百個實例的顯著成效之后，他們開始歡呼雀躍。現在，推動我們向Docker邁進的不僅是固有痛點，同時技術層面的巨大潛力也真正調動起了我們的積極性。這使我們得以快速實現原本極為困難的負載遷移。目前，我們已經將Kubernetes運行在多個蔥黃人的65套大型虛擬機系統當中，并計劃在未來幾個月內將這一數字進一步提升至100套。我們的Kubernetes集群每天并行處理著8000萬條請求，而未來數月我們計劃將這一處理能力直接提升至每天20億條請求。

利用Kubernetes作為工具管理容器

我們最初計劃利用Docker處理開發任務，而非大規模將其引入生產環境。其中最大的矛盾點在于，我們并沒有以規模化方式管理Docker組件的能力——具體包括了解哪些容器運行在哪些位置、當個部署版本正處于運行狀態、某款應用的當前狀態如何以及如何管理子網與VPC等等。面對這些難題，我們根本沒辦法利用其作為生產平臺。很明顯，我們需要龐大的工具供應解決上述問題。

而在審視Kubernetes時，我們發現其中擁有幾大能夠立刻抓住用戶眼球的關鍵特性：

• 可以被輕松安裝在AWS之上（而我們的全部應用亦運行于此）
• Dockerfile可通過一個yaml/json文件為復制控制器提供目錄路徑
• 各Pod能夠輕松實現數量層面的規模伸縮
• 我們能夠輕松在Kubernetes集群當中對AWS之上的虛擬機數量進行規模伸縮
• 滾動部署與回滾機制建立于工具體系之內
• 每個Pod都可通過運行狀態檢查實現監控
• 服務端點受該工具管理
• 擁有積極且充滿活力的技術社區

遺憾的是，工具供應的最大問題在于其無法適應我們的原有基礎設施——其只能提供一套作為遷移目標的潛在基礎設施方案。另外，一系列網絡局限使得我們無法直接將自己的應用程序轉移至新的VPC之上。再有，對如此眾多的應用程序進行重新調整要求開發人員們不得不面對眾多原本通常由系統管理員以及運維團隊負責處理的問題。

以Kubernetes為工具引導開發人員熟悉基礎設施

當我們決定由原本的Chef平臺轉向Kubernetes時，我覺得我們那時候還并不理解自身可能面對的各類潛在問題。我們實際上一直在以各種不同的方式利用各種不同的網絡配置進行服務器運行，而且其整體設計思路與Kubernetes VPC的精簡風格完全不符。

在生產環境下，我們跨越多個區域運行有AWS VPC與AWS經典服務。這意味著我們需要面向多種不同應用程序管理大量擁有不同訪問控制機制的子網體系。我們新近上線的應用程序非常安全，而且并不具備公共端點。這意味著我們擁有的是一整套VPC互連、網絡地址翻譯（簡稱NAT）以及以不同配置運行著的代理機制的復雜集合。

在Kubernetes的世界當中，VPC是惟一的組成部分。所有Pod在理論層面上都能夠彼此通信，而服務端點也經過明確定義。開發人員們能夠輕松解決部分細節問題，同時消除大部分運維需求。

我們最終決定將全部基礎設施/DevOps開發人員轉變成應用程序開發人員（不開玩笑）。我們在雇傭之初就要求他們具備開發技術基礎而非運維技術基礎，因此這項決策其實并不像聽起來那么不切實際。

在此之后，我們決定將整體工程技術部門轉型為運維部門。開發人員天然具備出色的靈活性，他們熱愛挑戰并樂于學習。這一點非常重要。就在1個月之后，我們的企業已經由原本擁有數位DevOps人員的狀態，成功轉化成每名工程師都有能力對業務架構進行修改。

而針對網絡、產品化、問題解決、根源分析等目標的人員培訓工作也順利使得Kubernetes以規模化方式上線。在頭一個月里，我一直在抓耳撓腮地反思自己的決定會不會帶來大麻煩。但兩個月之后，可行性已經開始初步顯現。三個月后，我們每周能夠實現十次部署。四個月賓，每周40款應用順利上線。當時我們有30%的應用程序已經順利完成遷移，這樣的結果豈止出色，簡直令人難以置信。Kubernetes讓我們得以從一家“被基礎設施拖累”的企業成功轉型成為一家“受基礎設施推動”的企業。

以Kubernetes為手段實現持續集成與交付

我們是如何實現每周超過40項部署任務的？簡單來講，就是在遷移的同時實現了技術集成與部署（簡稱CI/CD）能力。我們部署在Kubernetes中的第一款應用是Jenkins，而在此之后每款介入其中的應用都被添加到Jenkins內。隨著工作的不斷推進，我們得以將Kubernetes內的Pod添加以及移除之前的一切工作都由Jenkins以自動化方式實現，而且其實施速度甚至超過了我們的追蹤能力。有趣的是，我們的規模伸縮難題現在已經變成另一種困擾——我們希望一次性推出的變更太多，人們需要排隊等待自己的變更按順序上線。我們目前的目標是每周通過新基礎設施實現100次部署。如果我們能夠繼續推進遷移工作并立足于Kubernetes與Jenkins保持這種持續集成/交付流程，那么這一目標完全可以達成。

未來展望

接下來我們需要徹底完成遷移任務。這方面問題已經多數得到解決，而其中最麻煩的部分其實是當前手頭的工作比較單調乏味。將負載從原有基礎設施中遷移出去意味著我們需要變更網絡配置，從而實現面向Kubernetes VPC以及跨越各區域的訪問能力。這仍然是一項嚴峻挑戰，而我們也在積極加以解決。

另外，一部分服務在Kubernetes中的表現并不盡如人意——例如狀態化分布式數據庫。幸運的是，我們通常可以將這些負載遷移至第三方平臺并由其負責打理。在此輪遷移工作結束時，我們將只需要運行Kubernetes之上的各Pod，這也意味著我們的基礎設施將得到進一步簡化。

當然，天下沒有免費的午餐; 將全部基礎設施遷移至Kubernetes意味著我們需要雇傭水平高超的Kubernetes技術專家。我們的團隊已經按照基礎設施形式進行重組，他們也正忙于通過應用程序開發（這也應該是他們的本職工作）實現業務價值。然而，我們目前還不具備能夠始終緊跟Kubernetes與云計算最新特性的工程師隊伍。

考慮到這一點，我們已經任命一名工程師建立新的“云平臺團隊”，并將招聘幾位新成員填充進來。他們將負責開發相應工具，幫助我們借此更好地同Kubernetes相交互，同時管理全部云資源。除此之外，他們還將對Kubernetes源代碼以及部分Kubernetes SIG做出調整，如果可能還需要為該開源項目提供代碼貢獻。

總結陳詞

總結來講，Kubernetes給人的第一印象似乎有點生人勿近的意味，但其實際復雜程度與顛覆性水平并不像我們想象的那么夸張。而在另一方面，Kubernetes也給我們帶來了豐厚的回報——讓我們成為一家能夠根據客戶愿望以最快速度做出反應的企業。

原文鏈接： Kubernetes: ShareThis: Kubernetes In Production