Add proposal for AzureManagedCluster v1

docs/proposals/20220825-azuremanaged-cluster-v1.md

@@ -0,0 +1,67 @@
+---
+title: AzureManagedCluster graduation to v1 from experimental
+authors:
+  - "@jackfrancis"
+reviewers:
+  - @CecileRobertMichon
+  - @zmalik
+  - @NovemberZulu
+creation-date: 2022-08-25
+last-updated: 2022-08-25
+status: implementable
+see-also:
+- https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/2204
+- https://github.com/kubernetes-sigs/cluster-api/pull/6988
+---
+
+
+# AzureManagedCluster graduation to v1 from experimental
+
+## Summary
+
+`AzureManagedCluster` is a capz-native implementation of Azure Managed Kubernetes (AKS). Because there is no standard set of Cluster API resource definitions for a "Managed Kubernetes cluster", it is left up to the provider to re-use the existing Cluster API specification (for example, the `Cluster` and its to-be-implemented-by-provider properties such as `ControlPlaneEndpoint`, `ControlPlaneRef` and `InfrastructureRef`). As a result, capz implemented `AzureManagedCluster` with an API contract designation of "experimental", to allow for rapid prototyping and discovery.
+
+With the recent adoption of `AzureManagedCluster` by the capz community for practical, real-world use, we want to identify the set of outstanding items that may prevent graduation to v1, and address each one of them, so that future adoption can be unlocked, and users can confidently build resilient systems on top of a stable API.
+
+## Motivation
+
+### Goals
+- Agree upon a definitive v1 specification of `AzureManagedCluster`
+- Prioritize timeliness of a v1 definition so that users can confidently commit to v1 in the near term
+- Prioritize "architectural affinity" with other Cluster API providers implementing Managed Kubernetes
+
+### Non-Goals / Future Work
+- Add features to `AzureManagedCluster`
+- Standardize any opinions about how best to use AKS
+- Promote capz-specific opinions about Managed Kubernetes across the Cluster API provider ecosystem
+- Include operational support in the scope of a v1 definition
+
+## Outstanding items under consideration for v1 prerequisites
+
+### 1. Land Managed Cluster in Cluster API Proposal
+
+See:
+
+- https://github.com/kubernetes-sigs/cluster-api/pull/6988
+
+The above proposal defines a set of recommendations for Cluster API providers implementing Managed Kubernetes solutions. Because this proposal is an opt-in collection of architectural recommendations, it is not required that `AzureManagedCluster` strictly agrees with everything therein. However, by contributing to the successful landing of that proposal in Cluster API, we can best ensure that any capz-specific opinions or learnings are reflected, for the benefit of the larger ecosystem, and for the maximum happiness of AKS customers in particular.
+
+### 2. Integrate Cluster API Proposal Recommendations
+
+Once the proposal is accepted and merged into the Cluster API project as an endorsed set of provider recommendations, capz can audit the existing `AzureManagedCluster` experimental implementation for areas of disagreement with said recommendations. For each discovery of disagreement, there should be a defensible reason to matriculate a divergent capz Managed Kubernetes implementation into a v1 definition of `AzureManagedCluster`, and ideally some form of sign-off from other provider maintainers. Where community consensus cannot be reached, capz should strongly consider evolving the experimental `AzureManagedCluster` implementation to meet the Cluster API Managed Kubernetes recommendation as a pre-requisite to releasing v1.
+
+### 3. Full AKS Feature Support
+
+A v1 of `AzureManagedCluster` should be able to accommodate the entire feature set of AKS. Rather than require the concrete list of features of AKS to be fully implemented as a v1 prerequisite, we should instead audit the AKS feature matrix against the `AzureManagedCluster` architectural surface area and ensure that capz is well prepared to continually integrate existing and new AKS features into `AzureManagedCluster` in a non-breaking way for capz customers of `AzureManagedCluster` v1.
+
+### 4. Affinity between capz / Cluster API resource lifecycle enforcement and AKS lifecycle enforcement.
+
+Not unrelated to the above audit of AKS features, we should also overlay the Cluster API lifecycle combinatorics (simply speaking: Create, Read, Update, Delete) against the set of AKS cluster primitives to ensure that sane interfaces exist in capz in order to effectively enforce (for example, add an AKS node pool), or passively delegate authority (for example, defer to the built-in AKS autoscaler when enabled to enforce `MachinePool` replica count), if appropriate.
+
+### 5. Azure API Request Optimizations
+
+Prior to releasing a v1 of `AzureManagedCluster`, we should ensure that the sufficient set of configurable interfaces exist to allow `AzureManagedCluster` users to effectively tune capz so that no unnecessary Azure API requests are introduced into their AKS environment. We should ship sane, optimized defaults, but allow for flexible overrides to anticipate a wide variety of operational use cases.
+
+
+## Questions
+- This section intentionally left blank.