Incus launch kills kde desktop?

Incus
1 
incus launch -p default -p microk8s images:ubuntu/22.04 microk8s

And the KDE session gets killed. Desktop is gone. Tried this twice.
When I log back in the container was made and is running.
What is going on with incus launch killing the desktop ?

2

Run the following command and observe what has been added to this profile.

incus profile show microk8s
3

incus profile show microk8s

config:
  boot.autostart: "true"
  linux.kernel_modules: ip_vs,ip_vs_rr,ip_vs_wrr,ip_vs_sh,ip_tables,ip6_tables,netlink_diag,nf_nat,overlay,br_netfilter
  raw.lxc: |
    lxc.apparmor.profile=unconfined
    lxc.mount.auto=proc:rw sys:rw cgroup:rw
    lxc.cgroup.devices.allow=a
    lxc.cap.drop=
  security.nesting: "true"
  security.privileged: "true"
description: ""
devices:
  aadisable:
    path: /sys/module/nf_conntrack/parameters/hashsize
    source: /sys/module/nf_conntrack/parameters/hashsize
    type: disk
  aadisable2:
    path: /dev/zfs
    source: /dev/zfs
    type: disk
  aadisable3:
    path: /dev/kmsg
    source: /dev/kmsg
    type: unix-char
  aadisable4:
    path: /sys/fs/bpf
    source: /sys/fs/bpf
    type: disk
  aadisable5:
    path: /proc/sys/net/netfilter/nf_conntrack_max
    source: /proc/sys/net/netfilter/nf_conntrack_max
    type: disk
name: microk8s
used_by:
- /1.0/instances/microk8s
project: default

I see nothing there that could cause the kde desktop to exit or crash. I hope someone does.

4

That’s a terrible profile, this bypasses all security features and allows that container to directly reconfigure the kernel as it sees fit, including fully escaping the container and taking over the host system.

It’s not particularly surprising that this would then have negative effects on the whole system.

5

Hi Stéphane,

It’s the stock profile for ZFS at https://raw.githubusercontent.com/ubuntu/microk8s/master/tests/lxc/microk8s-zfs.profile as mentioned on https://microk8s.io/docs/install-lxd :confused:

Can we propose a better profile ?

– Hans

6

k8s is not meant to run in a container. It requires a physical system or a VM, and has been designed with such a setup in mind. Even the documentation talks about testing microk8s in a container instead of actually using it like that. When your host system crashes, it means that nasty things happen behind the scenes.

You should use an Incus VM with microk8s and not a container.

7

We’ve had that problem with the microk8s folks for well over 5 years now, I don’t see it improving any time soon.

K8s should be able to work without security.privileged and without any of those raw.lxc options, but making that work requires folks who actually understand Kubernetes to perform code changes to Kubernetes to properly behave when run in a container, as it stands it expects to be able to alter system-wide kernel setting on start up.

Unfortunately the microk8s team has been a team of packagers / scripters, not core Go and container developers, so nothing has been done to resolve this issue.

1 Like
8

Hi Stéphane,
Thanks for the background, much appreciated and it aligns well with my thoughts on the various *k8s.
Sad that this issue exists though.

Simos: for prod metal is used, this ticket is for dev and test with insufficient resources for a VM which makes Incus look ideal.

– Hans