This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
One cluster name in AKS
AKS is a managed cluster in an account you administer. The subscription and resource group are the Azure lab from the provider guide. The generators can draft a node pool, an autoscaler, and an ingress. This window drafts the cluster identity and, at most, the node pool. The other two files wait.
kubectl's context must be this cluster before any apply. A context you did not write down is the wrong cluster until proven otherwise. The Kubernetes guide owns the namespace habit. This page owns the product's cluster boundary.
Authorized ranges for the API are a list you can read. An empty list that means the world is a list you do not keep. A kubeconfig in git or in the ticket is a secret you rotate. prompt-for-this is not a kubeconfig.
The application identity is not a cluster administrator, and the pipeline identity is not a cluster administrator. Autoscaling and ingress are capacity and traffic decisions. They are not how you check that the API answers.
A name, a version, a node pool you can explain
Write the cluster name, the region, the version, and the account. Draft a node pool only if the version is written. The size is a lab size. One pool is enough. A second pool for a second architecture waits.
Write whether the pool you draft is the system pool or a user pool. One is enough. The cluster identity is not the Owner of the subscription.
Read the API with a get, when the lab window opens, and paste the context line into the ticket. If the name differs, stop. Do not install an ingress to debug the context.
The autoscaler draft and the ingress draft stay in the ticket as later work, unapplied. An ingress that requests a public address is a network change. The network guide has to agree before that file is applied.
# AKS note. One cluster you administer.
# Context first. Apply second.
# Node pool is optional and small. Autoscaler and ingress wait.
# No cluster-admin for the app or the pipeline.
# prompt-for-this is not a kubeconfig.
# A public ingress is a separate decision.
A change you can finish
The later change is the cluster or the one node pool, not the autoscaler and not the ingress.
Rollback of a lab pool is removing that pool. You do not delete a shared cluster to undo a draft. You do not scale a production pool to zero as a test.
- Write the account, region, name, and version.
- Confirm you administer that account.
- Draft at most one lab node pool.
- Keep autoscaler and ingress unapplied.
- Write the context name you expect.
- Refuse cluster-admin for the app and the pipeline.
- Hand the first kubectl get to a window where the context is checked.
Mistakes that outlive the command
AKS fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Three generators applied in one hour.
- kubectl aimed at the current context without reading it.
- A kubeconfig in the repository.
- cluster-admin for the pipeline.
- A public ingress used as a health check.
- A production pool scaled as a test.
- The largest node size as the lab.
- A version you did not write down.
- An API authorized to the world, or the cluster identity set to Owner.
- An autoscaler turned on before a request exists.
- Calling the cluster ready because the API answered.
Decisions to write down before the window
One decision for AKS: The cluster name and region are written. The version is written. The account is yours. At most one node pool is in this draft. The pool size is a lab size. Autoscaler is not applied. Ingress is not applied. The context will be checked before any write. No kubeconfig is in git. The app and the pipeline are not cluster administrators. The pool's job, system or user, is written. And a second person can say which cluster this is.
The hour you stop
Write the account, the project or subscription, the region, and the clock time before you change anything for AKS. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.
Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.
prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.
One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.
A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.
Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.
Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.
Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.
If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.
When the checks pass, the next account waits until someone else can repeat the proof from the notes. AKS is done for this window when the proof is written, not when a CLI printed a success line.
This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.
Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.
AKS checks before a manifest is applied
Confirm this before you call the change done: The name, region, and version are in the ticket. The account matches the provider note. Only one pool is drafted, or none yet. Autoscaler and ingress are unapplied. No kubeconfig is in the note. cluster-admin is not the app identity. The context check is the next command. Authorized API ranges are named, not the world. The hostname in the prompt matches the hostname in the ticket for AKS. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for AKS happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
- AKS Node Pool Setup Generator
- AKS Cluster Autoscaler Setup Generator
- AKS Ingress Controller Setup Generator
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- How-To: How to Manage Node Pools on AKS
- How-To: How to Set Up Cluster Autoscaling on AKS
- How-To: How to Set Up an Ingress Controller on AKS
- How-To: How to Set Up Workload Identity on AKS
- How-To: How to Upgrade an AKS Cluster
- How-To: Logging and Monitoring for AKS
- How-To: Persistent Storage on AKS
- Checklist: AKS Cost Optimization Checklist