Add language to make it explicit that annotations are not to be altered
by runtimes, and should only be used for features that are opaque to the
Kubernetes APIs. Unfortunately there are currently exceptions
introduced in [1][1], but this change makes it clear that they are to be
changed and that no more such semantic-affecting annotations should be
introduced.
In the spirit of the discussion and conclusion in [2][2].
Also captures the link between the annotations returned by various
status queries and those supplied in associated configs.
[1]: https://github.com/kubernetes/kubernetes/pull/34819
[2]: https://github.com/kubernetes/kubernetes/issues/30819#issuecomment-253369441
Automatic merge from submit-queue (batch tested with PRs 38727, 38726, 38347, 38348)
Add 'privileged' to sandbox to indicate if any container might be privileged in it, document privileged
Right now, the privileged flag is this magic thing which does "whatever Docker does". This documents it to make it a little less magic.
In addition, due to how rkt uses `systemd-nspawn` as an outer layer of isolation in creating the sandbox, it's helpful to know beforehand whether the pod will be privileged so additional security options can be applied earlier / applied at all.
I suspect the same indication will be useful for userns since userns should also occur at the pod layer, but it's possible that will be a separate/additional field.
cc @lucab @jonboulle @yujuhong @feiskyer @kubernetes/sig-node
```release-note
NONE
```
Adding the `privileged` bool to the sandbox allows runtimes, like rkt,
to make better security choices in some cases.
This also enumerates what "privileged" actually means and how it
interacts with other options (or more accurately, does not).
The documentation closely matches docker's current behavior because, so
far, that's what privileged has meant.
Automatic merge from submit-queue
CRI: add docs for sysctls
#34830 adds `sysctls` features in CRI, it is based on sandbox annotations, this PR adds docs for it.
@yujuhong @timstclair @jonboulle
No semantic changes, but a lot of shuffling of docstrings to make things
more consistent. In particular, standardise on the zeroth-article (i.e.
prefer `// Version` to `// The version`) and ending all docstrings with
periods.
Automatic merge from submit-queue
CRI: Add Status into CRI.
For https://github.com/kubernetes/kubernetes/issues/35701.
Fixes https://github.com/kubernetes/kubernetes/issues/35701.
This PR added a `Status` call in CRI, and the `RuntimeStatus` is defined as following:
``` protobuf
message RuntimeCondition {
// Type of runtime condition.
optional string type = 1;
// Status of the condition, one of true/false.
optional bool status = 2;
// Brief reason for the condition's last transition.
optional string reason = 3;
// Human readable message indicating details about last transition.
optional string message = 4;
}
message RuntimeStatus {
// Conditions is an array of current observed runtime conditions.
repeated RuntimeCondition conditions = 1;
}
```
Currently, only `conditions` is included in `RuntimeStatus`, and the definition is almost the same with `NodeCondition` and `PodCondition` in K8s api.
@yujuhong @feiskyer @bprashanth If this makes sense, I'll send a follow up PR to let dockershim return `RuntimeStatus` and let kubelet make use of it.
@yifan-gu @euank Does this make sense to rkt?
/cc @kubernetes/sig-node
Automatic merge from submit-queue
CRI: stop sandbox before removing it
Stopping a sandbox includes reclaiming the network resources. By always
stopping the sandbox before removing it, we reduce the possibility of leaking
resources in some corner cases.
Stopping a sandbox includes reclaiming the network resources. By always
stopping the sandbox before removing it, we reduce the possibility of leaking
resources in some corner cases.
The enum constants are not namespaced. The shorter, unspecifc names are likely
to cause naming conflicts in the future.
Also replace "SandBox" with "Sandbox" in the API.