Add image_id to CRI ContainerStatus message

[saschagrunert]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

There is a conversion function ConvertPodStatusToRunningPod, which can override the Container.ImageID into a digested reference from the ContainerStatus CRI RPC, which gets mapped from the image_ref:

kubernetes/pkg/kubelet/container/helpers.go

Lines 259 to 292 in 411c29c

	// ConvertPodStatusToRunningPod returns Pod given PodStatus and container runtime string.
	// TODO(random-liu): Convert PodStatus to running Pod, should be deprecated soon
	func ConvertPodStatusToRunningPod(runtimeName string, podStatus *PodStatus) Pod {
	runningPod := Pod{
	ID: podStatus.ID,
	Name: podStatus.Name,
	Namespace: podStatus.Namespace,
	}
	for _, containerStatus := range podStatus.ContainerStatuses {
	if containerStatus.State != ContainerStateRunning {
	continue
	}
	container := &Container{
	ID: containerStatus.ID,
	Name: containerStatus.Name,
	Image: containerStatus.Image,
	ImageID: containerStatus.ImageID,
	ImageRuntimeHandler: containerStatus.ImageRuntimeHandler,
	Hash: containerStatus.Hash,
	HashWithoutResources: containerStatus.HashWithoutResources,
	State: containerStatus.State,
	}
	runningPod.Containers = append(runningPod.Containers, container)
	}
	// Populate sandboxes in kubecontainer.Pod
	for _, sandbox := range podStatus.SandboxStatuses {
	runningPod.Sandboxes = append(runningPod.Sandboxes, &Container{
	ID: ContainerID{Type: runtimeName, ID: sandbox.Id},
	State: SandboxToContainerState(sandbox.State),
	})
	}
	return runningPod
	}

To avoid that failure case, we now introduce the same image_id into the container status and let runtimes separate the fields.

We also add a note that the mapping from the digested reference of the CRI to the Kubernetes Pod API ImageID field is intentional and should not change.

Which issue(s) this PR fixes:

Follow-up on: #123508

Special notes for your reviewer:

PTAL @mrunalp @haircommander @mikebrow @kubernetes/sig-node-pr-reviews

This is not a bug, it's preventing internal API misusage to create one.

Does this PR introduce a user-facing change?

None

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

None

[mrunalp]

@mikebrow @SergeyKanzhelev ptal

[haircommander]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 23b84deeaad2ffe9918b5d701b66ca6469283d79

[bart0sh]

/triage accepted
/priority important-longterm

[bart0sh]

/cc @mrunalp @SergeyKanzhelev

[mikebrow]

LGTM

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mikebrow, mrunalp, saschagrunert

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/kubelet/OWNERS [mrunalp]
• staging/src/k8s.io/cri-api/OWNERS [mikebrow,mrunalp,saschagrunert]

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