Address review comments

kubernetes-sigs · Aug 5, 2022 · 2acf17a · 2acf17a
1 parent 1ac518c
commit 2acf17a
Showing 1 changed file with 15 additions and 7 deletions.
diff --git a/docs/proposals/20220725-managed-kubernetes.md b/docs/proposals/20220725-managed-kubernetes.md
@@ -9,9 +9,12 @@ reviewers:
   - “@enxebre”
   - “@fabriziopandini”
   - “@jackfrancis”
+  - "@joekr"
   - “@sbueringer”
+  - "@shyamradhakrishnan"
+  - "@yastij"
 creation-date: 2022-07-25
-last-updated: 2022-07-25
+last-updated: 2022-08-05
 status: implementable
 see-also:
 replaces:
@@ -40,6 +43,7 @@ superseded-by:
     - [Current State of Managed Kubernetes in CAPI](#current-state-of-managed-kubernetes-in-capi)
       - [EKS in CAPA](#eks-in-capa)
       - [AKS in CAPZ](#aks-in-capz)
+      - [OKE in CAPOCI](#oke-in-capoci)
     - [Managed Kubernetes API Design Approaches](#managed-kubernetes-api-design-approaches)
       - [Option 1: Single kind for Control Plane and Infrastructure](#option-1-single-kind-for-control-plane-and-infrastructure)
         - [Background: Why did EKS in CAPA choose this option?](#background-why-did-eks-in-capa-choose-this-option)
@@ -141,8 +145,8 @@ So that I don't have to worry about the management of these instances.
 #### Story 6
 
 As a Service provider,
-I want to be able to offer “Managed Kubernetes” clusters via a CAPI provider which is consistent with other implementations,
-So that users intuitively know how to create clusters with my service.
+I want to be able to offer “Managed Kubernetes” powered by CAPI,
+So that I can eliminate the responsibility of owning and SREing the Control Plane from the Cluster consumer and cluster admin.
 
 ### Current State of Managed Kubernetes in CAPI
 
@@ -179,6 +183,11 @@ So that users intuitively know how to create clusters with my service.
 - Supported Flavor
   - AzureManagedControlPlane + AzureManagedCluster with AzureManagedMachinePool
 
+#### OKE in CAPOCI
+
+- https://github.com/oracle/cluster-api-provider-oci/issues/110
+- Design discussion starting
+
 ### Managed Kubernetes API Design Approaches
 
 When discussing the different approaches to represent a managed Kubernetes service in CAPI, we will be using the implementation of GKE support in CAPG as an example, as this isn’t currently implemented.
@@ -368,7 +377,6 @@ AdditionalLabels Labels `json:"additionalLabels,omitempty"`
 **Cons**
 
 - Duplication of API definitions between GCPCluster and GCPManagedCluster and reconciliation for the infrastructure cluster
-- Users need to be aware to use GCPManagedCluster instead of GCPCluster when creating a GKE based cluster.
 
 #### Option 4: Two kinds with a Managed Control Plane and Shared Infra Cluster with Better Separation of Responsibilities
 
@@ -395,7 +403,7 @@ So the **GCPCluster** controller will need to know if its creating infrastructur
 
 ## Recommendations
 
-It is proposed that option 3 (two kinds with a managed control plane and managed infra cluster with better separation of responsibilities) is the best way to proceed for **new implementations** of managed Kuberenetes in a provider.
+It is proposed that option 3 (two kinds with a managed control plane and managed infra cluster with better separation of responsibilities) is the best way to proceed for **new implementations** of managed Kubernetes in a provider.
 
 The reasons for this recommendation are as follows:
 
@@ -421,8 +429,8 @@ Some cloud providers also offer Managed Node Groups as part of their Managed Kub
 
 There are 2 different ways to represent a group of machines in CAPI:
 
-- **Machine Deployments** - you specify the number of replicas of a machine template and CAPI will manage the creation of immutable Machine-Infrastructure Machine pairs via MachineSets. The user is responsible for explicitly declaring how many machines (a.k.a replicas) they want and these are provisioned and joined to the cluster.
-- **Machine Pools** - are similar to machine deployments in that they specify a number of machine replicas to be created and joined to the cluster. However, instead of using MachineSets to manage the lifecycle of individual machines a provider implementer utilses a cloud provided solution to manage the lifecycle of the individual machines instead. Generally with a pool you don’t have to define an exact amount of replicas and instead you have the option to supply a minimum and maximum number of nodes and let the cloud service manage the scaling up and down the number of replicas/nodes. Examples of cloud provided solutions are Auto Scale Groups (ASG) in AWS and Virtual Machine Scale Sets (VMSS) in Azure.
+- **MachineDeployments** - you specify the number of replicas of a machine template and CAPI will manage the creation of immutable Machine-Infrastructure Machine pairs via MachineSets. The user is responsible for explicitly declaring how many machines (a.k.a replicas) they want and these are provisioned and joined to the cluster.
+- **MachinePools** - are similar to MachineDeployments in that they specify a number of machine replicas to be created and joined to the cluster. However, instead of using MachineSets to manage the lifecycle of individual machines a provider implementer utilses a cloud provided solution to manage the lifecycle of the individual machines instead. Generally with a pool you don’t have to define an exact amount of replicas and instead you have the option to supply a minimum and maximum number of nodes and let the cloud service manage the scaling up and down the number of replicas/nodes. Examples of cloud provided solutions are Auto Scale Groups (ASG) in AWS and Virtual Machine Scale Sets (VMSS) in Azure.
 
 With the implementation of a managed node group the cloud provider is responsible for managing the lifecycle of the individual machines that are used as nodes. This implies that a machine pool representation is needed which utilises a cloud provided solution to manage the lifecycle of machines.