21：Kubenetes存储架构及插件使用
1）Kubernetes挂载Volume过程
1 用户创建一个包含PVC的Pod(使用动态存储卷)
2 PV Controller发现这个PVC处于待绑定状态，调用Volume Plugin(in-tree或out-of-tree)创建存储卷，并创建PV对象；并将创建的PV与PVC绑定
3 Scheduler根据Pod配置、节点状态、PV配置等信息，把pod调度到worker节点Node上
4 AD Controller发现Pod和PVC处于待挂载状态，调用Volume Plugin(in-tree或out-of-tree)实现设备挂载到目标节点（/dev/vdb）
5 在Worker节点上，Kubelet(Volume Manager)等待设备挂载完成，通过Volume Plugin将设备挂载到指定目录：/var/lib/kubelet/pods/
6 Kubelet在被告知挂载目录准备好之后，启动Pod中的containers,用Docker -v 方式(bind)将已经挂载到本地的卷映射到容器中。
In-Tree：在Kubernetes源码内部实现，和Kubernetes一起发布、管理、更新迭代慢、灵活性差
out-of-tree：代码独立于Kubernetes，由存储尝试实现；CSI/Flexvolume是两种机制，可以根据存储类型实现为不同的存储插件。
2）Kubernetes存储架构
- PV Controller：负责PV/PVC的绑定、生命周期管理，并根据需求进行数据卷的Provision/Delete操作
- AD Controller：负责存储设备的Attach/Detach操作，将设备挂载到目标节点
- Volume Manager：管理卷的Mount/Unmount操作、卷设备的格式化等；
- Volume Plugins：扩展各种存储类型的卷管理能力，实现第三方存储的各种操作能力与Kubernetes存储系统结合
- Scheduler：实现Pod调度能力，存储相关的调度器实现了针对存储卷配置进行调度。
3）Flexvolume介绍
- Flexvolume实现了VolumePlugin的Attach/Detach/Mount/Unmount接口定义，这些接口由第三方实现，并按照一定的规则调用接口
- Flexvolume是一个由Kubelet驱动的可执行文件，每一次接口调用均为一次可执行文件的命令行调用；不是常驻内存的守护进程
- 调用Flexvolume的Stdout作为kubelet调用的返回结果，要求JSON格式
- 所有挂载均先将远程设备挂载到本地主机，然后从主机通过bind映射到容器内部
4）CSI介绍及使用
同Flexvolume一样，为第三方存储实现数据卷挂载实现的抽象接口
有了Flexvolume，为什么还要CSI?
- 提供容器存储统一接口，实现编排系统与存储类型解耦，在多平台运行（K8S，Mesos，Swarm）
- 容器化部署，减少环境依赖，增强安全性，丰富插件功能
CSI包含两部分： - CSI Controller Server：实现控制端的创建、删除、挂载、卸载功能
- CSI Node Server：实现节点上的mount、Unmount功能
22：有状态应用编排-StatefulSet
1)需求分析
对于一些有状态应用，是否可以用Deployment满足？
- 1 Pod之间并非相同的副本，每个Pod有一个独立的标识
- 2 Pod独立标识要能够对应到一个固定的网络标识，并在发布升级后继续保持
- 3 每个Pod有一块独立的存储盘，并在发布升级之后还能继续挂载原有的盘（保留数据）
- 4 应用发布之后，按照固定顺序升级Pod
2)架构设计
StatefulSet可能会创建三种类型的资源：
- 1 ControllerReversion：通过这个资源，StatefulSet可以很方便地管理不同版本的template模板
- 2 PVC：如果在StatefulSet中定义了volumeClaimTemplates，StatefulSet会在创建pod之前，先根据这个模板创建PVC，并把PVC加到pod volume中
- 3 Pod：StatefulSet按照顺序创建、删除、更新Pod，每个Pod由唯一的序号。
24：KubernetesAPI编程利器-Operator和OperatorFramework
| 操作 | 概念 |
|---|---|
| CRD(custom resource defination) | 允许用户自定义Kubernetes资源，是一个类型 |
| CR(Custom Resource) | CRD的一个具体实例 |
| webhook | webhook关联在apiserver上，是一种HTTP回调，一个基于web应用实现的webhook会在特定事件发生时把消息发送给特定的URL。用户一般可以定义为两类webhook，分别是mutating webhook(变更传入对象)和validating webhook(传入对象校验) |
| 工作队列 | controller核心组件，controller会监控集群内关注资源对象的变化，并把相关对象的事件(动作和key)，存储于工作队列中 |
| controller | controller是监测集群状态变化，并据此作出相应处理的控制循环。它关联一个工作队列，循环处理队列内容。每一个controller都试图把集群状态向预期状态推动，只是关注的对象不同，如replicaset controller 和endpoint controller |
| operator | operator是描述、部署和管理kubernetes应用的一套机制，从实现上来说，operator=CRD+webhook+controller |
常见operator工作模式
- 1 用户创建一个CRD
- 2 apiserver转发请求给webhook
- 3 webhook负责CRD的缺省值配置和配置项检验
- 4 controller获取到新建的CRD,处理“创建副本”等关键逻辑
- 5 controller实时检测CRD相关集群信息并反馈到CRD状态
OperatorFramework概述
Operator Framework给用户提供了webhook和controller框架，包括消息通知、失败重新入队等等，开发人员仅需要关心被管理应用的运维逻辑实现。
工作流程
- 1 用户创建sidecarset
- 2 webhook负责sidecars的缺省值配置和配置项校验
- 3 用户创建pod
- 4 webhook负责向pod注入sidecar容器
- 5 controller实时检测Pod信息，并更新到sidecarset状态
25：Kubernetes网络模型进阶
Kubernetes的Service丰富多样
| Service | 功能 |
|---|---|
| ClusterIP | Node内部使用，将Service承载在一个内部ClusterIP上，注意该服务只能保证集群内可以触达，这也是默认的服务类型 |
| NodePort | 供集群外部调用，将Service承载在Node的静态端口上，其实服务创建的时候也会自动创建一个ClusterIP，这样一来，服务就暴露在Node的端口上，集群外的用户可通过<NodeIP>:<NodePort>的形式调用到Service |
| LoadBalancer | 给云厂商留的扩展接口，将Service通过外部云厂商的负载均衡接口承载，其实为方便云厂商的插件编写，NodePort和ClusterIP两种机制也会自动创建，云厂商可选择将外部LB挂载到这两种机制上去 |
| ExternalName | 去外面自由飞翔，将Service的服务完全映射到外部的名称（如某域名），这种机制完全依赖外部实现，Service与CNAME挂钩，内部不会自动创建任何机制 |
26：理解CNI和CNI插件
CNI(Container Network Interface):容器网络的API接口
1）Kubernetes中如何使用CNI
- 1 配置CNI配置文件
- 2 安装CNI二进制插件
- 3 在这个节点上创建Pod
- 4 Kubelet会根据CNI配置文件执行CNI插件
- 5 Pod网络配置完成
2）CNI插件的三种实现模式
| 模式 | 功能 |
|---|---|
| Overlay | 靠隧道打通，不依赖底层网络 |
| 路由 | 靠路由打通，部份依赖底层网络 |
| Underlay | 靠底层网络打通，强依赖底层 |
28：理解容器进行时接口CRI
CRI的由来
抽象一套POD级别的容器接口，解耦Kubelet与容器运行时
定义通过gRPC协议通讯（gRPC性能优于http/REST模式）
29：安全容器技术
云原生语境下的容器，实质是“应用容器”——以标准格式封装的，运行于标准操作系统环境上的应用打包，或运行这一应用打包的程序/技术。
安全容器是一种运行时技术，为容器应用提供一个完整的操作系统执行环境，但将应用的执行与宿主机操作系统隔离开，避免应用直接访问主机资源，从而可以在容器主机之间或容器之间提供额外的保护。
安全问题的唯一正解在于允许那些（导致安全问题的）Bug发生，但通过额外的隔离层来阻挡它们。
30：理解RuntimeClass和多容器运行时
RuntimeClass是Kubernetes一种内置的全局域资源，主要用来解决多个容器运行时混用的问题
RuntimeClass中配置Scheduling，可让Pod自动调度到运行了指定容器运行时的节点上。但前提是节点上的label列表需要用户提前手动配置好
RuntimeClass中配置Overhead，可以把Pod中业务运行所需以外的开销统计进来，让调度、ResourceQuota、Kubelet Pod驱逐等行为更为准确。
