{%hackmd BJzAwtWvp %}
# k8s 簡介
## 參考資料

[Day23 Kubernetes (Kubernetes on Docker Desktop & Pod Lifetime)](https://ithelp.ithome.com.tw/articles/10247441)
[Kubernetes 基礎教學（一）原理介紹](https://cwhu.medium.com/kubernetes-basic-concept-tutorial-e033e3504ec0)

## 使用k8a達到的效果及目的
* 同時部署多個容器到多台機器上（Deployment）
* 服務的乘載量有變化時，可以對容器做自動擴展（Scaling）
* 管理多個容器的狀態，自動偵測並重啟故障的容器（Management）

## Kubernetes 四元件
在了解 Kubernetes 如何幫助我們管理容器們前，我們先要由小到大依序了解組成 Kubernetes 的四種最基本的元件：<font color="#f00">Pod、Worker Node、Master Node、Cluster</font>。

### Pod
Kubernetes 運作的最小單位，一個 Pod 對應到一個應用服務（Application） ，舉例來說一個 Pod 可能會對應到一個 API Server。

* 每個 Pod 都有一個身分證，也就是屬於這個 Pod 的<font color="#f00"> yaml 檔</font>
* <font color="#f00"> 一個 Pod 裡面可以有一個或是多個 Container，但一般情況一個 Pod 最好只有一個 Container</font>
* 同一個 Pod 中的 Containers 共享相同資源及網路，<font color="#f00">彼此透過 local port number 溝通</font>

#### Pod Lifetime
* 實體化出來的 Pods 會有幾種不同的狀態，用來描述該 Pod 當前生命週期階段。

* Pending : Pod 啟用已被 kubernetes 接受，但裡面的 containers 尚未啟用完全
* Running : Pod 已啟用，且內部 containers 已正確運行中
* Succeeded : Pod 與內部 containers 已啟用並正確結束，此狀態 Pod 不會自動重啟
* Failed : Pod 內的 containers 皆已停止，且至少一個 container 以異常終止方式停止
* Unknown : Pod 的狀態無法被更新，通常發生在 Pods 與 Nodes 連線溝通異常時

### Worker Node

Kubernetes 運作的最小硬體單位，一個 Worker Node（簡稱 Node）對應到一台機器，可以是實體機如你的筆電、或是虛擬機如 AWS 上的一台 EC2 或 GCP 上的一台 Computer Engine。

每個 Node 中都有三個組件：kubelet、kube-proxy、Container Runtime。

> 小提醒：在 Worker Node 與 Master Node 的組件部分，因為 Kubernetes 本身其實都抽象的很好，所以在 Kubernetes 「基礎的」使用上如何不了解這些組建也不會有非常大的影響。

#### kubelet

* 該 Node 的管理員，負責管理該 Node 上的所有 Pods 的狀態並負責與 Master 溝通

#### kube-proxy

* 該 Node 的傳訊員，負責更新 Node 的 iptables，讓 Kubernetes 中不在該 Node 的其他物件可以得知該 Node 上所有 Pods 的最新狀態

#### Container Runtime

該 Node 真正負責容器執行的程式，以 Docker 容器為例其對應的 Container Runtime 就是 Docker Engine

### Master Node

* Kubernetes 運作的指揮中心，可以簡化看成一個特化的 Node 負責管理所有其他 Node。一個 Master Node（簡稱 Master）中有四個組件：kube-apiserver、etcd、kube-scheduler、kube-controller-manager。

#### kube-apiserver

* 管理整個 Kubernetes 所需 API 的接口（Endpoint），例如從 Command Line 下 kubectl 指令就會把指令送到這裏
* 負責 Node 之間的溝通橋樑，每個 Node 彼此不能直接溝通，必須要透過 apiserver 轉介
* 負責 Kubernetes 中的請求的身份認證與授權

#### etcd

* 用來存放 Kubernetes Cluster 的資料作為備份，當 Master 因為某些原因而故障時，我們可以透過 etcd 幫我們還原 Kubernetes 的狀態

#### kube-controller-manager

* 負責管理並運行 Kubernetes controller 的組件，簡單來說 controller 就是 Kubernetes 裡一個個負責監視 Cluster 狀態的 Process，例如：Node Controller、Replication Controller
* 這些 Process 會在 Cluster 與預期狀態（desire state）不符時嘗試更新現有狀態（current state）。例如：現在要多開一台機器以應付突然增加的流量，那我的預期狀態就會更新成 N+1，現有狀態為 N，這時相對應的 controller 就會想辦法多開一台機器
* controller-manager 的監視與嘗試更新也都需要透過訪問 kube-apiserver 達成

#### kube-scheduler

* 整個 Kubernetes 的 Pods 調度員，scheduler 會監視新建立但還沒有被指定要跑在哪個 Node 上的 Pod，並根據每個 Node 上面資源規定、硬體限制等條件去協調出一個最適合放置的 Node 讓該 Pod 跑

### Cluster
* Kubernetes 中多個 Node 與 Master 的集合。基本上可以想成在同一個環境裡所有 Node 集合在一起的單位。


## 基本運作

接下來我們用一個簡單的問題「Kubernetes 是如何建立一個 Pod？」來複習整體 Kubernetes 的架構。上圖為一個簡易的 Kubernetes Cluster，通常一個 Cluster 中其實會有多個 Master 作為備援，但為了簡化我們只顯示一個。

當使用者要部署一個新的 Pod 到 Kubernetes Cluster 時，使用者要先透過 User Command（kubectl）輸入建立 Pod 的對應指令（下面會在解說如何實際動手操作來建立一個 Pod）。此時指令會經過一層確認使用者身份的認證後，傳遞到 Master Node 中的 API Server，API Server 會把指令備份到 etcd 。

接下來 controller-manager 會從 API Server 收到需要創建一個新的 Pod 的訊息，並檢查如果資源許可，就會建立一個新的 Pod。最後 Scheduler 在定期訪問 API Server 時，會詢問 controller-manager 是否有建置新的 Pod，如果發現新建立的 Pod 時，Scheduler 就會負責把 Pod 配送到最適合的一個 Node 上面。

雖然上面的基本運作看似複雜，但實際上我們在操作時，只要輸入一行指令後 Kubernetes 就會自動幫我們完成後續的動作。

---
###### tags: `k8s`