之前我曾經提到了一系列關於服務網格的內容。然而，我意識到有些同學可能對Kubernetes的瞭解相對較少，更不用說應用服務網格這個概念了。因此，今天我決定帶著大家快速理解Kubernetes中的一些專有名詞，以便在短時間內入門，並減少學習的時間。我將在接下來的5分鐘內為你介紹這些名詞，希望你能從中獲得一些收穫。如果你覺得有所幫助，請給個贊來鼓勵我吧！你的支援是我前進的動力~
Kubernetes
首先，我想強調的是，在學習任何一項知識時，官方文件都是最重要的資源：https://kubernetes.io/zh-cn/docs/home/
官方文件提供了詳盡、準確的資訊，幫助我們深入瞭解和掌握這個技術。因此，如果你真的對Kubernetes感興趣，我強烈建議你花些時間仔細閱讀官方文件。
談到Kubernetes，它是一個開源的容器編排引擎，旨在實現容器化應用的自動化部署、擴縮和管理。簡而言之，它能夠集中控制多個Docker容器，而不僅限於單獨操作每個容器。在沒有Kubernetes之前，如果我們想要同時操作多個Docker容器，可能需要學習並執行Shell指令碼，這需要花費一些時間。因此，如果你希望實現批次管理Docker容器，Kubernetes就是一個不錯的選擇，當然也可以考慮其他類似的產品。
Kubernetes 元件
假設你已經順利完成Kubernetes的安裝。一旦你部署好Kubernetes，你就擁有了一個完整的叢集。下面是官方提供的架構圖，我們可以參考一下。圖中列出了許多元件的名稱，包括：Node、Pod、kubelet、kube-proxy、kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager等一系列專有名詞。接下來，我們將逐一解釋這些名詞的含義。
Node
根據架構圖，你可能已經猜到Node實際上就是一臺機器，它負責執行容器化的應用程式。然而，一個Node上可以執行多個Pod。Pod是Kubernetes的最小排程單位，通常情況下，一個Pod代表一個微服務。下面是一個Pod的YAML示例：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
然而，這並不意味著一個Pod只能支援一個docker映象。例如，我們的服務網格中存在邊車模式，允許在同一個Pod中定義多個微服務。但為什麼不在同一個Pod中定義多個微服務呢？這是因為Pod是最小的排程單位，它們需要一起啟動和重啟。這種繫結關係非常嚴格，因此如果你已經有一個叢集，為什麼不將它們分開定義呢？因此，即使定義多個映象，也只需要定義一些輔助功能，如日誌收集等。
kubelet
kubelet這個元件在整個Kubernetes系統中扮演著重要的角色。具體而言，控制平面將Pod的定義傳送給kubelet，然後kubelet根據這些定義來建立和管理Pod中的容器。kubelet負責監控Pod和容器的狀態，並將這些狀態資訊報告給控制平面。控制平面可以根據這些狀態資訊來做出排程和管理決策，以確保整個系統的高效執行。
你可以將Pod理解為每個專案組的招聘HR，類似於一個專案的招聘負責人。而控制平面則可以理解為上層的公司領導，他們制定了招聘要求和招聘人數，具體的招聘工作由HR來執行。HR的職責是確保專案有足夠的人員，並且符合公司領導的要求。他們會持續監視專案的人員情況，一旦有人離職，他們會向上級報告，滿足上層的控制平面要求。同時，上層的公司領導與專案人員是沒有直接溝通的，所有的溝通都透過HR進行。HR在這個過程中起到了專案人員與上層領導之間的聯絡人的作用，負責傳遞資訊、解決問題和協調工作。
kube-proxy
加長最佳化語句：我們在架構圖中看到kube-proxy也是與上層有聯絡的。它透過服務代理和負載均衡功能，實現了叢集內部的網路通訊和流量轉發，確保了服務的可用性和可靠性。
在我們的專案組中，他是誰呢？他是那位真正指導Pod要執行哪些任務的人。可以說，他擔任著專案組中開發leader的角色，或者像專案經理一樣的角色。他負責指導我們要做什麼任務，一旦有需求，他會負責轉發和分配工作。
然而，需要注意的是，他並不直接與Pod進行網路通訊，而是與Service物件進行溝通。
Service
在上述情況中，我們引入了Service物件。實際上，Service物件代表了一組Pod資源。在生產環境中，我們通常不會只部署一個服務來處理請求，而是會有多個Pod副本同時處理。因此，我們需要一個Service物件將它們歸類在一起，以便kube-proxy可以進行負載均衡轉發等操作。只要Pod中的labels標籤後面的key:value匹配，就可以將請求轉發給相應的Pod副本。metadata下的labels欄位可以包含任何鍵值對，只要符合key:value的格式即可。
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
控制平面元件
控制平面元件在叢集中扮演著重要角色，它們負責做出全域性決策，例如資源的排程，以及監測和響應叢集事件，比如當部署的replicas欄位不滿足時，啟動新的Pod。控制平面元件可以在叢集中的任何節點上執行。然而，為了簡化設定和管理，通常會在同一臺計算機上啟動所有控制平面元件，並且不會在該計算機上執行使用者容器。可以將其類比為公司董事會，他們負責決策和管理，與實際執行工作的Pod之間關係不直接。
kube-apiserver
透過這個名字，你可以推斷出他負責處理並呼叫其他元件來完成所有API請求。舉個例子，我們之前定義了一個Pod的YAML格式檔案。透過在後臺執行kubectl apply -f your-pod.yaml，kube-apiserver就會接收到你的請求，並將其轉發給誰呢？正如我們之前提到的，它會將請求轉發給kubelet，kubelet負責與Docker進行互動並進行建立等操作。因此，kube-apiserver就像是我們的控制器一樣，直接接收請求但不處理它們。
etcd
etcd是一種用作Kubernetes所有叢集資料的後臺資料庫。不僅可以儲存你能想到的所有資料，而且採用分散式儲存方式，基於Raft演算法確保資料的一致性。這使得所有節點都能保持資料的一致性，因為etcd儲存了叢集的配置資料、狀態資訊和後設資料。作為叢集的“大腦”，etcd儲存了關於容器、節點、Pod、服務和其他資源的資訊。透過監視etcd中的資料變化，服務發現機制能夠實現自動的服務註冊和發現。當新的Pod或服務被建立時，它們會在etcd中註冊相關資訊。其他元件或應用程式可以透過查詢etcd來獲取這些資訊，從而實現服務之間的通訊和協調。
kube-scheduler
我們當時說kubelet是負責管理該節點上的容器和Pod，那麼誰來排程呢？就是由kube-scheduler負責。kube-scheduler的主要職責是從可用節點中選擇最優節點來執行Pod，以確保資源的均衡分配，避免機器資源的浪費。由於控制平面元件較多，為了更好地理解它們各自的作用，我還額外準備了一張圖來清晰地展示。
kube-controller-manager
kube-controller-manager是Kubernetes叢集中不可或缺的核心元件之一，它的主要職責是執行一系列控制器，以確保叢集的狀態始終維持在預期的狀態。為了更好地理解其功能，我們以Deployment Controller管理器為例進行說明，而其他控制器的詳細資訊則可以透過自行查詢來獲取。
Deployment Controller是一個負責管理應用部署的元件。它的主要功能是根據使用者定義的期望狀態來控制ReplicaSet的建立、更新和刪除操作，從而實現應用的滾動升級和回滾。舉一個例子。當一個Pod掛掉時，kubelet會首先監測到該Pod的狀態改變，並將這個資訊傳遞給kube-controller-manager中的Replication Controller（如果該Pod是由Replication Controller建立的）。Replication Controller是負責維護Pod副本數量的控制器之一。
一旦Replication Controller接收到關於Pod狀態改變的通知，它將檢查叢集中當前的Pod副本數量，並根據其定義的副本數量進行調整。如果發現當前的Pod數量少於所需的副本數量，Replication Controller將發出指令給kubelet，在相應的節點上重新建立缺失的Pod來滿足副本數量的要求。之前我們不是一直說將kubelet比作是HR嗎？上層領導找到了就是Deployment Controller。
注意不管是什麼管理層Controller都要走kube-apiserver這一層。只有他才有資格呼叫其他元件kube-apiserver。
cloud-controller-manager
cloud-controller-manager是一個可選的元件，它提供了與雲平臺相關的控制器。對於我們來說，它可能看起來與我們的工作無關。cloud-controller-manager在與雲平臺的API進行互動時，能夠管理雲資源，例如負載均衡器、節點組、儲存卷等。這使得我們能夠獲得更豐富的雲資源管理功能。需要注意的是，cloud-controller-manager的具體功能和行為是根據所使用的雲平臺而定的。因此，它可以根據我們所用的雲平臺提供適當的解決方案。
總結
在本文中，我向大家介紹了Kubernetes中的一些專有名詞。Kubernetes是一個非常強大的容器編排引擎，可以幫助我們自動化部署、擴充套件和管理容器化應用程式。透過了解這些專有名詞，我們可以更好地理解Kubernetes的工作原理和架構。因為大家的時間都很寶貴，所以我儘量減少閱讀時間帶大家快速入門Kubernetes，覺得不錯，給個贊吧~