Add a new container runtime interface#25899
Conversation
|
cc @mrunalp |
|
cc/ @philips @jonboulle @yifan-gu @euank from coreos / rkt |
There was a problem hiding this comment.
will fix it. thanks
|
@yujuhong Would it be useful to mention explicitly that this PR is not intended to be the final API / interface and that the individual fields/features can be fixed/updated/improved in subsequent PRs? |
There was a problem hiding this comment.
Should probably include paths to all shared namespaces for completeness.
There was a problem hiding this comment.
We can approach this in two different ways. One is, as you suggested, returning everything for completeness. The other is to add fields when we need it. I went with the second approach, and we can iterate and add more fields if required.
|
GCE e2e build/test passed for commit 96c0103455f27a974085e9a2fc4148f669ac4dec. |
|
It seems like I wasn't able to communicate my intentions well. I meant addressing the comments of other people so that theirs don’t get lost and carry the discussion about my concerns to another PR. I agree with 100% with the recent comments 👍 |
This commit includes a proposal and a Go file to re-define the container runtime interface. Note that this is an experimental interface and is expected to go through multiple revisions once developers start implementing against it. As stated in the proposal, there are also individual issues to carry discussions of specific features.
|
Updated the boillerplate to the new style. Reapplying the lgtm. |
|
GCE e2e build/test passed for commit 08dc661. |
|
Automatic merge from submit-queue |
Automatic merge from submit-queue Proposal: client/server container runtime Ref #25899 #13768 Proposal for client/server container runtime CC @brendandburns @dchen1107 @kubernetes/goog-node @kubernetes/sig-node
|
|
||
| // Linux contains configurations specific to Linux hosts. | ||
| Linux *LinuxPodSandboxConfig | ||
| } |
There was a problem hiding this comment.
is there any particular issue in having an User property in PodSandboxConfig above? OCI would want to specify an user in the config.json as part of running a container with a specified user. Having the CRI proto to support that would let OCI containers to run with a particular user. @mrunalp @yujuhong @vishh
There was a problem hiding this comment.
Since the securityContext of a container can have a runAsUser, we need something in this interface to be able to handle that. However, I think it should be solely part of a container's config, not pod sandbox.
Want to file a followup issue or make a PR to add this and discuss there instead?
There was a problem hiding this comment.
I agree that adding this at the container level makes sense. PodSandbox could be left upto the runtime.
There was a problem hiding this comment.
👍 I'll make a PR to discuss that then
There was a problem hiding this comment.
BTW, @euank sorry for the confusion, I did mean ContainerConfig not PodSandboxConfig
There was a problem hiding this comment.
+1 for adding user to container config.
| // Mounts specifies mounts for the container | ||
| Mounts []Mount | ||
| // Labels are key value pairs that may be used to scope and select individual resources. | ||
| Labels Labels |
There was a problem hiding this comment.
From where do these labels come?
What if the container runtime needs to know the origin of this container in k8s API terms, such as k8s namespace, k8s pod name, and user container name in the pod --- how could the runtime know those?
There was a problem hiding this comment.
This interface abstracts those details away. Those labels realistically do contain such information, but it's an internal contract for the kubelet to use for itself only, not something the runtime is supposed to interpret in any way.
Right now those come mostly from here iirc and are used for things like calculating restart count and checkpointing data.
The interface explicitly does not express more to the runtime than it needs to know.
That being said, a sufficiently smart runtime could lookup a container it manages in the kubelet's pods endpoint based on its container ID I expect.
Realistically though, k8s namespaces and pod names and so on are all higher level details that the runtime should not have to care about.
Automatic merge from submit-queue CRI: add LinuxUser to LinuxContainerConfig Following discussion in #25899 (comment) The Container Runtime Interface should provide runtimes with User information to run the container process as (OCI being one of them). This patch introduces a new field `user` into `LinuxContainerConfig` structure. The `user` field introduces also a new type structure `LinuxUser` which consists of `uid`, `gid` and `additional_gids`. The `LinuxUser` struct has been embedded into `LinuxContainerConfig` to leave space for future implementations which are not Linux-related (e.g. Windows may have a different representation of _Users_). If you feel naming can be better we can probably move `LinuxUser` to `UnixUser` also. /cc @mrunalp @vishh @euank @yujuhong Signed-off-by: Antonio Murdaca <[email protected]>
…er-proposal Automatic merge from submit-queue Proposal: client/server container runtime Ref kubernetes#25899 kubernetes#13768 Proposal for client/server container runtime CC @brendandburns @dchen1107 @kubernetes/goog-node @kubernetes/sig-node
Automatic merge from submit-queue Add a new container runtime interface This PR includes a proposal and a Go file to re-define the container runtime interface. This is based on the original doc: https://docs.google.com/document/d/1ietD5eavK0aTuMQTw6-21r67UU73_vqYSUIPFdA0J5Q/ The umbrella issues is kubernetes#22964 /cc @kubernetes/sig-node
…er-proposal Automatic merge from submit-queue Proposal: client/server container runtime Ref kubernetes#25899 kubernetes#13768 Proposal for client/server container runtime CC @brendandburns @dchen1107 @kubernetes/goog-node @kubernetes/sig-node
Automatic merge from submit-queue CRI: add LinuxUser to LinuxContainerConfig Following discussion in kubernetes#25899 (comment) The Container Runtime Interface should provide runtimes with User information to run the container process as (OCI being one of them). This patch introduces a new field `user` into `LinuxContainerConfig` structure. The `user` field introduces also a new type structure `LinuxUser` which consists of `uid`, `gid` and `additional_gids`. The `LinuxUser` struct has been embedded into `LinuxContainerConfig` to leave space for future implementations which are not Linux-related (e.g. Windows may have a different representation of _Users_). If you feel naming can be better we can probably move `LinuxUser` to `UnixUser` also. /cc @mrunalp @vishh @euank @yujuhong Signed-off-by: Antonio Murdaca <[email protected]>
This PR includes a proposal and a Go file to re-define the container runtime interface.
This is based on the original doc: https://docs.google.com/document/d/1ietD5eavK0aTuMQTw6-21r67UU73_vqYSUIPFdA0J5Q/
The umbrella issues is #22964
/cc @kubernetes/sig-node