kubernetes系列--交付中pod出现CrashLoopBackOff不能启动问题排查

在交付dubbo服务时，kubectl apply dp.yaml执行之后，查看pod状态，发现STATUS为CrashLoopBackOff。发现这个问题之后就开始排查问题的所在。

一、首先查看pod的日志，发现是只有echo，并没有java -jar的前台启动，所以会出现启动了之后，立刻pod就停止了，就有此情况CrashLoopBackOff的发生。

解决方法：重新制作java的docker镜像，将exec的内容包含进去，确保可以在docker启动的时候前台执行java -jar xxx.jar

二、解决之后发现，jenkins打包并没有生效，发现是docker build时，没有修改tag，此时本地docker制作dubbo-server的docker镜像时，并不会认为 harbor总的java镜像与本地java镜像不一致。所以会继续沿用本地的java docker镜像，解决方法有2种：1、docker build -t 指定新的；2、手动删除本地的docker镜像，使其重新从harbor拉到最新的。

三、可能跟二类似，在kubectl apply -f xxxx.yaml，发现还是上面的情况。查看日志是连zk出现地址错误，所以修改了gitee中的某个值，使其能适应自己这边系统。

修改了gitee中的某个文件，也是在jenkins打包的时候，发现也能推送到harbor最新的，但是在pod运行，不管是删除pod重新生成，还是更新pod，都不能是使用最新的harbor中的镜像中的内容。所以还是怀疑，本地的docker镜像觉得tag一直，就没有与远端同步。

四、应该还有另一种解决方法。强制使用在kubectl apply -f xxx.yaml的时候，强制使用harbor.od.com中的最新景象。

五、生产打包时，每一次尽可能使用不同的tag。，这样就能避免因为同tag，导致本地不能与harbor端同步，进而影响服务的交付。