kubernetes - Kubenet响应时间降低，使用hostNetwork解决：true，使用独角兽应用程序

我正在尝试调试使用hostNetwork: true解决的问题。 k8s安装使用的是kubenet，k8s版本是1.9.8。

使用m4.xlarge和c4.xlarge实例在AWS上使用kops完成安装。

问题如下：

当我们将该应用程序迁移到kubernetes时，某个端点的响应时间（百分位数95）增加了大约20-30％。

但是，在yaml中使用hostNetwork: true时，此问题已解决。该端点的性能与VM上的性能相同，即该端点的响应时间百分位数95相同。

我已经在7月18日的kubernetes办公时间问过（是的，前一阵子！），并且提出了hostNetwork: true解决方法。

请注意，所有kube-proxy物品都可以丢弃，因为在应用本身中进行测量时，可以看到响应时间增加。我的意思是，ruby应用程序会测量花费的时间并将其发送到日志收集器。这次，这是因为该请求开始由应用处理直到完成，已经显示出性能下降。因此，kube-proxy和其他东西不合时宜。

豆荚有3个容器：

这些应用程序也处于VM模式

我尝试过的事情：

找到了一种使用Ab（Apache基准）进行复制的方法
- ab -c 1 -n 1000 'https://...
- http，而不是https
我尝试删除了nginx容器，但它没有任何改变。日志收集器在localhost上使用，并且在不出现问题的VM上完成了同样的事情
我尝试在nginx和应用程序之间使用unix套接字，而不是localhost，但是它也没有任何改变。
尝试将相同的实例（m4.xlarge）与EKS一起使用：发生相同的情况。尽管不使用hostNetwork: true的性能成本较低，但大约为10％。请注意，EKS不使用kubenet，而是基于某些开源使用其自己的网络覆盖。
尝试使用仅返回字符串的另一个端点（输入“ Ok”），并且不会发生此问题
尝试使用返回几MB的端点（例如"Die" * 10 * 1024 * 1024），并且该问题也不会发生
尝试使用具有不同查询字符串参数的问题的同一端点，因此响应较大（9MB）或较短（130kb），并且两者均可靠地重现了问题
尝试过一个nodejs应用程序，该应用程序从相似的源返回相似的json，并且不存在问题（也不响应长/短响应）下一步可能做什么：

因此，我正在尝试调试此问题以了解其含义，并希望停止使用hostNetwork: true。似乎还有进一步挖掘的路径：

尝试其他CNI（EKS表现出较小的性能下降）以查看性能是否发生变化
查看此终结点的功能或它如何与独角兽和整个堆栈交互。一个很大的不同是，独角兽是每个请求一个进程（同步），而nodejs不是。
尝试使用更多较新的计算机（m5 / c5）来查看它们是否可以减轻性能影响。但是，由于使用当前实例作为虚拟机的当前实例不存在此问题，因此，如果有帮助，只会隐藏问题

此端点存在性能问题，是ruby中的端点，它读取数据库并获取返回的json。数据库，主机，网络似乎都很好（使用vmstat，我们的常规工具，AWS控制台，检查kern.log，sysloca以及其他东西来监视CPU，磁盘IO，交换等）

您是否有过类似的经历？或者您对如何继续调试此问题还有其他想法吗？

欢迎任何想法或任何帮助！

Rodrigo

此处提到的解决方法（例如dnsPolicy: Default）为我解决了这个问题。

并提供一些解决方法。

长话短说：nf中存在一种竞争条件，在进行DNAT / SNAT时会影响无连接协议（例如UDP）。编织人员已经发送了补丁来修复大多数比赛。要解决此问题，您可以使用外部dns（即，不是通过服务公开的kube-dn，因此使用DNAT），为glibc设置标志（但对musl不起作用），使用最小延迟tc等

注意：使用dnsPolicy: Default可以解决问题，因为它使用的是外部DNS服务器（即，不是托管在kubernetes中，而是通过具有DNAT功能的服务进行访问）。

尽管dnsPolicy: Default确实为我解决了该问题，但由于我们在某些应用程序上使用了k8s DNS服务解析，因此我将为群集测试glibc标志。