GCP Resource Name Generation

[mikebryant]

Describe the feature or the resource that you want. As a user, I want to work within Kubernetes. I don't want to be required to deal with conflicts between Namespaces or clusters.

I would like to, for example, be able to create an SQLInstance object in my kubernetes Namespace and have it set up a GCP cloud SQL instance for me. I want this to be repeatabled - I want to use the same object in different Namespaces, and have that create distinct databases. I don't care (in this case) what the underlying GCP resource name is.

Currently I need to care about conflicts, because the resource name I provide in Kubernetes is mapped directly to the GCP name.

The resourceName(tbd) feature in #54 doesn't go far enough - I would still need to carefully manage conflicts across Namespaces and clusters.

Some way of telling config connector to "make up a unique name" would be a way of solving this.

One issues does come to mind though - there then needs to be a way of getting this name back out for use in things cloudsql_proxy. I can see two things that would work there:

• config connector manages a child ConfigMap object of the SQLInstance, with appropriate details in for connecting to the resource with cloudsql_proxy
• config connector manages a child Service which maps to the private IP of the SQL instance, if that's enabled. (Or both?)

What're your thoughts on this?

[mikebryant]

For examples of the way similar things currently work - consider Ingress on GKE. When creating an Ingress, the underlying GCP objects are all created with generated names by the controller, but I didn't have to specify all of them, and they're guaranteed not to clash between Namespaces, clusters etc.

[xiaobaitusi]

Hi @mikebryant, I think that there are two separate questions.

I would like to, for example, be able to create an SQLInstance object in my kubernetes Namespace and have it set up a GCP cloud SQL instance for me. I want this to be repeatabled.

I think that you can achieve this using some template and customization approach, e.g helm charts or kpt. We also have some examples about how to leverage helm or kpt define resource template and generate final yamls to apply with ConfigConnector.

As for exposing ip information, we have received some similar request per #88. We are looking into how to best support this use case; if that's what you want, feel free to vote it up.

[mikebryant]

You're right, they're two separate things - thanks for pointing me to #88, will talk about getting details out of resources there

On how to achieve being able to deploy things without coordination to avoid clashing - I don't think either of those things can solve the problem without requiring external coordination.

I want a team who've been given a Namespace to be able to deploy things, to be able to use an SQL database for example, without needing to coordinate with teams they don't work with. Generally Namespaced objects in Kubernetes allow this - that's why they're in a Namespace, not cluster-wide.

If they all have to coordinate to make sure no-one else calls their database instance the same thing (e.g. all the teams wanting a database called main, primary, app, replica etc.) - this introduces an unnecessary barrier to usage.

Imagine if everyone using GCP needed to give their SQL Instance unique names across the whole world - they don't, it's split by project. The same thing needs to apply all the way down the stack. Config Connector has the ability to look at GCP and ensure unique names, people who just have access to one Namespace in the Kubernetes API do not - they can't see that information if the secure policies are using least-privilege.

Another factor that makes using helm and friends for this hard is the constraints places on many GCP resource names - the 30 character limit for GCP service accounts for instance is annoyingly small, and we've already having to resort to using 2 characters for various fields, which makes everything harder to understand. I would much rather be able to use sensible naming in the Kubernetes API, and leave config connector to mangle all the names in GCP to fit.

[xiaobaitusi]

To clarify, in your current setting, there will be multiple namespaces mapping to the same project and KCC resources that created under different namespaces will end up with GCP resources in the same project. Is this the case? Generally we recommend a one-to-one mapping between namespace and project. Different teams can use different projects as the natural boundary of their resources.

FYI, ConfigConnector takes a different approach to avoid the clashing/conflicting by ensuring only one k8s object is mapping to the actual GCP resource. This is done by obtaining the resource lease before apply.

I see your points with generated names and we'll treat it as an open feature request and see if other users have the similar need.