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.
This patch
- set limits (0.25 cpu, 64 MB) on containers which are not limited in pod spec
(these are also passed to the kubelet such that it uses them for the docker
run limits)
- sums up the container resource limits for cpu and memory inside a pod,
- compares the sums to the offered resources
- puts the sums into the Mesos TaskInfo such that Mesos does the accounting
for the pod.
- parses the static pod spec and adds up the resources
- sets the executor resources to 0.25 cpu, 64 MB plus the static pod resources
- sets the cgroups in the kubelet for system containers, resource containers
and docker to the one of the executor that Mesos assigned
- adds scheduler parameters --default-container-cpu-limit and
--default-container-mem-limit.
The containers themselves are resource limited the Docker resource limit which
the kubelet applies when launching them.
Fixesmesosphere/kubernetes-mesos#68 and mesosphere/kubernetes-mesos#304
