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。

目前knative v1.1.0版本还是基于域名进行转发流量到服务。

而大多数使用场景是：

1. 服务对外域名一般都是固定的，而且可能有多个。
2. 服务一般都是在域名的某一路径下面，即一个域名由多个服务组成。
3. 灰度基于多个header头之间and or关系。

下面讨论如何实现这些需求

kubelet中的podConfig是用来汇聚多个pod来源，对多个pod源中的pod信息进行聚合处理（去重、分析出pod发生的变化）。如果源里的pod发生变化，podConfig会将变化更新聚合，生成各类型的PodUpdate消息发送到PodUpdate通道。

当要排查集群中某个问题时候，一般通过两种方式来排查问题。一种是查看各个组件日志，确定问题；另一个是通过apiserver获取event事件，根据event事件分析出，某个组件做了什么动作。