---
title: "【K8S Beginners 筆記】CH 1~3 Introduction、Overview and Setup"
date: 2025-01-20
is_modified: true
disqus: cynthiahackmd
image: https://i.imgur.com/2F0W0aE.png
categories:
- "雲端網路 › 雲端運算"
tags:
- "Udemy"
- "Docker"
- "K8S"
- "Kubernetes Beginners"
- "讀書筆記"
---

{%hackmd @CynthiaChuang/Github-Page-Theme %}

<br>

最近公司流行考 CKA 和 CKAD 證照，所以大家最近都在瘋狂買課程。說真的，Udemy 應該給我們團購價才對 🤣。不過，**Beginners** 這門課程是專為 K8S 初學者設計的，非常適合我這個半吊子的學習者。

<br>

這已經是我第二次重寫 Beginners 課程的筆記了！上次莫名其妙收到 HackMD 團隊通知，說我的筆記涉嫌版權或內容濫用，我整個黑人問號 🤔，但又懶得改，乾脆直接撤下來。結果最近被老大調侃技能樹怎麼這麼久沒更新，害我默默翻出草稿夾，心想：好吧，乾脆來重寫這系列吧，總不能一直被笑吧！

這次我還特意把一些圖片換掉，希望能避開那些搞不懂的版權問題（雖然我到現在還是不知道到底踩到哪條紅線 🤷‍♂️）。不過，重新寫筆記也不錯，說不定寫完這系列筆記，年底真的可以去挑戰考證照 🌟！

<!--more-->

<p class="illustration">
<img src="https://i.imgur.com/2F0W0aE.png" width="600px" alt="課程縮圖" width="600px">
K8S for Beginners（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

## CH 1｜Introduction
課程正式開始前，講師 [Mumshad Mannambeth](https://www.udemy.com/user/mumshad-mannambeth/)介紹了下整個 K8S 的系列課程。在這個系列中包含了 3 個課程，分別面向初學者、開發者與管理員：

- [Kubernetes for the Absolute Beginners - Hands-on](https://www.udemy.com/course/learn-kubernetes/)
如其名，如果是 K8S 的初學者，可以從這堂課開始入手，這門課程會一步一步帶學生了解與熟悉 Kubernetes 的各種資源，如：YAML、PODS、Deployments、Networking、Services...等。
- [Kubernetes Certified Application Developer (CKAD) with Tests](https://www.udemy.com/course/certified-kubernetes-application-developer/)
這門課程內容包含 secrets、multi-container pods、logging and monitoring jobs、services and networking 的部署與配置...等，並協助準備針對開發者的 CKAD 認證考試。
- [Certified Kubernetes Administrator (CKA) with Practice Tests](https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/)
這門課是針對管理員，涵蓋監視、維護、故障排除...等，並協助準備 CKA 認證考試。

上述三門課程都包含編碼練習和測驗，還有講師家的 [KodeKloud](https://kodekloud.com/courses/labs-kubernetes-for-the-absolute-beginners-hands-on/) 平台，它可以省去環境部署的麻煩，是個可以永久免費練習 Kubernetes 環境，這個也是當初吸引購買這系列課程的主因 XDDD

## CH 2｜Kubernetes Overview
Kubernetes，簡稱為 K8S，是一個用於==自動部署、擴展和管理「容器化（containerized）應用程式」== 的開源系統。該系統由 Google 設計並捐贈給 Linux 基金會。

在這個章節中，先介紹兩個術語：**Container** 與 **Orchestration**

### 2-1｜Container Overview
這一節的內容，其實更像是在介紹 Docker，而不僅僅是單純的 container。講師從宏觀的視角切入，帶我們探討為什麼需要 Docker，以及它能解決哪些具體問題。

不過，需要特別留意一點：雖然 Docker 和 container 的概念在這裡稍微有些混淆，但它們其實並不完全等同。==container 是指一種技術==，而 ==Docker 只是這項技術的其中一個成功實現方式==。市面上其實也有其他 container 技術的實現方式，例如 LXC、LXD、LXCFS 等，它們都可以實現類似功能，取代這隻鯨魚哦！

#### 解決痛點：為什麼容器化技術如此重要？
容器化技術的誕生，正是為了解決開發與部署過程中的兩大痛點：

1. **相依性地獄（Dependency Hell）**
在未導入容器化技術之前，要開發一個涵蓋全端的服務，往往需要多種技術組件協同運作，比如 NodeJS 的前端、MongoDB 的資料庫、Kafka 的消息系統、Ansible 的自動化編排工具...等等。

然而，挑戰不僅在於從零開始部署這些元件，更在於它們之間錯綜複雜的相依性問題。例如，元件和作業系統之間的相依性，或者元件與元件之間共用函式庫的依賴衝突...等。更麻煩的是，每當元件升級，這些相依性檢查就得再來一次！（這個真的是超級討厭的！！！😩

課程中把這樣的現象稱之為地獄矩陣（The Matrix from Hell），維基百科則稱之為[相依性地獄](https://zh.wikipedia.org/zh-tw/相依性地狱)。

<p class="illustration">
<img src="https://i.imgur.com/enbb9n3.png" alt="地獄矩陣">
地獄矩陣
</p>
2. **環境設置效率與一致性**
部署過開發環境的人都懂，成功與否的關鍵，靠的不是教學而是人品。🙃

那些幸運的人，即便拿到天書也能順利完成；而那些倒霉的人，即使拿著詳細的說明書，也還是會掉進各種坑...不然我也不會寫出這麼多的踩坑紀錄 XDDD

更麻煩的是，部署環境從來不是一次性任務！除了新成員加入時得重部一次外，在專案的不同階段，還需要部署和維護測試環境（testing）、模擬環境（staging）、生產環境（production）...等等。這些部署不僅耗時費力，也讓環境難以維持一致性...相信大家一定有過這種經驗：明明在自己機器上跑得好好的，結果搬到其他地方卻掛了 😑

<br class="big">

容器化技術的優勢在於**避免相依性問題**與**提升部署效率與環境一致性**。它讓不同的元件可以運行於各自獨立的 container 中，彼此互不干擾，並允許專用函式庫的個性化配置。配置完成後，只需執行簡單指令（例如 docker run），便可快速復現整個環境，大幅減少手動調整的時間和潛在錯誤。

<p class="illustration">
<img src="https://i.imgur.com/67HhbdF.png" width="600px" alt="各個元件各自住在自己的 container 裡，彼此互不打擾，還能擁有自己專屬的函式庫。">
各個元件各自住在自己的 container 裡，彼此互不打擾，還能擁有自己專屬的函式庫。
</p>

#### container 技術的基礎概念
如果你對虛擬機（VM）有所了解，那麼理解 container 會容易很多。簡單來說，container 也能讓應用程式完全隔離，擁有獨立的 processes/service、network interface 和 mounts...等。但它與 VM 最大的不同就在於：
<div class="blockquote-center">
<p>
Container 會共享作業系統的核心來運行，而 VM 則不會。
</p>
</div>

<br class="big">

在了解 Docker 和 container 的運作方式之前，得先聊聊它和 Linux 系列作業系統之間的故事。

從恐龍本我們學到，所謂的作業系統是由**核心（Kernel）與一系列軟體所組成**。其中，Kernel 負責操作底層硬體，而軟體則包含使用者界面、驅動程式、編譯器、文件管理器、開發工具...等等。

而市面上常見的作業系統，如 Ubuntu、Fedora、SUSE 和 CentOS 等，他們實際上都 Linux 發行版、使用通用的 Linux Kernel，只是在界面和工具上進行了不同程度的客製化。

這意味著什麼呢？如果你打包了一個 CentOS container，你其實可以把它部署到 Ubuntu 上，因為它們共享相同的核心！這就是 container 和 VM 最大的不同之處——==container 直接共享主機的 Kernel==。

<p class="illustration">
<img src="https://i.imgur.com/6wJImxX.png" alt="Linux 系列的作業系統通用的 Linux Kernel" width="600px" >
Linux 系列的作業系統是通用的 Linux Kernel（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

重點說三次！
**Container 會共享作業系統 Kernel**
**Container 會共享作業系統 Kernel**
**Container 會共享作業系統 Kernel**

換句話說，如果主機的作業系統與 container 的作業系統無法共享同一個 Kernel，那這個 container 是跑不起來的。

在說誰呢？**Windows** 啦 XDDD

至於蘋果家的 MacOS 呢？我沒親自試過，不敢打包票，但應該是能跑吧？畢竟它是 Darwin 系統，也是類 Unix 系統，所以也有機會。而且，我在 Docker Hub 上還看到有一個 [macOS 專案](https://hub.docker.com/r/joseluisq/rust-linux-darwin-builder)，所以應該是能跑吧 XDDD

<br class="big">

從理論上來看，container 必須共享 Kernel ，且 Windows 顯然和 Linux Kernel 不搭嘎。那這讓我想到一個問題：**Windows 是怎麼讓 Linux container 跑起來的？**

但如果閱讀 [〈Install Docker Desktop on Windows〉](https://docs.docker.com/desktop/setup/install/windows-install/)或是[〈WSL｜在 WSL2 中安装 Docker〉](https://hackmd.io/@CynthiaChuang/Install-Docker-in-WSL2/)，其實就可以發現它的關鍵在於兩個後端 **WSL2（Windows Subsystem for Linux）** 和 **Hyper-V**，不過兩個是二擇一的：
1. **WSL2**
這是我之前傻傻地照著步驟安裝的方法，不過回頭再看，原來它是扮演相容層的角色，讓 Docker Desktop for Windows 可以透過它間接讓 container 能在 Windows 上運行。
2. **Hyper-V**
這是一種虛擬化技術，但它是如何充當後端，我沒有深入研究，不過推測是啟動一個虛擬的 Linux 系統吧？

換句話說，即使我們可以在 Windows 上運行 Linux container，但**背後的核心依然是 Linux**，而非 Windows。

<br class="big">

或許有人會認為「container 無法執行其他 Kernel」是一個限制。但我認為**不算**，畢竟 Docker 的重點是方便應用程式的部署和管理，而不是跨核心運行其他元件。如果真的需要，那或許你該考慮 VM，而不是 container 了。

#### VM 與 Container 的區別
<p class="illustration">
<img src="https://i.imgur.com/QdyRbLQ.png" alt="VM 與 container 的區別" width="500">
VM 與 Container 的區別
</p>

先前提過，container 與 VM 最核心的不同之處在於：**container 會共享作業系統的 Kernel 來運行，而 VM 則不會**。這點從上圖中就可看出來，container 依賴於主機的作業系統，並在其上執行應用程式；而==在 VM 中，都擁有各自的作業系統，並基於該作業系統執行應用程式==。

但核心差異，也帶來兩個區別：
1. **資源利用效率**
container 因共享主機的作業系統核心，能**減少了額外的硬體負擔**，因此能顯著提高資源利用率。這點從硬體空間使用、啟動迅速可以感受到明顯差別就是。
2. **安全性差異**
但也因為 container 並不像 VM 那樣完全隔離，**安全性也相對較差**。因此在涉及多租戶或高安全性需求的環境中，虛擬機器可能更合適。

以下是從 Microsoft [〈容器與虛擬機器〉](https://learn.microsoft.com/zh-tw/virtualization/windowscontainers/about/containers-vs-vm)一文中節錄兩者比較的部分，有助於我們了解 container 與 VM 的主要區別：

| 功能| 虛擬機器 | 容器|
| ---- | ---| ---- |
| 隔離 | 可與主機作業系統和其他 VM 徹底隔離。 如果強式安全性界限很重要 (例如，在相同伺服器或叢集上裝載來自競爭公司的應用程式)，隔離便很有用。| 一般可提供與主機和其他容器的輕量型隔離功能，但無法提供和 VM 一樣的強式安全性界限。|
| 作業系統 | 會執行包含核心在內的完整作業系統，因此需要更多系統資源 (CPU、記憶體和儲存體)。 | 執行作業系統的使用者模式部分，而且可以量身打造而只包含應用程式所需的服務，因此使用的系統資源較少。 |
| 客體相容性 | 幾乎可以在虛擬機器內執行任何作業系統。 | 會在與主機相同的作業系統版本上執行。 |
|作業系統更新和升級 |在每個 VM 上下載並安裝作業系統更新。 若要安裝新版作業系統，則必須升級，但通常會直接建立全新的 VM。 這可能非常耗時，特別是如果您有很多 VM 的話...|在容器內更新或升級作業系統檔案的方法相同：編輯 Dockerfile，以指向最新版的 Windows 基底映像。 使用這個新的基底映像重建容器映像。 將容器映像推送至容器登錄。 使用協調器重新部署。 協調器提供了強大的自動化功能而可大規模執行此作業。|
|永續性儲存體 |使用虛擬硬碟 (VHD) 作為單一 VM 的本機儲存體，或使用 SMB 檔案共用作為多部伺服器共用的儲存體|使用 Azure 磁碟作為單一節點的本機儲存體，或使用 Azure 檔案儲存體 (SMB 共用) 作為多個節點或伺服器共用的儲存體。|
|負載平衡|虛擬機器負載平衡功能會將執行中的 VM 移至容錯移轉叢集中的其他伺服器。|容器本身不會移動；相反地，協調器可以在叢集節點上自動啟動或停止容器，以管理負載和可用性的變更。|

#### Image、Container 與 Registry
在介紹容器化技術，特別是 Docker 的時候，我們都會提到三個基本概念：映像檔（Image）、Container 和 Registry。

- **Image**
常見的翻譯是「映像檔」或「鏡像」，它是一個**唯讀的完整操作系統環境**，在容器化技術中扮演著==模板==的角色，用來創建一個或多個 container。

如果沒有現成的 Image 符合需求，我們可以基於現有的 Image，向上疊加所需要的操作。值得注意的是，每一層建構完成後是不可修改的，因此才會說 Image 是唯讀的環境。我之前有寫過一篇[〈客製化自己的 Docker 映像檔流程〉](https://hackmd.io/@CynthiaChuang/The-Workflow-for-Creating-Your-Own-Custom-Image/)，就是在做這件事。

- **Container**
如果說 Image 是模板，那麼 ==container 就是基於這個模板創建出來的實體（Instance）==，用物件導向的角度來看，它就像是「類別（Class）」和「實例（Instance）」之間的關係。

就像前面所展示的，這些 container 可以視為獨立的環境，彼此之間互不干涉...除非它們共用相同的 Volume？

- **Registry**
課程中雖然沒有直接提到這個詞，但課程提到的 Docker Hub 就是這個概念的體現，因此我還是將它列出來。在課程中提到可以將 Image 推送到 Docker Hub，這就像是 **GitHub 和 Repository 的關係**，它們都能進行 Pull 和 Push 操作。唯一的區別是 Git Repository 存放的是 source code，而 Docker Registry 存放的是 Docker Images。

<br>

我將三者之間的關係，參考了[〈What is Docker Hub?〉](https://www.geeksforgeeks.org/what-is-docker-hub/)中的圖表，我重新畫了一張，雖然原本圖表的色系就和我的網誌風格超搭，但我希望能強調 Image 可以同時用來創建多個 container，因此做了一些調整，雖然...這調整好像不太明顯？

<p class="illustration">
<img src="https://i.imgur.com/8tYs4QA.png" alt="Docker 的整個生命週期包括三個基本概念 Image、Container 和 Registry" width="600">
Docker 的整個生命週期包括三個基本概念 Image、Container 和 Registry
</p>

這三者在開發和維運的過程中扮演了關鍵角色。在尚未導入容器化技術的時代，運營團隊在接手開發成果時，通常對應用設置不夠熟悉，必須仰賴開發團隊的協助才能完成。而導入 Docker 後，建立基礎設施的繁瑣流程大多數都可以透過 Docker 自動化處理，大幅提升了效率。

具體來說，開發團隊會將 Image 上傳到公開的映像檔倉庫（Public Image Registry）或是內部的私有倉庫（Private Registry）。運營團隊則可以從這些倉庫中拉取（Pull）所需的 Image，以在各種平台上快速部署應用程式。不僅縮短了生產環境的部署時間，還能確保與開發環境的一致性，減少因環境差異引起的問題

### 2-2｜Orchestration
在完成 Image 打包後，接下來就是 container 的部署及 **Orchestration** 的部分。

在部署時，container 之間往往存在依賴需求，例如與資料庫或訊息系統的連接。而當系統負載發生變化時，能否靈活地擴展或縮減（Scaling Out/In）便成為關鍵。

這些挑戰都可以透過 Orchestration 技術來應對。它==不僅能實現 container 的自動部署與管理==，還具備協調 container 間連接的能力，並支持自動擴展與縮減，滿足各種場景下的運營需求。

隨著應用程序架構日益複雜，高效管理大量 container、確保系統穩定性與可擴展性，成為容器化技術實踐中的核心課題。而 Orchestration 技術無疑是解決這些問題的關鍵，為運營效率的提升提供了強有力的支持。

<p class="illustration">
<img src="https://i.imgur.com/CMZL66R.jpg" alt="Container Orchestration" width="600">
Container Orchestration（圖片來源: <a href="https://www.atatus.com/glossary/container-orchestration/">atatus</a>）
</p>

#### Orchestration Technologies
本堂課程的主角 **Kubernetes（K8S）**，就是一種 ==Container Orchestration（容器編排）技術==，同時也是目前最受歡迎的 container 調度工具。

Kubernetes 之所以能在眾多 Orchestration 工具中脫穎而出，與其強大的功能和靈活的設計密不可分。它不僅支持 container 的自動化部署與管理，還能根據工作負載的變化，動態調整資源分配，實現高可用性與彈性擴展，讓應用程序的運行更加高效穩定。

此外，Kubernetes 的廣泛應用還得益於其**開放性和強大的社群支持**。無論是初學者還是大型企業，Kubernetes 提供了標準化的接口，便於整合至現有系統架構，快速啟用容器化的工作流。這樣的特性，使其成為雲端時代的核心基石之一。因此，無論是在 GCP、Azure 還是 AWS 等公有雲服務平台上，都能看到它的身影。

然而，儘管 Kubernetes 是當前的市場主流，市面上仍有其他 Container Orchestration 解決方案，能在不同應用場景中發揮重要作用。例如：

1. **Swarm**：設置簡單、入門容易，但在面對複雜應用場景時略顯不足。
2. **Mesos**：適合管理成百上千個節點的大型系統，但其高學習曲線和複雜性，對於小型叢集（Cluster）來說有些大材小用。
3. **Kubernetes**：定位居中，既能應付相對複雜的場景，又不至於讓使用者陷入過高的學習成本，因此成為市場上的首選。

順帶一提，下圖中統計提到的 **OpenShift**，也是一種 Orchestration 技術。這是 Red Hat 推出的一個基於 Kubernetes 的發行版，實際上可以視為 Kubernetes 的擴展版。換句話說，Kubernetes 是 OpenShift 的核心基礎。

<p class="illustration">
<img src="https://i.imgur.com/O6WHEvq.png" alt="Orchestration Technologies 2020 市占率" width="600">
Orchestration Technologies 2020 市占率（圖片來源: <a href="https://www.t4.ai/industries/container-platform-market-share">T4</a>）
</p>

#### Advantages
Kubernetes 的受歡迎程度，其實也再次證明了 Orchestration 技術在現代容器化應用中有多重要。它之所以能成為大家的最愛，不只是因為它夠流行，更是因為它真的解決了許多 container 管理上的痛點。而它的優勢之處，主要就體現在這幾個方面：

1. **高可用性**
服務會在多個節點（node）上執行，即便某個節點發生硬體故障，也不會導致整體服務的停擺。這樣的架構確保了服務的持續可用性，並且，透過 Orchestration 帶來的自動化管理，不僅可以減少人為操作的失誤，還能讓系統更穩定、更可靠。

2. **彈性**
Orchestration 讓系統具備高度彈性，能夠自動調整 container 或叢集（Cluster）的規模。當使用者需求增加時，系統能無縫地部署更多實體來應對負載的上升；相反地，若需求減少，系統也能在不關閉服務的情況下，縮減底層節點的數量，保持系統資源的最佳化。

3. **簡化操作**
使用者只需通過簡單的配置文件，就能輕鬆完成多項操作，包括負載平衡與 container 管理等。這不僅簡化了操作流程，還大幅減少了手動操作的複雜度，讓管理者能夠專注於業務發展而非繁瑣的技術細節。

### 2-3｜Kubernetes Architecture
了解了 Kubernetes 的優勢後，接下來我們將進一步探索 Kubernetes 的架構，並介紹一些專有名詞和概念。掌握這些基礎知識，將有助於讓後續的內容更加清晰易懂。

#### Proper Noun
1. **節點（Nodes/Minions）**
Node 節點在過去曾被稱為 Minions（小小兵 XDDD），不過這個稱呼現在似乎比較少見了，至少我身邊的人都習慣直接叫它 node。

廣義上，node 可以指==一台物理機器或虛擬機==，具體取決於所屬 cluster 的配置。而在 Kubernetes 中，container 會被放置在這些 node 上啟動並執行工作負載。狹義上，node 特指 worker node，即提供實際運算資源的節點。

<p class="illustration">
<img src="https://imgur.com/JhR3Ij6.png" alt="節點（Nodes/Minions）" width="350px">
節點（Nodes/Minions）
</p>

2. **叢集（Cluster）**
**Cluster 就是一組 node**。Cluster 的好處在於，當某個 node 發生故障時，其他 node 仍然可以繼續提供服務，從而**維持服務的可用性**。此外，擁有多個 node 也能有效地**分擔負載**，提高整體系統的運行效率。

<p class="illustration">
<img src="https://i.imgur.com/BfvzmSQ.png" alt="叢集（Cluster）" width="600px">
叢集（Cluster）
</p>

3. **主節點（Master）**
Master 本身也是一個 node，但它擁有**特殊的角色和職責**。作為 ==Kubernetes cluster 的管理者==，Master 負責管理和記錄 cluster 及相關資料，並監控 cluster 中的各個 nodes。此外，它還負責 container 的實際 orchestration，例如當某個 node 出現故障時，Master 會將其工作負載轉移到其他可用的 node 上。

<p class="illustration">
<img src="https://imgur.com/QtzSR29.png" alt="主節點（Master）">
主節點（Master）
</p>

#### Components
在了解了這些專有名詞後，講師進一步介紹在實際安裝 Kubernetes 時會涉及到的 **6 種元件**。這些元件協同工作，確保 Kubernetes 的順利運行，並使我們能夠更高效地管理和調度 container。接下來是每個元件的簡介：

<p class="illustration">
<img src="https://imgur.com/BF00Xt6.png" alt="Kube Components" width="600px">
Kube Components（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

1. **API server**
API server 是 Kubernetes 的前端，所有使用者、管理設備和 CLI 都會通過 API server 與 cluster 進行交互。它處理並轉發來自不同來源的請求，是 Kubernetes 的核心控制平面之一。

2. **etcd service**
etcd 是 Kubernetes 用來存儲所有 cluster 管理資料的資料庫。它存儲有關 pod、service deployments...等的資訊，並使用 etcd lock 技術將資料以 key-value pair 形式分散儲存，確保資料的一致性和高可用性。

3. **kubelet service**
kubelet 是運行在每個 node 上的服務，負責確保每個 container 按照預期在 node 上執行。它會監控每個 container 的狀態，並與 API server 進行溝通，報告當前狀況。

4. **Container Runtime**
Container Runtime 是執行 container 的基礎軟體。在這門課程中，我們使用的是 Docker Engine，但也有其他選擇，例如 RKT，我曾看過有人用它作為 Runtime，但不曉得最後為什麼放棄了 XDDD

5. **Controllers**
Controllers 則是 orchestration 背後的大腦。當 node、container 或 endpoint 出現故障時，controllers 會根據設定進行通知並回應，通常會啟動新的 container 來保持系統穩定。說到 controllers，資料中提到過這個 "s" 代表許多控制器，後面課程應該會詳細介紹？

6. **Schedulers**
Schedulers，也就是工作調度器，負責資源調度。它主要負責在不同 node 之間進行負載均衡，並決定 container 的最佳安放位置，以達到高效運作。

每個元件的運行相輔相成，協助 Kubernetes 完成容器的管理、調度與擴展等功能，保證了容器化應用的高效運行。

#### Master vs Worker Nodes
這 **6 種元件** 與前面提到的 M**aster-Worker 架構中的兩類 node** 共同構成了整個 Kubernetes 系統的基礎。雖然這樣說，但其實在單一 node 上並不會部署所有這 6 種元件，而是根據該 node 的角色進行特定的元件配置。Master node 和 Worker node 各自負責不同的任務，因此所安裝的元件也有所不同。

<p class="illustration">
<img src="https://i.imgur.com/WvBnRoC.png" alt="Master node 和 Worker node 各自負責不同的任務，因此所安裝的元件也有所不同。" width="600px">
Master node 和 Worker node 各自負責不同的任務，因此所安裝的元件也有所不同。（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

Worker node，也就是我們專門負責執行 container 的小小兵（minion）。為了讓 container 能順利運行，每個 node 都需要安裝 **container runtime**，這是執行 container 的基礎。此外，每個 Worker node 還會配置一個管理者——**kubelet**。它的主要任務是確保 container 的執行符合來自 Master node 的要求，同時也負責與 Master 進行溝通，接收請求並回報健康狀態，確保整體系統的協作與穩定運行。

與 kubelet 相對的是 **kube-apiserver**，這幾乎可以說是 ==Master 的標誌性象徵==，也是 Kubernetes cluster 中最重要的元件之一。對內，kube-apiserver 是 cluster 中各個 node 的溝通橋樑，因為 node 之間無法直接互通；對外，它則充當 K8S 的前端接口，負責處理使用者請求，並將這些請求交由 controllers 和 schedulers 分析後，再分發到相應的 node 執行。此外，kube-apiserver 還身兼溝通協調大師的角色，還斜槓負責整個 Kubernetes 中的==身份認證與授權==，保障系統的安全性與可靠性。

在 Master 中，與 kube-apiserver 密切合作的一個關鍵元件是 **etcd**。這個元件主要負責存放 Kubernetes cluster 的所有資料作為備份，並記錄 cluster 的狀態與運行信息，確保系統的高可靠性與容錯能力。此外，Master 中還有 controller 和 scheduler 等元件協同工作。不過這章節先暫時停在這，後續課程應該會進一步展開討論（應該吧？）。

<br class="big">

<p class="illustration">
<img src="https://imgur.com/Inaxpvp.png" alt="M" width="600px">
（圖片來源: <a href="https://kubernetes.io/docs/concepts/architecture/">kubernetes 官網</a>）
</p>

但在閱讀官網資料時，我注意到他們用的是**控制平面（Control Plane）**，而不是 **Master**。

根據查閱，Master Node 在 2020 年左右改用了「Control Plane」這個說法，雖然兩者看似相同，但仔細來說還是有些不同。**Master** 通常指的是管理其他節點的那個實體節點，而控制平面則是描述 Kubernetes 中負責管理集群的核心元件，像是 **kube-apiserver**、**etcd**、**scheduler** 和 **controller manager** 等。

不過，對大部分用戶來說，這些控制平面元件通常會部署在同一個 Master Node 上，尤其在測試環境或小型專案中。而在較大的集群或需要高可用性時，則可能會將這些元件分散部署，以提高可靠性。

簡而言之，Master 更像是指實際的節點，而控制平面則是這些元件運作的整體機制。因此大部分情況下，這兩個都是指向在同一個節點，除非在大型專案中將元件分散部署，兩者才會有明顯的差異。

#### kubectl
如要操作 Kubernetes，當然少不了它的命令行工具 **kubectl**，又稱 **kube command line tool** 或 **kube control**。其實，這工具和另一個常常讓人搞混的元件 kubelet 完全不同（還是只有我會搞混呢？）。kubectl 是 Kubernetes 提供的 API 命令工具集，用來和 K8S cluster 進行互動，負責部署與管理應用，並監控 cluster 或 node 的狀態。

<p class="illustration">
<img src="https://i.imgur.com/xVxABOG.png" alt="常用 kubectl 指令" width="600px">
常用 kubectl 指令（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

好了，言歸正傳，來看一下 kubectl 是如何使用的。它基礎常用指令有 `run`、`cluster-info` 和 `get nodes` 。
- **`kubectl run`**：用於在 cluster 中部署應用。
- **`kubectl cluster-info`**：查看有關集 cluster 的資訊。
- **`kubectl get nodes/pods`**： 列出 cluster 中的所有 node 資訊。

<br>

在這裡，我們忽然遇到了另一個專有名詞 Pod，於是我查了一下相關定義：
1. **Pod**
它是 Kubernetes 中**最小的運作單位**。每個 Pod 通常對應一個應用服務，可以包含一個或多個 container。這樣的設計讓 Kubernetes 能夠以彈性的方式管理 container，並確保同一服務的多個 container 能夠在同一個 Pod 內協同工作。
2. **Node**
它則是 Kubernetes 中**最小的硬體運作單位**。一般來說，每個 Node 對應一台物理機器或虛擬機，負責運行應用服務所需的 container。在 Kubernetes 集群中，Nodes 承擔著資源的提供與管理角色。

結合前面所提到的內容，可以得知，在 Kubernetes 的 cluster 中會有多個 Node，Kubernetes 則會根據需求在 Pod 中啟動一個或多個 container，並最終將這些 container 放置在相應的 Node 上執行。

<p class="illustration">
<img src="https://i.imgur.com/kUbliM1.png" alt="cluster、nodes 與 pods 之間三者關係" width="600px">
cluster、nodes 與 pods 之間三者關係（圖片來源: <a href="https://youtu.be/QMwIaXWPF6Q?si=HaTopfGNNBx-4lWl">Page Cloud Academy｜youtube</a>）
</p>

### 2-4｜練習與測驗
1. **What is a worker machine in Kubernetes known as?**
- [x] Node or Minion
2. **A Node in Kubernetes can only be a physical machine and can never be a virtual machine.**
- [x] False
3. **Multiple Nodes together form a**
- [x] Cluster
4. **Which of the following processes runs on Kubernetes Master Node**
- [x] Kube-apiserver
5. **Which of the following is a distributed reliable key-value store used by kubernetes to store all data used to manage the cluster**
- [x] etcd
6. **Which of the following services is responsible for distributing work or containers across multiple nodes.**
- [x] scheduler
7. **Which of the following is the underlying framework that is responsible for running application in containers like Docker?**
- [x] container runtime
8. **Which is the command line utility used to manage a kubernetes cluster?**
- [x] kubectl

### 2-5｜補充資料
- [Kubernetes Concepts](https://kubernetes.io/docs/concepts/)

## CH 3｜Setup Kubernetes
前面講師介紹了 Kubernetes 的起源與一些專有名詞，接下來就到了實作部分。講師接著分享了幾種設置 Kubernetes cluster 的方法。

不過此次為了重寫，而重新去聽了課程，發現這章被打散到各章節去了，但寫都寫了我就不把它打散了。

### 3-1｜Introduction and Minikube

<p class="illustration">
<img src="https://i.imgur.com/GpryRLk.png" alt="Setup Kubernetes" width="600px">
Setup Kubernetes（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

這裡講師介紹了幾種快速構建 Kubernetes cluster 的方法，適合不同需求與環境：
1. **本地端設置**
如果希望在筆記本電腦或虛擬機上自行搭建 Kubernetes，可以選擇工具如 **Minikube** 或 **kubeadm**。這些工具能快速幫助你啟動一個簡單的開發環境，適合學習和測試。
2. **雲端託管**
想省去基礎架構設置的麻煩，直接使用雲端服務提供的解決方案，例如 Google Cloud Platform（GCP）或 Amazon Web Services（AWS）的 Kubernetes 託管服務。這種方式適合生產環境，能大幅節省時間與管理成本。
3. **Play with Kubernetes**
課程中提到了一個名為 [Play with Kubernetes](https://labs.play-with-k8s.com/) 的實驗平台。這是一個由 Docker 提供並由 Tutorius 創建的遊樂場，能讓使用者在幾秒鐘內快速啟動一個 Kubernetes cluster。

### 3-2｜Demo：Minikube
這章節展示了如何安裝 Minikube，但因為我之前已經安裝過，所以直接跳過了。不過，根據影片內容，可以將安裝過程簡單總結為四個步驟：

1. **安裝 kubectl**
影片中使用的是二進制檔安裝，不過指令和[官方教學](https://kubernetes.io/docs/tasks/tools/)中的方式略有差異，這可能是隨著版本更新而產生的變化。因此，建議還是參考官方文件。另外，我注意到文件中提到也可以用 `apt-get` 安裝 kubectl，這可能更方便。
2. **確認本地端是否已安裝 VirtualBox**
由於 Minikube 的運行需要在本地啟動一個虛擬機（VM），因此需要額外安裝 [VirtualBox](https://www.virtualbox.org/wiki/Downloads)。另外，記得確保你的系統已啟用虛擬化功能！
3. **安裝 Minikube**
同樣建議參考[官方教學](https://minikube.sigs.k8s.io/docs/start/)，因為目前的安裝步驟已經和影片中的內容有所不同。
4. **執行測試**
在 Minikube 上執行一個簡單的應用，例如 hello-minikube app。

<br>

是說，在教學教學文件中，除了 Minikube，還提到了 **kubeadm** 的相關內容。不過，我在影片中並沒有找到這部分的介紹，但我想即使有，安裝步驟可能也已過時，所以直接翻閱官方文檔[〈Kubeadm｜Kubernetes〉](https://kubernetes.io/docs/reference/setup-tools/kubeadm/)比較適當。

此外，在〈Kubeadm｜Kubernetes〉文件提到 Minikube 和 kubeadm 的主要差異：
- **Minikube**：僅能設置單一 Node 的 Kubernetes cluster，適合用於本地測試與學習。
- **Kubeadm**：可用於設置多 Node 的 Kubernetes cluster，更適合生產環境或需要多節點的測試。

<p class="illustration">
<img src="https://i.imgur.com/LgyrJVh.png" alt="minikube 跟 kubeadmin">
minikube 跟 kubeadmin（圖片來源: <a href="https://www.udemy.com/course/learn-kubernetes/">課程截圖</a>）
</p>

不過，我並不打算在本地端安裝 minikube，但為了能夠測試課程中的指令，我選擇申請了 [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine?hl=zh-tw)。這部分的筆記我將它與[第10章節的筆記](https://hackmd.io/@CynthiaChuang/Kubernetes-for-the-Absolute-Beginners-04#10-2｜Google-Kubernetes-Engine-GKE)合併在一起了，到時候再一併介紹吧~

### 3-3｜練習與測驗
1. **Which of the below is an option to run Kubernetes in a Local Environment?**
- [x] minikube

2. **Which of the below is an instant way of setting up a permanent kubernetes cluster on the cloud?**
- [x] Google Container Engine (GKE)

3. **Which of the below solution is used for setting up a multi-node Kubernetes cluster in a local environment?**
- [x] kubeadm

## 其他連結
1. 課程內容：[Kubernetes for the Absolute Beginners - Hands-on](https://www.udemy.com/course/learn-kubernetes/)
2. 目錄： [【K8S Beginners 筆記】目錄](https://hackmd.io/@CynthiaChuang/Kubernetes-for-the-Absolute-Beginners-Contents)

## 參考資料
1. 協同撰寫。[Kubernetes](https://zh.wikipedia.org/zh-tw/Kubernetes)。檢自 維基百科 (2022-10-06)。
2. (2021-10-30)。[Docker 基本觀念與原理介紹](https://functional.style/docker/general/overview/)。檢自 點燈坊 (2022-10-06)。
3. JasonGerend, v-susbo, Et al.(2022-09-22)。[容器與虛擬機器](https://learn.microsoft.com/zh-tw/virtualization/windowscontainers/about/containers-vs-vm)。檢自 Microsoft Learn (2022-10-07)。
4. Jack in the world (2019-10-15)。[[CS] Docker的三個基本概念: Image, Container, 和Registry](https://mailtojacklai.medium.com/cs-docker的三個基本概念-image-container-和registry-89844595a7a6)。檢自 Jack in the world｜Medium (2022-10-07)。
5. Red Hat (2019-12-02)。[什么是容器编排？](https://www.redhat.com/zh/topics/containers/what-is-container-orchestration)。檢自 Red Hat (2022-10-14)。
6. The Kubernetes Authors (2022-10-02)。[Viewing Pods and Nodes](https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/)。檢自 Kubernetes (2022-11-02)。
8. 被蛇咬到的魯卡 (2020-11-11)。[Kubernetes 教學 — 什麼是 Pod？什麼 Node ？搞的我好亂呀！](https://medium.com/starbugs/kubernetes-教學-一-概念與架構-954caa9b1558)。檢自 Starbugs Weekly 星巴哥技術專欄｜Medium (2022-11-02)。

## 更新紀錄
:::spoiler 最後更新日期：2025-01-20
- 2025-01-20 更新：重構筆記內文、並重新製圖
- 2022-11-09 更新：新增 GKE、K8S 補充資料
- 2022-11-03 發布
- 2022-11-02 完稿
- 2022-10-05 起稿
:::

{%hackmd @CynthiaChuang/Github-Page-Footer %}