Kubernetes 版本迭代比較快，新版本通常包含許多 bug 修復(fù)和新功能，舊版本逐漸淘汰，建議創(chuàng)建集群時(shí)選擇當(dāng)前 TKE 支持的最新版本，后續(xù)出新版本后也是可以支持 Master 和節(jié)點(diǎn)的版本升級(jí)的。

網(wǎng)絡(luò)模式: GlobalRouter vs VPC-CNI

GlobalRouter 模式架構(gòu):

基于 CNI 和 網(wǎng)橋?qū)崿F(xiàn)的容器網(wǎng)絡(luò)能力，容器路由直接通過 VPC 底層實(shí)現(xiàn)；

容器與節(jié)點(diǎn)在同一網(wǎng)絡(luò)平面，但網(wǎng)段不與 VPC 網(wǎng)段重疊，容器網(wǎng)段地址充裕。

VPC-CNI 模式架構(gòu):

基于 CNI 和 VPC 彈性網(wǎng)卡實(shí)現(xiàn)的容器網(wǎng)絡(luò)能力，容器路由通過彈性網(wǎng)卡，性能相比 Global Router 約提高 10%；

容器與節(jié)點(diǎn)在同一網(wǎng)絡(luò)平面，網(wǎng)段在 VPC 網(wǎng)段內(nèi)；

支持 Pod 固定 IP。

網(wǎng)絡(luò)模式對(duì)比:

支持三種使用方式：

創(chuàng)建集群時(shí)指定 GlobalRouter 模式；

創(chuàng)建集群時(shí)指定 VPC-CNI 模式，后續(xù)所有 Pod 都必須使用 VPC-CNI 模式創(chuàng)建；

創(chuàng)建集群時(shí)指定 GlobalRouter 模式，在需要使用 VPC-CNI 模式時(shí)為集群?jiǎn)⒂?VPC-CNI 的支持，即兩種模式混用。

選型建議：

絕大多數(shù)情況下應(yīng)該選擇 GlobalRouter，容器網(wǎng)段地址充裕，擴(kuò)展性強(qiáng)，能適應(yīng)規(guī)模較大的業(yè)務(wù)；

如果后期部分業(yè)務(wù)需要用到 VPC-CNI 模式，可以在 GlobalRouter 集群再開啟 VPC-CNI 支持，也就是 GlobalRouter 與 VPC-CNI 混用，僅對(duì)部分業(yè)務(wù)使用 VPC-CNI 模式；

如果完全了解并接受 VPC-CNI 的各種限制，并且需要集群內(nèi)所有 Pod 都用 VPC-CNI 模式，可以創(chuàng)建集群時(shí)選擇 VPC-CNI 網(wǎng)絡(luò)插件。

參考官方文檔 《如何選擇容器服務(wù)網(wǎng)絡(luò)模式》: https://cloud.tencent.com/document/product/457/41636

運(yùn)行時(shí): Docker vs Containerd

Docker 作為運(yùn)行時(shí)的架構(gòu)：

kubelet 內(nèi)置的 dockershim 模塊幫傲嬌的 docker 適配了 CRI 接口，然后 kubelet 自己調(diào)自己的 dockershim (通過 socket 文件)，然后 dockershim 再調(diào) dockerd 接口 (Docker HTTP API)，接著 dockerd 還要再調(diào) docker-containerd (gRPC) 來實(shí)現(xiàn)容器的創(chuàng)建與銷毀等。

為什么調(diào)用鏈這么長(zhǎng)？Kubernetes 一開始支持的就只是 Docker，后來引入了 CRI，將運(yùn)行時(shí)抽象以支持多種運(yùn)行時(shí)，而 Docker 跟 Kubernetes 在一些方面有一定的競(jìng)爭(zhēng)，不甘做小弟，也就沒在 dockerd 層面實(shí)現(xiàn) CRI 接口，所以 kubelet 為了讓 dockerd 支持 CRI，就自己為 dockerd 實(shí)現(xiàn)了 CRI。docker 本身內(nèi)部組件也模塊化了，再加上一層 CRI 適配，調(diào)用鏈肯定就長(zhǎng)了。

Containerd 作為運(yùn)行時(shí)的架構(gòu)：

containerd 1.1 之后，支持 CRI Plugin，即 containerd 自身這里就可以適配 CRI 接口。

相比 Docker 方案，調(diào)用鏈少了 dockershim 和 dockerd。

運(yùn)行時(shí)對(duì)比：

containerd 方案由于繞過了 dockerd，調(diào)用鏈更短，組件更少，占用節(jié)點(diǎn)資源更少，繞過了 dockerd 本身的一些 bug，但 containerd 自身也還存在一些 bug (已修復(fù)一些，灰度中)。

docker 方案歷史比較悠久，相對(duì)更成熟，支持 docker api，功能豐富，符合大多數(shù)人的使用習(xí)慣。

選型建議：

Docker 方案 相比 containerd 更成熟，如果對(duì)穩(wěn)定性要求很高，建議 docker 方案；

以下場(chǎng)景只能使用 docker:

Docker in docker (通常在 CI 場(chǎng)景)

節(jié)點(diǎn)上使用 docker 命令

調(diào)用 docker API

沒有以上場(chǎng)景建議使用 containerd。

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

Service 轉(zhuǎn)發(fā)模式: iptables vs ipvs

先看看 Service 的轉(zhuǎn)發(fā)原理：

節(jié)點(diǎn)上的 kube-proxy 組件 watch apiserver，獲取 Service 與 Endpoint，根據(jù)轉(zhuǎn)發(fā)模式將其轉(zhuǎn)化成 iptables 或 ipvs 規(guī)則并寫到節(jié)點(diǎn)上；

集群內(nèi)的 client 去訪問 Service (Cluster IP)，會(huì)被 iptable/ipvs 規(guī)則負(fù)載均衡到 Service 對(duì)應(yīng)的后端 pod。

轉(zhuǎn)發(fā)模式對(duì)比：

ipvs 模式性能更高，但也存在一些已知未解決的 bug；

iptables 模式更成熟穩(wěn)定。

選型建議：

對(duì)穩(wěn)定性要求極高且 service 數(shù)量小于 2000，選 iptables；

其余場(chǎng)景首選 ipvs。

集群類型: 托管集群 vs 獨(dú)立集群

托管集群:

Master 組件用戶不可見，由騰訊云托管

很多新功能也是會(huì)率先支持托管的集群

Master 的計(jì)算資源會(huì)根據(jù)集群規(guī)模自動(dòng)擴(kuò)容

用戶不需要為 Master 付費(fèi)

獨(dú)立集群:

Master 組件用戶可以完全掌控

用戶需要為 Master 付費(fèi)購(gòu)買機(jī)器

選型建議:

一般推薦托管集群

如果希望能能夠?qū)?Master 完全掌控，可以使用獨(dú)立集群 (比如對(duì) Master 進(jìn)行個(gè)性化定制實(shí)現(xiàn)高級(jí)功能)

節(jié)點(diǎn)操作系統(tǒng)

TKE 主要支持 Ubuntu 和 CentOS 兩類發(fā)行版，帶 “TKE-Optimized” 后綴用的是 TKE 定制優(yōu)化版的內(nèi)核，其它的是 linux 社區(qū)官方開源內(nèi)核:

TKE-Optimized 的優(yōu)勢(shì):

基于內(nèi)核社區(qū)長(zhǎng)期支持的 4.14.105 版本定制

針對(duì)容器和云場(chǎng)景進(jìn)行優(yōu)化

計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)子系統(tǒng)均經(jīng)過性能優(yōu)化

對(duì)內(nèi)核缺陷修復(fù)支持較好

完全開源：https://github.com/Tencent/TencentOS-kernel

選型建議:

推薦 “TKE-Optimized”，穩(wěn)定性和技術(shù)支持都比較好

如果需要更高版本內(nèi)核，選非 “TKE-Optimized”版本的操作系統(tǒng)

節(jié)點(diǎn)池

此特性當(dāng)前正在灰度中，可申請(qǐng)開白名單使用。主要可用于批量管理節(jié)點(diǎn)：

節(jié)點(diǎn) Label 與 Taint

節(jié)點(diǎn)組件啟動(dòng)參數(shù)

節(jié)點(diǎn)自定義啟動(dòng)腳本

操作系統(tǒng)與運(yùn)行時(shí) (暫未支持)

產(chǎn)品文檔：https://cloud.tencent.com/document/product/457/43719

適用場(chǎng)景:

異構(gòu)節(jié)點(diǎn)分組管理，減少管理成本

讓集群更好支持復(fù)雜的調(diào)度規(guī)則 (Label, Taint)

頻繁擴(kuò)縮容節(jié)點(diǎn)，減少操作成本

節(jié)點(diǎn)日常維護(hù)(版本升級(jí))

用法舉例:

部分IO密集型業(yè)務(wù)需要高IO機(jī)型，為其創(chuàng)建一個(gè)節(jié)點(diǎn)池，配置機(jī)型并統(tǒng)一設(shè)置節(jié)點(diǎn) Label 與 Taint，然后將 IO 密集型業(yè)務(wù)配置親和性，選中 Label，使其調(diào)度到高 IO 機(jī)型的節(jié)點(diǎn) (Taint 可以避免其它業(yè)務(wù) Pod 調(diào)度上來)。

隨著時(shí)間的推移，業(yè)務(wù)量快速上升，該 IO 密集型業(yè)務(wù)也需要更多的計(jì)算資源，在業(yè)務(wù)高峰時(shí)段，HPA 功能自動(dòng)為該業(yè)務(wù)擴(kuò)容了 Pod，而節(jié)點(diǎn)計(jì)算資源不夠用，這時(shí)節(jié)點(diǎn)池的自動(dòng)伸縮功能自動(dòng)擴(kuò)容了節(jié)點(diǎn)，扛住了流量高峰。

啟動(dòng)腳本

組件自定義參數(shù)

此特性當(dāng)前也正在灰度中，可申請(qǐng)開白名單使用。

創(chuàng)建集群時(shí)，可在集群信息界面“高級(jí)設(shè)置”中自定義 Master 組件部分啟動(dòng)參數(shù)：

添加節(jié)點(diǎn)時(shí)，可在云服務(wù)器配置界面的“高級(jí)設(shè)置”中自定義 kubelet 部分啟動(dòng)參數(shù)：

節(jié)點(diǎn)啟動(dòng)配置

新建集群時(shí)，可在云服務(wù)器配置界面的“節(jié)點(diǎn)啟動(dòng)配置”選項(xiàng)處添加節(jié)點(diǎn)啟動(dòng)腳本：

添加節(jié)點(diǎn)時(shí)，可在云服務(wù)器配置界面的“高級(jí)設(shè)置”中通過自定義數(shù)據(jù)配置節(jié)點(diǎn)啟動(dòng)腳本 (可用于修改組件啟動(dòng)參數(shù)、內(nèi)核參數(shù)等):