Can I run k8s master INSIDE a docker container? Getting errors about k8s looking for host's kernel details

Question

In a docker container I want to run k8s.

When I run kubeadm join... or kubeadm init commands I see sometimes errors like

\"modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/3.10.0-1062.1.2.el7.x86_64/modules.dep.bin'. nmodprobe:
FATAL: Module configs not found in directory /lib/modules/3.10.0-1062.1.2.el7.x86_64", err: exit status 1

because (I think) my container does not have the expected kernel header files.

I realise that the container reports its kernel based on the host that is running the container ; and looking at k8s code I see

// getKernelConfigReader search kernel config file in a predefined list. Once the kernel config
// file is found it will read the configurations into a byte buffer and return. If the kernel
// config file is not found, it will try to load kernel config module and retry again.
func (k *KernelValidator) getKernelConfigReader() (io.Reader, error) {
    possibePaths := []string{
        "/proc/config.gz",
        "/boot/config-" + k.kernelRelease,
        "/usr/src/linux-" + k.kernelRelease + "/.config",
        "/usr/src/linux/.config",
    }

so I am bit confused what is simplest way to run k8s inside a container such that it consistently past this getting the kernel info.

I note that running docker run -it solita/centos-systemd:7 /bin/bash on a macOS host I see:

# uname -r
4.9.184-linuxkit
# ls -l /proc/config.gz 
-r--r--r-- 1 root root 23834 Nov 20 16:40 /proc/config.gz

but running exact same on a Ubuntu VM I see:

#  uname -r
4.4.0-142-generic
# ls -l /proc/config.gz 
ls: cannot access /proc/config.gz

[Weirdly I don't see this FATAL: Module configs not found in directory error every time, but I guess that is a separate question!]

UPDATE 22/November/2019. I see now that k8s DOES run okay in a container. Real problem was weird/misleading logs. I have added an answer to clarify.

Answer 1

I do not believe that is possible given the nature of containers.

You should instead test your app in a docker container then deploy that image to k8s either in the cloud or locally using minikube.

Another solution is to run it under kind which uses docker driver instead of VirtualBox

https://kind.sigs.k8s.io/docs/user/quick-start/

Answer 2

It seems the FATAL error part was a bit misleading.

It was badly formatted by my test environment (all on one line. When k8s was failing I saw the FATAL and assumed (incorrectly) that was root cause.

When I format the logs nicely I see...

kubeadm join 172.17.0.2:6443 --token 21e8ab.1e1666a25fd37338 --discovery-token-unsafe-skip-ca-verification --experimental-control-plane --ignore-preflight-errors=all --node-name 172.17.0.3
[preflight] Running pre-flight checks
    [WARNING FileContent--proc-sys-net-bridge-bridge-nf-call-iptables]: /proc/sys/net/bridge/bridge-nf-call-iptables does not exist
[preflight] The system verification failed. Printing the output from the verification:
KERNEL_VERSION: 4.4.0-142-generic
DOCKER_VERSION: 18.09.3
OS: Linux
CGROUPS_CPU: enabled
CGROUPS_CPUACCT: enabled
CGROUPS_CPUSET: enabled
CGROUPS_DEVICES: enabled
CGROUPS_FREEZER: enabled
CGROUPS_MEMORY: enabled
    [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 18.09.3. Latest validated version: 18.06
    [WARNING SystemVerification]: failed to parse kernel config: unable to load kernel module: "configs", output: "modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.0-142-generic/modules.dep.bin'\nmodprobe: FATAL: Module configs not found in directory /lib/modules/4.4.0-142-generic\n", err: exit status 1
[discovery] Trying to connect to API Server "172.17.0.2:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://172.17.0.2:6443"



[discovery] Failed to request cluster info, will try again: [the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps cluster-info)]

There are other errors later, which I originally though were a side-effect of the nasty looking FATAL error eg .... "[util/etcd] Attempt timed out"]} but I now think root cause is Etcd part times out sometimes.

Adding this answer in case someone else puzzled like I was.