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 社區官方開源內核:
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，而節點計算資源不夠用，這時節點池的自動伸縮功能自動擴容了節點，扛住了流量高峰，
啟動腳本
組件自定義引數
此特性當前也正在灰度中，可申請開白名單使用，
- 創建集群時，可在集群資訊界面“高級設定”中自定義 Master 組件部分啟動引數：
- 添加節點時，可在云服務器配置界面的“高級設定”中自定義 kubelet 部分啟動引數：
節點啟動配置
- 新建集群時，可在云服務器配置界面的“節點啟動配置”選項處添加節點啟動腳本：
- 添加節點時，可在云服務器配置界面的“高級設定”中通過自定義資料配置節點啟動腳本 (可用于修改組件啟動引數、內核引數等):
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/111816.html
標籤：其他
上一篇：鴻蒙內核原始碼分析(調度機制篇)