控制器的开发模式 -- 声明式编程的体现
-
声明式指的是我只需要提交一份，我期望的API对象。（之后的流程都由系统来完成） -
声明式中，一个API对象可以有多个读写端，在修改的时候，使用patch的方式来进行修改。 - 想要实现K8s中对API对象的控制，和各个API对象进行交互，完成特定业务场景的逻辑，遵循这种
标准Kubernetes 编程范式是重中之重。
深入声明式API -- Kubernetes编程范式
Kubernetes API对象结构
[图片上传失败...(image-d20038-1578817292527)]
- 在编写Pod的yaml文件时，都会在头上申明他的
apiversion与kind，比如：batch/v1，job - Kubernetes会匹配，API对象的 组 -
group，版本号 -version，资源类型 -kind。找到正确的版本后就会创建这个对象
创建的具体流程
- Post请求到达APIServer，对请求进行过滤，完成一些授权、审计、超时处理的前置性操作
- 进入
MUX与Routes阶段，主要是完成URL与Handler（主要用于查找需要创建对象的类型定义）的绑定 -
Convert操作, 将提交的对象转换成 通用的Super version对象（该API资源的所有版本的字段全集和）。这里转换的目的是不管是哪个版本都能统一处理 - 进行Admission与Validation操作，即完成初始化操作与验证对象中字段的合法性
- 转换API对象到最开始用户提交的版本，进行序列化，存储到Etcd中
授权工作机制 -- RBAC（Role-Based Access Control）
基本概念
- Role：角色，一组规则，定义了一组对 Kubernetes API 对象的操作权限。是 Namespaced 对象
- 本质上就是Kubernetes的API对象。
- 可以指定了它能产生作用的namespace。还能通过使用 ClusterRole 和 ClusterRoleBinding 这两个组合给非namespace（比如：node）API对象授权。
- 在yaml中的 rules 字段，可以定义权限规则。比如：GET、WATCH 和 LIST 等操作。
- Subject：被作用者。
- RoleBinding：定义了“被作用者”和“角色”的绑定关系。是 Namespaced 对象
存储 - PV与PVC
使用
- 持久化存储数据卷 - Persistent Volume
- 真正希望使用的持久化存储属性 - Persistent Volume Claim
- 使用PVC如下，在volumes中指明：
volumes:
- name: xxx
persistentVolumeClaim:
clasimName: testPVC
- 使用成功的前提是PVC能绑定到一个PV，包括两个条件：
- PV的存储大小必须要满足PVC的要求
- 它们各自的storageClassName必须一样
处理持久化存储的专用控制器 - Volume Controller
- 其维护着多个控制循环，这其中有个控制循环叫做persistentVolumeController
- 它会不断检查每一个PVC，查看它们是不是已经处于绑定状态。如果不是就会去查找所有可用的PV尝试与其绑定。
- 如果还找不到合适的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
