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

经排查，TGW的监控检测模块按期向全部的RS发送心跳包，可是TGW监控检测模块只能收到A处事器的回包，因此TGW以为只有A节点是存活状态，全部的哀求数据包最终就由TGW转发到A处事器上了，这就是负载平衡计策失效的基础缘故起因。

这里尚有一个征象是为什么etcd集群中只有一个节点的负载很高呢?

五个节点的etcd集群中只有一个节点负载很高，其他正常，通过查察A处事器的API Server的log，可以看到的大量的读哀求都牢靠发送到了统一个etcd节点。

对付这个征象，可以看下API Server会见后端存储的源码，今朝线上Kubernetes基于v1.7.12的源码编译运行，API Server会见etcd是在内部初始化一个etcd client端，然后通过etcd client端发送哀求到etcd server端。etcd client端有v2和v3两个版本。线上API Server行使的是v2版本客户端。首要代码如下：

//初始化etcd事变 
func New(cfg Config) (Client, error) { 
c := &httpClusterClient{//返回一个http范例的client 
clientFactory: newHTTPClientFactory(cfg.transport(), cfg.checkRedirect(), cfg.HeaderTimeoutPerRequest), 
rand:          rand.New(rand.NewSource(int64(time.Now().Nanosecond()))),//传入一个当前时刻的随机种子 
selectionMode: cfg.SelectionMode, 
} 
 
if err := c.SetEndpoints(cfg.Endpoints); err != nil { 
return nil, err 
} 
return c, nil 
} 
//对etcd列表举办打乱 
func (c *httpClusterClient) SetEndpoints(eps []string) error { 
... 
neps, err := c.parseEndpoints(eps) 
c.Lock() 
defer c.Unlock() 
c.endpoints = shuffleEndpoints(c.rand, neps)//打乱etcd列表 
c.pinned = 0 
... 
return nil 
} 
 
func shuffleEndpoints(r *rand.Rand, eps []url.URL) []url.URL { 
p := r.Perm(len(eps))//rank库的Perm要领可以返回[0,n)之间的随机乱序数组 
neps := make([]url.URL, len(eps)) 
for i, k := range p { 
neps[i] = eps[k] 
} 
return neps 
}  

可以看到在初始化etcd客户端时辰会传入一个当前时刻的随机种子去打乱全部Endpoints(etcd节点)的次序。

对付etcd的操纵都是通过API Server内部的etcd客户端发送http哀求到etcd Server端，最首要是挪用如下要领：

func (c *httpClusterClient) Do(ctx context.Context, act httpAction) (*http.Response, []byte, error) { 
... 
for i := pinned; i < leps+pinned; i++ { 
k := i % leps 
hc := c.clientFactory(eps[k]) 
resp, body, err = hc.Do(ctx, action) 
... 
if resp.StatusCode/100 == 5 { 
  switch resp.StatusCode { 
  case http.StatusInternalServerError, http.StatusServiceUnavailable: 
    cerr.Errors = ... 
  default: 
    cerr.Errors = ... 
  } 
  ... 
  continue 
} 
if k != pinned { 
  c.Lock() 
  c.pinned = k 
  c.Unlock() 
} 
return resp, body, nil 
} 
return nil, nil, cerr 
}  

该要领表白每次哀求时辰，会从pinned节点开始实行发送哀求，假如发送哀求非常，则凭证初始化时辰打乱次序的下一个节点(pinned++)开始实行发送数据。云云看来，假如API Server行使了某个endpoint发送数据，除非用坏了这个节点，不然会一向行使该节点(pinned)发送数据。这就声名白，没有非常环境下，一个API Server就对应往一个牢靠的etcd发送哀求。

对付etcd集群，假如是写哀求的话，follower节点会把哀求先转发给leader节点处理赏罚，然后leader再转发给follower同步。那么5个节点CPU负载不会这么不平衡，可是按照2.1排查API Server日记看到这里是大量的读哀求，相对付写哀求，读哀求是全部follower节点都能对外提供的。也就是大量哀求因为负载平衡计策失效都转发到A处事器，A再把查询哀求都打到个中一个牢靠的etcd，导致该节点忙于处理赏罚etcd查询哀求，负载就会飙高。

（编辑：湖南网）

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