如何动态解析ownerReference（Helm CHart）中的UID

Question

我有一个带有部署和作业对象的简单舵图

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-parent
spec:
  selector:
    matchLabels:
      app: {{ .Release.Name }}-parent
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-parent
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          
          # Add other container configuration as needed

和工作对象

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-job
  ownerReferences:
    - apiVersion: apps/v1
      blockOwnerDeletion: true
      controller: true
      kind: Deployment
      name: {{ .Release.Name }}-parent
      uid: $(kubectl get deployment my-release-parent -o jsonpath='{.metadata.uid}')
spec:
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-job
    spec:
      containers:
        - name: busybox
          image: busybox:latest
      restartPolicy: Never
          # Add other container configuration as needed
      # Add other Job configuration as needed

我正在尝试将部署对象的

UID

动态解析为作业清单中的

onwnerReference

。现在，如果我部署此图表，除了无法部署的作业外，一切正常。当我从作业清单中删除

ownerReference

时，

job

会完美部署，所以我知道问题与我解析

UID

的方式有关..

我想要一种情况，每当我删除部署时，它都会删除所有子资源。 查看更多：onwer参考

我尝试了不同的方法来动态解析 UID，如果我在部署后直接运行命令，此代码就可以工作。

kubectl get deployment deploymentexample -o yaml | grep uid | cut -d ' ' -f 4

kubectl get deployment my-release-parent -o jsonpath='{.metadata.uid}'

Answer 1

使用 Helm 查找：

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Release.Name }}-job
  {{- $parentDeployment := lookup "apps/v1" "Deployment" .Release.Namespace (printf "%s-parent" .Release.Name) }}
  {{- if $parentDeployment }}
  ownerReferences:
    - apiVersion: apps/v1
      blockOwnerDeletion: true
      controller: true
      kind: Deployment
      name: {{ .Release.Name }}-parent
      uid: {{ $parnetDeployment.metadata.uid }}
  {{- end }}
spec:
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-job
    spec:
      containers:
        - name: busybox
          image: busybox:latest
      restartPolicy: Never
          # Add other container configuration as needed
      # Add other Job configuration as needed

但是正如对您的问题的评论中提到的，如果

Deployment

和

Job

部署在同一个 Helm 图表中，这将不起作用。

如果在

helm upgrade

期间创建作业，它们已经具有

ownerRefference

，因为在升级期间部署已存在于集群中。

---

尽管如此，我认为

Helm hooks

会更适合您的项目。

例如，您可以使用以下注释创建作业：

annotations:
  helm.sh/hook: post-install,post-upgrade
  helm.sh/hook-delete-policy: before-hook-creation

并在每次安装或升级操作后创建动态作业。