PLEG定期检查节点上Pod运行情况，并且会把pod 的变化包装成Event发送给Kubelet的主同步机制syncLoop去处理。但是，在PLEG的Pod检查机制不能定期执行的时候，NodeStatus机制就会认为这个节点的状况是不对的，从而把这种状况同步到API Server，我们就会看到 not ready。异常容器虽然已经僵死，kubelet得不到该容器反馈，在PLEG的Pod检查机制不能

开启这个功能是有很大风险的，服务器端会根据同一个 IP 发送过来的包的时间戳来判断是否丢包，而时间戳是根据发包的客户端的系统时间得来的，如果服务端收到的包是同一出口 IP 而系统时间不一样的两个客户端的包，就有可能会丢包，可能出现的情况就是一个局域网内有的客户端能连接服务端，有的不能。具体原因是客户端处于NAT模式下，出口ip可能是同一个ip，不同客户端的发送的时间戳可能乱序，服务器会检查相同ip

部署环境HostIPk8s 版本glusterFS版本heketi版本heketi-client 版本k8s-master1192.168.10.11.20.09.5-1.el7heketi-8.0.0-1heketi-client-8.0.0-1k8s-master2192.168.10.21.20.09.5-1.el7heketi-8.0.0-1heketi-client-8.0.0-1k8s

背景公司内大部分 pod 因为特殊环境使用的 host 网络，最近无意中发现，有一个 pod 无法解析 k8s 的 service，于是展开了后面的排查排查步骤查阅百度发现文章都是一群人一个抄一个，句句不在点子上，如...

通过脚本将kubeadm证书延期10年前言kubernetes 集群证书是各个组件交互的一个凭证，证书过期之后回直接影响到集群的使用，且kubeadm的证书默认有效期是1年，因此证书做延期，我们义不容辞。检查下当前证书的有效期[root@k8s-master ]# kubeadm alpha certs check-expiration[check-expiration] Reading conf

单节点kubernetes机器image意外被删除问题介绍原因分析整改方案问题介绍公司业务环境更新迭代，镜像有点大，但是tar包就100多G，解压后大概三四百G，新来员工未考虑到磁盘空间的问题（默认1T），导致空间不足，解压完成后发现，k8s环境镜像除了k8s核心组件pod(apiserver/scheduler/controller)，其余的全部被驱逐，重启pod发现没有镜像，docker im