v1beta1 GKECluster and GKENodePool about provider-gcp HOT 5 CLOSED

Heads up @soorena776 @turkenh @lukeweber we're planning on adding the functionality you need from GKE (which we believe to be #92, #93, #94. and #101) by prioritising getting it to v1beta1, which should mean exposing all the functionality that is exposed by the GKE API. @hasheddan is working on this this sprint.

from provider-gcp.

Just a heads-up for other folks, if we go with separate NodePool external resource, then it means creating a KubernetesCluster claim won't be enough anymore for getting a GKE cluster. The user will have to curate a NodePool resource that will be attached to managed GKECluster resource since the claim doesn't cover NodePool.

We are running into this issue where we need one-to-many relation between claim and managed resources in a few other places as well, like VNet rule for Azure SQL. Though in this case, I feel like breaking the user flow of create claim and get the cluster is kind of a big deal for GKE clusters.

As we chatted, it makes sense that node pool has its own CRD. But my two cents, until something that provides that one-to-many relation, either aggregate resources or template stacks, we should go with inline node pool array on the managed resource CR (and its class) and call the node pool API wherever needed. We'd still implement the v1beta1 features but keep the version as v1alpha*, since it will likely be changed, until we have the full story for one-to-many relation.

from provider-gcp.

But my two cents, until something that provides that one-to-many relation, either aggregate resources or template stacks, we should go with inline node pool array on the managed resource CR (and its class) and call the node pool API wherever needed. We'd still implement the v1beta1 features but keep the version as v1alpha*, since it will likely be changed, until we have the full story for one-to-many relation.

The main driver for working on GKE v1beta1 right now is unblocking Upbound's W&E team, who want to use Crossplane to deploy GKE clusters that will in turn be used to host Crossplane control planes. Those folks don't need dynamic provisioning, so my thinking was that we'd ship v1beta1 GKE support with separate node pool managed resource (that could not yet be dynamically provisioned) but leave support for the current v1alpha3 style Kubernetes clusters.

This way folks who want to try out the new v1beta1 managed resources can do so under the constraint that they must statically provision their clusters (for now), and folks who still need to dynamically provision GKE clusters can use the existing v1alpha3 API and controller.

from provider-gcp.

Oh, so we'll have two versions for GKECluster type and different controllers for each. Dynamic provisioning users will use v1alpha3 but static provisioning users will be able to use either only va1lpha3 GKECluster or v1beta1 GKECluster & v1beta1 NodePool. I assume v1beta1 GKECluster won't have a claim reconciler in that scenario.

That's something new in our codebase but makes sense to me. Hopefully when we have the one-to-many, we can just drop the support for v1alpha3.

from provider-gcp.

Documenting a few of the discussions we have had about supporting v1beta1 GKE and adding support for node pools:

• In order to create a GKE cluster using the gcloud API, you must define a node pool (i.e. you cannot create a cluster with no node pools).
• Node pools can be created inline with the cluster, but cannot be updated using the cluster API.
• A node pool cannot be created without attaching it to a cluster.

While you cannot create a GKE cluster with 0 node pools, you can delete node pools after the creation of the cluster. It is my opinion that we should create GKE clusters with a default node pool then immediately delete it, without exposing the options to configure or keep that node pool to the user. This would be in accordance with our api design principles:

For both Status and Spec: Is this field represented as standalone managed resource? Do not include if the answer is yes. We should not manage an external resource in the CR other than its original external resource.

Because NodePool will be its own resource, all node pools should be managed using it.

cc @negz @muvaf

from provider-gcp.