MssGuo的博客

如果您希望去除这个限制，可以将其值设置得非常大，例如设置为0，这样Nginx就不会对客户端的请求主体大小进行限制了。此外，如果请求主体大于client_body_buffer_size指定的值，Nginx会将请求主体保存到临时文件中，因此确保临时文件目录具有足够的空间和适当的权限也是很重要的。这样的配置将会允许客户端发送非常大的请求主体，直到达到操作系统或硬件的限制。从报错信息来看这是nginx返回的错误信息，原因是nginx设置允许客户端的包大小设置小了，nginx反向代理到了后端harbor。

nacos 启用登录认证授权

下面启动一个java进程，模拟如何排查java进程cpu使用率非常高的情况。

环境：k8s 1.22.6、nfs-server后端存储。

节点存在node.kubernetes.io/memory-pressure:NoSchedule，但节点内存充足

k8s部署nacos 一直报错No DataSource set（k8s踩坑--警示-操作失误导致）

nacos登录 提示权限认证失败 没有命名空间的访问权限

pod调度失败，显示某个节点 too many pod。重启kubelet服务，再次查看节点可容纳数量。

关闭Linux中You have new mail in /var/spool/mail/root的提示。

创建了一个nodeport类型的service，端口是80，按道理来说会在每个节点上开启80端口，但是发现master节点上没有开启80端口，node1、node2上均开启了80端口。等方式查看service开启的nodeport端口了，但是我们可以使用telnet命令进行测试。排查防火墙selinux，都是关闭状态的。

提到了一个NetworkManager服务，排查发现本人的其他节点都是关闭NetworkManager的，只有node2是开启了NetworkManager，所以关闭NetworkManager后node2的calico正常了，不再报错，ping node2上的pod IP也能正常ping通。百度，发现也有人遇到相同的问题，但解决方法不一样，在这篇。ping不同node2节点上的pod IP。

FQA问题记录