Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kind should be able to start the control plane when /dev/kmsg is not available #662

Closed
hoegaarden opened this issue Jun 26, 2019 · 11 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@hoegaarden
Copy link
Contributor

hoegaarden commented Jun 26, 2019

What happened:

kind is not able to start the control plane (with the provided node images) when /dev/kmsg is not available in the node container.

kind then fails with:

 ✗ Starting control-plane 🕹️
Error: failed to create cluster: failed to init node with kubeadm: exit status 1

Checking on the node, I can see the following error:

# docker exec -ti kind-control-plane sh -c 'journalctl -u kubelet | grep -m1 -C3 kmsg'
Jun 26 08:18:59 kind-control-plane kubelet[375565]: I0626 08:18:59.522248  375565 kuberuntime_manager.go:205] Container runtime containerd initialized, version: 1.2.6-0ubuntu1, apiVersion: v1alpha2
Jun 26 08:18:59 kind-control-plane kubelet[375565]: I0626 08:18:59.525786  375565 server.go:1083] Started kubelet
Jun 26 08:18:59 kind-control-plane kubelet[375565]: I0626 08:18:59.526254  375565 server.go:144] Starting to listen on 0.0.0.0:10250
Jun 26 08:18:59 kind-control-plane kubelet[375565]: F0626 08:18:59.532066  375565 kubelet.go:1405] Failed to start OOM watcher open /dev/kmsg: no such file or directory
Jun 26 08:18:59 kind-control-plane kubelet[375565]: I0626 08:18:59.535478  375565 server.go:350] Adding debug handlers to kubelet server.
Jun 26 08:18:59 kind-control-plane systemd[1]: kubelet.service: Main process exited, code=exited, status=255/EXCEPTION
Jun 26 08:18:59 kind-control-plane systemd[1]: kubelet.service: Failed with result 'exit-code'.

For the node images I bake myself, I have the following dirty hack in place:

  • I create the image with kind build node-image ...
  • I add another layer which adds a systemd file which sets a ExecStartPre for the kubelet which just does something like [ -e /dev/kmsg ] || ln -s /dev/console /dev/kmsg

After that kind create cluster ... successfully starts the control plane.

What you expected to happen:

kind should be able to bring up the control plane, at least when /dev/console is available.

How to reproduce it (as minimally and precisely as possible):

Run kind on an environment without /dev/kmsg, eg. concourse (via kind-on-c for example) and with the 1.15 node image provided by kind.

Anything else we need to know?:

I currently (need to dig deeper) have no idea what the downsides are when linking /dev/kmsg to /dev/console or what to do when /dev/console is not available either (when would that be the case). My tests seem to suggest that the cluster works just fine when doing this linking. Would the kind maintainers be open for a PR which sets such a ExecStartPre (or makes /dev/kmsg available via some other means for that matter)?

Environment:

  • kind version: (use kind version):

    kind version v0.4.0
    
  • Kubernetes version: (use kubectl version):

    v1.15.0 (the version that is baked into kindest/node:v1.15.0)

  • Docker version: (use docker info): ``

    Containers: 1
     Running: 1
     Paused: 0
     Stopped: 0
    Images: 1
    Server Version: 18.09.6
    Storage Driver: overlay2
     Backing Filesystem: extfs
     Supports d_type: true
     Native Overlay Diff: true
    Logging Driver: json-file
    Cgroup Driver: cgroupfs
    Plugins:
    WARNING: bridge-nf-call-iptables is disabled
    WARNING: bridge-nf-call-ip6tables is disabled
     Volume: local
     Network: bridge host macvlan null overlay
     Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
    Swarm: inactive
    Runtimes: runc
    Default Runtime: runc
    Init Binary: docker-init
    containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
    runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
    init version: fec3683
    Security Options:
     apparmor
     seccomp
      Profile: default
    Kernel Version: 4.15.0-50-generic
    Operating System: Alpine Linux v3.10 (containerized)
    OSType: linux
    Architecture: x86_64
    CPUs: 4
    Total Memory: 15.66GiB
    Name: dd95e405-f2d2-4d82-54b3-36f4d1287a53
    ID: YMS4:B7WR:ZESV:VMM6:5CE3:OMGK:7U2Q:3GAS:EGEL:RPTL:35MW:EFPF
    Docker Root Dir: /scratch/docker
    Debug Mode (client): false
    Debug Mode (server): false
    Registry: https://index.docker.io/v1/
    Labels:
    Experimental: false
    Insecure Registries:
     127.0.0.0/8
    Live Restore Enabled: false
    Product License: Community Engine
    
  • OS (e.g. from /etc/os-release):

    NAME="Alpine Linux"
    ID=alpine
    VERSION_ID=3.10.0
    PRETTY_NAME="Alpine Linux v3.10"
    HOME_URL="https://alpinelinux.org/"
    BUG_REPORT_URL="https://bugs.alpinelinux.org/"
    
@hoegaarden hoegaarden added the kind/bug Categorizes issue or PR as related to a bug. label Jun 26, 2019
@hoegaarden
Copy link
Contributor Author

maybe related: #455

@BenTheElder
Copy link
Member

We should definitely try to tolerate environments, I'm a bit curious how your system doesn't have a /dev/kmsg though and if these are really comparable. Taking a look...

@hoegaarden
Copy link
Contributor Author

@BenTheElder
Copy link
Member

what does /dev/console give you in your environment? I'm not sure that using /dev/console as /dev/kmsg is any different from just placing an empty file at /dev/kmsg. As far as I can tell console is a tty and kmsg is a virtual file... so reading /dev/console as a file just hangs and prints nothing.

@hoegaarden
Copy link
Contributor Author

lxc has a config setting for that, see man lxc.container.conf:

[...]
   ENABLE KMSG SYMLINK
       Enable creating /dev/kmsg as symlink to /dev/console. This defaults to 0.

       lxc.kmsg
              Set this to 1 to enable /dev/kmsg symlinking.
[...]

... so it is not completely uncommon. 🤷‍♂️

@BenTheElder
Copy link
Member

interesting, thanks! that works for me :-)

@BenTheElder
Copy link
Member

fixed in #664

@BenTheElder
Copy link
Member

thanks!

hoegaarden added a commit to vmware-archive/kind-on-c that referenced this issue Jul 4, 2019
THe current approach to link `/dev/kmsg` to `/dev/console` only works on
images that we build ourselves. Let's see if we can mess with the
running container and create the link at runtime / on the fly.

As this is fixed in kind already [0], we can remove that hack probably
when kind 0.5.0 is out.

Why is this linking even needed? See also [0]!

[0]: kubernetes-sigs/kind#662
hoegaarden added a commit to vmware-archive/kind-on-c that referenced this issue Jul 4, 2019
THe current approach to link `/dev/kmsg` to `/dev/console` only works on
images that we build ourselves. Let's see if we can mess with the
running container and create the link at runtime / on the fly.

As this is fixed in kind already [0], we can remove that hack probably
when kind 0.5.0 is out.

Why is this linking even needed? See also [0]!

[0]: kubernetes-sigs/kind#662
hoegaarden added a commit to vmware-archive/kind-on-c that referenced this issue Jul 4, 2019
THe current approach to link `/dev/kmsg` to `/dev/console` only works on
images that we build ourselves. Let's see if we can mess with the
running container and create the link at runtime / on the fly.

As this is fixed in kind already [0], we can remove that hack probably
when kind 0.5.0 is out.

Why is this linking even needed? See also [0]!

[0]: kubernetes-sigs/kind#662
hoegaarden added a commit to vmware-archive/kind-on-c that referenced this issue Jul 4, 2019
The previous approach to link `/dev/kmsg` to `/dev/console` only works on
images that we build ourselves. Let's see if we can mess with the
running container and create the link at runtime / on the fly.

As this is fixed in kind already [0], we can remove that hack probably
when kind 0.5.0 is out.

Why is this linking even needed? See also [0]!

[0]: kubernetes-sigs/kind#662
hoegaarden added a commit to vmware-archive/kind-on-c that referenced this issue Jul 4, 2019
The previous approach to link `/dev/kmsg` to `/dev/console` only works on
images that we build ourselves.

The new approach is to do the linking at runtime, parallel to kind
brining up the cluster:
We run a function parallel to kind, which tries to exec into the control
plane node and do the linking. This should succeed as soon as the node
container is up, in which case the function will terminate gracefully.

As this is fixed in kind already [0], we can remove that hack probably
when kind 0.5.0 is out.

Why is this linking even needed? See also [0]!

[0]: kubernetes-sigs/kind#662
@nmvega
Copy link

nmvega commented Apr 27, 2020

interesting, thanks! that works for me :-)

@hoegaarden @BenTheElder

Just in case someone comes looking, for my Fedora-30 LXC O/S container (and probably for somewhat newer and older versions of Fedora, as well as for CentOS), this directive was removed (deprecated): lxc.kmsg = 0|1. Container configuration files with that entry will prevent it from starting. See this.

However poking around a little bit, I found and verified that this now works ...

Bind host /dev/kmsg for OOM killer:
lxc.mount.entry = /dev/kmsg dev/kmsg none defaults,bind,create=file

See this (and scroll down a bit).

I hope this helps others.

@BenTheElder
Copy link
Member

I missed your comment previously @nmvega, I think we should be doing something else in kind as well, I just stumbled across https://www.mail-archive.com/[email protected]/msg02241.html while rethinking this and came to post about the removal in LXC :-)

I'm not sure kind should be responsible for ensuring /dev/kmsg exists anyhow vs leaving it to the host environment ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

3 participants