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 網絡插件。
參考官方文檔 《如何選擇容器服務網絡模式》: //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》://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 社區官方開源內核:
TKE-Optimized 的優勢:
- 基於內核社區長期支持的 4.14.105 版本定製
- 針對容器和雲場景進行優化
- 計算、存儲和網絡子系統均經過性能優化
- 對內核缺陷修復支持較好
- 完全開源：//github.com/Tencent/TencentOS-kernel
選型建議:
- 推薦 「TKE-Optimized」，穩定性和技術支持都比較好
- 如果需要更高版本內核，選非 「TKE-Optimized」版本的操作系統
節點池
此特性當前正在灰度中，可申請開白名單使用。主要可用於批量管理節點：
- 節點 Label 與 Taint
- 節點組件啟動參數
- 節點自定義啟動腳本
- 操作系統與運行時 (暫未支持)
產品文檔：//cloud.tencent.com/document/product/457/43719
適用場景:
- 異構節點分組管理，減少管理成本
- 讓集群更好支持複雜的調度規則 (Label, Taint)
- 頻繁擴縮容節點，減少操作成本
- 節點日常維護(版本升級)
用法舉例:
部分IO密集型業務需要高IO機型，為其創建一個節點池，配置機型並統一設置節點 Label 與 Taint，然後將 IO 密集型業務配置親和性，選中 Label，使其調度到高 IO 機型的節點 (Taint 可以避免其它業務 Pod 調度上來)。
隨着時間的推移，業務量快速上升，該 IO 密集型業務也需要更多的計算資源，在業務高峰時段，HPA 功能自動為該業務擴容了 Pod，而節點計算資源不夠用，這時節點池的自動伸縮功能自動擴容了節點，扛住了流量高峰。
啟動腳本
組件自定義參數
此特性當前也正在灰度中，可申請開白名單使用。
- 創建集群時，可在集群信息界面「高級設置」中自定義 Master 組件部分啟動參數：
- 添加節點時，可在雲服務器配置界面的「高級設置」中自定義 kubelet 部分啟動參數：
節點啟動配置
- 新建集群時，可在雲服務器配置界面的「節點啟動配置」選項處添加節點啟動腳本：
- 添加節點時，可在雲服務器配置界面的「高級設置」中通過自定義數據配置節點啟動腳本 (可用於修改組件啟動參數、內核參數等):
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多乾貨！！
