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:

resources:
  limits:
    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

Kernel 6.8: MediaTek community flourishes

11/03/2024

The latest Linux Kernel 6.8 release brings thousands of new lines of code, improving the core kernel, architecture support, networking,…

Release the panthor!

04/03/2024

Late last week, the long-awaited kernel driver supporting 10th-generation Arm Mali GPUs was merged into drm-misc. The existing Gallium driver…

Patch submitted to introduce GitLab-CI pipeline for Linux kernel testing

01/03/2024

This initial version includes static checks (checkpatch and smatch for now) and build tests across various architectures and configurations,…

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.