Pod 的生命週期是動態的，因為 cluster 會根據需求，動態地創建或銷毀 Pod ，重啟的 Pod 自然也伴隨着 IP 地址的更動。為了解決這問題，kubernetes 在 客戶端和 Pod 間，引入了一個名為 Service 的組件，它會在 pod 的前方提供了一個穩定的網路端點。不只可以建立內部 Pod 之間的通信，讓 Pod 間可以用 domain name 的方式相互溝通；另外也可以建立外部與 Pod 的溝通管道。 最後 Service 也有能力爲這些 Pod 進行負載分配，平均每個 Pod 的使用率。
Workload 是指在 Kubernetes Pod 內運行的應用程式。但是 Pod 並不能保證總是可用的，所以需要管理它們。但若直接管理 Pod 的話，工作量將會非常大且繁瑣，為了減輕負擔，Kubernetes 提供 Workload Resources 來管理一組 Pods。即 Workload Resource 是 Kubernetes 中，定義和管理 Workload 的特定 API 物件，例如 Deployment、StatefulSet 等等都是屬於 Workload Resource。
Deployment 是 Kubernetes 中，最常使用的的一種工作負載(Workloads)，它以 YAML 格式描述 Pod ，提供聲明式(declarative)的設定。除了定義 Pod 的狀態，更進一步可以管理 :
- Pod 的 replica 數量
- 升級回滾的策略
Deployment 是用來編排無狀態 pod 的一種控制器資源，官方也建議應該透過 Deployment 來佈署 Pod & Replicaset，而非直接對 Pod & Replicaset 進行管理。
當我們在編寫 Kubernetes Pod 相關的 yaml spec 時，有時會針對 spec.containers ，設置啟動時要執行的命令及其參數，而 Kubernetes 提供
command和args，兩種方式可以選擇。但這時候就會出現一些疑問 :
- 這兩個差異是甚麼 ?
- Docker Image 中如果自帶 ENTRYPOINT 和 CMD ，若 Kubernetes 再設置
command和args會發生甚麼事情呢 ?以下就來簡單說明一下。
Helm 是 kubernetes 的包管理工具。 Helm 有一個公共 Repository ，裏面主要都是配置文件，會把 Kubernetes 服務中各種元件 yaml ，統一打包成一個叫做 Chart 的模組，然後透過 value.yaml，可用來統一管理與設定 Kubernetes ，幫助 developer 和系統管理員，更輕鬆地部署、管理和升級 Kubernetes 中的應用程式。
k8s Cluster 並不直接與 Pod 做互動，而是透過一些管理元件來處理 Pod ，這些管理元件總體被稱為 Workload，這裏介紹 DaemonSet 控制器。DaemonSet 用於提供 Node 基本設施的 Pod，會確保在所有(或是特定)節點上，一定運行著指定的一個 Pod。若想只運行在特定節點運行 DaemonSet Pod，可藉由給定的標籤，讓 Pod 可以只在特定節點上運行。