Production Baseline¶

Use this page as the umbrella go-live checklist for AKS platform readiness. It defines the minimum cluster baseline, the review questions that must be answered before workloads onboard, and where to hand off deeper design decisions to the focused best-practices pages.

Why This Matters¶

flowchart TD
    A[AKS Production Baseline] --> B[Identity and Secrets]
    A --> C[Networking and Egress]
    A --> D[Node Pools and Capacity]
    A --> E[Observability and Alerts]
    A --> F[Governance and Policy]
    A --> G[Upgrade and Reliability]
    A --> H[Cost and Efficiency]
    A --> I[Placement and Disruption]
    B --> B1[security.md]
    C --> C1[networking.md]
    D --> D1[resource-governance.md]
    E --> E1[monitor-aks and runbooks]
    F --> F1[governance.md]
    G --> G1[reliability.md]
    H --> H1[cost-optimization.md]
    I --> I1[explicit-placement-disruption-control.md]

AKS production failures often start before the first workload deploys: missing ownership, unclear network posture, mixed system and application capacity, or no upgrade and monitoring gate. A concise platform baseline prevents every cluster from becoming a one-off exception that is harder to secure, operate, and review.

Recommended Practices¶

Practice 1: Define the go-live readiness gate before workload onboarding¶

Treat the baseline as a formal entry gate, not a best-effort aspiration. Before any workload is admitted, the platform team should be able to answer: which identity model is enabled, which network posture was chosen, where system components run, where logs and alerts land, how upgrades are rehearsed, and who approves exceptions.

What must exist before onboarding workloads:

Practice 2: Standardize the reference architecture posture for public and private baselines¶

Every production cluster should start from one of two approved postures: a public baseline with tightly defined ingress and control-plane exposure, or a private baseline with private API connectivity and explicit operator access paths. In both variants, keep system and user node pools separate, use managed identity, enable Azure RBAC and Workload Identity, and wire diagnostic settings plus baseline alerts from day one.

Use this command to confirm that the cluster baseline flags match the approved posture before onboarding workloads:

az aks show \
    --resource-group "$RG" \
    --name "$CLUSTER_NAME" \
    --query "{identity:identity.type,azureRbac:aadProfile.enableAzureRbac,privateCluster:apiServerAccessProfile.enablePrivateCluster,oidcIssuer:oidcIssuerProfile.enabled,workloadIdentity:securityProfile.workloadIdentity.enabled}" \
    --output yaml

This verification is only the umbrella posture check. Delegate CNI, pod IP planning, ingress controller choice, outbound dependencies, and private API connectivity patterns to networking.md and private-cluster-api-connectivity.md.

Practice 3: Assign explicit platform ownership boundaries¶

Production AKS is an operating model, not just a cluster deployment. Make ownership explicit so cluster teams know who approves ingress changes, who manages policy rollouts, who owns namespace lifecycle, who executes upgrades, and who leads first response during incidents.

The implementation mechanics for runtime hardening, secrets, quotas, PSS rollout, and upgrade safety belong in the focused pages: security.md, resource-governance.md, governance.md, and reliability.md.

Practice 4: Enable the mandatory baseline controls before application teams self-serve¶

The baseline should provide safe defaults before developer onboarding begins: system and user pool separation, managed identity, Azure RBAC, Workload Identity, cluster monitoring, control-plane diagnostic settings, and a starter alert set for API-server health, node readiness, and cluster capacity signals. That keeps new namespaces from inheriting an unobservable or weakly governed platform.

Use this command to confirm that namespaces are onboarding into an already-structured platform rather than an empty cluster shell:

kubectl get namespaces \
    --show-labels

Review this output to confirm that namespace ownership and tenancy conventions are present before application teams start deploying workloads. Then use resource-governance.md for quotas and requests or limits, governance.md for policy controls, and security.md for runtime hardening, identity, and secrets.

Practice 5: Use the umbrella page as a decision router, not an implementation dump¶

Keep this page short on purpose. During design review, use it to classify each unresolved decision and send the reader to the page that owns it instead of repeating detailed guidance here.

Common Mistakes / Anti-Patterns¶

• Treating cluster creation as production readiness. A running AKS cluster is not a go-live baseline unless ownership, monitoring, upgrade readiness, and governance are already assigned.
• Letting the first workload define the platform defaults. If ingress, namespace boundaries, or identity patterns are decided workload by workload, the platform becomes inconsistent immediately.
• Mixing system-critical services and application workloads on the same default pool without a deliberate exception process. This turns capacity spikes into shared outages.
• Enabling deep controls only after onboarding begins. Retrofitting policy, alerts, or Workload Identity after teams are already deployed creates avoidable migration and outage risk.

Validation Checklist¶

Use this checklist for design review and go-live approval:

• [ ] The cluster is classified as an approved public or private production baseline.
• [ ] Managed identity, Microsoft Entra integration, Azure RBAC, OIDC issuer, and Workload Identity are enabled for the cluster baseline.
• [ ] System and user node pools are separated, and system capacity is reserved for cluster-critical components.
• [ ] Diagnostic settings and cluster monitoring are enabled, and baseline alerts exist for control-plane health, node readiness, and capacity symptoms.
• [ ] Namespace ownership, ingress ownership, policy ownership, upgrade ownership, and incident-response ownership are explicitly documented.
• [ ] Workload onboarding is blocked until the networking, security, governance, reliability, and resource-governance decisions have owners and approved patterns.
• [ ] Upgrade readiness is reviewed against supported versions, maintenance windows, and rollback communication paths.
• [ ] Budget guardrails and cost-review cadence exist before teams begin scaling out workloads.

See Also¶

• Best Practices overview
• Networking
• Security
• Governance
• Resource Governance
• Reliability
• Autoscaling
• Cost Optimization
• Explicit Placement and Disruption Control
• Private Cluster API Connectivity
• Cluster Architecture
• Node Pools
• Identity and Secrets
• Monitoring and Logging
• Upgrade Failure playbook

Sources¶

• AKS best practices
• Secure baseline AKS architecture
• Quickstart: Deploy an AKS cluster by using Azure CLI
• Monitor AKS