看看這5個維度是如何優(yōu)化Kubernetes集群的

一、節(jié)點(diǎn)配額和內(nèi)核參數(shù)調(diào)整

對于公有云上的 Kubernetes 集群，規(guī)模大了之后很容器碰到配額問題，需要提前在云平臺上增大配額。這些需要增大的配額包括：

• 虛擬機(jī)個數(shù)

• vCPU 個數(shù)

• 內(nèi)網(wǎng) IP 地址個數(shù)

• 公網(wǎng) IP 地址個數(shù)

• 安全組條數(shù)

• 路由表條數(shù)

• 持久化存儲大小

參考gce隨著node節(jié)點(diǎn)的增加master節(jié)點(diǎn)的配置：

• 1-5 nodes: n1-standard-1

• 6-10 nodes: n1-standard-2

• 11-100 nodes: n1-standard-4

• 101-250 nodes: n1-standard-8

• 251-500 nodes: n1-standard-16

• more than 500 nodes: n1-standard-32

參考阿里云配置：

# max-file 表示系統(tǒng)級別的能夠打開的文件句柄的數(shù)量，一般如果遇到文件句柄達(dá)到上限時，會碰到"Too many open files"或者Socket/File: Can’t open so many files等錯誤。
fs.file-max=1000000

#配置arpcache大小
net.ipv4.neigh.default.gc_thresh1=1024
#存在于ARP高速緩存中的最少層數(shù)，如果少于這個數(shù)，垃圾收集器將不會運(yùn)行。缺省值是128。

#保存在 ARP 高速緩存中的最多的記錄軟限制。垃圾收集器在開始收集前，允許記錄數(shù)超過這個數(shù)字 5 秒。缺省值是 512。
net.ipv4.neigh.default.gc_thresh2=4096

#保存在 ARP 高速緩存中的最多記錄的硬限制，一旦高速緩存中的數(shù)目高于此，垃圾收集器將馬上運(yùn)行。缺省值是1024。
net.ipv4.neigh.default.gc_thresh3=8192

#以上三個參數(shù)，當(dāng)內(nèi)核維護(hù)的arp表過于龐大時候，可以考慮優(yōu)化

#允許的最大跟蹤連接條目，是在內(nèi)核內(nèi)存中netfilter可以同時處理的“任務(wù)”（連接跟蹤條目）
net.netfilter.nf_conntrack_max=10485760

#哈希表大小（只讀）（64位系統(tǒng)、8G內(nèi)存默認(rèn)65536，16G翻倍，如此類推）
net.core.netdev_max_backlog=10000
#每個網(wǎng)絡(luò)接口接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時，允許送到隊列的數(shù)據(jù)包的最大數(shù)目。
net.netfilter.nf_conntrack_tcp_timeout_established=300
net.netfilter.nf_conntrack_buckets=655360

#關(guān)于conntrack的詳細(xì)說明：https://testerhome.com/topics/7509

#默認(rèn)值:128指定了每一個realuserID可創(chuàng)建的inotifyinstatnces的數(shù)量上限
fs.inotify.max_user_instances=524288

#默認(rèn)值:8192指定了每個inotifyinstance相關(guān)聯(lián)的watches的上限
fs.inotify.max_user_watches=524288

二、Etcd 數(shù)據(jù)庫

1、搭建高可用的etcd集群，集群規(guī)模增大時可以自動增加etcd節(jié)點(diǎn)；

目前的解決方案是使用etcd operator來搭建etcd 集群，operator是CoreOS推出的旨在簡化復(fù)雜有狀態(tài)應(yīng)用管理的框架，它是一個感知應(yīng)用狀態(tài)的控制器，通過擴(kuò)展Kubernetes API來自動創(chuàng)建、管理和配置應(yīng)用實(shí)例。

etcd operator 有如下特性：

• ceate/destroy: 自動部署和刪除 etcd 集群，不需要人額外干預(yù)配置。

• resize：可以動態(tài)實(shí)現(xiàn) etcd 集群的擴(kuò)縮容。

• backup：支持etcd集群的數(shù)據(jù)備份和集群恢復(fù)重建

• upgrade：可以實(shí)現(xiàn)在升級etcd集群時不中斷服務(wù)。

2、配置etcd使用ssd固態(tài)盤存儲；

3、設(shè)置 —quota-backend-bytes 增大etcd的存儲限制。默認(rèn)值是 2G；

4、需要配置單獨(dú)的 Etcd 集群存儲 kube-apiserver 的 event。

三、Kube APIServer 配置

node節(jié)點(diǎn)數(shù)量 >= 3000， 推薦設(shè)置如下配置：

--max-requests-inflight=3000
--max-mutating-requests-inflight=1000

node節(jié)點(diǎn)數(shù)量在 1000 — 3000， 推薦設(shè)置如下配置：

--max-requests-inflight=1500
--max-mutating-requests-inflight=500

內(nèi)存配置選項和node數(shù)量的關(guān)系，單位是MB：

--target-ram-mb=node_nums*60

四、Pod 配置

在運(yùn)行 Pod 的時候也需要注意遵循一些最佳實(shí)踐，比如:

1、為容器設(shè)置資源請求和限制，尤其是一些基礎(chǔ)插件服務(wù)

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.limits.ephemeral-storage
spec.containers[].resources.requests.ephemeral-storage

在k8s中，會根據(jù)pod不同的limit 和 requests的配置將pod劃分為不同的qos類別：

• Guaranteed

• Burstable

• BestEffort

當(dāng)機(jī)器可用資源不夠時，kubelet會根據(jù)qos級別劃分遷移驅(qū)逐pod。被驅(qū)逐的優(yōu)先級：BestEffort > Burstable > Guaranteed

2、對關(guān)鍵應(yīng)用使用 nodeAffinity、podAffinity 和 podAntiAffinity 等保護(hù)，使其調(diào)度分散到不同的node上。比如kube-dns 配置：

affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
-weight:100
labelSelector:
matchExpressions:
-key:k8s-app
operator:In
values:
-kube-dns
topologyKey:kubernetes.io/hostname

3、盡量使用控制器來管理容器（如 Deployment、StatefulSet、DaemonSet、Job 等）Kube-scheduler 配置

設(shè)置 —kube-api-qps=100 默認(rèn)值是 50Kube-controller-manager 配置

設(shè)置 —kube-api-qps=100 默認(rèn)值是20設(shè)置 —kube-api-burst=100 默認(rèn)值是30

作者：薛海山https://www.jianshu.com/p/e9fcc1a9eea