解讀 KubeCon EU 2019 應用管理領域的新看點

Kubecon EU 2019 剛剛在巴塞羅那拉下帷幕，來自阿里巴巴經濟體的講師團，在大會上分享了互聯網場景下規模化 Kubernetes 集羣的各項落地經驗和教訓。所謂「獨行速而衆行遠」，從不斷髮展壯大的社區中，咱們看到愈來愈多的人擁抱開源，往標準演進，搭上了這趟開往雲原生的高速列車。

衆所周知，雲原生架構的中心項目是 Kubernetes，而 Kubernetes 則圍繞着「應用」來展開。讓應用部署得更好，讓開發者更高效，才能給團隊和組織帶來切實的利益，才能讓雲原生技術變革發揮更大的做用。

變革的勢頭既如洪水般吞沒着老舊封閉的內部系統，又如春雨般孕育出更多的新開發者工具。在本次 KubeCon 中，就出現了許多有關應用管理與部署的新知識。這些知識中有哪些想法和思路值得借鑑，讓咱們少走彎路？在它們背後，又預示着什麼樣的技術演進方向？

在本文中，咱們邀請到了阿里雲容器平臺技術專家、原 CoreOS 公司工程師、 K8s Operator 項目的核心做者之一鄧洪超，爲讀者精選了這次會議「應用管理」領域的精華內容來一一進行分析與點評。

The Config Changed

Kubernetes 上部署的應用通常會把配置存放到 ConfigMap 裏，而後掛載到 Pod 文件系統中去。當 ConfigMap 發生更改時，只有 Pod 裏掛載的文件會被自動更新。這種作法對某些會自動作熱更新的應用（好比 nginx）來講是 OK 的。可是，對於大多數應用開發者來講，他們更傾向於認爲更改配置要作一次新的灰度發佈、跟 ConfigMap 相關聯的容器應該作一次灰度升級。

灰度升級不只簡化了用戶代碼，加強了安全穩定性，更是體現了不可變基礎架構的思想。應用一旦部署，就再也不作變動。須要升級時，只要部署一個新版系統，驗證 OK 後再摧毀舊版就行了；驗證不經過時也容易回滾到舊版。

正是基於這樣的思路，來自 Pusher 的工程師們研發了 Wave，一款自動監聽 Deployment 相關聯的 ConfigMap/Secret 並隨之改動而觸發 Deployment 升級的工具。這款工具的獨特之處在於它會自動搜索該 Deployment PodTemplate 裏面的 ConfigMap/Secret，而後把裏面全部數據計算一次 hash 放到 PodTemplate annotations 裏面；當有變更時，會從新計算一次 hash 並更新 PodTemplate annotations，從而觸發 Deployment 升級。

無獨有偶，開源社區裏還有另外一款工具 Reloader 也作了相似的功能——不一樣的是，Reloader 還能讓用戶本身選擇填寫監聽哪幾個 ConfigMap/Secret。

分析與點評

升級不灰度，背鍋兩行淚。不管是升級應用鏡像仍是更改配置，都要記得作一次新的灰度發佈和驗證。

另外咱們也看到，不可變基礎架構給構建雲計算應用帶來了嶄新的視角。朝着這個方向發展，不只能讓架構更安全更可靠，更是能跟其餘主要工具結合好，充分發揮雲原生社區的做用，對傳統應用服務實現「彎道超車」。舉個例子，充分結合上面的 wave 項目和 Istio 中 weighted routing 功能，網站就能達到小部分流量對新版配置進行驗證的效果。

視頻連接：https://www.youtube.com/watch?v=8P7-C44Gjj8
/>

Server-side Apply

Kubernetes 是一個聲明式的資源管理系統。用戶在本地定義指望的狀態，而後經過 kubectl apply 去跟更新當前集羣狀態中被用戶指定的那一部分。然而它遠沒有聽起來那麼簡單...

原來的 kubectl apply 是基於客戶端實現的。Apply 的時候不能簡單地替換掉單個資源的總體狀態，由於還有其餘人也會去更改資源，好比 controllers、admissions、webhooks。那麼怎樣保證在改一個資源的同時，不會覆蓋掉別人的改動呢？

因而就有了現有的 3 way merge：用戶把 last applied state 存在 Pod annotations 裏，在下次 apply 的時候根據 (最新狀態，last applied，用戶指定狀態) 作 3 way diff，而後生成 patch 發送到 APIServer。可是這樣作仍是有問題！Apply 的初衷是讓個體去指定哪些資源字段歸他管理。

可是原有實現既不能阻止不一樣個體之間互相篡改字段，也沒有在衝突發生時告知用戶和解決。舉個例子，筆者原來在 CoreOS 工做時，產品裏自帶的 controller 和用戶都會去更改 Node 對象的一些特殊 labels，結果出現衝突，致使集羣出故障了只能派人去修。

這種克蘇魯式的恐懼籠罩着每個 k8s 用戶，而如今咱們終於迎來了勝利的曙光——那就是服務器端 apply。APIServer 會作 diff 和 merge 操做，不少本來易碎的現象都獲得瞭解決。更重要的是，相比於原來用 last-applied annotations，服務器端 apply 新提供了一種聲明式 API (叫 ManagedFields) 來明確指定誰管理哪些資源字段。而當發生衝突時，好比 kubectl 和 controller 都改同一個字段時，非 Admin（管理員）的請求會返回錯誤而且提示去解決。

分析與點評

媽媽不再用擔憂我 kubectl apply 了。雖然仍是 Alpha 階段，可是服務器端 apply 替代客戶端只是時間問題。這樣一來，不一樣組件同時更改同一資源將會變得更加安全可靠。

另外咱們也看到，隨着系統的發展，尤爲是聲明式 API 的普遍使用，在本地的邏輯將會變少，而在服務器端的則會變多。在服務器端有諸多好處：許多操做，好比 kubectl dry-run、diff，在服務器端實現會更簡單；提供 HTTP endpoint，這樣會更容易把 apply 這樣的功能構建到其餘工具中；把複雜邏輯放到服務器端實現和發佈，可以更容易作好管控，讓用戶享受到安全、一致、高質量的服務。

視頻連接：https://www.youtube.com/watch?v=1DWWlcDUxtA
/>

Gitops

會議中有一個座談小組討論了 Gitops 的好處，下面給你們總結一下。

第一，Gitops 讓整個團隊內部更「民主」了。全部東西都寫下來了，想看就看。任何變動在發佈前都須要走 pull request，不只讓你知道得清清楚楚，還能讓你參與評審輸入意見。全部改動、討論通通都記錄在 Github 等工具上，隨時能夠翻看歷史。這些種種讓團隊協做更流暢和專業化。

第二，Gitops 讓發佈更安全穩定了。代碼再也不可以隨意發佈，須要相關負責人、甚至多人評審。須要回滾時，原來的版本就存在 Git 裏面。誰在何時發佈了什麼代碼，有審計歷史。這些種種發佈流程更專業化，讓發佈結果更穩定可靠。

分析與點評

Gitops 不只僅是解決一個技術問題，更主要的利用 Github 等工具的版本、歷史、審計、權限讓，讓團隊協做和發佈流程更專業化和流程化。

Gitops 若是可以普遍推廣，對整個業界的影響將是巨大的。比方說，不論去任何公司，任何人均可以快速上手發佈代碼。

Gitops 裏面體現的 Configuration as code 和 Git as the source of truth 的思想，仍是很是值得咱們學習和實踐的。

視頻連接：https://www.youtube.com/watch?v=uvbaxC1Dexc
/>

Automated Canary Rollout

金絲雀發佈 (Canary rollout)，是指在發佈過程當中，先將一小部分流量導入到新版本，並分析和驗證上線行爲是否正常。一切正常的話繼續將流量逐漸切換到新版本中，直到舊版沒有流量並被摧毀。咱們知道，在 Spinnaker 等工具中，會有一個手工驗證和經過的步驟。這個步驟其實能夠用自動化工具替代掉，畢竟每次檢查的東西都挺機械式的，例如檢查下成功率和 p99 延時。

基於上述思想，來自 Amadeus 和 Datadog 的工程師分享瞭如何利用 Kubernetes、Operator、Istio、Prometheus 等工具來作金絲雀發佈。思路是整個金絲雀發佈被抽象成一個 CRD，而後作一次金絲雀發佈的過程就變成了編寫一個聲明式的 YAML 文件就夠了，Operator 收到用戶建立的 YAML 文件後會自動完成複雜的運維操做。這裏主要步驟分爲:

1. 部署新版本服務 (Deployment + Service)
2. 更改 Istio VirtualService 配置切換一部分流量到新版本;
3. 檢驗 Istio metrics 中新版本服務的成功率和 p99 響應時間是否均知足條件;
4. 若是知足則整個應用升級到新版本；不然就回滾。

無獨有偶，Weave 也開源了自動化金絲雀發佈工具 Flagger。不一樣的是，Flagger 會按部就班地切流到新版本，好比每次新切 5% 流量過去，等到流量都切過去直接摧毀舊版。

分析與點評

使用金絲雀發佈一時爽，一直使用一直爽。金絲雀發佈有助於提升發佈成功率和系統穩定性，是應用管理的重要流程。

另外咱們也看到，雲原生時代這些複雜的運維流程將被簡化和標準化。經過 CRD 抽象，裏面複雜的過程步驟將變成幾個短短的 API 對象提供給用戶。使用 Operator 作自動化運維，只要在 Kubernetes 標準平臺上用戶就能夠用上這些功能。而 Istio 和 Kubernetes 做爲頂級的標準化平臺，提供了強大的基礎能力讓用戶更容易上手。
視頻連接：https://www.youtube.com/watch?v=mmvSzDEw-JI
/>

寫在最後

在這篇文章裏，咱們盤點了本次 KubeCon 中有關應用管理與部署的一些新知識：

1. 當配置文件改動時，作一個新的應用發佈的緣由和方法。
2. 客戶端 kubectl apply 有諸多問題，其中重要一點就是互相篡改資源字段。這些在服務器端 apply 的實現中解決了。
3. Gitops 不只僅是解決一個技術問題，更主要的讓團隊協做和發佈流程更專業化和流程化。
4. 利用 Kubernetes、Operator、Istio、Prometheus 這些頂級標準化平臺，咱們能簡化金絲雀發佈的運維操做，下降了開發者的使用門檻。

這些新的思想，也讓咱們感慨萬千：從前，咱們總在羨慕「別人家的基礎架構」，它們老是這麼優秀而高不可攀。而如今，開源項目和技術標準，正在將這些技術下降門檻，讓每個開發者都使用上。

而另外一方面，一個微妙的變化也正在發生着——「自研」的基礎軟件不得不面臨着邊際效應遞減規律，致使愈來愈多的像 Twitter 這樣的公司開始加入到雲原生陣營。擁抱開源生態和技術標準，儼然成爲當前互聯網企業的一個重要機遇和挑戰。構建面向雲原生的應用與架構，藉助雲以及開源的力量，才能作好充分準備在這場上雲的變革中揚帆遠航。

 

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。