Support for Windows job containers #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This looks like a PR to your own fork, is there a reason for that? Otherwise, LGTM |
config-windows.md
Outdated
|
|
||
| The following parameters can be specified: | ||
|
|
||
| * **`rootfsMountPoint`** *(string, OPTIONAL)* - specifies the path that the containers rootfs volume should be mounted to. |
specs-go/config.go
Outdated
| @@ -557,6 +559,13 @@ type WindowsHyperV struct { | |||
| UtilityVMPath string `json:"utilityVMPath,omitempty"` | |||
| } | |||
|
|
|||
| // WindowsJobContainer contains information for configuring a job container on Windows. | |||
| type WindowsJobContainer struct { | |||
| // RootfsMountPoint is an optional path that indicates where the containers rootfs volume should | |||
Yea, don't wanna open the PR before our team looks at it |
|
Thanks @katiewasnothere! ❤️ |
kevpar
reviewed
Mar 29, 2021
config-windows.md
Outdated
| The following parameters can be specified: | ||
|
|
||
| * **`rootfsMountPoint`** *(string, OPTIONAL)* - specifies the path that the containers rootfs volume should be mounted to. | ||
| If not supplied, the runtime will create a random path for the rootfs to be mounted at. |
There was a problem hiding this comment.
Rather than random path I would say something like the path will be determined by the runtime.
|
This looks good to me once the current comments are addressed! |
dcantah
force-pushed
the
windows-job-container
branch
2 times, most recently
from
12764f4 to
74361f9
Compare
See kubernetes/enhancements#2288 for more background. To avoid any confusion here the name chosen for this container type for the cri API and the user facing k8s settings is HostProcess containers Internally we've coined these as job containers but it's referring to the same type of container, we'd just like to keep the name the same as we use internally at the OCI level and in our code. The cri HostProcess field being set would be our key to fill in the WindowsJobContainer field on the runtime spec for example. There's been asks for Windows privileged containers, or something analogous to it, for quite some time. While in the Linux world this can be achieved just be loosening some of the security restrictions normally in place for containers, this isn't as easy on Windows for many reasons. There's no such thing as just mounting in /dev for the easy example. The model we've landed on to support something akin to privileged containers on Windows is to keep using the container layer technology we currently use for Windows Server and Hyper-V isolated containers, and to simply have the runtime manage a process, or set of processes, in a job object as the container. The work for job containers is open source and lives here: https://github.com/microsoft/hcsshim/tree/master/internal/jobcontainers This approach covers all of the use cases we've currently heard that privileged containers would be useful for. Some of these include configuring network settings, administrative tasks, viewing/manipulating storage devices, and the ability to simplify running daemons that need host access (kube-proxy) on Windows. Without these changes we'd likely set an annotation to specify that the runtime should create one of these containers, which isn't ideal. As for the one optional field, this is really the only thing that actually differs/isn't configurable for normal Windows Server Containers. With job containers the final writable layer (volume) for the container is mounted on the host so it's accessible and viewable without enumerating the volumes on the host and trying to correlate what volume is the containers. This is contrary to Windows Server Containers, where the volume is never mounted to a directory anywhere, although it's still accesible from the host for the curious. Signed-off-by: Daniel Canter <[email protected]>
dcantah
force-pushed
the
windows-job-container
branch
from
74361f9 to
3dd1e1f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See kubernetes/enhancements#2288 for more background. To avoid any confusion here the name chosen for this container type for the cri API and the user facing k8s settings is HostProcess containers. Internally we've coined these as job containers but it's referring to the same type of container, the cri
HostProcessfield being set would be ourkey to fill in the
JobContainerfield here on the runtime spec for example.There's been asks for Windows privileged containers, or something analogous to it, for quite some time. While in the Linux world this can be achieved just be loosening some of the security restrictions normally in place for containers, this isn't as easy on Windows for many reasons. There's no such thing as just mounting in /dev for example.
The model we've landed on to support something akin to privileged containers on Windows is to keep using the container layer technology we currently use for Windows Server and Hyper-V isolated containers, and to simply have the runtime manage a process, or set of processes, in a job object as the container. The work for job containers is open source and lives here:
https://github.com/microsoft/hcsshim/tree/master/internal/jobcontainers
This approach covers all of the use cases we've currently heard that privileged containers would be useful for. Some of these include configuring network settings, administrative tasks, viewing/manipulating storage devices, and the ability to simplify running daemons that need host access (kube-proxy) on Windows. Without these changes we'd likely set an annotation to specify that the runtime should create one of these containers, which isn't ideal.
As for the one optional field, this is really the only thing that actually differs/isn't configurable for normal Windows Server Containers that we would like configurable in this case. With job containers the final writable layer (volume) for the container is mounted on the host so it's accessible and viewable without enumerating the volumes on the host and trying to correlate what volume is the containers. This is different from Windows Server Containers where the volume is never mounted to a directory anywhere, although it's still viewable and accessible from the host (mountvol for example)
Signed-off-by: Daniel Canter [email protected]