前言

上一章我們使用 Kubernetes Service 實現藍綠部屬，本章就來探討 Kubernetes 內部是如何實現流量轉發、負載平衡等功能，並且談談有了 Kubernetes 為何還需要 Istio 的原因。

Kubernetes 元件介紹

想要了解 Kubernetes 內部的原理，要先從它的架構開始。Kubernetes 是由不同功能的元件組合而成，有的負責生命週期的管理，有的處理外部與內部的溝通行為，主要元件有以下這幾種。

kube-apiserver

管理 Kubernetes API，負責處理接受請求的工作。

etcd

鍵值資料庫，負責保存叢集資料。

kube-scheduler

監聽 Pod 元件的資源使用率，並選擇 Pod 要在哪個節點上運行。

kube-controller-manager

管理 Kubernetes Controller 元件如 Node Controller、Job Controller。

cloud-controller-manager

管理與 Cloud 相關的控制邏輯。

kubelet

會安裝在叢集裡的每個節點，確保 Container 能在 Pod 上正常執行。

kube-proxy

會安裝在叢集裡的每個節點，維護節點的網路規則。

Container runtime

負責運行 Container 的應用程式。

Kubernetes 元件圖，圖片取至 Kubernetes Components

Kubernetes 是如何實現流量轉發、負載平衡等功能，底下實作就是藉由 Kube-proxy 元件，下面就來介紹什麼是 Kube-proxy。

Kube-proxy 介紹

Kube-proxy 為 Kubernetes 的元件，會安裝在叢集中的各個節點，負責處理 Service、Pod 元件互相溝通的方式，有三種不同的實作模式，分別為 User space、iptables以及IPVS。

kube-proxy IPVS proxy mode 示意圖，圖片取至 Kubernetes Documentation - Service

到底 Kube-proxy 是如何實作 Service 呢，我們以 IPVS 模式做為例子，當建立了一個 Service Yaml 檔案並部屬到 Kubernetes 時，會發生以下流程。

1. Kubectl 透過 API Server 與 Kubernetes 進行互動
2. 建立 Service 元件給予其 IP，並在 DNS 上記錄
3. 根據 Service 的 Label Selector 讓 Kubernetes 了解要將流量導入哪些 Pod
4. Kube-proxy 對各個節點設置 IPVS 規則，使流量可以正確轉發

kube-proxy 可以想像成是在管理每個節點上的表，讓進入節點的流量可以根據 IP 轉發到正確位置

這裡舉一個簡單的例子讓你了解整個流程，在 Kubernetes 世界中 Service 以及 Pod 都會有自己的 IP ，假設建立了名為 my-svc 的 Service (IP: 10.23.1.2) 以及兩個 Pod (IP: 10.1.0.3、10.2.3.5)，kube-proxy 就會幫忙在節點中建立規則。

ipvsadm -Ln
...
  -> RemoteAddress:Port       Forward Weight ActiveConn InActConn       
TCP  10.23.1.2:80 rr
  -> 10.1.0.3:80              Masq    1      0          0         
  -> 10.2.3.5:80              Masq    1      0          0   
...

此為節點上的 IPVS 規則，當此節點擷取到 10.23.1.2:80 的封包，會以 rr(round-robin) 模式將封包移轉至 10.1.0.3:80 或 10.2.3.5:80

rr(round-robin) 是一種排程演算法，目的是將流量平均分散至各個 Pod，藉以達成負載平衡。

而 Pod 之間要互相溝通，就只需要有 Service Name 即可，具體流程如下

1. Pod 對 my-svc 發出請求
2. DNS 將 Service Name 轉成 IP (Ex: my-svc -> 10.23.1.2)
3. Pod 對 Service IP(10.23.1.2) 發出請求
4. 節點根據 IPVS 規則擷取封包，以 rr(round-robin) 模式選擇 IP (10.1.0.3 或是 10.2.3.5)
5. Pod 成功建立連線

所以 Kubernetes 如何實現流量轉發、負載平衡等功能，靠的就是 Iptables、IPVS等技術，Kube-proxy 會與節點溝通並配置相關規則，藉此完成 Service 的實作。

Kube-proxy vs. Service Mesh

了解完 Kube-proxy 的原理，再來談談與 Service Mesh 相比使用 Kube-proxy 有哪些缺點

• Kube-proxy 攔截的是進出節點的流量，而 Sidecar 攔截的是進出 pod 的流量，Kube-proxy 沒辦法對服務更精細的控制。
• 若 Pod 不能正常服務(Ex: HTTP 500 Error)，Kube-proxy 無法偵測到，也就無法嘗試重啟 Pod。
• 只能對 Pod 作 rr、隨機分發等負載平衡機制，沒辦法對流量進行細緻的控制(Ex: 99%流量給A，1%流量給 B)

圖片取至 Why Do You Need Istio When You Already Have Kubernetes?

Istio 可以辦到哪些事?

若在 Kubernetes 安裝 Istio，就可以對網路行為做到更細微的控制，以下是一些例子

若 Pod 出現如 HTTP Error 等錯誤訊息，Istio 可以偵測並嘗試重啟 Pod

Istio 能對流量進行更精細的規劃(如百分比)，並且可透過 GUI 顯示當前網路流量。

總結

本篇的內部實作細節可能會讓你的腦袋打結，但其實只需了解目前 Kubernetes 對網路的實作方式沒辦法解決 Microservices 架構帶來的問題，而 Istio 就是為此而生的。下一章開始我們就會開始操作 Istio ，實際了解它到底提供了哪些功能。