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

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

目前我们在推动租户上云的过程中，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，发现还是

目前在一套上云的环境中k8s用的是calico的vxlan模式，可以支持跨vpc的访问，但是在部署服务过程中发现服务之间无法互相访问，无论是通过域名/svc ip还是pod ip，只有访问自身是没有问题的如下图：因为我们集群的kube-proxy用的是iptables模式，第一个想到的就是查看下iptables的防火墙规则，看看路由转发到对应访问的服务主机上没有，查看了下也有相对应的路由规则，检查

随着现在更多环境的服务进行上云，对网关这块能实现的功能也比较关注，除了能正常的实现代理的作用，还需要可以进行比如：熔断，链路追踪，限流等，这里主要操作下对ingress的限流。首先还是需要在k8s集群上部署一个服务用来进行测试，我这里部署了一个nginx的pod，然后用ingress代理这个nginx服务，最后在ingress上做限流操作，通过访问ingress查看是否达到限流的作用。下面创建in