1 of 26

Love, Death and Robots - with Wasm & K8s on Boston Dynamics Spot

2 of 26

Can containers and Kubernetes run anywhere? Yes, nearly. We have seen in the past fighter jets, fully isolated environments, security critical infrastructure and more with Kubernetes. So it is no wonder that Boston Dynamics Spot, the most advanced mobile quadrupled robot, is running on containers too. But this wasn’t enough for us.

How and why we tweaked the (real world) bot a little and what are our lessons learned is part of this talk. We will show you the easy steps to migrate to K8s, the experimental integrations with Wasm and ideas on how to manage Spot like any other Kubernetes.

Our targets are to provide a highly reliable, self-healing software infrastructure for industrial great robots that are secure, fast and autonomous.

  • Intro
    • Us
    • Spot
  • Containers are everywhere
  • Our constructed problem
    • Portainer is great but the process around feels clumsy
    • Development experience is bad
    • Portainer is great BUT poor node control, node status, separation of concerns (groups, SA),
    • Look and feel: for an industrial great robot
  • Step 1: Why not Kubernetes?
  • Step 2: Why not WASM?
  • Step 3: The fully autonomous Spot dev process
  • Sum up

3 of 26

Who are we?

Max Körbächer

Founder and Cloud Native Advisor

  • CNCF Ambassador
  • Co-Chair CNCF TAG Environmental Sustainability
  • Contributed to the Kubernetes release team for 3y and related K8s technologies

Kevin Hawryluk

Head of Technology

  • Can’t be with us today

4 of 26

Meet Spot

Spot is a mobile robot that can carry around 14kg of equipment.

Can go almost anywhere, by controller or autonomously.

Is customizable by different mountable hardware, via an SDK and pre build solutions.

Source: BostonDynamics

5 of 26

6 of 26

So containers can run anywhere, huh?

For me, Spot looks like an agile server with cameras, legs and a Nintendo controller.

Can I put a containers & Kubernetes on it?

Source: BostonDynamics

7 of 26

Everything starts with a stupid idea

Source: BostonDynamics

8 of 26

Spot Core & Spot Core IO

Spot itself is a black box but extensible

Item

Description

Motherboard

i5 Intel® 8th Gen (Whiskey Lake-U) Core™ CCG Lifecycle

Memory (RAM)

16 GB SO-DIMM DDR4 2666

Primary storage

512 GB M.2 22x60 SSD

Physical interfaces

1 x RS-232 ports�3 x USB 3.1�2 x USB 2.0�2 x DisplayPort�1 x HDMI

Accessories

Computer port & dust blocking kit �Power adapter DC 12 V, 5A, 60 W Level VI

Operating system

Ubuntu Desktop 18.04 LTS 64-bit

Source: BostonDynamics

9 of 26

Spot Core & Spot Core IO

Spot itself is a black box but extensible

Item

Description

CPU

6-core NVIDIA Carmel ARM V8.2 64-bit CPU with 6MB Lw + 4MB L3 cache

GPU

384-core NVIDIA Volta GPU with 48 Tensor cores

Memory

16GB 128-bit LPDDR4x at 51.2 GB/s

5G/LTE

User-installable SIM card

Disk encryption

SSD encrypted with standard LUKS technology

Network encryption

Connections encrypted with TLS 1.2 and 1.3

Authentication

Access to services restricted to authenticated users

Secure boot

Tamper-proof filesystem with hardware root of trust

Firmware verification

Firmware updates must be cryptographically signed

Source: BostonDynamics

10 of 26

Optimization Potential

11 of 26

Surprise!

Containers are already there

On Spot Core + Core I/O we have:

  • Ubuntu 18.04
  • Portainer on spot Core
  • Custom Docker interface on Core I/O
  • Different processor architectures
  • GPUs
  • Accessible and secured storage

Core is going to be deprecated in future.

12 of 26

Some downsides of this setup

  • No in depth observability given
  • No internal security scans possible (yet)
  • Health checks are missing
  • Node awareness and handling not given
  • No custom roles
  • Can’t change settings of the cluster

It is a good starting point, but many basic features you most of the time wish to have, are missing.

13 of 26

Current development process

For Spot Core I/O

  • No automation possible
  • The dev cycle is slowed down dramatically
  • Containers are not very secure

Development

Most part of the software build by Roboverse is written in Python. Development happens locally.

Continuous Integration

If the software is ready to be deployed, it needs to be packages as a tar ball.

Continuous Deployment

And gets then manually uploaded through a GUI to the Spot.

Test & Execution

Lastly, we are good to go for testing and executing the newly written functions.

Configuration

Unpacked, the new software must be configured and ensured that all configs are set correctly.

14 of 26

Our dirty road of changes

15 of 26

Trigger warning!

What we are doing here is experimental as we try to discover better approaches

16 of 26

Our target setup

Before we were aware of recent changes of Core I/O

  • Increase system visibility to all extends (full monitoring & logging of the node, pods and any other actions happening on the core)

  • Optimize the development cycle by speeding up the process and deployment to spot -> also interesting for field operations & autonomy

  • Provide a high level of availability and self healing capabilities

  • Security, security & security

17 of 26

Replacing Portainer

Besides the mentioned downsides we also have:

Portainer/Compose is failing when sensors are missing/not connected.

The error handling causes drastical miss behaviour of the entire stack.

sudo snap install microk8s --classic --channel=1.27

Ubuntu 18.04

microK8s

Observability, Policies, Security

18 of 26

Replacing Core I/O interface

The latest version of Core - I/O got rid of Portainer to, and runs an own container runtime.

This solution prevents at the moment running anything then a simple container.

soooo….

Ubuntu 18.04

crun

kind

19 of 26

Extending Core I/O with wasm? because we can

Why to do that?

  • Different target architectures provide a pain point during development

  • Having many different versions of containers at the same time eating up space

  • Increase the security limit

Ubuntu 18.04

crun

kind

kwasm

20 of 26

Providing WASM as additional runtime

# Add helm repo

helm repo add kwasm http://kwasm.sh/kwasm-operator/

# Install operator

helm install -n kwasm --create-namespace kwasm-operator kwasm/kwasm-operator

# Annotate single node

kubectl annotate node kind-worker kwasm.sh/kwasm-node=true

# Run example

kubectl apply -f examples/kind/runtimeclass.yaml

kubectl apply -f examples/kind/pod.yaml

21 of 26

Issues!

Still WIP

Bringing the different machine learning models into wasmSpot written yet in Python is kinda tricky.

Simple apps are no issue, but the complexity of different dependencies are not yet solved.

22 of 26

GitOps in Spot

What we want to achieve:

  • Running ArgoCD in kind looking for new images whenever it has connection (5G/Wifi) or idles (charging station, planned break in a route).
  • During development, this speed things up drastically.
  • During working in the field and client side, this will allow to reduce the maintenance costs.

The dirty way we took:

  • Quick and dirty implementation, no user management, just defaults
  • We didn’t evaluate “the right” solution, might be replaced in future
  • Have to build a scaling process around it

23 of 26

Newly gained capabilities

Improved development cycle

Bringing GitOps to the spot, right now ArgoCD works fine for this and via wasm the custom written software run on any robot.

Increased Developer experience and faster deployment of new versions.

Security (again)

Sealing of critical control mechanisms in wasm to prevent miss usage. Forbidding activities that a container shouldn’t do.

Spot is a very sensitive robo-dog (sorry), catch it, plug a cable, upload your image -> not any more!

Autonomy

Event driven starting of wasm application & ArgoCD updates via Mobile/Wifi connection.

No further more tar uploads via the backdoor cable and a use case for real field operations.

Opened for fine grained extensibility

Fine tuned access management, restrict policies, only signed images are allowed to be executed. Plus whatever else you want!

Getting control of the platform while improving security. In addition, we can now optimize the workload on Spot.

24 of 26

What we learned:

Spot is really just a walking server with sensors (and more).

It’s almost disappointing how easy Kubernetes & wasm got already.

Machine learning is not yet ready for wasm.

Keep in mind, this is experimental, we are not done yet!

Stupid ideas can turn in something relevant, BUT

25 of 26

Our cloud native ecosystem is maturing. To implement stuff getting way to easy.

26 of 26

Feedback & Questions