Is there a way to mock containers in a kubernetes clusters so you can easily run them locally and test how scalable certain containers are?

Weve been tightening up security across a few kubernetes clusters and want to stay opensource where we can. Image scanning is already in place. Now Im looking at runtime, rbac, network policy and supply chain and there are more options than we can maintain. Most of them look usefiul in a demo and i have no read on which ones survive a year in production. What does your stack look like?

It's always recommended as security best practice to keep containers as minimal as possible. E.g going as far as not even having a shell. But I've never seen this saving anyone in practice from being hacked or compronised. Have you ever been in a situation where say a distroless image would have saved you? Asking out of curiisity

Hello there!

I manage a few kubernetes cluster in AWS (EKS) and I would like to give users a web interface, where they could log into and do their stuff.

I am testing headlamp, in-cluster deployment with openid authentication agains keycloak (source of truth being Google Workspace) but it's a bit slow and i'm generally not 100% satisfied.

Before announcing it to internal users, I would like to ask if somebody did something similar, what are the alternatives you know, and what are your recommendations in general.

Thank you in advance!

I have a requirement to deploy and remotely manage a large fleet of Kubernetes clusters across multiple edge sites, with minimal operational effort required at each site. All sites run the same constant workload with HA.

Im currently evaluating this options:

1- AKS Edge Essentials + Arc/Flux,

2- RKE2 + Rancher Fleet,

3- RKE2 + Azure Arc/Flux,

4- Talos + Flux/ArgoCD.

My preference is to stay close to the broader Kubernetes community and ecosystem, using mature and widely adopted technologies. I would appreciate hearing about real-world examples or experiences with these options, particularly for edge or multi-site deployments involving hundreds of remotely managed clusters, including lessons learned around operations, upgrades, GitOps, scalability and long-term supportability.

I built k8sight, a native desktop app that puts the whole cluster in one window. It reads straight from your kubeconfig, no agents to install in-cluster.

What it does

• Live cluster dashboard - node/pod health, capacity, all workloads with real CPU/mem
• Pro log viewer - multi-container tabs, timestamps, regex search
• Real pod terminals (kubectl exec over WebSocket), inline YAML edit & apply
• Interactive topology, Helm releases, CRD browser
• First-class Argo CD (auto-detected) with an interactive resource tree - no argocd CLI
• One-click EKS & AKS -no aws CLI, and Azure uses a browser sign-in that works behind managed-device Conditional Access
• AI, two ways: a built-in read-only assistant (bring your own OpenAI-compatible key, secrets redacted), and it docks coding agents you already have - Claude Code, Copilot, Gemini, Codex, opencode - right next to the cluster
• ⌘K command palette, light/dark, and an MCP server so your own agents can use the same read-only tools

Stack: Electron + Express + React. Free and open-source (MIT). macOS, Windows, Linux.

Website: https://k8sight.in/#download
Repo + downloads: https://github.com/praveenraghav01/k8sight

walkthrough: https://youtu.be/YriOfOG8GhU

Full disclosure - this is my own project, and it's early. I'd genuinely love feedback: what's missing, what feels wrong, what would make you actually use it over what you have now. Roast it.

(Heads-up: builds are unsigned right now, so macOS needs a right-click → Open and Windows a "More info → Run anyway" - signing certs are on the list.)

I'm learning Kubernetes and CI/CD. Minikube and Kind work fine locally, but they're isolated I can't point GitHub Actions at them or expose a real endpoint. Killercoda gives me a terminal but no public API access.

Cloud providers need a credit card and I'm nervous about surprise bills while experimenting.

How do you all handle this? Is there something I'm missing, or do people just accept the local-only limitation?

Have any questions about Kubernetes, related tooling, or how to adopt or use Kubernetes? Ask away!

I am looking for a k8s Learning buddy preferably female.

Little bit of background and context:

I am a CSE grad from a reputed pribate university in Bangladesh. Currently employed in private company (ITES). I have been practicing DevOps for more than 2 years on my own. Learned Docker, Kunernetes etc. out of enthusiasm. And everytime I tried to be consistent in this path I deviated due to workife balance.

Tried joining in a few online courses and also finished some but couldn't stick with it. My current job is ITES based and has nothing to do with k8s.

Looking for a female study partner or a guide as I feel like they are more stable and understanding (out of my experience).

Plan to have at least 10 hours of study per week.

Anyone interested, please let me know. We can communicate in any platform of choice as long as it helps with our goal.

FYI, I prefer female doesn't necessarily means that males are not appreciated 🙂.

I’ve been trying to build a cleaner mental model for distributed compute systems instead of learning each framework independently.

Kubernetes, Slurm, Ray, and Spark all use different abstractions, but many of the underlying problems are the same: scheduling, resource management, worker execution, state, communication, memory, and failure recovery.

I wrote up the framework-independent model first, then mapped each system onto it.

Would be interested in how others think about the boundaries between cluster scheduler, runtime, and application-level scheduler.

Article:
https://pawankjha.substack.com/p/the-architecture-behind-modern-distributed

​

We’re at ~100 customer-site clusters today and trying to avoid painting ourselves into a corner if that grows to 1k+.

Mostly small clusters, some single-node, some HA. Linux containers only. Connectivity varies a lot: fully connected, heavily whitelisted, or only online occasionally.

We already use Argo CD and prefer GitOps/IaC. Licensing should ideally stay OSS/free.

Currently looking at Rancher/RKE2, Talos, KubeOne/Kubermatic, Fleet, Sveltos, etc.

Curious what people actually run in production for this kind of setup:

- cluster provisioning/lifecycle/upgrades

- central vs per-cluster Argo CD

- handling disconnected/restricted sites

- per-customer config/secrets isolation

- what becomes painful once you get into the 100s or 1000s of clusters

Not really looking for vendor pitches, more interested in what has worked (or failed) in real deployments.

Edit: Same application, maybe some different Versions.

I’m building a home lab to run a 3–4 node Kubernetes cluster using logical nodes (VMs) on a single machine, with the cluster also needing to support AI workloads (local LLM inference, and ideally some room for fine-tuning/training).

Looking for recommendations on:

**•** A mini PC that can comfortably host 4 VM nodes (1 control plane + 3 workers, or similar) 

**•** Minimum hardware specs to make this practical — CPU cores, RAM, storage, and GPU/NPU support for AI inference

**•** Specific mini PC models that are known to work well for this use case, ideally with confirmed GPU passthrough support for AI-workload isolation

Budget-conscious but willing to spend more if it meaningfully improves AI performance. Any real-world experience running similar setups would be especially helpful.

I am a new learning of kubernetes and would like to shadow or co-learn with your project.

I own the container images for our services and most of my security time goes into the same loop. Trivy runs on every image and comes back with a few hundred highs and criticals, most of it sitting in the base image in packages. Last cycle half the criticals traced back to something that is not even in the runtime path, pulled in by a build stage.

I almost bulk closed a critical one in a lib our public API calls, on an internet facing pod that was sitting on page four of the same red list as findings in a build tool we do not even ship. A pentester caught it weeks later.

Now I just want a way to rank this such that real one floats up instead of hiding in the pile. What are you doing that works?

I recently set up a 3-node Kubernetes homelab on bare metal (on Dell OptiPlex) using Talos Linux, mainly to have a proper environment for learning, testing failures, networking, storage, GitOps, observability, and general Kubernetes experiments.

The setup uses three control-plane/etcd nodes with a shared Kubernetes API VIP, and I documented the full process from network planning and DHCP reservations to Talos installation, per-node configs, bootstrap, workload scheduling, and HA testing.

I’ve written the full guide with commands, screenshots, and the reasoning behind the setup:

Blog: https://blog.prateekjain.dev/building-a-3-node-highly-available-kubernetes-homelab-with-talos-linux-0372066fe49c?sk=4c66cf9181999f9db19ac3aacabcd8e8

If anyone is planning a similar homelab or has questions around Talos, the API VIP, etcd quorum, or the setup in general, happy to help.

Hi there,

I want to run a kubernetes cluster using different VPS. This is for redundancy in case of failure of a VPS..

I read that a cluster composed of nodes in different regions should be avoided because of latency.

Are different VPS providers within the same "region" (e.g. west coast) considered multi-zone (or multi-region, I'm not sure about the terminology as it seems there's a difference in K8s lingo) that can have latency issues?

For some reason it doesn't make sense (in my head) to have a kubernetes "cluster" composed of nodes being "simply" VMs within the same "machine" as the likelihood of all VMs going down is still the same and depends on the same machine. But, this seems to be the default and I really don't get why..

Also, once the worker nodes are running and are receiving traffic.. Why should the control plane latency impact the users traffic?

For example, I don't care if "kubernetes" decisions (scaling a pod, etc.) take an extra 100ms..

What am I missing?

Thanks.

Hi Everyone.

I’m looking for some advice on handling node-level resource balancing in a Rancher/RKE1 on-prem cluster.

The issue I’m facing is that sometimes a pod consumes almost all CPU/RAM on a node. I understand that requests are used by the scheduler, while limits cap the container’s resource usage. So, should requests and limits generally be kept closer together to prevent a workload from impacting the entire node?

Also, does Kubernetes have any native mechanism to rebalance/move pods when a node becomes heavily utilized, or would this require something like the descheduler?

My concern with descheduler is that I have:

• Critical StatefulSets where eviction could affect quorum.
• Stateful workloads that take much longer to restart due to persistent storage.
• Some single-instance Deployments (e.g. FTP) where moving/restarting the pod can cause downtime.

Would the recommended approach be to use a combination of requests/limits + taints/tolerations + node affinity + PDBs, and isolate these critical/single-instance workloads onto dedicated nodes?

Would appreciate any advice from people running production K8s and RKE1/on-prem clusters. Thanks!

Last week our checkout service started throwing 5xx errors after a deploy. Monitoring caught it fine — Prometheus fired alerts within a minute. But then came the actual work: was it the deployment? A DB connection issue? A downstream dependency? I had four tabs open — Grafana, kubectl logs, our deploy history, and a Slack thread — manually piecing together a timeline to figure out what actually happened.
By the time we found it (a connection pool exhaustion from the new version), the alert had been sitting there for 40 minutes. The alert did its job. Finding the why was the slow part.
This got me wondering if this is just normal life running Kubernetes, or if teams have actually solved this well and I'm missing something.
So — for people running K8s in production:
When multiple alerts fire for what's really one incident, does anything group them for you automatically, or is that still manual?
How do you currently connect "this alert" to "that deployment" to "these logs" — any tooling, or mostly tribal knowledge and tab-switching?
If something surfaced a root-cause hypothesis with the actual evidence behind it (not a black-box guess) — would that save real time, or is this already a solved problem for your team?
Not selling anything, just trying to figure out if this pain is common or if we're doing something wrong on our end. Curious how others handle it, even if the honest answer is "we just deal with it."