Forem: Nuno do Carmo

Portainer: deploying MicroK8s

Nuno do Carmo — Thu, 06 Jul 2023 16:46:31 +0000

Introduction

Some weeks ago, I published a blog post as an answer to another blog about Rancher manager requirements.

However, one of the collateral impact of the original blog post was an unwanted publicity to another great project: Portainer.io

Their team has contacted me and we've been talking since then. They were simply 5⭐ on their response and on their DMs.

I told them how much I appreciated their project and that I fully understood they had no part on the initial blog post. And while we were discussing, they told me that they were launching a new feature: deploy a MicroK8s node directly from Portainer.

As said in the previous blog post, for anyone following me since some time, they do know my big appreciation for MicroK8s and the team at Canonical.

It was a certitude that I would test it and blog about how to use it on WSL2.

So without further due, let's see how Portainer and MicroK8s might be one of the greatest match that might go a bit unnoticed! (note: this is purely my personal opinion)

Prerequisites

Here’s the list of components I used for this blog post:

OS: Windows 11 Professional version 23H2 - channel: Insiders canary / build: 25393

WSL2 distro: Ubuntu 22.04

Since WSL v0.67.6, systemD can be enabled in /etc/wsl.conf
Since WSL v1.3.10, cgroups v2 can be used without a direct impact on containers use cases
To enable cgroups v2, here's changes in both WSL configuration files

  # Windows filesystem: $env:USERPROFILE\.wslconfig
  [wsl2]
  kernelCommandLine = cgroup_no_v1=all systemd.unified_cgroup_hierarchy=1

  # Linux distro filesystem: /etc/wsl.conf
  [boot]
  command = sh -c 'umount /sys/fs/cgroup/unified && umount /sys/fs/cgroup/systemd && umount /sys/fs/cgroup; mount -t cgroup2 cgroup2 /sys/fs/cgroup -o rw,nosuid,nodev,noexec,relatime,nsdelegate'

The distro hostname has been changed in /etc/wsl.conf
Port forwarding has been disabled in $env:USERPROFILE\.wslconfig

Docker: Docker Desktop (for Windows)
- Version: 4.21.0 (113844)
- Docker socket shared with the distro: Settings > Resources > WSL integration
SSH keys are generated
[Optional] Terminal Preview: Windows Terminal
- Version: 1.18.1462.0

Deploying Portainer as a Windows container

First thing first, yes the title of this chapter is correct, not a typo.

Secondly, you could ask: why? In addition to the usual "because I can", the goal here is to show the long history of Portainer with the containers world and "back in the days", the idea of Windows containers was somehow talked about quite often.

And if the talks are less and less present today, the fact that Portainer continues to have a Windows container solution, shows their commitment to their project as open as possible in terms of backend technologies.

Finally, this will allow to have a solution working fully on your machine without any Virtual Machines involved.

Portainer Business Edition license

The feature of deploying a MicroK8s cluster is part of the Portainer Business Edition, and not the community one.

Before anyone jumps into conclusions how bad this is or could be, let me say that I fully approve the monetization of features that are more targeted at companies rather than community overall.

And to ensure the paywall doesn't feel as hard as "if you don't pay, you cannot try/use the features", Portainer provides a "free tier" for testing purpose with few licenses.

To obtain your free tier Business Edition, go to Portainer.io and click on the Get Started Free button. Fill up the form and you'll receive an email with the license. Keep it handy, as we'll need it once we deployed the Portainer container.

Starting Portainer

The full documentation on deploying Portainer Business Edition can be found on their docs site or their academy site.

The step by step approach is a real good way to learn, so it's strongly advised you go through the docs or academy at least once and see the different options.

For this blog post, in order to avoid duplicated docs, only the final command will be shared:

# Check which Docker daemon is running
docker version --format '{{json .Server.Os}}'

# [Optional] Switch the Docker daemon to Windows Containers
& 'C:\Program Files\Docker\Docker\DockerCli' -SwitchDaemon

# Create a volume, needed by Portainer
docker volume create portainer_data

# Start the Portainer Windows container
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart always -v \\.\pipe\docker_engine:\\.\pipe\docker_engine -v portainer_data:C:\data portainer/portainer-ee:latest

# [Optional] Check if the container is running
docker ps

**NOTE:* the Docker daemon can be switched from Docker Desktop tray icon too.*

Once the container is running, you can access Portainer web interface on https://localhost:9443.

**NOTE:* you'll get a certificate warning as the web site is using a self-signed certificate. You can trust it and will be able to see the page above.*

From here, follow the Portainer docs to setup your user, enter your license, optionally add the current Docker instance as your first environment and finally see Portainer's management page.

You're now ready to deploy a brand new MicroK8s cluster from Portainer!

Deploying MicroK8s

Before you go ahead, please note that this section if fully described in Portainers docs on how to deploy MicroK8s.

If it already exists, then why "duplicating it", you might ask? Well, as said above, I hate duplicating docs indeed, however the setup used, Windows containers + WSL2 target, is not covered. Which is totally fine as it might be a very edge-y case anyways. And, you'll see later, in order to make the whole environment work as intended, there's some need of Windows network configuration.

But I don't want to spoil it for you, so let's tackle this last section step by step.

Step 1: Create new SSH credentials

As written in the docs, you'll need to use SSH to connect to the host where you want to deploy MicroK8s.

In Portainer, you'll need to create a new Shared Credential before the creation of a new environment.

Once again, to avoid docs duplication, you can refer to Portainer docs on how to add SSH credentials for all the details. And here's the quick steps to do it:

Click on Settings in the left menu to expand it and click on Shared Credentials
Click on + Add credentials button in the top right of the main page
Click on the SSH card to select it
Fill all requested fields in the Credential details section
- Warning: ensure that the SSH key you'll use is also added to the $HOME/.ssh/authorized_keys file in your WSL2 distro!
Click on Add credentials at the bottom of the main page

With the credentials created, you can continue onto the next step.

Step 2: Create a new environment

Go to the Portainer management page and perform the following actions:

Click on Environments in the left menu
Click on + Add environment button in the top right of the main page
Click on Create a Kubernetes cluster card under the Set up new environments section
Click on Start Wizard at the bottom of the main page
Provide a name to your new cluster
- Example: wslmicrok8s
Select the correct credentials
- Info: if there's only one credential, it will be selected by default
Enter the WSL2 IP and click on Test connections
- Info: you can get the IP from your distro with the command hostname -I | cut -f1 -d' '

At this stage, you should see a connection timeout error. Jump into the next smaller step to fix it.

Step 2.1: It's all about networking

This is normal as the networks used by Docker Desktop for the Windows containers and WSL2 are explicitly separated. So all this work to end up here?

Well, no, thankfully this issue is similar to another one which was resolved few years ago by a WSL2 community member.

Let's resolve the issue:

# Check which network the Portainer container is using
## The command below assumes the container name is "portainer"
docker network ls --filter id=$(docker inspect portainer --format '{{ range.NetworkSettings.Networks}}{{.NetworkID}}{{end}}')

# Enable the Docker and WSL networks to communicate
## The command below assumes the Docker network name is "nat"
powershell.exe -c 'Get-NetIPInterface | where {$_.InterfaceAlias -eq "vEthernet (WSL)" -or $_.InterfaceAlias -eq "vEthernet (nat)" } | Set-NetIPInterface -Forwarding Enabled'

After you ran the command to connect both networks, you can go back to the Portainer management page and click on Test connections again.

This time, you should get a successful message stating the node is reachable.

Provisioning the new environment

The last options of the environment are:

Pick a Kubernetes version
Select additional MicroK8s Addons
With all the mandatory fields filled, you can click on + Provision environment at the bottom of the main page
Click on Close

You'll be redirected to the Environments page and you'll see under the URL column, all the different provisioning stages.

The provisioning should take few minutes and once completed, you can click on the environment name to see its details.

But what you might really want, is to see the MicroK8s cluster content, so click on Home at the top of the left menu, and you should see a line with your new cluster.

[Optional] See the provisioning from the distro

From a WSL distro point of view, you list before and after the list of snaps to see the difference once MicroK8s has been deployed.

Congratulations, you have now deployed a new MicroK8s cluster on a WSL distro while running Portainer as a Windows container.

Conclusion

As I stated in the introduction, I was already fan of Portainer before and I can tell the software has grown a lot and the Enterprise features are also well thought.

I would like to give again a shoutout to the Portainer team for their support and overall kindness during the writing of this blog. You're an amazing team and I wish you to be very successful.

Lastly, I hope you had fun reading this blog and learnt something out of it.

The Corsair 🏴‍☠️

Rancher & MicroK8s

Nuno do Carmo — Fri, 02 Jun 2023 12:10:33 +0000

Introduction

This blog is an "answer" to the The New Stack article and the goal is to see how few changes, based on the Rancher official documentation, could help run the example in the article.

Prerequisites

I'm working on Windows and to have a comparable environment, I created an Hyper-V virtual machine (VM) instead of using WSL2.

Here's the configuration details:

VM: 2 cores / 4Go Ram / 60Go disk
OS: Ubuntu server 22.04
Option: OpenSSH server installed

I decided to not install MicroK8s from the installer and will instead make it part of the environment configuration steps (see below).

Memory consumption

One of the points pointed out by the author, is that "Rancher" requires at least 4Go RAM as mentioned in the docs.

So while there's some sort of misunderstanding in the requirements, I've taken up to the challenge and created the VM with only 4Go.

Note: the misunderstanding is that the requirements are only for Rancher on Docker, in a standalone server. The author tried to put everything in the same server. This means that only the Rancher requirements were "looked into", and discarded the MicroK8s' own requirements.

For the time being, let's see what a fresh install of Ubuntu server uses:

As displayed, the OS footprint is about 200 Mo, which represents only 5% of the RAM available.

Configuration

Once the OS is installed, we can SSH with the user and password created during the installation.

MicroK8s

The first part will be to update the system and install MicroK8s:

# Update the repositories
sudo apt update

# Update the packages
sudo apt upgrade -y

# Install MicroK8s
sudo snap install microk8s --classic

# [Optional] Install Kubectl
sudo snap install kubectl --classic
## [Option 2] Create an alias to `microk8s kubectl`
sudo snap alias microk8s.kubectl mk

# Add the user to the microk8s group
sudo usermod -a -G microk8s $USER
sudo chown -R $USER ~/.kube

# Apply the group change by starting a new session

# [Optional] Create the .kube directory
mkdir ~/.kube

# Get the Kubeconfig
microk8s config > ~/.kube/config

Attention: MicroK8s shows different cluster IP depending on which kubectl is used.

Attention 2: As of May 2023, the version installed by default is 1.26.4 from the channel 1.26/stable. However the current version of Rancher Manager, 2.7.3, only supports Kubernetes 1.25+. Source: Support matrix | SUSE

Memory consumption

As stated in MicroK8s official documentation, the cluster doesn't need much RAM, about 500Mo, which fully correlates with the RAM usage once MicroK8s has been installed:

As displayed, the current RAM used is around 700Mo which represents the 200Mo from the OS and the 500Mo from MicroK8s. So we're about 20% of RAM usage, which seems plenty to continue.

Docker

The second part and which relates now to the article, is the installation of Docker which will be used to run the Rancher container.

# Install the dependencies
sudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release -y

# Install the Docker repository GPG key
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Add the Docker repository
echo "deb [arch="$(dpkg --print-architecture)" signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Update the repositories
sudo apt update

# Install docker
sudo apt-get install docker-ce docker-ce-cli containerd.io -y

# Add the user to the docker group
sudo usermod -aG docker $USER

# Apply the group change by starting a new session

Memory consumption

Docker install doesn't consume much, around 20Mo only. This is normal as the daemon is idle with no containers running:

Let's try to run a "minimal" Nginx container from the Chainguard image:

Even with such minimal container running, the RAM usage is about 90Mo.

Note: before continuing, I stopped all the containers running and rebooted the server. This brought bach the RAM usage to 790+Mo

Rancher Manager

Here's the final component, and so far the RAM usage seems to handle pretty well the workloads.

I'll start a new container based on the latest Rancher version, instead of 2.4 as described in the article. The reason why the author faced issues between Rancher and MicroK8s is due to the version mismatch.

The current version of Rancher, 2.7.3, only supports Kubernetes versions up to 1.25 (as described in the official Rancher Support Matrix. However, the default MicroK8s version is 1.26.

I'll explain later how we can easily change the MicroK8s version, but let's go back to the Rancher container.

The command to start the container is the following:

# Start a new Rancher container
docker run -d --name=rancher-server --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher:latest

Once the container started, Rancher is available via the web on the address of the server. Example: https://192.168.0.31

Memory consumption

The Rancher container contains a K3s single node cluster, the containerD runtime and Rancher Manager installed. This is reflected in the memory usage:

As displayed, this is a clear jump in RAM usage as it went from almost 800Mo to 2Go+, which represents 50% of the total RAM.

Still, there's plenty of RAM to continue and perform the last task.

Add MicroK8s to Rancher

As stated above, one of the issue the author ran into was due to a version mismatch.

The current default version installed by MicroK8s is 1.26. So to ensure the compatibility between Rancher and MicroK8s, the version needs to be downgraded to 1.25.

Thanks to the concept of snap channels, this can be achieved in one command:

# [Optional] Check the current MicroK8s version
microk8s version

# Change the channel to the 1.25 stable
sudo snap refresh microk8s --channel=1.25/stable

# [Optional] Check the current MicroK8s version
microk8s version

Now that all the components have compatible versions, MicroK8s can be imported into Rancher in the web interface as follow:

In the welcome page, once logged in, click on Import Existing

Choose Generic

Write a name, all lowercase, and click Create

On the registration page, click on the second option curl --insecure ... to copy the text

Note: Based on how Rancher was installed with the Docker command, it created a self-signed certificate. This means that MicroK8s will not have the corresponding certificate and would generate an error if the first option was used

Once the registration completes, the node will appear as active

Memory consumption

After all the tasks were done, and which were successful, the final RAM usage is around 2.5Go, which represents 60%+:

Conclusion

As stated in a tweet, this article comes with a bitter-sweet taste for me.

In one end, I can totally relate to the "learning in public" by writing blog posts, trying new technology and making (many) mistakes while doing so.

However when I face specific issues that others don't seem to have, then I tend to ask for help on different community channels, and of course I go back to the products/projects official documentation.

This is also where I don't relate at all, with the article as a whole and have some questions about the publishing process of The New Stack. The article ends abruptly by stating: Portainer is better, use it!

Well, because the article is somewhat incorrect in certain points, again due to the lack of documentation checking, the article actually brought a shade on both Portainer and MicroK8s which never asked for it (I got DMs from both companies).

So here's my advice to anyone reading this blog post: please continue learning in public, ask questions and if you face issues ask for help. But sincerely, avoid doing unwanted comparisons and READ THE DOCS! I'm a Tech Writer, if my docs are not good/complete, open an issue, they're ALL open sourced.

The Corsair 🏴‍☠️