CNCF-云原生技术（一）

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/, 返回一个异步删除的工单号，可以根据工单号查询删除进度
C. 给应用扩容的 API 是 PUT /containers/create?increaseReplicas=1， 参数指定扩容的增量容器数量
D. 更新一个容器镜像的 API 是 PATCH /containers/?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：应用配置管理

命令	功能
ConfigMap	管理容器运行所需的配置文件，环境变量，命令行参数等可变配置用于解耦容器镜像和可变配置，从而保证工作负载（Pod）的可移植性
Secret	集群中用于存储密码，token等敏感性息用的资源对象。其中敏感数据采用base-64编码保存，相比存储在明文的ConfigMap中更规范，更安全
ServiceAccount	主要用于解决Pod在集群中的身份认证问题。其中认证使用的授权信息，则利用前面讲到的Secret进行管理
Resource	容器资源配置管理，CPU、内存、临时存储，需要指定需要的数量和资源的界限
SecurityContext	限制容器的行为，保证系统和其他容器的安全
initContainer	会比普通container先启动；会按照定义的顺序启动，而普通的container是并发启动的；执行成功后结束退出，普通容器会一直执行

练习

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