Kubernetes is not just for Black Friday

Bart Farrell: Is Kubernetes really only for enterprise scale, or does it make sense for individuals in small setups too? Today on KubeFM, we're joined by Thibault, or Thib, who's Director of Program Development at The Matrix.org Foundation. This episode looks at Kubernetes from a non-traditional angle, self-hosting, home labs, and learning by doing. Not because it's fashionable, but because it solves real problems around reliability, upgrades, and recoverability. Thibault walks through his journey from Docker Compose and Podman, managed with Ansible, to running Kubernetes with k3s. explaining where declarative systems help, where imperative tooling fell short, and why peer-reviewed, community-maintained solutions mattered for a solo operator. We talk about GitOps, Helm charts, discoverability, and why Kubernetes can actually reduce risk for people who don't run production services for a living, but still care deeply about their data. This is a practical conversation about Kubernetes beyond Black Friday scale, and why it can be a reasonable choice even on modest hardware. This episode of KubeFM is sponsored by LearnKube. Since 2017, LearnKube has helped Kubernetes engineers from all over the world level up through Kubernetes courses. Courses are instructor-led and are 60% practical, 40% theoretical. Students have access to course materials for the rest of their lives. They are given in-person and online to groups as well as individuals. For more information about how you can level up, go to learnkube.com. Now, let's get into the episode with Thib. So, welcome to KubeFM. To get started, what three emerging Kubernetes tools are you keeping an eye on?

Thibault Martin: Actually, none. Everything is an emerging tool for me because I would qualify myself as a newcomer in the Kubernetes world. There are plenty of funny toys I would like to play with, and everything is new for me.

Bart Farrell: That's exciting. It means there's a lot of freshness to what we'll be talking about. In terms of an introduction to you, Thibault, who are you, what do you do, and where do you work?

Thibault Martin: Yep. So my name is Thib. I'm working for The Matrix.org Foundation. People might know the Matrix protocol. So the foundation behind it is The Matrix.org Foundation. I'm doing a lot of things there. I think my official title is Director of Program Development or something like that. In practice, it means I organize the conference, our presence at FOSDEM. I'm talking to developers to make sure that we have a pleasant protocol to work with and that people are kept posted about all the updates. So Mr. Everything at the foundation.

Bart Farrell: Just like I said, it sounds like a lot of work. And this is a terrible joke, but it's the first time that I've met someone who's working in the Matrix or for the Matrix. But more importantly, we'll forget that terrible joke. For people that don't know what FOSDEM is, can you explain what FOSDEM is, when it is? Because I think a lot of people in our audience should definitely know about it.

Thibault Martin: FOSDEM is the biggest open source conference in Europe. It happens every year in Brussels. Usually it's the first weekend between January and February. So usually first weekend of February. This year, it's on January 31st and February 1st.

Bart Farrell: Thib, how did you get into Cloud Native?

Thibault Martin: I don't know if I'm into Cloud Native. Actually, I might be more into Cloud Native than I think. I do have a Kubernetes cluster at home, and I am running what some people call a Cloud Native operating system on my personal laptop because I'm running Universal Blue. But anyway, so I got into it because I wanted to self-host things. This is not my job. I don't run services for a living, but I wanted to make sure that my data was somewhere where I could know where it is and not just leaking everywhere. So I started self-hosting things. And one thing leading to another, I complexified or simplified my setup and got into Kubernetes.

Bart Farrell: The Kubernetes ecosystem moves very quickly. In your experience, what resources have been most helpful? Is it blogs, podcasts? What's worked best for you?

Thibault Martin: People. So the good thing for me is that I'm working with a team of people who are much smarter than I am and they keep an eye on everything. In particular, I have a colleague who always tries to sell me new toys. Fortunately for me, most of them are open source, so it's not expensive. It's only expensive in terms of time, but not in terms of budget. And so mostly talking to people who know what they are doing and who are keenly interested in Kubernetes.

Bart Farrell: And if you had to go back in time and give your younger self one piece of career advice, what would it be?

Thibault Martin: Write a blog, open a blog and write things down. For me, it's been really career changing, I would say. The first thing is if you face a problem, you're probably not the only one to face a problem. If you find a solution and you write about it on your blog, then people will know that you have the solution. So you are going to share the knowledge. People will start to see that you can actually solve problems, which is a useful skill, especially on a tight market. And yes, for yourself as well, document things. When you are in a company, in most companies, you have a handbook to know how things are done and how you can do them if you are new to that. And I tend to forget how I do things. So it's useful for me to have a handbook that I can refer to later.

Bart Farrell: Sound advice. Now, the next questions that we're going to be looking at are from an article that you wrote titled Kubernetes is not just for Black Friday. So we want to look at this a bit more in detail. Many developers out there assume that Kubernetes is overkill for personal projects or home labs, reserving it for enterprise-scale applications. What was your initial perception of Kubernetes, and what made you reconsider?

Thibault Martin: So to me, Kubernetes, I was like many people who got into self-hosting. I started with a simple Docker compose, and Kubernetes looked like a very complex beast. And I still think it's complex, but not as much as I used to think. And so to me, it was very scary. It was all about you need to have three servers to have high availability, and it's discouraged in the official doc to only have a single one that will do both all the scheduling plus all the hosting. And I was like, wow, this is too complicated for me. I don't need to have that. Then I realized that Kubernetes would allow me to solve my two main problems, my own incompetence, because I'm not a SRE. My job is not to run services online. So I'm going to make mistakes. And the other one is hardware failure, because I am hosting my Kubernetes cluster on a server in my living room, and it can fail. It can get toast. And so Kubernetes is helping me on those two fronts.

Bart Farrell: Now, before Kubernetes, you were using Podman containers orchestrated with Ansible playbooks. Can you walk us through that architecture and why it seemed like a good approach at the time?

Thibault Martin: Like most people, I started with Docker Compose, and then I wanted to have something more integrated in my server. In particular, I wanted to have systemd units, because I wanted to be able to control my services with a systemctl restart, etc. Or I wanted my services to restart at boot, or I wanted to control my services, my containers like normal services. And this is something that Podman does out of the box. So I deployed Podman containers on my VPS, and then I generated systemd unit from the Podman containers, from the Podman pods, and everything went well. But then I realized, well, actually, one of my threats is that my server could fail. So I need something that I can replicate elsewhere. And Ansible is good for that, because basically you describe in an Ansible playbook what you want to get done. and Ansible is going to do all the heavy lifting in theory for you where it's going to do everything behind, not really behind your back, but behind the scenes, to achieve the desired state that you wrote in the playbook. And so that seemed like a good approach for my threats.

Bart Farrell: Ansible is known for its declarative approach. You describe the desired state and Ansible ensures it. However, you found this wasn't quite true in practice with the Podman collection, what limitations did you encounter?

Thibault Martin: Well, this is mostly true for Ansible in general, but for the Podman collection, it's not really that true. So first of all, I want to thank the person behind that collection, because it saved me a lot of time. And even if it doesn't fit my use case today, it's a nice collection to have. So thanks to the maintainers for maintaining it. The limitations I've hit, though, is that it's not really that Ansible native. I don't know if that makes sense. You don't really write the state you want with that. Podman collection, but you have to take a more sequential approach where first you create a pod and then you add a container and then you generate the systemd services. You can't just say I want this pod with these containers in it with this systemd service. For example, if I wanted to deploy Synapse, which is the Matrix server, I had a very long list of tasks to do and it's very brittle. I wasn't really doing what you are supposed to do with Ansible, which is describe the state you want. I was still writing the step-by-step procedure on how to get there.

Bart Farrell: You mentioned that your Ansible roles weren't peer-reviewed and were specific to your needs. Why is the lack of peer review particularly concerning for a solo self-hoster?

Thibault Martin: Well, I'm a team of one, so it's only me. I'm on my own. If I make a mistake, nobody is going to catch it. And I know I'm going to make mistakes, because it's not my job, and even if it were my job, everybody makes mistakes, we're all human after all. So I wanted to get something more standardized and battle-tested than my own brittle Ansible playbooks that I was writing in my own corner. This is mostly because self-hosting is fun. I wrote another post that is, I don't want to self-host services, but I do. Because actually, I would like if I didn't have to maintain my own services, but I sort of need, because I don't really always trust... the providers, especially with my sensitive data. So I'm a team of one and I don't have the time to do all that. For example, if I'm going to leave on holiday, I'm not necessarily going to bring my laptop with me all the time and I might need to access a file on my Nextcloud. And if my server is down because I made a mistake, it's going to be painful.

Bart Farrell: Upgrades and service discoverability were two other pain points with your previous setup. Can you elaborate on the challenges you faced in these areas?

Thibault Martin: So I might have been doing things wrong, but as soon as you start introducing dependency between containers, it starts to be painful because if you want to change things, so I thought I was a real genius because I had a value somewhere, an Ansible var, where I would just update the tag of the container and then I would run the Ansible playbook again and it would just update the container. That works well, but as soon as you start having containers that depend on one another, it's much more brittle. Sometimes you have to log in manually into the server and first kill the containers, remove them so you can remove the one they depend on, etc. So updates and rollbacks are a bit rocky. It takes a lot of manual work, which is everything I wanted to avoid. And the second one is discoverability. I was genuinely amazed when I deployed Traefik. I just... added a few labels to my containers and then Traefik, which i didn't configure anything for suddenly it knew where to route the traffic to the right containers what certificates to retrieve and i was amazed by that so i wanted that sort of thing but for everything for example for monitoring i wanted i want to have monitoring so i want to have a Prometheus to scrape the logs of my containers. And I didn't really have that sort of discoverability with my brittle Podman setup.

Bart Farrell: You described what you really needed, a tool that lets you say, deploy version X of Keycloak and handles everything else automatically. How does Kubernetes fulfill this requirement?

Thibault Martin: Basically with manifests, I would say Kubernetes is doing what Ansible was supposed to do, but at a different scale. I basically describe what I want and Kubernetes is going to do its magic to deploy the service I asked it to. It's going to check, does that pod exist? Does that container exist? No, then I'm going to create it. And it's basically going to deploy the services for me. So I can deploy new changes, I can roll back automatically without having to log in, kill containers, remove them, etc. For example, if you take an nginx deployment, it's like a few lines. It's very, very simple to say, I want to have an Nginx container running on my Kubernetes cluster. In a few lines, you have it done.

Bart Farrell: You rely heavily on community-maintained Helm charts from Artifact Hub rather than writing your own manifests. Some might argue this trades one form of complexity for another. Now you're dependent on external maintainers and their opinions. How do you balance leveraging community charts while maintaining control over your deployments?

Thibault Martin: It's free work. It's in the wild. Experts have wrote it. People whose job it is have written it. And you just need to try to understand what they did. You don't need to trust them blindly. But it's something that was peer-reviewed. So usually, well, not everything is going to be peer-reviewed. But as soon as something is quite popular, more people are going to chime in and say, oh, maybe you can do it differently. And this is exactly what I'm looking for. I want to have the same foundation to build from, and so I'm going to read the Helm charts, try to understand them, and try to make sure that they are not doing things I don't want them to do. It's really open source in its purest form, in the sense that everything is meant for collaboration. You have people peer reviewing each other, catching each other's mistakes, improving the charts, etc. So, for example, I can deploy a Keycloak or Authentik or any other SSO by just upgrading, updating a few values. I just have a values.yaml file where I'm going to say those are the things specific to my deployment. Everything else can be pretty standardized. So yeah, you need to understand what the chart is doing and you need to understand what you want, which is pretty important as well. So you can customize the chart to your needs.

Bart Farrell: You mentioned using Flux for GitOps rather than running Helm commands from your laptop. Can you explain this workflow and its benefits?

Thibault Martin: Actually, I lied. I used to use Flux because I started with Raspberry Pi. The first device I deployed a Kubernetes cluster on was a Raspberry Pi 4, so I wanted something with a very low memory footprint, and I deployed Flux. And because I have a team of people who like to nerd-snipe me with new toys, nowadays I'm using Argo CD. The principle is the same. It's basically the GitOps approach. And it answers my need for what if the hardware fails. For example, let's say my server is in my living room. and my laptop is in my office. The both of them are in my home. If I go, I don't know, to the cinema or somewhere and there's a burglary and people leave with my server and my laptop. I don't have anything anymore to redeploy in my cluster in its previous state. Like I don't know, I can't replay the commands. There is no history anywhere. So GitOps to me is solving that problem in the sense that instead of just applying the manifest directly to the Kubernetes cluster, I have a Git repository where I store all the desired state for my cluster. And then the cluster, through Flux CD or through Argo CD, is going to pull that Git repository and it's going to deploy the manifest in my name, I would say. It's going to deploy the manifest for me. So it's really, to me, liberating because I know there is a place somewhere else, not in my infrastructure, that has a good idea of... what should be my infrastructure. One of the main advantages is that I have version control, so it's very easy to track what I did, when, and to roll back the changes by just reverting a commit, basically. So I'm going to get back to that later, but I have many posts I want to write on my blog, but someday, hopefully in early 2026, I will talk about that on my blog.

Bart Farrell: Okay, we have something to look forward to, and perhaps a future episode to record about that, so that sounds good. A common objection to Kubernetes is the complexity of cluster setup, choosing network plugins, storage providers, and other components. How did you address this barrier to entry?

Thibault Martin: That was my barrier to entry as well. As I said earlier, Kubernetes is complex. It's not something super simple. You have all those plugins that do a lot of things, and you never know what you need to know or what you don't know to make the right choice. So to me, the best way to address that was to have an opinionated distribution that kept things as simple as possible. I wanted something that allowed me to say, I want a Kubernetes cluster on this single server. And to me, that was k3s. So it's an opinionated bundle and it's pre-selecting all the plugins. I still don't know what a CNI plugin is, for example, because again, it's not my job. And that allowed me to get basically full control of Kubernetes on a server. It allowed me to deploy it on a server and not rely on a cloud provider where you don't know how much you are going to get billed for whatever container is running on your cluster.

Bart Farrell: Something else that came up here is that k3s markets itself with a simple one-liner installation. Was it really that straightforward in practice?

Thibault Martin: Yes. So that's how I started. I started on a Raspberry Pi 4, so it was very easy for me to deploy things, and I just had to wipe the SD card to start again. So that's how I started with the one-liner. And then I realized that it was a journey with a lot of realization. I realized that I could automate that, and even better, I could automate all the pre-flights check. For example, make sure that the firewall allows me to... do what I need, it's not going to block all the requests and the good thing is that the people who maintain k3s they also maintain an Ansible playbook that does all of that for you. So it's going to do all the checks on the target machine to make sure that it's ready to welcome k3s. It's going to deploy k3s on it and then it's going to copy on your client everything you need to actually connect using kubectl. to the Kubernetes cluster.

Bart Farrell: You praised the discoverability features in Kubernetes, particularly around certificates and metrics. How does this compare to your previous Traefik-based setup?

Thibault Martin: So at first it was a bit unsettling to me because I was very used to Traefik where you just add a label to the containers themselves and then through the magic of the Docker sockets, Traefik would be able to read those labels and do all this magic behind its back. And when I started using Kubernetes, I wanted to do the same thing. And one person in the chat we have with all the infrastructure enthusiasts told me, no, no, no, you need to use cert-manager. And I was like, why would I use cert-manager? Because I have Traefik that can just do that for me. And that's where I got the epiphany when he talked to me about that. He told me, yes, but in the Kubernetes world, you're not always going to have a single node. You have a very specific setup where you have a single node. So Traefik could do that for you in theory, even if it would be a bit dirty. But what you do in Kubernetes is you have operators that can listen to specific custom resources, well, that can monitor specific custom resources, and then do all the heavy lifting for you. And that's where I understood that communities was really the thing I wanted, because I could deploy services, and then I could deploy Prometheus. And it would basically work by itself without me having much to do.

Bart Farrell: For developers considering this transition, what does the learning curve look like? is prior Kubernetes experience absolutely necessary or maybe not?

Thibault Martin: I wouldn't say. Because of k3s and all the tooling we have around, the most difficult thing I would say in the Kubernetes world is to pick your tools. So k3s is lowering the barrier to entry and with a simple Raspberry Pi 4, you can just experiment in your own corner. And other than that, it's just moving and shuffling YAML files around. gives you a very safe playground to experiment. It's not very difficult to understand what the YAML files do. I would say there is a slightly steeper learning curve in the sense that you need to know how containers work and how containerized applications work before you can start deploying them on Kubernetes. But apart from that, I would say nowadays you have a lot of learning resources online. So just pick a few tools, stick to them for a few weeks, and try to make things that work. And then you can start playing with new tools.

Bart Farrell: There's a common concern about resource overhead when running Kubernetes, especially on modest hardware. What's been your experience with k3s on resource consumption?

Thibault Martin: To me, it's been very lightweight. It's something I was a bit concerned about because it's a complex setup to have Kubernetes. There's no way this is going to run on the Raspberry Pi. And nowadays, I'm not using a Raspberry Pi. But it's not because Kubernetes is resource hungry. The overhead was very limited. Actually, the reason why I moved away from a Raspberry Pi is because the Raspberry Pi is notoriously bad at encryption algorithms, especially AES. And I really wanted to have an encrypted disk. on my Raspberry Pi in case there was a burglary at home and my disk was stolen. I didn't want my data to leak everywhere. And that gave me terrible performance on the Raspberry Pi. But this is not related to Kubernetes at all.

Bart Farrell: Sounds like a burglary is a significant source of concern in your case.

Thibault Martin: Yeah, it is.

Bart Farrell: Okay, good. Well, I'm glad you're a step ahead in terms of threat detection and risk prevention there. You emphasize the importance of relying on standardized, peer-reviewed solutions. At the same time, isn't there a risk in deploying Helm charts you don't fully understand?

Thibault Martin: Yeah, definitely. There is always a risk in playing things you don't understand. It would be completely reckless to just say, oh, this chart looks fancy and it seems to be deploying the right service for me, so I'm just going to deploy it. The chance, the luck we have with open source is that we can have a look at... what it's going to do ahead of time. So the chart is a solid foundation to do your own thing and to customize them through the values, but you still need to have a good idea of what they are going to do. Where it really shines is that you don't have to write every single chart yourself because there is a vibrant community of experts and enthusiasts writing charts for almost everything.

Bart Farrell: If someone is currently running a Docker Compose or Podman-based home lab and considering Kubernetes, what would be your advice for getting started?

Thibault Martin: Definitely install k3s. This is what got me started because you can get a low risk setup to get started and experiment. You can safely experiment. It's not going to cost you a lot. Your electricity bill should not change a lot just by running k3s. And explore artifacthub.io where you can see all the charts that exist for the various services you could be interested in. And I would say be open-minded. to embrace the change for declarative deployments where you really say, you don't say, this is how I want things to be deployed, but this is what I want to be deployed. Kubernetes is going to do all the heavy lifting for you. So you just have to browse the docs. Thanks, by the way, to all the developers and documentation writers who put them together because they are really excellent.

Bart Farrell: I'm sure they'll appreciate the shout out because there's a lot of behind the scenes work that goes into that. And sometimes it's underappreciated. Thib, to wrap up, what's the key message you want listeners to take away about Kubernetes and self-hosting?

Thibault Martin: For me, it would be open minded. Don't get the prejudice that it's just for enterprise scale and you can just get started with a small setup and go ahead. I do have a Kubernetes setup and I'm still not doing. Black Friday sales.

Bart Farrell: And you mentioned some blogs you're thinking about doing for next year, as well as being very involved in FOSDEM. But what's next for you? Is there anything else we should keep in mind?

Thibault Martin: I'm very interested in many things. I like to get different views on things. And these days I'm exploring, in addition to Kubernetes, I'm exploring what I call causal computing. Basically, what if you can do without services? What if you can get... everything on your own computer, like we did in the 90s, for example. So I am exploring that these days. And hopefully, sometimes next year, I will be able to have a sort of a wrap up of all the trade-offs you have to make if you want to follow that route and why it still makes sense to have your own services.

Bart Farrell: And if people want to get in touch with you, what's the best way to do that?

Thibault Martin: The best way to do that is to go to my website, to ergaster.org. So E-R-G- A-S-T-E-R.org. And there is an about page with all the ways you can contact me.

Bart Farrell: Fantastic. Thanks so much for joining us. I hope our paths cross again in the future with another blog post you're writing. And I really do recommend for folks out there, if you haven't been to FOSDEM, please check it out. It's an event that everyone seems to speak about very, very highly. Thanks a lot, Thib. Have a good one.

Thibault Martin: Thanks.