容器云平台API Server卡顿问题排查

58云计算平台是58集团架构线基于Kubernetes + Docker技术为集团内部服务开发的一套业务实例管理平台，它具有简单，轻量的特点及高效利用物理资源，更快的部署和统一规范的标准化运行环境，通过云平台，使得服务标准化，上线流程规范化，资源利用合理化。然而云平台的建设过程不是一帆风顺，也不乏出现一些问题挑战，本文就针对云平台现实中遇到的一个问题和大家分享。

1、关于问题

1.1 问题概述

近期，很多业务同事反馈使用云平台上线存在容器部署慢，平台反应慢的问题。通过详细的问题排查定位后，最终问题得以解决。

1.2 Kubernetes基本知识

私有云平台通过Kubernetes对容器进行编排。Kubernetes整体架构如下图所示：

其中几个主要的模块的功能简要描述如下：

• etcd：用于Kubernetes的后端存储。
• Pod：Kubernetes最基本的操作单元，包含一个或多个紧密相关的容器。
• Replication Controller：副本控制器，用来保证Deployment或者RC中副本的数量。
• Scheduler：Kubernetes的调度器，Scheduler监听API Server，当需要创建新的Pod时Scheduler负责选择该Pod与哪个Node进行绑定。
• Kubelet：每个Node节点上都会有一个Kubelet负责Master下发到该节点的具体任务，管理该节点上的Pod和容器。
• API Server：对于整个Kubernetes集群而言，API Server是通过暴露Kubernetes API的方式提供给内部组件或者外部程序调用去完成对Kubernetes的操作。各个组件之间也是通过API Server作为桥梁进行间接通信，这种方式做到各个组件间充分解耦。

业务同事操作管理平台发出创建集群请求到集群创建完成的整个流程如下：

1. 业务同学操作管理平台进行升级操作，管理平台通过http方式向API Server发出请求。
2. API Server处理和解析请求参数，将待创建的Pod信息通过API Server存储到etcd。
3. Scheduler通过API Server的watch机制，查看到新的Pod，尝试为Pod绑定Node。
4. 经过预选筛除不合适节点及从待选节点中根据一定规则选出最适合的节点。
5. 对选中的节点及Pod进行binding操作，将相关的结果通过API Server存储到etcd。
6. 对应Node的Kubelet进程调用容器运行时创建容器。

2. 定位问题

2.1 问题排查

从1.2可以看到，API Server在创建Pod过程中起到非常关键的中间桥梁作用，解析外部请求及读写etcd。因此决定首先从API Server进程所在宿主机的各项性能指标及日志方面进行排查，看是否有所发现。

目前线上环境有3台主机运行API Server，以达到流量负载均衡的目的，异常时间段网卡eth2入流量如下图所示：

由3台API Server主机的监控数据，发现服务器A的网卡入流量远高于另外两台，说明绝大部分请求发送到了服务器A。

通过对比三台服务器API Server 的CPU利用率，发现服务器A的API Server进程CPU使用率一直保持在2000%(20核)上下波动，而另外两台服务器的API Server的CPU利用率没有超过100%(1核)。进一步证实了A的API Server进程处理了绝大多数的请求。

查看A服务器的API Server的相关log，发现正在大量输出如下的日志：

这个日志显示有大量请求通过API Server到etcd查询Pod的状态。

对于Kubernetes后端的存储目前采用5个etcd节点组成etcd集群。登陆其中一个节点(E1)，发现对E1节点执行etcd操作命令，比如命令：“etcdctl ls /registry/pods/default”，命令执行也会经常超时。如果你想和更多Kubernetes技术专家交流，可以加我微信liyingjiese，备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态。

同时对比5台etcd节点的流量，发现有一个节点网卡入流量远高于其他四个节点，该节点(E1)的etcd进程的CPU利用率在100%左右，明显高于剩余的4个节点CPU利用率。查看节点E1的etcd进程日志，经常看到如下报错：

可以推断节点E1的负载非常高，节点间同步心跳都已经超时，无法正常的响应外部的请求了。

2.2 问题分析

经过上述排查，主要集中在这两个问题上：

2.2.1负载均衡策略失效

首先可以看到对Kubernetes集群的操作请求大部分都落在某个API Server上，导致其中一个API Server负载很高，那么有可能负载均衡策略有些问题。那就先看看当前负载均衡策略是如何的。

当前我们租赁的是腾讯的机房，负载均衡策略采用的是TGW(Tencent Gateway)系统所自带支持的负载均衡策略。腾讯云上有关介绍如下：

TGW负载均衡策略保证请求的分摊转发，也会自动对resource server(RS)进行存活检测，每分钟会有心跳包去对接入TGW的IP Port进行探测。

关于TGW相关配置具体如下：

1. 做域名解析：我们对需要访问到API Server的物理机都做了本地DNS，将一个固定域名(D)解析到一个特定的VIP(V)，而该VIP就是TGW对外提供的虚拟IP。
2. 配置TGW服务的RS列表：将三台API Server节点对应的物理IP加入到RS列表。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!