導讀node
本文將經過大量的代碼範例向您展現應該如何利用Konvoy更簡單地給Kubernetes集羣打補丁，並保證集羣在生命週期中都處於安全和健康的狀態，真正實現無感升級。web
最近，咱們在內部的生產Konvoy集羣中遇到了臭名昭著的kmem bug。咱們發如今用戶報告某個集羣中的CI任務出現間歇性故障以後，咱們就遇到了這個問題。當時顯示以下的報錯：docker
來自Pod日誌：安全
來自Kernel日誌：微信
這個發生故障是在一個特別的CI任務，該任務使用docker-in-docker 鏡像來建立Kind Cluster，爲的是測試咱們的D2iQ Helm Charts運行Kubernetes集羣的能力。儘管錯誤是間斷出現的，但一經出現，便會在加載容器或者測試代碼的環節讓咱們的流程失敗。鑑於咱們全部的工做節點均可能會引發這個問題，並且CI任務能夠在任什麼時候間、任意節點上運行。故須要定義一個流程，給工做節點打上補丁，以確保集羣和工做負載始終保持良好狀態。很是幸運的是，利用Konvoy來打造這個流程就變得很是簡單。網絡
咱們將首先介紹是如何利用Konvoy爲工做節點打補丁、並解決了生產Konvoy集羣中出現的kmem問題。首先，咱們將介紹咱們的bugfix解決方案，接着，將介紹如何在整個生產kubernetes集羣中完成無感修復。經過代碼範例的截屏，咱們將展現給您如何利用Konvoy來更簡單地給集羣打補丁，並確保集羣都處於安全和健康的狀態。架構
測 試 app
咱們今天所要解決的bug是一個已知與CentOS操做系統相關的問題。目前惟一已知的應對方法，也是最多見的方法，就是在啓動時就完全禁用kmem的記帳功能。這是目前來講的最佳實踐，不少文章都推薦了這個方法，此外，咱們也應該把kernel更新到最新的版本，由於咱們目前所使用的還不是最新版本。咱們決定利用Konvoy中的「節點池」功能來驗證上述的解決方案，利用一個含有最新kernel的AMI來部署一個新的工做節點。針對測試，咱們決定給這個節點打上標籤，這樣就只有咱們的測試Pods能夠被調度用在新的測試節點上運行。只須要在Konvoy中執行很是簡單的兩個步驟，就能夠經過新的節點池在集羣中添加這個新的工做節點。分佈式
1. 在cluster.yaml裏添加一個新的節點池，把數量設置爲1。咱們還須要給節點池加入了污點和容差，確保其它的工做負載不會被調度到這些節點。svg
在新節點池的cluster.yaml的「ClusterProvisioner」（集羣配置器）部分，咱們在imageID的參數填入某個特定AMI，這個AMI包含有最新的kernel。
在cluster.yaml的ClusterConfiguration的節點池部分之下，給測試節點節點池添加名稱爲「testnode」的標籤。
2. 一旦cluster.yaml包含了新的節點池和污點以後，運行Konvoy up給集羣添加一個新的節點，具體操做以下:
僅需很是簡單的兩步，Konvoy就在集羣中添加了新的節點。在這個例子中，由於上游的CentOS AMIs中kmem不是缺省的，須要在Konvoy以外引入另一個步驟，咱們須要禁用kmem。針對這一步驟，咱們建立了兩個簡單的Ansible playbooks去完成對kmem的禁用，以後咱們就能夠在整個集羣中自動執行這個步驟了。若是您有興趣能夠點擊這裏下載這些playbooks。
最後，咱們部署了一個測試Pod，咱們讓這個CI任務運行了好幾天，就是想看看是否可以讓這個錯誤重現。
在接下來的幾天中，咱們每隔幾小時就要檢查Pod日誌的Kibana（這是咱們缺省集羣部署的一個部分），觀察可否復出現以前的的錯誤。
解 決
在通過72個小時的運行以後，沒有再出現一樣的錯誤。咱們由此認定本次給集羣打補丁是一個有效的解決方案。下面，咱們就看看看如何利用Konvoy按照測試中的一樣流程，給生產集羣打補丁並最終解決這個問題的。
鑑於每個worker節點都是有漏洞的，咱們須要爲目前的節點池建立一個副本。在cluster.yaml中，咱們建立了一個新的節點池，稱之爲「worker-7.7.1908」，與目前的工做節點池的點數同樣。
就像上面同樣，咱們在池中添加了新的AMI，可是此次咱們去掉了污點，由於咱們指望讓全部的工做負載都可以在這裏運行。
在本例中，咱們要從新啓動節點，以保證kmem的記帳功能被徹底禁用。只須要先執行以下命令，就能夠對要增長的節點進行初始化配置。
Tips：在實際執行konvoy provision以前，您能夠先經過執行增長 --plan-only選項的命令 ，先查看Terraform計劃，來肯定是否要對您的基礎架構進行修改。
新實例配置好了以後，咱們會經過playbooks來禁用kmem。
當咱們肯定kmem在新池中已經被禁用了，這時就能夠利用Konvoy來向集羣添加(節點)。
如今節點已經添加進了集羣，也已經作好接收工做負載的準備，咱們就能夠利用Konvoy安全地將現有的工做負載從現有的池子中過濾出來。請注意，這可能須要一段時間才能完成。
在這一步中，Konvoy不只會把工做節點過濾出來，並且還會把這些節點隔離起來，這些節點就有會承載其它的運行了。產出的範例以下：
如今，咱們將舊的節點池擴展至0。
最後，咱們能夠終止舊的工做池，並把它從集羣中刪除。
如上，舊的工做池實例和相關的資源正在被終止，並從集羣中刪除。
這個例子展現了Konvoy如何簡化集羣打補丁的過程，也縮短了集羣解決問題的時間。給集羣打補丁多是一項很是困難的工做，咱們但願您已經瞭解到Konvoy是如何讓集羣打補丁的流程變得友好而高效。在後續的文章中，咱們將繼續探討如何利用Konvoy進一步給您的Kubernetes集羣打補丁，還有其它有關集羣管理方面的內容，敬請關注。
歡迎點擊【閱讀原文】，申請免費試用，或聯繫D2iQ銷售團隊瞭解更多: sales@d2iq.com
往期精彩文章
關於D2iQ
點擊「閱讀原文」，獲取Konvoy免費試用
本文分享自微信公衆號 - D2iQ（d2iq_apac）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。