kubernetes API對象

無狀態服務（Deployment和ReplicaSet）

• Deployment 假設應用是無狀態的：
  • 一個應用的所有Pod是完全一樣的，它們互相之間沒有順序，也無所謂運行在哪臺宿主機上
  • 可以“殺掉”任意一個 Pod
• Deployment狀態信息含義
  • DESIRED ：用戶期望的 Pod 副本個數
  • CURRENT：當前處於 Running 狀態的 Pod 的個數
  • UP-TO-DATE：當前處於最新版本的 Pod 的個數
  • AVAILABLE：當前已經可用的 Pod 的個數
    • 既是 Running 狀態，又是最新版本，並且已經處於 Ready狀態的 Pod 的個數
    • 是用戶所期望的最終狀態

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         0         0            0           1s

• Deployment 是一個兩層控制器，實際操控的是ReplicaSet，而不是Pod

  • Deployment 控制版本，ReplicaSet 控制副本數

• 只要滿足replica selector的pod都會受replicaset的控制

  • 並不僅僅是template中定義的，因爲replicaset並不查重
  • 應該確保一個pod僅由一個replicaset控制
    

• 滾動更新

  • 通過同時保持新舊兩個ReplicaSet來實現

• 水平擴展 / 收縮

  • 通過 ReplicaSet 的屬性（比如 replicas 的值），來控制 Pod 的數量

• 升級策略

  • maxSurge
    • 除了 DESIRED 數量之外，在升級中還可以創建新 Pod的數量或比例
  • maxUnavailable
    • 在升級時可以刪除多少舊Pod
      

• API對象命名

  • 子對象的名字 = 父對象的名字+隨機hash字符
  • replicaset名字是根據template進行hash的，以保證新舊對象hash值不同

有狀態服務（StatefulSet）

• Deployment和ReplicaSet是爲無狀態服務設計的，但真正的分佈式應用實例之間往往是有狀態

• initcontainer處理的是container之間的關係, statefulset處理的是pod之間的關係

• 不同於deployment使用replicaset管理pod, statefulset直接管理下屬的pod

  • 使用controller-revision-hash這個label來標記版本

• Statfulset只會在下屬的pod中綁定ownerReference，而不會在對應的PVC中添加

  • 擁有 OwnerReference 的資源，在管理的這個資源進行刪除的默認情況下，會刪除下屬資源
  • 因此默認情況下刪除 StatefulSet 之後，StatefulSet 創建的Pod會被刪除，但是 PVC 並不會被刪除

• 通過partition字段可以實現灰度發佈

  • 假設當前有個 replicas 爲 10 的 StatefulSet，當我們更新版本的時候，如果 Partition 是 8，並不是表示要把 8 個 Pod 更新爲新版本，而是表示需要保留 8 個 Pod 爲舊版本，只更新 2 個新版本作爲灰度
  • 這是目前 Deployment 所不支持的
    

拓撲狀態

• 例如主從或者主備關係的應用
• 應用實例必須嚴格按照某些順序啓動或重建
• 通過headless service來創建針對單個pod的DNS記錄，從而標識了唯一的“網絡身份”
  • 在 StatefulSet 的整個生命週期裏都會保持不變，絕不會因爲對應 Pod 的刪除或者重新創建而失效
  • StatefulSet在刪除pod並重建時，會分配相同給的“網絡身份”
• 對於“有狀態應用”實例的訪問，必須使用 DNS 記錄或者 hostname 的方式，而絕不應該直接訪問這些 Pod 的 IP 地址

存儲狀態

• 例如應用的多個實例分別綁定了不同的存儲數據

• Pod第一次讀取到的數據，和隔了十分鐘之後再次讀取到的數據，應該是同一份，哪怕在此期間Pod被重新創建過

• 通過volumeClaimTemplates給stateful的pod添加PVC

  • 這些PVC都會以<PVC 名字 >-<StatefulSet 名字 >-< 編號 >的方式命名
  • pod被刪除後對應的PVC和PV都不會刪除，因此pod重建後會重新綁到對應的PVC

• 實戰：k8s部署一個主從模式的 MySQL 集羣

守護進程（DaemonSet）

• DaemonSet確保全部或指定節點上運行一個且僅有一個Pod的副本
  • 可以通過nodeAffinity和Toleration匹配對應節點
• 當有節點加入集羣時，也會自動爲此節點新增一個Pod ；當有節點從集羣移除時，這些Pod也會被回收
• 刪除DaemonSet將會刪除它創建的所有Pod
• 適用於日誌，監控，網絡插件等服務
• DaemonSet 控制器操作的直接就是 Pod

離線任務（Job和CronJob）

• Deployment、StatefulSet，以及 DaemonSet都這對於在線任務，容器保持running狀態
• Job和CronJob支持離線任務，任務完成後pod便自動退出了
• Job Controller 控制的對象，直接就是 Pod
• 控制參數
  • spec.parallelism: 定義的是一個 Job 在任意時間最多可以啓動多少個 Pod 同時運行
  • spec.activeDeadlineSeconds 字段可以設置最長運行時間,超時後強制結束任務
  • restartPolicy在 Job 對象裏只允許被設置爲Never 和 OnFailure
    • 而在 Deployment 對象裏則只允許被設置爲Alway
  • spec.completions設定完成策略
    • 單Pod型任務有一個Pod成功就標誌完成
    • 定數成功型任務保證有N個任務全部成功
    • 工作隊列型任務根據應用確認的全局成功而標誌成功
• job成功結束後一直處於completed狀態，需要手動清理
• cronjob是一個job對象的控制器
  • CronJob 與 Job 的關係，正如同 Deployment 與 Pod 的關係一樣
  • 通過spec.schedule設定運行週期