Kubernetes：声明式API、RBAC与存储

控制器的开发模式 -- 声明式编程的体现

1. 声明式指的是我只需要提交一份，我期望的API对象。（之后的流程都由系统来完成）
2. 声明式中，一个API对象可以有多个读写端，在修改的时候，使用patch的方式来进行修改。
3. 想要实现K8s中对API对象的控制，和各个API对象进行交互，完成特定业务场景的逻辑，遵循这种 标准Kubernetes 编程范式是重中之重。

深入声明式API -- Kubernetes编程范式

Kubernetes API对象结构

[图片上传失败...(image-d20038-1578817292527)]

1. 在编写Pod的yaml文件时，都会在头上申明他的apiversion与kind，比如：batch/v1，job
2. Kubernetes会匹配，API对象的 组 -group，版本号 - version，资源类型 - kind。找到正确的版本后就会创建这个对象

创建的具体流程

1. Post请求到达APIServer，对请求进行过滤，完成一些授权、审计、超时处理的前置性操作
2. 进入MUX与Routes阶段，主要是完成URL与Handler（主要用于查找需要创建对象的类型定义）的绑定
3. Convert操作, 将提交的对象转换成 通用的Super version对象（该API资源的所有版本的字段全集和）。这里转换的目的是不管是哪个版本都能统一处理
4. 进行Admission与Validation操作，即完成初始化操作与验证对象中字段的合法性
5. 转换API对象到最开始用户提交的版本，进行序列化，存储到Etcd中

授权工作机制 -- RBAC（Role-Based Access Control）

基本概念

1. Role：角色，一组规则，定义了一组对 Kubernetes API 对象的操作权限。是 Namespaced 对象
   1. 本质上就是Kubernetes的API对象。
   2. 可以指定了它能产生作用的namespace。还能通过使用 ClusterRole 和 ClusterRoleBinding 这两个组合给非namespace（比如：node）API对象授权。
   3. 在yaml中的 rules 字段，可以定义权限规则。比如：GET、WATCH 和 LIST 等操作。
2. Subject：被作用者。
3. RoleBinding：定义了“被作用者”和“角色”的绑定关系。是 Namespaced 对象

存储 - PV与PVC

使用

1. 持久化存储数据卷 - Persistent Volume
2. 真正希望使用的持久化存储属性 - Persistent Volume Claim
3. 使用PVC如下，在volumes中指明：

volumes:
- name: xxx
  persistentVolumeClaim:
    clasimName: testPVC

• 使用成功的前提是PVC能绑定到一个PV，包括两个条件：
  1. PV的存储大小必须要满足PVC的要求
  2. 它们各自的storageClassName必须一样

处理持久化存储的专用控制器 - Volume Controller

1. 其维护着多个控制循环，这其中有个控制循环叫做persistentVolumeController
2. 它会不断检查每一个PVC，查看它们是不是已经处于绑定状态。如果不是就会去查找所有可用的PV尝试与其绑定。
3. 如果还找不到合适的PV，就通过StorageClass（就是创建PV的模板，一般定义如下）帮它创建一个PV，然后与PVC完成绑定（像前面说的storageClassName必须一样才能完成绑定）

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: test-storage
provisioner: xxx/xxx # 存储插件
parameters: # PV的参数
  type: xxx # 指定类型

PV、PVC、StorageClass关系

image

参考：

《深入剖析Kubernetes》 - 张磊