Until Docker learns parent mount namespace customization the container will
always have the root ns as a parent, not the one of the km minion. Hence, the
kubelet (which lives in the km minion mount ns) will create mounts that cannot
be seen by the Docker containers.
This feature can be enabled again when Docker learns to explicitly set the
parent mount ns, in analogy to the parent cgroup.
The minion server will
- launch the proxy and executor
- relaunch them when they terminate uncleanly
- logrotate their logs.
It is a replacement for a full-blown init process like s6 which is not necessary
in this case.
When we deploy the kubernetes using Ubuntu's script.
1. First we set the roles "ai i i" and NUM_MINIONS=3, it runs as expected.
2. Then we change the roles to "a i i" and NUM_MINIONS=2, we found it will not run successfully.
It's because there are history files left on the previous deployment.
This commit will delete the files when stop the cluster.
Before NodeName in the pod spec was used. Hence, pods with a fixed, pre-set
NodeName were never scheduled by the k8sm-scheduler, leading e.g. to a failing
e2e intra-pod test.
Fixesmesosphere/kubernetes-mesos#388
I tested out a Limit Ranger, and it seems like the admission happens *before* Validation. Please correct me if I'm wrong though, I didn't look at the code in detail. In any case, I think it makes sense for admission to happen before validation because code in admission can change containers.
By the way I think it's pretty hard to find flows like this in the code, so it's useful if we add links to code in the design docs (for prospective developers) :)
The basic idea is that in the main mungedocs we run the entirefile and
create an annotated set of lines about that file. All mungers then act
on a struct mungeLines instead of on a bytes array. Making use of the
metadata where appropriete. Helper functions exist to make updating a
'macro block' extremely easy.
to detect this, but somehow this is not communicated to invocations from the remote API. Thus to get kubernets working on a local docker installation, its important to make sure that
the memory and swap accounting are turned on in the kernel and passed as a parameter to the kernel when booting up.
Hence added the required instructions as a pre-req for running kubernets in a local docker installation.
Primary motivation: enable GKE and other cluster-as-a-service folks to
easily run additional logic on the master without having to modify salt
or SSH to the master after it's been created.
