Kubernetes 各種資源型態 Resource Object

K8s 本身提供的資源型態

大致分成幾類

Workload 類型資源型態

Pod

K8s 中最小的運作單位

1. 裡面可以包含一到多個 Container 通常是一個
2. 相同 Pod 內的 Container 共享儲存空間與網路
3. Pod Spec 要說明 Container 如何運作

Controller 類型資源型態

ReplicationController

確保同一時間有指定數量的 Pod 正在運行，隨時可以規模放大/縮小

後續被 ReplicaSet + Deployment 取代(目的是支援後續 1.3 的 AutoScaling)

ReplicaSet

ReplicaSet 與 ReplicationController 相同，但多了支援更多 Local Selector

Deployment

即 Pod + ReplicaSet ，目的在維持各服務的理想運行狀態

StatefulSet

對 Stateful 的應用程式進行管理

與 Deployment 共同點

• 都是透過 container spec 來描述理想狀態

與 Deployment 差異點

• StatefulSets 會為每一個 pod 維護一個固定的識別資訊，而 Deployment 則不會
• StatefulSets pod 雖然都是從同樣的 spec 產生出來，非 Deployment 等同等關係，因此無法互相替代對方的任務
• 每個 StatefulSets Pod 都有一個永久性的識別資訊，不會因為被 reschedule 而改變
• StatefulSet 的管理是由 k8s 中名稱為 StatefulSet Controller 的元件來負責。

DaemonSet

由 Daemon Controller 管理，確保每個 K8s 節點都有指定數量的 Pod 正在運行，當 Cluster 新增節點也會為新節點新增 Pod

Job

算是 K8s Pod 的測試工具，確保 Pod 有在正確運行，在一定條件達成後 Job 與相關 Pod 會自動移除

CronJob

週期性工作

TTL Controller

限制已經執行完的 K8s Resource Object 的生命週期，避免不必要的資源浪費與占用

Service Discovery 類型資源型態

Service

處理流量到達 Pod 的資源，其中 Service 會包含

• DNS 服務
• 網路服務(自動負載平衡)
  • 每個 Service 會有 VLAN 底下的 Pod 也會被分配 IP
  • Cluster 內部可以透過 service_name.namespace.cluster.local 的 Domain 取得資源
  • 若要開放服務對外存取必須調整 Service type 成為 NodePort 或者是 LoadBalancer(僅在公有雲有效)
  • Service 的流量要導入到哪個 Pod 透過 Label 來決定
  • Kube Proxy 會自動產生對應的 iptables rules 讓流量可以自動分配到 pod

Ingress

目的在解決 K8s Service 對外部存取的問題

• 提供 Service 對外存取規則
• 負載平衡
• SSL 中止代理
• 提供名稱

權限管理類型資源型態

Service Account

K8s 中的 Pod 有沒有辦法正常運作，取決於這個 Pod 有沒有相對應的權限

1

kubectl get serviceaccount # Get Service Account Info

基礎的 pod 會包含

• default service account
• 特定的 namespace

1

kubectl describe serviceaccount/default # check default serviceaccount secret

1

kubectl describe secret/(secret name) #Check specify secret

每個 ServiceAccount Resource Object 也會有一個 Secret 物件(帶有與 API Server 驗證的 Token)

RBAC Mechanism

RBAC 是 K8s 預設啟動的驗證模組

RBAC 定義了資源本身上使用者與 Resource Object 的關係

• Role 定義在特定 namespace 下的 resource 的存取權限
• RoleBinding 設定哪些使用者(or service account)與 role 綁定而擁有存取權限
• ClusterRole 定義在整個 k8s cluster 下的 resource 的存取權限
• ClusterRoleBinding 設定哪些使用者(or service account)與 role 綁定而擁有存取權限

Storage 類型資源型態

Volume

由於 Container 常常被移轉到不同的節點上，資料持久性就會要避免消失的情況，因此 Volume 是來解決 Container 儲存問題的抽象資料型態

k8s 支援非常多儲存格式

PersistentVolume & PersistentVolumeClaim

有了 Volume 的抽象概念後就是實作儲存的內容，提出 PersistentVolume(PV) & PersistentVolumeClaim(PVC) 的概念實現永久性資料儲存

PV

可視為掛載在 Pod 上的儲存空間

PVC

概念來自於使用者的 Request，類似 Pod 差異在 Pod 使用 Worker Node 運算資源可以去限定 CPU/Memory則 PVC 是使用 PV，可限定 storage 的 size & access mode(read/write or read-only)。

Storage Class

PV/PVC 雖然解決資料持久性的問題，但是也衍伸出了問題

• 如果我常常需要產生 PV，又要刪除它呢 ?
• 可以不要一直去煩 storage manager 嗎? 每次產生新的 PV 都需要請他建立對應的 RBD image
• 產生 PV 的動作可以自動完成嗎 ?
• 每次都要手動建立 RBD image 哪有 cloud native ?

而 Storage Class 的功能就是要動態 & 自動的把上述的事情給自動化

Secret

解決 K8s 上敏感性資料的隱私問題，讓使用者不要把敏感性資料定義在 Image 或放在 Pod 的 Spec 中，而是使用 Volume 掛載的方式或是環境變數的方在 Pod 進行使用

Config Map

處理應用程式設定檔的內容管理問題

Policy 類型資源型態

Network Policy

定義 Pod 之間是否可以通訊，透過 label 進行篩選

SecurityContext

對容器設定安全政策來確保他容器不受其影響 & 保護系統。

k8s 提供三種安全政策

• Container-level Security Context：僅套用到指定的容器
• Pod-level Security Context：套用到 Pod 內所有容器以及 Volume
• Pod Security Policies（PSP）：套用到 k8s cluster 內部所有 Pod 以及 Volume

ResourceQuota

通常是在一個 Cluster 有多個使用者的時候使用或是資源有限的時候，來管理資源用量的管理

可管理資源

• Compute Resource 包含 CPU 與記憶體
• Storage 限制每個 NameSpace 可用的儲存空間
• Object Count 限制特定的 Resource Object Type 數量

LimitRange

同 ResourceQuota 一樣來限制資源量，但 LimitRange 是來設置可用的上下介範圍的預設值

Extension 類型資源型態

CustomResourceDefinitions

可供使用者自訂義的 Resource Object

參考資料

• [Kubernetes] Resource Object 概觀