Kubernetes 1.36 to 1.37 Upgrade Risks for .NET Services

Kubernetes minor-version upgrades are often treated as infrastructure maintenance.

For a .NET team, that can be misleading.

A Kubernetes upgrade can change the environment in which an ASP.NET Core application runs:

Kubernetes
    ↓
Kubelet
    ↓
Container Runtime
    ↓
Linux
    ↓
.NET Runtime
    ↓
ASP.NET Core
    ↓
Application

A change at any layer can appear as an application problem.

The Kubernetes 1.37 release is currently scheduled for August 26, 2026. The release candidate was published on August 5, and the project is currently in the final stages of the release cycle.

That makes the period before the release a good time to validate production clusters.

For .NET services, the biggest upgrade risks are not necessarily changes to C# code. They are operational issues involving node compatibility, container runtimes, cgroup configuration, pod lifecycle, health probes, resource behavior, and workload disruption.

What Changes During a Kubernetes Upgrade?

A Kubernetes minor upgrade can involve several components:

Control Plane
    ↓
API Server
Controller Manager
Scheduler
    ↓
Worker Nodes
    ↓
Kubelet
Container Runtime

For a kubeadm-managed cluster, Kubernetes explicitly recommends upgrading one minor version at a time rather than skipping minor versions. The documented upgrade procedure also notes that containers are restarted during an upgrade because the container specification hash changes.

That restart behavior matters for .NET services.

Even if the application image itself does not change, your application processes can still restart as nodes and cluster components are upgraded.

First Risk: Kubernetes 1.37 Is a Pre-Release Planning Target

As of this writing, Kubernetes 1.37 has not reached general availability.

The official schedule lists:

1.37.0-rc.0
    ↓
August 5, 2026

1.37.0-rc.1
    ↓
August 19, 2026

1.37.0
    ↓
August 26, 2026

These dates come from the Kubernetes release schedule and can change if the release process changes.

Therefore, production teams should distinguish between:

Testing against 1.37 RC

and:

Production upgrade to 1.37.0

Do not automatically promote a release candidate to production simply because application tests pass.

Risk 1: Container Runtime and cgroup Compatibility

One of the most important node-level checks is the relationship between:

Kubelet
+
Container Runtime
+
cgroup Driver

Kubernetes documents that the kubelet and container runtime must use compatible cgroup-driver configuration. The systemd driver is recommended when using cgroup v2.

Check the node:

stat -fc %T /sys/fs/cgroup/

For cgroup v2, Kubernetes documents:

cgroup2fs

For cgroup v1:

tmpfs

Kubernetes has deprecated cgroup v1, and kubelet does not start on cgroup-v1 nodes by default unless the administrator explicitly changes the failCgroupV1 setting.

For an upgrade, this should be a node-inventory check rather than something discovered after a reboot.

Check the Container Runtime Before Upgrading

Inspect the runtime:

kubectl get nodes \
  -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion

For containerd, inspect:

containerd --version

and:

sudo grep -n "SystemdCgroup" \
  /etc/containerd/config.toml

Kubernetes documentation distinguishes the configuration structure for containerd 1.x and 2.x and recommends matching the runtime and kubelet cgroup-driver configuration.

Do not assume that every node in the cluster has identical runtime configuration.

Mixed node pools are common in long-lived clusters.

Risk 2: cgroup v1 Nodes

A cluster can appear healthy while containing old nodes.

That becomes dangerous during an upgrade.

Suppose:

Node A → cgroup v2
Node B → cgroup v2
Node C → cgroup v1

The cluster may operate normally until Node C is rebooted or replaced.

A Kubernetes upgrade is exactly the kind of event that can expose this configuration drift.

Find affected nodes before upgrading:

kubectl get nodes -o wide

Then inspect each Linux node:

stat -fc %T /sys/fs/cgroup/

Do not rely only on the control-plane version.

Risk 3: .NET Pods Will Restart

A Kubernetes node upgrade normally involves draining and rescheduling workloads.

For kubeadm upgrades, Kubernetes documents that containers are restarted after an upgrade because the container specification hash changes.

For an ASP.NET Core application:

Pod
 ↓
SIGTERM / shutdown
 ↓
Application stops
 ↓
Pod terminates
 ↓
New Pod starts
 ↓
Readiness probe passes
 ↓
Traffic resumes

Your application therefore needs to handle startup and shutdown correctly.

Risk 4: ASP.NET Core Graceful Shutdown

ASP.NET Core provides host lifecycle mechanisms for graceful shutdown.

The .NET Generic Host listens for termination signals through ConsoleLifetime, allowing the application to begin a graceful shutdown. During shutdown, the host stops accepting new connections and allows existing requests to complete within the configured shutdown period.

This matters when Kubernetes drains a node.

A service should not assume that:

Pod termination
=
instant process termination

Instead, test the complete lifecycle.

For example:

Request in progress
        ↓
Pod receives termination
        ↓
Application begins shutdown
        ↓
Existing request completes
        ↓
Process exits

.NET 10 Adds Another Shutdown Consideration

.NET 10 changed the default runtime behavior around Unix termination signals. The runtime itself no longer installs the previous default SIGTERM handler.

Microsoft notes that typical ASP.NET Core applications do not require action because higher-level hosting APIs such as ConsoleLifetime handle application-model-specific termination behavior.

This creates an important upgrade-testing rule:

Test the actual application entry point, not an isolated console process.

If your service uses custom process-level signal handling, verify that behavior explicitly.

Risk 5: Readiness and Liveness Probes

A Kubernetes upgrade can restart pods faster than a poorly configured application can become ready.

Consider:

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080

and:

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080

These should not necessarily perform the same checks.

Microsoft recommends separating readiness and liveness semantics in ASP.NET Core. Readiness indicates whether the application can receive requests, while liveness indicates whether the application is functioning sufficiently to avoid being restarted.

A useful model is:

/health/live
    ↓
"Is the process functioning?"

/health/ready
    ↓
"Can this instance receive traffic?"

Avoid Using Database Health for Liveness

A common configuration is:

Liveness
    ↓
Database check
    ↓
Database unavailable
    ↓
Restart application

This can create a restart loop.

If the database is temporarily unavailable, restarting every application replica can make the incident worse.

Instead:

Liveness
    ↓
Process/application health

Readiness
    ↓
Can this instance serve requests?

The exact dependency checks should be based on your architecture.

Risk 6: Startup Time

.NET services may perform significant startup work:

Configuration
Database migration checks
Cache initialization
Certificate loading
Dependency discovery
Message-broker connection

If the readiness probe starts too early:

Pod starts
 ↓
Readiness fails
 ↓
Traffic delayed

That may be acceptable.

But if liveness is also configured too aggressively:

Pod starts
 ↓
Liveness fails
 ↓
Pod restarts
 ↓
Startup repeats

you can create a restart loop.

ASP.NET Core documentation demonstrates using separate readiness and liveness checks specifically for applications with long-running startup work.

Risk 7: Pod Disruption During Node Upgrades

Before upgrading nodes, inspect:

kubectl get pods -A

and:

kubectl get pdb -A

PodDisruptionBudgets can limit how many replicas are voluntarily disrupted at once.

For a .NET API with:

3 replicas

a sensible disruption policy may allow one replica to be unavailable while the others continue serving traffic.

The exact configuration depends on your availability requirements.

The important point is to verify that:

Node drain
+
PDB
+
Replica count

do not create an impossible scheduling situation.

Risk 8: Single-Replica .NET Services

A deployment such as:

replicas: 1

is especially sensitive to node upgrades.

During a node drain:

Replica
   ↓
Terminated
   ↓
Rescheduled
   ↓
Startup

There can be a period with no available instance.

For critical services, evaluate whether multiple replicas are required.

Do not confuse Kubernetes availability with application availability.

A Kubernetes deployment can be healthy while the application has zero ready replicas.

Risk 9: Resource Requests and Limits

Node upgrades change scheduling conditions.

Suppose your application requests:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"

and limits:

resources:
  limits:
    cpu: "1"
    memory: "1Gi"

During a rolling node upgrade, replacement capacity must exist for these requests.

If the remaining nodes do not have sufficient allocatable capacity:

Drain node
   ↓
Pod pending
   ↓
No capacity

The application may become unavailable.

Check:

kubectl describe nodes

and inspect:

Allocatable
Requested
Allocated

before starting the upgrade.

Risk 10: .NET Memory Behavior

.NET applications can be sensitive to container memory limits.

A service may appear healthy under normal traffic but fail after rescheduling onto a node with different resource pressure.

Monitor:

Working set
GC heap
GC pauses
Container memory
OOMKilled events

Check recent events:

kubectl get events \
  --sort-by=.lastTimestamp

Also inspect pod status:

kubectl describe pod <pod-name>

Look for:

OOMKilled
Evicted
BackOff
Unhealthy
FailedScheduling

Do not increase memory limits automatically after an upgrade without identifying the actual cause.

Risk 11: ASP.NET Core Container Port Changes

Containerized ASP.NET Core applications should have explicit port configuration.

.NET 8 changed the default ASP.NET Core container port from 80 to 8080. Microsoft documents that Kubernetes manifests and other container configurations may need to account for this change.

For example:

containers:
  - name: api
    image: my-api:latest
    ports:
      - containerPort: 8080

A Kubernetes upgrade is not itself responsible for this .NET change, but upgrade testing is a good opportunity to detect stale manifests.

Verify:

Container port
Service targetPort
Probe port
Ingress/backend port
Application listening address

all agree.

Risk 12: API Deprecations and Removed APIs

Minor Kubernetes releases can deprecate APIs and remove functionality.

Kubernetes documents that deprecated APIs continue to function until their planned removal, while removed APIs are no longer available in the newer version.

This is particularly important for:

Helm charts
Operators
Admission controllers
Ingress controllers
Monitoring agents
CI/CD tools
Custom controllers

The .NET application may be completely correct while its deployment tooling is incompatible.

Audit Manifests Before the Upgrade

Search your repositories:

grep -R \
  "apiVersion:" \
  ./k8s

Also inspect Helm templates:

helm template ./chart

Then validate the generated manifests against the target cluster.

Do not inspect only the application's Deployment.

Check:

Deployment
Service
Ingress
ConfigMap
Secret
HPA
PDB
NetworkPolicy
ServiceAccount
RBAC
CronJob

Risk 13: Ingress and Gateway Dependencies

A .NET API may be healthy while external traffic fails because the ingress or gateway layer is incompatible.

Test:

Internet
   ↓
Load Balancer
   ↓
Ingress / Gateway
   ↓
Service
   ↓
Pod
   ↓
ASP.NET Core

After the upgrade, verify:

kubectl get ingress -A

and:

kubectl get svc -A

For modern deployments, also inspect Gateway API resources where applicable.

Do not test only:

curl localhost:8080

That verifies the application but not the production traffic path.

Risk 14: DNS and Service Discovery

A distributed .NET application may depend heavily on Kubernetes DNS:

orders-api
payments-api
identity-api

Test internal connectivity after node upgrades:

kubectl exec \
  <pod-name> \
  -- getent hosts orders-api

Then test the actual service endpoint.

A healthy pod does not guarantee that:

DNS
+
Service
+
Network Policy

are functioning correctly.

Risk 15: Network Policies

If your .NET services use NetworkPolicies, test both:

Allowed traffic

and:

Denied traffic

For example:

API
 ↓
Database

should remain allowed.

But:

Unknown namespace
 ↓
Database

should remain blocked.

Upgrade validation should confirm that security boundaries did not change unintentionally.

Build an Upgrade Test Environment

A practical sequence is:

Development
    ↓
Upgrade test cluster
    ↓
Staging
    ↓
Canary production nodes
    ↓
Full production rollout

Do not use production as the first place where the cluster encounters Kubernetes 1.37.

A representative staging cluster should include:

Same .NET runtime
Same container image
Same probes
Same ingress
Same runtime configuration
Same monitoring
Same policies

as production.

Test a Real .NET Workload

A basic smoke test is:

curl https://api.example.com/health/ready

Then exercise:

GET
POST
Authentication
Database access
External API calls
Background jobs
Message queues
File/storage operations

The exact tests should match your service.

Test Rolling Restarts

Before upgrading Kubernetes, simulate the event:

kubectl rollout restart deployment my-api

Observe:

kubectl rollout status deployment my-api

Then inspect:

kubectl get pods -w

You want to confirm:

Old pod
   ↓
Not ready
   ↓
New pod ready
   ↓
Old pod terminated

without unacceptable request failures.

Test Node Drain

A more realistic test is:

kubectl drain <node-name> \
  --ignore-daemonsets \
  --delete-emptydir-data

Do this only in an appropriate test environment and according to your cluster's operational procedures.

Observe:

Pod eviction
Rescheduling
Readiness
Application startup
Request failures
PDB behavior

This closely approximates what happens during node maintenance.

Monitor the .NET Application During the Test

Watch:

kubectl top pods

and:

kubectl get pods -w

Also inspect application telemetry:

Request rate
Error rate
P95 latency
P99 latency
GC behavior
Database latency
Dependency failures

The goal is not merely:

kubectl get nodes
→ Ready

A cluster can be green while the application is experiencing elevated latency.

Validate Graceful Shutdown

Create a long-running test endpoint:

app.MapGet(
    "/test/slow",
    async (CancellationToken cancellationToken) =>
    {
        await Task.Delay(
            TimeSpan.FromSeconds(10),
            cancellationToken);

        return Results.Ok();
    });

Then send a request while terminating the pod.

Observe whether the request:

Completes gracefully

or:

Gets terminated unexpectedly

Do not use an artificial endpoint in production. This is strictly for controlled testing.

Validate Background Services

If the .NET application uses:

BackgroundService

test shutdown behavior separately.

ASP.NET Core invokes StopAsync during graceful host shutdown and provides a cancellation token to allow background operations to stop. Microsoft documents a default shutdown timeout and recommends that remaining operations respond promptly when cancellation is requested.

A node upgrade is therefore also a test of:

Queue consumers
Schedulers
Background workers
Message processing

Protect Against Duplicate Processing

Suppose a background worker receives:

Message 123

and the pod is terminated during processing.

Your system should have an explicit delivery strategy:

At-most-once
At-least-once
Exactly-once semantics where actually supported

Do not assume Kubernetes termination automatically prevents duplicate processing.

For critical workloads, design application-level idempotency.

Upgrade One Node Pool at a Time

For production clusters with multiple node pools:

Pool A
Pool B
Pool C

do not upgrade everything simultaneously.

A safer operational sequence is:

Pool A
   ↓
Validate
   ↓
Pool B
   ↓
Validate
   ↓
Pool C

The exact sequence depends on the cluster architecture and managed-Kubernetes provider.

Maintain a Rollback Strategy

Before upgrading, define:

What happens if node upgrade fails?
What happens if pods cannot schedule?
What happens if ingress breaks?
What happens if the .NET service fails?
How will traffic be shifted?
How will nodes be replaced?

Do not assume "rollback" means simply changing:

1.37 → 1.36

Kubernetes version rollback procedures can have constraints depending on the upgrade stage and cluster management platform.

For node-level problems, replacing unhealthy nodes with known-good images may be safer than attempting an ad-hoc downgrade.

Kubernetes 1.36 to 1.37 Preflight Checklist

Use this checklist before production rollout:

Area	Check
Kubernetes	Current patch release
Target	1.37 release status
Nodes	All Ready
cgroups	cgroup v2 where required
Runtime	Supported and consistent
Kubelet	Version compatibility
CNI	Supported configuration
CSI	Supported configuration
Ingress	Supported controller/version
APIs	Deprecated/removed API audit
PDB	Disruption behavior
Replicas	Sufficient capacity
Probes	Readiness/liveness validated
Shutdown	Graceful termination tested
Resources	Scheduling capacity verified
.NET	Runtime/container compatibility
Observability	Metrics/logs/traces working
Backup	etcd/data backups verified
Rollback	Operational plan documented

Common Mistakes

Upgrading the Control Plane First and Ignoring Nodes

The entire cluster lifecycle needs to be planned.

Checking Only Kubernetes Version

A healthy control plane does not prove that every node is ready.

Ignoring cgroup Configuration

Old node images can become upgrade blockers.

Treating Readiness and Liveness as the Same Thing

They serve different purposes in ASP.NET Core and Kubernetes.

Using a Database Check for Liveness

A dependency outage can turn into application restart loops.

Running One Replica

Node maintenance can temporarily eliminate service capacity.

Ignoring PDB Configuration

Disruption policies can prevent or complicate node drains.

Forgetting Background Workers

A restarted pod can interrupt message processing.

Testing Only `/health`

Health checks do not validate the complete application path.

Assuming `Ready` Means Production Is Healthy

Check application-level telemetry after the upgrade.

Troubleshooting

Pod Stays Pending After Node Upgrade

Check:

kubectl describe pod <pod-name>

Look for:

Insufficient CPU
Insufficient memory
Taints
Affinity
Node selectors
PDB constraints

Node Becomes NotReady

Inspect:

kubectl describe node <node-name>

Then check:

journalctl -u kubelet

and:

systemctl status containerd

for containerd-based nodes.

.NET Pod Keeps Restarting

Check:

kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous

Look for:

OOMKilled
Probe failures
Startup exceptions
Configuration errors
Port mismatch
Dependency failures

Readiness Probe Fails After Upgrade

Verify:

Application listening port
Service targetPort
Probe port
Health endpoint
Network policy
Startup duration

For .NET 8+ container images, remember that the default ASP.NET Core container port changed to 8080 unless explicitly configured otherwise.

Application Receives Traffic Before It Is Ready

Review the readiness probe.

ASP.NET Core supports separate readiness and liveness checks specifically so Kubernetes can avoid sending traffic to an application that is running but not yet ready.

Best Practices

Treat Kubernetes 1.37 as an infrastructure change, not merely a version change.
Upgrade one minor version at a time.
Use the latest supported patch release before upgrading.
Audit every worker node before the upgrade.
Verify cgroup configuration.
Verify container runtime compatibility.
Keep kubelet and kubeadm versions within supported skew.
Test node drains before production.
Maintain sufficient replica capacity.
Review PodDisruptionBudgets.
Separate readiness and liveness checks.
Test ASP.NET Core graceful shutdown.
Test background worker shutdown.
Validate database and message-processing behavior.
Audit Kubernetes API deprecations.
Test ingress and Gateway traffic.
Test NetworkPolicies.
Verify resource capacity for rescheduling.
Monitor application-level SLOs during rollout.
Use staged or canary node upgrades where possible.

Frequently Asked Questions

Is Kubernetes 1.37 released?

Not yet at the time of writing. The official Kubernetes release schedule currently targets August 26, 2026 for Kubernetes 1.37.0.

Can I skip Kubernetes 1.36 and upgrade directly to 1.37?

For kubeadm upgrades, skipping minor versions is unsupported. The official upgrade documentation recommends upgrading one minor version at a time.

Will my .NET application need code changes?

Not necessarily.

Many upgrade risks are operational rather than C#-level changes. However, applications with custom signal handling, fragile probes, single replicas, background workers, or strict runtime assumptions should be tested carefully.

Why are cgroups important?

Kubernetes and the container runtime use cgroups for resource management. Kubernetes has deprecated cgroup v1, and kubelet behavior requires particular attention on older nodes.

Should I upgrade containerd separately?

That depends on your Kubernetes distribution and supported runtime versions. Check the runtime requirements for the exact Kubernetes version and distribution you operate rather than assuming a runtime upgrade is automatically required.

What should my ASP.NET Core readiness probe check?

It should answer whether the application is ready to receive traffic.

For example:

Application initialized
Required configuration loaded
Critical dependencies available

The exact checks depend on the service.

Should liveness check the database?

Usually, avoid making liveness dependent on a database or other external dependency unless there is a specific architectural reason.

A temporary dependency outage should not automatically cause Kubernetes to restart every application instance.

How do I test whether a .NET service survives node upgrades?

Start with:

Pod restart
    ↓
Node drain
    ↓
Staged node upgrade
    ↓
Application telemetry

Verify request continuity, startup, readiness, graceful shutdown, background processing, and dependency connectivity.

What is the biggest upgrade risk?

There is no universal single risk.

For older self-managed clusters, node/runtime and cgroup compatibility can be critical. For .NET workloads, application lifecycle behavior—especially probes, shutdown, startup, and resource capacity—can determine whether a technically successful cluster upgrade becomes a successful application upgrade.

Conclusion

A Kubernetes minor upgrade is successful only when both the platform and its workloads remain healthy.

For a .NET service, the relevant upgrade path is:

Kubernetes 1.36
      ↓
Node/runtime validation
      ↓
Kubernetes 1.37 testing
      ↓
.NET lifecycle testing
      ↓
Node drain testing
      ↓
Staged rollout
      ↓
Application validation
      ↓
Production

The most important preparation is not changing the Kubernetes version in a configuration file.

It is identifying what your application assumes about its environment.

Check:

cgroups
container runtime
kubelet
resource capacity
probes
shutdown
startup
PDBs
replicas
ingress
network policies
background workers
API compatibility

Kubernetes 1.37 is currently scheduled for August 26, 2026, giving teams a useful pre-release window to test representative workloads before production adoption.

For .NET services, the upgrade should ultimately be evaluated at two levels:

Platform health
+
Application health

A cluster showing:

Nodes = Ready

is necessary, but it is not sufficient.

The real success criteria are:

Requests continue
Pods become Ready
Existing requests drain correctly
Background work behaves correctly
Dependencies remain reachable
No unexpected OOMs occur
Latency remains within SLO
Error rate remains acceptable

The key principle is:

Do not upgrade Kubernetes first and discover application compatibility afterward. Validate the infrastructure assumptions of your .NET services before the upgrade.

That approach turns Kubernetes 1.37 from a risky version change into a controlled infrastructure migration.

What Changes During a Kubernetes Upgrade?

First Risk: Kubernetes 1.37 Is a Pre-Release Planning Target

Risk 1: Container Runtime and cgroup Compatibility

Check the Container Runtime Before Upgrading

Risk 2: cgroup v1 Nodes

Risk 3: .NET Pods Will Restart

Risk 4: ASP.NET Core Graceful Shutdown

.NET 10 Adds Another Shutdown Consideration

Risk 5: Readiness and Liveness Probes

Avoid Using Database Health for Liveness

Risk 6: Startup Time

Risk 7: Pod Disruption During Node Upgrades

Risk 8: Single-Replica .NET Services

Risk 9: Resource Requests and Limits

Risk 10: .NET Memory Behavior

Risk 11: ASP.NET Core Container Port Changes

Risk 12: API Deprecations and Removed APIs

Audit Manifests Before the Upgrade

Risk 13: Ingress and Gateway Dependencies

Risk 14: DNS and Service Discovery

Risk 15: Network Policies

Build an Upgrade Test Environment

Test a Real .NET Workload

Test Rolling Restarts

Test Node Drain

Monitor the .NET Application During the Test

Validate Graceful Shutdown

Validate Background Services

Protect Against Duplicate Processing

Upgrade One Node Pool at a Time

Maintain a Rollback Strategy

Kubernetes 1.36 to 1.37 Preflight Checklist

Common Mistakes

Upgrading the Control Plane First and Ignoring Nodes

Checking Only Kubernetes Version

Ignoring cgroup Configuration

Treating Readiness and Liveness as the Same Thing

Using a Database Check for Liveness

Running One Replica

Ignoring PDB Configuration

Forgetting Background Workers

Testing Only /health

Assuming Ready Means Production Is Healthy

Troubleshooting

Pod Stays Pending After Node Upgrade

Node Becomes NotReady

.NET Pod Keeps Restarting

Readiness Probe Fails After Upgrade

Application Receives Traffic Before It Is Ready

Best Practices

Frequently Asked Questions

Is Kubernetes 1.37 released?

Can I skip Kubernetes 1.36 and upgrade directly to 1.37?

Will my .NET application need code changes?

Why are cgroups important?

Should I upgrade containerd separately?

What should my ASP.NET Core readiness probe check?

Should liveness check the database?

How do I test whether a .NET service survives node upgrades?

What is the biggest upgrade risk?

Conclusion

Testing Only `/health`

Assuming `Ready` Means Production Is Healthy