pulumi / pulumi-kubernetes

A Pulumi resource provider for Kubernetes to manage API resources and workloads in running clusters
https://www.pulumi.com/docs/reference/clouds/kubernetes/
Apache License 2.0
406 stars 115 forks source link

Feature: Add an optional service provider field to Provider class #695

Open lblackstone opened 5 years ago

lblackstone commented 5 years ago

Currently, there doesn't seem to be a way to tell what service provider a Provider references (AKS, EKS, GKE, etc.). Since each service provider has subtle differences in behavior, it would be nice to have a built-in way to drive conditional behavior.

lukehoban commented 5 years ago

Would this be used for anything? Or is it effectively just a tag?

Another use case for this would be generating nicer URLs for resources when we know they are associated with a GKE cluster for example - though for that purpose, we probably need more than just "this is GKE", but more "this is this particular GKE cluster identity".

lblackstone commented 5 years ago

The initial use case was for selecting which status field in a Service object has the endpoint configuration; this isn't standard across the major clouds.

AFAICT, there's no way to reliably introspect this information from a kubeconfig, but we could set it for clusters created with Pulumi. This could certainly enable richer integration with our dashboard.

lukehoban commented 5 years ago

The initial use case was for selecting which status field in a Service object has the endpoint configuration; this isn't standard across the major clouds.

But is it determined solely by the cloud provider? Or is it potentially confugurable within the cloud provider?

It seems Kubernetes should have some way to ask/answer these questions that isn't heuristic based on "was it AKS?" style questions?

lblackstone commented 5 years ago

Yes, it completely depends on the cloud provider's implementation for provisioning cloud resources. This one is for LoadBalancers, but resources like PVs, Ingress, etc., are also subject to differences.

A strong concept of cluster identity is sorely lacking upstream. cc @hausdorff