1 課程第一講

云原生關鍵技術點：

• 如何構建自包含、可定制的應用鏡像；
• 能不能實現應用快速部署與隔離能力；
• 應用基礎設施創建和銷毀的自動化管理；
• 可復制的管控系統和支撐組件。

練習：

1.云原生技術與容器技術的關系是？
B. 容器技術是云原生的基礎技術之一

2.Kubernetes 并不支持為應用固定 IP，于是我自己通過編寫網絡插件把應用 IP 管理在了 etcd 里，然后上線。請問這破壞了云原生的理念了嗎？
A. 否

3.我編寫的容器化應用，會將日志文件寫在某路徑寫死的目錄里。請問這破壞了云原生理念了嗎？
B. 是

4.以下哪些能力是標準 Kubernetes 項目提供的？
A. 容器編排與調度
C. 資源管理
D. 服務注冊與發現

5.云原生架構必須只使用 CNCF 里的項目。
A. 否

6.如果我想學習一鍵部署 Kubernetes 集群，應該關注本課程大綱里的哪個知識點？
B. 集群安裝配置與驗證

7.云原生架構必須選型 Kubernetes 方案。
A. 否

8.容器啟動后，我會時常 SSH 進入到容器里然后寫很多文件。請問這破壞了云原生理念了嗎？
B. 是

9.以下哪些項目跟 Kubernetes 項目功能重合度最高？
C. Docker Swarm 模式（SwarmKit）

10.以下哪些標準，可以用來考察一個應用的架構是不是云原生的？
A. 應用實例能否快速水平擴展
B. 應用是否使用鏡像機制打包來保證環境一致性
C. 應用數據是否都寫在容器數據卷中

2 容器基本概念

1）容器

一個視圖隔離、資源可限制、獨立文件系統的進程集合
視圖隔離：namespace(能看見部分進程；獨立主機名)
控制資源使用率：cgroup(內存大小；CPU使用個數)

2）如何運行容器?

• 1 從docker register 下載鏡像：docker pull
• 2 查看本地容器：docker images
• 3 選擇相應的鏡像并運行：docker run

3）容器運行時的生命周期

• 單進程模型：init進程生命周期=容器生命周期；運行期間可運行exec執行運維操作
• 數據持久化：獨立于容器的生命周期；數據卷-docker volume VS bind

練習

1.以下哪個docker命令創建出來的容器可以自動重啟？
C. docker run -d --restart always busybox top
2.已運行 docker run -d -t —name demo ubuntu top 命令, 在 demo 這個容器內看到 top 命令的 PID 是什么？
B. 1
3.已運行 docker run -d -t —name demo ubuntu top 和 docker run --name demo-x --pid container:demo ubuntu ps 命令，是否可以在 demo-x 容器內部停止容器？
A. 是
4.已運行 docker run -d -t —name demo ubuntu top 命令, docker exec -it demo kill -9 1 強行給容器內一號進程發KILL信號，容器是否會退出？
B. 否
5.已運行 docker run -d —name demo busybox:1.25 top 命令，如何使用 docker 命令來獲取容器 demo 的 Init 進程 PID？
A. docker inspect demo -f '{{.State.Pid}}'

6.已運行 docker run -d -t —name demo ubuntu top 命令，以下哪個 docker 命令創建出的容器能看見 demo 容器進程？
B. docker run --name demo-x --pid container:demo ubuntu ps

7.已運行 docker run -d -t —name demo ubuntu top 和 docker run --name demo-x --pid container:demo ubuntu ps 命令，如果 demo 容器退出了，正在運行的 demo-x 容器是否會退出？
A. 是

8.以下哪個 docker 命令可以用來創建一個使用宿主機主機名的容器？
A. docker run --uts=host ubuntu hostname

9.已知容器 Init 進程 PID，在宿主機上通過 kill -9 PID 的方式結束該進程，容器當前的狀態是什么？
A. Exited

10.如何快速判斷 docker daemon 是否支持動態接管運行容器？
A. docker info | grep 'Live Restore Enabled'
B. docker info -f '{{.LiveRestoreEnabled}}'

3 Kubernetes 核心概念

1）核心功能

• 服務發現與負載均衡
• 容器自動裝箱
• 存儲編排
• 自動容器恢復
• 自動發布與回滾
• 配置與密文管理
• 批量執行
• 水平伸縮

2）Kubernetes的架構

Kubernetes的架構

• API Server：顧名思義是用來處理 API 操作的，Kubernetes 中所有的組件都會和 API Server 進行連接，組件與組件之間一般不進行獨立的連接，都依賴于 API Server 進行消息的傳送；
• Controller：是控制器，它用來完成對集群狀態的一些管理。比如剛剛我們提到的兩個例子之中，第一個自動對容器進行修復、第二個自動進行水平擴張，都是由 Kubernetes 中的 Controller 來進行完成的；
• Scheduler：是調度器，“調度器”顧名思義就是完成調度的操作，就是我們剛才介紹的第一個例子中，把一個用戶提交的 Container，依據它對 CPU、對 memory 請求大小，找一臺合適的節點，進行放置；
• etcd：是一個分布式的一個存儲系統，API Server 中所需要的這些原信息都被放置在 etcd 中，etcd 本身是一個高可用系統，通過 etcd 保證整個 Kubernetes 的 Master 組件的高可用性。
• Node: 是真正運行業務負載的，每個業務負載會以 Pod 的形式運行
• pod：最小的調度以及資源單元；由一個或者多個容器組成；定義容器的運行方式（Command、環境變量等）；提供給容器共享的運行環境（網絡、進程空間）一個 Pod 中運行的一個或者多個容器
  +kubelet：真正去運行這些 Pod 的組件的是叫做 kubelet，也就是 Node 上最為關鍵的組件，它通過 API Server 接收到所需要 Pod 運行的狀態，然后提交到Container Runtime 組件中。
• 在 OS 上去創建容器所需要運行的環境，最終把容器或者 Pod 運行起來，也需要對存儲跟網絡進行管理。Kubernetes 并不會直接進行網絡存儲的操作，他們會靠 Storage Plugin 或者是網絡的 Plugin 來進行操作。用戶自己或者云廠商都會去寫相應的 Storage Plugin 或者 Network Plugin，去完成存儲操作或網絡操作。
• 在 Kubernetes 自己的環境中，也會有 Kubernetes 的 Network，它是為了提供 Service network 來進行搭網組網的。真正完成 service 組網的組件的是 Kube-proxy

練習

1.Kubernetes 的中文含義是________
B. 舵手

2.Kubectl 是________
A. 一個與 Kubernetes 集群進行交互、管理的命令行工具

3.Kubernetes 進行資源調度的最小粒度是________
C. Pod

4.API Server 的主要功能是________
A. 暴露 Kubernetes API，Kubernetes 控制面的前端，也是內部組件互相通訊的中樞

5.Kubelet 或者 Scheduler 是否會和 etcd 直接通訊？
B. 否

6.Scheduler 的主要功能是________
A. Pod 的在Node上的放置

7.如果想要改變 Deployment 中的 Pod 副本數，需要________
B. 通過 API 調用，通知 Kubernetes 需要 Deployment到達到的 Pod 副本最終數目

8.屬于 Node 上的基本組件有________
A. Kubelet
B. Kube-proxy
D. Container runtime engine

9.Kubernetes 的 API Object通常包含那幾部分？
A. apiVersion
B. kind
C. metadata
D. spec
E. status

10.Kubernetes 的主要功能不包括________
A. Service discovery and load balancing（服務發現與負載均衡）
B. Automatic bin packing（容器自動裝箱）
C. Storage orchestration（存儲編排）
D. Self-healing（自動容器恢復）
G. Automated rollouts and rollbacks（自動發布與回滾）
H. Secret and configuration management（配置與密文管理）
I. Horizontal scaling（水平伸縮）
J. Batch execution（批量執行）

4 理解 Pod 和容器設計模式

1）為什么需要 Pod；

在真實的操作系統里面，一個程序往往是根據進程組來進行管理的。Kubernetes 把它類比為一個操作系統，比如說 Linux。針對于容器我們前面提到可以類比為進程，就是前面的 Linux 線程。那么 Pod 又是什么呢？實際上 Pod 就是我們剛剛提到的進程組，也就是 Linux 里的線程組。

當 Kubernetes 把 Helloworld 給拉起來的時候，你實際上會看到四個容器，它們共享了某些資源，這些資源都屬于 Pod，所以我們說 Pod 在 Kubernetes 里面只有一個邏輯單位。

2）Pod 的實現機制

共享網絡

• 容器A和B通過Infra Container的方式共享同一個Network Namespace
• 直接使用localhost進行通信
• 看到的網絡設備和Infra容器看到的完全一樣
• 一個Pod只有一個IP地址，也就是這個Pod的Network Namespace對應的IP地址
• 整個Pod的生命周期和Infra容器一致，而與容器A和B無關

共享存儲

• shared-data 對應在宿主機上的目錄會被同時綁定掛載進了上述兩個容器當中

3）詳解容器設計模式

Sidecar
通過在Pod重定義專門容器，來執行業務容器需要的輔助工作，比如日志收集，debug應用、應用監控
優勢在于將輔助功能同業務容器解耦，實現獨立發布和能力重用

練習

1.容器的“單進程”模型的具體含義是？
B. 容器里PID=1 的進程是應用本身，一般情況下不具備像 systemd 這樣完善的進程管理能力

2.如果：Kubernetes 比作操作系統，容器比作進程，那么：Pod 可以比作進程組
B. 是

3.如果容器 A 要獲取容器 B 里的某個文件，我該怎么做？
B. A、B 放在一個 Pod 里通過共享 Volume 來傳遞文件

4.關于 Pod 的描述正確的是
B. 一個邏輯概念
C. 多個容器的組合
D. Kubernetes 的原子調度單位

5.一個 Pod 里Infra Container 的啟動順序是？
D. 第一個

6.Istio 項目會往用戶的 Pod 里注入 Envoy 容器，用來代理 Pod 的進出流量，這是什么設計模式？
B. sidecar

7.容器的PID=1 的進程是應用本身
B. 是

8.如果沒有 Pod 概念，但我要用多個容器模擬 Pod 的話，可能需要做哪些工作？
A. resource hoarding
B. 樂觀調度
C. 共享這些容器的Network Namespace
D. 設置 Affinity 約束

9.關于 Google Borg 論文論述正確的是？
B. 應用互相之間往往存在協作關系
C. 很多應用需要部署永遠部署在同一臺機器上
D. Google 在進行應用開發的過程中，天生就具備微服務的概念

10.兩個容器之間的超親密關系可能包括哪些情況？
B. 直接發生文件交換
C. 高頻率的 RPC 調用
D. 共享某些 Linux Namespace

5 應用編排與管理：核心原理

1）K8S資源對象

• Spec：期望的狀態
• Status：觀測到的狀態
• Metadata：Labels（用來識別資源的標簽）、Annotations（用來描述資源的注解）、OwnerReference（描述多個資源之間的相互關系）

labels：b=標識性的Key-value元數據
作用：用于篩選資源、唯一的組合資源的方法
可以使用 selector來查詢：類似于 SQL select * where ...

annotations
key:value
作用：存儲資源的非標識性信息；擴展資源的spec/status
特點：一般比label更大；可以包含特殊字符；可以結構化也可以非結構化

ownereference
“所有者”即集合類資源: Pod的集合（replicaset, statefulset）
集合類資源的控制器創建了歸屬資源：Replicaset控制器創建pod
作用：方便反向查找創建資源的對象；方便進行級聯刪除

2）控制器模式

• 控制循環中包括了控制器、被控制的系統、以及能夠觀測系統的傳感器。
• 控制循環中邏輯的傳感器主要由Reflector、Informer、Indexer三個組件構成。

命令式API和聲明式API比較

命令式API

• 如果命令沒有響應，則會反復重試，且需要記錄當前的操作，較為復雜
• 如果多重試了怎么辦：巡檢做修正，額外工作很危險
• 如果多方并發訪問怎么辦？需要加鎖，復雜低效

聲明式API

• 天然地記錄了狀態；
• 冪等操作、可在任意時刻反復操作；
• 正常操作即巡檢；
  . + 可合并多個變更

3）控制器模式總結

• 由聲明式的API驅動-K8S資源對象
• 由控制器異步地控制系統向終態趨近
• 使系統的自動化和無人值守化成為可能
• 便于擴展-自定義資源和控制器

練習

1.controller 中 worker 最不適合做什么操作（D）
A. 創建其他資源對象
B. 重新往 workqueue 中塞入對象
C. 更新資源對象的 status
D. 調用其他耗時的web 服務并等待返回
E. 什么都不做

2.Controller中的object store默認以什么作為索引？
C. 對象的namespace

3.Controller中的 workerqueue 中可以存放什么內容
A. Namespace名+ pod 名

4.下列哪個場景不是 selector 的使用場景(C)
A. 設計一個查詢的界面，根據 label 篩選資源
B. 配置應用的調度規則， 選擇必需調度到包含某些 label 的節點
C. 存儲數據庫應用的配置信息
D. 判斷可能歸屬于 replicaset 的 pod

5.controller中reflector不會對 apiserver進行 LIST 操作的場景(D)
A. controller 重啟的時候
B. 和 apiserver watch 操作異常的情況
C. 配置定期的執行 LIST
D. controller中需要篩選符合標簽的 pod 時候

6.在controller的event handler中， 不適合執行的操作是(D)
A. 根據資源的 ownerreference 找到資源的創建者
B. 判斷資源信息，對于不關心的對象， 直接返回
C. 在workqueue中加入資源
D. 執行控制器的實際處理工作

7.下列關于controller中workqueue描述不正確的(B)
A. 因為workqueue具備去重功能，可以往 workqueue中反復加入資源
B. 為了加速controller的處理，可以往 workqueue中加入資源的指針
C. 一個控制器的workqueue一般只存儲一種類型資源的名字
D. 對于處理 node 的控制器，可以只在 workqueue 中加入節點的名字而不包括命名空間

8.下列哪個鍵值對不適合做為 annotations(B)
A. statefulset 的歷史配置 yaml
B. service對應的應用名，用來方便篩選
C. 用來表示ingress路由的正則表達式值
D. 用來擴展 pod 狀態，表示對應pod 在第三方數據庫的記錄情況

9.下列哪個鍵值對無法作為Kubernetes對象的label？(D)
A. app.kubernetes.io/version=3.4.1
B. failure-domain.beta.kubernetes.io/region=cn-shanghai
C. app-name=trade
D. scaling-config=“min-replicas:50”

10.以下不是聲明式的API 設計(ABC)
A. 創建一個容器的 API 是 POST /containers/create，請求參數是容器的各種規格， 返回系統生成的容器 id
B. 刪除一個容器的 API 是 DELETE /containers/<containerid>, 返回一個異步刪除的工單號，可以根據工單號查詢刪除進度
C. 給應用擴容的 API 是 PUT /containers/create?increaseReplicas=1， 參數指定擴容的增量容器數量
D. 更新一個容器鏡像的 API 是 PATCH /containers/<containerid>?image=nginx, 返回的是容器新的目標狀態

06：應用編排與管理：Deployment

問題：我們可以直接管理集群中的所有Pod嗎？

• 1 如何保證集群內可用Pod的數量
• 2 如何為所有Pod更新鏡像版本
• 3 更新的過程中，如何保證服務可用性
• 4 更新的過程中，發現問題如何快速回滾

1）Deployment：管理部署發布的控制器

• 1 定義一組Pod的期望數量，controller會維持Pod數量與期望數量一致

• 2 配置Pod發布方式，controller會按照給定策略更新Pod，保證更新過程中不可用的pod數量在限定范圍內

• 3 如果發布有問題，支持“一鍵”回滾

• Deployment的語法

# Deployment的yaml文件
apiVersion:apps/v1
kind: Deployment
metadata:                             #deployment元信息
  name: nginx-deployment
  labels:
    app:nginx
spec:
  replicas: 3                           # 期望Pod數量
  selector:                              # Pod的選擇器
    matchLabels:
      app:nginx
  template:                            # Pod相關的一個模板
    metadata: 
      labels:                               # 標簽
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9                 # 鏡像版本
        ports:
        - containerPort: 80

常用語法：

• 創建一個Deployment

kubectl create -f nginx-development.yaml

• 查看Deployment狀態

kubectl get deployment

• 查看Pod

kubectl get pod

• 更新鏡像

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

• 快速回滾

# 回滾到Deplyment上一個版本
kubectl rollout undo deployment/nginx-deployment

2）架構設計

• Deployment只負責管理不同版本的ReplicaSet，由ReplicaSet管理Pod副本數
• 每個ReplicaSet對應了Deployment template的一個版本
• 一個ReplicaSet下的Pod都是相同的版本

Deployment控制器的實現原理

• Deployment 管理多版本的方式，是針對每個版本的 template 創建一個 ReplicaSet，由 ReplicaSet 維護一定數量的 Pod 副本，而 Deployment 只需要關心不同版本的 ReplicaSet 里要指定多少數量的 Pod；
• 因此，Deployment 發布部署的根本原理，就是 Deployment 調整不同版本 ReplicaSet 里的終態副本數，以此來達到多版本 Pod 的升級和回滾。

ReplicaSet控制器實現原理

ReplicaSet controller 的邏輯很簡單，就只管理副本數

擴/縮容模擬

• Deployment的副本數由ReplicaSet管理
• 修改Deployment replicas之后，controller會把replicas同步到當前版本的ReplicaSet中，由ReplicaSet執行擴容/縮容

發布模擬

• Deployment controller 會新建一個對應 template2 的 ReplicaSet。
• 創建出來之后 ReplicaSet 會逐漸修改兩個 ReplicaSet 的數量，比如它會逐漸增加 ReplicaSet2 中 replicas 的期望數量
• 逐漸減少 ReplicaSet1 中的 Pod 數量，刪除舊版本的Pod

回滾模擬

• 回滾的過程，其實就是Deployment controller重新調整下屬ReplicaSet的replicas數量
• 最終使舊版本的ReplicaSet重新擴出所有的Pod

spec字段解析

• MinReadySeconds: 判斷Pod available的最小ready時間
• revisionHistoryLimit：保留歷史reversion(ReplicaSet)的數量，默認值為10
• paused：標識Deployment只做數量維持、不做新的發布
• progressDeadlineSeconds：判斷Deployment status condition為failed的最大時間

升級策略字段解析

• MaxUnavailable：滾動過程中最多有多少個Pod不可用
• MaxSurge：滾動過程中最多存在多少個Pod超過期望replicas數量

練習

1.以下關于paused說法錯誤的是：（D）
A. 可以在deployment發布的過程中修改paused字段
B. paused默認值為false
C. paused不可以用來暫停擴縮容操作
D. deployment controller在發布出現問題時會自動設置paused

2.以下關于revision歷史版本說法正確的是：(B)
A. 使用deployment可以rollout回滾到任何一個歷史上的版本
B. pod-template-hash標識了pod的revision版本
C. revisionHistoryLimit字段不設置默認沒有數量限制
D. 更新了deployment任意字段，最新revision會發生變化

3.一個Deployment中，哪些labels/selector必須一致：(C)
A. deployment.Labels與deployment.Spec.Template.Labels一致
B. deployment.Labels與deployment.Spec.Selector一致
C. deployment.Spec.Selector與deployment.Spec.Template.Labels一致
D. deployment.Labels、deployment.Spec.Selector、deployment.Spec.Template.Labels三者都要一致

4.以下哪個明顯不是deployment擴容出來的pod name：(B)
A. nginx-deployment-77964d65f-5h52m
B. nginx-deployment-676cc869
C. nginx-deployment-6987cdb55b-r4tnr
D. nginx-deployment-5c689d88bb-vqf4b

5.創建Deployment描述文件中寫的template，用處不包括：(D)
A. 聲明Pod的掛載目錄
B. 計算ReplicaSet的hash
C. 指定鏡像版本
D. 指定期望數量

6.通過Deployment不能實現以下功能：(C)
A. 應用擴縮容
B. 應用發布回滾
C. 應用重啟
D. 應用副本數量維持

7.關于MaxUnavailable以下說法正確的是：(B)
A. MaxUnavailable不可以設置為0，否則無法發布
B. MaxUnavailable可以設置超過replicas
C. MaxUnavailable可以和MaxSurge同時設置為0
D. MaxUnavailable可以設置超過100%

8.Deployment與ReplicaSet的關系與以下哪組資源最像？(C)
A. Pod與Node
B. Pod與Container
C. ReplicaSet與Pod
D. Deployment與Pod

9.以下關于Deployment的說法正確的有哪些?(AC)

A. Deployment下running的Pod數量可能大于replicas數量
B. Deployment更新鏡像時一定會創建一個ReplicaSet
C. 用kubectl rollout undo命令回滾Deployment，不會創建新的ReplicaSet
D. 滾動發布的時候MaxUnavailable和MaxSurge可以同時設為0

10.指定Deployment回滾到某個歷史版本執行成功的過程中，不會發生以下哪些事件：(BC)
A. Pod創建和銷毀
B. ReplicaSet創建和銷毀
C. Deployment期望數量變化
D. Deployment template變化

07：應用編排與管理 - Job和DaemonSet

1.如果 Job 的 activeDeadlineSeconds 設置為 10s， backoffLimit 為 5 次。 當任務運行到第三次時候，時間已經到達 10s，請問此任務會繼續重試運行，還是會 DeadlineExceeded？
A. DeadlineExceeded

2.DaemonSet 不能幫助我們做什么事情？（D）
A. 保證集群內每一個(或者一些)節點都運行一組相同的Pod
B. 跟蹤集群節點狀態，保證新加入的節點自動創建對應的Pod
C. 跟蹤集群節點狀態，保證移除的節點刪除對應的Pod
D. 能夠設置Pod重試次數，到達指定重試次數后停止

3.有一個任務會偶發失敗，我們希望失敗的時候能夠不斷的重試直到任務能夠運行成功，應該使用哪幾個標簽配合完成?(B)
A. restartPolicy: Never
B. restartPolicy: OnFailure
C. restartPolicy: Always

4.以下哪幾個參數配合能夠實現將任務一共運行 10 次，每次均運行 2 個pod?
A. .spec.completions: 10 .spec.parallelism: 2

5.CronJob 中 schedule 字段書寫規范，以下哪一個代表每分鐘執行一次？
A. */1 * * * *

6.Job 能幫助我們做的事情不包括如下哪個？(A)
A. 確保每一臺機器都能運行指定的Pod
B. 跟蹤Pod狀態，根據配置及時重試失敗的 Pod
C. 確定依賴關系，保證上一個任務運行完畢后再運行下一個任務
D. 控制任務并行度，并根據配置確保Pod 隊列大小

7.Job 中 spec 可否指定replicas 參數？
B. 不可以

8.使用哪些標簽能讓 daemonset 的 pod 只運行在某些節點？
A. .spec.template.spec.nodeSelector
B. .spec.template.spec.affinity

9 .Daemonset 有哪幾種更新方式？
B. On-Delete
C. RollingUpdate

08：應用配置管理

練習

1.ServiceAccount創建完成，其對應的Secret信息由哪個組件更新
B. kube-controller-manager

2.ServiceAccount用的Secret類型是哪一種
B. kubernetes.io/service-account-token

3.Pod中引用ConfigMap不正確的是（c）
A. 環境變量
B. 命令行參數
C. 資源聲明
D. Volumes

4.應用中獲取Secret時，推薦如下哪種方式
C. Get

5.因為ETCD數據寫入大小限制，ConfigMap數據大小要求小于1MB
正確

7.當節點磁盤空間不足時，Pod被驅逐的順序為: BestEffort 先于 Burstable
正確

8.InitContainer理解正確的有
A. InitContainer先于普通容器啟動執行
B. 多個InitContainer的執行是按定義次序串行執行，而多個普通容器是并行執行
C. InitContainer執行成功后就結束退出，而普通容器可以一直執行
D. Pod重啟時，InitContainer會再次執行

9.下面容器資源申明合理的是(ACD)
A. resources: requests: cpu: 100m limits: cpu: 500m
B. resources: requests: cpu: 200m limits: cpu: 100m
C. resources: requests: cpu: 100m memory: 64Mi
D. resources: limits: cpu: 100m

10.下面哪些是Security Context的設置項
A. SELinux
B. privileged
C. Seccomp
D. AllowPrivilegeEscalation

09：應用存儲和持久化數據卷：核心知識

問題：1、如果一個Pod中某一個容器異常退出，被kubelet拉起如何保證之前產生的重要數據不丟失？2、同一個Pod的多個容器如何共享數據？

Kubernetes Volumn類型：

• 1、本地存儲：emptydir/hostpath
• 2、網絡存儲：in-tree；out-of-tree
• 3、Projected Volumn：secret/configmap/downwardAPI/serviceAccountToken
• 4、PVC與PV體系

Pod Volumns
不足之處：無法準確表達數據volume復用/共享語義，新功能擴展實現

Persistent Volumns
將存儲與計算分離，使用不同的組件（Controllers）管理存儲與計算資源，解耦Pod與Volumn的生命周期關聯

PeristentVolumnClaim(PVC)設計意圖

• 1 職責分離，PVC中只用聲明自己需要的size、access mode(單node獨占還是多node共享、只讀還是讀寫訪問)等業務真正關心的存儲需求(不用關心存儲實現細節), PV和其對應的后端存儲信息則由交給cluster admin統一運維和管控，安全訪問策略更容易控制
• 2 PVC簡化了User對存儲的需求，PV才是存儲的實際信息的承載體，通過kube-controller-manager中的PersistentVolumnController將PVC與合適的PV bound在一起，從而滿足User對存儲的實際需求。
• 3 PVC像是面向對象編程抽象出來的接口，PV是接口對應的實現

練習

1.在Kubernetes PVC+PV體系下通過CSI實現的volume plugins動態創建pv到pv可被pod使用不包括下面哪些階段？（D）
A. create volume
B. attach volume
C. mount volume
D. create & start container

2.FlexVolume以及CSI哪個是當前Kubernetes社區更推薦out-of-tree volume plugins實現方式？
B. CSI(Container Storage Interface)

3.以下有關PVC和PV分開設計的好處說法錯誤的有？(C)
A. 職責分離(用戶只用關心怎么使用，cluster admin關心如何實現)
B. 簡化用戶使用存儲所需了解的存儲知識
C. 可以使多個PVC對應到同一PV上，以滿足多對一共享需求

4.有關PVC和PV Bound的說法不正確的有？(D)
A. Bound操作是由PersistentVolumeController來執行的
B. 處在Bound狀態的PVC對象.spec.volumeName字段 == PV name
C. 處在Bound狀態的PV對象.spec.ClaimRef 記錄了bound的PVC對象的信息
D. unbound(刪除pvc對象)的PV對象可以直接被新的PVC對象bound

5.在Pod中聲明使用volume常見類型？
A. 本地存儲
B. 網絡存儲
C. Projected Volume(投射卷)
D. PVC+PV持久化存儲

6.在Pod中聲明使用volume需要配置哪些字段？
A. .spec.volumes
B. .spec.initContainers.volumeMounts
C. .spec.containers.volumeMounts

7.使用Static Provision的PV需要Kubernetes集群管理員和用戶分別做什么？
A. Kubernetes集群管理員預先創建存儲
B. Kubernetes集群管理員根據預創建的存儲創建相應的PV對象
C. 用戶創建PVC對象聲明存儲需求
D. 用戶在Pod中通過聲明自己具體如何使用存儲

8.使用Dynamic Provision的PV需要Kubernetes集群管理員和用戶分別做什么？
A. Kubernetes集群管理員創建不同類型存儲所需的不同的StorageClass對象
B. 用戶創建PVC對象聲明存儲需求，并在PVC對象中通過storageClassName字段說明需要的存儲類型
C. 用戶在Pod中通過聲明自己具體如何使用存儲

9.在Kubernetes PVC+PV體系下通過CSI實現的volume plugins動態創建pv到pv可被pod使用有哪些組件需要參與？
A. PersistentVolumeController + CSI-Provisoner + CSI controller plugin
B. AttachDetachController + CSI-Attacher + CSI controller plugin
C. Kubelet + CSI node plugin

10.在Kubernetes PVC+PV體系下通過CSI實現的volume plugins包括？(AB)
A. Kubernetes社區驅動實現的通用功能部分（https://kubernetes-csi.github.io/）
B. 云存儲廠商實現的對接其OpenAPIs的driver部分
C. 自定義CRD以及Controller

10：應用存儲和持久化數據卷-存儲快照和拓撲調度

1）存儲快照

產生背景：

• 1 如何保證重要數據在誤操作之后可以快速恢復，以提高數據操作的容錯率
• 2 如何能夠快速進行復制，遷移重要數據的動作？如進行環境復制與數據開發等。

存儲快照用戶接口-snapshot

存儲快照接口-restore

PersistentVolumeClaim擴展字段.spec.dataSource可以指定為VolumeSnapshot對象，從而根據PVC對象生成新的PV對象，對應的存儲數據是從VolumeSnapshot關聯的VolumeSnapshotContent restore的

K8S對Volume Snapshot/Restore的處理流程

2）Topology-拓撲

這里的拓撲是指對Kubernetes集群中nodes的“位置”關系一種認為的劃分規則，通過在node的labels種設置以標識自己屬于具體的拓撲域。

產生背景：
Kubernetes中通過PVC&PV體系將存儲與計算分離，即使用不同的Controllers管理存儲資源和計算資源。但如果創建的PV有訪問“位置”（.spec.nodeS=Affinity）的限制，也就是只有在特定的一些nodes上才能訪問PV，原有的創建Pod的流程與創建PV的流程分離，也就無法保證新創建的Pod被調度到可以訪問PV的node節點上，最終導致Pod無法正常運行起來。

3）存儲拓撲調度

1 本質問題：
PV在Binding或者Dynamic Provisioning時，并不知道使用它的Pod會被調度到哪些Node上？但PV本身的訪問對Node的位置（拓撲）有限制。

2 流程改進

• Binding/Dynamic Provisioning PV 的操作Delay到調度結果之后做，好處：
  對于pre-provisioned的含有Node Affinity的PV對象，可以在Pod運行的Node確認之后，根據Node找到合適的PV對象，然后與Pod中使用的PVC Binding，保證Pod運行的Node滿足PV對訪問”位置“的要求
  對于dynamic provisioning PV場景，在Pod運行確認之后，可以結合Node的”位置“信息創建可被該Node訪問的PV對象

3 相關組件的改進

• PV Controller：支持延遲Binding操作
• Dynamic PV Provisioner：動態創建PV時要結合Pod待運行的Node的“位置‘信息
• Scheduler：選擇Node時要考慮Pod的PVC Binding需求，也就是要結合pre-provisioned的PV的Node Afffinity以及dynamic provisioning時PVC指定StorageClass.AllowedTopologies的限制

K8S對Volumn Topology-aware Scheduling處理流程

練習

1.Kubernetes中Node的拓撲信息記錄在哪里？（B）
A. .metadata.annotations
B. .metadata.labels

2.下面在Kube-Scheduler中結合Pod中聲明的PVCs選擇Node過程描述正確的有？（C）
A. Pod中已經Bound的PVCs在Kube-Scheduler不做處理
B. Pod中所有UnBound的PVCs會先找到能匹配的PV列表，并check PV的NodeAffinity與Node Labals中的拓撲信息是否匹配
C. Pod中需要Dynamic Provisioning PV的PVCs，check StorageClass .allowedTopologies與Node Labals中的拓撲信息是否匹配

3.在Kubernetes中使用自定義的拓撲（如rack, foo, bar）是否需要相關組件做修改？
B. 否

4.下列有關使用存儲拓撲調度時對StorageClass的配置正確的有？
A. 需要通過設置.volumeBindingMode: WaitForFirstConsumer來聲明PVC延時處理
B. 可以通過.allowedTopologies限制動態生成的PV的拓撲限制，拓撲限制會寫到動態生成的PV .spec.nodeAffinity中
C. 可以干預哪些需要使用該StorageClass動態生成PV對象的PVC的使用方Pod的可調度的Node

5.下列有關如何使用存儲拓撲調度的說法正確的有？
A. 聲明delay binding的StorageClass對象（.volumeBindingMode=WaitForFirstConsumer）
B. PVC對象.spec.storageClassName指定為聲明了delay binding的StorageClass對象
C. 在靜態（預）創建的PV上的.spec.nodeAffinity添加對使用該PV的Pod所在Node拓撲限制
D. 在需要動態創建的PV所使用的StorageClass的.allowedTopologies中限制動態創建的存儲能被使用的拓撲限制

6.Kubernetes中為了支持存儲拓撲調度相關組件做的改變有？
A. PersistentVolumeController支持PVC與PV的delay binding
B. 動態創建PV的csi-provisioner支持將第一個使用PV的Pod待運行Node的拓撲信息以及StorageClass .allowedTopologies傳遞給創建存儲的Driver
C. Kube-Scheduler結合Pod使用的PVCs，預分配的PV Node Affinity以及StorageClass .allowedTopologies選擇合適的Node

7.可以限制PV對象可被訪問拓撲位置限制的地方？(AB)
A. StorageClass: .allowedTopologies
B. PV: .spec.nodeAffinity
C. Node: .metadata.labels

8.使用存儲快照功能需要用到哪些Kubernetes API資源對象？
A. VolumeSnapshot
B. VolumeSnapshotClass
C. VolumeSnapshotContent
D. PersistentVolumeClaim

9.Kubernetes中基于CSI實現存儲快照（snapshot&restore）功能需要的組件有？
A. Kubernetes csi-snapshotter Controller
B. 云存儲廠商基于存儲快照的OpenAPI實現的Driver：Kubernetes csi-snapshotter GRPC server
C. Kubernetes csi-provisioner Controller
D. 云存儲廠商基于存儲快照create存儲的OpenAPI實現的Driver：Kubernetes csi-provisioner GRPC server

10.Kubernetes csi-snapshotter Controller中實現的功能包括？
A. watch VolumeSnapshot&&VolumeSnapshotContent等API資源對象變化
B. 根據VolumeSnapshot API資源對象聲明調用相應云存儲Driver（即csi-snapshotter GRPC server）創建快照，并生成VolumeSnapshotContent
C. bind VolumeSnapshot and VolumeSnapshotContent