關於Kubernetes調度特定應用的記錄

Kubernetes 提供可拓展的容器調度功能:

• 用戶可以對接不同的container runtime， 其中最常用的是docker。
• 用戶可以在docker內封裝隔離各類進程應用 。

因此，kubernetes可以調度和部署一系列web服務等app， 也可以部署分佈式應用， 計算密集型應用如Spark和Tensorflow等，這取決於開發者的部署配置和docker鏡像內容等。

下文記錄一些實踐經驗，不深入配置層面。

Kubernetes 部署web服務

• web 服務config配置用config map方案比較方便。
• 集羣管理工具用Rancher比較方便, 用戶可以在其UI管理多個k8s集羣，避免編寫yaml等和kubectl等繁瑣操作。Rancher在namespace的基礎上也引入了project的概念， 即project內可包含多個 k8s namespace. 但是kubectl get ns仍會發現所有project下的namespace， Rancher的這個做法只是方便用戶管理集羣。另外Rancher對k8s內資源的變化響應也是很不錯的， 即在Rancher前端UI能很及時地看到deployment等的狀態刷新情況。另外Rancher提供部署回滾功能，降低誤操作帶來的開銷。
• 使用Rancher的時候注意其與K8s的兼容關係。
• web服務間通信配置參考service。
• k8s集羣所有服務上免費可用的tls參考

Kubernetes 部署計算密集型服務

計算密集型服務與web服務有區別：

• 計算密集型服務注重計算性能， 容器環境會有損耗(內存/cpu虛擬化開銷)
• 計算密集型服務偏向批量啓動和批量刪除等操作， 如啓動深度學習集羣，大數據集羣等， 計算完畢後deployment/pods等即刪除。
• 計算密集型服務對實例間帶寬要求高，在K8s環境下要考慮CNI損耗
• 不同計算業務的容器運行環境配置不同，運行依賴不同，調度配置(workers/masters)等較複雜

實踐：

• 優化計算和存儲性能：

  • 引入統一存儲和本地固態硬盤等
  • 選用開銷較少的CNI
  • 增加計算業務並行化部分， 用並行度淡化虛擬化開銷
  • 容器中使用GPU計算有較好的性能

• 計算密集型服務的調度的簡單做法可以依賴原生k8s的deployment等概念，利用k8s的client，編寫簡單的創建服務， 如將spark master設置爲deployment A, 爲其配置service A等， 再將spark worker等設置爲deployment B, 爲其配置service B, 二者通過service A/B通信。

• 計算密集型服務的調度的更佳做法具體開發可以參考k8s operator,
  開發operator的做法會更規範， 對管理複雜的計算密集型服務調度實現起來更有效。對比之下，單純依靠k8s的client去組織分佈式服務會顯得低效且會引入很多瑣碎問題，例如需要修改spark鏡像， 插入指定的啓動程序， 用於收集spark節點的信息等。