Kubernetes - 元件原理介紹

發表於 更新於 分類於 Disqus： 文章字數： 3.2k 所需閱讀時間 ≈ 6 分鐘

開場先來個感嘆，這年頭要把精力全部花在寫程式好像是一件不太可能的事情了，做後端現在都要多種能力，要會好多種不同語言的 Web Framework，還需要可能會多種不同的資料庫，又分 RDBMS 跟 NoSQL、還有快取型的資料庫，此外，可能還要學會如何寫基本 script 檔，例如 Windows 的 bat 檔案、Linux 的 bash 檔，再來佈署應用程式又是一大學問，從一台主機架設，到 Docker 容器化佈署，再到現在很夯的 Kubernetes 的容器管理平台的佈署。技術債學都學不完的～

今天就來講講 Kubernetes 的元件原理，我個人覺得 Kubernetes 的複雜程度是比學 Docker 還要難上許多的，而且雖然 Kubernetes 裡面的容器技術可以不用 Docker 引擎，但現今潮流都是 Docker + Kubernetes 連環計，所以不建議還不懂 Docker 的情況下就先學 Kubernetes。

Kubernetes 裡面擁有許多複雜的元件，所以在開始實際操作時，建議先理解基本元件的原理再去實際操作會比較好。

Kubernetes 簡介

為什麼又叫 K8s

這個我一開始學的時候也不知道為什麼大家都叫 K8s，後來才發現一個很簡單的原因就是，從第一個字首 K 到字尾 S 之間總共有 8 個英文字母，所以發明 Kubernetes 的外國人為了不想寫那麼多字母，就寫成 K8s。

所以文章後面也用 K8s 來簡短的書寫 XD

誰發明 K8s 的

其實，起源是因為 Google 公司內部的狂人工程師們發明了一個 Borg 系統，只是並沒有開源，只能用在 Google 公司內部。最後 Google 公司裡面的工程師將其 Borg 系統經過改良造就了現在的 K8s 系統，並宣布開源，將 K8s 所有權交由 Linux 基金會來使用。

K8s 為什麼可以火紅

簡單來說：K8s 可以幫助我們自動化的操作與管理容器。

在這邊容器其實就可以想成是 Docker 的 Container。也就是說雖然 Docker 佈署已經是很方便的一件事情，但是我們仍就需要手動佈署多個容器到機器上，如果只有單一機器就還好，但是真正大型的服務一定會有需求是多個容器都在不同的機器上，那麼手動去每個機器佈署將會是很累人的一件事情，而且如果要監聽並管理這些容器的狀態也是很麻煩。

因此 K8s 有以下很好的優點：

  • 容器如果掛掉了，可以自動重啟

  • 當服務的用量增加，K8s 可以能自動讓容器做 auto scaling (自動擴展)

  • 同時佈署多個容器到多個機器上

    這個其實可以想成，在 Docker 裡面有一個很方便的佈署方式，就是利用 docker-compose。也就是說在 K8s 會需要寫類似這種性質的設定檔，而且這設定檔可以一次寫多台機器上不同的容器，因此當根據這設定檔佈署，就能完成多個容器到多個機器上的效果。

但是，也是會有一個很大的缺點：

當需要佈署容器越多的話，所需要寫 K8s 設定檔就會用複雜。當然，聰明的工程師就會設法在寫一個好用的工具去寫設定檔。

最知名的就是：Helm

之後有機會再去介紹～

Kubernetes 概觀來看

首先以一個概觀的角度來看的話，要知道第一件事情就是：

在 K8s 的世界裡面都是一個集群 (Cluster)、一個集群 (Cluster) 組成的。集群的意思，就是類似群組的意思，在一個集群裡面會有多個節點 (Node)，節點可以想成是一台主機的概念去看它。

所以大型的系統多半都是多集群的。

Cluster 裡面 Master 與 Worker 節點

Master

也就是一個 Cluster 裡面的指揮中心，它負責管理 Cluster 裡面的其他節點。在 Master 裡面有包含四大元件：

API Server

在 K8s 中，如果我們要對集群進行指令的操作，會用 kubectl 工具的 Command Line 指令，而這些指令就會直接送到 API Server，所以 API Server 會有 Kubernetes 的許多 API 接口，因此透過這個接口才能將容器佈署到其他節點上。

API Server 也負責其他 Node 的橋樑，也就是要靠 API Server 作為中介的角色。

還有一些身分認證及授權的責任。

Controller Manager

這個元件會去監視其他節點的健康狀態，而遇到不健康狀態就像是供應節點的主機掛掉了，又持續無法重啟，那個 Controller 就會刪除該節點，而節點上的 Pod 元件 (裡面裝的是容器) 也會一一的被終止，最後刪除。

也有一種狀況是現在服務需求量大，節點的供應已經無法滿足，Controller 也會根據我們給的設定檔，選擇要不要加開節點來供應。

Controller 會與 API Server 互相溝通，以便完成任務

Scheduler

會負責監聽每個節點裡面的 Pod 元件，會知道說每個 Pod 的內部資源利用率怎麼樣，確保工作負載不會超過可用資源，也就是提供負載均衡 (Load balancing) 的技術。

所以當你現在要佈署新的容器到節點上，Scheduler 會決定要把該容器放到哪個 Pod 裡面去運行。

etcd

用來存放 Kubernetes Cluster 的資料，並將資料持久化，不會因為沒存到而遺漏資料，而當 Master 因為某些原因而故障時，可以透過 etcd 幫我們還原 Kubernetes 的狀態

Worker

也就是非 Master 節點，都是 Worker 節點，負責工作就對了！

每個 Worker 節點會有以下元件：

Pod

Pod 是節點裡面的最小單位，簡單來說就是 Pod 就是放置容器服務的地方。通常一個 Pod 對應到一個容器，也可以一個 Pod 裡面放置多個容器。

在實際學習操作 K8s 都是先從如何撰寫 Pod 的設定檔，每個 Pod 會對應到一個設定檔，其實就是 yaml 檔，在設定檔裡面主要就是寫我們要佈署在這個 Pod 的 Docker Container 的資訊。

在 Pod 裡面還有一個很重要的概念要知道就是：

Pod 裡面的所有 Containers 都是共享所有儲存空間及網路，因此 Pod 裡面的 Container 要通訊，只要透過 localhost 的 port 就可以溝通了。

要知道，這是一個很強的功能，因為以往用 Docker 佈署的時候：docker 運行每個容器，都是分離的，沒辦法透過 localhost 的方式進行溝通，除非放到將應用程式放到同一個容器裡面， 不然只能用另一個容器的名字做為 mapping 去連到。

kubelet

負責自己的 Worker Node 的運行狀態，會確保 Pod 裡面的容器是否有正常運行。而當 Pod 如果出問題，會與 Master 節點進行連絡，Master 節點的 Controller Manager 就可能會下達命令將 pod 改成其他 Worker 節點運行，以維持整個 Cluster 的運作。

kube-proxy

主要負責網絡代理，負載均衡的實現，同時會根據傳入請求的 IP 和 Port，將流量轉發到指定的合適的 Pod 裡面的容器中。

cAdvisor

cAdvisor 主要是監視和收集每個節點上 Pod 裡面的容器的 CPU，內存，文件和網路使用情況等資源使用情況和性能指標的元件。

總結

從以上的介紹，最後再加上這張圖：

就可以理解整個 K8s Cluster 裡面的架構長怎樣。其實也就是工程師會透過下指令到 API Server 進行佈署等操作。而 User 使用我們佈署在 K8s 上的應用程式服務的時候，每個 Worker Node 的 kube-proxy 會根據 URL 去 Mapping 到要轉發到哪個 Pod 裡面的容器去服務。

光這樣介紹，其實還是會覺得很模糊，必須實際從 Pod 設定檔撰寫開始操作，才會慢慢理解整個 K8s 運作過程。而且 K8s 架構其實很大，也有很多知識點需要去慢慢消化，只能說當工程師太難了 QQ

下一篇關於 K8s 文章會介紹如何撰寫最基本的 Pod yaml 設定檔！

最後最後！請聽我一言！

如果你還沒有註冊 Like Coin，你可以在文章最下方看到 Like 的按鈕，點下去後即可申請帳號，透過申請帳號後可以幫我的文章按下 Like，而 Like 最多可以點五次，而你不用付出任何一塊錢，就能給我寫這篇文章的最大的回饋！