kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

contributors: rename CoreOS -> CoreOS Container Linux 

CoreOS Linux was renamed to CoreOS Container Linux. Make it consistent
in a couple of design proposals.

https://coreos.com/os/docs/latest/
This commit is contained in:
Brandon Philips 2017-02-02 10:59:08 +01:00
parent 980fa6c290
commit 3b9c3aa8ab
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
contributors/design-proposals/kubelet-rootfs-distribution.md
View File

@ -11,7 +11,7 @@ a number of dependencies that must exist in its filesystem, including various
mount and network utilities. Missing any of these can lead to unexpected mount and network utilities. Missing any of these can lead to unexpected
differences between Kubernetes hosts. For example, the Google Container VM differences between Kubernetes hosts. For example, the Google Container VM
image (GCI) is missing various mount commands even though the Kernel supports image (GCI) is missing various mount commands even though the Kernel supports
those filesystem types. Similarly, CoreOS Linux intentionally doesn't ship with those filesystem types. Similarly, CoreOS Container Linux intentionally doesn't ship with
many mount utilities or socat in the base image. Other distros have a related many mount utilities or socat in the base image. Other distros have a related
problem of ensuring these dependencies are present and versioned appropriately problem of ensuring these dependencies are present and versioned appropriately
for the Kubelet. for the Kubelet.
@ -38,7 +38,7 @@ mount --rbind /var/lib/kubelet /path/to/chroot/var/lib/kubelet
chroot /path/to/kubelet /usr/bin/hyperkube kubelet chroot /path/to/kubelet /usr/bin/hyperkube kubelet
``` ```
Note: Kubelet might need access to more directories on the host and we intend to identity mount all those directories into the chroot. A partial list can be found in the CoreOS kubelet-wrapper script. Note: Kubelet might need access to more directories on the host and we intend to identity mount all those directories into the chroot. A partial list can be found in the CoreOS Container Linux kubelet-wrapper script.
This logic will also naturally be abstracted so it's no more difficult for the user to run the Kubelet. This logic will also naturally be abstracted so it's no more difficult for the user to run the Kubelet.
Currently, the Kubelet does not need access to arbitrary paths on the host (as Currently, the Kubelet does not need access to arbitrary paths on the host (as
@ -53,13 +53,13 @@ chroot.
## Current Use ## Current Use
This method of running the Kubelet is already in use by users of CoreOS Linux. The details of this implementation are found in the [kubelet wrapper documentation](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html). This method of running the Kubelet is already in use by users of CoreOS Container Linux. The details of this implementation are found in the [kubelet wrapper documentation](https://coreos.com/kubernetes/docs/latest/kubelet-wrapper.html).
## Implementation ## Implementation
### Target Distros ### Target Distros
The two distros which benefit the most from this change are GCI and CoreOS. Initially, these changes will only be implemented for those distros. The two distros which benefit the most from this change are GCI and CoreOS Container Linux. Initially, these changes will only be implemented for those distros.
This work will also only initially target the GCE provider and `kube-up` method of deployment. This work will also only initially target the GCE provider and `kube-up` method of deployment.
@ -158,7 +158,7 @@ Currently, there's a `--containerized` flag. This flag doesn't actually remove t
#### Timeframe #### Timeframe
During the 1.6 timeframe, the changes mentioned in implementation will be undergone for the CoreOS and GCI distros. During the 1.6 timeframe, the changes mentioned in implementation will be undergone for the CoreOS Container Linux and GCI distros.
Based on the test results and additional problems that may arise, rollout will Based on the test results and additional problems that may arise, rollout will
be determined from there. Hopefully the rollout can also occur in the 1.6 be determined from there. Hopefully the rollout can also occur in the 1.6

2
contributors/design-proposals/propagation.md
View File

@ -37,7 +37,7 @@ The slave mount namespace is the correct solution for this AFAICS. Until this
becomes available in k8s, we will have to have operations restart containers manually becomes available in k8s, we will have to have operations restart containers manually
based on monitoring alerts. based on monitoring alerts.
1. (From @victorgp) When using CoreOS that does not provides external fuse systems 1. (From @victorgp) When using CoreOS Container Linux that does not provides external fuse systems
like, in our case, GlusterFS, and you need a container to do the mounts. The only like, in our case, GlusterFS, and you need a container to do the mounts. The only
way to see those mounts in the host, hence also visible by other containers, is by way to see those mounts in the host, hence also visible by other containers, is by
sharing the mount propagation. sharing the mount propagation.