一、節(jié)點配額和內核參數(shù)調整

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

• 虛擬機個數(shù)

• vCPU 個數(shù)

• 內網 IP 地址個數(shù)

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

• 安全組條數(shù)

• 路由表條數(shù)

• 持久化存儲大小

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

• 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ù)量， 一般如果遇到文件句柄達到上限時，會碰到"Too many open files"或者Socket/File: Can’t open so many files等錯誤。
fs.file-max=1000000


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


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


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


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


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


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


# 關于conntrack的詳細說明：https://testerhome.com/topics/7509


# 默認值: 128 指定了每一個real user ID可創(chuàng)建的inotify instatnces的數(shù)量上限
fs.inotify.max_user_instances=524288


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

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

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

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

etcd operator 有如下特性：

• ceate/destroy: 自動部署和刪除 etcd 集群，不需要人額外干預配置。
• resize：可以動態(tài)實現(xiàn) etcd 集群的擴縮容。
• backup：支持etcd集群的數(shù)據(jù)備份和集群恢復重建
• upgrade：可以實現(xiàn)在升級etcd集群時不中斷服務。

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

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

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

四、Kube APIServer 配置

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

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

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

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

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

--target-ram-mb=node_nums * 60

五、Pod 配置

在運行 Pod 的時候也需要注意遵循一些最佳實踐，比如:

1、為容器設置資源請求和限制，尤其是一些基礎插件服務

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

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

2、對關鍵應用使用 nodeAffinity、podAffinity 和 podAntiAffinity 等保護，使其調度分散到不同的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 配置

設置 --kube-api-qps=100 默認值是 50
Kube-controller-manager 配置

設置 --kube-api-qps=100 默認值是20
設置 --kube-api-burst=100 默認值是30

審核編輯 ：李倩