为何Amazon EKS v1.19集群中Secret自动刷新控制器的Deployment等资源被删除

一、Kubernetes 原生可查资源 #

• 查看资源事件记录
  执行kubectl describe deployment <你的Deployment名称> -n <部署命名空间>，查看Events字段的历史记录，另外可以通过kubectl get events -n <部署命名空间> --sort-by='.metadata.creationTimestamp'拉取对应命名空间下所有历史事件，重点关注类型为Deleted的事件，里面会记录操作发起的主体（ServiceAccount/用户）、操作时间。

  注意：K8s事件默认保留时间只有1小时，如果删除操作发生在更早之前，事件会被清理，需要查询其他日志。

• 检查etcd历史版本（如果有权限访问etcd的话）
  可以通过etcdctl命令拉取对应Deployment/Pod资源的历史版本，对比删除前后的配置变化，同时能查到操作关联的请求来源。
• 排查集群内其他有删除权限的主体
  执行kubectl get clusterroles,clusterrolebindings | grep -i delete，检查有删除Deployment、Service、Pod权限的ServiceAccount或用户，排查是否存在其他控制器（比如Argo CD、Flux这类GitOps工具）因为配置漂移主动删除了不在Git仓库内的资源，或者其他运维脚本、定时任务执行了删除操作。

二、Amazon EKS 特有排查路径 #

• 查看EKS审计日志
  如果你开启了EKS的审计日志功能，直接在CloudWatch Logs的/aws/eks/<集群名称>/cluster日志组下搜索audit相关日志，筛选请求verb为delete、资源类型为deployments、services、pods的请求，日志内会完整记录：
  • 操作发起的IP地址
  • 操作用户/ServiceAccount身份
  • 操作的精确时间
  • 操作的完整请求参数
    你使用的EKS 1.19版本已经支持完整的审计日志字段，可以直接定位到删除操作的发起方。
• 查看CloudTrail日志
  EKS的API调用都会记录到AWS CloudTrail中，CloudTrail默认会保留90天的操作记录，你可以在CloudTrail控制台筛选事件名为DeleteDeployment、DeleteService、DeletePod的事件，同样可以查到操作发起的身份（IAM用户/IAM角色）、来源IP、操作时间。
• 检查集群自动扩缩容/节点回收相关操作
  排查你删除时间节点是否有节点被回收、集群缩容的操作，不过这类操作只会删除Pod，不会删除Deployment和Service，所以如果Deployment和Service也被删除，基本可以排除节点层面的原因。

三、其他常规排查方向 #

• 检查资源是否配置了ownerReferences
  如果你创建的Deployment、Service配置了上层所有者引用，比如是某个Operator或者Helm release管理的资源，当上层所有者被删除时，这些关联资源会被级联删除，可以通过kubectl get deployment <名称> -n <命名空间> -o yaml | grep ownerReferences确认是否有该配置。
• 排查最近的集群操作记录
  检查集群运维人员近期是否执行过批量清理资源、卸载Helm包、回滚集群配置之类的操作，可能存在误删的情况。

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