Pod 是 Kubernetes 中最小的運行單位，它可以包含一個或多個 container。Pod 的實現原理主要涉及以下幾個方面：
- 容器技術 : 實現隔離和獨立運行
- 共享網絡和存儲 : Pod 中的所有容器共享相同的網絡和存儲空間
- Pod 調度 : 調度器會監測節點的資源利用率，將 Pod 調度到適合的節點上運行。
- 生命週期管理 : 當 Pod 發生故障或需要擴展時，控制器會自動創建、刪除或調整 Pod 的數量。
在 Kubernetes 中，Pod 是容器組的概念，爲應用程序提供了一個更加靈活的運行環境，負責管理容器的生命周期和資源。
Kubernetes Secret 是一種將配置設置與應用分離的抽象，解決服務間配置的冗余與維護問題。主要可以用來保存敏感訊息，將這些 data 放在 Secret 中，比放在 Pod 的定義中或者 Docker Image中，來說更加安全和靈活。
ConfigMap 是一種資源配置管理的抽象，可讓不同的微服務間共享配置，提供了一種將配置設置與應用分離的方法，讓我們可以只更新 Config 設定檔 ，而無需修改應用的 Code 或其 Image ，解決服務間配置的冗余與維護問題。基礎的 ConfigMap 用法，通常用於存儲鍵值對，來作爲容器化應用中的環境變量。
Kubernetes 若要把應用暴露於 Cluster 外部 ，已知可以使用 NodePort 和 LoadBlancer 類型的 Service，但當每暴露一個 Service 給外部時，就會需要暴露一個對應的 Port ，隨著 Service 越來越多之後，我們就需要管理更多的 Port Number，也會使得維運上更加複雜。這時就可以考慮使用 Kubernetes Ingress ，它可用來代理不同 Kubernetes Service，能對外開放統一的 Port ，並將外部的請求轉發到 Cluster 內不同的 Service 上，來實現負載均衡。 Ingress 專注於 Cluster 對外的暴露、負載均衡、L7轉發、 Virtual Hosting 等功能。
kubernetes 可以創建多個 Pods，Pod 內有一個或多個 Container，那麼 Container 之間是怎麼溝通的的呢 ? 這裡歸類出一些 case :
- 不同網路下，不同 pod 間的 container 的通訊
- 同一網路下，不同 pod 間的 container 的通訊
- 同一個 pod 中，不同的 container 的通訊
以下來對這些 case 進行說明。
Kubernetes 是可以支援
ClusterIP:Port、PodIP:Port的形式，來完成相互溝通的，但是這樣會帶來些問題，因為 Kubernetes 內部 Pod 和 Service 都有機會重啟的，這會導致 Pod 和 Service 的 IP 發生變化；但 Service 名字等一些標識資訊是不會經常變動的，所以 Kubernetes 更推薦通過 Service 的名字來訪問服務，這就是服務發現。Service Discovery 是一種機制，通過該機制，服務可以動態發現彼此，而無需 hardcode 硬寫 IP 或 endpoint 配置。可以讓我們只透過 Service 的名稱，就能找到相對應 Pod ，而非使用 IP 地址訪問。
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會發生甚麼事情呢 ?以下就來簡單說明一下。