# Azure/AKS: what the tracker accepts, and what it redirects > Azure/AKS holds no service code. It is the issue and feature tracker for a managed Kubernetes service, and the first thing it does is draw a support boundary: best-effort help only for problems reproducible outside your own cluster, everything else redirected to Azure Support. What sits in the repository instead of code is the more useful part, a set of example reproductions. **Azure/AKS** — Azure Kubernetes Service - Repository: https://github.com/Azure/AKS - Website: https://azure.github.io/AKS/ - Stars: 2,142 · Forks: 398 - Language: TypeScript - License: MIT - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/azure-aks ## A repository whose first job is a support boundary The Azure/AKS repository is offered for tracking features and issues with Azure Kubernetes Service, and it is monitored by the AKS product team so the community can discuss questions, customer scenarios and feature requests. That is the whole stated purpose, and the very next paragraph sets the limit. Support through issues here is on a best-effort basis, and only for issues that are reproducible outside of a specific cluster configuration. Urgent support is explicitly described as out of scope for the repository's objectives, and the README points at the Azure support options page and the AKS support policies page for anything with a response-time commitment. So this is not an open source project that happens to have an issue tab. It is a public, searchable record of how a managed service behaves, with a routing rule attached. That framing determines everything else worth knowing about it, including what the repository does contain. There is a second boundary. Issues for AKS-Engine, Virtual-Kubelet, Azure Container Instances and other tools should not be filed here unless they concern that feature's relationship with AKS, and anything else is directed to the upstream Azure Compute projects page. Three adjacent projects are named explicitly, which suggests the boundary between them and AKS itself causes regular confusion. ## The redirect rule, and why it exists The mechanism that keeps the tracker usable is a hard redirect. If your issue would require direct access to your cluster or to your Azure resources, you will be redirected to an Azure support ticket. The README gives the cases it has in mind: custom network devices, configuration problems, and authentication issues tied to your Azure subscription. The reason is stated in one line and it is a good one. Microsoft employees may not ask for personal or subscription information on GitHub. A cluster-specific problem cannot be diagnosed without exactly that information, so the only two honest options are a private channel or no answer at all. The redirect is the mechanism that lets the public tracker stay useful for everything else. There is also a second privacy line in the same paragraph: the report must be reproducible outside the cluster you are running. That single requirement does more work than it looks. A defect that reproduces on a vanilla cluster with public manifests is a defect in the product. A defect that only appears with your node image, your network plugin and your configuration is a fact about your environment, and the maintainers cannot act on it. For a user filing a report, the practical consequence is that you should reproduce on a minimal cluster before you file, and if you cannot, you already know where the report belongs. ## Four requirements, and what gets closed for missing them The bug guidance is specific enough to be useful and blunt enough to offend. The README states up front that an inability to meet the requirements for bug reports is subject to having the issue closed by maintainers and routed to official Azure support channels, on the stated grounds of providing the proper support experience. The four requirements follow. The report must be reproducible outside your cluster, as described above. It must have a good title that is clear, relevant and descriptive, so the general shape of the problem is graspable immediately. It must have a description before the steps, and that description has to assume the reader is unfamiliar with the issue and the system in question. And it must contain clear, concise steps to replicate, which should let anyone see what you did and recreate it themselves, including expected and actual results plus relevant URLs. Supporting material is the last item and it is not optional in practice: YAML files and deployments, scripts to reproduce, the exact commands used, screenshots. Nothing in that list is unusual for a good bug report, which is the point. What is unusual is that a vendor has written down the standard in advance and attached a consequence to it. If you have never filed a bug with enough detail to be acted on, this list is a usable rubric for your own bug reports, whether or not they end up here. The same reasoning cuts the other way: if you file something thin, the outcome is a redirect to a paid support channel rather than a free conversation with the product team. ## The examples directory is the real content Since there is no service code here, the informative part of the tree is `examples/`, and reading its names is the fastest way to understand what actually breaks in a managed Kubernetes service. There are directories for `cgroups/`, `kubelet/` and `runc/`, which is the node-side stack, plus `kernel-1095-issue/` and `iptables/`, which is the host kernel and its packet filtering. A managed cluster is an opinionated Kubernetes distribution sitting on a kernel that Microsoft updates on your schedule, and those two facts explain why a tracker for a managed service has cgroup and kernel reproductions at all. It is not a Kubernetes project, but most of its interesting failures live below the Kubernetes API. Then the cluster-side surface: `fleet/` for multi-cluster management, `vnet/` for networking, `istio-based-service-mesh/`, `kube-prometheus/` for observability, `unattended-upgrades/` for node image upgrades, and `disable-azsecd.yaml` for a specific security add-on setting. `cost-analysis-export/` points at the cost export side of the service rather than its runtime. And a recent cluster of AI names: `end-to-end-AI-codelabs/`, `kueue-and-ray-on-aks/` and `llm-routing-on-aks/`, which say that GPU-adjacent workloads are where the new example material is being written. One more directory worth naming is `envoy-ghsa-jfxv-29pc-x22r/`, named after an Envoy advisory identifier, which indicates the tracker keeps reproductions tied to specific upstream vulnerabilities. What the tree does not give you is any instructions. The README documents no way to run any of these, and there is no README inside the examples tree that the repository advertises. Treat them as context for what the product team has been looking at, not as a reproducible lab environment. ## Dated release tags and one tag per feature The release tags on this repository are the interesting part of its history. Two of them are plain dates, a release tagged 2026-09-04 and another tagged 2026-08-07, which tells you the service ships on a roughly fortnightly rhythm and that the tag is the release date rather than a version string. The third is different. AppNet 2026-08-19 is tagged for a single feature area rather than for the service as a whole, and the tree contains an `appnet-notes/` directory alongside the other note directories `ai-conformance/` and `vhd-notes/`. So a feature-scoped tag is paired with in-tree notes, which is a usable signal: if you depend on app networking and want to know when your behaviour changes, you can watch that tag rather than diffing two service releases by hand. CHANGELOG.md sits at the top level next to SECURITY.md, which is the conventional pairing for a project that needs a changelog for the files it does contain and a separate reporting path for vulnerabilities. SECURITY.md is the right place to look before you assume a bug report is the right channel for a security problem, and given that one example directory is named after an advisory, that distinction matters here. The `website/` directory is why the recorded primary language for this repository is TypeScript, and `body.json` at the root is a stray artefact of however that site is built. Neither tells you anything about AKS itself. ## Three places to take an AKS problem The alternatives are worth laying out side by side, because picking the wrong one is the most common way this repository gets used badly. The GitHub tracker is for reproducible, product-level defects and for feature discussion. You get a public record, other customers benefit from the same answer, and the product team monitors it. You get no commitment on timing, and you get nothing for anything tied to your subscription. Azure Support is for everything cluster-specific and for anything urgent. The difference in approach is direct: a ticket carries a response-time commitment and gives the engineers the access to your resources that the GitHub path is forbidden from asking for. The cost is that it is paid support and the conversation is not public. The upstream Azure Compute projects page is the third option, and it is the one people reach for when they have filed a report in the wrong place. AKS-Engine, Virtual-Kubelet and Azure Container Instances each have their own tracking, and a defect in one of those that happens to surface inside AKS belongs there unless the behaviour is genuinely AKS's. One thing to keep in mind while choosing: the README's own documentation links are all redirects through aka.ms, covering the roadmap, the blog, the release notes, hybrid deployment options, and the kubernetes-service feed in Azure Updates. Those are where service behaviour is described. This repository is where it is complained about. Keeping the two apart is the fastest way to answer most AKS questions without filing anything. ## Conclusion Use the Azure/AKS tracker for defects that reproduce on a cluster you can describe publicly, with YAML, commands and expected versus actual results attached. Take anything cluster-specific to Azure Support instead, because the README states that urgent support is out of scope and redirects those reports to a ticket. Read CHANGELOG.md and the dated release tags when you are tracking a rollout, and note that the MIT licence covers the files in this repository rather than the service. ## FAQ ### What is the Azure/AKS GitHub repository used for? It tracks features and issues for Azure Kubernetes Service and is monitored by the AKS product team so the community can discuss questions, customer scenarios and feature requests. Support through issues is best-effort and limited to issues reproducible outside a specific cluster configuration. ### Can I get urgent AKS support through a GitHub issue? No. Urgent support is explicitly out of scope for the repository, and issues needing direct access to your cluster or Azure resources are redirected to an Azure support ticket, since Microsoft employees may not ask for personal or subscription information on GitHub. The README points to the Azure support options and AKS support policies pages. ### What does a good AKS bug report have to contain? Reproducibility outside your own cluster, a clear and descriptive title, a description written for a reader unfamiliar with the system, and concise replication steps including expected and actual results with relevant URLs. Supporting material should include YAML or deployments, reproduction scripts, the exact commands used and screenshots. ### What should I not file on the Azure/AKS repository? Issues for AKS-Engine, Virtual-Kubelet, Azure Container Instances or other tools and services, unless the report concerns that feature's relationship with AKS. Those belong on the upstream Azure Compute projects page that the README links. ### Where are the AKS roadmap and release notes? Off the repository, through redirects: the roadmap at aka.ms/aks/roadmap, the blog at aka.ms/aks/blog, release notes at aka.ms/aks/release-notes and hybrid deployment options at aka.ms/aks-hybrid, plus the kubernetes-service feed in Azure Updates for new features and new regions. ## Sources - [Azure/AKS on GitHub](https://github.com/Azure/AKS) - [License: MIT](https://github.com/Azure/AKS/blob/master/LICENSE) - [Project website](https://azure.github.io/AKS/) - [README](https://github.com/Azure/AKS/blob/master/README.md) - [Releases](https://github.com/Azure/AKS/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-aks