Kubernetes 1.34 Maintenance Mode: Preparing .NET Workloads for Upgrade

Kubernetes upgrades are rarely difficult because of the version number itself.

The difficult part is everything running around the cluster.

A production .NET application may depend on Kubernetes Deployments, Services, Ingress controllers, ConfigMaps, Secrets, persistent storage, autoscaling, admission policies, container runtimes, observability agents, and third-party operators. An upgrade can therefore affect much more than the Kubernetes API server.

This matters now for teams running Kubernetes 1.34.

The Kubernetes project currently lists 1.34 as actively supported, with the 1.34.9 patch release dated June 9, 2026. Kubernetes 1.34 enters maintenance mode on August 27, 2026, followed by end of life on October 27, 2026. The currently supported release lines also include Kubernetes 1.35 and 1.36.

That creates a practical upgrade window for platform teams.

For .NET developers, the important question is not simply "How do I upgrade Kubernetes?"

It is:

How do I verify that my .NET workloads, manifests, controllers, networking, storage, and deployment pipeline will continue working after the cluster upgrade?

What Maintenance Mode Means for Kubernetes 1.34

Kubernetes maintains the three most recent minor releases. The current supported lines are 1.34, 1.35, and 1.36.

For Kubernetes 1.34, the timeline is:

Milestone	Date
Kubernetes 1.34 release	August 27, 2025
Latest listed patch	1.34.9
Maintenance mode	August 27, 2026
End of life	October 27, 2026

During maintenance mode, the release branch receives a narrower class of fixes. Kubernetes documentation describes maintenance mode as the final two months of the support period, when critical security and dependency-related fixes can still be produced before the branch reaches EOL.

The practical implication is straightforward:

Do not plan a major production upgrade after October 27, 2026 if you can avoid it.

Which Kubernetes Version Should You Upgrade To?

Kubernetes 1.36 is currently the newest supported minor release, while 1.35 is also supported. The official release schedule lists 1.36 with an EOL date of June 28, 2027 and 1.35 with an EOL date of February 28, 2027.

Therefore, a team currently running 1.34 should evaluate both its platform compatibility and its organization's upgrade policy before selecting the destination version.

A simple decision matrix is:

Current	Candidate	Consideration
1.34	1.35	Smaller version jump
1.34	1.36	Longer supported lifecycle
1.34	Managed provider-supported version	Check provider's upgrade policy

The newest supported version is not automatically the correct choice for every organization.

The right target depends on:

Cloud provider support
CNI compatibility
CSI/storage drivers
Ingress controller
Operators
Admission webhooks
Monitoring agents
Deployment tooling
Internal platform standards

Why .NET Applications Need Specific Testing

A .NET application itself is usually not tightly coupled to the Kubernetes API server.

For example, this container:

FROM mcr.microsoft.com/dotnet/aspnet:10.0

WORKDIR /app

COPY ./publish .

ENTRYPOINT ["dotnet", "Orders.Api.dll"]

can continue running without modification after a Kubernetes upgrade.

The risk is generally around the Kubernetes resources and infrastructure surrounding the container.

For example:

.NET Application
       |
       v
Deployment
       |
       +--> Service
       |
       +--> ConfigMap
       |
       +--> Secret
       |
       +--> Ingress
       |
       +--> HPA
       |
       +--> PersistentVolume
       |
       +--> Service Account
       |
       +--> NetworkPolicy

Each layer should be included in the upgrade test.

Step 1: Inventory the Current Cluster

Before changing anything, record what is actually running.

Start with:

kubectl version

Then:

kubectl get nodes -o wide

Check namespaces:

kubectl get namespaces

List workloads:

kubectl get deployments,statefulsets,daemonsets -A

Check services:

kubectl get services -A

Check ingress resources:

kubectl get ingress -A

For .NET applications, also identify:

Container image
.NET runtime version
Deployment replicas
Resource requests
Resource limits
Probes
ConfigMaps
Secrets
Service accounts
HPA configuration
Persistent storage
Network policies

This inventory becomes your upgrade checklist.

Step 2: Check Deprecated APIs

One of the most important upgrade tasks is finding deprecated Kubernetes APIs.

Kubernetes provides a deprecation policy and migration guidance for APIs that are eventually removed. The project recommends using client warnings, metrics, and audit information to locate deprecated API usage.

Start by inspecting your manifests:

kubectl api-resources

Then search your source repositories for old API versions:

grep -R "apiVersion:" ./k8s

For example, review manifests containing:

apiVersion: extensions/v1beta1

or other deprecated versions.

The exact deprecated APIs depend on the Kubernetes version path you are upgrading across, so do not assume that every old-looking API is necessarily removed in your target version.

The important rule is:

Check the Kubernetes deprecation guide for your destination version instead of relying on memory.

Step 3: Test Manifests Before the Upgrade

Your deployment YAML should be validated before it reaches the production cluster.

For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: orders-api
  template:
    metadata:
      labels:
        app: orders-api
    spec:
      containers:
        - name: orders-api
          image: example/orders-api:1.8.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"

For a .NET application, resource configuration deserves particular attention.

A Kubernetes upgrade can change scheduling conditions, node availability, or resource distribution. The application may be perfectly compatible with the new Kubernetes version but still behave differently if the workload is scheduled differently.

Step 4: Verify .NET Health Probes

ASP.NET Core applications commonly expose health endpoints.

For example:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks();

var app = builder.Build();

app.MapHealthChecks("/health");

app.Run();

Then configure Kubernetes:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

During the upgrade, watch whether probes continue behaving as expected.

A temporary increase in startup latency can cause a poorly configured probe to restart a healthy .NET application repeatedly.

Step 5: Review Resource Requests and Limits

A common deployment configuration is:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

These values should be based on observed workload behavior rather than copied blindly between applications.

For a .NET API, monitor:

CPU utilization
Working set
Garbage collection
Request latency
Pod restarts
OOM kills
CPU throttling

Before and after the upgrade, compare the same workload.

Do not interpret a different CPU profile automatically as a Kubernetes regression. Node images, runtime versions, container runtime behavior, and workload placement can also influence the result.

Step 6: Verify Autoscaling

If your .NET service uses an HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: orders-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: orders-api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Check:

kubectl get hpa -A

Then:

kubectl describe hpa orders-api

During testing, verify:

Traffic
   |
   v
CPU / Metrics
   |
   v
HPA
   |
   v
Replica Count

The objective is not simply confirming that the HPA object exists.

Confirm that it still reacts correctly to load.

Step 7: Check Ingress and Networking

A .NET API can be healthy inside the cluster while external traffic is broken.

Test the complete path:

Internet
   |
   v
Load Balancer
   |
   v
Ingress
   |
   v
Service
   |
   v
.NET Pods

Check:

kubectl get ingress -A
kubectl get svc -A
kubectl get endpointslices -A

EndpointSlices are particularly important when applications or custom controllers interact directly with endpoint information. Kubernetes has been moving away from the older Endpoints API toward EndpointSlices.

Do not assume that an ingress controller, CNI plugin, or cloud load balancer is automatically compatible simply because the Kubernetes API server upgraded successfully.

Check the vendor's supported Kubernetes versions.

Step 8: Check Storage

If your .NET application uses persistent storage, identify:

kubectl get storageclass
kubectl get pv
kubectl get pvc -A

Then verify:

CSI driver version
StorageClass behavior
Volume attachment
Mount operations
Read/write behavior
Pod rescheduling
Stateful workloads

For example:

.NET Worker
    |
    v
PersistentVolumeClaim
    |
    v
CSI Driver
    |
    v
Cloud / Storage Backend

The Kubernetes upgrade is only one component of this chain.

Step 9: Check Admission Webhooks and Operators

This is an area that is easy to overlook.

Many production clusters use:

Policy engines
Security agents
Certificate managers
Service meshes
Database operators
Autoscaling operators
Custom controllers

List them:

kubectl get crd

and:

kubectl get mutatingwebhookconfigurations
kubectl get validatingwebhookconfigurations

A third-party controller can fail even when your .NET Deployment is completely valid.

Before the upgrade, verify that each critical operator supports the target Kubernetes version.

Step 10: Upgrade a Non-Production Cluster First

The safest sequence is:

Production 1.34
      |
      v
Clone / Reproduce Workload
      |
      v
Test Cluster
      |
      v
Target Kubernetes Version
      |
      v
Functional Tests
      |
      v
Load Tests
      |
      v
Production Upgrade

Do not make production the first place where you discover a deprecated API or incompatible admission webhook.

For kubeadm-based environments, Kubernetes documentation describes the general process as upgrading the control plane, upgrading nodes, updating clients, and adjusting manifests where required.

Managed Kubernetes services will have provider-specific procedures, so follow the provider's documented upgrade workflow rather than directly applying kubeadm instructions to a managed cluster.

Step 11: Test the .NET Application End to End

A useful test matrix looks like this:

Test	Expected Result
Application startup	Pods become Ready
Health endpoint	HTTP 200
API requests	Successful
Database connectivity	Successful
Redis/cache	Successful
Message queue	Successful
Authentication	Successful
External API calls	Successful
Background workers	Processing normally
HPA	Scales correctly
Rolling deployment	No unexpected outage
Pod rescheduling	Application recovers
Node drain	Workload remains available

For a production API, test both normal traffic and failure scenarios.

Step 12: Test Node Draining

Kubernetes upgrades often involve node replacement or maintenance.

Test:

kubectl drain <node> --ignore-daemonsets

Then observe the .NET workload.

For example:

kubectl get pods -o wide

Verify that pods are recreated on other nodes.

After maintenance:

kubectl uncordon <node>

Kubernetes' upgrade documentation uses node draining and uncordoning as part of the node upgrade process.

This is particularly important for applications with strict availability requirements.

Step 13: Validate Deployment Strategies

A production Deployment should normally have an explicit rollout strategy.

For example:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Then:

kubectl rollout status deployment/orders-api

And:

kubectl rollout history deployment/orders-api

The Kubernetes version upgrade and application deployment should be treated as separate changes where possible.

Avoid combining:

Kubernetes upgrade
+
.NET runtime upgrade
+
Application release
+
Database migration

into one uncontrolled deployment.

If something breaks, diagnosis becomes much harder.

Kubernetes Upgrade vs .NET Runtime Upgrade

These are separate concerns.

Change	Example
Kubernetes upgrade	1.34 → 1.36
.NET upgrade	.NET 9 → .NET 10
Base image upgrade	New ASP.NET Core container
Application release	API version 2.5
Database upgrade	PostgreSQL version change

If the goal is to evaluate Kubernetes compatibility, keep the .NET application unchanged initially.

Once the cluster upgrade is proven, perform the runtime or application upgrade separately.

This gives you a much cleaner failure boundary.

Version Skew Matters

Kubernetes does not require every component to be upgraded simultaneously.

The project defines version-skew policies describing which versions of components can operate together. Your upgrade procedure should therefore account for:

API server
kubelet
kubectl
kube-proxy
control-plane components
cloud-provider components
cluster add-ons

Do not assume that "the cluster version" is one binary.

It is a collection of components with compatibility relationships.

Monitor the Upgrade

During the upgrade, monitor:

kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp

For a specific .NET deployment:

kubectl rollout status deployment/orders-api
kubectl get pods -l app=orders-api

Check logs:

kubectl logs deployment/orders-api

And inspect unhealthy pods:

kubectl describe pod <pod-name>

Application-level observability should also remain active.

Monitor:

HTTP 5xx rate
Request latency
Throughput
Pod restarts
CPU
Memory
Database latency
Queue depth
Error rate

The most important metric is not whether kubectl get nodes says Ready.

It is whether the application continues serving its business workload correctly.

Rollback Planning

Before upgrading, define the rollback strategy.

For example:

Upgrade
   |
   v
Validation
   |
   +---- Healthy ---> Continue
   |
   +---- Unhealthy
             |
             v
        Stop rollout
             |
             v
       Restore service

Kubernetes documentation notes that upgrade rollback has constraints, especially around API and storage-version changes. Kubernetes' API policy is designed to preserve upgrade and rollback compatibility within its supported version-skew expectations, but applications should not assume that every cluster change is trivially reversible.

Therefore, backup and recovery plans should be tested before the production upgrade.

Common Mistakes

Waiting Until EOL

Maintenance mode is a warning window, not a deadline you should intentionally target.

Kubernetes 1.34 reaches EOL on October 27, 2026.

Testing Only the API Server

A successful control-plane upgrade does not prove that ingress, storage, operators, or .NET applications work correctly.

Upgrading Everything at Once

Avoid combining Kubernetes, .NET, database, and application changes unless there is a strong reason.

Ignoring Deprecated APIs

Deprecated APIs may continue working today but can become unavailable after a future upgrade.

Forgetting Operators

Third-party controllers can be more upgrade-sensitive than ordinary Deployments.

Testing Only Startup

A pod reaching Running does not mean the application is healthy.

Skipping Node Drain Tests

A workload may appear healthy until a node is removed.

Assuming the Newest Version Is Always Best

Kubernetes 1.36 is currently the newest supported minor release, but target-version selection should consider the entire platform ecosystem and organizational upgrade policy.

Troubleshooting Upgrade Failures

Pods remain Pending

Check:

kubectl describe pod <pod-name>

Look for:

Insufficient CPU
Insufficient memory
Node selectors
Taints and tolerations
Affinity rules
Storage constraints

Pods repeatedly restart

Check:

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

For .NET applications, inspect:

Startup exceptions
Configuration
Secrets
Connection strings
Health probes
Environment variables

Ingress returns 404 or 502

Check:

kubectl get ingress
kubectl get svc
kubectl get endpointslices

Then inspect the ingress controller logs.

HPA does not scale

Check:

kubectl describe hpa <name>

Verify that the metrics pipeline and resource requests are correctly configured.

Deployment fails validation

Check the manifest's apiVersion and compare it with the destination Kubernetes API reference and deprecation guide. Kubernetes explicitly recommends migrating workloads and integrations away from deprecated APIs before they are removed.

A Practical Upgrade Checklist

Record the current Kubernetes version.
Inventory .NET workloads and cluster dependencies.
Identify deprecated API usage.
Check the compatibility of CNI and CSI components.
Check ingress controller compatibility.
Check operators and admission webhooks.
Create a representative non-production environment.
Upgrade the test cluster first.
Run .NET functional tests.
Run application load tests.
Test HPA behavior.
Test node draining and pod rescheduling.
Verify storage and external integrations.
Document rollback and recovery procedures.
Upgrade production using the provider-supported process.
Monitor application and infrastructure metrics during rollout.

Conclusion

Kubernetes 1.34 is approaching an important lifecycle milestone. The official schedule places it into maintenance mode on August 27, 2026, with end of life on October 27, 2026. Kubernetes 1.35 and 1.36 are also supported, with 1.36 currently offering the longest remaining lifecycle among the three supported minor releases.

For .NET teams, the upgrade should not be treated as a simple control-plane operation.

The real work is validating the complete application platform:

Kubernetes
   |
   +--> .NET Containers
   +--> Deployments
   +--> Services
   +--> Ingress
   +--> HPA
   +--> Storage
   +--> Networking
   +--> Operators
   +--> Security Policies
   +--> Observability

The safest approach is to inventory first, identify deprecated APIs, test the target version in isolation, validate the .NET workload under realistic traffic, test node replacement, and only then move toward production.

The key lesson is simple:

Do not wait for Kubernetes 1.34 to reach EOL before starting the upgrade. Use the maintenance window to prove that your .NET platform is ready for the next supported release.

Frequently Asked Questions

When does Kubernetes 1.34 enter maintenance mode?

Kubernetes 1.34 enters maintenance mode on August 27, 2026, and reaches end of life on October 27, 2026.

Should I upgrade from Kubernetes 1.34 directly to 1.36?

It can be a valid target, but the decision should depend on your platform's compatibility requirements and upgrade policy. Kubernetes 1.36 is currently supported and has a later EOL date than 1.35.

Will a Kubernetes upgrade require changes to my .NET code?

Not necessarily. A compatible .NET container can often continue running without application-code changes. The greater upgrade risk is frequently in Kubernetes manifests, networking, storage, operators, admission webhooks, and infrastructure dependencies.

How should I test a .NET application before the upgrade?

Run functional tests, API tests, database tests, background-worker tests, health checks, load tests, scaling tests, and node-drain/rescheduling tests against a non-production cluster running the target Kubernetes version.

How do I find deprecated Kubernetes APIs?

Use Kubernetes client warnings, metrics, audit information, manifest inspection, and the official deprecation and migration guides. Kubernetes recommends identifying deprecated API usage before the replacement version removes it.

Is Kubernetes 1.36 currently supported?

Yes. The official Kubernetes release schedule currently lists 1.36 as actively supported, with EOL on June 28, 2027.