如何追踪Kubernetes中自动恢复的Secret资源创建来源

• 启用并分析审计日志
  如果集群未开启审计日志，临时配置kube-apiserver的审计策略以捕获Secret的CREATE事件。等Secret恢复后，从kube-apiserver的日志中过滤相关请求：

  kubectl logs -n kube-system <kube-apiserver-pod-name> | grep "app-secret" | grep "CREATE"
  

  日志会包含发起创建请求的用户标识、客户端IP、调用的API路径等关键信息，可直接定位来源。

• 全面排查定时执行逻辑
  除了CronJob，还要覆盖以下场景：

  • 所有Pod内的定时任务：遍历Pod执行命令查看crontab配置

    kubectl exec -n <目标命名空间> <pod-name> -- crontab -l
    

    同时检查Pod的启动命令/参数中是否包含定时创建Secret的脚本逻辑。
  • 集群节点上的系统定时任务：登录节点查看/var/spool/cron/、/etc/cron.d/目录下的定时配置文件，确认是否有节点级别的定时脚本会重建Secret。

• 检查CRD关联的控制器逻辑
  从提供的CRD列表看，集群包含Rancher（management.cattle.io）、Calico、Banana Cloud Logging等组件，这些组件的控制器可能自动创建资源：

  • 检查Rancher相关资源，确认是否有集群/项目级配置会同步这个Secret：

    kubectl get clusters.management.cattle.io -A -o yaml | grep "app-secret"
    kubectl get settings.management.cattle.io -A -o yaml | grep "app-secret"
    

  • 检查Banana Cloud Logging资源，看是否有日志输出/流配置引用该Secret，导致控制器自动重建：

    kubectl get loggings.logging.banzaicloud.io -A -o yaml | grep "app-secret"
    

• 分析Secret的所有权与关联资源
  查看Secret的所有者引用，确认是否被其他Kubernetes资源管控：

  kubectl describe secret app-secret
  

  重点关注OwnerReferences字段，如果存在关联资源（如Deployment、CR实例），该资源的控制器可能会在Secret缺失时重建它。同时，排查所有引用该Secret的资源：

  kubectl get deployments,statefulsets,daemonsets -A -o yaml | grep "app-secret"
  

• 实时监控API Server请求
  持续监控集群事件，或直接抓包API Server的流量：

  • 实时监控事件：

    kubectl get events -w | grep "app-secret"
    

  • 使用tcpdump在控制节点抓取API Server（默认6443端口）的流量，过滤POST请求（Secret创建用POST）：

    tcpdump -i any port 6443 and host <kube-apiserver-ip> and 'tcp[13]&24!=0'
    

• 排查集群外部自动化工具
  检查CI/CD工具（Jenkins、GitLab CI）的定时任务，或配置管理工具（Ansible、Terraform）的执行计划，确认是否有定期同步Kubernetes资源的操作会重建该Secret。查看这些工具的任务执行日志，定位是否有相关的资源部署记录。

内容的提问来源于stack exchange，提问作者paws