PodEvict API does not trigger Pod deletion callback when DeleteOptions is set to metav1.NewDeleteOptions(0)

[PualrDwade]

What happened?

当我使用client-go组件的Evict API时，发现当设置了 DeleteOptions 为 metav1.NewDeleteOptions(0) 时，无法触发mutating webhook的Pod 删除回调, 当我不设置 DeleteOptions 时，可以正常触发

代码如下:

if err := cli.CoreV1().Pods("default").Evict(context.Background(), &policy.Eviction{
		TypeMeta: metav1.TypeMeta{
			Kind:       "Pod",
			APIVersion: "v1",
		},
		ObjectMeta: metav1.ObjectMeta{
			Name:      "pod-xxx",
			Namespace: "default",
		},
		DeleteOptions: metav1.NewDeleteOptions(0),
	}); err != nil {
		glog.Fatalf(err.Error())
	}

mutatingwebhookconfiguration:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: my-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  clientConfig:
    caBundle: xxxxx
    service:
      name: my-webhook-svc
      namespace: kube-system
      path: /delete/pod
      port: 443
  failurePolicy: Ignore
  matchPolicy: Exact
  name: delete-pod-webhook.test.org
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - DELETE
    resources:
    - pods
    scope: '*'
  sideEffects: Unknown
  timeoutSeconds: 30

What did you expect to happen?

我期望Evict API在设置了 DeleteOptions 为 metav1.NewDeleteOptions(0) 时，能够正常触发mutatingwebhook的Pod删除回调。

How can we reproduce it (as minimally and precisely as possible)?

1. 使用 k8s.io/client-go v0.21.2 创建一个客户端。
2. 使用 Evict API 并设置 DeleteOptions 为 metav1.NewDeleteOptions(0)。
3. 观察到mutatingwebhook的Pod删除回调没有被触发。

Anything else we need to know?

No response

Kubernetes version

$ cluster version
#  v1.20.6

$ client-go version
#  v0.21.2

Cloud provider

Tencent Kubernetes Engine (TKE)

OS version

No response

Install tools

No response

Container runtime (CRI) and version (if applicable)

No response

Related plugins (CNI, CSI, ...) and versions (if applicable)

No response

[liangyuanpeng]

$ cluster version

v1.20.6

kubernetes v1.20 is not a support version, and a better place to ask would be on the support channels. please see:
https://git.k8s.io/kubernetes/SUPPORT.md

/kind support

[pranav-pandey0804]

/sig api-machinery

[liggitt]

The webhook has to intercept the pods/eviction CREATE operation if it wants to observe this.

Eviction can trigger force deletion with gracePeriodSeconds: 0 which will immediately delete the pod unless it has a finalizer present.

[PualrDwade]

The webhook has to intercept the pods/eviction CREATE operation if it wants to observe this.

Eviction can trigger force deletion with gracePeriodSeconds: 0 which will immediately delete the pod unless it has a finalizer present.

thanks~ btw, where is the request for a resource to mention this scenario?

[PualrDwade]

The webhook has to intercept the pods/eviction CREATE operation if it wants to observe this.

Eviction can trigger force deletion with gracePeriodSeconds: 0 which will immediately delete the pod unless it has a finalizer present.

also, I've found that setting the same Options when calling pod delete API can triggers pod delete webhook

if err := cli.CoreV1().Pods("default").Delete(context.Background(), "pod-xxx", *metav1.NewDeleteOptions(0)); err != nil {
    glog.Panicln("delete pod error:", err)
}

[liggitt]

I've found that setting the same Options when calling pod delete API can triggers pod delete webhook

The admission webhook is intercepting the request that is made. In that case, a delete request is made on the pods resource, so admission registered for that endpoint+operation is called.

When making an eviction request to the eviction subresource with options that immediately remove the pod object, no explicit delete API call is made to the pods endpoint.

[leilajal]

/triage accepted