We're hiring!

SocketCAN x Kubernetes

Jakub Piotr Cłapa avatar

Jakub Piotr Cłapa
April 27, 2022

Share this post:

Reading time:

The SocketCAN package is an implementation of CAN protocols for Linux. Generally speaking, CAN is a networking technology that has widespread use in automation, embedded devices, and automotive fields. While there have been other CAN implementations for Linux, SocketCAN uses the Berkeley socket API, the Linux network stack, and implements the CAN device drivers as network interfaces, often making it the first choice for a CAN implementation.

Recently, we worked on a project where we used Kubernetes to control and automate deployments and updates. One component of our workflow required the availability of a CAN interface inside the Kubernetes Pod; to our surprise, such support didn't exist. Fast forward to today, and SocketCAN support is now available in the form of a Kubernetes SocketCAN device plugin!

Key takeaways

  • We have implemented a plugin that enables you to use hardware-backed and virtual SocketCAN interfaces inside your Kubernetes Pods.
  • The implemented vcan interface allows processes inside a pod to communicate with each other using the full Linux SocketCAN API.
  • If you have a real CAN adapter in your embedded system, you can use the implemented plugin to use it inside your Kubernetes deployment.

Quick start (TL;DR)

Assuming you have a microk8s Kubernetes cluster configured, you can install the SocketCAN plugin (if you are using k3s you should replace microk8s with k3s):

microk8s kubectl apply -f https://raw.githubusercontent.com/Collabora/k8s-socketcan/main/k8s-socketcan-daemonset.yaml
microk8s kubectl wait --for=condition=ready pod -l name=k8s-socketcan

Next, you can create a simple Pod that has two vcan interfaces enabled:

microk8s kubectl apply -f https://raw.githubusercontent.com/Collabora/k8s-socketcan/main/k8s-socketcan-client-example.yaml
microk8s kubectl wait --for=condition=ready pod k8s-socketcan-client-example

Afterwards, you can run these two commands in two separate terminals to verify it's working correctly:

microk8s kubectl exec -it k8s-socketcan-client-example -- candump vcan0
microk8s kubectl exec -it k8s-socketcan-client-example -- cansend vcan0 5A1#11.2233.44556677.88

Finally, you should see this:

NOTE: We support Azure AKS, microk8s, and k3s out-of-the-box. Using it with other Kubernetes providers should require minimal adjustments to the YAML file.

What is SocketCAN and why should I care?

SocketCAN let's you do CAN communication on Linux in the same way you do networking. Its benefits include familiar socket API, transparent support for any hardware device, and a flexible in-kernel filtering capability (think of a network firewall). It also allows you to create virtual CAN buses that are great for Continuous Integration testing of your software components without the hardware.

We gathered some helpful resources describing the SocketCAN architecture and recommended usage patterns.

We also asked an AI what it thinks about our SocketCAN Kubernetes plugin and below was it's answer... We are still trying to figure out, what's with all the lighthouses???

Why use Kubernetes?

Kubernetes provides a streamlined way to run containers (Docker) on other people's computers (also known as the Cloud). It's especially great for testing (notably CI systems) since it allows you to easily run as many instances as you need without manually provisioning virtual machines (VMs).

It can be also useful for embedded systems where it can help keep your containers configured and updated automatically (check out k3s for some examples).

k8s-socketcan – a Kubernetes device plugin

This is all very nice but there is a little bit of a problem – Kubernetes only supports TCP/IP natively. You cannot use hardware CAN devices and you also cannot create new virtual CAN buses unless you break encapsulation and security and use privileged pods.

Fortunately, there is a way to extend Kubernetes with device plugins. With k8s-socketcan you can allocate virtual CAN buses to your workloads in the exact same way you would allocate GPUs:

    k8s.collabora.com/vcan: 1

Or you can configure the plugin (see https://github.com/Collabora/k8s-socketcan#hardware-can-interfaces) to move a real hardware-backed CAN bus into a Kubernetes Pod and securely isolate it from other devices in the system.

This way you can easily test your CAN components in the cloud and deploy them onto your embedded devices. :)


Comments (0)

Add a Comment

Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest News & Events

Monado stays ahead: Keeping pace with OpenXR 1.1 for cross-platform, open source XR


Monado, the cross-platform open source XR runtime, has recently received significant updates to align with the features and specifications…

Blast from the past at Embedded World: Atari plays for Linux


Adhering to the fundamentals of open source, the Atari VCS OS is based on Debian using the Apertis infrastructure, and the graphics rely…

Up close and personal with STMicroelectronics' STM32MP2 at Embedded World


Using TensorFlow Lite models optimized for the STM3MP2 NPU along with an upstream-ready H.264 encoder (Video4Linux2), this demo showcases…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2024. All rights reserved. Privacy Notice. Sitemap.