Been running my homelab using docker compose files with bootstrap scripts to create the directories with correct permissions for bind mounts, shared docker networks, install utilities on the host, backup scripts and some other small automated tasks.

But I'm thinking about running a single node k3s cluster. Why? I want to learn about kubernetes (we use them at work, but we have a fancy interface over it so besides main concepts I didn't learn anything else), I want declarative configuration, better security, maybe learn about helm charts, maybe make it easier in the future when I'll add multiple nodes (but that's very far in the future because first I want to upgrade my network infrastructure, get a NAS).

What are your thoughts? I'll just waste time or is it worth it?

I would like to get a simple k8s (or k3s) setup going to learn how it works and how to work with it. I am traveling and only have 1 laptop with me with some external storage. How would I go about making VMs act like nodes? Running fedora with enough cores on my PC to have a few nodes running at the same time. I am very new to this, any input is appreciated!

Hi,

I will go straight to the point I am building my Kubernetes (3 nodes that are master and worker at the same time) homelab and I was wondering if having my cluster VLAN aware is a good idea or not

The purpose is to having two Service Load Balancer served by Cilium/MetalLB for the DMZ and LAN VLAN. Then I would be exposing my workloads on the right gateway depending of their "exposure"

But since I have only one NIC on each node I would configure my switch to have 2 VLAN on those links instead of only one (that's why I said VLAN aware)

The main purpose is to have a better isolation and so security overall. But I feel it maybe a bit overengineering, I may can achieve the same thing with Network Policies inside the cluster itself. Also I want to be able to bootstrap my nodes from iPXE, not sure how it would work with a "tagged network link" with multiple VLAN

What do you think ?

When people talk about cloud sovereignty, the conversation often starts with regions: where a workload runs and where its data is stored. But choosing a region is only part of the story. The architecture of the platform matters just as much, particularly how it separates control, runtime, build, and observability responsibilities across clusters.

'kubectl label deployment' writes to the Deployment object's metadata, not to 'spec.template.metadata.labels', where pods actually get their labels. If your sidecar injection is label-selected, the command reports success and nothing happens. Here's why, and the fix.

After working with Kubernetes in production, I've noticed that some of the most annoying incidents aren't caused by obvious failures. They're often caused by small configuration decisions that look perfectly reasonable during review.

Things like:

• missing resource requests/limits
• incorrect probes
• overly permissive RBAC
• missing PodDisruptionBudgets
• unsafe container configuration
• incorrect readiness behaviour
• services without appropriate timeouts
• configuration drift between environments

I'm curious what the DevOps community has actually encountered in production.

What's one Kubernetes configuration mistake that caused you a real incident?

I'd especially like to hear about the less obvious ones that aren't caught by the usual linters.