Second attempt: Plumb context to Kubelet CRI calls

[dashpole]

Related to #113566.

Second attempt at #113408, which was reverted in #113548

What type of PR is this?

/kind feature

What this PR does / why we need it:

Plumb context to kubelet CRI calls.

This includes two additional commits on-top-of the original PR.

The "clean up extra timeouts" commit fixes a confusing place where we set the same timeout on a context twice, identified here: #113408 (comment).

The "try fixing incorrectly canceled context" commit ignores the incoming context from the pod worker. I believe this will fix the test failure.

Which issue(s) this PR fixes:

Part of #113414

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: [Kubelet tracing KEP](https://github.com/kubernetes/enhancements/issues/2831)

cc @liggitt @dims @bobbypage @dchen1107 @aojea

[dashpole]

/sig node

[dims]

/approve
/lgtm

Let's try again! :)

[dashpole]

cc @sallyom

[smarterclayton]

Let's have a chat about this - #107829 dealt with the correct behavior that getting context into the Kubelet so that we could reduce propagation latency of "pod termination requests" (which leads to measurable end user outcomes). There are probably fixes in 107829 that address the issues involved, but I would like to review this before we put it in again.

[smarterclayton]

It looks like this attempt doesn't try to fix all of the context propagation in the kubelet, is that correct? I took a maximalist approach in my change, but it didn't have to be that way.

[dashpole]

It looks like this attempt doesn't try to fix all of the context propagation in the kubelet, is that correct? I took a maximalist approach in my change, but it didn't have to be that way.

My primary goal was to propagate context from SyncPod -> CRI calls for tracing purposes. See #113414. There are definitely plenty of other places in the kubelet where context would be helpful (Device plugins, CNI, probably others). During the process of plumbing SyncPod -> CRI, I had to add context to functions that were used elsewhere, and used existing contexts where possible.

[smarterclayton]

After our discussion we agreed that for sync*Pods having a context.TODO() with a go comment pointing to #113606 will unblock us.

/hold cancel

[dashpole]

Cluster didn't come up

Master not detected. Is the cluster up?

/retest

[dims]

@dashpole where are you seeing this?

[dashpole]

where are you seeing this?

@dims
https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/113591/pull-kubernetes-node-e2e-containerd/1588273024799346688

[aojea]

/label tide/merge-method-squash

[dims]

looks like most recent run of pull-kubernetes-e2e-gce-ubuntu-containerd is 💚

[dims]

/triage accepted
/priority important-soon
/milestone v1.26
/assign @liggitt

[dashpole]

/assign @mrunalp

[mrunalp]

/approve

[klueska]

/approve
for changes in staging/src/k8s.io/cri-api/

[dims]

/approve
/lgtm

let's try this again.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dashpole, dims, klueska, mrunalp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/client/OWNERS [dims]
• pkg/kubelet/OWNERS [dims,klueska,mrunalp]
• staging/src/k8s.io/cri-api/pkg/OWNERS [klueska,mrunalp]
• test/e2e_node/OWNERS [dims,klueska,mrunalp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sallyom]

late to the party but yay! 🥳