Kubernetes (k8s) [1]是一個用於管理容器 Container 的開源軟體，一般被稱為 Container Orchestration Platform。K8s 的前身是由 Google 內部開發的 Borg 項目，並於2014年公開發布。在那之後由 CNCF [2] 接手到 2018 年畢業，並且擁有一個龐大且快速增長的完整生態系統。
[1] Kubernetes（k8s）從K到S中間共有8個字符，名稱源自古希臘語，意思為舵手或飛行員。 [2] Cloud Native Computing Foundation（CNCF），雲端原生運算基金會，致力於Github上的快速成長的開源技術推廣。
Deployment - 從傳統部署到容器化部署
要想知道 Kubernetes 和 Containerized Deployment 的重要性，首先需要了解到部署演變歷史：
Traditional Deployment - 傳統部署
傳統部署會直接在服務器上運行應用程序，這樣無法控制應用程序可能消耗的資源(CPU, Memory)，從而導致資源分配問題。如果應用程序消耗了運行它的服務器的大部分資源，則此高負載可能會導致同一物理服務器上運行的其他應用程序出現性能問題。一種解決方案是在每個服務器上運只運行一個應用程序，但這將導致資源利用不足，維護成本增加。
Virtualized Deployment - 虛擬化部署
在虛擬化部署時代，多個虛擬機（VM）帶來了解決方案的開端。虛擬化使將應用程序隔離在同一服務器上運行的不同 VM 之間，從而提供安全層和更好的資源分配。此解決方案降低了硬件的成本，但每個 VM 仍需要與傳統部署相同的管理和維護
Containerized Deployment - 容器化部署
容器化部署，說到這必須先說說容器 Container。容器包括其運行環境以及應用程序運行所需的所有 Library 和 Dependency。具有不同需求的容器可以在同一台 VM 或服務器上運行，並且共享資源。而且容器相當容易移植，並且可以輕鬆地在不同的雲端和 OS 發行版之間運行，從而使軟件對硬件的依賴性越來越低，並降低了維護成本
Container Orchestration - 管理容器化部署
在 Production Environment 裡一般會運行大量的容器，並且需要管理應用程式的容器以確保沒有停機時間。理論上要手動管理成千上萬個同時運行的容器得可行性是很低的。Kubernetes 能夠管理容器化的應用程式（Containerized Application）的生命週期，定義應用程式該如何運行，如何與外界的其他應用程序交互，同時提供可預測性 Predictability、可擴展性 Scalability、高可用性 High Availability。
Kubernetes Architecture - 體系結構
在 Kubernetes 的概念裡，一台機器或是 VM 被稱作一個_節點 Node_。而 Kubernetes 能夠在多個節點之間使用共享網路連結，這樣多個節點被稱為集群 Cluster。 Kubernetes 上的組件 (Component) 和工作負載 (Wordload) 都在此 Cluster 上進行配置。
Kubernetes Cluster 中的每個 Node 在系統中都有特定的角色，一般來說分為以下兩大類：
Master
Master (主節點) 是 Kubernetes Cluster 的大腦。一般會在上面配置核心組件，用於在其餘服務器的運行狀況檢查、公開許多不同的 API、安排 Workload、並編排不同組件之間的通信。Master 是一個 Cluster 的主要聯繫點，在 Production 環境中正常會有多個 Master 來達成高可用性 High Availability。
Node
Node (節點) 是其餘服務器的總稱，也被稱為節點。一般會經由 Master 安排各種容器在上面運行，這意味著它們中的每一個都需要在其上安裝 Container Runtime（例如 Docker 或 CRI-O）。
Kubernetes Cluster 中運行的不同基礎組件可確保*應用程序的所需狀態與 Cluster 的實際狀態相匹配。若應用程序的所需狀態發生變化，Master 將通過在 Node 上創建或銷毀 Container，以及調整各項網路設定來恢復應用程序的所需狀態。
用戶與 Master 之間的溝通直接用 API 或通過提交 JSON 或 YAML 設置檔案。該設置檔案包含有關創建內容和管理方法的說明，由決定如何部署應用程序的組件安排。
Kubernetes Component - 組件
Master Component - 主組件
Master Component 是一個 Cluster 的控制平面。這些組件用於製定有關 Cluster 的決策，以及檢測和響應事件。Kubernetes Cluster 需要運行多個應用程序。它們是用於保證 Cluster 的健康狀態和進行通信和控制的組件。
etcd
etcd 是一個兼具一致性和高可用的分布式键值存储 key-value store，Kubernetes 使用 etcd 儲存設置configuration data、狀態 status、元資料 metadata。
kube-apiserver
kube-apiserver 是公開 Kubernetes API 主要組件。它是Kubernetes控制平面的前端，也是用戶與集群進行交互的主要手段。kube-apiserver 是唯一與etcd 進行直接通信的組件。
kube-scheduler
kube-scheduler 主要功能是監測尚未分配節點的工作負載 （Pod），並為它們分配到一個節點上運行。分配決策的考慮因素包括 Pod 所需的資源需求（如 cpu, memory）、軟硬件以及策略約束 （constraints）、親和性規範（affinity）、數據位置（data locality）、工作負載間的干擾、以及最後時限（deadline）。
kube-controller-manager
kube-controller-manage 主要是運行控制器[3]的主組件。為了降低複雜性，所有控制器都在單個進程中運行。其中包括 Node Controller 節點控制器、Replication Controller 副本控制器、Endpoint Controller 端點控制器、Service Account & Token Controllers 服務帳戶和令牌控制器。
cloud-controller-manager
cloud-controller-manager是 Cluster 在雲提供商上運行時，負責控制雲端資源的控制平面組件，使其鏈接到雲提供商的應用編程接口。與 kube-controller-manager 類似，cloud-controller-manager 將多個控制器在單個進程中運行。其中包括 Node Controller 節點控制器、Route Controller 路由控制器、Service Controller 服務控制器。
[3] 控制器 Controller，是一個專門負責確保期望狀態 (Desired State) 符合當前狀態 (Current State) 的組件
Node Component - 節點組件
在 Kubernetes 中執行 Workload（運行容器）的服務器稱為節點。節點可以是VM或物理機。
kubelet
kubelet 運行在每個節點上，類似於一個代理。其確保容器在 Pod[4] 中處於運行狀態並健康。kubelet 只管理 Kubernetes 創建的容器。
kube-proxy
kube-proxy 是 Cluster 中的每個 Node 上運行的網絡代理。其維護 Node 上的網絡規則，以允許從內部或外部連接與 Cluster 內的 Pod 通信。
container runtime
Kubernetes 能夠管理容器，但不能運行它們。因此需要一個container runtime 來負責運行容器。Kubernetes支持多種container runtime，例如 Docker 或 containerd 以及Kubernetes CRI。
[4] Pod，Kubernetes 中的最小運行單位，往下閱讀更多資訊。
Kubernetes Core Concept - 概念
Kubernetes 使用容器來部署應用程序，但它也使用其他抽象層來提供擴展、彈性和生命週期管理功能。
Pod
pod
Pod 是 Kubernetes 中的最小可部署單元。一個 Pod 是由一或多個容器組成的，同一個 Pod 中的容器使用相同的網絡地址 IP、存儲資源 Volume、以及有關如何管理這些容器的信息。
Service
service
Service 是一個抽象定義，其提供了一個穩定的 IP 地址，並通過將請求重定向到服務中的不同 Pod 來充當負載平衡器 Load Balancer。服務抽象允許在不更改應用程序配置的情況下橫向擴展或替換失效的 Pod。
默認情況下，Service 僅使用內部可路由的 IP 地址可用，但可以透過定公開。這可以通過使用 NodePort 配置來完成，該配置通過在每個節點外部網絡接口上打開靜態端口 Static Port 來工作。或者可以使用該 LoadBalancer 服務在雲提供商處創建一個外部負載均衡器。但是，僅當存在雲控制器管理器時，此服務才有效。
ReplicaSet & Deployment
replicaset & deployment
Replicaset 確保在任何時間下都有指定數量的 Pod 在運行。Replicaset 的任務是根據需要創建和刪除Pod，以達到所需的狀態。Replicaset 可以通過 Pod 中的 metadata.ownerReference 了解何為其附屬 Pod，因此可以根據 Pod 的狀態安排任務。
Deployment 是比 Replicaset 更高層次的概念，是管理副本集並使用許多其他功能為 Pod 提供更新聲明。Deployment Controller 運行 Replicaset 中指定的應用程序的多個副本 Replicas。萬一任何 Pod 可能發生故障或無法響應，該 Pod 將被替換直到實際狀態等於所需狀態為止。
StatefulSet
StatefulSet 能夠像 Deployments 一樣管理 Pod，但還會維護每個 Pod 的粘性標識。Pod 是從相同的基礎創建的，但不可互換。StatefulSet Controller 的操作模式與任何其他 Controller 相同。StatefulSet Controller 通過進行必要的更新以從集群的實際狀態變為所需狀態，來維護 StatefulSet 對像中定義的所需狀態。
即使將 Pod 移動到另一個 Node，StatefulSet 將保持其中每個 Pod 的唯一性，基於數字的名稱也會保留。
DaemonSet
daemonset
Pod Controller 的另一種類型稱為 DaemonSet。它確保所有（或某些）節點都運行 Pod 的副本。對於大多數用例，在何處運行 Pod 無關緊要，但是在某些情況下，要求單個 Pod 在所有節點上運行。這對於聚集日誌文件、收集指標、或運行網絡存儲群集很有用。
Job & CronJob
Job 能夠管理任務，直到任務運行完成。其可以並行運行多個 Pod，它們對於批處理任務 batch-oriented tasks 很有用。
Kubernetes 中的 CronJob 就像 Linux 中的傳統 cron 作業類似。它們可用於在特定時間或間隔運行任務，常見的有備份或清除任務。
Volume
Volume 是 Pod 中的容器可訪問的資料夾 directory。Kubernetes 使用其自身的 Volume 定義，從而允許所有容器共享數據並保持可用狀態，直到終止 Pod。Kubernetes Volume 具有明確的生命週期。這意味著當 Pod 不再存在時，Pod 中的數據將被破壞。這也意味著 Volume 不是用於存儲持久數據的好解決方案。
Persistent Volume
為了避免將 Volume 生命週期的約束與 Pod 生命週期綁定在一起，Persistent Volume 允許為 Cluster 配置獨立於 Pod 生命週期的存儲資源。終止 Pod 後，將根據該 Volume 的回收策略來確定是否保留該 Volume。策略可以是手動刪除該 Volume 或者終止該 Pod 時刪除。
