背景

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事件分析出，某个组件做了什么动作。

1 概述

在云上让集群外部流量访问k8s，通常的做法是使用loadbalance类型的service，让外部流量通过loadbalance进入到ingress controller，然后分发到各个pod。