如何归因Kubernetes资源创建

huangapple
go评论93阅读模式
英文:

How to attribute Kubernetes resource creation

问题

我遇到一个奇怪的问题，我之前创建的一个Kubernetes资源，然后通过 kubectl 删除了，但它神秘地又回来了。这是一个普通的Kubernetes集群（没有运算符），我应该是集群的唯一用户。

  1. $ kubectl get secret app-secret
  2. NAME         TYPE     DATA   AGE
  3. app-secret   Opaque   2      1d
  5. $ kubectl delete secret app-secret
  6. secret "app-secret" deleted

第二天：

  1. $ kubectl get secret app-secret
  2. NAME         TYPE     DATA   AGE
  3. app-secret   Opaque   2      3h

我想追踪是谁/哪个实体把它带回来的。

我尝试检查 CronJobs，因为资源重新创建的时间似乎是每24小时的固定时间。但在那里没有找到线索。

我还尝试检查Secret的YAML定义，希望能找到某种“创建者”或“作者”字段。

  1. apiVersion: v1
  2. kind: Secret
  3. type: Opaque
  4. metadata:
  5.   name: app-secret
  6.   creationTimestamp: "2023-04-04T04:18:33Z"
  7.   namespace: default
  8.   resourceVersion: "39713521316"
  9.   uid: 36eb0332-ea37-43d3-8034-4e47a8ebcd43
  10. data:
  11.   foo: YmFy

但在那里也没有找到线索。

我还尝试使用 kubectl event，但是事件似乎不包括 Secrets。

这是CRD：

  1. kubectl get crd 
  2. NAME                                                  CREATED AT
  3. # 省略了其余的CRD

我刚刚再次删除了它，但是在24小时内它可能会再次出现。

有哪些方法可以追踪到底是什么原因造成了这个问题？

英文:

I'm experiencing a weird issue where a k8s resource I previously created, then subsequently deleted via kubectl is being mysteriously coming back. It's a vanilla k8s cluster (no operators), and I should be the only user of the cluster.

  1. $ kubectl get secret app-secret
  2. NAME         TYPE     DATA   AGE
  3. app-secret   Opaque   2      1d
  5. $ kubectl delete secret app-secret
  6. secret "app-secret" deleted

The next day:

  1. $ kubectl get secret app-secret
  2. NAME         TYPE     DATA   AGE
  3. app-secret   Opaque   2      3h

I'd like to track down who/which entity brought it back.

I tried to review CronJobs because the resource recreation time appears to be the same walltime every 24 hrs. No luck there.

I also tried checking the YAML definition of the secret in hopes of finding some kind of 'creator' or 'author' field.

  1. apiVersion: v1
  2. kind: Secret
  3. type: Opaque
  4. metadata:
  5.   name: app-secret
  6.   creationTimestamp: "2023-04-04T04:18:33Z"
  7.   namespace: default
  8.   resourceVersion: "39713521316"
  9.   uid: 36eb0332-ea37-43d3-8034-4e47a8ebcd43
  10. data:
  11.   foo: YmFy

No luck there either.

I also tried kubectl event, but the events don't appear to include Secrets.

Here are the CRDs

  1. kubectl get crd 
  2. NAME                                                  CREATED AT
  3. alertmanagers.monitoring.coreos.com                   2020-11-27T16:26:59Z
  4. apiservices.management.cattle.io                      2021-10-06T19:38:28Z
  5. apps.catalog.cattle.io                                2020-11-27T16:27:04Z
  6. authconfigs.management.cattle.io                      2021-10-06T19:38:30Z
  7. bgpconfigurations.crd.projectcalico.org               2020-11-27T16:05:00Z
  8. bgppeers.crd.projectcalico.org                        2020-11-27T16:05:00Z
  9. blockaffinities.crd.projectcalico.org                 2020-11-27T16:05:00Z
  10. caliconodestatuses.crd.projectcalico.org              2022-10-04T02:32:09Z
  11. clusterflows.logging.banzaicloud.io                   2022-01-14T14:43:04Z
  12. clusterinformations.crd.projectcalico.org             2020-11-27T16:05:01Z
  13. clusteroutputs.logging.banzaicloud.io                 2022-01-14T14:43:05Z
  14. clusterregistrationtokens.management.cattle.io        2021-10-06T19:38:28Z
  15. clusterrepos.catalog.cattle.io                        2020-11-27T16:27:04Z
  16. clusters.management.cattle.io                         2020-11-27T16:27:03Z
  17. features.management.cattle.io                         2020-11-27T16:27:04Z
  18. felixconfigurations.crd.projectcalico.org             2020-11-27T16:04:49Z
  19. flows.logging.banzaicloud.io                          2022-01-14T14:43:04Z
  20. globalnetworkpolicies.crd.projectcalico.org           2020-11-27T16:05:01Z
  21. globalnetworksets.crd.projectcalico.org               2020-11-27T16:05:01Z
  22. groupmembers.management.cattle.io                     2021-10-06T19:38:31Z
  23. groups.management.cattle.io                           2021-10-06T19:38:31Z
  24. hostendpoints.crd.projectcalico.org                   2020-11-27T16:05:01Z
  25. ipamblocks.crd.projectcalico.org                      2020-11-27T16:04:59Z
  26. ipamconfigs.crd.projectcalico.org                     2020-11-27T16:05:00Z
  27. ipamhandles.crd.projectcalico.org                     2020-11-27T16:05:00Z
  28. ippools.crd.projectcalico.org                         2020-11-27T16:05:00Z
  29. ipreservations.crd.projectcalico.org                  2022-10-04T02:32:16Z
  30. kubecontrollersconfigurations.crd.projectcalico.org   2022-10-04T02:32:17Z
  31. loggings.logging.banzaicloud.io                       2022-01-14T14:43:04Z
  32. navlinks.ui.cattle.io                                 2021-10-06T19:38:28Z
  33. networkpolicies.crd.projectcalico.org                 2020-11-27T16:05:02Z
  34. networksets.crd.projectcalico.org                     2020-11-27T16:05:02Z
  35. nodepools.kube.cloud.ovh.com                          2020-11-27T16:02:54Z
  36. operations.catalog.cattle.io                          2020-11-27T16:27:04Z
  37. outputs.logging.banzaicloud.io                        2022-01-14T14:43:05Z
  38. preferences.management.cattle.io                      2020-11-27T16:27:04Z
  39. prometheuses.monitoring.coreos.com                    2020-11-27T16:26:58Z
  40. prometheusrules.monitoring.coreos.com                 2020-11-27T16:26:59Z
  41. servicemonitors.monitoring.coreos.com                 2020-11-27T16:27:00Z
  42. settings.management.cattle.io                         2020-11-27T16:27:04Z
  43. tokens.management.cattle.io                           2021-10-06T19:38:31Z
  44. userattributes.management.cattle.io                   2021-10-06T19:38:31Z
  45. users.management.cattle.io                            2021-10-06T19:38:31Z
  46. volumesnapshotclasses.snapshot.storage.k8s.io         2020-11-27T16:05:48Z
  47. volumesnapshotcontents.snapshot.storage.k8s.io        2020-11-27T16:05:48Z
  48. volumesnapshots.snapshot.storage.k8s.io               2020-11-27T16:05:48Z

I just deleted it again, but in 24h it's likely going to be back.

What are ways I might track this down?

答案1

得分: 1

检查是否正在使用CD工具，如ArgoCD，这些工具可以重新创建资源，以保持应用程序处于所需状态。
还要检查是否安装了CRDs，某些CRDs可能负责保持某些资源处于所需状态。

英文:

Check if you are using CD tools like ArgoCD, these tools could recreate resources to keep applications in desired state.
Also check for any installed CRDs, some CRDs might take responsibility of keeping some resources in a desired state.

huangapple
  • 本文由 发表于 2023年4月4日 12:42:14
  • 转载请务必保留本文链接：https://go.coder-hub.com/75925577.html
  • kubernetes
  • kubernetes-secrets
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定