Second KubeCon for me... and second KubeCon as a local. After Valencia (where I am from), KubeCon came to the city I've been calling home for the last four years. Being a local at KubeCon is great, you always have a conversation topic, and you can recommend places and foods you love to the people you meet or already know. For me, this KubeCon EU 2023 was a total of 6 days of conferences, networking, and a lot of learning.
While KubeCon itself started on the Wednesday, I also joined the co-located events on Tuesday, as well as Rejekts on Sunday and Monday. Last year I went to Valencia together with 2 more colleagues from ITQ, but this year I was happy to be joined by another 11 ITQers. Platform engineers, sales, and even management! Kubernetes is certainly a growing topic in ITQ.
Cloud_Native Rejekts
For the people who got to Amsterdam a few days before KubeCon, and for the impatient locals like me, you could attend Cloud_Native Rejekts on the Sunday and Monday before KubeCon. Rejekts is, as they describe, "the b-side conference giving a second chance to the many wonderful, but rejected, talks leading into KubeCon + CloudNativeCon ".
But of course, as Rejekts is growing in popularity, they have had to also reject over 100 talks for this edition of the conference, so there were some jokes about rejected from Rejekts. Although with a slightly smaller audience, the format was similar to the last Kubernetes Community Days in Amsterdam (read my take on it here). Two main rooms for talks, and a small area for networking (with Suse as only sponsor booth) At the end, it was 2 days full of talks, with some networking time, and a great way of warming up the engines ahead of KubeCon.
I really enjoyed Rejekts and I will surely be joining again next year.
ArgoCon
Last year I joined GitOpsCon in Valencia, ArgoCD was the star of the day. With GitOpsCon having moved to Open Source Summit, the Argo community has gotten together and organized ArgoCon, as a co-located event to KubeCon.
A combination of 30 min talks with 5 min lighting talks, made my morning very enjoyable, learning more about ArgoCD, and Argo Workflows, which I use daily. As my colleague @thefluffysysop pointed, ArgoCon was probably the most popular co-located event to KubeCon.
GKE Partner Roundtable
Although I was really enjoying ArgoCon, my colleague @codeviellard and me joined the Google Kubernetes Engine partner's round table at Google's office in Amsterdam Zuid. We took part of an interesting workshop/session by Daniel Marzani, Strategic Cloud Engineer at Google cloud, where we looked at current challenges some GKE clients are facing and diverse ways to approach them.
Live interviews:
I also recorded some live interviews with some interesting people from the Cloud Native community, check them out in my previous post.
Some thoughts / Lessons learnt:
Now I will go a bit deeper into some topics / lessons learnt during the KubeCon week. I will also include some of the products that address these points, and which I will be looking into during the coming months.
Building and securing software supply chains
As complexity in getting code from the developer's laptop into the production environment grows, so does the cognitive load on the developers and the probability of shipping vulnerable software. In Rejekts I attended two different talks on Software Supply Chains, one on building them(Thomas Vitale, watch here), and another one on securing them (Abdel Sghiouar, watch here).
I will start with the security aspect. Dependencies which have dependencies which have more dependencies, is a non stop chain. Abdel mentioned some of the important aspects when it comes to software supply chain security, such as generating metadata on how the software is built (SBOM), automated build pipelines with container image signing (with Sigstore), and working with the SLSA framework during the design phase of the supply chains.
This is a task that has to be enforced by the platform team, but developers have to become more and more aware about what they can do on their side to secure their code. But by the way, in the topic of software supply chains, how do you actually build one? I have to come back to VMware's open source project, Cartographer.
Cartographer
Cartographer is the choreographer with which you can chain different processes and create a modular software supply chain. Think about CI/CD and GitOps (continuous testing, container image building + app configuration and deployment, through git), security (image scanning, SBOM generation), and any other custom actions you might need, like registering certain assets in a CMDB, integration of notification systems etc... Cartographer will basically allow you to integrate all these steps into one, cohesive, software supply chain.
Service Mesh is going "mainstream"
Well, mainstream might be a heavy word, but its usage is increasingly growing, and the main projects around it (Istio, Linkerd, Cilium) are growing at incredible speeds. While I have not worked with service mesh myself that much, it is something which I am increasingly more interested in. Multi-cluster deployments, blue-green, canary... These are all benefited or enabled by service mesh implementations.
I am also quite attracted by the idea of incorporating external services (running on VMs, for example) into the cluster mesh, together with all the other Kubernetes-native resources and CRDs.
Cilium Service Mesh
While I am a bit hesitant of the side-car proxy model, because of their resource usage (mostly), Cilium makes use of eBPF for all pod-to-pod communication. As someone who has never gone as low-level as looking into the Linux Kernel, or writing code with C and C++, any talk I had ever seen on Cilium felt like a different language to me. Intimidating, could be the word. Fortunately, it was different this time; and I have to thank Liz Rice (author of the "Learning eBPF" book) for her fantastic talk at KubeCon (watch here). After a whole week of conference, I joined Liz's talk, which was the very last KubeCon talk, on keeping Cilium simple.
For multi-cluster deployments, exposing one service to another cluster through the mesh is as easy as adding an annotation, turning the service into a "global" service. With cilium external endpoints, you can also add services running on VMs to the mesh. You can view all endpoints in the mesh using the cilium CLI inside of your cpod (cilium pod).
I personally have already started to look into Cilium service mesh, which I will be deploying in my lab soon (potential blog post coming there)
Meet your developers at the right level of abstraction
Kubernetes is hard, and developers want to (rightfully) focus on building and improving their application, and not learning how all this "Cloud Native Middleware" works and fits in within the larger picture of (Enterprise) IT. This could be challenging, because not every organization has the people and/or time to build and maintain an array of custom-built Kubernetes controllers.
In his talk about fighting k8s misconfiguration (together with Whitney Lee, watch here) Viktor Farcic made a good point by using an example of creating Validating Admission Policies. When it comes to creating Validating Admission Policies, you will have to apply them to every individual resource type, on each API group. This will be a cumbersome activity when building your platform. Kubernetes is a "platform to build platforms", so, why would you be exposing your users to the lowest level of abstraction there is? Why not create your own Custom Resource Definition for your applications and let the developers interact with those CRDs, instead of interacting directly with low-level kubernetes resources?
What you could do is logically group your resources and create a higher level of abstraction, to which you can apply policies and RBAC to. It saves you time as platform operator, and it saves your developers time, since they can work at that higher level of abstraction. That's where Crossplane comes in.
Crossplane
With Crossplane, you can create control planes! (Do not confuse with Controlplane, the Kubernetes security solution). If you like IaaC and continuous reconciliation (or GitOps), you're in for a treat with Crossplane. Create your own CRDs and API groups without having to write your own Kubernetes controllers. If know Terraform, you could think of it as building a Terraform module, in which you abstract the diverse objects and just ask the user to input some parameters, which the user sees in association with the higher abstraction, and not with every object which needs to be created. For example, why ask the developer to create a pod + service to expose the UI, when they could create an "app", in which they input the image, the command to run and the port to serve the UI in.
Another cool thing in Crossplane is that it also extends to manage resources which are external to Kubernetes clusters (once again, like Cilium, integration with non Kubernetes resources is growing). If it has an API exposed through some kind of endpoint, its resources could easily be managed by Crossplane.
You can learn more about Crossplane by watching this KubeCon presentation on Crossplane intro + deep dive.
Close up
KubeCon EU 2023 was once again a great event. Knowledge sharing, networking, and lots of people excited about technology. None of this would be possible without an incredibly dedicated community
Internal Developer Platforms are on everyone's mind, from designing, to building, monitoring, and operating them. And it's not even solely about your Kubernetes resources anymore, we have seen how Crossplane can be used to manage external resources, as well as Cilium service mesh, which can add any kind of endpoint to the mesh.
KubeCon EU 2024 in Paris
Although I have enjoyed being a local at KubeCon for the 2 years, I am very excited to be a tourist next year in Paris.
