In April 2023, our engineers Maxime Durand and Eva Scapellato travelled to Amsterdam to attend the Kubecon Europe 2023, THE conference of the Cloud Native Computing Foundation (CNCF). Attracting over 7,000 developers, IT professionals, and industry leaders, it provides a platform to discuss the latest trends and innovations in cloud-native computing, with a particular focus on technologies like Kubernetes, Prometheus, and more. In this article, Maxime and Eva provide insights and experiences from the conference, covering key trends, the conference format, and highlighting some of the standout talks.
Tags: <kubernetes, cloud native>
The Big Trends
Several significant trends emerged within the cloud-native ecosystem.
The CNCF showcased projects across different categories (you can find a list of all the projects here), with a particular emphasis on the GitOps methodology and continuous delivery solutions. This year, Flux and Argo, two new projects, joined the Graduated category, indicating their stability and maturity for production use.
On top of that, eBPF-based technologies continued to grow and gain visibility. There was a good reason for the CNCF, in addition to hosting the ArgoCon as a prelude to KubeCon, to host the CiliumCon. Cilium is a cloud-native solution for providing, securing, and observing network connectivity between workloads based on eBPF.
Moreover, KubeCon Europe 2023 touched upon new themes, such as environment-friendly practices! It seems that the community is now realising the impact it has in terms of energy consumption, and it’s about time!
Finally, there were the usual themes: observability (with Grafana, Prometheus, Thanos, Jaeger, OpenTelemetry), with or without mesh service (Linkerd, Istio, Cilium) and a lot of talks around security.
What Is KubeCon Like?
That’s all well and good, but at the end of the day, what is KubeCon? How does it work on a day-to-day basis?
This year it was at the RAI Convention Centre in Amsterdam, and it’s enormous! Once you get your access badge (which you will have around your neck throughout the KubeCon), the day kicks off with keynote sessions in a vast concert hall-like setting. For about 1h30, we listened to talks about the latest statistics, news, project announcements, projects that change status (incubating, graduated etc.), and updates from Kubernetes and the biggest cloud contributors, including companies like Huawei, Mercedes, Apple, and Cisco.
The rest of the day is devoted to presentations in smaller settings. As the most important talks fill up quickly, you can attend them on your computer or attend other lectures unless you arrive early, sometimes even leaving the previous session before the end.
Afterwards, you get your lunch break and then another series of lectures until 6-7 pm, depending on the day. This amounts to 6 to 8 lectures per day.
Beyond the presentations, KubeCon featured a bustling hall with booths representing most cloud-native technology providers. It’s a great place to chat with them, forge connections and bring back socks and T-shirts 😉 The conference ended with an extended evening where you could continue to bond with the community and socialise over drinks. Exciting but exhausting!
Favourite Talks
It isn’t easy to list all the talks, clearly because dozens of them are already in the same slot, but also because it represents hundreds over several days. Here is the list of the talks. They are all available on YouTube on the CNFC channel.
So this year, we have chosen to group our favourite topics by important theme within the cloud-native landscape:
Resource Management in Kubernetes (By Maxime)
- “Making Sense of Your Vital Signals: The Future of Pod and Containers Monitoring” by David Porter, Google, and Peter Hunt, Red Hat
- “How to Blow up a Kubernetes Cluster” by Felix Hoffmann, iteratec
- Set the memory request/limit to the same values to avoid OOMKill. Memory is an incompressible resource. The only way for the cluster to recover the memory of a pod is to kill it. If the pod exceeds its limit value and another pod does not have enough memory (defined by its request value), kubelet will kill the pod that exceeds it. If you set both values equal, you guarantee these resources and won’t have any OOMKill.
- Always set a CPU request but do not set a limit. CPU is a compressible resource. Kubelet will assign the request value that the pod needs, but if the cluster has more resources, the pod will be able to benefit from all the available CPU resources. But what happens if another pod is created and/or needs the CPU resources? Well, no worries, kubelet will reduce the CPU usage of that pod to its request value, and it will work “normally” as long as you set your request value correctly. By doing this, you reduce the latency of your cluster considerably and therefore improve its performance.
- Clusters need room to operate. You can’t use 90-100% of your cluster. You need to leave some space for your cluster to work properly (to create and destroy pods, maintenance operations, jobs etc)
- Set CPU limits when you prefer consistent workloads over performant workloads
- Overcommit on memory when you want your workloads to be as cheap as possible and don’t care about OOMKill
- Best effort: without request/limit:
- Burstable: request < limit
- Guaranteed: request = limit
GitOps with ArgoCD (By Maxime)
- “Unlocking Argo CD’s Hidden Tools for Chaos Engineering – Featuring VCluster and More” by Dan Garfield and Brandon Phillips, Codefresh
- “Tips from the Trenches: GitOps at Adobe” by Larisa Andreea Danaila and Ionut-Maxim Margelatu, Adobe
Security (By Maxime)
Even if I have seen several talks on this subject, more or less interesting, I think this one is really worth seeing is the talk: Hacking and Defending Kubernetes Clusters: We’ll Do It LIVE!!! – Fabian Kammel & James Cleverley-Prance, ControlPlane.
This will show you by example (by hacking it actually), how to better secure a Kubernetes cluster. The things I noted to improve safety are:
- Restrict traffic via network segmentation (block node ports 30000-32767)
- Strong authentification (delete default password)
- Restrict API Server Access (MS-M9002)
- Restrict over permissive containers (MS-M9013)
- Principle of least privilege (MS-M9003)
- Pod Security Standards (MS-M9017)
- Disable via `automountServiceAccountToken = false` (MS-9025)
- Pin by hash (do not use latest or even version tags)
- Container signing
- Rotate short-lived secrets regularly
OpenTelemetry (By Eva)
OpenTelemetry is an open-source project that aims to standardise and simplify the instrumentation of applications for the collection of metrics. It offers a unified platform for observing distributed systems, such as containerised applications, microservices and cloud-based architectures.
OpenTelemetry is the second most widely used tool recognised by the CNCF after Kubernetes. So it’s worth knowing a little about it. For those unfamiliar with the technology, the presentation “OTel Me About Metrics” is for you.
You’ll find an introduction to metrics and the various tools provided by Open Telemetry so that you can start using them.
The most interesting part is the explanation of which tool is used in which case. You can find the summary in the table below:
- “Tutorial: Exploring the Power of OpenTelemetry on Kubernetes” – Pavol Loffay, Benedikt Bongartz & Yuri Oliveira Sa, Red Hat; Severin Neumann, Cisco; Kristina Pathak, LightStep
- “Connected Observability Pipelines in the OpenTelemetry Collector” – Dan Jaglowski, observIQ
- Using OpenTelemetry for Application Security, with a Real Life Example – Ron Vider, Oxeye