In the Spring, container conferences sprout everywhere! One was the Paris Container Day in June, which we had the chance to attend. With one day and around 20 talks, it was a more modest event than behemoths like KubeCon (which we’ll talk about soon), and focused mostly on container platforms rather than on developing containers.
The publicized theme of the conference was “Standards & Craftsmanship”. Rehashing the parallel with shipping containers as “the standard that led to globalized trade,” standardization efforts and their effects were indeed well covered.
Security in containers
With Aqua and CyberArk as sponsors, it was clear that there would be an emphasis on the topic of security in the “containerization” process and orchestration at the event. Sure enough, The State of Kubernetes Security was one of the morning’s keynotes, serving to introduce the rest of the conference.
Under the headline of Standardization, we were reminded of standard bodies like the CIS that publish security benchmarks and establish a number of safety rules, including those for Kubernetes. More practically, they introduced us to kube-bench, a tool offered by Aqua Security to help ensure that a Kubernetes setup meets these security benchmarks. They also covered breach examples (i.e., the known breach that happened at Tesla). The takeaway was that it was important not to forget your basics: limiting permissions using RBAC, updating your clusters, etc.
Down below, in the kernel itself, eBPF is rapidly emerging as the new network and observability standard of choice. It provides a generic language to hook and analyze any event in the kernel, and after five years of development, it seems mature enough to underpin the next generation of networking and security frameworks.
Falco uses it to detect misbehaving containers easily by hooking onto every kernel event of the container, and would probably be prohibitively slow without the in-kernel decisions that eBPF provides. On the network side, Cilium aims to implement a very efficient routing and firewalling layer for container platforms, again leveraging eBPF to tag, track, and filter packets in a very detailed way. Cilium’s capacities reach almost into the domain of service meshes, and it looks very promising to boost network performance and security in Kubernetes.
Standards make room for new standards
These past few years, Kubernetes has become the reference for container hosting, and several speakers at the conference noted how the offers for managed Kubernetes have multiplied, with most infrastructure providers having some kind of Kubernetes hosting. This de-facto standard allows richer components to abstract themselves from the underlying infrastructure (cloud vs. on-premises), and evolve faster by targeting a single API. Several talks looked at its extensibility.
For OPS people, the REST API standardizes the description of infrastructure resources (workloads, config, …) in a common format, making many platform-management tasks easier. Helm is emerging as the almost-standard package manager for Kubernetes and makes installing complex Kubernetes deployments easy and uniform. The package list covers many applications, like traditional monitoring tools, storage solutions, and even games! At a higher level, Spinnaker is a platform dedicated to executing Continuous Deployment pipelines that integrate Red/Black and Canary Deployments and directly target high-level cloud management APIs. For example, Pivotal showed the integration of Spinnaker to their managed Kubernetes offering, PKS. One can also list Jenkins X, a new variant of Jenkins fully dedicated to Kubernetes CI/CD.
Beyond the building blocks provided by Kube (pod, deployment, etc.) it is possible to add new primitives to describe your own abstractions. Some of them can also be managed by the Kubernetes API. This was what Bastien Cadiot demonstrated with Knative: this project used the extensibility of Kubernetes to provide three rich new abstractions. Knative Serving allows serverless hosting, similar to AWS Lambda. Knative Build can be used to launch event-triggered pipelines. The last part is Knative Eventing, that allows reacting to events. The joint use of these three elements allow you to react to a notification from your Git hosting (Eventing) and launch a pipeline (Build) whose steps will be executed by a function (Serving).
Many of the above are implemented using Kubernetes custom resources and the operator pattern, and many more exist. You can find a partial view of these reusable operators here.
One API to unite them all
Kubernetes, Kubernetes, Kubernetes… If everything in this article revolves around it, it’s because nearly every presentation at the Paris Container Day talked about it! To summarize, here’s what we got out of this day.
Having a common abstraction like Kubernetes frees editors and developers to focus on high-level features, like CI/CD or serverless offerings with a lot of the low-level work (high-availability, networking, scheduling, …) standardized.
Standardization doesn’t mean the platform has stopped evolving though. Security standards are still being refined, and eBPF promises a shift in the networking and security approaches that should push Kubernetes even further.
Cilium looks particularly promising on the network side: its promise of a blend between network and service mesh along with great performance are very exciting and we will keep a close watch on its evolution.
It was a great day overall, and we’re excited to see what the future of cloud-native orchestration will bring with the fast-paced evolution we’re seeing.