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

一、某上云项目用网关来代理数据库的背景财务的服务在k8s集群外部，想连接数据库，就只能通过直连数据库的主机ip+prot的形式才能建立连接，但是却达不到高可用的目的，然后通过网关代理数据库的方式以达到高可用的目的。二、某上云项目网关代理数据库出现的问题财务的数据库改为网关代理的方式和外部服务建立连接以来，出现断断续续的服务连接中断，然后外部服务无法再次进行和网关的连接，只有重启外部服务，才能再次的

解决kubernetes集群中服务之间通过svc无法访问问题项目场景：应用上云，服务都是通过kubernetes集群上进行发布，集群内的服务之间都是通过svc ip 进行连接问题描述：通过租户反应，他们部署到kubernetes集群上个别服务突然通过svc无法进行连接了原因分析：首先进入后台查看无法正常连接的服务是否正常，get po 看了下，发现无法访问的pod的状态也是没有问题的，get sv