TKE 叢集組建最佳實踐

騰訊雲原生發表於2020-09-29

Kubernetes 版本

Kubernetes 版本迭代比較快,新版本通常包含許多 bug 修復和新功能,舊版本逐漸淘汰,建議建立叢集時選擇當前 TKE 支援的最新版本,後續出新版本後也是可以支援 Master 和節點的版本升級的。

網路模式: GlobalRouter vs VPC-CNI

GlobalRouter 模式架構:

  • 基於 CNI 和 網橋實現的容器網路能力,容器路由直接通過 VPC 底層實現;
  • 容器與節點在同一網路平面,但網段不與 VPC 網段重疊,容器網段地址充裕。

VPC-CNI 模式架構:

  • 基於 CNI 和 VPC 彈性網路卡實現的容器網路能力,容器路由通過彈性網路卡,效能相比 Global Router 約提高 10%;
  • 容器與節點在同一網路平面,網段在 VPC 網段內;
  • 支援 Pod 固定 IP。

網路模式對比:

支援三種使用方式:

  • 建立叢集時指定 GlobalRouter 模式;
  • 建立叢集時指定 VPC-CNI 模式,後續所有 Pod 都必須使用 VPC-CNI 模式建立;
  • 建立叢集時指定 GlobalRouter 模式,在需要使用 VPC-CNI 模式時為叢集啟用 VPC-CNI 的支援,即兩種模式混用。

選型建議:

  • 絕大多數情況下應該選擇 GlobalRouter,容器網段地址充裕,擴充套件性強,能適應規模較大的業務;
  • 如果後期部分業務需要用到 VPC-CNI 模式,可以在 GlobalRouter 叢集再開啟 VPC-CNI 支援,也就是 GlobalRouter 與 VPC-CNI 混用,僅對部分業務使用 VPC-CNI 模式;
  • 如果完全瞭解並接受 VPC-CNI 的各種限制,並且需要叢集內所有 Pod 都用 VPC-CNI 模式,可以建立叢集時選擇 VPC-CNI 網路外掛。

參考官方文件 《如何選擇容器服務網路模式》: https://cloud.tencent.com/document/product/457/41636

執行時: Docker vs Containerd

Docker 作為執行時的架構:

  • kubelet 內建的 dockershim 模組幫傲嬌的 docker 適配了 CRI 介面,然後 kubelet 自己調自己的 dockershim (通過 socket 檔案),然後 dockershim 再調 dockerd 介面 (Docker HTTP API),接著 dockerd 還要再調 docker-containerd (gRPC) 來實現容器的建立與銷燬等。

  • 為什麼呼叫鏈這麼長?Kubernetes 一開始支援的就只是 Docker,後來引入了 CRI,將執行時抽象以支援多種執行時,而 Docker 跟 Kubernetes 在一些方面有一定的競爭,不甘做小弟,也就沒在 dockerd 層面實現 CRI 介面,所以 kubelet 為了讓 dockerd 支援 CRI,就自己為 dockerd 實現了 CRI。docker 本身內部元件也模組化了,再加上一層 CRI 適配,呼叫鏈肯定就長了。

Containerd 作為執行時的架構:

  • containerd 1.1 之後,支援 CRI Plugin,即 containerd 自身這裡就可以適配 CRI 介面。
  • 相比 Docker 方案,呼叫鏈少了 dockershim 和 dockerd。

執行時對比:

  • containerd 方案由於繞過了 dockerd,呼叫鏈更短,元件更少,佔用節點資源更少,繞過了 dockerd 本身的一些 bug,但 containerd 自身也還存在一些 bug (已修復一些,灰度中)。
  • docker 方案歷史比較悠久,相對更成熟,支援 docker api,功能豐富,符合大多數人的使用習慣。

選型建議:

  • Docker 方案 相比 containerd 更成熟,如果對穩定性要求很高,建議 docker 方案;

  • 以下場景只能使用 docker:

    • Docker in docker (通常在 CI 場景)
    • 節點上使用 docker 命令
    • 呼叫 docker API
  • 沒有以上場景建議使用 containerd。

參考官方文件 《如何選擇 Containerd 和Docker》:https://cloud.tencent.com/document/product/457/35747

Service 轉發模式: iptables vs ipvs

先看看 Service 的轉發原理:

  • 節點上的 kube-proxy 元件 watch apiserver,獲取 Service 與 Endpoint,根據轉發模式將其轉化成 iptables 或 ipvs 規則並寫到節點上;
  • 叢集內的 client 去訪問 Service (Cluster IP),會被 iptable/ipvs 規則負載均衡到 Service 對應的後端 pod。

轉發模式對比:

  • ipvs 模式效能更高,但也存在一些已知未解決的 bug;
  • iptables 模式更成熟穩定。

選型建議:

  • 對穩定性要求極高且 service 數量小於 2000,選 iptables;
  • 其餘場景首選 ipvs。

叢集型別: 託管叢集 vs 獨立叢集

託管叢集:

  • Master 元件使用者不可見,由騰訊雲託管
  • 很多新功能也是會率先支援託管的叢集
  • Master 的計算資源會根據叢集規模自動擴容
  • 使用者不需要為 Master 付費

獨立叢集:

  • Master 元件使用者可以完全掌控
  • 使用者需要為 Master 付費購買機器

選型建議:

  • 一般推薦託管叢集
  • 如果希望能能夠對 Master 完全掌控,可以使用獨立叢集 (比如對 Master 進行個性化定製實現高階功能)

節點作業系統

TKE 主要支援 Ubuntu 和 CentOS 兩類發行版,帶 “TKE-Optimized” 字尾用的是 TKE 定製優化版的核心,其它的是 linux 社群官方開源核心:

img

img

TKE-Optimized 的優勢:

  • 基於核心社群長期支援的 4.14.105 版本定製
  • 針對容器和雲場景進行優化
  • 計算、儲存和網路子系統均經過效能優化
  • 對核心缺陷修復支援較好
  • 完全開源:https://github.com/Tencent/TencentOS-kernel

選型建議:

  • 推薦 “TKE-Optimized”,穩定性和技術支援都比較好
  • 如果需要更高版本核心,選非 “TKE-Optimized”版本的作業系統

節點池

此特性當前正在灰度中,可申請開白名單使用。主要可用於批量管理節點:

  • 節點 Label 與 Taint
  • 節點元件啟動引數
  • 節點自定義啟動指令碼
  • 作業系統與執行時 (暫未支援)

產品文件:https://cloud.tencent.com/document/product/457/43719

適用場景:

  • 異構節點分組管理,減少管理成本
  • 讓叢集更好支援複雜的排程規則 (Label, Taint)
  • 頻繁擴縮容節點,減少操作成本
  • 節點日常維護(版本升級)

用法舉例:

部分IO密集型業務需要高IO機型,為其建立一個節點池,配置機型並統一設定節點 Label 與 Taint,然後將 IO 密集型業務配置親和性,選中 Label,使其排程到高 IO 機型的節點 (Taint 可以避免其它業務 Pod 排程上來)。

隨著時間的推移,業務量快速上升,該 IO 密集型業務也需要更多的計算資源,在業務高峰時段,HPA 功能自動為該業務擴容了 Pod,而節點計算資源不夠用,這時節點池的自動伸縮功能自動擴容了節點,扛住了流量高峰。

啟動指令碼

元件自定義引數

此特性當前也正在灰度中,可申請開白名單使用。

  1. 建立叢集時,可在叢集資訊介面“高階設定”中自定義 Master 元件部分啟動引數:

img

  1. 新增節點時,可在雲伺服器配置介面的“高階設定”中自定義 kubelet 部分啟動引數:

img

節點啟動配置

  1. 新建叢集時,可在雲伺服器配置介面的“節點啟動配置”選項處新增節點啟動指令碼:

  1. 新增節點時,可在雲伺服器配置介面的“高階設定”中通過自定義資料配置節點啟動指令碼 (可用於修改元件啟動引數、核心引數等):

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多幹貨!!

相關文章