One Calendar, One Checklist: Get Ready for Argo CD 3.6 and Kubernetes 1.38

Every restaurant has a week before the holiday rush. Nobody puts it on the menu, but it's when the good kitchens check the walk-in, count the pans, and test the new equipment before the crowd arrives.

For platform teams, the next few weeks are that week. A Kubernetes branch is about to lose upstream support. Argo CD 3.6 is in release-candidate territory. KubeCon North America is on the calendar. And Kubernetes 1.38 is taking shape, with a few changes you'd rather read about now than discover during an upgrade.

So here's one calendar, one test plan, and one checklist. No panic required, but a little planning goes a long way.

What We Are Cooking Today

• Line up the dates that matter between now and mid-December
• Preview what's in Argo CD 3.6 (and what to test in staging)
• Scan the Kubernetes 1.38 development news for things that could affect you
• Run a short pre-November checklist

The November Calendar

Date	What	Source and confidence
Oct 20 (check it shipped)	October Kubernetes patch releases, postponed one week to include the latest Go releases and CVE fixes	Last Week in Kubernetes Development newsletter
Oct 27	Upstream Kubernetes 1.34 end of life	Reported by several trackers; confirm on the official Kubernetes releases page
Nov 3	Argo CD 3.6 GA target	Project release schedule; dates can slip by a few days
Nov 8-12	Maintainer Summit (Nov 8) and KubeCon + CloudNativeCon North America, Salt Lake City	Kubernetes community newsletters
Dec 2	Amazon EKS standard support for 1.34 ends	endoflife.date; confirm with AWS docs
Dec 16	Kubernetes 1.38 target release	Kubernetes release schedule as reported by the community newsletter

A correction from last week: I wrote that the October patch round was scheduled for October 13. The project later postponed it by one week, to October 20. If you're planning around the 1.37.2, 1.36.6, and 1.35.10 releases, check the official patch calendar for what actually shipped.

The nuance worth remembering: upstream end of life isn't the same as your managed provider's support window. EKS keeps its own calendar, which is why 1.34 reaches the upstream deadline weeks before EKS standard support ends. You still want to know exactly what your provider patches and for how long.

Argo CD 3.6: What's In the Release Candidate

The first release candidate landed in mid-September. The headline theme is "less memory, faster UI, better rollout visibility." Everything below comes from the project's RC announcement.

Area	What's new
Web UI	A global Resources Explorer (managed resources across all your Applications, respecting RBAC), regex search for Applications and ApplicationSets, lazy-loaded UI routes, and virtual scrolling for huge lists. The project reports roughly 20-30% less rendering work when filtering and searching on large installations.
ApplicationSets	A new OCI generator, tpl function support in go templates, workqueue rate limiter flags, and progressive sync that no longer acts on stale data
Progressive sync observability	Four new metrics and new status conditions, so "which step is my rollout stuck on?" finally has an answer
Controller	A new rollback RBAC action, server-side label filtering with resource.selectors, and configurable serialization and compression for cached manifests
CLI	--strip-status for argocd admin export, a --server-proxy-url flag for argocd cluster add, and better signal handling
Observability	OpenTelemetry spans across the controller, repo-server, and gitops-engine with a configurable sample ratio, plus a hydrator_status label on argocd_app_info
Quality	More than 170 bug fixes, including a repaired OIDC refresh flow and server-side diff that respects impersonation

The memory claim, in context

The cached-manifest compression item comes with striking numbers. The project says one live instance dropped controller memory from 3.27 GB to under 1 GB (about 70%) for roughly 2.5% more CPU, while a test on a large production instance measured around 30% savings with no observable CPU or performance cost. Those are the project's reported results on specific instances, not a guarantee. Your numbers depend on your cluster sizes, resource counts, and churn. Measure your own controller before and after.

The feature I'd test first: rollback RBAC

Argo CD gets a dedicated rollback action for Applications. It's disabled by default for backward compatibility, and you enable it with the server.rbac.rollback.enforce.enable flag in the argocd-cm ConfigMap. The restrictions are sensible: it works only for non-autosynced Applications, only to revisions in the Application's history, only dryRun and prune can be overridden, and no partial sync. That means you can let an on-call engineer roll back without granting full sync rights. Whether that's a win depends on your model, so test it in staging before you rewrite anyone's permissions.

Kubernetes 1.38: The Early Read

The 1.38 cycle began August 31. After the enhancements freeze, the community newsletter reported 86 enhancements tracked out of 102 that opted in, with 16 removed from the milestone. Alpha 2 shipped October 7. Everything below is in development, so treat it as a preview, not a promise.

• Leader Election Recovery (alpha, targeted). Today a controller-manager leader that can't renew its Lease during a brief API server or etcd blip exits and restarts, rebuilding its caches. The proposal adds a write gate so the former leader can keep trying to renew without restarting. It's behind a disabled-by-default gate (LeaderElectionRecovery).
• Projected ServiceAccount tokens for kubelet image credential providers (targeting GA). Image pulls can follow workload identity with short-lived tokens instead of long-lived pull Secrets.
• HPAGeneration promoted to GA in the development branch, and kuberc support graduated to stable.
• DRA keeps growing. Device binding conditions reached GA in the development branch, and device taints and rules went GA in the 1.37 cycle, as we covered earlier this month.

Now the part to read carefully, if you run your own control plane:

• A feature gate removal. The SeparateTaintEvictionController gate was removed from kube-controller-manager. The newsletter says to remove it from existing --feature-gates configuration before upgrading.
• kubectl kustomize no longer loads kustomize Go (.so) plugins. Exec and KRM function plugins are unaffected.
• A deprecation cleanup. The MatchLabelKeysInPodAffinity gate was removed.

On a managed service you usually don't set controller-manager flags, but the kustomize change can still hit your CI scripts.

Ingredients

• kubectl and the aws CLI (or your cloud's equivalent)
• A non-production Argo CD you can break
• The argocd CLI with admin access to that instance
• Read access to your CI repositories
• One focused hour

Recipe Steps

Step 1: Inventory every cluster version

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  for c in $(aws eks list-clusters --region "$r" --query 'clusters[]' --output text); do
    v=$(aws eks describe-cluster --region "$r" --name "$c" --query 'cluster.version' --output text)
    echo "$r  $c  $v"
  done
done

Expected: one line per cluster with its version. It makes many API calls, so run it with credentials that can read EKS in every region you use. Pitfall: forgetting clusters in regions you "never use." Somebody always uses one.

For nodes inside a cluster:

kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion

Step 2: Plan the 1.34 ladder

Kubernetes upgrades one minor version at a time. From 1.34, the path is 1.35, 1.36, then 1.37, with a rehearsal at each hop. Put an owner and a date next to each cluster. Our security best-practices guide covers the hardening side.

Step 3: Back up Argo CD's configuration

Before testing any release candidate, snapshot what you have. The new status-stripping option makes the export clean enough to treat like a GitOps-style backup:

argocd admin export -n argocd --strip-status > argocd-backup.yaml

Check argocd admin export --help for the exact options in your CLI version. Store the file somewhere durable, not on your laptop.

Step 4: Stand up the 3.6 release candidate in staging

Use the latest 3.6 release candidate from the Argo CD releases page, install it into a non-production cluster, and read the 3.5 to 3.6 upgrade guide first. Then validate the things you rely on most: SSO login (the OIDC refresh flow was fixed), your ApplicationSets (especially anything using progressive sync), and your custom health checks.

Step 5: Try the rollback action in staging

Enable server.rbac.rollback.enforce.enable in argocd-cm, create a test role with the rollback action on a non-autosynced test Application, and confirm an on-call-style user can roll back but can't do a full sync. Use the RBAC documentation for the exact policy syntax in your version.

Step 6: Scan for the 1.38 gotchas

If you run your own control plane, check for the removed gate:

kubectl -n kube-system get pods -l component=kube-controller-manager -o yaml | grep -i feature-gates

For the kustomize change, find kustomizations that use generators or transformers and check whether any rely on Go .so plugins:

find . -name kustomization.yaml -exec grep -lE "^(generators|transformers|validators):" {} +

Anything listed deserves a look. Exec and KRM function plugins are fine; Go plugin binaries aren't.

Step 7: Decide what you'll do at KubeCon

Sounds odd, but it's useful. If you're attending, note the Argo CD, Karpenter, and upgrade-related sessions that apply to your roadmap before the schedule fills your head with ten other things. This part is pure opinion, and good for morale.

Chef Tips

• Test release candidates, don't run them in production. RC feedback is how projects find the bugs you'd otherwise hit later. Staging is the right place to participate.
• Read upgrade notes before release notes. Release notes say what's exciting. Upgrade notes say what breaks.
• Sequence your changes. Don't upgrade Kubernetes and Argo CD in the same maintenance window. When something fails, you want exactly one suspect.
• Treat community-newsletter items as previews. Merged to the development branch isn't the same as shipped in the release.

Kitchen Disasters

Symptom	Likely cause	Fix
Staging Argo CD upgrade fails on a CRD or config	Skipped the upgrade notes	Read the 3.5 to 3.6 guide and apply documented changes first
Rollback action not available	It's off by default	Enable server.rbac.rollback.enforce.enable in argocd-cm
Rollback refused on an Application	Auto-sync is on, or the revision isn't in history	Rollback only works for non-autosynced Applications and revisions in history
Control plane fails to start after a future upgrade	Removed feature gate still in --feature-gates	Remove it from your configuration before upgrading
CI job running kubectl kustomize fails	It relied on a Go .so plugin	Move to an exec or KRM function plugin
A cluster surprises you on the wrong version	Cluster in a region nobody checked	Inventory across all regions and accounts

Serving Suggestions

• Pair the Argo CD test with our GitOps and CI/CD fundamentals if you're bringing new teammates up to speed.
• Build a dashboard for the new progressive-sync metrics, and alert on rollouts stuck at a step. Check the metrics documentation for exact names and labels in your version.
• If you adopt the new resource selectors to cut Argo CD memory, change one cluster at a time and watch for resources that silently stop appearing.

Cleanup

Tear down the staging Argo CD when you're done testing, or keep it as a permanent "next version" environment, which is the better habit. Delete any test roles and Applications you created, and keep the export file from Step 3 until the production upgrade is finished.

Frequently Asked Questions

Should I upgrade production to Argo CD 3.6 on GA day?

That's your call, but most teams wait for the first patch release and a staging soak. The project says only the three most recent minor versions get patches, so you do have a window, but not an infinite one.

Is 1.38 final yet?

No. It's in development with a December 16 target. Scope can still change.

Does upstream 1.34 end of life mean EKS 1.34 stops getting patches immediately?

Not necessarily. Managed providers publish their own support calendars. Read yours.

Do the Argo CD memory savings apply to me?

Maybe. They depend on how many resources your controller caches. Measure memory before and after in staging before you promise anyone a number.

Final Thoughts

None of these dates is scary on its own. The danger is the pile-up: a version deadline, a release-candidate window, a conference, and a December upgrade all landing in the same six weeks. One calendar and one afternoon of checks turns that pile-up into a plan. Write the dates down, test the release candidate, scan for the 1.38 surprises, and let the holiday rush come.

🔥 Related CloudChef Recipes

Loading related posts...

References

• Argo Project blog: Argo CD v3.6 release candidate 1
• Argo CD docs: Release process and cadence
• Last Week in Kubernetes Development: week ending October 11, 2026
• Last Week in Kubernetes Development: week ending September 27, 2026
• Kubernetes releases and patch schedule
• endoflife.date: Amazon EKS release and support dates