1 背景：

使用kubebuilder来开发vpa相关的operator，这个operator会watch集群里的所有的vpa创建和删除和更新，controller-runtime提供了predictate来过滤调不需要的事件，使用predicate.GenerationChangedPredicate过滤掉vpa更新status。但是却发现vpa的status更新（由vpa-recommender更新推荐值）也触发了Reconcile。

遇到奇怪的现象：spark生成的job pod大概率都调度到同一节点，即不同的job的pod都会调度到同一节点，pod过于集中在某个节点上，出现调度不均衡现象。节点没有任何污点，节点资源空闲程度差不多。job没有任何nodeSelector、nodeAffinity、nodeName、PodTopologySpread。

vpa介绍

vpa全称Vertical Pod Autoscaler ，它是google论文Autopilot: Workload Autoscaling at Google Scale的开源实现。它根据pod里的container的历史监控数据来推荐container的request资源，即vpa扩容是直接修改pod里的resource的request、limit（可以在vpa资源里配置只修改request或limit和request都修改）。

kubernetes提供了修改pod的/etc/resolv.conf文件配置方法，即spec.dnsConfig和spec.dnsPolicy，具体可以访问[Customizing DNS Service]，但是这种方法会导致pod重新生成。

我们有个业务场景：pod访问本地的localdns方式，取代中心化的访问coredns。kubelet的cluster dns配置已经改成localdns地址，但是在变更之前生成的pod还是使用coredns，需要将这部分pod的dns的nameserver改成localdns。但是不能主动删除pod或重启container（这的确不是一个好的容器使用方式（把容器当成宠物），这里公司文化决定的（业务程序没有实现优雅退出））。 即需要将pod直接访问coredns进行域名解析方式，切换到pod访问本地的node local dns，但是不能让pod进行重启。

背景

kubernetes集群版本从1.18升级到1.23后出现许多运行正常的pod，由于liveness probe失败导致重启，还有一些是readiness probe失败。

起初怀疑pod重启，不应该是kubernetes升级导致的，由于1.18和1.23版本的container hash算法没有修改，所以升级kubelet不会导致已经运行的container重新生成。后面排查到pod重启时间在kubernetes升级之后，不是升级那个时间。所以可以排除升级kubelet导致的重启。

最近在开发cni网络插件，遇到容器访问service的loadbalancer地址不通。但是访问pod、service、node的地址都是通的。

背景： 有两个版本的kubernetes 1.18.20和1.21.8，kubelet使用systemd启动并且相同启动参数，kubernetes v1.21版本中没有容器相关数据，而v1.18版本确有容器相关监控数据。操作系统是centos7。