Node.js ElasticSearch服务在Kubernetes 1.6上的NodeJS API中变得随机不可用

我们目前正在解决ElasticSearch集群的特定Kubernetes服务（LoadBalancer）的一个问题，该服务在客户端提供EconReset后似乎变得非常不可用。设置如下所示：

• 使用Kops部署的AWS上的Kubernetes 1.6
• Elasticsearch 2.4群集（Fabric8发现插件部署）。它将自己暴露为服务/负载平衡器
• 作为客户端的NodeJS API部署，使用

  请求

  模块连接到上述Elasticsearch服务

在运行足够长的时间（不多，大约10-15分钟）后，不一定在大量负载（大约每秒1个请求）下运行，ElasticSearch服务似乎变得不可用，这是API端出现错误的症状：

{ Error: connect ECONNRESET 100.69.12.100:9200 at 
 Object.exports._errnoException (util.js:953:11) at 
 exports._exceptionWithHostPort (util.js:976:20) at 
 TCPConnectWrap.afterConnect [as oncomplete] (net.js:1080:14) cause: { 
 Error: connect ECONNRESET 100.69.12.100:9200 at 
 Object.exports._errnoException (util.js:953:11) at 
 exports._exceptionWithHostPort (util.js:976:20) at 
 TCPConnectWrap.afterConnect [as oncomplete] (net.js:1080:14) code: 
 'ECONNRESET', errno: 'ECONNRESET', syscall: 'connect', address: 
 '100.69.12.100', port: 9200 }, isOperational: true, code: 
 'ECONNRESET', errno: 'ECONNRESET', syscall: 'connect', address: 
 '100.69.12.100', port: 9200 }

此错误是随机发生的，不需要指定的高负载，而不是定义的时间段。在这些EconReset的确切时间，ElasticSearch服务（和其他服务）的

kube dns

加载项日志创建（娱乐？）：

这些线路几乎每5分钟重复一次Kubernetes服务。如果这是正常行为，或者肯定与我们观察到的失败有关，我完全不明白它们的意思

API和ElasticSearch在网络上的交互基本上是一组搜索查询（最多并行30/50）。在交互过程中，ElasticSearch侧未观察到错误日志

这在几个月前效果良好，变化如下：

• Kubernetes使用Kops从1.4版升级到1.6版
• 向ElasticSearch群集添加了CPU/内存限制。遵循弹性建议
• 向Elastic添加了额外的初始30个调用，这些调用在第一次调用后缓存

尝试的操作：

• 减少和增加ElasticSearch端的资源限制（CPU/内存），以查看行为的任何变化。对经济没有影响
• 增加了ElasticSearch端搜索的线程池和队列大小。它处理更多的负载，但问题本身在低负载下表现出来

考虑回滚到Kubernetes 1.4，并删除任何限制。任何提示或信息都将受到高度赞赏

更新1：有关

elasticsearch

服务的一些额外信息：

$ kubectl get svc elasticsearch
NAME             CLUSTER-IP       EXTERNAL-IP    PORT(S)            AGE
elasticsearch   100.65.113.208    [AWS ELB] 9200:30295/TCP,9300:32535/TCP   6d

$ kubectl describe svc elasticsearch
  Name:         elasticsearch
  Namespace:        ppe
  Labels:           <none>
  Annotations:      kubernetes.io/change-cause=kubectl create --filename=app/elasticsearch/manifest/ --recursive=true --record=true --namespace=ppe --context=
  Selector:     component=elasticsearch,provider=fabric8,type=client
  Type:         LoadBalancer
  IP:           100.65.113.208
  LoadBalancer Ingress: [AWS ELB]
  Port:         http    9200/TCP
  NodePort:     http    30295/TCP
  Endpoints:        100.96.1.25:9200,100.96.1.26:9200,100.96.2.24:9200 + 5 more...
  Port:         transport   9300/TCP
  NodePort:     transport   32535/TCP
  Endpoints:        100.96.1.25:9300,100.96.1.26:9300,100.96.2.24:9300 + 5 more...
  Session Affinity: None
  Events:           <none>

更新3

我们不仅通过与Elastic通信的NodeJS API观察到了这种行为，还通过

kibana日志记录

Kubernetes服务和

elasticdump

观察到了这种行为：

Mon, 15 May 2017 13:32:31 GMT | sent 1000 objects to destination 
elasticsearch, wrote 1000
Mon, 15 May 2017 13:32:42 GMT | got 1000 objects from source 
elasticsearch (offset: 24000)
Mon, 15 May 2017 13:32:44 GMT | Error Emitted => failed to parse json 
(message: "Unexpected token E in JSON at position 0") - source: "Error: 
'read tcp 172.20.33.123:46758->100.96.4.15:9200: read: connection reset 
by peer'\nTrying to reach: 'http://100.96.4.15:9200/ghs.products-2017-
05-13/_bulk'"

这两个模块和最初的NodeJSAPI都使用

request

NPM模块与ElasticSearch进行通信。有趣的是，ElasticSearch NodeJS客户端（）似乎没有使用

request

---

仍在调查中，但这可能最终成为一个问题/暴露的弹性Kubernetes服务之间的不兼容+

请求

NodeJS模块

吊舱是否重新启动？如果您运行

kubectl描述pod PODNAME

，有任何有用的消息吗？没有pod重新启动。一切都在限制之内。ElasticSearch上没有错误消息。除了客户端的EconReset之外，唯一可疑的错误消息是提到的kube dns。新的服务线路是一种非常正常的行为（也在kube 1.5中观察到）是的，我看到了。我希望这是一些网络问题的迹象，因为它们同时发生。

const elasticSearchClient = elasticSearch.Client({host: config.endpoints.elasticsearch, apiVersion: '2.3',
maxRetries: 5, requestTimeout: 15000, deadTimeout: 30000, keepAlive: true});

Mon, 15 May 2017 13:32:31 GMT | sent 1000 objects to destination 
elasticsearch, wrote 1000
Mon, 15 May 2017 13:32:42 GMT | got 1000 objects from source 
elasticsearch (offset: 24000)
Mon, 15 May 2017 13:32:44 GMT | Error Emitted => failed to parse json 
(message: "Unexpected token E in JSON at position 0") - source: "Error: 
'read tcp 172.20.33.123:46758->100.96.4.15:9200: read: connection reset 
by peer'\nTrying to reach: 'http://100.96.4.15:9200/ghs.products-2017-
05-13/_bulk'"