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

总的来说，TGW做负载平衡时辰，因为心跳检测模块和个中两个Resource Server间毗连不通，导致误将全部哀求都转发到个中一个API Server，而一个特定的API Server行使v2版本etcd客户端就只会往一个牢靠的etcd处事端发哀求，这样整个负载平衡计策就失效了。

2.2.2 etcd存取数据迟钝

namespace未做分别：

从2.1中查察API Server 的日记可以看出，许多get哀求Pod工具信息，好比：“Get /api/v1/namespaces/default/pods?...” 这些都是从default namespace下获取Pod信息，这就声名线上并没有对Pod的namespace做分别。

Kubernetes是通过namespace对容器资源举办断绝，默认环境下，假如未指定namespace的话，建设的容器都被分别到default namespace下，由于这个缘故起因也给后头往etcd中存储容器元数据信息也留下了坑。全部的Kuberentes的元数据都存储在etcd的/registry目次下，整体如下图所示：

Kubernetes中Pod的信息存储在/registry/pods/#{定名空间}/#{详细实例名}的目次布局中，正由于假如不指定namespace的话，就会存储到default的namespace中，也就是/registry/pods/default目次下生涯了线上所有Pod工具信息。

也就是说大量get哀求Pod工具信息，因为未做namespace分别,每次城市去会见default子目次，每次哀求相等于都要做全局搜刮，跟着集群的增多，Pod不绝的存入到该子目次中，搜刮机能也会变得越来越差。

查询功效未插手缓存：

从2.1中查察API Server 的日记看到许多Get/List操纵，那么可以细心看看相干要领的执行流程，下面是List要领执行进程中挪用的中间函数：

f 
 
unc (c *Cacher) GetToList(ctx context.Context, key string, resourceVersion string, pred SelectionPredicate, listObj runtime.Object) error { 
if resourceVersion == "" { 
return c.storage.GetToList(ctx, key, resourceVersion, pred, listObj)//直接查询etcd 
} 
listRV, err := ParseListResourceVersion(resourceVersion) 
... 
obj, exists, readResourceVersion, err := c.watchCache.WaitUntilFreshAndGet(listRV, key, trace)//从缓存中获取 
... 
return nil 
}  

可以看到，GetToList要领中传入的有个resourceVersion 参数，假如配置了就会从缓存中获取，假如不配置就会去etcd中查询。这个也是一个要害点，有关resourceVersion 的相干行使如下：

• 不配置：通过API Server从etcd读取。
• 配置成0：从API Server的cache读取，减轻API Server和etcd压力。譬喻Kubelet常常通过此要领Get Node工具，Kubernetes Infomer第一次启动时List也通过此要领得到工具。
• 大于0：读取工具指定版本。

线上打点平台通过http接口去查询Pod信息时辰是没有配置resourceVersion，以是每次通过Get/List要领获取资源时辰城市查询etcd，云云一来常常大量高频率的查询etcd会导致其压力较大，开启缓存计策不只可以减轻会见etcd压力并且还可以加速查询速率。

总结以上两点：全部的哀求都发往一个牢靠的API Server，导致该API Server节点负载较高，同时该API Server又会将查询哀求牢靠的发给某个etcd节点，然而哀求功效并没有在API Server端做缓存，每次城市直接查询etcd，在从etcd中获取Pod信息又是从default这个大的子目次中全局搜刮，每次哀求都较量费时，这样导致某一个牢靠的etcd一向处理赏罚大量的费时的哀求，最终将该etcd资源耗尽，负载过高，因而查询功效不能实时返回给API Server，导致建设Pod时辰拿不到相干的信息，Pod建设事变无法举办，以是最终表象是集群陈设长时刻卡顿。

3、办理方案

切换负载平衡方案：姑且切换为DNS轮询方法，担保每个API Server节点的流量平衡。同时跟进TGW对付某些网段的RS和TGW处事不能探测心跳及后续改造。

将Kubernetes中Pod按多个namespace分别，今朝线上全部的Pod都分别到默认的default的namespace下，每次读取Pod信息都是从etcd检索整个namespace，较量消费etcd机能，今朝已经将Pod的namespace举办细分，加速了读取Pod信息速率同时镌汰了etcd机能消费。

etcd v3版本客户端会对Endpoints按期打乱，后续我们会进级到v3版本，这样统一个API Server的哀求就不会一向落到某一个etcd上，这样纵然负载平衡计策失效也能做到对etcd哀求的分摊。

查询Kubernetes资源信息时带入resourceVersion开启缓存机制，减轻对etcd的会见压力。

4、总结

从API Server卡顿题目排查进程来看，隐藏的题目是恒久存在的，只是蕴蓄到必然量后，题目的影响才会凸显。这就要求我们平常对Kubernetes相干组件的机能指标，日记等要保持时候敏感，要对Kubernetes各类默认计策及参数很是认识，同时对付重要成果模块做到源码层面相识，这样才气规避隐藏风险和出题目后能快速定位，担保出产情形不变康健的运行。

【编辑保举】

1. 甲骨文推出新的云基本办法署理 令Kubernetes开拓职员的糊口更轻松
2. 切磋Kubernetes的差异陈计划策
3. Kubernetes 收集、监控技能全面解读
4. Kubernetes行使时必要留意的坑点
5. 将来的Kubernetes将效仿Facebook的做法

（编辑：湖南网）

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