## Kubernetes 版本

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

## 網路模式: GlobalRouter vs VPC-CNI

**GlobalRouter 模式架構:**

![](https://main.qcloudimg.com/raw/2736412841a6cab7afa61074d61cb423.jpg)

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

**VPC-CNI 模式架構:**

![](https://main.qcloudimg.com/raw/acf14e42ef058942b209436316abb515.jpg)

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

**網路模式對比:**

![](https://main.qcloudimg.com/raw/4c7f6b4a20d62b9015bce5493a975190.jpg)

**支援三種使用方式：**

- 建立叢集時指定 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 作為執行時的架構：**

![](https://main.qcloudimg.com/raw/020cb53a364ecb854ce62ef7a9aef8ae.jpg)

- 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 作為執行時的架構：**

![](https://main.qcloudimg.com/raw/f6c45104d533710c536784abcd40466f.jpg)

- 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 的轉發原理：

![](https://main.qcloudimg.com/raw/08b029c63b29551716923a73afc9d77f.jpg)

- 節點上的 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](https://main.qcloudimg.com/raw/2e49fc5ef2b8dd0d28f553818c597b91.jpg)

![img](https://main.qcloudimg.com/raw/71af533b8c36ae4eb7ef139da18aaeaa.png)

**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](https://main.qcloudimg.com/raw/2347a3880101c7adf1227a2e6b49a90d.jpg)

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

![img](https://main.qcloudimg.com/raw/ecdfc11072b8572f0998ff17d60ec4bf.jpg)

**節點啟動配置**

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

![](https://main.qcloudimg.com/raw/0d6646ad21e26ceb4aaa52c266bb51cf.png)

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

![](https://main.qcloudimg.com/raw/a3de6a52ad97d3f39c6538661546f13c.png)

TKE 叢集組建最佳實踐

相關文章