云原生面试整理

kubenetes架构与运维

1.kubernetes 的组成

kubernetes 架构主要包含两个组件：

• 主节点(Master)
• 工作节点(Node)

主节点有许多内置组件：

• kube-apiserver:这是 Kubernetes 控制面板中唯一带有用户可访问 API 以及用户可交互的组件。API 服 务器会暴露一个 RESTful 的 Kubernetes API 并使用 JSON 格式的清单文件（manifest files）。
• kube-controller-manager:被称为“kube-controller manager”，它运行着所有处理集群日常任务的控制器。包括了节点控制器、副本控制器、端点（endpoint）控制器以及服务账户等。
• kube-scheduler:调度器会监控新建的 pods（一组或一个容器）并将其分配给节点。
• data-store(etcd):Kubernetes 使用“etcd”。这是一个强大的、稳定的、高可用的键值存储，被 Kubernetes 用于长久储存所有的 API 对象。
• kube-dns：它负责将服务名称解析为相应的IP地址，并确保服务之间可以通过名称进行通信。

工作节点内置组件:

• kubelet:负责调度到对应节点的 Pod 的生命周期管理，执行任务并将 Pod 状态报告给主节点的渠道，通过容器运行时（拉取镜像、启动和停止容器等）来运行这些容器。它 还会定期执行被请求的容器的健康探测程序。
• kube-proxy:它负责节点的网络，在主机上维护网络规则并执行连接转发。它还负责对正在服务的 pods 进行负载平衡。

2.简述kubenetes 的基础概念

Master控制组件

• Kubenetes API Server： 作为K8s系统的入口，其封装了核心对象的增删改查操作， 集群内各个功能模块之间数据交互和通信的中心枢纽
• Kubenetes Scheduler： 为新建立的Pod进行节点选择负责集群的资源调度
• Kubenetes Controller： 负责执行各种控制器，目前已经提供了很多控制器来保证Kubenetes的正常运行；
• Replication Controller： 管理维护 Replication Controller，管理Replication Controller 和Pod，保证Replication Controller 定义的副本数量与实际运行的Pod数量一致；
• Node Controller： 管理维护Node， 定期检查Node的健康状态，标识出失效/未失效的Node节点
• Namespace Controller： 管理维护Namespace，定期清理无效的Namespace，包括Namespace下的API对象，比如Pod，Service 等
• Service Controller： 管理维护Serivice，负责负载均衡以及服务代理。
• Endpoint Controller： 管理维护Endpoints，关联Service 和Pod，创建Endpoints为Service的后端， 当Pod发生变化时，实时更新Endpoints。
• Service Account Controller： 管理维护Service Account，为每个Namespace创建默认的Serive Account，同时为Service Account 创建Service Account Sercret。
• Daemonset Controller： 管理维护Daemon Set，负责创建Daemon Pod， 保证指定的Node上正常的运行Daemon Pod。
• Deployment Controller：管理维护Deployment，关联Deployment和Replication Controller，保证运行指定数量的Pod。当Deployment更新时，控制实现Replication Controller 和Pod 的更新。
• Job Controller： 管理和维护Job， 为Job创建一次性任务Pod， 保证完成Job指定完成的任务数目。
• Pod Autoscaler Controller：实现Pod的自动伸缩，定时获取监控数据，进行策略匹配， 当满足条件时执行Pod的伸缩动作。

3.Worker 节点加入集群的过程

通常需要对 Worker 节点进行扩容，从而将应用系统进行水平扩展。主要过程如下：

1. 在该 Node 上安装 Docker、kubelet 和 kube-proxy 服务；
2. 然后配置 kubelet 和 kubeproxy 的启动参数，将 Master URL 指定为当前Kubernetes 集群 Master 的地址，最后启动这些服务；
3. 通过 kubelet 默认的自动注册机制，新的 Worker 将会自动加入现有的Kubernetes 集群中；
4. Kubernetes Master 在接受了新 Worker 的注册之后，会自动将其纳入当前集群的调度范围。

4.如何使用 EFK 统一管理k8s日志

在 Kubernetes 集群环境中，通常一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，通常采用 EFK 实现。

EFK 是 Elasticsearch、Fluentd 和 Kibana 的组合，其各组件功能如下：

• Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口；
• Fluentd：负责从 Kubernetes 搜集日志，每个 node 节点上面的 fluentd 监控并收集该节点上面的系统日志，并将处理过后的日志信息发送给 Elasticsearch；
• Kibana：提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志。

通过在每台 node 上部署一个以 DaemonSet 方式运行的 fluentd 来收集每台 node 上的日志。Fluentd 将docker 日志目录/var/lib/docker/containers 和/var/log 目录挂载到 Pod 中，然后 Pod 会在 node 节点的/var/log/pods 目录中创建新的目录，可以区别不同的容器日志输出，该目录下有一个日志文件链接到/var/lib/docker/contianers 目录下的容器日志输出。

5.K8s如何优雅的关机维护节点

由于 Kubernetes 节点运行大量 Pod，因此在进行关机维护之前，建议先使用kubectl drain 将该节点的 Pod 进行驱逐，然后进行关机维护。

kubenetes 控制平面

1. etcd 介绍和适应的场景

Etcd是CoreOS基于Raft开发的分布式key-value存储， etcd基于其优秀的特点， 可广泛的应用于以下场景

• 基本的key-value存储
• 监听机制
• key的过期及续约机制，用于监控和服务发现
• 原子Compare And Swap和Compare And Delete，用于分布式锁和leader选举

2.etcd store 的实现

etcd v3 store 分为两部分:

• 一部分是内存中的索引，kvindex，是基于Google开源的一个Golang的btree实现的
• 另外一部分是后端存储。按照它的设计，backend可以对接多种存储，当前使用的boltdb。是一个单机的支持事务的kv存储，etcd 的事务是基于boltdb的事务实现的。

etcd 在每次修改 key 时会生成一个全局递增的版本号（revision）。

• 然后通过数据结构 B-tree 保存 key 与版本号之间的关系；
• 再以版本号作为 boltdb key，以用户的 key-value 等信息作为 boltdb value，保存到 boltdb。也就是说 etcd 会在boltdb中把每个版本都保存下，从而实现了多版本机制。

reversion的结构

reversion主要由两部分组成，第一部分main rev，每次事务进行加一，第二部分sub rev，同一个事务中的每次操作加一。

etcd 提供了命令和设置选项来控制compact来进行版本压缩，同时支持put操作的参数来精确控制某个key的历史版本数。

内存kvindex保存的就是key和reversion之间的映射关系，用来加速查询。

k8s更新应用时，K8S都会记录当前的版本号，即为revision，当升级出现问题时，可通过回滚到某个特定的revision，默认配置下，K8S只会保留最近的几个revision，可以通过Deployment配置文件中的spec.revisionHistoryLimit属性增加revision数量，默认是10。

3.K8s部署高可用的etcd经验

• 合适的peer数量：通常为5个，可以允许2个节点挂掉不影响正常运行
• 部署方式的优化：
  • apiserver和etcd可以部署在同一节点
  • 部署的方式尽量同地域部署
• 负载均衡：可以将etcd事件分离的多个不同的etcd集群， 对etcd集群进行规划和流量负载均衡
• 合理的日志文件大小： 无论是数据创建还是修改， etcd都会保存raft日志，为了有效降低日志文件大小，etcd会以固定周期创建快照保存系统的当前状态，并移除旧日志文件。另外当修改次数累积到一定的数量（默认是10000，通过参数“–snapshot-count”指定），etcd也会创建快照文件。
• 自动压缩历史版本：etcd会为每个键都保存了历史版本。为了避免出现性能问题或存储空间消耗完导致写不进去的问题，这些历史版本需要进行周期性地压缩。压缩历史版本就是丢弃该键给定版本之前的所有信息，节省出来的空间可以用于后续的写操作。etcd支持自动压缩历史版本。在启动参数中指定参数“–auto-compaction”，其值以小时为单位。也就是etcd会自动压缩该值设置的时间窗口之前的历史版本。
• 定期消除碎片化： 压缩历史版本，相当于离散地抹去etcd存储空间某些数据，etcd存储空间中将会出现碎片。这些碎片无法被后台存储使用，却仍占据节点的存储空间。因此定期消除存储碎片，将释放碎片化的存储空间，重新调整整个存储空间。 可以使用命令etcdctl defrag
• 备份方案
  • etcd备份： 通过 etcdctl snapshot save， 备份的时间间隔需要考虑， 时间过长， 会导致数据丢失过多， 时间间隔太短， 会造成etcd频繁对数据上锁， 会对etcd造成影响
  • 如何确保备份的时效性， 同时防止磁盘爆掉： 通过 snapshot + 备份wal log ， 来用snapshot进行恢复， wallog进行回放。

4.apiserver介绍

Kube-APIServer 是 Kubernetes 最重要的核心组件之一，主要提供以下功能：

• 提供集群管理的 REST API 接口，包括:
• 认证 Authentication；
• 鉴权 Authorization；
• 准入 Admission（Mutating & Valiating）；
  • mutating： 可以修改对象的值
  • Validating： 不可以对对象的值进行修改
• 提供其他模块之间的数据交互和通信的枢纽（其他模块通过 APIServer 查询或 修改数据，只有 APIServer 才直接操作 etcd）。
• APIServer 提供 etcd 数据缓存以减少集群对 etcd 的访问。

5.apiserver认证

开启TLS时，所有的请求都需要首先认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。

如果认证成功，则用户的username会传入授权模块做进一步授权验证；而对于认证失败的请求则返回HTTP 401。

认证插件

• X509证书
• 静态Token文件
• 引导Token
• 静态密码文件
• ServiceAccount
• OpenID
• Webhook 令牌身份认证
• 匿名请求

6.apiserver鉴权介绍

授权主要是用于对集群资源的访问控制，通过检查请求包含的相关属性值，与相对应的访问策略相比较，API请求必须满足某些策略才能被处理。跟认证类似，Kubernetes也支持多种授权机制，并支持同时开启多个授权插件（只要有一个验证通过即可）。如果授权成功，则用户的请求会发送到准入控制模块做进一步的请求验证；对于授权失败的请求则返回HTTP 403。

Kubernetes授权仅处理以下的请求属性：

• user, group, extra
• API、请求方法（如get、post、update、patch和delete）和请求路径（如/api）
• 请求资源和子资源
• Namespace
• API Group

目前，Kubernetes支持以下授权插件：

• ABAC： 基于配置的权限控制
• RBAC： 基于角色的权限控制
• Webhook： 基于webhook服务的外部权限控制
• Node：控制不同Node节点的权限范围

7.Kubenetes RBAC vs ABAC

ABAC（Attribute Based Access Control）本来是不错的概念，但是在Kubernetes 中的实现比较难于管理和理解，而且需要对Master 所在节点的SSH 和文件系统权限，要使得对授权的变更成功生效，还需要重新启动API Server。

而RBAC 的授权策略可以利用kubectl 或者Kubernetes API 直接进行配置。RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在Kubernetes中被映射为API 资源和操作。

8.Kubernetes 的准入机制

准入控制（Admission Control）在授权后对请求做进一步的验证或添加默认参数。不同于授权和认证只关心请求的用户和操作，准入控制还处理请求的内容，并且仅对创建、更新、删除或连接（如代理）等有效，而对读操作无效。

准入控制支持同时开启多个插件，它们依次调用，只有全部插件都通过的请求才可以放过进入系统，并且可以为对象增加的自定义属性，或者创建新的关联对象登操作。

常用组件（控制代码）如下：

• AlwaysAdmit：允许所有请求
• AlwaysDeny：禁止所有请求，多用于测试环境。
• ServiceAccount：它将 serviceAccounts 实现了自动化，它会辅助serviceAccount 做一些事情，比如如果pod 没有 serviceAccount 属性，它会自动添加一个 default，并确保 pod 的 serviceAccount 始终存在。
• LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在 namespace 中LimitRange 对象中。
• NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的namespace，则这个请求被拒绝。

自定义mutating插件举例：为资源增加自定义属性

• 作为多租户集群方案中的一环，我们需要在namespace的准入控制中，获取用户信息，并将用户信息更新到namespace的annotation
• 只有当namespace中有有效用户信息时，我们才可以在namespace创建时，自动绑定用户权限，namespace才可用。

9.Kubernetes 如何保证集群的安全性

Kubernetes 通过一系列机制来实现集群的安全控制，主要有如下不同的维度：

• 基础设施方面：保证容器与其所在宿主机的隔离；
• 权限方面：
  • 最小权限原则：合理限制所有组件的权限，确保组件只执行它被授权的行为， 通过限制单个组件的能力来限制它的权限范围。
  • 用户权限：划分普通用户和管理员的角色。
• 集群方面：
  • API Server 的认证授权：Kubernetes 集群中所有资源的访问和变更都是通过Kubernetes API Server 来实现的，因此需要建议采用更安全的 HTTPS 或Token 来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节。
  • API Server 的授权管理：通过授权策略来决定一个 API 调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的 RBAC 方式来提升集群安全授权。
  • 敏感数据引入 Secret 机制：对于集群敏感数据建议使用 Secret 方式进行保护。
  • AdmissionControl（准入机制）：对 kubernetes api 的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。

10.K8s各模块如何与 API Server 通信

Kubernetes API Server 作为集群的核心，负责集群各功能模块之间的通信。

集群内的各个功能模块通过 API Server 将信息存入 etcd，当需要获取和操作这些数据时，则通过 API Server 提供的 REST 接口（用 GET、LIST 或 WATCH 方法）来实现，从而实现各模块之间的信息交互。

• 如 kubelet 进程与 API Server 的交互：每个 Node 上的 kubelet 每隔一个时间周期， 就会调用一次 API Server 的REST 接口报告自身状态，API Server 在接收到这些信息后，会将节点状态信息更新到 etcd 中。
• 如 kube-controller-manager 进 程 与 API Server 的 交 互 ：kube-controller- manager 中的 Node Controller 模块通过 API Server 提供的 Watch 接口实时监控Node 的信息，并做相应处理。
• 如 kube-scheduler 进程与 API Server 的交互：Scheduler 通过 API Server 的Watch 接口监听到新建 Pod 副本的信息后，会检索所有符合该 Pod 要求的 Node 列表，开始执行 Pod 调度逻辑，在调度成功后将 Pod 绑定到目标节点上。

11.Controller Manager

• Controller Manager 是集群的大脑，是确保整个集群动起来的关键；
• 作用是确保 Kubernetes 遵循声明式系统规范，确保系统的真实状态（Actual State）与用户定义的期望状态（Desired State）一致；
• Controller Manager 是多个控制器的组合，每个 Controller 事实上都是一个 control loop，负责侦听其管控的对象，当对象发生变更时完成配置；
• Controller 配置失败通常会触发自动重试，整个集群会在控制器不断重试的机制下确保最终一致性（ Eventual Consistency）。

12.Controller 的工作流程及原理

核心还是生产者消费者模型， 通过Informer 和Lister 进行 监听和全量的消息获取

获取到消息(task) 后， 基于不同的EventHandler， 将时间放到不同的生产队列里面， 然后通过多个worker并发的进行事件消费完成最终的配置；

Informer 的内部机制

Informer提供了controller进行事件消费的框架 or 模型

• Reflector： 解析数据为内存struct对象
• Delta Fifo Queue： 环形内存对象
• Indexer: informer 为对象创建的索引， 用来提供键值读取
• Tread Safe Store: 线程安全的存储结构，数据 与apiserver保持一致性
• Informer：接收事件，并分配事件到对应EventHandler

13.Kubernetes Scheduler作用及原理

特殊的 Controller，工作原理与其他控制器无差别。

Scheduler 的特殊职责在于监控当前集群所有未调度的 Pod，并且获取当前集群所有节点的健康状况和资源使用情况，为待调度 Pod 选择最佳计算节点，完成调度。

调度阶段分为：

• Predict：过滤不能满足业务需求的节点，如资源不足、端口冲突等。
• Priority：按既定要素将满足调度需求的节点评分，选择最佳节点。
• Bind：将计算节点与 Pod 绑定，完成调度。

调度需要充分考虑诸多因素：

• 公平调度
• 资源高效利用
• Qos
• affiniy 、 anti-affinity
• 数据本地化
• 内部负载干扰
• deadlines

Predicates

在 Kubernetes 中，为 Pod 筛选可用节点的方法通常包括以下几种：

1. 静态匹配：根据 Pod 的 nodeSelector 字段，为 Pod 指定一个或多个目标节点。这种方式适用于有特定节点要求的 Pod，如需要运行在特定的节点或特定类型的节点上。
2. 亲和性规则：根据 Pod 的 affinity/anti-affinity 字段，为 Pod 指定一个或多个节点亲和或互斥的标签，然后在节点标签中匹配这些标签。这种方式适用于需要控制 Pod 和节点之间关系的场景，如需要将相关的 Pod 调度到同一个节点上。
3. 资源匹配：根据节点的资源使用情况，筛选出空闲的节点，然后将 Pod 调度到其中。这种方式适用于资源敏感的 Pod，如需要大量 CPU 和内存资源的 Pod。
4. 路由匹配：根据节点的位置和拓扑结构，筛选出网络拓扑上最近的节点。这种方式适用于需要快速访问其他节点的 Pod。

在 kube-scheduler 中，这些方法会组合起来，对每个 Pod 进行筛选和评分，然后选择得分最高的节点作为调度目标。同时，Kubernetes 还支持用户自定义调度策略，可以通过修改 kube-scheduler 的配置文件，定义自己的调度器算法。

Priorities

在 Kubernetes 中，为了将 Pod 调度到最优的节点上，调度器会根据一定的规则对每个节点进行评分，最终选择得分最高的节点。评分规则的定义在 kube-scheduler 的配置文件中，可以通过修改该文件来定义自己的评分规则。

一般而言，Kubernetes 的评分规则会包括以下几个方面：

1. 节点资源的可用性：调度器会根据节点的 CPU、内存、存储等资源使用情况，评估节点资源的可用性。这个评估过程一般包括计算出节点的资源使用率，以及与 Pod 的资源需求进行比较。
2. Pod 亲和性规则的匹配情况：如果 Pod 定义了亲和性规则，调度器会根据这些规则，评估节点与 Pod 之间的亲和性匹配程度。例如，如果 Pod 需要调度到和另一个 Pod 在同一个节点上，调度器会评估节点上是否已经有符合条件的 Pod。
3. 节点和 Pod 之间的拓扑关系：如果 Pod 和节点之间存在网络拓扑关系，调度器会考虑这些关系，评估节点和 Pod 之间的网络距离。例如，如果 Pod 需要快速访问某个服务，调度器会评估距离最近的节点是否可以满足这个需求。
4. 其他因素：除了以上几个方面，调度器还可以考虑其他因素，如节点的稳定性、负载均衡等。例如，如果节点已经运行了过多的 Pod，调度器可能会选择其他节点，以保证集群的负载均衡。

14.Scheduler 绑定Pod到 worker 流程

Kubernetes Scheduler 根据如下两种调度算法将 Pod 绑定到最合适的工作节点：

• 预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube- scheduler 根据预选策略过滤掉不满足策略的 Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node 的label 必须与 Pod 的Selector 一致”。
• 优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的 Nodes 进行打分排名，选择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具有越高的排名。

15.Controller的协同工作原理

以Deployment的创建为例

• Api Server进行认证鉴权准入后， 将Deployment对象放入etcd
• Deployment Controller 会监听到Deployment对象， 创建ReplicaSet 副本集，并发送给apiserver
• ReplicaSet Controller 监听到ReplicaSet对象， 创建Pod对象，并发送给apiserver
• Scheduler 监听到未被调度的Pod对象， 根据当前集群的所有节点， 调度器会按某种算法，选择适合部署的节点，将Pod对象和Node绑定，并重新发送给apiserver
• Kubelet会关注当前ApiServer和本Node相关的Pod有哪些，并通过docker进行create pod，后续还需要挂载网络和磁盘。

Kubernetes 常用对象

1.简述 Kubernetes RC 的机制

Replication Controller 用来管理Pod 的副本，保证集群中存在指定数量的Pod副本。当定义了RC 并提交至Kubernetes集群中之后， Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存货的目标Pod，确保Pod实例数量刚好等于此RC的期望值，若存在过多的Pod副本在运行， 系统会停止一些Pod，反之则自动创建一些Pod

2.ReplicationController和ReplicaSet区别

K8s新版本中， Replica Set 取代了 Replication Controller， 他们的功能类似， 都是确保在任何给定时间运行指定数量的Pod副本。不同之处在与RC使用基于集合的选择器， 而Replication Controller 使用基于权限的选择器。

3.Statefulset 与 Deployment 的差异

• 身份标识
  • StatefulSet Controller 为每个 Pod 编号，序号从0开始。
• 数据存储
  • StatefulSet 允许用户定义 volumeClaimTemplates，Pod 被创建的同时，Kubernetes 会以volumeClaimTemplates 中定义的模板创建存储卷，并挂载给 Pod。
• StatefulSet 的升级策略不同
  • 滚动升级
  • onDelete
  • 分片升级

4.Kubernetes deployment 升级过程

• 初始创建 Deployment 时，系统创建了一个 ReplicaSet，并按用户的需求创建了对应数量的 Pod 副本。
• 当更新 Deployment 时，系统创建了一个新的 ReplicaSet，并将其副本数量扩展到 1，然后将旧 ReplicaSet 缩减为1。
• 之后，系统继续按照相同的更新策略对新旧两个 ReplicaSet 进行逐个调整。
• 最后，新的 ReplicaSet 运行了对应个新版本 Pod 副本，旧的 ReplicaSet 副本数量则缩减为 0。

5.Kubernetes deployment 升级策略

在 Deployment 的定义中，可以通过 spec.strategy 指定 Pod 更新的策略，目前支持两种策略：Recreate（重建）和 RollingUpdate（滚动更新），默认值为RollingUpdate。

• Recreate：设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 时，会先杀掉所有正在运行的Pod，然后创建新的 Pod。
• RollingUpdate：设置 spec.strategy.type=RollingUpdate，表示 Deployment 会以滚动更新的方式来逐个更新 Pod。同时，可以通过设置spec.strategy.rollingUpdate 下的两个参数（maxUnavailable 和maxSurge） 来控制滚动更新的过程。
  • MaxUnavailable：滚动过程中最多有多少个 Pod 不可用；
  • MaxSurge：滚动过程中最多存在多少个 Pod 超过预期 replicas 数量

6.Kubernetes 自动扩容机制？

Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器实现基于 CPU 使用率进行自动 Pod 扩缩容的功能。HPA 控制器周期性地监测目标 Pod 的资源性能指标，并与 HPA 资源对象中的扩缩容条件进行对比，在满足条件时对 Pod 副本数量进行调整。

• HPA 原理

  Kubernetes 中的某个 Metrics Server（Heapster 或自定义 Metrics Server）持续采集所有 Pod 副本的指标数据。HPA 控制器通过 Metrics Server 的 API（Heapster 的API 或聚合 API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标Pod 副本数量。

  当目标 Pod 副本数量与当前副本数量不同时，HPA 控制器就向 Pod 的副本控制器（Deployment、RC 或 ReplicaSet）发起 scale 操作，调整 Pod 的副本数量，完成扩缩容操作。

Pod生命周期和资源管理

1. Pod 可能位于的状态？

• Pending：API Server 已经创建该 Pod，且 Pod 内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。
• Running：Pod 内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态
• Succeeded：Pod 内所有容器均成功执行退出，且不会重启。
• Failed：Pod 内所有容器均已退出，但至少有一个容器退出为失败状态。
• Unknown：由于某种原因无法获取该 Pod 状态，可能由于网络通信不畅导致。

1. 2.Pod 的常见调度方式？

Kubernetes 中，Pod 通常是容器的载体，主要有如下常见调度方式：

• Deployment 或 RC：该调度策略主要功能就是自动部署一个容器应用的多份副本， 以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。
• NodeSelector：定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以通过 Node 的标签（Label）和 Pod 的nodeSelector 属性相匹配。
• NodeAffinity 亲和性调度：亲和性调度机制极大的扩展了 Pod 的调度能力，目前有两种节点亲和力表达：
  • requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）。
  • preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的 Node 的节点，但不强求，多个优先级规则还可以设置权重值。
• Taints 和 Tolerations（污点和容忍）；
  • Taint：使 Node 拒绝特定 Pod 运行；
  • Toleration：为 Pod 的属性，表示 Pod 能容忍（运行）标注了 Taint 的 Node。

通过NodeAffinity选择节点

相较于使用nodeSlector, 更具有普遍性和扩展性

Taints 和 Tolerations

用来标记Node， 保证Pod不被调度到打了标的node上

3.创建一个Pod的主要流程？

Kubernetes 中创建一个 Pod 涉及多个组件之间联动，主要流程如下：

1. 客户端提交 Pod 的配置信息（可以是 yaml 文件定义的信息）到 kube- apiserver。
2. Apiserver 收到指令后，通过对应的kubeconfig进行认证，认证后将yaml中的配置信息存储到etcd。
3. Controller-Manager 通过apiserver的watch 接口发先了Pod的信息的更新，执行该资源锁依赖的拓扑结构整合，整合后将对应的信息交给apiserver，apiserver写到etcd，此时Pod已经可以被调度了。
4. Kube-scheduler 检测到 pod 信息会开始调度预选，会先过滤掉不符合 Pod资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行 pod 的节点，绑定信息后交给apiserver， apiserver写到etcd，然后将Pod交给kubelet。
5. kubelet收到pod后， 调用CNI接口创建Pod网络，调用CRI接口去启动容器，调用CSI进行存储卷的挂载。
6. 网络、容器、存储创建完成后Pod创建完成，等业务进程启动后，Pod运行成功；

4.Kubernetes中Pod的重启策略？

答：Pod 重启策略（RestartPolicy）应用于 Pod 所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet 将根据 RestartPolicy 的设置来进行相应操作。

Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。

• Always：当容器失效时，由 kubelet 自动重启该容器；
• OnFailure：当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器；
• Never：不论容器运行状态如何，kubelet 都不会重启该容器。

5.Pod 的健康检查方式？

对 Pod 的健康检查可以通过两类探针来检查：LivenessProbe 和ReadinessProbe。

• LivenessProbe 探针：用于判断容器是否存活（running 状态），如果LivenessProbe 探针探测到容器不健康，则 kubelet 将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含 LivenessProbe 探针，kubelet 认为该容器的 LivenessProbe 探针返回值用于是“Success”。
• ReadineeProbe 探针：用于判断容器是否启动完成（ready 状态）。如果ReadinessProbe 探针探测到失败，则 Pod 的状态将被修改。Endpoint Controller 将从 Service 的Endpoint 中删除包含该容器所在 Pod 的Eedpoint。
• startupProbe 探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针 kill 掉。

6.Pod 的LivenessProbe 探针种类？

kubelet 定期执行LivenessProbe 探针来诊断容器的健康状态，通常有以下三种方式：

• ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器健康。
• TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，若能建立 TCP 连接，则表明容器健康。
• HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，若响应的状态码大于等于 200 且小于 400，则表明容器健康。

7.pod 中 readness 和liveness 的区别

readness：用于探测容器是否已经准备好接受流量，如果readness探测失败，那么kubelet会把Pod的IP从service的endpoint中删除，这样流量就不会转发到该Pod上。当readness探测成功后，kubelet会把Pod的IP加入到service的endpoint中，这样流量就可以转发到该Pod上。
liveless：用于探测容器是否还在运行，如果liveness探测失败，那么kubelet会杀死容器，并根据容器的重启策略进行重启。

8.Pod 如何实现对节点的资源控制？

Kubernetes 集群里的节点提供的资源主要是计算资源，计算资源是可计量的能被申请、分配和使用的基础资源。当前 Kubernetes 集群中的计算资源主要包括 CPU、GPU 及Memory。

CPU 与Memory 是被 Pod 使用的，因此在配置 Pod 时可以通过参数 CPU Request 及Memory Request 为其中的每个容器指定所需使用的 CPU 与Memory 量，Kubernetes 会根据 Request 的值去查找有足够资源的 Node 来调度此Pod。

通常，一个程序所使用的 CPU 与 Memory 是一个动态的量，确切地说，是一个范围，跟它的负载密切相关：负载增加时，CPU 和Memory 的使用量也会增加。

Pod如何进行资源限制

Kubernetes 通过 Cgroups 提供容器资源管理的功能，可以限制每个容器的 CPU 和内存使用，比如对于刚才创建的 deployment，可以通过下面的命令限制 nginx 容器最多只用 50% 的 CPU 和 128MB 的内存：

$ kubectl set resources deployment nginx-app -c=nginx --limits=cpu=500m, memory=128Mi  

# deployment "nginx" resource requirements updated

等同于在每个 Pod 中设置 resources limits

9.Pod Requests\Limits 对Pod调度影响

作用

requests 和 limits 的区别在于：

• requests 表示容器所需的资源数量，确保 Pod 能够启动和运行。
• limits 表示容器能够使用的最大资源数量，确保容器的资源使用量不会超过指定的限制。

当一个 Pod 创建成功时，Kubernetes 调度器（Scheduler）会为该 Pod 选择一个节点来执行。

对于每种计算资源（CPU 和Memory）而言，每个节点都有一个能用于运行 Pod 的最大容量值。

调度器在调度时，首先要确保调度后该节点上所有 Pod 的 CPU 和内存的 Requests 总和，不超过该节点能提供给 Pod 使用的 CPU 和Memory 的最大容量值。

10.QoS 模型

当 Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和limits 值相等的时候，这个 Pod 就属于Guaranteed 类别。当 Pod 仅设置了 limits 没有设置 requests 的时候，Kubernetes 会自动为它设置与 limits 相同的 requests 值，所以，这也属于 Guaranteed情况。

而当 Pod 不满足 Guaranteed 的条件，但至少有一个 Container 设置了 requests。那么这个 Pod 就会被划分到 Burstable 类别。

而如果一个 Pod 既没有设置 requests，也没有设置 limits，那么它的 QoS 类别就是BestEffort。

QoS 划分的主要应用场景，是当宿主机资源紧张的时候，kubelet 对 Pod 进行Eviction（即资源回收）时需要用到的。当 Kubernetes 所管理的宿主机上不可压缩资源短缺时，就有可能触发Eviction。

Eviction 发生的时候，kubelet 具体会挑选哪些 Pod 进行删除操作，就需要参考这些Pod 的 QoS 类别了。

删除顺序 BestEffort -> Burstable -> Guaranteed

11.kubernets cpuset

我们知道，在使用容器的时候，你可以通过设置 cpuset 把容器绑定到某个 CPU 的核上，而不是像 cpushare 那样共享 CPU 的计算能力。这种情况下，由于操作系统在 CPU 之间进行上下文切换的次数大大减少，容器里应用的性 能会得到大幅提升。

在 Kubernetes 里又该如何实现呢？

首先，你的 Pod 必须是 Guaranteed 的 QoS 类型；

然后，你只需要将 Pod 的 CPU 资源的 requests 和 limits 设置为同一个相等的整数值即可。

spec:
 containers:
 - name: nginx
 image: nginx
 resources:
 limits:
 memory: "200Mi"
 cpu: "2"
 requests:
 memory: "200Mi"
 cpu: "2"

这时候，该 Pod 就会被绑定在 2 个独占的 CPU 核上。当然，具体是哪两个 CPU 核，是由 kubelet 为你分配的。

12.节点宕机后Pod的驱逐过程

当node节点由于某些原因（网络、宕机）会被认定被（UNKNOW、FALSE状态），当时间超过了pod-eviction-timeout时，那么节点上的Pod都会被node-controller删除。

13.pod 启动失败以及排查

• 一般查看系统资源是否满足，然后就是查看pod日志看看原因
• describe pod 通过这个参数查看pod的失败原因
• 还有可以看组件日志，apiserver组件等日志， 有没有异常
• 访问不到看看网络插件和日志， 还有就是dns状态和日志

14.init 容器的介绍和作用

Kubernetes中的init容器（Init Container）是在Pod中首先运行的一种特殊容器。Init容器的作用是在正常容器（Application Container）启动之前执行一些初始化任务，例如初始化数据库、创建配置文件、下载数据等。Init容器只有在成功完成后才会运行正常容器，如果Init容器失败，正常容器将不会启动。

Init容器和正常容器共享Pod的网络命名空间和卷存储，但是它们有独立的进程空间。在Pod中可以定义多个Init容器，每个Init容器都将按照定义顺序依次执行。这种机制为应用程序提供了更高的可靠性和灵活性。

15.PodSecurityPolicy实现哪些安全策略

在 PodSecurityPolicy 对象中可以设置不同字段来控制 Pod 运行时的各种安全策略， 常见的有：

• 特权模式：privileged 是否允许 Pod 以特权模式运行。
• 宿主机资源：控制 Pod 对宿主机资源的控制，如 hostPID：是否允许 Pod 共享宿主机的进程空间。
• 用户和组：设置运行容器的用户 ID（范围）或组（范围）。
• 提升权限：AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限， 通常在设置非 root 用户（MustRunAsNonRoot）时进行设置。
• SELinux：进行 SELinux 的相关配置。

kubernetes流量控制

1.Headless Service的作用？

在某些应用场景中，若需要人为指定负载均衡器，不使用 Service 提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。Kubernetes 提供了Headless Service 来实现这种功能，即不为 Service 设置 ClusterIP（入口 IP 地址），仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。

对于 Headless Service，Kube-proxy 创建的是一组 DNS 记录，用于解析到每个 Pod 的 IP 地址。这样，客户端就可以通过 DNS 解析来得到 Pod 的 IP 地址，并与它直接建立连接，完全绕过了 Kube-proxy 组件。

2.Kubernetes Service 及类型？

通过创建 Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址， 并且将请求负载分发到后端的各个容器应用上。其主要类型有：

• ClusterIP：虚拟的服务 IP 地址，该地址用于 Kubernetes 集群内部的 Pod 访问， 在 Node 上 kube-proxy 通过设置的 iptables 规则进行转发；
• NodePort：使用宿主机的端口，使能够访问各 Node 的外部客户端通过 Node 的 IP 地址和端口号就能访问服务；
• LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer 字段指定外部负载均衡器的 IP 地址，通常用于公有云。
• ExternalName Service(不定义Selector 的Service)： 可以用来连接外部访问， 类似于创建了一个访问集群外部服务的一个负载均衡
• Headless Service：不使用 Service 提供的默认负载均衡的功能，仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。

3.Service 分发后端的策略？

Service 负载分发的策略有：RoundRobin 和 SessionAffinity

• RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个 Pod 上。
• SessionAffinity：基于客户端 IP 地址进行会话保持的模式，即第 1 次将某个客户端发起的请求转发到后端的某个 Pod 上，之后从相同的客户端发起的请求都将被转发到后端相同的 Pod 上。

4.外部如何访问K8s集群内的服务？

• 映射 Pod 到物理机：将 Pod 端口号映射到宿主机，即在 Pod 中采用hostPort 方式，以使客户端应用能够通过物理机访问容器应用。
• 映射 Service 到物理机：将 Service 端口号映射到宿主机，即在 Service 中采用nodePort 方式，以使客户端应用能够通过物理机访问容器应用。
• 映射 Sercie 到LoadBalancer：通过设置 LoadBalancer 映射到云服务商提供的LoadBalancer 地址。这种用法仅用于在公有云服务提供商的云平台上设置Service 的场景。

5.kube-proxy 的作用

• 监控集群中用户发布的服务Service，并完成负载均衡配置。
• 每个节点的 Kube-Proxy 都会配置相同的负载均衡策略，使得整个集群的服务发现建立在分布式负载均衡器之上，服务调用无需经过额外的网络跳转（Network Hop）。
• 负载均衡配置基于不同插件实现：
  • userspace。
  • 操作系统网络协议栈不同的 Hooks 点和插件：
    • iptables；
    • ipvs。

6.kube-proxy 的三种工作模式

• userspace模式

  该模式下kube-proxy 会为没一格Service 创建一个监听端口。发向Cluster IP 的请求被IPtables规则重定向到kube-proxy监听的端口上，kube-proxy 根据LB算法选择一个提供服务的Pod并和其建立连接。将请求转发到Pod上， 该模式充当一个四层LB的角色。

• iptables模式

  kube-proxy为service后端的每个pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到Pod IP。

• ipvs模式

  和iptables类似，监听Pod的变化并创建ipvs rules。ipvs 也是在kernel模式通过netfilter实现的，但是采用了hashtable来存储规则，因此在规则比较多的情况下，ipvs相对iptables转发效率更高。除此之外，ipvs支持更多的LB算法。如果要设计kube-proxy为ipvs模式，必须在操作系统中安装IPVS内核模块。

7.kube-proxy ipvs原理

IPVS 在kubernetes 1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构(HASH表)， 允许几乎无线的规模扩张， 因此被kube-proxy采纳为最新模式。

在IPVS模式下， 使用iptables的扩展ipset， 而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构， 因此当规则很多时， 也可以很高效的查找和匹配。

可以将ipset 理解为一个IP段的集合， 这个集合的内容可以是IP地址、IP网段、端口等。iptables 可以直接添加规则对这个“可变的结合”进行操作，这样做的好处在与可以大大减少iptables的规则数量，从而减少性能损耗

8.kube-proxy ipvs 和iptables 的异同

iptables与IPVS都是基于Netfilter实现的， 但因为定位不同， 二者有着本质的差别：iptables 是为防火墙而设计的, 原理是修改iptable 的dnat规则实现； IPVS 则是专门用于高性能负载均衡， 不使用dnat规则改用更高效的数据结构（HASH表），允许几乎无限的规模扩张。

与iptables相比，IPVS 拥有以下明显优势：

1. 为大型集群提供了更好的可扩展性和性能；
2. 支持比iptables更复杂的负载均衡算法
3. 支持服务器健康检查和连接重试等功能；
4. 可以动态修改ipset的结合， 即使iptables的规则正在使用这个集合；

9.core dns组件介绍

coreDNS包含一个内存态DNS，以及与Italyconroller类似的控制器

CoreDNS的实现原理是， 控制器监听Service和Endpoint的变化并配置DNS，客户端Pod再进行域名解析时，从CoreDNS 中查询服务对应的地址记录

10.Kubernetes ingress介绍？

Kubernetes 的Ingress 资源对象，用于将不同 URL 的访问请求转发到后端不同的 Service，以实现 HTTP 层的业务路由机制（L7负载均衡）。

Kubernetes 使用了 Ingress 策略和 Ingress Controller，两者结合并实现了一个完整的Ingress 负载均衡器。使用Ingress 进行负载分发时，Ingress Controller 基于Ingress 规则将客户端请求直接转发到 Service 对应的后端Endpoint（Pod）上，从而跳过 kube-proxy 的转发功能，kube-proxy 不再起作用，全过程为：ingress controller + ingress 规则> services。

同时当 Ingress Controller 提供的是对外服务，则实际上实现的是边缘路由器的功能。

11.Service Mesh 介绍

服务网格(Service Mesh) 这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。

随着规模和复杂性的增长，服务网格越来越难以理解和管理。 它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

可以理解为服务调用链路上的所有能力， 加起来组成的网格状的结构

使用Servcie Mesh 可以做到如下功能：

• Http、Grpc 和TCP流量的自动负载均衡。
• 通过丰富的路由规则、重试、故障转移和故障注入，可以对流量进行细粒度的控制。
• 可插入的策略层和配置API，支持访问控制、速率限制和配额。
• 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。
• 通过强大的基于身份验证和授权，在集群中实现安全的服务间通信。

12.istio 架构

• 数据平面： SideCar 方式部署的 Proxy， 负责网络通信（上面介绍的服务网格， 其实是通过数据面实现的）；
• 控制平面： 负责管理和配置代理来进行路由流量，就是负责控制数据面的部署和配置；

watch api service， 监控state信息： Service 、 Pod、 Endpoint 等信息， 将Istio 配置和 State 信息结合后下发给Envoy， 作为各Pod的Proxy。

13.istio 原理

• istiod: 负责监听集群所有service 、pod、 endpoint 、secret、以及istio自身对象的变化，并负责将集群的信息push给envoy mesh实例
• istio-ingressgateway：进入网络的所有流量都会通过ingress-envoy进行传输
• istio-egressgateway ：离开网络的所有流量都会通过egress-envoy进行传输

• 先为pod注入sidecar， 注入Istio side car 的结果是会有 istio-init 和 istio-proxy 两个pod
• 通过istio-init， 修改iptable， 将应用容器的所有流量都转发哦到Envoy的容器中
• 通过istio-proxy， 实际为envoy容器， 用来进行虚拟路由， 将流量转发给实际的endpoint。

istio配置对象

• VirtualService: 用于定义对特定目标服务的一组流量规则。描述一个具体的服务对象，包含了对流量的各种处理。可以实现对服务的请求路由、错误注入、流量切分、流量镜像、超时设置、请求重试等。
• DestinationRule： VirtualService 路由生效后， 配置应用与请求的策略集，可以设置负载均衡策略和熔断， 还可以对Service 区分不同的版本；
• ServiceEntry： 是通常用于在Istio服务网格之外启动对服务的请求
• Gateway： 为Http/Tcp 流量配置负载均衡器，最常见的是在网格边缘的操作，以启用应用程序的入口流量。

kubelet

1.Kubernetes kubelet 的作用

Kubernetes 的初始化系统（init system）

• 从不同源获取 Pod 清单，并按需求启停 Pod 的核心组件：
• Pod 清单可从本地文件目录，给定的 HTTPServer 或 Kube-APIServer 等源头获取；
• Kubelet 将运行时，网络和存储抽象成了 CRI，CNI，CSI。
• 负责汇报当前节点的资源信息和健康状态；
• 负责 Pod 的健康检查和状态汇报。

2.kubelet 如何监控Worker 节点资源

kubelet 使用 cAdvisor 对worker 节点资源进行监控。在 Kubernetes 系统中， cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会自动启动cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。

3.简述 Kubernetes CNI 模型

CNI 提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对CNI 接口进行实现。CNI 仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。在 CNI 模型中只涉及两个概念：容器和网络。

• 容器（Container）：是拥有独立 Linux 网络命名空间的环境，例如使用 Docker 或 rkt 创建的容器。容器需要拥有自己的 Linux 网络命名空间，这是加入网络的必要条件。
• 网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP 地址，可以是容器、物理机或者其他网络设备（比如路由器）等。

对容器网络的设置和操作都通过插件（Plugin）进行具体实现，CNI 插件包括两种类型：CNI Plugin 和 IPAM（IP Address Management）Plugin。CNI Plugin 负责为容器配置网络资源，IPAM Plugin 负责对容器的 IP 地址进行分配和管理。IPAM Plugin 作为 CNI Plugin 的一部分，与 CNI Plugin 协同工作。

4.Kubernetes Calico 网络组件原理

Calico 是一个基于 BGP 的纯三层的网络方案，与 OpenStack、Kubernetes、AWS、GCE 等云平台都能够良好地集成。

Calico 在每个计算节点都利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发。每个 vRouter 都通过 BGP 协议把在本节点上运行的容器的路由信息向整个Calico 网络广播，并自动设置到达其他节点的路由转发规则。

Calico 保证所有容器之间的数据流量都是通过 IP 路由的方式完成互联互通的。Calico 节点组网时可以直接利用数据中心的网络结构（L2 或者 L3），不需要额外的 NAT、隧道或者 Overlay Network，没有额外的封包解包，能够节约 CPU 运算，提高网络效率。

5.Calico 和 flannel CNI网络插件的区别

• calico 根据iptables 规则进行路由转发， 并没有进行封包，解包的过程， 这和flannel比起来效率会快很多。
• Fannel 实质上是一种 “覆盖网络”， 也就是将TCP数据包装在另一种网络包里面进行路由转发和通信， 目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。默认的节点间数据通信方式就是UDP转发。

6.Kubernetes CSI 模型

Kubernetes CSI 是Kubernetes 推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用 Kubernetes 的原生存储机制为容器提供存储服务。CSI 使得存储提供方的代码能和Kubernetes 代码彻底解耦，部署也与Kubernetes 核心组件分离，显然，存储插件的开发由提供方自行维护，就能为Kubernetes 用户提供更多的存储功能，也更加安全可靠。

7.Kubernetes 数据持久化方式有哪些

Kubernetes 通过数据持久化来持久化保存重要数据，常见的方式有：

• EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由 Pod 内保部映射到宿主机上。类似于docker 中的 manager volume。当Pod节点删除时，column的数据也会被删除。
• Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于 docker 中的bind mount 挂载方式。
• PersistentVolume（简称 PV）：如基于 NFS 服务的 PV，也可以基于 GFS 的PV。它的作用是统一数据持久化目录，方便管理。

8.简述 Kubernetes PV 和PVC？

答：PV 是对底层网络共享存储的抽象，将共享存储定义为一种“资源”。PVC 则是用户对存储资源的一个“申请”。

9.K8s所支持的存储供应模式

Kubernetes 支持两种资源的存储供应模式：静态模式（Static）和动态模式（Dynamic）。

• 静态模式：集群管理员手工创建许多 PV，在定义 PV 时需要将后端存储的特性进行设置。
• 动态模式：集群管理员无须手工创建 PV，而是通过 StorageClass 的设置对后端存储进行描述，标记为某种类型。此时要求 PVC 对存储的类型进行声明，系统将自动完成 PV 的创建及与 PVC 的绑定。