AKS GitOps - Azure Glossary

Understand the concept

In plain English

AKS GitOps means the cluster follows what is written in Git instead of relying on one-off kubectl commands or undocumented portal changes. A platform team stores Kubernetes manifests, Helm releases, or Kustomize overlays in a repository, and Flux reconciles those files into the AKS cluster. When the repository changes, the cluster moves toward the new desired state. When someone changes the cluster directly, GitOps can reveal or correct the drift, depending on how reconciliation is configured.

Why it matters

AKS GitOps matters because production Kubernetes changes need a trustworthy record. Without GitOps, teams can drift into direct edits, emergency patches, and environment differences that are difficult to explain during incidents. With GitOps, desired state is reviewed, versioned, and repeatable. It gives developers a familiar pull-request workflow while giving platform teams a way to enforce baseline configuration across clusters. It also improves auditability: teams can connect a running Kubernetes object back to the commit that declared it. The value is not just automation; it is disciplined change control for clusters that otherwise become hard to govern. Practically, AKS GitOps becomes safer when teams save Flux configuration, repository revision, reconciliation status, namespace scope, and approval record, so reviewers can compare design with reality.

Technical context

Technically, AKS GitOps is implemented through the microsoft.flux cluster extension and fluxConfiguration resources. Azure Resource Manager manages the extension, while Flux controllers inside the cluster pull repository sources, render Kustomize or Helm content, and apply resources to target namespaces. The configuration includes repository URL, branch, path, reconciliation interval, credentials, scope, and dependency behavior. It sits across DevOps, Kubernetes operations, identity, policy, and deployment automation, so both Azure permissions and repository governance matter. In practice, Flux configuration, repository revision, reconciliation status, namespace scope, and approval record becomes the minimum proof set before approval.

Exam context

Compare with

Azure Kubernetes Service Node pool

Where it is used

Where you see it

AKS extension pages and az k8s-extension output show the Flux extension, version, provisioning state, namespace, and cluster scope used for GitOps reconciliation during production reviews and incidents.
Flux configuration views show repository URL, branch, path, sync interval, kustomization settings, and whether source or reconciliation errors are blocking deployment during production reviews and incidents.
Cluster logs and Kubernetes events show whether GitOps controllers can read the repository, apply manifests, resolve secrets, and keep desired state synchronized during production reviews and incidents.

Common situations

Keep AKS cluster configuration synchronized from a reviewed Git repository instead of manual kubectl changes.
Deploy namespace-scoped applications, policies, and platform add-ons through Flux reconciliation.
Detect drift between repository intent and live Kubernetes state during release and incident reviews.
Separate cluster bootstrap, application deployment, and emergency change procedures with auditable Git history.
Standardize multi-cluster configuration by applying the same repository patterns across environments.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 AKS GitOps in action Scenario, objectives, solution, measured impact, and takeaway.

Scenario

SummitLedger, a regional bank, had three AKS environments that drifted after emergency fixes were applied with kubectl during payment incidents. The platform team adopted AKS GitOps so production configuration could be reviewed, reconciled, and audited from Git.

Goals

Reduce unauthorized direct cluster changes by 90 percent within one quarter
Cut payment API release rollback time from two hours to under 30 minutes
Trace every production Kubernetes change to an approved pull request
Standardize namespace baselines across dev, test, and production

Approach using AKS GitOps

The team installed the microsoft.flux extension on each AKS cluster and created fluxConfiguration resources for payment namespaces. Application manifests, network policies, resource limits, and Helm values were stored in branch-protected repositories. Azure RBAC controlled who could manage the extension, while Git permissions controlled who could approve changes. Flux reconciliation status was checked in release gates, and Azure Monitor alerts reported failed source syncs or kustomization errors. Emergency changes were still allowed, but the incident process required a follow-up Git commit so the cluster returned to declared state.

Potential outcomes

Direct production edits dropped by 94 percent after three months
Rollback time averaged 22 minutes because teams reverted commits instead of rebuilding manifests manually
Audit sampling found 100 percent of reviewed Kubernetes changes tied to pull requests
Namespace baseline variance across environments fell from 17 differences to 2 documented exceptions

What to learn

AKS GitOps is valuable because it turns cluster configuration into reviewed, repeatable, and recoverable source-controlled operations.

Scenario 02 AKS GitOps in action Scenario, objectives, solution, measured impact, and takeaway.

Scenario

HelioMart, an online marketplace, ran seasonal promotions across three AKS clusters and struggled to keep ingress, scaling, and feature-flag manifests aligned by region. The engineering group used AKS GitOps to make regional overlays predictable before the holiday sale.

Goals

Keep regional AKS configurations within approved drift limits
Deploy promotion services to three regions within 45 minutes
Reduce failed release approvals caused by missing manifests
Maintain a clear rollback path for each regional overlay

Approach using AKS GitOps

The platform team created a GitOps repository with a shared base and region-specific Kustomize overlays. Flux configurations on each AKS cluster targeted the appropriate branch and path, while pull-request checks validated manifests before merge. The team connected status dashboards to Flux reconciliation output and required a green source and kustomization status before traffic shifting. Regional owners could update values in their overlay, but security and ingress baselines stayed in the shared base. The release runbook included commands to suspend reconciliation, resume it, and confirm the last applied revision.

Potential outcomes

All three regions reached the approved promotion state in 34 minutes
Manifest-related release failures dropped by 61 percent compared with the prior sale
Drift alerts caught four unauthorized staging edits before they reached production
Rollback drills completed in 18 minutes by reverting regional overlay commits

What to learn

AKS GitOps helps large AKS estates move fast without losing control of regional differences and approval evidence.

Scenario 03 AKS GitOps in action Scenario, objectives, solution, measured impact, and takeaway.

Scenario

StoneBridge Learning, an education technology provider, needed reliable back-to-school deployments for course-registration services hosted on AKS. Their challenge was letting application teams move quickly while preventing last-minute manual fixes from breaking production consistency.

Goals

Deploy course-registration changes through reviewed Git commits only
Reduce environment mismatch incidents during enrollment week
Give support staff a simple way to verify the active configuration
Improve recovery if a bad manifest or Helm value reached production

Approach using AKS GitOps

The company enabled the Flux extension on its AKS clusters and mapped each course-service namespace to a Git repository path. Application teams owned service manifests, while the platform team owned shared policies, ingress templates, and resource-limit conventions. Azure DevOps pipelines validated YAML and Helm rendering before merging to the production branch. Operators used Azure CLI and kubectl checks to confirm Flux source readiness, reconciliation success, and the last applied revision. The team also documented suspension steps so reconciliation could be paused during an active incident.

Potential outcomes

Enrollment-week environment mismatch tickets fell by 72 percent
Support teams verified active configuration in under 10 minutes using documented status checks
A bad Helm value was reversed in 16 minutes by reverting a commit
Manual production changes were limited to two approved break-glass events with follow-up commits

What to learn

AKS GitOps gives teams a clean bridge between developer delivery speed and platform-grade operational control.

Azure CLI

Azure CLI is useful for AKS GitOps because it lets operators install the Flux extension, create fluxConfiguration resources, inspect reconciliation state, and export evidence without relying only on portal screens.

Useful for

Inspect AKS Flux extensions and GitOps configurations before approving cluster configuration changes.
Capture repository, branch, path, namespace, interval, and reconciliation evidence during release reviews.
Troubleshoot source, kustomization, and controller errors without making direct kubectl changes first.
Compare GitOps settings across development, staging, and production clusters for drift analysis.

Before you run a command

Confirm the subscription, resource group, AKS cluster, namespace, and repository path before inspecting GitOps.
Use read-only extension and flux configuration commands before changing controller or repository settings.
Know whether the issue is repository access, source sync, kustomization apply, or Kubernetes admission failure.
Coordinate with the repository owner because Git changes may be reconciled automatically after Azure checks.

What the output tells you

The output shows whether the Flux extension is installed, healthy, and associated with the expected cluster.
Flux configuration fields identify repository URL, branch, path, namespace, scope, interval, and reconciliation settings.
Error messages indicate whether repository authentication, source sync, kustomization, or Kubernetes admission is failing.
Resource identifiers connect GitOps configuration to change records, cluster ownership, and deployment evidence.

Mapped commands

Inspect and operate AKS GitOps

diagnostic

az k8s-extension create --cluster-type managedClusters --cluster-name <cluster> --resource-group <resource-group> --name flux --extension-type microsoft.flux

az k8s-extensionremoveContainers

az k8s-configuration flux create --cluster-type managedClusters --cluster-name <cluster> --resource-group <resource-group> --name <config> --namespace <namespace> --url <repo-url> --branch main

az k8s-configuration fluxremoveContainers

az k8s-configuration flux show --cluster-type managedClusters --cluster-name <cluster> --resource-group <resource-group> --name <config>

az k8s-configuration fluxdiscoverContainers

Architecture context

Technically, AKS GitOps is implemented through the microsoft.flux cluster extension and fluxConfiguration resources. Azure Resource Manager manages the extension, while Flux controllers inside the cluster pull repository sources, render Kustomize or Helm content, and apply resources to target namespaces. The configuration includes repository URL, branch, path, reconciliation interval, credentials, scope, and dependency behavior. It sits across DevOps, Kubernetes operations, identity, policy, and deployment automation, so both Azure permissions and repository governance matter. In practice, Flux configuration, repository revision, reconciliation status, namespace scope, and approval record becomes the minimum proof set before approval.

Security: Security for AKS GitOps starts with repository trust and cluster write scope. The Flux extension needs credentials or identity access to read the repository and permission to apply resources inside the cluster. If that access is too broad, a compromised repository, branch, or secret can become a cluster compromise path. Teams should protect Git branches, use least-privilege namespaces where possible, store credentials securely, and avoid embedding secrets in manifests. Pair GitOps with Azure Policy, Kubernetes RBAC, and admission controls so the reconciler cannot deploy workloads that violate security baselines. The evidence to retain is Flux configuration, repository revision, reconciliation status, namespace scope, and approval record, because those details show who can change the boundary and whether exposure matches policy.
Cost: GitOps itself is usually not the largest AKS cost driver, but what it deploys can be. A GitOps repository can create replicas, ingress controllers, observability agents, service meshes, storage classes, and workloads across many clusters. That makes cost review part of GitOps governance. Pull requests should consider resource requests, replica counts, autoscaling policies, namespaces, and retention settings before the reconciler applies them. FinOps teams benefit when cluster cost changes can be traced to commits, because they can identify which team changed capacity and whether the spend matched demand. A FinOps review should connect Flux configuration, repository revision, reconciliation status, namespace scope, and approval record to owner, environment, expected utilization, and review date so spend stays explainable.
Reliability: AKS GitOps improves reliability by making cluster state recoverable from a known repository, but it can also spread mistakes quickly if guardrails are weak. A bad manifest, broken Helm chart, or invalid dependency can repeatedly fail reconciliation or roll out across multiple clusters. Reliable GitOps uses staged environments, health checks, drift alerts, rollback commits, and clear reconciliation intervals. Platform teams should monitor Flux status, suspend reconciliation during controlled maintenance when needed, and confirm that critical workloads have probes and disruption budgets before GitOps pushes changes. During incidents, Flux configuration, repository revision, reconciliation status, namespace scope, and approval record helps responders decide whether the issue is workload behavior, platform capacity, or a misconfigured release.
Performance: AKS GitOps affects performance indirectly through deployment consistency and reconciliation behavior. A repository can standardize resource requests, autoscaling settings, probes, ingress configuration, and node affinity across environments, which helps avoid performance surprises. However, overly aggressive reconciliation intervals, oversized manifests, or repeated failed releases can create operational noise and slow change response. Performance reviews should examine whether GitOps-deployed workloads have realistic requests and limits, whether autoscaling is configured, and whether the cluster can absorb rollout surges. GitOps should make performance settings visible, testable, and repeatable. Teams should compare performance before and after changing AKS GitOps, using Flux configuration, repository revision, reconciliation status, namespace scope, and approval record to separate real bottlenecks from configuration assumptions.
Operations: Operationally, AKS GitOps turns deployment work into repository, reconciliation, and evidence management. Operators inspect Flux configurations, source status, kustomization status, Helm release health, reconciliation errors, and last-applied revisions. They should document which repository path owns each namespace, who approves changes, and what command proves the cluster has converged. Normal operations include onboarding clusters, rotating repository credentials, reviewing failed reconciliations, comparing drift, and exporting status for audits. The healthiest pattern is simple: change in Git, verify in cluster, capture evidence, then reuse the pattern. The runbook should capture Flux configuration, repository revision, reconciliation status, namespace scope, and approval record, assign an owner, and define when to roll back, escalate, or accept a documented exception.

Common mistakes

Bypassing GitOps with direct kubectl changes and then being surprised when reconciliation overwrites them.
Giving Flux cluster-wide permissions when a namespace-scoped configuration would reduce blast radius.
Storing secrets directly in Git instead of using an approved secret management pattern.
Troubleshooting only the application deployment while ignoring repository access and source reconciliation health.