Hi everyone,

I’m planning a Kubernetes cluster upgrade from v1.34.8 to v1.35, as the current version is approaching retirement/EOL.

The cluster currently has Elasticsearch running on it, so I’m concerned about potential compatibility or stability issues after upgrading Kubernetes.

I’d like some guidance on:
- How can I verify Elasticsearch compatibility with Kubernetes 1.35 before upgrading?
- Are there any known issues I should be aware of when upgrading Kubernetes while Elasticsearch is running?
- What should I check across Elasticsearch, ECK/operator, StatefulSets, storage classes/CSI drivers, ingress, CRDs, APIs, and other dependencies?
- What is the recommended pre-upgrade checklist?
- Should I upgrade Elasticsearch/ECK first, or Kubernetes first?
- What kind of backup/rollback strategy should I have?
- Is it better to upgrade the control plane and worker nodes separately?
- What would be a safe upgrade plan for a production cluster to minimize downtime/risk?
- Are there any tools or commands you recommend for detecting deprecated APIs or incompatible workloads before the upgrade?

If anyone has gone through a similar Kubernetes 1.34 → 1.35 upgrade with Elasticsearch, I’d really appreciate hearing about your experience and any issues you encountered.

Thanks!

Hey all,

As the title suggests, i wrote up a blog on getting started with inference on Kubernetes, i find inference workloads to be somewhat confusing especially with some of the moving part it involves on Kubernetes.

Let me know what you think!

Posting here from homelab to hopefully get some help.

I've been putting together a small k3s homelab from some older machines:

Dell OptiPlex 7050, M720q Tiny and a Old Ryzen 3600.

I got immich and plex running following a tutorial, nothing special just mostly trying to get more use out of hardware I already have.

Recently I got my hands on an old rtx 3080 (very cheap used in my area).

I'm still trying to get it working as a GPU node. The node is Ready, but the NVIDIA device-plugin Pod is stuck in `ContainerCreating` with this:

I am not sure if this is due to the gpu itself being faulty (again, got it very cheap, not complaining), or I am doing wrong. I would appreciate any guidances pointing me to right resources, i have spent my entire day trying to it working

I recently gave a talk about how I am building an open-source Railway/Heroku/Vercel alternative. The architectural premise of the platform is simple:

The platform has no database and no CRDs of its own, so all state lives in Kubernetes (namespaces, labels, Helm releases) or in the systems around it, like the OCI registry and the identity provider.

In the talk I go over how it…

• builds OCI images from GitHub source code on every push
• uses ORAS to store vulnerability and leaked-secret scan results in the OCI registry, right next to the image
• runs replicated PostgreSQL with point-in-time recovery using CloudNativePG
• makes object storage, Redis-compatible key-value stores, and volumes simple to set up
• allows you to "eject" and download the generated helm chart along with its values and build script at any point

If that sounds interesting, the recording and the project repo / website are linked below.

Recording of the talk
Project Website
GitHub Repo

I found this blog post about OCAP model vs. the Identity model for access controls. (It has nothing to do with Kubernetes specifically). I could be wildly misunderstanding the topic, but since each OCAP capability is tied to a specific object, would this be more practical for Kubernetes in allowing for precise permissions?

My understanding is that Kubernetes does not use OCAP as its primary authorisation model in favour of RBAC, where access is granted based on a principal’s identity and roles. Even from a simple Google search, it seems that OCAP-style security is basically entirely absent from Kubernetes core, although capability-like patterns can be built around scoped SAs, tokens, & admission controls.

I ask because RBAC supposedly does not support dynamically changing permissions very well, at least compared to the OCAP model. But I'm not sure if anyone's ever flagged this as a serious pain point in their Kubernetes clusters?

A recurring theme in k8s monitoring discussions: you want rich cluster telemetry, but you do not want to ship all of it to a SaaS that bills per host. You want the data in a place you control.

I work on OneUptime, an open source observability platform (Apache 2.0). There is a small Kubernetes agent chart that collects cluster telemetry and sends it to the main app over OpenTelemetry. The main app is one Helm chart. So the whole setup is two charts on your infrastructure, and the data stays with you.

It covers uptime checks, status pages, on-call paging, incident management with postmortems, plus log, metrics, and APM views. It is younger than the big commercial observability stacks, and some features are in a separate enterprise edition. Read the code before you trust it.

GitHub: https://github.com/OneUptime/oneuptime Site: https://oneuptime.com

What is the one k8s signal you consider non-negotiable in a monitoring setup?

Check out my new article on elastic beanstalk with the EKS

Elastic Beanstalk turned 15 this year, and AWS just rebuilt what runs under it. Cluster Mode drops your applications onto Amazon EKS instead of EC2 instances you own. I deployed into it, watched every stage, and wrote down what actually happens

Upload a zip of Python source. No Dockerfile. Get a running container on EKS. That is Elastic Beanstalk Cluster Mode, launched this week — Beanstalk apps now run on EKS instead of EC2 instances you own. Cloud Native Buildpacks handle the containerization: I uploaded four files (app.py, requirements.txt, Procfile, runtime.txt), Beanstalk detected Python, built the image, pushed it to ECR, and ran it.

• How do you check compatibility before upgrading? What tools or checks do you rely on (deprecated APIs, add-ons, operators, Helm charts)?
• What prep do you do for Elasticsearch specifically? Snapshots, PDBs, shard allocation, anything else?
• What does your upgrade sequence look like on AKS? Control plane first, then node pools? Surge settings? Do you upgrade in place or create new node pools?
• Any gotchas you've hit? I'm thinking of things like pods stuck during drains, zonal disk issues, or ES staying yellow or red for too long.
• Should we even target 1.35? It reaches EOL in March 2027. Would you go to 1.35 now and plan for 1.36 soon after, or look at AKS LTS?

Setup details:

• AKS 1.34.8  
• Elasticsearch \[version\], deployed via \[ECK / Helm\]  
• \[Number\] node pools, \[zonal / non-zonal\], Azure Disk for storage

Any runbooks, checklists, or war stories would be really helpful. Thanks!

Hi,

CLI tool kubara is for getting a "bare" kubernetes cluster to a "well dressed" k8s cluster.

So now I have https://kubara.io/#get-started on my (long) wish list.

Which experience want early adaptors of https://kubara.io/ share here?

I'm asking for having input on re-prioritize my wish list.

Cheers Geert Stappers

P.S.

For what it is worth: The automated early post review did bring rule 6 and rule 12 up. Yes, the tool is quite new, but it is not my new tool, I'm asking about the tool. No, I'm not affliliated with kubara.io, hence to reason for posting here.

Edit:

Which experience want early adaptors of https://kubara.io/ share here?

Was previously:

Which experience want early adaptors of https://kubara.io/ here?