淮南服装网站建设费用,做网站域名的成本,竞价托管代运营多少钱,21天网站建设实录目录 前期环境优化 1.永久关闭交换分区 2.#加载 ip_vs 模块 3.调整内核参数 4.#使用Systemd管理的Cgroup来进行资源控制与管理 5.开机自启kubelet 6.内核参数优化方案 7.etcd优化 默认etcd空间配额大小为 2G#xff0c;超过 2G 将不再写入数据。通过给etcd配置 --quo…目录 前期环境优化 1.永久关闭交换分区 2.#加载 ip_vs 模块 3.调整内核参数 4.#使用Systemd管理的Cgroup来进行资源控制与管理 5.开机自启kubelet 6.内核参数优化方案 7.etcd优化 默认etcd空间配额大小为 2G超过 2G 将不再写入数据。通过给etcd配置 --quota-backend-bytes 参数增大空间配额最大支持 8G --quota-backend-bytes 8589934592 | header  7.2.提高etcd对于对等网络流量优先级 7.3.etcd被设计用于元数据的小键值对的处理。 7.4.etcd的备份 8.kubelet优化 8.1增加并发度 8.2.配置镜像拉取超时 8.3.单节点允许运行的最大 Pod 数 9.kube-apiserver优化 9.1.配置kube-apiserver的内存 10.kube-controller-manager优化 10.1.Controller参数配置 10.2.可通过 leader election 实现高可用 10.3.限制与kube-apiserver通信的qps 11.kube-scheduler优化 12.kube-proxy优化 13.pod优化 13.1.为容器设置资源请求和限制 14.如何设置k8s节点的CPU限制 验证 1k8s dashboard验证 2. 使用kubectl top命令验证在Node所在的集群上运行以下命令 前期环境优化 1.永久关闭交换分区 sed -ri s/.*swap.*/#/ /etc/fstab 2.#加载 ip_vs 模块 for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o ^[^.]*);do echo $i; /sbin/modinfo -F filename $i /dev/null 21 /sbin/modprobe $i;done 3.调整内核参数 cat /etc/sysctl.d/kubernetes.conf EOF #开启网桥模式可将网桥的流量传递给iptables链 net.bridge.bridge-nf-call-ip6tables1 net.bridge.bridge-nf-call-iptables1 #关闭ipv6协议 net.ipv6.conf.all.disable_ipv61 net.ipv4.ip_forward1 EOF //生效参数 sysctl --system  4.#使用Systemd管理的Cgroup来进行资源控制与管理 因为相对Cgroupfs而言Systemd限制CPU、内存等资源更加简单和成熟稳定。 #日志使用json-file格式类型存储大小为100M保存在/var/log/containers目录下方便ELK等日志系统收集和管理日志。配置好这里改成500M mkdir /etc/docker cat /etc/docker/daemon.json EOF {   registry-mirrors: [https://6ijb8ubo.mirror.aliyuncs.com],   exec-opts: [native.cgroupdriversystemd],   log-driver: json-file,   log-opts: {     max-size: 100m   } } EOF systemctl daemon-reload systemctl restart docker.service systemctl enable docker.service     开机自启 5.开机自启kubelet systemctl enable kubelet.service #K8S通过kubeadm安装出来以后都是以Pod方式存在即底层是以容器方式运行所以kubelet必须设置开机自启 6.内核参数优化方案 cat /etc/sysctl.d/kubernetes.conf EOF net.bridge.bridge-nf-call-iptables1 net.bridge.bridge-nf-call-ip6tables1 net.ipv4.ip_forward1 net.ipv4.tcp_tw_recycle0 vm.swappiness0                                    #禁止使用 swap 空间只有当系统内存不足OOM时才允许使用它 vm.overcommit_memory1                            #不检查物理内存是否够用 vm.panic_on_oom0                                #开启 OOM fs.inotify.max_user_instances8192 fs.inotify.max_user_watches1048576 fs.file-max52706963        ##指定最大文件句柄数 fs.nr_open52706963        #最大打数                     net.ipv6.conf.all.disable_ipv61 net.netfilter.nf_conntrack_max2310720 EOF 补充#gc_thresh1 提高到较大的值此设置的作用是如果表包含的条目少于 gc_thresh1内核将永远不会删除超时过时的条目。   net.core.netdev_max_backlog16384 # 每CPU网络设备积压队列长度 net.core.rmem_max 16777216 # 所有协议类型读写的缓存区大小 net.core.wmem_max 16777216 # 最大的TCP数据发送窗口大小 kernel.pid_max 4194303 #最大进程数 vm.max_map_count 262144 7.etcd优化 7.1.增大etcd的存储限制 默认etcd空间配额大小为 2G超过 2G 将不再写入数据。通过给etcd配置 --quota-backend-bytes 参数增大空间配额最大支持 8G  --quota-backend-bytes 8589934592 | header  7.2.提高etcd对于对等网络流量优先级 如果etcd leader处理大量并发客户端请求可能由于网络拥塞而延迟处理follower对等请求。在follower 节点上可能会产生如下的发送缓冲区错误的消息 dropped MsgProp to 247ae21ff9436b2d since streamMsgs sending buffer is full dropped MsgAppResp to 247ae21ff9436b2d since streamMsgs sending buffer is full 7.3.etcd被设计用于元数据的小键值对的处理。 较大的请求将工作的同时可能会增加其他请求的延迟。默认情况下任何请求的最大大小为1.5 MiB。这个限制可以通过–max-request-bytesetcd服务器的标志来配置。 key的历史记录压缩 ETCD 会存储多版本数据随着写入的主键增加历史版本将会越来越多并且 ETCD 默认不会自动清理历史数据。数据达到 –quota-backend-bytes 设置的配额值时就无法写入数据必须要压缩并清理历史数据才能继续写入。 --auto-compaction-mode --auto-compaction-retention 所以为了避免配额空间耗尽的问题在创建集群时候建议默认开启历史版本清理功能。 7.4.etcd的备份 所有 Kubernetes 对象都存储在 etcd 上。定期备份 etcd 集群数据对于在灾难场景例如丢失所有主节点下恢复 Kubernetes 集群非常重要。快照文件包含所有 Kubernetes 状态和关键信息。为了保证敏感的 Kubernetes 数据的安全可以对快照文件进行加密。 备份 etcd 集群可以通过两种方式完成: etcd 内置快照和卷快照。 内置快照 etcd 支持内置快照因此备份 etcd 集群很容易。快照可以从使用 etcdctl snapshot save 命令的活动成员中获取也可以通过从 etcd 数据目录复制 member/snap/db 文件该 etcd 数据目录目前没有被 etcd 进程使用。获取快照通常不会影响成员的性能。 下面是一个示例用于获取 $ENDPOINT 所提供的键空间的快照到文件 snapshotdb ETCDCTL_API3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb # exit 0   # verify the snapshot ETCDCTL_API3 etcdctl --write-outtable snapshot status snapshotdb -------------------------------------------- |   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE | -------------------------------------------- | fe01cf57 |       10 |          7 | 2.1 MB     | -------------------------------------------- 卷快照 如果 etcd 运行在支持备份的存储卷如 Amazon Elastic Block 存储上则可以通过获取存储卷的快照来备份 etcd 数据。 etcd恢复 etcd 支持从 major.minor 或其他不同 patch 版本的 etcd 进程中获取的快照进行恢复。还原操作用于恢复失败的集群的数据。 在启动还原操作之前必须有一个快照文件。它可以是来自以前备份操作的快照文件也可以是来自剩余数据目录的快照文件。 有关从快照文件还原集群的详细信息和示例请参阅 etcd 灾难恢复文档。 如果还原的集群的访问URL与前一个集群不同则必须相应地重新配置Kubernetes API 服务器。在本例中使用参数 –etcd-servers$NEW_ETCD_CLUSTER 而不是参数–etcd-servers$OLD_ETCD_CLUSTER 重新启动 Kubernetes API 服务器。用相应的 IP 地址替换 $NEW_ETCD_CLUSTER 和 $OLD_ETCD_CLUSTER。如果在etcd集群前面使用负载平衡则可能需要更新负载均衡器。 如果大多数etcd成员永久失败则认为etcd集群失败。在这种情况下Kubernetes不能对其当前状态进行任何更改。虽然已调度的 pod 可能继续运行但新的pod无法调度。在这种情况下恢复etcd 集群并可能需要重新配置Kubernetes API服务器以修复问题。 注意: 如果集群中正在运行任何 API 服务器则不应尝试还原 etcd 的实例。相反请按照以下步骤还原 etcd 停止 所有 kube-apiserver 实例 在所有 etcd 实例中恢复状态 重启所有 kube-apiserver 实例 8.kubelet优化 8.1增加并发度 设置 --serialize-image-pullsfalse 该选项配置串行拉取镜像默认值时true配置为false可以增加并发度。但是如果docker daemon 版本小于 1.9且使用 aufs 存储则不能改动该选项。 --serialize-image-pullsfalse 8.2.配置镜像拉取超时 设置--image-pull-progress-deadline30 配置镜像拉取超时。默认值时1分对于大镜像拉取需要适量增大超时时间。 --image-pull-progress-deadline30 8.3.单节点允许运行的最大 Pod 数 kubelet 单节点允许运行的最大 Pod 数--max-pods110(默认是 110可以根据实际需要设置) --max-pods110 9.kube-apiserver优化 ApiServer参数配置 --max-mutating-requests-inflight # 单位时间内的最大修改型请求数量默认200 --max-requests-inflight # 单位时间内的最大非修改型(读)请求数量默认400 --watch-cache-sizes # 各类resource的watch cache默认100资源数量较多时需要增加 9.1.配置kube-apiserver的内存 使用--target-ram-mb配置kube-apiserver的内存按以下公式得到一个合理的值 --target-ram-mbnode_nums * 60 10.kube-controller-manager优化 10.1.Controller参数配置 --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不健康就会停止驱逐。 10.2.可通过 leader election 实现高可用 kube-controller-manager可以通过 leader election 实现高可用添加以下命令行参数 --leader-electtrue --leader-elect-lease-duration15s --leader-elect-renew-deadline10s --leader-elect-resource-lockendpoints --leader-elect-retry-period2s 10.3.限制与kube-apiserver通信的qps 调大 –kube-api-qps 值可以调整至 100默认值为 20 调大 –kube-api-burst 值可以调整至 150默认值为 30 禁用不需要的 controllerkubernetes v1.14 中已有 35 个 controller默认启动为--controllers即启动所有 controller可以禁用不需要的 controller 调整 controller 同步资源的周期避免过多的资源同步导致集群资源的消耗所有带有 --concurrent 前缀的参数 限制与kube-apiserver通信的qps添加以下命令行参数 --kube-api-qps100 --kube-api-burst150 11.kube-scheduler优化 scheduler的配置项比较少因为调度规则已经是很明确了不过可以自定义预选和优选策略 --kube-api-qps # 请求apiserver的最大qps默认50 --policy-config-file # json文件不指定时使用默认的调度预选和优选策略可以自定义指定 kube-scheduler可以通过 leader election 实现高可用添加以下命令行参数 --leader-electtrue --leader-elect-lease-duration15s --leader-elect-renew-deadline10s --leader-elect-resource-lockendpoints --leader-elect-retry-period2s 限制与kube-apiserver通信的qps 限制与kube-apiserver通信的qps添加以下命令行参数 --kube-api-qps100 --kube-api-burst150 12.kube-proxy优化 使用 ipvs 模式  由于 iptables 匹配时延和规则更新时延在大规模集群中呈指数增长增加以及删除规则非常耗时所以需要转为 ipvsipvs 使用 hash 表其增加或者删除一条规则几乎不受规则基数的影响。 13.pod优化 13.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。 使用控制器管理容器 14.如何设置k8s节点的CPU限制 k8s节点的CPU限制可以通过设置k8s调度器的参数来实现具体步骤如下 1打开k8s调度器的配置文件 kube-scheduler.yaml 2在spec configuration parameters中找到--kube-reserved参数并添加如下配置项 --kube-reserved cpu1000m,memory1Gi,ephemeral-storage1Gi 3修改配置参数--cpu-limit-percent的数值将其设置为一个合理的值 4保存并退出文件。 这里需要注意的是对于k8s节点的CPU调度限制的设置需要根据实际情况进行调整比如内存大小、容器数量、容器类型等因素。一般情况下k8s节点的CPU调度限制默认为100%而实际调度节点的CPU利用率一般不会超过80%左右因此合理的CPU限制数值应该小于80%。同时为了保证一定的CPU资源用于Node的正常运行建议将CPU限制调低一些。 验证 1k8s dashboard验证 进入k8s dashboard选择Pods - Nodes选项卡在Nodes列表中选择需要验证的Node在该Node的Details选项中找到Allocated Resources的CPU信息可以看到该节点的CPU利用率是否达到了限制值。 kubectl proxy http://localhost:8001/api/v1/nodes/your_node_name_here/proxy/  访问dashboard即可。 2. 使用kubectl top命令验证在Node所在的集群上运行以下命令 kubectl top node 该命令将返回Node的CPU和内存使用情况以及节点的CPU利用率。