This is mostly for symmetry since many folks that validate PodSpecable types often also want to validate `Pod`, so while `Pod` isn't as often a duck-type, the main value of this is exposing similar mechanisms to #2279 for `corev1.Pod` without folks needing to define their own `corev1.Pod` clone.
Today you can't use `duckv1.WithPod` to author webhooks because it doesn't implement the `Validate` or `SetDefaults` methods, and that makes sense since they are (by definition) a generic encapsulation of a number of types.
However, if we could infuse `ctx` with appropriate callbacks for `Validate` and `SetDefaults` then folks can use our types, but infuse `ctx` with callbacks that perform the appropriate validation.
What I have in mind is something along these lines:
```go
return defaulting.NewAdmissionController(ctx,
// Name of the resource webhook.
"foo.bar.dev",
// The path on which to serve the webhook.
"/defaulting",
// The resources to default.
map[schema.GroupVersionKind]resourcesemantics.GenericCRD{
appsv1.SchemeGroupVersion.WithKind("Deployment"): &duckv1.WithPod{},
appsv1.SchemeGroupVersion.WithKind("ReplicaSet"): &duckv1.WithPod{},
appsv1.SchemeGroupVersion.WithKind("StatefulSet"): &duckv1.WithPod{},
appsv1.SchemeGroupVersion.WithKind("DaemonSet"): &duckv1.WithPod{},
batchv1.SchemeGroupVersion.WithKind("Job"): &duckv1.WithPod{},
},
// A function that infuses the context passed to Validate/SetDefaults with custom metadata.
func(ctx context.Context) context.Context{
return duckv1.WithPodSpecDefaulter(ctx, myFancyLogic)
},
// Whether to disallow unknown fields.
false,
)
```
It is roughly equivalent for validation.
Matt Moore