事情是这样的：

1、原来给部署的nacos 2.0.3 版本，k8s上微服务有前端20个、后端20个，spring cloud+dubbo rpc+canal+seata+apollo+nacos;nacos作为注册中心用，spring cloud和dubbo所有服务都注册在这上面，完全启动后有2200个服务；apollo存放所有微服务的配置；中间件服务器全部是3节点的小集群；[存储数据库等描述新忽略]

2、跑了一星期，nacos集群里的2200个服务里有几十个服务出现频繁的掉线和重启；

3、宿主机SSH登录不上，在虚拟化里发现如下一些内核报错：

 

 

排查问题的过程：

1、一开始是怀疑是开发写的程序有问题，经过沟通开发同学，在测试机上是好的；又观察了一下自重启的服务是随机的。数据库和存储是共享出问题全出问题；因此，定位是nacos的问题；

2、查看nacos日志，有发现了报错Enum的变量没有找到。然后实锤了，是nacos client 版本和nacos server版本不一致；介于不能让开发把所有nacos client版本改了，nacos server降低到1.4.2；

3、为什么linux内核会报错，为什么linux内核io磁盘缓存会超过40%？网上查找的答案，一个都没解决，但是找到了原因，是Linux交换IO达到了极限；于是升级了SSD硬盘，也加了IO回写优化；问题依旧没有解决；

4、找到了CPU和内存过高的进程；经过jmap -heap 38查看进程内存模型，pmap -x 21002查看了进程运行的应用；定位，不是应用的问题，石锤了是nacos进程；然后发现，他的老生代居然97%，实锤JAVA内存溢出；

出现了卡脖子的问题：

1、nacos 是3节点，选举发生了错误；表象是三个节点频繁的自重启；查看日志，发现确实是raft的日志有警告；

2、咨询了一些同事，把data文件夹清空；有状态pod，3个节点。我分别登上3个节点去删data，然后在rancher重新部署；然后问题依然解决不了；

3、怀疑data被删除后，又重新同步了数据；所以，把3个pod删除，逐一手动重启；呵呵，三个节点频繁的自重启的问题居然解决了；

4、nacos 稳定版本，内存溢出？？？大厂都在用啊。于是先加了JVM和虚拟机内存；问题依旧；

 5、甚至都怀疑到了虚拟化上，物理机->PVE->centos7虚拟机->k8s集群->nacos；我把PVE和物理机全优化了，也做了网络和磁盘IO测试，妥妥8000+iops;网络内网，三层交换在一起，无丢包，那交换机还是新的呢；千兆网卡；千兆口绿灯妥妥的；虚拟机排查了也没毛病和其他机器一样配置；K8S别的POD怎么不出问题?最终还是回到 nacos 3节点小集群上；

本以为高枕无忧了：

1、nacos 1.4.2就这样平稳的运行了5天。不过第5天的时候，我登上pod看，内存溢出问题依旧存在，又跑了90%；表象稳定了5天，其实爆掉是迟早；

2、没有办法，看日志已经没有了ERROR，剩下一些WARING。发现了

于是，逐个nc端口8848和7848，发现7848端口访问宿主机不通；

通过查看yaml找到pulicEndpaints:

 

    field.cattle.io/publicEndpoints: >-
      [{"addresses":["192.168.110Id":"conf:s-cjqgq"},{"addresses":["192.168.110.154"],"nodeId":"c-6zh2h:machine-jb8gk","port":8848,"protocol":"TCP"},{"addresses":["192.168.110.166"],"nodeId":"c-6zh2h:machine-qnmr5","port":8848,"protocol":"TCP"},{"addresses":["192.168.110.161"],"nodeId":"c-6zh2h:machine-vxqzd","port":8848,"protocol":"TCP"}].154"],"allNodes":true,"port":32753,"protocol":"TCP","service

 好家伙，没加注解；加上；

 好了，通了；

老生代降下来了：

 有状态3POD也不用一个手动启动，有状态本身就是顺序启动，我觉得data同步没那么傻；结果现在rancher点升级或重新部署，妥妥的好了。7484是raft端口，不通导致无法正确的选举；不知道为啥宿主机需要开放端口，pod是互通的；反正开了宿主机开放，好了；

结论：

nacos 3个pod，pod是端口互通的，宿主机端口7484raft不通，打通后；问题解决；