Kata Container And GVisor With K0s

Using another container runtime for better isolation and security

Photo by Roxanne Desgagnés on Unsplash

As not all pods can be trusted, this article will show different options to enhance process isolation through the usage of container runtimes other than the default one (runc). We will use Kubernetes k0s distribution to illustrate all of this. If you do not know k0s, you can find a quick introduction in this article.

Create a K0s Cluster

In the introduction article, we detailed the steps needed to easily setup a k0s cluster. Recently Mirantis came with an even simpler solution introducing the k0sctl companion binary which only requests ssh access to some Linux server in order to install the cluster automatically on those ones.

After grabbing the latest release from GitHub, we can generate a default configuration file.

$ k0sctl init > k0sctl.yaml

This one contains the following properties:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  hosts:
  - ssh:
      address: 10.0.0.1
      user: root
      port: 22
      keyPath: /Users/luc/.ssh/id_rsa
    role: server
  - ssh:
      address: 10.0.0.2
      user: root
      port: 22
      keyPath: /Users/luc/.ssh/id_rsa
    role: worker
  k0s:
    version: 0.10.0

We could modify this file and add additional configuration options for the control plan’s processes (API Server, kube-controller, kube-proxy), the network plugin (Calico by default), and other components. In the current example, we just kept the default configuration and changed the IP addresses to match the pre-provisioned hosts:

• master node: 163.172.190.5
• worker node: 163.172.190.5

We launch the cluster creation with a simple command (k0sctl.yaml is the configuration file used by default):

$ k0sctl apply

k0sctl binary makes k0s cluster creation a breeze

We retrieve the kubeconfig file generated and configure our local kubectl:

$ k0sctl kubeconfig -c…