Kubernetes CKA課程筆記 13
前一篇(12)我已經將機台做好的安裝K8s Cluster的以下準備:
接著該頁面往下拉首先看到 — 安裝runtime(i.e. Container Runtime)
Container Runtime就是接下來第一個要安裝的應用程式
- Container Runtime 不是 Kubernetes元件
- Kubernetes卻需要Container Runtime來做Schedule Container
首先問題是 →什麼是Container Runtime?
Container Runtime:
在第二篇筆記(Kubernetes Architecture)有提到
- 我們的應用程式將運作為Container
- 甚至K8s有些運算也是要運行成Container
- (ex:API Server,Schedule,Controller Manager,etcd…etc)
- 所以K8s的master Node 與 worker Node都需要Container Runtime
該如何挑選Container Runtime:
- 現今的K8s其實不care使用何種runtime
- 但是最初K8s僅支援Docker為其Container Runtime
- 在早期方式是K8s的kubelet程式碼內直接地寫入Docker的Code
- (記得kubelet是裝在master & worker都有)
- 所以kubelet直接地操作Docker去操作Container
- 而現今已經有其他熱門的Container Runtime
- 1.containerd
- 2.cri-o
(還有其他Container Runtime可能沒那麼熱門)
但是K8s開發者總不可能寫出支援各種runtime的kubelet程式出來
所以K8s開發出了一個kubelet與Container Runtime中間的介面:
Container Runtime Interface(CRI):
- 其定義了各種Container Runtime技術要實作的介面規格
- 就可以達成以下
但是Docker卻是第一個不實作CRI規格的Container Runtime
所以前不久版本的K8s若仍使用Docker為Container Runtime則還要多一層
所以在上述結構中kubelet還能操作Docker
而Docker本身除了Container Runtime外還有其他功能:
- build Docker image
- Docker CLI
- Docker UI
- Docker API
- …etc
但是K8s僅需要Docker的Container Runtime
所以越來越多比Docker輕量化的Container Runtime提供給K8s引用
其中兩個前面有講到:
- containerd
- cri-o
然後最終Dockershim也漸漸不再支援(v1.20)
並在1.23版完全移除Dockershim
而我最想知道的講師解說:
- 若使用一些公司繼續維護的Dockershim(或相近的Service)
我們就仍然可以繼續使用Docker當作Container Runtime
2.但還是建議直接選要其他輕量化的Container Runtime
3.並且我們仍然可以使用Docker去pull Docker images,並使用其他(非Docker)輕量化Container Runtime來執行
(我最想知道第三點!!!Docker 製作或Dockerhub的image能不能給其他非Docker的Container Runtime使用!!!!)
所以舉例我們仍可以透過Docker建立images
並在K8s中使用如containerd這個Container Runtime來運行
基於以上理由,各家雲端平台的K8s Cluster整合方案也都採用containerd
- Amazon的EKS(Elastic)
- Azure的AKS(Azure Kubernetes Service)
- Google的GKE(Google Kubernetes Service)
所以接著下一篇就將進行containerd的實機安裝
