主机重启后，kubelet比docker先启动，会对不健康的pod进行一个资源回收的过程，这个时候docker还没正常启动，kubelet无法调用docker的socket接口对镜像回收，会导致每五分钟一次的循环检查，默认到100次就会触发gc，会导致kubelet的pleg不健康，这个启动顺序还是很重要的。一环境主机重启后，查看kubelet日志经常有大量无法回收镜像文件报错，会导致kubele

主机重启后，kubelet比docker先启动，会对不健康的pod进行一个资源回收的过程，这个时候docker还没正常启动，kubelet无法调用docker的socket接口对镜像回收，会导致每五分钟一次的循环检查，默认到100次就会触发gc，会导致kubelet的pleg不健康，这个启动顺序还是很重要的。一环境主机重启后，查看kubelet日志经常有大量无法回收镜像文件报错，会导致kubele

1、对容器暴露的3306端口进行封堵：iptables -t mangle -APREROUTING-p tcp --dport 3306 -m comment --comment “iptables20210527” -j DROP2、查看mangle表的规则： 3、删除mangle表中对应的PREROUTING链的规则：iptables -t mangle -D PREROUTING 24、允

从如上分析来看，既然在coredns中已经配置了外部转发dns服务，租户如果继续在服务中还配置外部dns服务地址，就会导致应用服务会有两个dns nameserver,首先会访问集群内部域名地址会解析到pod中配置的那个外部dns服务中，会出现解析不了的情况，就反馈失败，然后轮到集群内部定义的dns服务就会正常解析成功。把在服务中配置dnscongfig相关参数去掉，让服务统一走集群内的cored

问题描述：因业务增长，需要添加新的node节点到openshift的集群，以满足业务的需求，但是节点加进openshift集群后，发现在主机上用域名和端口的形式是可以访问已经部署的服务，但是在新node节点上启动的容器，进入容器中，用域名加端口的形式访问，报错无法解析，curl 容器的svc ip加端口是没有问题的，具体访问情况如下：在主机上进行测试在新节点的容器内访问服务：解决问题过程：open

iptables -I DOCKER -s 192.168.133.130(放行备库mysql） -p tcp --dport 3306 -j ACCEPT。

当我们把服务部署到kubernetes集群上，除了基本的监控告警来锁定服务异常，通过人为干预来检查和恢复外，其实kubernetes也提供了针对服务的存活检查，那就是探针。可以通过探针检查服务的存活状态，一旦服务不正常，超过自己设置的检查数，就会重新拉起服务，接下来我们可以配置一个服务做演示：一、首先创建一个服务kubectl create deploy test1 --image=nginx:l

Docker可以通过阅读Docker中的指令来自动构建映像 Dockerfile。Dockerfile是一个文本文档，其中包含用户可以在命令行上调用以组合图像的所有命令。使用docker build 用户可以创建自动构建，该构建连续执行多个命令行指令。一、 将一个war包的程序构建成镜像想构建镜像，需要将war包，Dockerfile放在同一级目录下，还需要基础镜像才行1.1、先拉取一个基础镜像，

目前我们在推动租户上云的过程中，kubernetes集群的规模越来越大，对于整个集群的稳定性来说，肯定是不言而喻的，我这边维护上云租户使用的kubernetes集群基本上都是采用的虚拟机，各个项目规模达到一定规模，就会首当其冲出现etcd的性能问题，针对这个问题我们对etcd采取了迁移到好的裸金属主机上或者在虚拟机上挂上块存储，以下介绍我们在生产环境上执行etcd的三种迁移方式。情景一、三台etc

某上云项目中,k8s管理节点vip突然时不时无法访问了，针对这个问题，首先对vip发起了一个长ping;发现过一个就ping不通了，结果如下：然后查看keeplive的日志，两台主机会发生vip会时不时的争抢：因为我们在这两台主机上部署了三套keeplive，怀疑是这个原因导致，因为其他项目没有出现这个问题(其他项目是没有将几套keeplive都部署在两台主机上的），最终是更改keeplive的配