0%
Theme NexT works best with JavaScript enabled
Kubernetes (k8s)
Kubernetes (有時會使用縮寫 K8s，8 是 K 到 s 中間的英文字母個數) 是開放原始碼系統，可在任何位置部署、擴充及管理容器化的應用程式。
Kubernetes（K8S）是一個可以幫助我們管理微服務（microservices）的系統，他可以自動化地部署及管理多台機器上的多個容器（Container）。
更進一步地說，Kubernetes 想解決的問題是：「手動部署多個容器到多台機器上並監測管理這些容器的狀態非常麻煩。」而 Kubernetes 要提供的解法： 提供一個平台以較高層次的抽象化去自動化操作與管理容器們。
intro
同時部署多個容器到多台機器上（Deployment）
服務的乘載量有變化時，可以對容器做自動擴展（Scaling）
管理多個容器的狀態，自動偵測並重啟故障的容器（Management）
Kubernetes 四元件
Pod
Kubernetes 運作的最小單位，一個 Pod 對應到一個應用服務（Application）
每個 Pod 都有一個身分證，也就是屬於這個 Pod 的 yaml 檔
一個 Pod 裡面可以有一個或是多個 Container，但一般情況一個 Pod 最好只有一個 Container
同一個 Pod 中的 Containers 共享相同資源及網路，彼此透過 local port number 溝通
Worker Node
Kubernetes 運作的最小硬體單位，一個 Worker Node（簡稱 Node）對應到一台機器，可以是實體機如你的筆電、或是虛擬機如 AWS 上的一台 EC2 或 GCP 上的一台 Computer Engine。
每個 Node 中都有三個組件：kubelet、kube-proxy、Container Runtime。
kubelet
該 Node 的管理員，負責管理該 Node 上的所有 Pods 的狀態並負責與 Master 溝通
kube-proxy
該 Node 的傳訊員，負責更新 Node 的 iptables，讓 Kubernetes 中不在該 Node 的其他物件可以得知該 Node 上所有 Pods 的最新狀態
Container Runtime
該 Node 真正負責容器執行的程式，以 Docker 容器為例其對應的 Container Runtime 就是 Docker EngineMaster 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 進階三元件 Service
在連線到一個 Pod 的服務資源時，會使用到 port-forward 的指令
但如果我們有多個 Pods 想要同時被連線時，我們就可以用到 Service 這個進階元件
簡單來說，Service 就是 Kubernetes 中用來定義「一群 Pod 要如何被連線及存取」的元件。
Deployment
要把一個 Pod 做橫向擴展，也就是複製多個相同的 Pod 在 Cluster 中同時提供服務，並監控如果有 Pod 當機我們就要重新把它啟動時，如果我們要一個 Pod 一個 Pod 透過指令建立並監控是很花時間的。因此，我們可以透過 Deployment 這個特殊元件幫我們達成上述的要求。
Ingress
了解完了 Service 跟 Deployment 後，接下來就輪到概念稍微複雜的 Ingress 元件了。 在上面有提到 Service 就是 Kubernetes 中用來定義「一群 Pod 要如何被連線及存取」的元件。 但在 Service 中，我們是將每個 Service 元件對外的 port number 跟 Node 上的 port number 做 mapping，這樣在我們的 Service 變多時，port number 以及分流規則的管理變得相當困難。
而 Ingress 可以透過 HTTP/HTTPS，在我們眾多的 Service 前搭建一個 reverse-proxy。這樣 Ingress 可以幫助我們統一一個對外的 port number，並且根據 hostname 或是 pathname 決定封包要轉發到哪個 Service 上，如同下圖的比較：
在 Kubernetes 中，Ingress 這項服務其實是由 Ingress Resources、Ingress Server、Ingress Controller 構成
Ingress Resources 就是定義 Ingress 的身分證
Ingress Server 則是實體化用來接收 HTTP/HTTPS 連線的網路伺服器
Ingress Server 有各式各樣的實作，就如同市面上的 Web Server 琳瑯滿目一樣
Ingress Controller 就是一個可以把定義好的 Ingress Resources 設定轉換成特定 Ingress Server 實作的角色。
舉例來說，Kubernetes 由官方維護的兩種 Ingress Controller 就有 ingress-gce 跟 ingress-nginx ，分別可以對應轉換成 GCE 與 Nginx。也有其他非官方在維護的 Controller，詳細的列表可見官網的 additional-controllers 。
Reference
