LGTM at a high level.

For some extra context, I'll copy over a comment from a previous discussion where @bgrant0607 said that api.LivenessProbe could be renamed to api.Probe.

Rather than renaming LivenessProbe, we could break the Actions into a Probe type and maintain {Context}Probes that hold a Probe and context specific configuration. e.g.

type Probe struct {
    HTTPGet   *HTTPGetAction   `json:"httpGet,omitempty"`
    TCPSocket *TCPSocketAction `json:"tcpSocket,omitempty"`
    Exec      *ExecAction      `json:"exec,omitempty"`
}

type LivenessProbe struct {
    Probe               Probe `json:",inline"`
    InitialDelaySeconds int64 `json:"initialDelaySeconds,omitempty"`
}

type ReadinessProbe struct {
    Probe              Probe `json:",inline"`
    TimeoutSeconds     int64 `json:"timeoutSeconds,omitempty"`
    FrequencySeconds   int64 `json:"frequencySeconds,omitempty"`
    UnhealthyThreshold int64 `json:"unhealthyThreshold,omitempty"`
    HealthyThreshold   int64 `json:"healthyThreshold,omitempty"`
}

I'm not sure if this is over thinking it as most settings could make sense for most contexts, but I can see a few benefits to this approach. We could add configs to ContextProbes as they become implemented (i.e. we wouldn't have config fields that do things in some spots and are unimplemented in others). We could also have Context specific configs. Alternatively, we could rename LivenessProbe to Probe and break out ContextProbes later on if needed.

Copying over my response from #3695:

I think all the fields you specify make sense for both types of probes. I do, however, like the factoring in your ReadinessProbe example -- splitting the probe specification from the control and interpretation parameters. That's similar to the factoring of Volume vs. VolumeSource. If we could unify it with the Handler type, it would be pretty compelling, addressing a long-standing TODO. Otherwise, I don't know that there's a practical benefit to clients. We could consider inlining the inner struct into the outer, if that's the case.

As per my previous comment, how about Probe rather than LivenessProbe? I think all the same fields can work for Readiness.

As for the bundle of actions, options are:

• Action
• Call
• Hook
• Handler

Obviously, if we did unify with Handler, we should implement TCP lifecycle hooks, though I'm happy to TODO that initially and just document it as a caveat.

I've renamed LivenessProbe to Probe and attempted to use the Handler type for the Actions so take a look. I'm happy to break the bundle into another type if Handler doesn't make sense yet. I'm having trouble imagining what a TCPSocket lifecycle handler would do/look like in configuration.

LGTM at a high level, also.

LGTM

I also want to run e2e on this. Assuming both of your PRs in this area pass, which do you want to go in first in case of merge?

@thockin It will be easier for me if #3695 goes first.

Needs a rebase, now. Blame yourself :)

@thockin this is ready.

running e2e against this now

e2e passes