k8s學習（CNCF × Alibaba 雲原生技術公開課）（二）

<續> Kubernetes 學習

1、 PV Controller、AD Controller 以及 Volume Manager 其實都是透過呼叫 Volume Plugin 提供的介面，比如 Provision、Delete、Attach、Detach 等去做一些 PV、PVC 的管理。而這些介面的具體實現邏輯是放在 VolumePlugin 中的。 根據原始碼的位置可將 Volume Plugins 分為 In-Tree 和 Out-of-Tree 兩類，

• In-Tree 表示原始碼是放在 Kubernetes 內部的，和 Kubernetes 一起釋出、管理與迭代，缺點及時迭代速度慢、靈活性差； 比如cephfs、glusterfs
• Out-of-Tree 類的 Volume Plugins 的程式碼獨立於 Kubernetes，它是由儲存商提供實現的，目前主要有 Flexvolume 和 CSI 兩種實現機制，可以根據儲存型別實現不同的儲存外掛。所以我們比較推崇 Out-of-Tree 這種實現邏輯。 比如 CSI、FlexVolume

2、Flexvolume是可被 Kubelet 驅動的可執行檔案，host 空間中的二進位制程式，是 Volume Plugins 的一個擴充套件，主要實現 Attach/Detach/Mount/Unmount 這些介面。

Flexvolume預設的存放地址為 "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/alicloud~disk/disk"

所有掛載均需先將遠端裝置掛載到本地主機，然後從主機透過bind對映到容器內部。

阿里雲提供了一個 Flexvolume 的實現：針對阿里云云盤、NAS、OSS儲存開發的flexvolume 外掛，可以支援kubernetes pod 自動繫結阿里雲端儲存服務。此版本支援Flexvolume、靜態pv、對於動態pv尚不支援。

3、CSI 是容器化部署，可以減少環境依賴，增強安全性，豐富外掛的功能。Flexvolume 是在 host 空間一個二進位制檔案（ 透過yaml配置進行部署阿里雲K8S儲存外掛，目前支援CentOS 7 作業系統），執行 Flexvolum 時相當於執行了本地的一個 shell 命令，這使得我們在安裝 Flexvolume 的時候需要同時安裝某些依賴，而這些依賴可能會對客戶的應用產生一些影響。因此在安全性上、環境依賴上，會有不好的影響。CSI 是透過 CRD 的形式實現的， CRD（Custom Resource Definition），CRD 在用法上和 Pod 這樣的原生資源基本相同，都支援透過 kubectl 命令列或者 K8s API 進行訪問和操作。正是 CRD 的靈活和強大，促成了 K8s 周邊生態的蓬勃發展。 VolumeSnapshotDataSource 可以實現資料卷的快照功能，

4、 K8s 的後設資料部分。該部分主要包括了用來識別資源的標籤：Labels， 用來描述資源的註解；Annotations， 用來描述多個資源之間相互關係的 OwnerReference。

資源標籤是一種具有標識型的 Key：Value 後設資料， 標籤主要用來篩選資源和組合資源，可以使用類似於 SQL 查詢 select，來根據 Label 查詢相關的資源。

後設資料是：annotations。一般是系統或者工具用來儲存資源的非標示性資訊，可以用來擴充套件資源的 spec/status 的描述

Ownereference，所謂所有者，一般就是指集合類的資源，比如說 Pod 集合，就有 replicaset、statefulset， 集合類資源的控制器會建立對應的歸屬資源， 可以用來實現級聯刪除的效果。

5、 Kubernetes 控制器模式依賴宣告式的 API。另外一種常見的 API 型別是命令式 API。 控制型模式最核心的就是控制迴圈的概念。在控制迴圈中包括了控制器，被控制的系統，以及能夠觀測系統的感測器，三個邏輯元件。 當然這些元件都是邏輯的，外界透過修改資源 spec 來控制資源，控制器比較資源 spec 和 status，從而計算一個 diff，diff 最後會用來決定執行對系統進行什麼樣的控制操作，控制操作會使得系統產生新的輸出，並被感測器以資源 status 形式上報，控制器的各個元件將都會是獨立自主地執行，不斷使系統向 spec 表示終態趨近。

6、Deployment 是 Kubernetes 中常見的一種 Workload，支援部署管理多版本的 Pod：Deployment 建立 ReplicaSet，而 ReplicaSet 建立 Pod。他們的 OwnerRef 其實都對應了其控制器的資源。

• Deployment 管理多版本的方式，是針對每個版本的 template 建立一個 ReplicaSet，由 ReplicaSet 維護一定數量的 Pod 副本，而 Deployment 只需要關心不同版本的 ReplicaSet 裡要指定多少數量的 Pod；

• 因此Deployment 釋出部署的根本原理，就是 Deployment 調整不同版本 ReplicaSet 裡的終態副本數，以此來達到多版本 Pod 的升級和回滾。

7、引入了一個 kind 叫 Job，是 job-controller 裡面的一種型別， metadata 裡面的 name 來指定這個 Job 的名稱，在 Job 裡面，我們主要重點關注的一個是 restartPolicy 重啟策略和 backoffLimit 重試次數限制。Pod 多了一個叫 ownerReferences，這個東西來宣告此 pod 是歸哪個上一層 controller 來管理，可以看到 ownerReferences 是歸 batch/v1，也就是上一個 Job 來管理的。並行執行 Job使用Job 控制器兩個引數：一個是 completions（Pod 佇列執行次數），一個是 parallelism（並行執行的個數）。 定時任務 CronJob， 其實也可以叫定時執行 Job

8、DaemonSet 也是 Kubernetes 提供的一個 default controller，它實際是做一個守護程式的控制器， DaemonSet 架構設計。DaemonSet 還是一個 controller，它最後真正的業務單元也是 Pod，DaemonSet 其實和 Job controller 特別相似，它也是透過 controller 去 watch API Server 的狀態（ 這個 node 的狀態還是透過 API Server 傳遞到 ETCD），然後及時地新增 pod。唯一不同的是，它會監控節點的狀態，節點新加入或者消失的時候會在節點上建立對應的 pod，然後同時根據你配置的一些 affinity 或者 label 去選擇對應的節點：

• 首先是儲存，GlusterFS 或者 Ceph 之類的東西，需要每臺節點上都執行一個類似於 Agent 的東西，DaemonSet 就能很好地滿足這個訴求；
• 另外，對於日誌收集，比如說 logstash 或者 fluentd，這些都是同樣的需求，需要每臺節點都執行一個 Agent，這樣的話，我們可以很容易蒐集到它的狀態，把各個節點裡面的資訊及時地彙報到上面；
• 還有一個就是，需要每個節點去執行一些監控的事情，也需要每個節點去執行同樣的事情，比如說 Promethues 這些東西，也需要 DaemonSet 的支援。

9、 ConfigMap主要是管理一些可變配置資訊，比如說我們應用的一些配置檔案，或者說它裡面的一些環境變數，或者一些命令列引數。 好處在於它可以讓一些可變配置和容器映象進行解耦，這樣也保證了容器的可移植性。

只有透過 K8s api 建立的 pod 才能使用 ConfigMap，比如說透過用命令列 kubectl 來建立的 pod，肯定是可以使用 ConfigMap 的，但其他方式建立的 pod，比如說 kubelet 透過 manifest 建立的 static pod，它是不能使用 ConfigMap 的。

10、 Secret 是一個主要用來儲存密碼 token 等一些敏感資訊的資源物件。其中，敏感資訊是採用 base-64 編碼儲存起來的。 ServiceAccount 首先是用於解決 pod 在叢集裡面的身份認證問題，身份認證資訊是存在於 Secret 裡面。 Resource，即：容器的一個資源配置管理： 目前內部支援型別有三種：CPU、記憶體，以及臨時儲存。 目前資源配置主要分成 request 和 limit 兩種型別，一個是需要的數量，一個是資源的界限。CPU、記憶體以及臨時儲存都是在 container 下的 Resource 欄位裡進行一個宣告。

SecurityContext 主要是用於限制容器的一個行為，它能保證系統和其他容器的安全 。

11、 InitContainer 和普通 container 的區別，有以下三點內容：

1. InitContainer 首先會比普通 container 先啟動，並且直到所有的 InitContainer 執行成功後，普通 container 才會被啟動；
2. InitContainer 之間是按定義的次序去啟動執行的，執行成功一個之後再執行第二個，而普通的 container 是併發啟動的；
3. InitContainer 執行成功後就結束退出 ，而普通容器可能會一直在執行。它可能是一個 longtime 的，或者說失敗了會重啟，這個也是 InitContainer 和普通 container 不同的地方。

12、在雲環境下，技術棧可以是多種多樣的。那麼如何能夠將這些異構的服務元件串聯起來，成為了服務治理的一個重大課題。而Sidecar模式為服務治理，提供了一種解決方案。邊車(Sidecar)模式，早期有一些摩托車，除了主駕駛位，還帶一個邊車位，可以額外坐一個人。業務程式碼程式(相當於主駕駛)共享一個代理(相當於邊車)，代理除了負責服務發現和負載均衡，還負責動態路由、容錯限流、監控度量和安全日誌等功能，這些功能是具體業務無關的，屬於跨橫切面關注點(Cross-Cutting Concerns)範疇。在該模式中，邊車附加到父應用程式併為應用程式提供支援功能。 sidecar還與父應用程式共享相同的生命週期，與父項一起建立和退役。邊車圖案有時被稱為搭接圖案並且是分解圖案。

13、Docker， 當執行docker run時，它會建立並執行容器，但是底層它實際呼叫的是runc命令。（Docker使用的是LXC但是層次隔離不太完整，所以後來Docker開發了libcontainer，最後演變為了runc。）

——當我們有需求去替換 runc 執行時工具庫時，例如替換為安全容器 kata container 或 Google 研發的 gViser，則需要增加對應的shim(kata-shim等)，以上兩者均有自己實現的 shim。