TKE 集羣組建最佳實踐

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/doc...

運行時: 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/doc...

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 社區官方開源內核:

TKE-Optimized 的優點:

• 基於內核社區長期支持的 4.14.105 版本定製
• 針對容器和雲場景進行優化
• 計算、存儲和網絡子系統均通過性能優化
• 對內核缺陷修復支持較好
• 徹底開源：https://github.com/Tencent/Te...

選型建議:

• 推薦 「TKE-Optimized」，穩定性和技術支持都比較好
• 若是須要更高版本內核，選非 「TKE-Optimized」版本的操做系統

節點池

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

• 節點 Label 與 Taint
• 節點組件啓動參數
• 節點自定義啓動腳本
• 操做系統與運行時 (暫未支持)

產品文檔：https://cloud.tencent.com/doc...

適用場景:

• 異構節點分組管理，減小管理成本
• 讓集羣更好支持複雜的調度規則 (Label, Taint)
• 頻繁擴縮容節點，減小操做成本
• 節點平常維護(版本升級)

用法舉例:

部分IO密集型業務須要高IO機型，爲其建立一個節點池，配置機型並統一設置節點 Label 與 Taint，而後將 IO 密集型業務配置親和性，選中 Label，使其調度到高 IO 機型的節點 (Taint 能夠避免其它業務 Pod 調度上來)。

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

啓動腳本

組件自定義參數

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

1. 建立集羣時，可在集羣信息界面「高級設置」中自定義 Master 組件部分啓動參數：

1. 添加節點時，可在雲服務器配置界面的「高級設置」中自定義 kubelet 部分啓動參數：

節點啓動配置

1. 新建集羣時，可在雲服務器配置界面的「節點啓動配置」選項處添加節點啓動腳本：

1. 添加節點時，可在雲服務器配置界面的「高級設置」中經過自定義數據配置節點啓動腳本 (可用於修改組件啓動參數、內核參數等):

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