1. 问题说明

• 针对K8S 1.13 后的版本，提供 K8S 通用的优化要点。常见的使用经验、问题处理分享。

• 针对 K8S 组件，一些典型参数以及常见的一些问题和处理方法。

2. 问题处理

先看一下Kubernetes主要架构组件图：

2.1  etcd

Kubernetes 中的大部分概念如 Pod、ReplicaSet、Deployment、Service、Node 等都可以被 看作一种资源对象，几乎所有资源对象都可以通过 Kubernetes 提供的 kubectl 工具(或者 API 编程调用)执行增、删、改、查等操作并将其保存在 etcd 中持久化存储。从这个角度 来看，Kubernetes 其实是一个高度自动化的资源控制系统，它通过跟踪对比 etcd 库里保存 的“资源期望状态”与当前环境中的“实际资源状态”的差异来实现自动控制和自动纠错 的高级功能。

• etcd 保存整个集群的状态信息，类比相当于k8s的数据库。

• 高可用方面，etcd 需要以集群的方式进行部署，以实现 etcd 数据存储的冗余、备份与高可用。etcd 集群需要奇数形式，至少由三台组成，考虑到同步的开销，一般不推荐超过7个etcd节点。

• 存储，由于etcd 的特性，应考虑使用高性能的存储设备，如 SSD 磁盘，在Kubernetes 集群较大时，必须使用PICe SSD 来提升IO性能减少读写延迟。

• etcd 性能有两个关键因素：延迟(latency)：延迟是完成操作的时间；吞吐量(throughput)：吞吐量是在某个时间期间之内完成操作的总数量。

压缩空间

# 获取当前版本号
$ rev=$(ETCDCTL_API=3 etcdctl --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9]*'）
# 压缩所有旧版本
$ ETCDCTL_API=3 etcdctl compact $rev
# 去碎片化
$ ETCDCTL_API=3 etcdctl defrag

时间参数

etcd 的心跳间隔默认是 100 毫秒。Etcd 的选举超时时间默认是 1000 毫秒（即从节点等待多久没收到主节点的心跳就尝试去竞选领导者）。在网络环境吞吐量大情况下，如同步吞吐在100MB左右。可适当调整：

--heartbeat-interval=300

--election-timeout=5000

问题一：

etcd集群状态：不同节点上有时候结果还不一样。有时候member1 不健康，有时候 member3 不健康 —— unhealthy。

原因：

etcd 对系统时间很敏感，当集群节点出现时间不一致时则出现问题。

解决：

统一 NTP 服务器校准。集群各节点使用如：

1. timedatectl set-timezone Asia/Shanghai 确保时区。

2. ntpdate -u $NTP-SERVER 进行时间同步。

3. 使用 chronyd 进行自动时间同步。

问题二：

1. 集群加入主机后，主机列表没有新增。

2. 接入主机命令执行之后，一般会报错 Node “xxx" not found。（原因是添加被etcd 拒绝）

3. 主机状态 未知。

4. Kubelet 状态有 database space exceeded报错。

原因：

1. 默认情况下，ETCD使用的空间上限是 2 GB。一般支持最大 8 GB。

2. 默认 etcd 的 snap 频率是 10万次提交 进行一次 Snapshot。Kubernetes 数据存储在 etcd，当 k8s load 较高时，Snap 频率会提高。

解决：

# ETCDCTL_API=3 etcdctl --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt --write-out=table endpoint status

查看 节点数据存储量，通常数据量应该很小。几百K到几十M不等。出问题一般会超过2G。

1. 获取 revision，然后压缩compact

# ETCDCTL_API=3 etcdctl --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt endpoint status --write-out="json"
# ETCDCTL_API=3 etcdctl --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt compact 4974364

 2.defrag 整理空间

# ETCDCTL_API=3 etcdctl --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt defrag

   3.修改默认空间

   etcd 的硬盘存储上限（默认是 2GB）,当 etcd 数据量超过默认 quota 值后便不再接受写请求，可以通过设置 --quota-backend-bytes 参数来增加存储大小。

2.2  APIServer

APISERVER 是整个系统的对外接口，提供一套 RESTful 的 Kubernetes API，供客户端和其它组件调用。

• 提供对k8s资源操作的唯一入口，并提供认证授权，访问控制，API注册与发现等机制。

• 只有 apiserver 才能操作 etcd，其他组件通过 APISERVER 进行数据的查询和集群状态更新。

• Kubernetes 所有的数据变动都会经过 APISERVER。

• 上述参数根据实际生产环境调整。

• 在 v1.10 以前的版本中可能出现 kubelet 连接 apiserver 超时之后不会主动 reset 掉连接进行重试，除非主动重启 kubelet 或者等待十多分钟后其进行重试。v1.14 及以上版本修复此问题。

• Kube-APIServer模块的代码审核也是最严格的，一般不会有什么较大的改动，一旦有改动，都是需要长久的讨论才能决定怎么改，毕竟API-Server的性能，直接决定了Kubernetes整体的性能。

问题一：

Kubernetes 的各个组件与 Master 之间可以通过 kube-apiserver 的非安全端口 http://<kube-apiserver-ip>:8080 进行访问。但如果 API Server 需要对外提供服务，或者集群中的某些容器也需要访问 API Server 以获取集群中的某些信息，存在安全隐患。

解决方案：

安全的做法是启用 HTTPS 安全机制。设置 kube-apiserver 的启动参数“--token-auth-file”，或启用RBAC认证，使用文件提供安全认证：

--secure-port=6443

--insecure-port=0

--basic-auth-file=/etc/kubernetes/basic_auth_file

8080 端口在后续的版本中将被弃用。

问题二：

大量 POD 重建导致 events 增多，api server 压力较大，集群访问受到影响。

解决方案 1：

 kubectl delete events --all -n tenant1  

• 删除该租户下的所有 events。

解决方案 2：

 kubectl get pod -o wide --all-namespaces | awk '$5>0'

• 查看租户下不断重启的 容器组，并处理。

2.3 kube-scheduler

kube-scheduler，负责资源调度(Pod 调度)的进程，相当 于公交公司的“调度室”。实现 Pod 的调度， 整个调度过程通过执行一系列复杂的算法，最终为每个 Pod 都计算出一个最佳的目标节点。

• 通过 watch 到api-server 事件变化，获取需要创建并且未进行调度的 pod 进行调度，如果调度成功会把信息通过 api-server记录到etcd中。

• daemonset 不经过 scheduler 调用，直接在 node 启动。

• 对某些 Node 定义特定的 Label，并且在 Pod 定义文件中使用 NodeSelector 这 种标签调度策略，kube-scheduler 进程可以实现 Pod 定向调度的特性。

• Pod/Node Affinity & Anti-affinity

• Taint & Toleration

• Priority & Preemption

• Pod Disruption Budget

systemd 启动参数：

• --kubeconfig:设置与 API Server 连接的相关配置，可以与 kube-controller-manager 使用的 kubeconfig 文件相同。

• --logtostderr:设置为 false 表示将日志写入文件，不写入 stderr。

• --log-dir:日志目录。

• --v:日志级别。

问题一：

scheduler 默认监听 0.0.0.0，存在安全隐患。

解决：

启用 HTTPS，指定监听地址为内网或本机127.0.0.1。

--bind-address ip ，在 HTTPS 安全端口提供服务时监听的 IP 地址，默认值为 0.0.0.0。

--secure-port int，设置 HTTPS 安全模式的监听端口号，设置为 0 表示不启用 HTTPS，默认值为 10257。

2.4 kube-controller-manager

kube-manager，是 Kubernetes 中各种操作系统的管理者，是集群内部的管理控制中心，也是 Kubernetes 自动化功能的核心。作为集群内部的管理控制中心，负责集群内资源的管理。目的在于及时发现故障并自动化修复，确保集群始终处于预期的工作状况。

• 负责集群内的Node、Pod 副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）等的管理。

• 当某个Node意外挂掉时，kube-controller-manager 会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。

通过设置 kube-controller-manager 组件的启动参数--leader-elect=true，即可实现 kube-controller-manager 组件的高可用性。

问题一：

节点宕机，保障业务不受影响。

解决：

1. Pod 应该多实例，分布不同主机。避免某个节点宕机带来的单点影响。

2. 当计算节点出现问题时，kube-controller 默认需要5分钟后才会驱逐计算节点上的容器并重建。这个时间不建议减少太多，避免因为网络抖动带来 pod 频繁调度和误杀问题。

3. kube-controller-manager，其中「--unhealthy-zone-threshold」参数可以设置在一个 zone 中有多少比例的 Node 失效时将被判断为 unhealthy 不进行节点驱逐，默认值为 0.55。

4. 如果对时间敏感度有强烈需求，以下脚本供参考。

#!/bin/sh

KUBECTL="/usr/bin/kubectl"

# Get only nodes which are not drained yet
NOT_READY_NODES=$($KUBECTL get nodes | grep -P 'NotReady(?!,SchedulingDisabled)' | awk '{print $1}' | xargs echo)
# Get only nodes which are still drained
READY_NODES=$($KUBECTL get nodes | grep '\sReady,SchedulingDisabled' | awk '{print $1}' | xargs echo)

echo "Unready nodes that are undrained: $NOT_READY_NODES"
echo "Ready nodes: $READY_NODES"


for node in $NOT_READY_NODES; do
echo "Node $node not drained yet, draining..."
$KUBECTL drain --delete-local-data --ignore-daemonsets --force $node
echo "Done"
done;

for node in $READY_NODES; do
echo "Node $node still drained, uncordoning..."
$KUBECTL uncordon $node
echo "Done"
done;

• 将上方脚本加入crontab中，设置为1分钟执行一次。

问题二：

Kubernetes 的关键组件除了 API Server 、 scheduler、controller-manager 是运行在 master 节点上的，其余都在普通节点上。当集群内普通节点资源被消耗完，关键组件可能没有足够的资源来运行（如网络组件），导致整个集群无法正常工作。

解决：

将普通 Pod （非关键组件）从节点上驱逐来释放占有的资源。但是这样做，普通 Pod 与关键组件 Pod 会一起进入调度器，普通 Pod 可能会先一步被调度到机器上，重新占有释放的资源。这样事情就会陷入一个死循环。可以将被选中的节点（用于释放资源），标记一个暂时的污点（taint “CriticalAddonsOnly” ），这样不能容忍污点的 Pod 将不能调度到有污点的节点上。

1. 组件必须运行在 kube-system 命名空间下;

2. 1.14 前版本，可以 scheduler.alpha.kubernetes.io/critical-pod 的注解（annotation ）设置为空字符串；

3. PodSpec’s 的容忍（tolerations） 设置为：[{"key":"CriticalAddonsOnly","operator":"Exists"}]；

4. 需要将 priorityClassName 设置为 system-cluster-critical 或 system-node-critical ，后者是整个群集的最高级别。

2.5 kubelet

kubelet 负责 Pod 对应的容器的创建、启停等任务，同时与 Master 密切协作，实现集群管理的基本功能。

• kubelet 负责容器声明周期。

• kubelet 服务依赖于 Docker 服务。如果 docker 进程异常或启动失败，则 kubelet 服务也随之出错。

• 建议 kubelet 以主机服务进程启动运行，如 systemd。

• kubelet 默认采用向 Master 自动注册本 Node 的机制。定时向 Master 汇报自身的节点情况，包括操作系统、Docker 版本、机器的 CPU 和内存情况，以 及当前有哪些 Pod 在运行等。

问题一：

kubelet 容器启动出错。

解决：

kubelet Pod status，获悉容器相关状态：

CrashLoopBackOff：容器退出，kubelet正在将它重启

InvalidImageName：无法解析镜像名称

ImageInspectError：无法校验镜像

ErrImageNeverPull：策略禁止拉取镜像

ImagePullBackOff：正在重试拉取

RegistryUnavailable：连接不到镜像中心

ErrImagePull：通用的拉取镜像出错

CreateContainerConfigError：不能创建kubelet使用的容器配置

CreateContainerError：创建容器失败

m.internalLifecycle.PreStartContainer 执行hook报错

RunContainerError：启动容器失败

PostStartHookError：执行hook报错

ContainersNotInitialized：容器没有初始化完毕

ContainersNotReady：容器没有准备完毕

ContainerCreating：容器创建中

PodInitializing：pod 初始化中

DockerDaemonNotReady：docker还没有完全启动

NetworkPluginNotReady：网络插件还没有完全启动

问题二：

kubelet 故障引起的常见结果。

解决：

kubelet 故障对应用影响：

问题三：

重启kubelet之后，会导致节点上面的一些Pod也发生重启，并且会留下一些状态为MatchNodeSelector的僵尸Pod。

原因：

正常情况下，如果我们在某一节点上重启了kubelet，那么上面的Pod(容器)是不会重启的。这是kubelet 现存 BUG，但触发需要一定条件。

1. 某些Pod是通过NodeSelector的label给调度到某些专有label的节点上的。

2. 当kubelet重启并且与apiServer的连接非常不稳定时，会有几率出现这些Pod被重启。

解决：

当重要业务节点需要重启 kubelet 时，为保证上面运行的 pod 业务。可以修改 kubelet 配置的 --node-labels 参数

• 添加--node-labels 后，再执行 kubelet 重启的操作。

2.6 kube-proxy

kube-proxy，实现 Kubernetes Service 的通信与负载均衡机制的重要组件。

• 负责把对 Service 的请求转发到后端的某个 Pod 实例上，自动建立每个 Service 到对应 Pod 的请求转发路由表，从而实现 Service 的负载均衡机制。

• kube-proxy 服务依赖于 network 服务。

• 生成 service 相关网络访问规则，支持 iptables 和 ipvs 规则（最新版默认使用这个）创建。

• --iptables-sync-period 刷新 iptables 规则的最大时间间隔（例如 5s，1m，2h22m）必须大于 0。（默认 30 秒）

• --iptables-min-sync-period 当端点和 Service 改变时（例如 5s，1m，2h22m），iptables 规则刷新的最小间隔可以被刷新。（默认10秒）

问题一：

节点故障时，上面运行的 pod 需要较长时间才恢复正常。

原因：

Kube-proxy 默认 30 秒就刷新一次 iptables 规则。如果主机故障或删除 iptables 规则，那就需要 30 秒后 kube-proxy 才能实现并恢复。

解决：

1. 按实际调整 iptables 刷新、同步规则时间。

2. pod 设置 readiness 健康检查，探测 pod 异常时可以自动去除前端 service 访问。

3. 调整 kubelet 的 --node-monitor-grace-period 参数，减少这个时间让节点从调度中摘除。

4. 上层添加硬负载，如 F5；软负载如Haproxy 可在 retries 配置中解决、Nginx在 max_fails 配置中解决。

问题二：

kube-proxy 不工作，导致访问某个节点的 pod 业务，服务异常。

原因：

iptables 规则没生成或规则没及时同步。

解决：

1. 删除 kube-proxy 重建。

2. Service 需要的 ClusterIP 段可能有冲突，查找内网是否存在与默认10.96.0.0/12网段。

3. 大规模，如 service 超过5000个。使用 ipvs 模式替代 iptables。

问题三：

存在 keepalived 的节点，监控脚本就不停重启keepalived

原因：

kube-proxy 使用 ipvs 模式，重启会导致 ipvs 的所有规则清除。keepalived节点依靠ipvs来转发， 但是只要restart该节点的kube-proxy， ipvsadm -L -n规则就全没了。

解决：

调整 kube-proxy 的参数：--cleanup-ipvs=false 。