Repository: kubernetes
Issue: Clarify ContainerStatus.Started null value and initialize the value for Init containers
Labels: sig/node,sig/architecture,needs-triage

This issue is to discuss whether we can change the `Started` field of `ContainerStatus` from pointer to non-pointer bool value. The pointer type is inconsistent with other field `Ready`. The semantic of `Started` being `null` is undefined and it is not ideal if users will use `Started` field `null` value as indication of a spacial condition beyond what `false` indicates. So if there is a process of making field non-pointer after skew period has passed, it would be great to follow it.

The field was introduced as a pointer following [this suggestions](https://github.com/kubernetes/kubernetes/pull/77807#discussion_r289542539:): 

> If this is optional, it needs to be a pointer. We can't add non-optional fields, ergo this should be a pointer. Otherwise an old client will not set it and it will be false, which is super confusing.

The field long passed it's skew inconsistency period.

The field is set by prober_manager: https://github.com/kubernetes/kubernetes/blob/0e3818e02760afa8ed0bea74c6973f605ca4683c/pkg/kubelet/prober/prober_manager.go#L270

## Current behavior

The PR: https://github.com/kubernetes/kubernetes/pull/115463 improves the documentation for the `Started` field of `ContainerStatus`. We never declared when `null` value means for the `ContainerStatus`.

For regular container:
- Field is `null` before the `prober_manager` starts.
- Field is `false` once `prober_manager` started.
- Field is `true` when no startup probes defined or once startup probe succeeded.

For Init and ephemeral containers:
- Field is always `null` as those do not start the `prober_manager`.

`StartedAt` field of `Status` type is always populated for both - regular and Init containers. It is populated earlier than `Started` will be set by `prober_manager`. So there is period of time when `StartedAt` has a date and `Started` is `null`.

There is also `Ready` field on `ContainerStatus` that is not a pointer. It will be `false` from the Pod creation and will change to `true` while readiness probes succeed.

## Changes for sidecar containers

The question about this field came up because we plan to use it for https://github.com/kubernetes/enhancements/issues/753. Also resolving this would clarify the field that needs to be added as part of that same KEP.

We need a signal for sidecar containers KEP to indicate that the sidecar container started and other containers initialization can proceed. We believe that relying on `Started` field would be the best option. So we will initialize the `Started` field for sidecar containers and there will be logic relying on it.

## Proposal

- Change `Started` type from `*bool` to `bool`.
- This changes behavior for Init Containers and Pods before they received by the kubelet - value will be `false` instead of `null`
- Clearly document the difference between `ContainerStatus.Started` and `ContainerStatus.State.StartedAt` fields.
- For sidecar container KEP use the `Started` field as a signal that sidecar container started and ready to proceed with other containers initialization.


/sig architecture
/sig node
/label api-review
//cc @matthyx @dims 

Discussion in Slack: https://kubernetes.slack.com/archives/CJUQN3E4T/p1675467718491919