控制器的開發(fā)模式 -- 聲明式編程的體現(xiàn)

1. 聲明式指的是我只需要提交一份，我期望的API對象。（之后的流程都由系統(tǒng)來完成）
2. 聲明式中，一個API對象可以有多個讀寫端，在修改的時候，使用patch的方式來進行修改。
3. 想要實現(xiàn)K8s中對API對象的控制，和各個API對象進行交互，完成特定業(yè)務場景的邏輯，遵循這種 標準Kubernetes 編程范式是重中之重。

深入聲明式API -- Kubernetes編程范式

Kubernetes API對象結構

[圖片上傳失敗...(image-d20038-1578817292527)]

1. 在編寫Pod的yaml文件時，都會在頭上申明他的apiversion與kind，比如：batch/v1，job
2. Kubernetes會匹配，API對象的 組 -group，版本號 - version，資源類型 - kind。找到正確的版本后就會創(chuàng)建這個對象

創(chuàng)建的具體流程

1. Post請求到達APIServer，對請求進行過濾，完成一些授權、審計、超時處理的前置性操作
2. 進入MUX與Routes階段，主要是完成URL與Handler（主要用于查找需要創(chuàng)建對象的類型定義）的綁定
3. Convert操作, 將提交的對象轉換成 通用的Super version對象（該API資源的所有版本的字段全集和）。這里轉換的目的是不管是哪個版本都能統(tǒng)一處理
4. 進行Admission與Validation操作，即完成初始化操作與驗證對象中字段的合法性
5. 轉換API對象到最開始用戶提交的版本，進行序列化，存儲到Etcd中

授權工作機制 -- RBAC（Role-Based Access Control）

基本概念

1. Role：角色，一組規(guī)則，定義了一組對 Kubernetes API 對象的操作權限。是 Namespaced 對象
   1. 本質上就是Kubernetes的API對象。
   2. 可以指定了它能產生作用的namespace。還能通過使用 ClusterRole 和 ClusterRoleBinding 這兩個組合給非namespace（比如：node）API對象授權。
   3. 在yaml中的 rules 字段，可以定義權限規(guī)則。比如：GET、WATCH 和 LIST 等操作。
2. Subject：被作用者。
3. RoleBinding：定義了“被作用者”和“角色”的綁定關系。是 Namespaced 對象

存儲 - PV與PVC

使用

1. 持久化存儲數(shù)據(jù)卷 - 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. 其維護著多個控制循環(huán)，這其中有個控制循環(huán)叫做persistentVolumeController
2. 它會不斷檢查每一個PVC，查看它們是不是已經(jīng)處于綁定狀態(tài)。如果不是就會去查找所有可用的PV嘗試與其綁定。
3. 如果還找不到合適的PV，就通過StorageClass（就是創(chuàng)建PV的模板，一般定義如下）幫它創(chuàng)建一個PV，然后與PVC完成綁定（像前面說的storageClassName必須一樣才能完成綁定）

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: test-storage
provisioner: xxx/xxx # 存儲插件
parameters: # PV的參數(shù)
  type: xxx # 指定類型

PV、PVC、StorageClass關系

image

參考：

《深入剖析Kubernetes》 - 張磊