I changed my mind about the name halfway through implementing #2700 and
seemingly forgot to update the most important location, but a stale local file
stopped me from noticing.
Signed-off-by: Ian Campbell <ijc@docker.com>
`linuxkitprojects/kubernetes` → `linuxkitprojects/kubelet`
`linuxkitprojects/kubernetes-image-cache-*` → `linuxkitprojects/kubernetes-docker-image-cache-*`
`kubernetes` subdirectory is also renamed to `kubelet`.
`image-cache` subdirectory is not renamed since we may want to build other
sorts of image cache at some point.
Signed-off-by: Ian Campbell <ijc@docker.com>
Previously the network policy yaml had to be hard-coded in the image.
This patch allows the policy to be added via the metadata directories:
- /var/config/cni/etc/net.d/
- /var/config/kube-system.init/
Signed-off-by: David Scott <dave.scott@docker.com>
This has no kube object(s) but just arranges for the CNI configuration to be
written in the right place. The CNI bridge, loopback etc binaries are already
included since they are in the reference set.
Signed-off-by: Ian Campbell <ijc@docker.com>
KUBE_NETWORK now specifies a yml which is passed to the Moby tool, which can
introduce files into /etc/kubeadm/kube-system.init/ or do other things as it
likes.
In the case of weave this just adds the weave yaml to that directory. To avoid
too much confusion between weave.yml (Moby tool input) and `weave.yaml` (the
kubernetes `ServiceAccount`, `DeamonsSet` etc object specs) name the latter
`kube-weave.yaml`.
Signed-off-by: Ian Campbell <ijc@docker.com>
Building both BIOS and EFI variants is a waste of time in most cases, instead
just build whichever one is relevant to the platform (which currently means EFI
on Darwin and BIOS everywhere else).
At the same time make it possible to pass "KUBE_FORMATS" (a space separated
list of targets) to the build e.g. `make KUBE_FORMATS="iso-efi iso-bios"` will
preserve the behaviour prior to this patch.
Signed-off-by: Ian Campbell <ijc@docker.com>
Specifically ignore present-but-empty files entirely and ignore (but log)
failure to apply any one file.
Ignoring an empty file is useful because it means you can clobber a file which
might be referenced from an images binds without needing to override those
binds (since that generally means duplicating the whole lot which is annoying).
Ignoring any failures to apply means the rest gets applied and the rest of the
script (including untaint and the stamp file creation) still happen, resulting
in a system where the admin just has to address the failures rather than the
remaining updates. We touch a file to indicate failure generally plus one to
indicate the specific yaml which failed to apply.
Signed-off-by: Ian Campbell <ijc@docker.com>
