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

Error out of disk space when install in a LXC container #65

Closed
raguilera82 opened this issue Jul 8, 2018 · 8 comments
Closed

Error out of disk space when install in a LXC container #65

raguilera82 opened this issue Jul 8, 2018 · 8 comments

Comments

@raguilera82
Copy link

raguilera82 commented Jul 8, 2018

Hi,

I have an error when I am trying to install microk8s in a LXC container with nesting and privileged security to true. I follow these steps:

  1. After access the container, I install it: sudo snap install microk8s --edge --classic
  2. Enable dns and dashboard addons: microk8s.enable dns dashboard
  3. List all pods: microk8s.kubectl get pods --all-namespaces
  4. Access info heapster pod: microk8s.kubectl describe pod heapster-v1.5.2-84f5c8795f-c8hld --namespace kube-system

At that moment I see this info:

Events:
  Type     Reason            Age                From               Message
  ----     ------            ----               ----               -------
  Warning  FailedScheduling  21m (x6 over 21m)  default-scheduler  0/1 nodes are available: 1 node(s) were not ready.
  Warning  FailedScheduling  21m                default-scheduler  0/1 nodes are available: 1 node(s) were not ready, 1 node(s) were out of disk space.

I have checked my ZFS storage and I have not a problem with my disk space.

Can anyone reproduce it with LXC container? Any ideas?

Thank you very much

@ktsakalozos
Copy link
Member

Hi @raguilera82 ,

What is your lxc profile look like?

I had partial success in running microk8s with this one:

name: microk8s-profile
config:
  boot.autostart: "true"
  linux.kernel_modules: ip_tables,ip6_tables,netlink_diag,nf_nat,overlay
  raw.lxc: |
    lxc.apparmor.profile=unconfined
    lxc.mount.auto=proc:rw sys:rw
    lxc.cap.drop=
  security.nesting: "true"
  security.privileged: "true"
description: ""
devices:
  aadisable:
    path: /sys/module/nf_conntrack/parameters/hashsize
    source: /dev/null
    type: disk
  aadisable1:
    path: /sys/module/apparmor/parameters/enabled
    source: /dev/null
    type: disk

@ktsakalozos
Copy link
Member

@raguilera82 , seems docker inside lxc containers does not play well with ZFS https://github.com/lxc/lxd/issues/2305 could you use dir instead?

@raguilera82
Copy link
Author

Hi @ktsakalozos

Thanks for your answers. My experience with LXC containers (version 3.2) is that they work properly with Docker and ZFS (this is the recommend storage) if you enabled nesting and privileged properties of security. For example, I have a LXC container with an instance of GitLab and I can work with Docker and docker-compose without problems into the container. The issue that you have mentioned is quite old.

Now, I can not change the system storage, maybe for that reason I will get back to Minikube until this issue will be fixed.

Thank you very much for your time.

@ktsakalozos
Copy link
Member

Thank you for giving microk8s a try

@ktsakalozos
Copy link
Member

Hi @raguilera82 ,

After some experimentation with LXC and zfs I got microk8s working. Here is what I had to do:

  1. Create the following profile:
$ cat microk8s.profile 
name: microk8s
config:
  boot.autostart: "true"
  linux.kernel_modules: ip_vs,ip_vs_rr,ip_vs_wrr,ip_vs_sh,nf_conntrack_ipv4,ip_tables,ip6_tables,netlink_diag,nf_nat,overlay
  raw.lxc: |
    lxc.apparmor.profile=unconfined
    lxc.mount.auto=proc:rw sys: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
  aadisable1:
    path: /sys/module/apparmor/parameters/enabled
    source: /dev/null
    type: disk
  aadisable2:
    path: /dev/zfs
    source: /dev/zfs
    type: disk
$ lxc profile copy default microk8s
$ cat microk8s.profile | lxc profile edit microk8s
  1. Launch a container:
$ lxc launch -p default -p microk8s ubuntu:18.04 
  1. Install zfsutils-linux in the container. This package should be part of microk8s so I also opened a new issue.
# apt install zfsutils-linux
  1. And finally install microk8s
# snap install microk8s --edge --classic

Most of the work is on the lxc profile so there is not really much to do for microk8s. Here is an ascii cast of the above steps: https://asciinema.org/a/198964

Thanks

@raguilera82
Copy link
Author

Thank you @ktsakalozos

Your steps work perfectly! Also, I have tried with ubuntu:16.04 with your microk8s profile and all works like a charm.

Thank you very much for your time!

@kim0
Copy link

kim0 commented Dec 18, 2018

@ktsakalozos Thanks for the info above! I have a question, I see we're removing a lot of the security constraints from lxc .. Can you comment on how contained is that lxc container now? Is it still a little hard to break out of a lxc container with that configuration, or does it basically have full host control without much effort? Basically can I let fairly hostile guests in that lxc with some level of guarantee it's not too easy to break out

Thanks!

@ktsakalozos
Copy link
Member

Hi @kim0 ,

I am not entirely sure what you are asking me. I would say it is a little hard to reach the host but not hard enough.

MicroK8s, can get out of the lxc confinement and can access the host machine and this is the purpose of the profile we apply. MicroK8s is expected to run on the host and you are expected to trust it. What you might not trust is the user workload that runs inside Kubernetes and that is constrained by docker containers. You should be aware that MicroK8s is not supposed to be deployed in production or in untrusted environments. Its purpose is mainly to assist in application development locally. If security is of concern you should look into production grade Kubernetes solutions.

Having said that here are a few ways to harden MicroK8s.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants