To help reduce confusion from this file (which configures our `kubelet.sh`
wrapper) vs `/var/lib/kubeadm/kubelet.conf` (which is created by `kubeadm` and
configures `kubelet` itself).
Signed-off-by: Ian Campbell <ijc@docker.com>
This vendors containerd v1.0.0-beta.1
Enable seccomp support at build time.
Requires /dev bind mount so it can use /dev/disk/by-uuid to resolve devices to
uuids.
Signed-off-by: Ian Campbell <ijc@docker.com>
Set KUBE_MASTER_AUTOINIT when using boot.sh to enable. User will need to pick
up the token for other nodes using `kubeadm token list`.
Signed-off-by: Ian Campbell <ijc@docker.com>
Rework the kubelet.sh script by adding an explicit step which waits for the
configuration to be valid, either by finding appropriate metadata or by waiting
explicitly for kubelet.conf to be created (e.g. by kubeadm) before launching
kubelet. The previous construct was implicitly waiting for kubelet.conf to be
created since kubelet fails if that file is not present.
Pull the set of start of day yaml files to be applied (currently just weave)
out of the kubelet image and into the LinuxKit yaml by providing a directory
which is searched for *.yaml after init.
Signed-off-by: Ian Campbell <ijc@docker.com>
With the master tailoring for docker now being in docker-master.yml,
kube-master and kube-node are identical, so just use a single kube.yml.
The reference to kube-master.yml in README.md is obsolete, so just drop it.
Signed-off-by: Ian Campbell <ijc@docker.com>
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>
