117 Kubernetes部署Agent服务那晚的告警到现在还记得，新上线的采集Agent在测试集群里一会儿Running一会儿CrashLoopBackOff，kubectl logs抓出来就一行“Failed to create Kubernetes client: can’t create rest client: dial tcp: lookup kube-apiserver on 10.96.0.10:53: no such host”。直觉告诉我不是网络问题，K8s内网DNS正常得很。后来发现是Agent启动时读取的配置里，kube-apiserver地址写成了集群外部的域名，Pod里的DNS解析策略又默认是ClusterFirst，压根儿走不出去。一个配置项浪费了我一小时。Agent部署到K8s，看着和普通服务差不多的套路，真正跑起来全是细节。先把结论放这儿：Agent和Web服务在K8s上的部署理念完全不同。Web服务是被动等连接，Agent是主动外连或者跑定时任务，对网络出口、宿主环境、生命周期清理都有额外要求。用Deployment模板直接套，早晚出幺蛾子。部署形态上先分清楚。如果你的Agent要采集每个节点的系统指标、容器日志、网络流量，那必须用DaemonSet，保证每个Node上一个Pod。用Deployment加replicas会有调度偏差，节点数量一变你就得手动扩缩容，而且Pod可能扎堆到同一台机器上，别的节点漏采。反过来，如果Agent是业务侧的同步组件，一个服务需要两三个副本做容灾，那Deployment更合适。还有种定时扫描Agent，跑完就退出的，用Job/CronJob，别用Deployment，不然P
117 Kubernetes部署Agent服务那晚的告警到现在还记得，新上线的采集Agent在测试集群里一会儿Running一会儿CrashLoopBackOff，kubectl logs抓出来就一行“Failed to create Kubernetes client: can’t create rest client: dial tcp: lookup kube-apiserver on 10.96.0.10:53: no such host”。直觉告诉我不是网络问题，K8s内网DNS正常得很。后来发现是Agent启动时读取的配置里，kube-apiserver地址写成了集群外部的域名，Pod里的DNS解析策略又默认是ClusterFirst，压根儿走不出去。一个配置项浪费了我一小时。Agent部署到K8s，看着和普通服务差不多的套路，真正跑起来全是细节。先把结论放这儿：Agent和Web服务在K8s上的部署理念完全不同。Web服务是被动等连接，Agent是主动外连或者跑定时任务，对网络出口、宿主环境、生命周期清理都有额外要求。用Deployment模板直接套，早晚出幺蛾子。部署形态上先分清楚。如果你的Agent要采集每个节点的系统指标、容器日志、网络流量，那必须用DaemonSet，保证每个Node上一个Pod。用Deployment加replicas会有调度偏差，节点数量一变你就得手动扩缩容，而且Pod可能扎堆到同一台机器上，别的节点漏采。反过来，如果Agent是业务侧的同步组件，一个服务需要两三个副本做容灾，那Deployment更合适。还有种定时扫描Agent，跑完就退出的，用Job/CronJob，别用Deployment，不然P
