解讀 KubeCon EU 2019 應用管理領(lǐng)域的新看點

Kubecon EU 2019 剛剛在巴塞羅那拉下帷幕，來自阿里巴巴經(jīng)濟體的講師團，在大會上分享了互聯(lián)網(wǎng)場景下規(guī)?；?Kubernetes 集群的各項落地經(jīng)驗和教訓。所謂“獨行速而眾行遠”，從不斷發(fā)展壯大的社區(qū)中，我們看到越來越多的人擁抱開源，往標準演進，搭上了這趟開往云原生的高速列車。

眾所周知，云原生架構(gòu)的中心項目是 Kubernetes，而 Kubernetes 則圍繞著“應用”來展開。讓應用部署得更好，讓開發(fā)者更高效，才能給團隊和組織帶來切實的利益，才能讓云原生技術(shù)變革發(fā)揮更大的作用。

變革的勢頭既如洪水般吞沒著老舊封閉的內(nèi)部系統(tǒng)，又如春雨般孕育出更多的新開發(fā)者工具。在本次 KubeCon 中，就出現(xiàn)了許多有關(guān)應用管理與部署的新知識。這些知識中有哪些想法和思路值得借鑒，讓我們少走彎路？在它們背后，又預示著什么樣的技術(shù)演進方向？

在本文中，我們邀請到了阿里云容器平臺技術(shù)專家、原 CoreOS 公司工程師、 K8s Operator 項目的核心作者之一鄧洪超，為讀者精選了此次會議“應用管理”領(lǐng)域的精華內(nèi)容來一一進行分析與點評。

Kubernetes 上部署的應用一般會把配置存放到 ConfigMap 里，然后掛載到 Pod 文件系統(tǒng)中去。當 ConfigMap 發(fā)生更改時，只有 Pod 里掛載的文件會被自動更新。這種做法對某些會自動做熱更新的應用（比如 nginx）來說是 OK 的。但是，對于大多數(shù)應用開發(fā)者來說，他們更傾向于認為更改配置要做一次新的灰度發(fā)布、跟 ConfigMap 相關(guān)聯(lián)的容器應該做一次灰度升級。

灰度升級不僅簡化了用戶代碼，增強了安全穩(wěn)定性，更是體現(xiàn)了不可變基礎(chǔ)架構(gòu)的思想。應用一旦部署，就不再做變更。需要升級時，只要部署一個新版系統(tǒng)，驗證 OK 后再摧毀舊版就好了；驗證不通過時也容易回滾到舊版。

正是基于這樣的思路，來自 Pusher 的工程師們研發(fā)了 Wave，一款自動監(jiān)聽 Deployment 相關(guān)聯(lián)的 ConfigMap/Secret 并隨之改動而觸發(fā) Deployment 升級的工具。這款工具的獨特之處在于它會自動搜索該 Deployment PodTemplate 里面的 ConfigMap/Secret，然后把里面所有數(shù)據(jù)計算一次 hash 放到 PodTemplate annotations 里面；當有變動時，會重新計算一次 hash 并更新 PodTemplate annotations，從而觸發(fā) Deployment 升級。

無獨有偶，開源社區(qū)里還有另一款工具 Reloader 也做了類似的功能——不同的是，Reloader 還能讓用戶自己選擇填寫監(jiān)聽哪幾個 ConfigMap/Secret。

升級不灰度，背鍋兩行淚。不論是升級應用鏡像還是更改配置，都要記得做一次新的灰度發(fā)布和驗證。

另外我們也看到，不可變基礎(chǔ)架構(gòu)給構(gòu)建云計算應用帶來了嶄新的視角。朝著這個方向發(fā)展，不僅能讓架構(gòu)更安全更可靠，更是能跟其他主要工具結(jié)合好，充分發(fā)揮云原生社區(qū)的作用，對傳統(tǒng)應用服務實現(xiàn)“彎道超車”。舉個例子，充分結(jié)合上面的 wave 項目和 Istio 中 weighted routing 功能，網(wǎng)站就能達到小部分流量對新版配置進行驗證的效果。

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

Kubernetes 是一個聲明式的資源管理系統(tǒng)。用戶在本地定義期望的狀態(tài)，然后通過 kubectl apply 去跟更新當前集群狀態(tài)中被用戶指定的那一部分。然而它遠沒有聽起來那么簡單...

原來的 kubectl apply 是基于客戶端實現(xiàn)的。Apply 的時候不能簡單地替換掉單個資源的整體狀態(tài)，因為還有其他人也會去更改資源，比如 controllers、admissions、webhooks。那么怎樣保證在改一個資源的同時，不會覆蓋掉別人的改動呢？

于是就有了現(xiàn)有的 3 way merge：用戶把 last applied state 存在 Pod annotations 里，在下次 apply 的時候根據(jù) (最新狀態(tài)，last applied，用戶指定狀態(tài)) 做 3 way diff，然后生成 patch 發(fā)送到 APIServer。但是這樣做還是有問題！Apply 的初衷是讓個體去指定哪些資源字段歸他管理。

但是原有實現(xiàn)既不能阻止不同個體之間互相篡改字段，也沒有在沖突發(fā)生時告知用戶和解決。舉個例子，筆者原來在 CoreOS 工作時，產(chǎn)品里自帶的 controller 和用戶都會去更改 Node 對象的一些特殊 labels，結(jié)果出現(xiàn)沖突，導致集群出故障了只能派人去修。

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

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

另外我們也看到，隨著系統(tǒng)的發(fā)展，尤其是聲明式 API 的廣泛使用，在本地的邏輯將會變少，而在服務器端的則會變多。在服務器端有諸多好處：許多操作，比如 kubectl dry-run、diff，在服務器端實現(xiàn)會更簡單；提供 HTTP endpoint，這樣會更容易把 apply 這樣的功能構(gòu)建到其他工具中；把復雜邏輯放到服務器端實現(xiàn)和發(fā)布，能夠更容易做好管控，讓用戶享受到安全、一致、高質(zhì)量的服務。

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

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

第一，Gitops 讓整個團隊內(nèi)部更“民主”了。所有東西都寫下來了，想看就看。任何變更在發(fā)布前都需要走 pull request，不僅讓你知道得清清楚楚，還能讓你參與評審輸入意見。所有改動、討論統(tǒng)統(tǒng)都記錄在 Github 等工具上，隨時可以翻看歷史。這些種種讓團隊協(xié)作更流暢和專業(yè)化。

第二，Gitops 讓發(fā)布更安全穩(wěn)定了。代碼不再能夠隨意發(fā)布，需要相關(guān)負責人、甚至多人評審。需要回滾時，原來的版本就存在 Git 里面。誰在什么時候發(fā)布了什么代碼，有審計歷史。這些種種發(fā)布流程更專業(yè)化，讓發(fā)布結(jié)果更穩(wěn)定可靠。

Gitops 不僅僅是解決一個技術(shù)問題，更主要的利用 Github 等工具的版本、歷史、審計、權(quán)限讓，讓團隊協(xié)作和發(fā)布流程更專業(yè)化和流程化。

Gitops 如果能夠廣泛推廣，對整個業(yè)界的影響將是巨大的。比方說，不論去任何公司，任何人都可以快速上手發(fā)布代碼。

Gitops 里面體現(xiàn)的 Configuration as code 和 Git as the source of truth 的思想，還是非常值得我們學習和實踐的。

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

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

基于上述思想，來自 Amadeus 和 Datadog 的工程師分享了如何利用 Kubernetes、Operator、Istio、Prometheus 等工具來做金絲雀發(fā)布。思路是整個金絲雀發(fā)布被抽象成一個 CRD，然后做一次金絲雀發(fā)布的過程就變成了編寫一個聲明式的 YAML 文件就夠了，Operator 收到用戶創(chuàng)建的 YAML 文件后會自動完成復雜的運維操作。這里主要步驟分為:

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

使用金絲雀發(fā)布一時爽，一直使用一直爽。金絲雀發(fā)布有助于提高發(fā)布成功率和系統(tǒng)穩(wěn)定性，是應用管理的重要流程。

另外我們也看到，云原生時代這些復雜的運維流程將被簡化和標準化。通過 CRD 抽象，里面復雜的過程步驟將變成幾個短短的 API 對象提供給用戶。使用 Operator 做自動化運維，只要在 Kubernetes 標準平臺上用戶就可以用上這些功能。而 Istio 和 Kubernetes 作為頂級的標準化平臺，提供了強大的基礎(chǔ)能力讓用戶更容易上手。

視頻鏈接：https://www.youtube.com/watch?v=mmvSzDEw-JI

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

這些新的思想，也讓我們感慨萬千：從前，我們總在羨慕“別人家的基礎(chǔ)架構(gòu)”，它們總是這么優(yōu)秀而遙不可及。而現(xiàn)在，開源項目和技術(shù)標準，正在將這些技術(shù)降低門檻，讓每一個開發(fā)者都使用上。

而另一方面，一個微妙的變化也正在發(fā)生著——“自研”的基礎(chǔ)軟件不得不面臨著邊際效應遞減規(guī)律，導致越來越多的像 Twitter 這樣的公司開始加入到云原生陣營。擁抱開源生態(tài)和技術(shù)標準，儼然成為當前互聯(lián)網(wǎng)企業(yè)的一個重要機遇和挑戰(zhàn)。構(gòu)建面向云原生的應用與架構(gòu)，借助云以及開源的力量，才能做好充分準備在這場上云的變革中揚帆遠航。