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

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

select concat(round(sum(DATA_LENGTH/1024/1024),2), ‘MB’) as data from information_schema.TABLES where table_schema=‘单库名称’;

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

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

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

一、现象说明我们在k8s集群上部署服务，发现在72段主机上的服务访问是都没有问题的；但是在161段主机有的服务可以访问；有的访问没有返回值；其中在161段主机访问没有返回值的服务；到服务所在的主机是可以访问的。二、解决过程针对上述现象，我们确定了这两个段的ip是在一个vpc的，互相访问是没有问题的，不然也不可能存在有的访问有返回值，有的没有返回值，截图如下：上图是我把grafana调到161段主机

在当今的体系结构中，运行在 ‘ClusterFirst’ DNS 模式下的 Pod 可以连接到 kube-dns serviceIP 进行 DNS 查询。node-local-dns 接口不能绑定 kube-dns 的集群 IP 地址，因为 IPVS 负载均衡使用的接口已经占用了该地址。：集群内的服务基本都是通过域名进行访问，coredns在解析压力大时会存在慢或者丢包的情况，导致服务之间解析异常

k8s集群出现一台主机calico重启，无法重新添加路由当时查看了下kubelet的日志，发现有报错证书无效，查看了集群内其它环境主机，路由都正常，按理说不应该是证书无效才对开始看下calico的日志，发现有报Liveness probe failed: calico/node is not ready: bird/confd is not live: exit status 1 /BIRD is

一、场景描述用户无法正常访问部署在k8s上的服务和使用我们的PaaS平台。二、问题描述某环境的etcd集群全部挂掉，导致k8s集群部署的服务都无法正常提供使用，查看etcd状态和报错日志，如图所示：图中报错显示etcd成员的空间不足三、问题处理过程描述当时根据etcd的报错日志，先到对应的主机查看了下磁盘和内存的使用情况，发现etcd所在的主机资源都是充足的，然后一起重启了下三台etcd，发现还是