I’m trying to adopt Kubernetes, but I keep hitting the same snag. A lot of the official docs read like they assume you already know the basics. Definitions show up, but they use other Kubernetes terms in place of plain explanations.

It makes me feel lost at the start. I’m not sure if I’m missing something, or if other beginners feel the same.

I'm new to Talos so bear with me. I created a simple local cluster, cool:
talosctl cluster create docker

Preferably, I want to configure a yaml file or such and create a pipeline which patches changes automatically. I just checked talhelper but it's archived since last week: https://github.com/budimanjojo/talhelper. I do see other community solutions. It feels however like I'm missing something but my knowledge is limited. What do teams / enterprises use in production to provision clusters and patches from pipeline?

Three years ago I shared my Kubernetes cheat sheet here which got positive feedback. This week I finally found some time for a proper update, trimming some commands which are used less often and introducing overviews of API resources, pod statuses, service types and other useful information.

Note that it's not intended to be a full reference or substitute for the official documentation, but rather as a quick overview of commonly used features. If you are an expert Kubernetes user there might not be much new information on it for you, but as a novice or intermediate user (such as myself) you might find it useful.

You can download the cheat sheet as a PDF file here. It's published under CC BY-ND 4.0, so feel free to share it, print it out, use it at work, etc.

Please let me know if you find it useful or if you see any mistakes.

Anyone used it?

Netflix migrated most of its batch workloads onto Kueue, an open-source cloud-native batch job execution system that has outgrown its homegrown solution over the years. The company mapped the capabilities previously created in-house to Kueue’s functionality and also benefited from new features that would have been costly to incorporate into its homegrown solution. Engineers used API parity with the existing system to derisk the project and allow for a gradual and seamless migration.

Check out our latest episode: Agent Substrate: Running AI Agents at Scale on Kubernetes, with Tim Hockin & Brandon Royal! https://kubernetespodcast.com/episode/272-agent-substrate/
AI agents require terminal access, browser automation, and file system isolation—yet internal benchmarks show they sit idle over 90% of the time waiting on humans or LLMs. Traditional Kubernetes primitives were built for long-running web services and databases, not rapid, ephemeral agent sessions with extreme pod churn.
We sat down with Tim Hockin (Principal Software Engineer and one of the original founders of Kubernetes) and Brandon Royal (Product Manager on GKE) to discuss Agent Substrate (ate.dev), a new open-source runtime designed to solve this paradigm shift.
We dive deep into the architecture, covering:
- The "Idleness" Challenge: Why AI agent workloads require a fundamentally different approach to density and resource allocation.
- Workers vs. Actors: How decoupling underlying worker pods from ephemeral agent sessions bypasses control plane limits to achieve >10x density improvements.
- Instant Suspend & Resume: How state snapshotting (memory/disk to local storage or cloud buckets) eliminates the cost of idle compute.
- Agent Identity & Sandboxing: Why sandbox isolation goes beyond hypervisors to include strict policy enforcement and identity delegation.

I want to capture multicast traffic in my Kubernetes clusters. The options I’m considering are hostNetwork, macvlan, or ipvlan. Are there any other approaches that can capture multicast traffic with near host-level latency?

Curious what people are using in real environments.

One platform for everything, or a mix of different tools for vulnerabilities, posture, access, compliance, etc.?

And are you happy with the setup?

Did you learn something new this week? Share here!

Looking for input from people who've actually shipped custom domains for a multi-tenant SaaS, because I want to avoid picking the wrong path and regretting it later.

Current setup:

• Multi-tenant events platform on AWS
• Frontend is a React app — dist folder on S3, served through CloudFront
• Today every tenant gets a platform subdomain (tenant.stage.example.com) via a wildcard cert on CloudFront. Frontend reads the hostname, asks the backend "which event is this?", renders accordingly.
• API calls go to a fixed, separate domain (api.example.com) — so the custom domain is only needed for serving the static frontend, not the API.

What we want:
Clients want to bring their own domains (portal.clientbrand.com) instead of our subdomain. So I need per-domain TLS that issues + renews automatically, with no manual step per client.

Options I'm weighing:

1. CloudFront manual + automation — add each domain as an alternate domain name + ACM cert via a script. Works, but there's the ~100 CNAMEs-per-distribution wall, and one cert per distribution feels fragile at scale.
2. CloudFront SaaS Manager (the multi-tenant distribution thing from 2025) — looks purpose-built for this, up to ~2000 domains, per-tenant ACM. Since we're already on CloudFront this seems like the least-effort path, but I haven't found many real-world reports.
3. Caddy on-demand TLS — reverse proxy that issues certs on first handshake. Unlimited scale, but it's a new component to run/monitor, and I'd need the ask endpoint to avoid getting our Let's Encrypt limits burned by random hostnames.
4. Managed service (Approximated / similar) — lowest effort, but monthly cost + another third party in the traffic path.

Questions:

• For anyone running CloudFront SaaS Manager in production — is it solid? Any gotchas with cert provisioning, DNS validation, or pricing at scale?
• Given our API is already on a fixed domain (custom domain = static content only), is a reverse proxy like Caddy overkill for us?
• Anyone regret going the manual-CloudFront-automation route and wish they'd started with something else?

Expected scale is realistically low-hundreds of custom domains over time, not thousands. Trying to pick something that won't need re-architecting in a year.

Thanks in advance 🙏

I wanted a more comfortable way to read Kubernetes The Hard Way on an electronic reader, so I built a small project that converts the upstream repository into an EPUB.

It tracks the current upstream default branch and records the exact source commit in the book. Every six hours, it checks for changes and automatically publishes an updated EPUB when necessary.

Tables, code blocks, images, and navigation are formatted for EPUB readers. The styling is designed to remain readable in both light and dark mode.

Security was also important to me. The builder rejects JavaScript, executable files, unsafe embedded content, remote resources, and malformed archives. Every release passes the project’s security checks and official EPUBCheck validation. Releases also include an SHA 256 checksum and build provenance attestation.

Calibre is not required. The EPUB is constructed directly with Python and should work with any standards compliant reader.

This is an unofficial, noncommercial reading format adaptation. It is not affiliated with or endorsed by Kubernetes, CNCF, The Linux Foundation, or Kelsey Hightower. The EPUB remains under the upstream CC BY NC SA 4.0 license.

You can download the EPUB here:

https://github.com/terrytrent/kubernetes-the-hard-way-epub-builder/releases/tag/epub-master

The source code and build instructions are here:

https://github.com/terrytrent/kubernetes-the-hard-way-epub-builder

I mainly built this because I wanted it for myself, but I figured it might be useful to other people too. If you try it, let me know how it looks in your reader, especially if you find any formatting problems in light or dark mode.

Hi everyone,

I'm working on an open source K8s optimization tool that analyzes Prometheus+OpenCost data and generates recommendations such as CPU/memory rightsizing, idle workload detection, and other resource-efficiency improvements.

I'm now thinking about how these recommendations should become actionable.

The first approach I considered was applying changes directly to the cluster. For example, updating a deployment's requests/limits through the Kubernetes API. The problem is that this requires powerful permissions on the cluster and I'm not very comfortable with an optimization tool having write access to production workloads.

The alternative I'm considering is a GitOps-based workflow:
Recommendation -> Git commit -> Pull Request -> review/CI -> ArgoCD -> cluster

This has some nice properties:
- no write access to the production cluster
- changes are auditable
- easy rollback
- fits naturally with GitOps workflows

The downside is obviously that not every k8s environment is GitOps-based, and implementing this properly means dealing with GitHub/GitLab, private repositories, self-hosted Git instances, different repo structures, Helm/Kustomize, etc.

For those of you running Kubernetes in production, would you prefer an optimization tool to apply changes directly through the Kubernetes API, create a Git PR, or something else?

I'm building this as part of GreenKube, an open-source Kubernetes FinGreenOps project, but the question is really about the workflow itself. I'd be very interested in hearing how others approach this.

Hi, we’re an OpenShift shop that originally started out on-prem. We then got ARO (Azure managed service) and honestly kinda hate the product due to the dysfunctional support arrangement between Microsoft and Red Hat. So much that I want to rip those managed clusters out and build self-managed ones.

Now the question has come up for the other cloud. In AWS, it a better product? Out RH account teams claims it is. My default would be to use the cloud service if possible, assuming it’s a good product. I’d like to just confirm nobody has any nightmare horror stories about ROSA as an unusable pile of garbage before going down that path.

Hey there,

I migrated a production cluster from ingress-nginx to Traefik v3 and wrote a bit of a not-so-guide about it. Why Traefik, why now, and the gotchas.

I did not write it as a step by step guide, you can ask your favourite AI assistant for that now. It is more the thinking process and the "unknown unknowns" that showed up on the way. The short version: Traefik's ingress-nginx compatibility provider translates the annotations, so no Ingress edits, but nothing carries over the controller-level defaults. The HTTP->HTTPS redirect was one of those things.

The link: https://hostim.dev/blog/migrating-off-ingress-nginx/

Disclaimer: I run hostim.dev, and this post is an attempt to balance between contributing my 2 cents and getting the word out.

Cheers

Hey, I’ve been looking for a DevOps jobs for 7 months now . But I guess My location is working against me , I’m based in Nairobi Kenya . I have 5 years experience as a backend dev and in the last year of my career I worked as a DevOps. I have experience with Docker, Kubernetes (EKS), Azure , AWS (S3, VPC, IAM, fargate, ecr, ), GitHub Actions, gitops , terraform , gcp .

Here’s my proof of work and experience:

https://github.com/MainBank5

Any offer is welcome. I can submit my resume privately

Share any new Kubernetes tools, UIs, or related projects!

Hey everyone,

Like many teams running Kubernetes, we noticed our platform/DevOps engineers spending hours every week triaging routine pod errors for developers—things like ImagePullBackOff, bad probes, or OOM crashes that developers didn't have the context to diagnose themselves.

To fix this, I built a full-stack Kubernetes AI Troubleshooting Agent that acts as an automated first responder.

Architecture & Tech Stack:

* Frontend: Next.js / React (modular cluster explorer & live investigation timeline)

* Backend: Python + FastAPI

* Cluster Diagnostics: Automated collectors inspecting pod states, events, streaming logs, deployment specs, and DNS/service endpoints via kubectl

* AI / Reasoning: OpenRouter-backed LLMs prompted with SRE-level diagnostic instructions

* Database & Auth: Insforge backend handling auth, RBAC-style cluster permissions, and investigation histories

* Local Dev: kind clusters running in Docker

How it works:

* A developer opens the dashboard and selects their authorized cluster/namespace.

* When an issue occurs, clicking "Investigate" kicks off an automated diagnostic run:

* Evaluates pod health & restarts

* Scrapes recent container logs & termination reasons

* Inspects Kubernetes events for scheduling/resource bottlenecks

* Verifies service endpoints and network policies

* The raw diagnostic payload is passed to the LLM engine.

* The agent returns:

* Root Cause Summary: Clear, plain-English explanation of why the failure occurred.

* Remediation Command: Concrete kubectl command or YAML patch.

* Confidence Score: e.g., 85% confidence if alternative configuration choices exist.

* Prevention Advice: Best-practice changes (e.g., CI linting, memory limit tuning).

Tested Failures:

Tested against invalid tags (ImagePullBackOff), misconfigured crash-loops, and CoreDNS readiness check issues. In all cases, it accurately flagged the error and saved ~15-20 minutes of manual log hunting per incident.

I'd love to get your thoughts: Have you implemented AI-assisted debugging in your clusters? What safety guardrails do you require before letting agents suggest or execute cluster mutations?

Anyone else hit this?

Users created with 2.14.1 / 2.14.2 / 2.15.0 cannot login #5537

https://github.com/rancher/rancher/issues/55378

The primary thing I use rancher for is to allow for local access, and you can't log in with accounts created in recent versions of rancher. I don't feel like downgrading k8s to a version the pre-bug version of rancher stable works on.

I have a prior working experience in k8s but when it comes to interview, I am not getting the confidence as I had my legin many boats.

It is boring to go through any book or course which gives me lots of basic info so I am looking for a way through i could brushup my skills and also practice/learn the things and master myself from interview & working perspective.

Looking for your valuable inputs,,

Thanks

One of the key tools for achieving graceful shutdown in Unix-based systems is the concept of signals, which are software interrupts sent to a program to indicate that an important event has occurred.

A CRD upgrade can pass schema validation while a rolling deployment still leaves old controller pods reading or writing the previous shape. The risky cases seem to be renamed fields, changed defaults, status fields with different meaning, and a downgrade after some objects have already been rewritten. What compatibility contract do you use across that window? I would expect additive fields first, explicit conversion where versions differ, checks around storedVersions, fixtures that exercise both controller versions, and a rollback plan that does not assume newly stored objects are readable by the old binary. Which parts do you test before rollout, and when is a conversion webhook worth the operational cost instead of keeping one storage version and doing a staged migration?

Hi all!

Along 32 other providers, you can now declare application secrets using a single toml and also use kubernetes among them.

It's OSS project we've been working on for a year with 10 SDKs supported.

Let us know, is has helped many people sort out their secrets!

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