大盤點： KubeCon EU 2019 應用管理領域的新看點！

作者 | 鄧洪超

衆所周知，雲原生架構的中心項目是 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 功能，網站就能達到小部分流量對新版配置進行驗證的效果。

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 這樣的功能建構到其他工具中；把複雜邏輯放到伺服器端實作和釋出，能夠更容易做好管控，讓使用者享受到安全、一緻、高品質的服務。

Gitops

會議中有一個座談小組讨論了 Gitops 的好處，下面給大家總結一下。

第一，Gitops 讓整個團隊内部更“民主”了。所有東西都寫下來了，想看就看。任何變更在釋出前都需要走 pull request，不僅讓你知道得清清楚楚，還能讓你參與評審輸入意見。所有改動、讨論統統都記錄在 Github 等工具上，随時可以翻看曆史。這些種種讓團隊協作更流暢和專業化。

第二，Gitops 讓釋出更安全穩定了。代碼不再能夠随意釋出，需要相關負責人、甚至多人評審。需要復原時，原來的版本就存在 Git 裡面。誰在什麼時候釋出了什麼代碼，有審計曆史。這些種種釋出流程更專業化，讓釋出結果更穩定可靠。

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

Gitops 如果能夠廣泛推廣，對整個業界的影響将是巨大的。比方說，不論去任何公司，任何人都可以快速上手釋出代碼。

Gitops 裡面展現的 Configuration as code 和 Git as the source of truth 的思想，還是非常值得我們學習和實踐的。

Automated Canary Rollout

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

基于上述思想，來自 Amadeus 和 Datadog 的工程師分享了如何利用 Kubernetes、Operator、Istio、Prometheus 等工具來做金絲雀釋出。思路是整個金絲雀釋出被抽象成一個 CRD，然後做一次金絲雀釋出的過程就變成了編寫一個聲明式的 YAML 檔案就夠了，Operator 收到使用者建立的 YAML 檔案後會自動完成複雜的運維操作。這裡主要步驟分為:

• 部署新版本服務 (Deployment + Service)
• 更改 Istio VirtualService 配置切換一部分流量到新版本 ;
• 檢驗 Istio metrics 中新版本服務的成功率和 p99 響應時間是否均滿足條件 ;
• 如果滿足則整個應用更新到新版本；否則就復原。

無獨有偶，Weave 也開源了自動化金絲雀釋出工具 Flagger。不同的是，Flagger 會循序漸進地切流到新版本，比如每次新切 5% 流量過去，等到流量都切過去直接摧毀舊版。

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

另外我們也看到，雲原生時代這些複雜的運維流程将被簡化和标準化。通過 CRD 抽象，裡面複雜的過程步驟将變成幾個短短的 API 對象提供給使用者。使用 Operator 做自動化運維，隻要在 Kubernetes 标準平台上使用者就可以用上這些功能。而 Istio 和 Kubernetes 作為頂級的标準化平台，提供了強大的基礎能力讓使用者更容易上手。

寫在最後

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

• 當配置檔案改動時，做一個新的應用釋出的原因和方法。
• 用戶端 kubectl apply 有諸多問題，其中重要一點就是互相篡改資源字段。這些在伺服器端 apply 的實作中解決了。
• Gitops 不僅僅是解決一個技術問題，更主要的讓團隊協作和釋出流程更專業化和流程化。
• 利用 Kubernetes、Operator、Istio、Prometheus 這些頂級标準化平台，我們能簡化金絲雀釋出的運維操作，降低了開發者的使用門檻。

這些新的思想，也讓我們感慨萬千：從前，我們總在羨慕“别人家的基礎架構”，它們總是這麼優秀而遙不可及。而現在，開源項目和技術标準，正在将這些技術降低門檻，讓每一個開發者都使用上。而另一方面，一個微妙的變化也正在發生着——“自研”的基礎軟體不得不面臨着邊際效應遞減規律，導緻越來越多的像 Twitter 這樣的公司開始加入到雲原生陣營。擁抱開源生态和技術标準，俨然成為目前網際網路企業的一個重要機遇和挑戰。建構面向雲原生的應用與架構，借助雲以及開源的力量，才能做好充分準備在這場上雲的變革中揚帆遠航。