Published at 28.06.2022
After a while, with most online streams and virtual meetings, KubeCon and DoK Day EU were back to in-person events in Valencia, Spain.
The beautiful Spanish coastal city received people from all over the world to talk about Kubernetes and celebrate its community.
Some of our team members were there in person and shared some of the highlights of both events.
Table of Contents
Paul Eichler, one of our youngest Platform Engineers, not only took part in a big adventure riding motorcycles from Saarbrücken to Valencia on the “longest trip” he ever did, alongside our CEO, Julian Fischer.
He was also the key contributor to the research that led to the talk entitled “Operator Lifecycle Management” delivered by Julian at DoK Day EU 2022.
Matteo Olivi, one of our Platform Engineers and contributor of articles on the subject of K8s to The New Stack, sees KubeCon as a great way to evaluate where the community is headed, as well as check out future trends for K8s and other Cloud Native Computing Foundation (CNCF) projects.
Better yet is to get scoops from the maintainers and contributors themselves. Creating a direct dialogue between these maintainers and the users. Sharing experiences and feedback that might influence new features and improvements.
KubeCon provided an excellent opportunity to connect with the K8s community and participate in exciting discussions.
From very complex technical topics to high-level architectural considerations and insights into how companies utilize Kubernetes, the panels and talks brought some points worthy of further study. Here are the highlights according to our team.
Many organizations must provide Kubernetes to large numbers of internal (e.g., app dev teams) or external users (e.g., paying customers) while ensuring that the users’ workloads do not interfere with each other.
Roughly speaking, there are two main conflicting approaches; to have a small number of large clusters with multiple tenants on them vs. having many small clusters and giving each tenant dedicated clusters.
Our impression from this KubeCon EU is that the latter approach is becoming more popular than the former.
In our opinion, this might be due to several reasons, such as the current lack of reasonable multi-tenancy solutions on Kubernetes, the complexity of managing large clusters, and the need for flexibility (which is easier to satisfy with many independent clusters). Also, limitations to the scalability of Kubernetes play a role here.
But going with many small clusters also introduces challenges since there are no established solutions to manage a large number of clusters while striking a suitable trade-off between consistency and flexibility.
Numerous organizations’ Kubernetes clusters consistently lag behind the most recent Kubernetes release by more than the “physiological amount”.
This is a direct consequence of the fact that updating Kubernetes is hard. And although an incredible amount of work has been put into making this more accessible, much more is needed.
As Kubernetes gets updated in the cluster, all the applications that run on top of it might need to be adjusted to work correctly or take advantage of the newest features and security improvements.
Most work so far focused on the first problem – updating Kubernetes itself – but not on updating the apps that run on Kubernetes accordingly. Here we again touch on the topic of the talk by Julian Fischer.
A great panel that touched on both the topics above, amongst others, was “K8s After the Honeymoon: It’s Complicated” by Saad Malik, chief technology officer and co-founder of Spectro Cloud; Bailey Hayes, principal software engineer at SingleStore; and Fabrizio Pandini, a staff engineer at VMware.
K8s After the Honeymoon: It’s Complicated
Since its early days, it’s been possible to extend Kubernetes via custom controllers and operators. This allows building a control plane based on the same design pattern of Kubernetes itself – a declarative API and set of control loops that drive the state of the cluster towards the users’ desired state encoded in the declarative API – but that manages resources Kubernetes cannot natively manage and that you define (e.g., databases, virtual machines, software-defined networks, etc.).
While this is not new, the number of companies writing custom controllers/operators to manage their resources seems staggeringly high and keeps growing.
Please accept YouTube cookies to play this video. By accepting you will be accessing content from YouTube, a service provided by an external third party.
If you accept this notice, your choice will be saved and the page will refresh.
Accept YouTube Content
Design Patterns For Extensible Controllers
Security has been a major topic in the cloud-native community. At this KubeCon EU, the focus was on software supply chain security.
In these talks, particularly relevant topics to the talk given at DoK Day were discussed.
Most notable is that Helm currently has no plans to change the way they support CustomResourceDefinitions (CRDs) in the near future (you can learn more about them and why this is a restriction in the talk of Julian Fischer), the Operator Lifecycle Manager (OLM) will receive some major changes with OLM 2.0 and the introduction of rucksacks to the operator framework. Also interesting to note is that the OLM might soon become a CNCF project, hopefully leading to even more interest in the project.
Kubernetes is organized in a set of Special Interest Groups (SIGs). Each SIG owns different subproblems and portions of the codebase. For example, SIG Performance oversees all the changes and discussions that impact performance, SIG Release is in charge of the release process of the project, etc.
At KubeCon, most SIGs get a dedicated talk where they summarize the work that’s been recently done, what’s in progress, and what’s next. At every SIG meeting we attended, the SIG members called for more contributors and highlighted how the current maintainers and contributors are barely enough to keep up with all the work.
For the example of a SIG meeting, see SIG Architectures.
Additionally, there are the communities around open source Kubernetes extensions, like TAG Observability, also looking for helping hands on their task to provide guidance on how to make Kubernetes more observable through different open source tools.
DoK Day not only fed the attendees’ minds with great talks and topics. It also offered a warm welcome that reflects the nature of the Kubernetes community in general.
To be part of live events again is so refreshing and makes us all excited to participate and create more dialogue that helps further the communities growth and influence the future of cloud-native technology as a whole.
KubeCon didn’t disappoint when it came to identifying the path the Kubernetes community is heading to. The question is how to keep this exponential growth when the number of contributors, creators, and maintainers may not keep up.