Kubernetes has many powerful and advanced capabilities. Mount proc and sys in privileged containers.Containers cannot disable AppArmor or set the size of the connection tracking table. This is needed because hosted Docker containers may need to access for example storage devices (See comment in ).ĭevices: disable /sys/module/nf_conntrack/parameters/hashsize and /sys/module/apparmor/parameters/enabled: Hide two files owned by the host from the LXD containers. Security.privileged: “true”: Runs the container in privileged mode, not using kernel namespaces. Security.nesting: “true”: Support running LXD (nested) inside the container. Kubernetes will complain with messages like “Failed to start ContainerManager open /proc/sys/kernel/panic: permission denied” For privileged containers, lxc over-mounts part of /proc as read-only to avoid damage to the host. If you can account for the needs of the Docker containers you could tighten the AppArmor profile instead of disabling it completely, as suggested in. Docker containers need to be confined based on their profiles thus we rely on confining them and not the hosts. By default AppArmor will block nested hosting of containers, however Kubernetes needs to host Docker containers. Allow the container to talk to a bunch of subsystems of the host (eg /sys) (see ). Linux.kernel_modules: Comma separated list of kernel modules to load before starting the container This is needed to start the container when the host boots. Explanation of the custom rulesīoot.autostart: “true”: Always start the container when LXD starts. Start the Kubernetes dashboard lxc exec microk8s - microk8s dashboard-proxyĪnd replace 127.0.0.1 with the container’s IP address we noted earlier. The dashboard addon has a built in helper. With this, we can access Microbot from our host but using the container’s address that we noted earlier. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE lxc exec microk8s - sudo microk8s kubectl get service microbot-service lxc exec microk8s - sudo microk8s kubectl expose deployment microbot -type=NodePort -port=80 -name=microbot-service Replicaset.apps/microbot-6d97548556 1 1 1 21mĪs we can see, Microbot is running. Then create an rc.local file to perform the profile loading: cat > /etc/rc.local 443/TCP 21m To automate the profile loading first enter the LXD container with: lxc shell microk8s When the LXD container boots it needs to load the AppArmor profiles required by MicroK8s or else you may get the error: cannot change profile for the next exec call: No such file or directory lxc exec microk8s - sudo snap install microk8s -classic Install MicroK8s in an LXD containerįirst, we’ll need to install MicroK8s within the container. Note that this command uses the ‘default’ profile, for any existing system settings (networking, storage, etc.) before also applying the ‘microk8s’ profile - the order is important. lxc launch -p default -p microk8s ubuntu:20.04 microk8s We can now create the container that MicroK8s will run in. cat microk8s.profile | lxc profile edit microk8s We can now pipe that file into the LXD profile. There is a section at the end of this document to describe what these rules do. If you’re using ZFS, you’ll need this version or, if you’re using ext4, you’ll need this one. Once created, we’ll need to add the rules. The first step is to create a new profile to use: lxc profile create microk8s These can be applied using a custom profile. MicroK8s requires some specific settings to work within LXD (these are explained in more detail below). You can install LXD via snaps: sudo snap install lxd This is a great way, for example, to test out clustered MicroK8s without the need for multiple physical hosts. MicroK8s can also be installed inside an LXD container.
0 Comments
Leave a Reply. |