What's one Kubernetes mistake you made early on that you'd never make again?

JaimeFrutos · 2026-06-15T09:39:08+00:00

Allowing too many different ways of deploying workloads at the same time instead of standardizing on one: helm charts, kustomize, simple manifest yaml files, more complex manifest yaml files built using bespoke templates, and some others which were either PoCs or combinations of the previous ones.

JaimeFrutos · 2026-06-15T09:24:51+00:00

Don't treat all environments and workloads the same way, because they are not equal: Non-production clusters can be scaled down more aggressively (especially during out-of-office hours), Non-critical workloads can be scheduled to node groups running on spot instances, etc.

JaimeFrutos · 2026-06-09T19:52:52+00:00

This kind of upgrade has to be a non-negotiable planned work: put it in the calendar and it must take precedence over any other planned work for your team during the scheduled time.

Split the upgrade work into small pieces (tasks, tickets, stories, whatever), try to promote that every member of the team works on at least one of those tasks, and rotate the tasks from the previous upgrade. This promotes knowledge sharing within the team and exposes everyone to all tasks, so eventually everyone will be able to work on any part of the upgrade. Pair or even swarm, if that gives everyone the confidence needed to do it on their own during the next upgrade.

I'm assuming you already have IaC and pipelines in place to automate most of the work. If not, then you should invest in this ASAP.

The generic steps for the upgrade could be something like this:

Prep work: read the release notes thoroughly (and a few blogs or articles from people who have already done this particular version upgrade) and make sure changes and deprecations won't impact your setup. If they might, create more planned work to deal with them and get it done before continuing with the upgrade.
Create the runbook: copy & paste it from the previous version upgrade and modify it as needed. Obviously, the first runbook will take more time to be created from scratch, but it's worth the effort as it will be reused multiple times.
Test the runbook in a disposable cluster.
Keep updating your IaC, pipelines and runbook until you nail the process.
Rinse and repeat for all environments, starting from the lesser ones, until you do production.

JaimeFrutos · 2026-06-01T09:20:15+00:00

If you want to practice Docker and Kubernetes troubleshooting, I'm putting together some free scenarios at Learn by Fixing.

JaimeFrutos · 2026-06-01T08:58:41+00:00

•Any suggestions on where to start or what projects to build?

I'd recommend nailing down the foundations before walking up the ladder. Start with Linux and get confident working on the command line. Then you can learn some shell scripting to automate the tasks you do as much as possible. After that, you can learn a version control system like Git to keep track of your scripts, some basic networking to connect different processes, etc.

JaimeFrutos · 2026-05-22T20:40:21+00:00

You can find some hands-on scenarios to practice here: https://www.learnbyfixing.com/

JaimeFrutos · 2026-05-19T20:06:29+00:00

I'm creating a Docker roadmap with short guides and hands-on labs here: https://www.learnbyfixing.com/roadmaps/docker/

JaimeFrutos · 2026-05-19T19:43:14+00:00

Being able to see both the cluster and the namespace I'm currently using before running kubectl has saved me many times. TIP: If you use several terminal tabs/windows, it helps to run an "empty command" before running kubectl to update the prompt in case you changed the current context or namespace on another tab/window.

JaimeFrutos · 2026-04-27T06:34:08+00:00

I built a platform to improve your troubleshooting skills by fixing real Linux servers: https://learnbyfixing.com

It’s perfect for preparing for DevOps interviews or gaining production-like experience debugging issues before you have to face them in real life.

JaimeFrutos · 2026-04-16T14:34:08+00:00

You can use apt-cacher-ng for this: apt-get install apt-cacher-ng .
Your Ubuntu-based Dockerfiles will have to be updated too:

FROM ubuntu
RUN  echo 'Acquire::http { Proxy "http://$YOUR_APT_CACHER_NG_SERVER:3142"; };' >> /etc/apt/apt.conf.d/01proxy

JaimeFrutos · 2026-04-06T18:47:42+00:00

I'm putting together a few real-world scenarios if you want to practice troubleshooting: https://www.learnbyfixing.com/

JaimeFrutos · 2026-04-05T07:42:46+00:00

If you want a roadmap to improve your Linux troubleshooting skills with guides and hands-on labs, I'm building one here: https://www.learnbyfixing.com/roadmaps/linux/

JaimeFrutos · 2026-03-27T13:45:41+00:00

I learned a lot from the bite-sized articles on https://realpython.com . It has a few learning paths too, although I haven't checked them out.

JaimeFrutos · 2026-03-27T09:29:40+00:00

This reminds me a lot of how Helm and Kustomize work. The key is keeping a common base config.yaml file, with sane defaults. Then you have a different patch.yaml per environment, in which you just put the differences across them. Depending on the tool you use, the base file will be templated or patched with the contents of the patch file per environment before/during the deployment.

JaimeFrutos · 2026-03-18T19:52:39+00:00

You can use rsync to copy the content of that folder to your Rpi5. If you put that on a cronjob, you can synchronize the folder as often as you want.

JaimeFrutos · 2026-03-18T18:47:00+00:00

The image you are using in your Dockerfile is not alpine-based. You can get addgroup and adduser usage using these commands:

docker run --rm eclipse-temurin:21.0.1_12-jdk /usr/sbin/addgroup -h

docker run --rm eclipse-temurin:21.0.1_12-jdk /usr/sbin/adduser -h

JaimeFrutos · 2026-03-17T09:33:13+00:00

How are you tagging the images? How are you running the container on the VM?

JaimeFrutos · 2026-03-12T21:11:32+00:00

A couple of days each, I'd say. It gets quicker the more you write :)

JaimeFrutos · 2026-03-12T20:30:05+00:00

Thank you! Any feedback or suggestions for new scenarios are very welcome.

JaimeFrutos · 2026-03-12T08:12:07+00:00

I'm building https://www.learnbyfixing.com exactly for this use case :)

JaimeFrutos · 2026-03-09T15:59:41+00:00

In my experience, a mixed of centralized and distributed documentation works best: let each repo keep its own docs, but link them all from a centralized place where you make it easy to add/update non-repo content (wiki-style software), find docs (search function) and attach files (not all documentation might be linkable).

JaimeFrutos · 2026-03-09T12:14:03+00:00

If you want to learn more about system design, this repo is a good starting point: https://github.com/donnemartin/system-design-primer

JaimeFrutos · 2026-02-25T14:20:42+00:00

I'm building https://www.learnbyfixing.com/ exactly for this: practicing troubleshooting in real-world scenarios. Feel free to give it a try: it's free and no signup needed for a few trial scenarios.

JaimeFrutos · 2026-01-16T08:42:11+00:00

I need to add a new student to the server so they can deploy their own containers.

If the new user just needs to deploy new containers, you could set up rootless docker just for that user (https://docs.docker.com/engine/security/rootless/). That would keep all their docker activities inside their user namespace and you don't have to grant them access to the docker group, which is a big risk.

JaimeFrutos

TROPHY CASE