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

Add Kata Containers docs #257

Merged
merged 15 commits into from Sep 5, 2019
@@ -0,0 +1,121 @@
---
wrapper_template: "base_docs.html"
markdown_includes:
nav: "shared/_side-navigation.md"
context:
title: "Untrusted container runtimes"
description: Configure and use kata containers as the untrusted container runtime
keywords: kata, untrusted runtime, image
tags: [architecture]
sidebar: k8smain-sidebar
permalink: untrusted-container-runtime.html
layout: [base, ubuntu-com]
toc: False
---

From 1.16 onwards, you have the option of attaching Kata Containers to
**Charmed Kubernetes** as part of a pluggable architecture for untrusted
container runtimes, allowing more to be developed in the future.

This runtime gives you the ability to fence containers via a hypervisor,
rather than runc. If used correctly, this can
[improve security](https://katacontainers.io/collateral/kata-containers-1pager.pdf).
This conversation was marked as resolved by joedborg

This comment has been minimized.

Copy link
@tvansteenburgh

tvansteenburgh Aug 27, 2019

Contributor

I'd replace the above two paragraphs with:

Beginning with Charmed Kubernetes 1.16, the Kata Containers runtime can be used with containerd to safely run insecure or untrusted pods. When enabled, Kata provides hypervisor isolation for pods that request it, while trusted pods can continue to run on a shared kernel via runc. The instructions below demonstrate how to configure and use Kata Containers.


## Caveat

Kata Containers can only be used on bare metal owing to KVM's reliance on the
This conversation was marked as resolved by joedborg

This comment has been minimized.

Copy link
@tvansteenburgh

tvansteenburgh Aug 27, 2019

Contributor

s/owing/due/

kvm Kernel module, which can't be installed on cloud instances.
This conversation was marked as resolved by joedborg

This comment has been minimized.

Copy link
@tvansteenburgh

tvansteenburgh Aug 27, 2019

Contributor

Is the requirement actually bare metal, or would nested virt also work? I think saying "cloud instances" is a little vague, and we should try to be more precise with the language here. For example, Azure supports nested virt, would kata work there? EC2 has the "bare metal" i3 instance type. These are cloud instances that might work with Kata.


If you see an error similar to
This conversation was marked as resolved by joedborg

This comment has been minimized.

Copy link
@tvansteenburgh

tvansteenburgh Aug 27, 2019

Contributor

Attempting to use Kata on a host that doesn't support virtualization may result in an error similar to this one:


```
Failed create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container: failed to create containerd task: Could not access KVM kernel module: No such file or directory
qemu-vanilla-system-x86_64: failed to initialize KVM: No such file or directory
```

it's probably due to this.
This conversation was marked as resolved by joedborg

This comment has been minimized.

Copy link
@tvansteenburgh

tvansteenburgh Aug 27, 2019

Contributor

delete this line


## Deploying Kata Container
This conversation was marked as resolved by joedborg

This comment has been minimized.

Copy link
@tvansteenburgh

tvansteenburgh Aug 27, 2019

Contributor

I think this section should be updated to demonstrate the use of a kata overlay, rather than individual commands.

This comment has been minimized.

Copy link
@joedborg

joedborg Aug 28, 2019

Author Contributor

Let's have both.


Kata Containers can be deployed to any Charmed Kubernetes cluster that's
running with [containerd](container-runtime).

First, we need to deploy the charm.

```bash
juju deploy cs:~containers/kata
```

After which, we need to relate the charm to the principals. Currently, this
is only to "anchor" the charm.

```bash
juju add-relation kata kubernetes-master
juju add-relation kata kubernetes-worker
```

Finally, we can relate the untrusted container runtime with the container
runtime.

```bash
juju add-relation kata:untrusted containerd:untrusted
```

All together.

```bash
juju deploy cs:~containers/kata
juju add-relation kata kubernetes-master
juju add-relation kata kubernetes-worker
juju add-relation kata:untrusted containerd:untrusted
```

## Deploying Pods to Kata

### Untrusted Annotation

The simplest way to run your pods with Kata is to annotate them with
`io.kubernetes.cri.untrusted-workload: "true"`. For example.

```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-untrusted
annotations:
io.kubernetes.cri.untrusted-workload: "true"
spec:
containers:
- name: nginx
image: nginx
```

### RuntimeClass

If you don't want to taint your workloads as `untrusted`, you can also create
the following `RuntimeClass`.

```yaml
apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
name: kata
handler: kata
```

After this `RuntimeClass` is created, we can run workloads that are pinned to
the class.

```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-kata
spec:
runtimeClassName: kata
containers:
- name: nginx
image: nginx
```
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.