This allows cri-containerd and docker based systems to pass the correct options
via composition of yml files, while keeping the kubelet service stanza common.
Since bind mounts are not conditional on the presence of the source we need to
create an empty file in the docker case.
Signed-off-by: Ian Campbell <ijc@docker.com>
This doesn't seem to be necessary when using Docker Engine as the CRI backend,
but in general it is.
The sysctl container must be writeable to allow the
/etc/sysctl.d/01-kubernetes.conf mount point to be created. See #2503.
Signed-off-by: Ian Campbell <ijc@docker.com>
Depending on the configuration/components used the system can expect to be able
to share `/var/run/netns` (=`/run/netns` via symlink) bind mounts with other
system level containers, which requires exposing those to the host.
This doesn't appear to be needed when using Docker engine but it is with
cri-containerd.
Signed-off-by: Ian Campbell <ijc@docker.com>
Kubernetes assumes (for now) that various paths are valid at the host level to
be mounted into containers, including /opt/cni and /etc/cni.
We cannot (easily) use symlinks here because the weave.yml mounts /opt and /etc
rather than /opt/cni and /etc/cni (this seems likely to be common pattern). So
if /etc/cni were a symlink to the persistent disk (under /var/lib) then it will
be dangling link within the weave container.
So add bind mounts to the runtime configuration of the kubernetes image. This
also means we must create the target mount points in the yml.
Signed-off-by: Ian Campbell <ijc@docker.com>
This avoids a slightly tricky sequence of nested bind mounts by just unpacking
a tarball on boot (with a stamp so it only happens once).
Signed-off-by: Ian Campbell <ijc@docker.com>
For example to tell kubelet to use cri-containerd:
command: ["/usr/bin/kubelet.sh", "--container-runtime=remote", "--container-runtime-endpoint=unix:///var/run/cri-containerd.sock"]
Signed-off-by: Ian Campbell <ijc@docker.com>
Not having to redo the kubeadm-init.sh step massively speeds up the test/dev
cycle. Having the same MAC (and hence same IP) is useful there too since you
don't need to figure out the mac on each boot.
Signed-off-by: Ian Campbell <ijc@docker.com>
The sock-shop demo[0] requires around 5G of images on a worker node and 3G of
RAM (if there is only one worker node and therefore everything runs on that
node).
Since the master is more than happy with the 4G disk and 1G RAM it is given
today split the settings into master and node specific and bump only the
latter.
KUBE_PORT_BASE is unused and was already removed in 54ddde0d43 but
accidentally reintroduced (by me) in 62aa9248a4, whack it again.
[0] https://microservices-demo.github.io/microservices-demo
Signed-off-by: Ian Campbell <ijc@docker.com>
Currently they will be on a read only partition so broken;
previously this would have been a non persistent read write partition
in an initramfs but this no longer works.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
