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

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

相關文章