Back

Kubernetes plug-in, CloudRun... Key takeaways from Paris Containers Day!

Image Slider

June 10, 2021

By Mickaël D., DevOps expert

Paris Containers Day is an event organized by Wescale and Publicis Sapient (formerly Xebia) since 2016, focusing on containers and orchestration. The event was ultimately held online, like other conferences such as AWS Re:Invent, despite the fact that it was originally planned to be held in person.

In addition, unlike previous editions, which took place over a single day, this one will take place over two afternoons.

What should we take away from this series of lectures? 

Few announcements—that's definitely not the goal of Wescale/Publicis Sapient and the various speakers. However, there has been a lot of feedback on topics such as container runtimes, security applied to Kubernetes, Cloud Run, and plugin development for Kubernetes.

1. Threat Detection and Response in Kubernetes with Falco

Presented by Thomas Labarussias, Site Reliability Engineer at Qonto, Contributor to Falco, and creator of FalcoSidekick

The purpose of this session is to explain how Falco works, a project related to runtime security and threat detection within Kubernetes, and to also present FalcoSidekick and how it works. 

Falco is an agent for detecting *unusual* behavior at runtime created by Sysdig. It captures logs in real time, including kernel, container, and Kubernetes logs. 

Using a relatively simple and configurable rules engine (YAML-formatted instructions), Falco triggers alerts based on the content of captured logs. In addition, it comes with over a hundred predefined rules. 

Since Falco's default architecture only provides for five different output types (stdout, file, gRPC, shell, and HTTP), FalcoSidekick extends this by also adding a user interface.

Please feel free to visit the official website.

2. CloudRun: a Knative-compatible managed product from Google Cloud

Presented by Guillaume Blaquière, Cloud Architect at Sfeir. 

CloudRun is a serverless solution for container hosting, unlike Cloud Functions or App Engine, which are more source code-oriented, allowing for greater portability. 

CloudRun features include automatic scalability based on the number of requests the container has to process, as well as a managed mode based on Knative and the ability to leverage the power of Anthos on Cloudrun clusters. 

It also features demonstrations of Knative on AWS/EKS, GCP/GKE, on GCP/HKE + the CloudRun plugin, and finally, a Managed CloudRun.

More information at

3. And for a few more runtimes...

Presented by Thomas Gérardin - Cloud Builder at Wescale

This presentation begins with a history of containerization: from 1979, with Chroot, to the present day with the various runtimes and the emergence of a standard (Container Runtime Interface - CRI) proposed by the OCI (Open Container Initiative).

Here is a list and some information about different runtimes: 

  • **Docker**, which relies on the **containerd** runtime, 
  • **containerd**, which itself relies on **runc**, 
  • **runc** or **crun**, which are low-level runtimes (close to the kernel and written in Go and C, respectively), 
  • **rkt** (whose project was halted in February 2020), 
  • **cri-o**, which manages numerous features, including images, security, metrics, the file system, etc. 
  • **Kata-container** is embarking on a new path, that of micro-VMs (which emphasizes deeper isolation). 

He reminds us that runtimes provide different features depending on their level and "proximity" to the kernel, and describes an example of a stack with a container orchestrator linked to one or more container runtimes (depending on the features required).

More information at:

4. Misused containers

Presented by Emmanuel Pluot and Olivier Cloirec, Site Reliability Engineers at Publicis Sapient.

This conference covers a wide range of topics, such as: 

Builder: focus on the C++ language and compilation during the container image build. 

Interpreter: feedback on using the Groovy language during container build. The principle is quite similar: an executable is generated for the purpose of testing a practical case. 

nsenter: Hack the host machine by stealing the namespace of a host process using the PID of a process. This looks like a security flaw and can be mitigated via an admission controller. 

LogForwarder: how to redirect logs to **stdout** output using **Fluentbit**, 

X11 / IDE: Detour and start a graphical application in a container.

The presentation focuses on Visual Studio Code, but given the packages installed, any graphical application can be installed. This application of container-related features is one of the least known and least useful.

5.    Create and distribute a plugin for Kubernetes

Presented by Aurélie Vache, Cloud Developer at StackLabs, and Gaëlle Acas, Site Reliability Engineer at Stack Labs.

Aurelie Vache, already well known for her work popularizing Kubernetes and the container ecosystem in general, began by explaining the principle behind **kubectl** and how it works in a very simple way. However, since adding plugins is linked to the core of **Kubernetes**, the release cycle can be relatively long.

However, the most time-consuming part of the process involves creating a plugin, which consists of: 

  • First, create a file named *kubectl-myplugin*, 
  • Make it executable, 
  • Place it in the **PATH** (/usr/local/bin, for example), 
  • Run the plugin. 

All this with relatively easy-to-use languages such as Python, Bash, Go, Rust, or Quarkus (those with which we can code a CLI).

Once the plugin has been developed and tested, it remains to be packaged, and that's where Krew, the plugin package manager for Kubernetes, comes in.

More info about Krew

6. Containers within containers (maritime)

Presented by Guilhem Lettron, Freelance Site Reliability Engineer, and Barthelemy Vessemont, Head of Infrastructure, at Storelift.

The goal of the presentation was to create a cashierless store using shipping containers, managing the heterogeneity of several details such as hardware (Raspberry, Arduino, GPU for machine learning) and containerized software.

Furthermore, through the use of numerous computer vision frameworks, it is entirely possible to track customers inside stores.

To this end, they organized themselves as follows: 

- Container Build: images approximately ten to twelve gigabytes in size containing all the necessary frameworks and divided into three stages. In addition, through the use of Docker-in-Docker, the workload on the machines is much more configurable and less financially impactful (especially when using the cloud, with instances that have fairly significant resources). 

- The physical part was more complicated because the initial technical choice was to use Raspberry machines.

However, they realized there were some technical limitations (the installation of Python packages was extremely time-consuming) and ultimately opted for ARM64 emulators containerized on conventional X86 servers.

The final stack, beyond Kubernetes, brings together numerous technologies such as:

  • Observability: Thanos, Prometheus, Fluentd, Fluentbit, and cAdvisor
  • Network: After testing ROS, Flannel, and others, they finally opted for Host-Network due to certain technical limitations of the aforementioned CNI plugins.
  • Deployment: They started by testing Ansible and switched to Kubernetes because of its modularity.

More info about Boxy

7. K3S, the lightweight Kubernetes, builds my images without Docker

Presented by Romain Boulanger - Cloud Engineer at Sfeir

He presents us with the ideal case study of a customer who wants to migrate their applications to Kubernetes while using their own machines, without forgetting the emphasis on security.

Created by Rancher (already at work on the well-known Kubernetes cluster orchestrator), K3S is a lightweight version of Kubernetes with certain features removed. It is very quick to install and comes as a simple executable file. It is recommended for anything related to IoT, continuous integration, or RAM architectures.

K3S is described as "lightweight" because the following features differ from Kubernetes:

  • Legacy, alpha, non-default, and add-ons,
  • Using sqlite3,
  • Automatic TLS management,
  • Few dependencies
  • No port to expose for the API.

In addition, Docker (like ETCD) is optional.

More info about K3S

You can find the sessions from Paris Container Day 2021 (as well as previous editions) here: Paris Container Day - YouTube

https://youtu.be/-0SNfmGb1pE