Kubernetes CKA課程筆記 11
目前我們在AWS的EC2 Server上有1 x master Node + 2 x worker Node
以下講解實際Kubernetes Cluster安裝步驟
步驟1.
- 安裝Container Runtime到這三台(並設置為常態的Linux運行)
- 安裝kubelet到這三台(並設置為常態的Linux運行)
上述兩個都能由應用程式儲存的倉庫(package repository)進行安裝
(就當作一般應用程式那樣安裝)
當上述兩樣安裝完後,即可佈署Pods提供給其他K8s元件
步驟2.(這邊安裝物件出現差異,是以Pod形式的部分)
在master Node(Control Plane)上此時可以安裝部分Pods
由這些Pods運行前面章節提到master該運行的系統:
- API Server
- Scheduler
- Controller Manager
- etcd
步驟3.
另外一提要在三台都要佈署的是 — kube proxy(以Pod形式運作)
步驟4.
考量到上述有些系統要用Pod方式運行,就該有以下考量
- 製作其K8s manifest file
- 並保證其能安全地運作(Deploy securely,i.e.別人手伸不進這些系統)
(保證這些系統間溝通是加密安全地方式)
有上述考量情況下,就還要談到K8s的另一種Pod — Static Pods
前面章節我們講到的Pod都是要我們自己對著master的API Server發動請求
API Server再去呼喚Scheduler
Scheduler決定好要分配的Node後命令kubelet去這個Node搭建實際的Pod
之後Pod的資料儲存進etcd store
(上述Pod的就是普通的Regular Pod)
但是我們都還沒搭好這些元件(API Server,Scheduler,Controller Manager,etcd),怎麼透過這些物件建立Pod呢!?到底是先要有蛋還是先要有雞!?
所以要引入 — Static Pods
Static Pods:
- 直接地由kubelet daemon管理
- 不用master Node(Control Plane)驅動
- 所以只要搭建好Container Runtime
- 並且搭建好kubelet
- 即可建立Static Pods
所以簡單將兩種Pod作圖劃分如下:
而實際Kubelet怎麼做到呢?
答案是:
Kubelet會一直盯著一個default目錄的manifests file,這個目錄位置是:
/etc/kubernetes/manifests
並依據這些manifests file建立成Static Pods(不需要master其他程式協助)
再來就要談到Regular Pods vs Static Pods差異:
- Kubelet(不是Controller Manager)會親自監視Static Pods運作/重啟
- Static Pods 名稱字尾會帶著node HostName!!!
總結上述的內容,我們在master node上要先製作四個文檔:
- API Server的Static Pod manifests file
- Scheduler的Static Pod manifests file
- Controller Manager的Static Pod manifests file
- etcd的Static Pod manifests file
然後放置到/etc/kubernetes/manifests目錄下
在來還要談及各個安裝的元件之間如何安全地溝通
比如說日後API Server怎麼有區別性地(identify)呼叫kubelet
(這邊可能是因為日後master可能有多個node,也就是有多個API Server)
並且不同元件間的溝通理應是加密的形式(mutual TLS的加密溝通)
這時候就需要 →憑證(Certificates)
總歸兩個問題點:
1.在K8s Cluster內誰跟誰溝通?
- 在K8s Cluster中,API Server管理了全部的溝通
- (除了前面章節的外部Client發動請求到API Server外還包辦Node間溝通)
- 幾乎所有非API Server的元件(像是Kubelet等元件)
- 這些非API Server元件都會直接地與API Server溝通
- 並且這些溝通都會帶著自簽(self-signed)憑證(K8s-CA憑證)(概念如下圖)
- 每個元件都分別會有client或server憑證(看下面分類整理)
- 這些憑證儲存於路徑=>/etc/kubernetes/pki
每個元件需要的憑證種類:
- API Server需要Server憑證
- Scheduler與Controller Manager要Client憑證,以發動Req到API Server
- Kubelet與etcd需要Server憑證,因為API Server也要呼叫他們,所以
- API Server還需要Client憑證
- Kubelet也需要Client憑證,因為Kubelet也會反過來呼叫API Server
當有Kubelet Request呼叫API Server,怎麼確定這個Request不是駭客發動的?
所以發動端就要拿著同一個CA(Certificate Authority)簽發的憑證
用以證明是同一個Cluster發動的的請求
而管理整個Cluster內部憑證的部分就是 — PKI(Public Key Infrastructure)
但是還有一個請求是來自K8s Cluster外部的 — 就是我們自己(i.e. K8s Admin)
身為K8s Admin拿著的憑證自然也要同一個CA簽發的
總結在安裝K8s Cluster前我們要準備好以下:
- 對於整個K8s Cluster需要一份自簽憑證(K8s Cluster root CA)
- 而各個元件所需要的憑證也要來自同一個CA簽發
自此在安裝前我們需要準備:
Static Pod Manifests…#%$@#%^&^%^憑證....$超多....太複雜了.....
但是有一個command line工具提供上述準備的解套 →kubeadm
kubeadm:
- 將協助快速建置K8s Cluster
- 快速建立必要的設定
- 快速做好需要的憑證
- 不太需要擔心過程會有缺漏(因為這東西來自kubernetes官方維護)
所以後面就是用這個kubeadm工具來作實際kubernetes Cluster建置
