问题描述：
前几天在.netcore3.1上K8S过程中，启动POD数量3个，但是其中有一个POD一直启动不起来，查看日志，发现报错信息为:Error while reading json file in dotnet core “the configured user limit (128) on the number of inotify instances has been reached” 。我又重新部署了一次，结果就成功了，偶发现象？但是随后在做性能压测时，因为要部署多个压测环境的时候，又出现了这个问题，并且多次部署后，偶尔会出现偶尔不会出现，很妖~
问题分析：
启动了多个POD，只有部分POD报错，并且在重新部署，很大概率是能正常启动的，应该是跟程序代码没有关系。怀疑是微软的bug？果断google一下，发现了一个issue(https://github.com/dotnet/aspnetcore/issues/7531
)。根据这个issue中的描述，我们知道原来netcore在Linux上是用inotify实现文件是否变化的通知。这样就可以在文件发生变化的时候，动态加载内容到系统中。我们一个POD启动是启动了2个watch，并且因为安全考虑，我们在docker file中统一都用的是app这个用户。linux中默认一个用户watch的文件的最大数量是128，当前一个物理节点上pod大部分都是60左右，如果POD数量超过64，也就是65*2>128，就会发生这个错误。
- 系统默认值大小：
- 偶发性出现错误时，3个物理机（101,102,103）的POD数量（事后的截图，参数调整到140后）：
验证：
- 为了验证这个问题，我们重新部署了一个sandbox环境的一个程序，调整POD部署的亲和度，让POD全部部署到一个物理机节点上，并扩容使物理机上的POD数量到63，发现没有问题。
- 再使物理机的节点扩容到64个，果然有一个POD无法启（我们一个程序，会启动2个watch）。
- 随后调整参数到140
max_user_instances=140
POD又可以全部启动。
以上几个实验验证了我们的猜想，解决方案就变得简单了。
解决方案：
我们评估我们的单物理机最大可能会部署POD的数量，做一些冗余就好了我们调整了参数：
max_user_instances=2048
问题解决！
