Running .NET on Azure Kubernetes Service (AKS): A Production Support Guide

Why AKS needs deliberate production support

Azure Kubernetes Service is often sold on how much it manages for you, and it does manage a great deal: the control plane, much of the upgrade machinery, and integration with the rest of Azure. That is real, and it is why AKS is a sensible platform for .NET workloads.

But “managed control plane” is not “managed application”. Everything above the control plane remains your responsibility: your workloads, your scaling configuration, your security posture, your observability, and your costs. Kubernetes is powerful because it is flexible, and flexible systems fail in flexible ways. A misconfigured resource limit, a missed upgrade, or an unbounded autoscaler can each take a system down.

Running AKS well in production is therefore a set of continuous workstreams rather than a one-time deployment. The rest of this guide walks through them.

The workstreams of running AKS

Cluster and node management

An AKS cluster is organised into node pools, groups of virtual machines that run your pods. Supporting the cluster means keeping those nodes healthy and patched, sizing pools to the workload, and separating workloads sensibly (for example, a system node pool for platform components and user pools for applications). Node images receive regular security updates that need to be applied.

Scaling

AKS scales at two levels, and both need configuring:

• The Horizontal Pod Autoscaler adds or removes pod replicas based on metrics such as processor use.
• The Cluster Autoscaler adds or removes nodes so there is room for those pods.
• KEDA scales event-driven .NET workloads on external signals such as a Service Bus queue length.

Scaling only works if pods declare sensible resource requests and limits and expose health probes, so Kubernetes knows what each workload needs and whether it is healthy. Getting these wrong is a common cause of both instability and wasted spend.

Upgrades

Kubernetes moves fast, and each version has a supported lifetime. Supporting AKS means upgrading both the Kubernetes version and the node images on a planned cadence, staying close enough to current to keep support and avoid a forced multi-version jump later. This is the same staying-current discipline covered in keeping software up to date, applied to the platform.

Observability

You cannot support what you cannot see, and a cluster has more moving parts to see than a single server. Effective observability combines platform and application signals:

• Azure Monitor Container Insights and managed Prometheus for cluster, node, and pod health.
• Application Insights for the .NET application: request rates, dependency calls, and exceptions.
• Structured logs and distributed traces to tie a user request to the pod, node, and dependencies that served it.

The aim is enough correlated signal to answer, quickly, whether a problem lives in the code, the pod, the node, or a downstream dependency such as the database.

Security

Securing AKS spans the cluster and the workloads on it:

• Identity and access through Microsoft Entra integration and Kubernetes role-based access control (RBAC), so people and workloads have least privilege.
• Network policy to control which pods can talk to which, limiting lateral movement.
• Image scanning and runtime protection, for example with Microsoft Defender for Containers, to catch vulnerable images and suspicious behaviour.
• Secret management through Azure Key Vault rather than secrets baked into manifests.

This complements the application-level security in our guide on keeping supported software secure.

Cost management

Kubernetes makes it easy to over-provision, because asking for more capacity is a one-line change. Left unmanaged, cost drifts upward. Supporting cost means rightsizing resource requests, tuning autoscaler bounds, choosing appropriate node sizes, and using scale-down and spot capacity where suitable, so you pay for what the workload needs rather than what someone guessed at setup.

An operating rhythm across a support engagement

These workstreams are not a sequence; they run in parallel as an ongoing rhythm. Some are continuous (monitoring, security, incident cover), while others are periodic (a version upgrade, a cost review). The roadmap below shows a representative quarter of managed AKS operations.

The SQL Server data tier

A common and sensible pattern is to run the .NET application on AKS while keeping the SQL Server data tier outside the cluster, on Azure SQL Database, Azure SQL Managed Instance, or SQL Server on a virtual machine. Managed data services provide backups, high availability, and patching that are difficult and risky to reproduce inside Kubernetes, where pods are designed to be disposable.

Supporting this arrangement means looking after three things: the database itself, the connection between the cluster and the database (secrets in Key Vault, private networking, and connection resilience), and the interaction between them under load. The database work is exactly where automated database administration applies, covered in our guide on automated DBA for SQL Server.

How AI augments AKS operations

A Kubernetes cluster generates a large volume of signals from many pods and nodes, which is precisely the kind of problem AI is good at.

• During incidents, AI correlates pod, node, and application signals and reads logs across many pods at once to converge on a root cause, instead of an engineer paging through them under pressure.
• For capacity and cost, AI spots trends and anomalies in resource use that point to a scaling problem or wasted spend.
• On configuration, AI reviews manifests and Helm charts for risky settings (a missing resource limit, an over-broad RBAC grant, an unset probe) before they ship.

As everywhere in AI-augmented application support, a senior engineer approves cluster changes. AI narrows the search and drafts the fix; the human decides what reaches production, validated through the normal change process.

Where to start

1. Check your version currency. Confirm which Kubernetes version your cluster runs and how close it is to losing support. Falling behind is the most common avoidable AKS risk.
2. Review resource requests and probes. Missing limits and health probes are behind a large share of scaling and reliability problems. They are quick to audit.
3. Get an assessment. A maintainability review covers the cluster, the workloads, and the data tier, and produces a prioritised plan.

See our managed application support service for how we run AKS in production, our AKS deployment service for first-time setup, or book a consultation to discuss your cluster. For the wider approach, read our guide on AI-augmented application support.