解讀 KubeCon EU 2019 應用管理領域的新看點
作者 | 阿里雲智慧事業群技術專家 鄧宏超
劃重點
阿里雲容器平臺技術專家、原 CoreOS 公司工程師、 K8s Operator 專案的核心作者之一鄧洪超,精彩解讀 KubeCon EU 2019 "應用管理“領域精華內容:
The config changed
Server-side Apply
Gitops
Automated Canary Rollout
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 功能,網站就能達到小部分流量對新版配置進行驗證的效果。
影片連結:
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 這樣的公司開始加入到雲原生陣營。擁抱開源生態和技術標準,儼然成為當前網際網路企業的一個重要機遇和挑戰。構建面向雲原生的應用與架構,藉助雲以及開源的力量,才能做好充分準備在這場上雲的變革中揚帆遠航。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31555606/viewspace-2646251/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 匿名IP的優點與應用領域
- 《BMW白皮書》解讀三:BMW生態應用的八大領域
- AR擴增實境應用領域大盤點
- 讀書系列-《解構領域驅動》-領域概念
- 實景三維在園區管理領域的應用
- Linux 應用領域Linux
- nodejs應用領域NodeJS
- 網路安全應用領域有哪些?常見應用領域總結!
- Linux最常見的三個應用領域詳解!Linux
- Kotlin 程式語言詳解:特點、應用領域及語法教程Kotlin
- 華為雲亮相KubeCon EU 2024,以持續開源創新開啟智慧時代
- 並嚮應用領域逐漸延展,近年來開始主導資訊科技領域的深度創新
- Bert時代的創新:Bert在NLP各領域的應用進展
- 中電金信:向“新”而行—探索AI在保險領域的創新應用AI
- 擴充 Swift 應用領域Swift
- 效能測試應用領域
- Python的優缺點和應用領域有哪些? 【詳細】Python
- 區塊鏈的應用領域—物聯網和物流領域(二)區塊鏈
- 盤點|AI在機器人運動控制領域應用盤點AI機器人
- zigbee協議的缺點 zigbee的主要應用領域協議
- 網路安全的應用領域有哪些?
- 區塊鏈的應用領域——公益(六)區塊鏈
- 區塊鏈的應用領域——保險(五)區塊鏈
- 嵌入式的應用領域有哪些?
- 人工智慧的應用領域有哪些?人工智慧
- 區塊鏈的應用領域-金融(一)區塊鏈
- StarRocks在支付對賬領域的應用
- ChatGPT在資訊保安領域的應用前景ChatGPT
- Photoshop軟體的應用領域介紹
- IT職場:如何將TRIZ應用於非技術領域的創新問題?
- 七麥:2017年中國移動應用市場解讀 短視訊、影像領域成黑馬迸發點
- Mock技術在測試領域的應用Mock
- 深度學習在醫療領域的應用深度學習
- 幻影成像的實現方式和應用領域
- 漫談 C# 在遊戲領域的應用C#遊戲
- 大資料分析應用的九大領域大資料
- 社交資料在徵信領域的應用探索
- API在哪些領域應用廣泛API