k8s集群优化

最新推荐文章于 2025-05-08 20:16:08 发布
转载 最新推荐文章于 2025-05-08 20:16:08 发布 · 395 阅读 · 1
文章标签：

#kubernetes

1、内核参数调化

1.1、增大内核选项配置 /etc/sysctl.conf

fs.file-max=1000000
# max-file 表示系统级别的能够打开的文件句柄的数量， 一般如果遇到文件句柄达到上限时，会碰到
# "Too many open files"或者Socket/File: Can’t open so many files等错误。
# 配置arp cache 大小
net.ipv4.neigh.default.gc_thresh1=1024
# 存在于ARP高速缓存中的最少层数，如果少于这个数，垃圾收集器将不会运行。缺省值是128。
net.ipv4.neigh.default.gc_thresh2=4096
# 保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前，允许记录数超过这个数字 5 秒。缺省值是 512。
net.ipv4.neigh.default.gc_thresh3=8192
# 保存在 ARP 高速缓存中的最多记录的硬限制，一旦高速缓存中的数目高于此，垃圾收集器将马上运行。缺省值是1024。
# 以上三个参数，当内核维护的arp表过于庞大时候，可以考虑优化
net.netfilter.nf_conntrack_max=10485760
# 允许的最大跟踪连接条目，是在内核内存中netfilter可以同时处理的“任务”(连接跟踪条目)
net.netfilter.nf_conntrack_tcp_timeout_established=300
net.netfilter.nf_conntrack_buckets=655360
# 哈希表大小(只读)(64位系统、8G内存默认 65536，16G翻倍，如此类推)
net.core.netdev_max_backlog=10000
# 每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
fs.inotify.max_user_instances=524288
# 默认值: 128 指定了每一个real user ID可创建的inotify instatnces的数量上限
fs.inotify.max_user_watches=524288
# 默认值: 8192 指定了每个inotify instance相关联的watches的上限

1.2、其他的内核参数

net.ipv4.tcp_keepalive_time=600
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=10
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1
net.ipv4.neigh.default.gc_stale_time=120
net.ipv4.conf.all.rp_filter=0 
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.arp_announce=2
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_announce=2
net.ipv4.ip_local_port_range= 45001 65000
net.ipv4.ip_forward=1
net.ipv4.tcp_max_tw_buckets=6000
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_synack_retries=2
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
net.netfilter.nf_conntrack_max=2310720
net.ipv6.neigh.default.gc_thresh1=8192
net.ipv6.neigh.default.gc_thresh2=32768
net.ipv6.neigh.default.gc_thresh3=65536
net.core.netdev_max_backlog=16384
net.core.rmem_max = 16777216 
net.core.wmem_max = 16777216
net.ipv4.tcp_max_syn_backlog = 8096 
net.core.somaxconn = 32768 
fs.inotify.max_user_instances=8192 
fs.inotify.max_user_watches=524288 
fs.file-max=52706963
fs.nr_open=52706963
kernel.pid_max = 4194303
net.bridge.bridge-nf-call-arptables=1
vm.swappiness=0 
vm.overcommit_memory=1 
vm.panic_on_oom=0 
vm.max_map_count = 262144

详解：
net.ipv4.tcp_keepalive_time=600 #此参数表示TCP发送keepalive探测消息的间隔时间(秒)
net.ipv4.tcp_keepalive_intvl=30 #tcp检查间隔时间（keepalive探测包的发送间隔）
net.ipv4.tcp_keepalive_probes=10  #tcp检查次数（如果对方不予应答，探测包的发送次数）
net.ipv6.conf.all.disable_ipv6=1 #禁用IPv6，修为0为启用IPv6
net.ipv6.conf.default.disable_ipv6=1 #禁用IPv6，修为0为启用IPv6
net.ipv6.conf.lo.disable_ipv6=1 #禁用IPv6，修为0为启用IPv6
net.ipv4.neigh.default.gc_stale_time=120 #ARP缓存条目超时
net.ipv4.conf.all.rp_filter=0  #默认为1，系统会严格校验数据包的反向路径，可能导致丢包
net.ipv4.conf.default.rp_filter=0 #不开启源地址校验
net.ipv4.conf.default.arp_announce=2 #始终使用与目的IP地址对应的最佳本地IP地址作为ARP请求的源IP地址
net.ipv4.conf.lo.arp_announce=2 #始终使用与目的IP地址对应的最佳本地IP地址作为ARP请求的源IP地址
net.ipv4.conf.all.arp_announce=2 #始终使用与目的IP地址对应的最佳本地IP地址作为ARP请求的源IP地址
net.ipv4.ip_local_port_range= 45001 65000 # 定义网络连接可用作其源（本地）端口的最小和最大端口的限制，同时适用于TCP和UDP连接。
net.ipv4.ip_forward=1 # 其值为0,说明禁止进行IP转发；如果是1,则说明IP转发功能已经打开。
net.ipv4.tcp_max_tw_buckets=6000 #配置服务器 TIME_WAIT 数量
net.ipv4.tcp_syncookies=1 #此参数应该设置为1，防止SYN Flood
net.ipv4.tcp_synack_retries=2 #表示回应第二个握手包（SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包），进行重试的次数（默认为5）
net.bridge.bridge-nf-call-ip6tables=1 # 是否在ip6tables链中过滤IPv6包
net.bridge.bridge-nf-call-iptables=1 # 二层的网桥在转发包时也会被iptables的FORWARD规则所过滤，这样有时会出现L3层的iptables rules去过滤L2的帧的问题
net.netfilter.nf_conntrack_max=2310720 #连接跟踪表的大小，建议根据内存计算该值CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32)，并满足nf_conntrack_max=4*nf_conntrack_buckets，默认262144
 
net.ipv6.neigh.default.gc_thresh1=8192
net.ipv6.neigh.default.gc_thresh2=32768
net.ipv6.neigh.default.gc_thresh3=65536
 
#gc_thresh3 是表大小的绝对限制
#gc_thresh2 设置为等于系统的最大预期邻居条目数的值
#在这种情况下，gc_thresh3 应该设置为一个比 gc_thresh2 值高的值，例如，比 gc_thresh2 高 25%-50%，将其视为浪涌容量。
#gc_thresh1 提高到较大的值；此设置的作用是，如果表包含的条目少于 gc_thresh1，内核将永远不会删除（超时）过时的条目。
 
net.core.netdev_max_backlog=16384 # 每CPU网络设备积压队列长度
net.core.rmem_max = 16777216 # 所有协议类型读写的缓存区大小
net.core.wmem_max = 16777216 # 最大的TCP数据发送窗口大小
net.ipv4.tcp_max_syn_backlog = 8096 # 第一个积压队列长度
net.core.somaxconn = 32768 # 第二个积压队列长度
fs.inotify.max_user_instances=8192 # 表示每一个real user ID可创建的inotify instatnces的数量上限，默认128.
fs.inotify.max_user_watches=524288 # 同一用户同时可以添加的watch数目，默认8192。
fs.file-max=52706963 # 文件描述符的最大值
fs.nr_open=52706963 #设置最大微博号打开数
kernel.pid_max = 4194303 #最大进程数
net.bridge.bridge-nf-call-arptables=1 #是否在arptables的FORWARD中过滤网桥的ARP包
vm.swappiness=0 # 禁止使用 swap 空间，只有当系统 OOM 时才允许使用它
vm.overcommit_memory=1 # 不检查物理内存是否够用
vm.panic_on_oom=0 # 开启 OOM
vm.max_map_count = 262144

2、etcd性能优化

2.1、磁盘

Etcd对磁盘写入延迟非常敏感，因此对于负载较重的集群，etcd一定要使用local SSD或者高性能云盘。可以使用fio测量磁盘实际顺序 IOPS。

fio -filename=/dev/sda1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=60G -numjobs=64 -runtime=10 -group_reporting -name=file
2.2、进程优先级

由于etcd必须将数据持久保存到磁盘日志文件中，因此来自其他进程的磁盘活动可能会导致增加写入时间，结果导致etcd请求超时和临时leader丢失。因此可以给etcd进程更高的磁盘优先级，使etcd服务可以稳定地与这些进程一起运行。

ionice -c2 -n0 -p $(pgrep etcd)

2.3、增大etcd的存储限制

默认etcd空间配额大小为 2G，超过 2G 将不再写入数据。通过给etcd配置 --quota-backend-bytes 参数增大空间配额，最大支持 8G。

--quota-backend-bytes 8589934592

2.4、提高etcd对于对等网络流量优先级

如果etcd leader处理大量并发客户端请求，可能由于网络拥塞而延迟处理follower对等请求。在follower 节点上可能会产生如下的发送缓冲区错误的消息：

dropped MsgProp to 247ae21ff9436b2d since streamMsg's sending buffer is full
dropped MsgAppResp to 247ae21ff9436b2d since streamMsg's sending buffer is full

可以通过提高etcd对于对等网络流量优先级来解决这些错误。在 Linux 上，可以使用 tc 对对等流量进行优先级排序：

tc qdisc add dev eth0 root handle 1: prio bands 3
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip sport 2380 0xffff flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport 2380 0xffff flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip sport 2379 0xffff flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip dport 2379 0xffff flowid 1:1

2.5、其他

为了在大规模集群下提高性能，可以将events存储在单独的 ETCD 实例中，可以配置kube-apiserver参数：

–etcd-servers=“http://etcd1:2379,http://etcd2:2379,http://etcd3:2379”
–etcd-servers-overrides=“/events#http://etcd4:2379,http://etcd5:2379,http://etcd6:2379”

key的历史记录压缩 ETCD 会存储多版本数据，随着写入的主键增加，历史版本将会越来越多，并且 ETCD 默认不会自动清理历史数据。数据达到 –quota-backend-bytes 设置的配额值时就无法写入数据，必须要压缩并清理历史数据才能继续写入。

--auto-compaction-mode
--auto-compaction-retention

所以，为了避免配额空间耗尽的问题，在创建集群时候建议默认开启历史版本清理功能。

3.3.0 之前的版本，只能按周期 periodic 来压缩。比如设置 –auto-compaction-retention=72h，那么就会每 72 小时进行一次数据压缩。
3.3.0 之后的版本，可以通过 –auto-compaction-mode 设置压缩模式，可以选择 revision 或者 periodic 来压缩数据，默认为 periodic。

3、docker优化

3.1、配置docker daemon并行拉取镜像，以提高镜像拉取效率

配置docker daemon并行拉取镜像，以提高镜像拉取效率，在/etc/docker/daemon.json中添加以下配置：

"max-concurrent-downloads": 10
3.2、使用local SSD或者高性能云盘作为docker容器的持久数据目录

可以使用local SSD或者高性能云盘作为docker容器的持久数据目录，在/etc/docker/daemon.json中添加以下配置：

"data-root": "/ssd_mount_dir"
3.3、预加载pause镜像

启动pod时都会拉取pause镜像，为了减小拉取pause镜像网络带宽，可以每个node预加载pause镜像，在每个node节点上执行以下命令：

docker load -i /tmp/preloaded_pause_image.tar

4、kubelet优化

4.1、增加并发度

设置 --serialize-image-pulls=false， 该选项配置串行拉取镜像，默认值时true，配置为false可以增加并发度。但是如果docker daemon 版本小于 1.9，且使用 aufs 存储则不能改动该选项。

4.2、配置镜像拉取超时

设置--image-pull-progress-deadline=30， 配置镜像拉取超时。默认值时1分，对于大镜像拉取需要适量增大超时时间。

4.3、单节点允许运行的最大 Pod 数

kubelet 单节点允许运行的最大 Pod 数：--max-pods=110（默认是 110，可以根据实际需要设置）

5、kube-apiserver优化

5.1、高可用优化

设置--apiserver-count和 --endpoint-reconciler-type，可使得多个 kube-apiserver 实例加入到 Kubernetes Service 的 endpoints 中，从而实现高可用。

5.2、node节点数量的优化

设置 --max-requests-inflight 和 --max-mutating-requests-inflight，默认是 200 和 400。 节点数量在 1000 - 3000 之间时，推荐：

--max-requests-inflight=1500
--max-mutating-requests-inflight=500
节点数量大于 3000 时，推荐：

--max-requests-inflight=3000
--max-mutating-requests-inflight=1000
5.3、配置kube-apiserver的内存

使用–target-ram-mb配置kube-apiserver的内存，按以下公式得到一个合理的值：

--target-ram-mb=node_nums * 60

6、kube-controller-manager优化

Controller参数配置

--node-cidr-mask-size # node上的pod cidr掩码位数，默认为24位，即最多253个可用地址，视地址空间和pod数量调整。
--node-monitor-period # 检查当前node健康状态的周期间隔，默认5s
--node-monitor-grace-period # 当前node超过了这个指定周期后，即视node为不健康，进入ConditionUnknown状态，默认40s
--pod-eviction-timeout # 当node进入notReady状态后，经过这个指定时间后，会开始驱逐node上的pod，默认5m
--large-cluster-size-threshold # 判断集群是否为大集群，默认为 50，即 50 个节点以上的集群为大集群。
--unhealthy-zone-threshold：# 故障节点数比例，默认为 55%
--node-eviction-rate # 开始对node进行驱逐操作的频率，默认0.1个/s，即每10s最多驱逐某一个node上的pod，避免当master出现问题时，会有批量的node出现异常，这时候如果一次性驱逐过多的node，对master造成额外的压力
--secondary-node-eviction-rate： # 当集群规模大于large-cluster-size-threshold个node时，视为大集群， 集群中只要有55%的node不健康， 就会认为master出现了故障， 会将驱逐速率从0.1降为0.001； 如果集群规模小于large-cluster-size-threshold个node， 集群中出现55%的node不健康，就会停止驱逐。

6.1、通过 leader election 实现高可用

kube-controller-manager可以通过 leader election 实现高可用，添加以下命令行参数：

--leader-elect=true
--leader-elect-lease-duration=15s
--leader-elect-renew-deadline=10s
--leader-elect-resource-lock=endpoints
--leader-elect-retry-period=2s

6.2、限制与kube-apiserver通信的qps

调大 –kube-api-qps 值：可以调整至 100，默认值为 20
调大 –kube-api-burst 值：可以调整至 150，默认值为 30
禁用不需要的 controller：kubernetes v1.14 中已有 35 个 controller，默认启动为–controllers，即启动所有 controller，可以禁用不需要的 controller
调整 controller 同步资源的周期：避免过多的资源同步导致集群资源的消耗，所有带有 --concurrent 前缀的参数

限制与kube-apiserver通信的qps，添加以下命令行参数：

--kube-api-qps=100
--kube-api-burst=150

7、kube-scheduler优化

7.1、kube-scheduler可以通过 leader election 实现高可用，添加以下命令行参数：

--leader-elect=true
--leader-elect-lease-duration=15s
--leader-elect-renew-deadline=10s
--leader-elect-resource-lock=endpoints
--leader-elect-retry-period=2s

7.2、限制与kube-apiserver通信的qps，添加以下命令行参数：

--kube-api-qps=100
--kube-api-burst=150

8、pod优化

8.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中，会根据pod的limit 和 requests的配置将pod划分为不同的qos类别：

  • Guaranteed
  • Burstable
  • BestEffort
    当机器可用资源不够时，kubelet会根据qos级别划分迁移驱逐pod。被驱逐的优先级：BestEffort > Burstable > Guaranteed。

8.2、对关键应用使用 nodeAffinity、podAffinity 和 podAntiAffinity 等保护，使其调度分散到不同的node上。比如kube-dns配置

8.3、尽量使用控制器来管理容器（如 Deployment、StatefulSet、DaemonSet、Job 等）

9、kubernetes集群数据备份与还原

9.1、etcd数据备份（备份数据前先找到etcd集群当前的leader）

ETCDCTL_API=3 etcdctl --endpoints=127.0.0.1:2379 --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --cacert=/etc/kubernetes/pki/etcd/ca.crt endpoint --cluster status | grep -v 'false' | awk -F '[/ :]' '{print $4}'

然后登录到leader节点，备份snapshot db文件：

rsync -avp /var/lib/etcd/member/snap/db /tmp/etcd_db.bak

还原 将备份的snaphost db文件上传到各个etcd节点，使用以下命令还原数据：

ETCDCTL_API=3 etcdctl snapshot restore \
            /tmp/etcd_db.bak \
            --endpoints=192.168.0.11:2379 \
            --name=192.168.0.11 \
            --cert=/etc/kubernetes/pki/etcd/server.crt \
            --key=/etc/kubernetes/pki/etcd/server.key \
            --cacert=/etc/kubernetes/pki/etcd/ca.crt \
            --initial-advertise-peer-urls=https://192.168.0.11:2380 \
            --initial-cluster-token=etcd-cluster-0 \
            --initial-cluster=192.168.0.11=https://192.168.0.11:2380,192.168.0.12=https://192.168.0.12:2380,192.168.0.13=https://192.168.0.13:2380 \
            --data-dir=/var/lib/etcd/ \
            --skip-hash-check=true

注意:
如果集群中正在运行任何 API 服务器，则不应尝试还原 etcd 的实例。相反，请按照以下步骤还原 etcd：

停止 所有 kube-apiserver 实例
在所有 etcd 实例中恢复状态
重启所有 kube-apiserver 实例

10、harbor

如果使用harbor作为镜像仓库与chart仓库，可使用脚本将harbor中所有的镜像和chart导入导出。

10.1、备份
#!/bin/bash
harborUsername='admin'
harborPassword='Harbor12345'
harborRegistry='registry.test.com'
harborBasicAuthToken=$(echo -n "${harborUsername}:${harborPassword}" | base64)
docker login --username ${harborUsername} --password ${harborPassword} ${harborRegistry}
rm -f dist/images.list
rm -f dist/charts.list
# list projects
projs=`curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}"'/api/projects?page=1&page_size=1000' | jq -r '.[] | "\(.project_id)=\(.name)"'`
for proj in ${projs[*]}; do
  projId=`echo $proj|cut -d '=' -f 1`
  projName=`echo $proj|cut -d '=' -f 2`
  # list repos in one project
  repos=`curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}"'/api/repositories?page=1&page_size=1000&project_id='"${projId}" | jq -r '.[] | "\(.id)=\(.name)"'`
  for repo in ${repos[*]}; do
    repoId=`echo $repo|cut -d '=' -f 1`
    repoName=`echo $repo|cut -d '=' -f 2`
    # list tags in one repo
    tags=`curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}"'/api/repositories/'"${repoName}"'/tags?detail=1' | jq -r '.[].name'`
    for tag in ${tags[*]}; do
      #echo ${tag};
      # pull image
      docker pull ${harborRegistry}/${repoName}:${tag}
      # tag image
      docker tag ${harborRegistry}/${repoName}:${tag} ${repoName}:${tag}
      # save image
      mkdir -p $(dirname dist/${repoName})
      docker save -o dist/${repoName}:${tag}.tar  ${repoName}:${tag}
      # record image to list file
      echo "${repoName}:${tag}" >> dist/images.list
    done
  done
  # list charts in one project
  charts=`curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}"'/api/chartrepo/'"${projName}"'/charts' | jq -r '.[].name'`
  for chart in ${charts[*]}; do
    #echo ${chart}
    # list download urls in one chart
    durls=`curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}"'/api/chartrepo/'"${projName}"'/charts/'"${chart}" | jq -r '.[].urls[0]'`
    #echo ${durl[*]}
    for durl in ${durls[*]}; do
        #echo ${durl};
        # download chart
        mkdir -p $(dirname dist/${projName}/${durl})
        curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" -o dist/${projName}/${durl} "https://${harborRegistry}/chartrepo/${projName}/${durl}"
        # record chart to list file
        echo "${projName}/${durl}" >> dist/charts.list
        
    done
  done
done
10.2、还原
#!/bin/bash
harborUsername='admin'
harborPassword='Harbor12345'
harborRegistry='registry.test.com'
harborBasicAuthToken=$(echo -n "${harborUsername}:${harborPassword}" | base64)
docker login --username ${harborUsername} --password ${harborPassword} ${harborRegistry}
while IFS="" read -r image || [ -n "$image" ]
do
  projName=${image%%/*}
  # echo ${projName}
  # create harbor project
  curl -k -X POST -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}/api/projects" -H "accept: application/json" -H "Content-Type: application/json" -d '{ "project_name": "'"$projName"'", "metadata": { "public": "true" }}'
  # load image
  docker load -i dist/${image}.tar
  # tag image
  docker tag ${image} ${harborRegistry}/${image}
  # push image
  docker push ${harborRegistry}/${image}
done < dist/images.list
while IFS="" read -r chart || [ -n "$chart" ]
do
  projName=${chart%%/*}
  # echo ${projName}
  # create harbor project
  curl -k -X POST -H "Authorization: Basic ${harborBasicAuthToken}" "https://${harborRegistry}/api/projects" -H "accept: application/json" -H "Content-Type: application/json" -d '{ "project_name": "'"$projName"'", "metadata": { "public": "true" }}'
  # upload chart
  curl -s -k -H "Authorization: Basic ${harborBasicAuthToken}" -X POST "https://${harborRegistry}/api/chartrepo/${projName}/charts" -H "accept: application/json" -H "Content-Type: multipart/form-data" -F "chart=@dist/${chart};type=application/gzip"
done < dist/charts.list

11、pvc对应的存储卷

集群中其它应用数据一般是保存在pvc对应的存储卷中的。

11.1、备份

首先根据pvc找到对应的pv：

kubectl -n test get pvc demo-pvc -o jsonpath='{.spec.volumeName}'
找到pv的挂载目录：

mount | grep pvc-xxxxxxxxxxxxxxxxxxx

使用rsync命令备份数据：

rsync -avp --delete /var/lib/kubelet/pods/xxxxxx/volumes/xxxxxxx/ /tmp/pvc-data-bak/test/demo-pvc/

11.2、还原

首先根据pvc找到对应的pv：

kubectl -n test get pvc demo-pvc -o jsonpath='{.spec.volumeName}'
找到pv的挂载目录：

mount | grep pvc-xxxxxxxxxxxxxxxxxxx
使用rsync命令备份数据：

rsync -avp --delete /tmp/pvc-data-bak/test/demo-pvc/ /var/lib/kubelet/pods/xxxxxx/volumes/xxxxxxx/

12、备份数据管理

所有备份出的数据可以存放在一个目录下，并使用restic工具保存到多个后端存储系统上

初始化备份仓库

restic --repo sftp:user@host:/srv/restic-repo init

将目录备份到备份仓库

restic --repo sftp:user@host:/srv/restic-repo backup /data/k8s-all-data

ETCD使用中需要注意的问题--自动压缩--最大字节数--存储数据大小
一名数据库爱好者的专栏
08-19 1456
我们在实际生产中使用ETCD存储元数据，　起初集群规模不大的时候元数据信息不多没有发现什么问题。随着集群规模越来越大问题逐渐暴露了有些实际的配置还是需要在初始化的时候就研究确定。
云原生（二十九） | Kubernetes篇之自建高可用k8s集群优化
Lansonli（蓝深李）的博客
06-24 1671
文章目录自建高可用k8s集群优化一、Docker配置优化二、优化kubelet三、时区问题 可参照官方文档： Kubelet 配置 (v1beta1) | Kubernetes 验证集群kube-proxy使用ipvs模式工作； 10249是每个节点kube-proxy的metrics信息端口，可以访问/proxyMode或者/metrics等 很多应用镜像时区都是UTC，而不是本机时间（当然，前提是本机时间是对的，云服务器不存在这个问题）我们不用每一个Pod都设置挂载本地时间
管理etcd的存储空间配额
weixin_43539320的博客
02-06 859
合理的空间配额管理是etcd集群稳定的基石。预防性容量规划自动化监控告警定期维护操作可以确保etcd集群持续可靠地提供服务。建议结合具体业务场景，制定适合的配额策略和维护计划。官方文档参考：https://etcd.io/docs/v3.4/op-guide/maintenance/#space-quota``
Kubernetes生产实战(八)：集群性能调优指南
最新发布
sre救赎之路
05-08 1150
1）性能调优优先级网络优化 > 存储IO优化 > 资源利用率提升 > 成本优化2）必装工具清单监控：Prometheus + Grafana日志：Loki + Grafana安全：Falco + Trivy成本：kube-cost + Kubecost3）优化迭代流程通过系统化的优化策略，结合持续监控和迭代改进，可使Kubernetes集群在生产环境中实现最佳的性能、安全性和成本效益平衡。
ETCD v3历史数据清理及策略设置
qq_33454695的博客
04-26 1495
每5分钟执行一次：扫描现有key的所有latestVersion。压缩掉 latestVersion- retention之前的所有。每1/10个配置的时间段，执行一次压缩，压缩的数据是1/10个小时计算的。
k8s集群优化配置
weixin_47677347的博客
09-17 314
1、k8s小细节
K8S性能优化(一)-集群调优
sre救赎之路
05-09 2504
因此，运行 10 个 pod 的系统实际上会运行 20 个容器。在安装大型集群或将现有的集群扩展到较大规模时，在安装集群设置集群网络 cidr 时，如果集群的节点数超过 500 个，则可能无法使用常用的集群网络 cidr。根据节点中的处理器内核数来设置节点可运行的 pod 数量。当两个参数都被设置时，其中较小的值限制了节点上的 pod 数量。把节点可以运行的 pod 数量设置为一个固定值，而不需要考虑节点的属性。设为 10 ，则该节点上允许的最大 pod 数量为 40。，以支持超过 500 个节点的环境。
K8s 集群稳定性评估与大规模基础服务部署调优
http://www.54tianzhisheng.cn/
05-24 1072
【云原生】一文细数kubernetes常见20道问题彻底搞懂 K8S Pod Pending 故障原因及解决方案Kubernetes 架构核心点详细总结！顶级的Kubernetes日志监控工具Kubernetes 集群需要重点关注的 6 个指标如何优雅的限制 Kubernetes 节点上运行的 Pod 数量容器与Pod到底有什么区别和联系？如何调试Kubernetes集群...
K8S云平台环境调优说明
数通畅联
09-05 1931
随着云计算技术的不断发展，在信息化建设模式上上云是大势所趋。在搭建完云平台环境后，常需要对服务器及部署产品进行优化处理，本文主要介绍K8S部署成功后环境调优的配置步骤。
k8s集群优化之监控平台的建立-运维进阶.docx
10-24
### k8s集群优化之监控平台的建立 #### 监控平台建设 为了实现Kubernetes集群的有效运维，首要任务之一便是构建一个稳定的监控平台。监控平台不仅能够帮助我们实时掌握集群的状态，还能够辅助我们发现潜在的问题，...
K8s kubernetes 系统初始化脚本，一键安装部署基础环境，安装依赖包，针对k8s优化的内核参数，升级内核
08-06
2.1 设置主机名和hosts文件解析 2.2 安装依赖包 2.3 设置防火墙为 Iptables 并设置空规则 2.4 关闭 SELINUX 2.5 调整内核参数，对于 K8S 2.6 调整系统时区 2.7 关闭系统不需要服务 2.8 设置 rsyslogd 和 systemd journald 2.9 升级系统内核为 4.44 一键shell脚本
promethues（普罗米修斯）监控k8s集群-详细文档
06-19
Prometheus 是一个流行的开源监控系统和时间序列数据库，它被广泛用于监视各种应用程序和服务，包括 Kubernetes (k8s) 集群。本详细文档将介绍如何使用 Prometheus 监控 k8s 集群，并结合 Alertmanager 实现报警功能...
K8S集群设计、部署、维护、优化
我是赛博AI Lewis
04-23 721
K8S集群设计、部署、维护、优化。
K8S实战之部署java应用
weixin_43546282的博客
01-14 1448
kubernetes基本概念 Pod: 1.最小的部署单元， 2.一组容器的集合 3.一个pod中的容器共享网络命名空间 4.生命周期是短暂的 Controllers: 1.Deployment:部署无状态应用 2.Statefulset:部署有状态应用 3.Replicaset：确保预期的Pod副本数量 4.Daemonset: 确保node运行同一个pod 5.Job：一次性任务 6.Cronjob:定时任务 更高级层次对象，部署和管理pod Service: 防止Pod失联，找到你需要Pod 定义
Kubernetes中Java应用Heap Dump
勿忘初心
02-07 2171
伴随着微服务及容器化的发展，越来越多的应用运行在kubernetes集群中，运维、调试的问题也随之而来。以Java为例，当线上环境出现内存问题，比如OOM，这时候需要Dump内存进行分析的时候，就会发现对于普通开发人员来说他们没有操作kubernetes集群机器的权限，从而导致，Dump出来的文件无法回传到开发手中进行MAT之类的分析。 本文的解决办法是这样的，当用户需要Dump某个应用实例的时候，只需要在实例终端界面点击一下按钮，后台会自动Dump Heap到OSS上，上传完成后，会将下载的信息展示在列表
k8s pod 生成 java dump文件方法
运维那些事儿
04-19 3459
k8s生成java dump文件
在k8s下坑人的OOM问题
a807719447的专栏
03-11 3289
最近测试提了个bug，说批量图片上传会返回500错误。然后我弄了两个zip压缩包一个3MB，一个120MB，发现3MB的压缩包每次上传都没问题，而120MB的每次上传都会报500，于是上spring cloud gateway网关查看了下日志，发现网关报了一个莫名奇妙的错误 Connection prematurely closed BEFORE response 意思为连接在响应前过早关闭了。显得莫名奇妙，然后拿着这个报错百度google了一番，没找到答案，于是换个方向。小文件没有问题，而大文件出问题，
etcd 配置优化
IT老男孩
09-04 5368
本文永久链接: https://www.xtplayer.cn/etcd/etcd-optimize/注意： 以下操作中所指的 K8S 集群，均是 rancher 或者 rke 创建的集群。存储空间配额--quota-backend-bytes存储空间配额可以理解为 ETCD 数据库大小，默认限制 2G(推荐最大 8G)。当数据写入耗尽存储空间时，ETCD 会引发整个集群范围的警告，该警告将会导致...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值