You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I created a Kubernetes cluster using Terraform. Since the DigitalOcean Terraform provider does not yet support the urn attribute for the digitalocean_kubernetes_cluster resource, I manually moved the cluster and droplets to a different project. Afterwards I created an nginx ingress via Terraform and its Helm provider. The load balancer that the DigitalOcean cloud provider created for the type: LoadBalancer service of the nginx ingress Helm chart appeared in the default project.
It would be nice if the load balancer was created in the same project as the cluster, ideally following the cluster when it is moved through projects.
An alternative new feature would be to allow specifying the project as an annotation to the nginx ingress service (which I can set via the Helm chart -- I already do that for service.beta.kubernetes.io/do-loadbalancer-name, cf. https://docs.digitalocean.com/products/kubernetes/how-to/configure-load-balancers/) This could be a new service.beta.kubernetes.io/do-loadbalancer-project-name: "my-project-name" annotation.
Another alternative would be to create the load balancer using the digitalocean_loadbalancer Terraform resource, which does support the urn attribute and can thus be moved to a specific project. Afterwards I could set the kubernetes.digitalocean.com/load-balancer-id annotation on the nginx ingress service to make it use the existing load balancer instead of creating a new one. However, this would require me to configure a forwarding_rule for this resource, which would conflict with the configuration set by the cloud provider.
The text was updated successfully, but these errors were encountered:
The LB should be assigned the same project as the cluster on creation (assuming it is created through Kubernetes based mechanisms). It should also move with the cluster to the new project it gets assigned to. You will not be able to view or modify an LB via Projects (cloud webpage for your project or doctl) since it is a resource for a DOKS cluster and is expected to be interacted with through Kubernetes.
If the cluster owned LB isn't moving over and/or the LB is being created for your cluster but the LB gets assigned to the default project instead of the correct one. This is a bug. Can you please file a support ticket with this information and any screenshots you may have? Thank you very much for bringing this to our attention!
I created a Kubernetes cluster using Terraform. Since the DigitalOcean Terraform provider does not yet support the
urn
attribute for thedigitalocean_kubernetes_cluster
resource, I manually moved the cluster and droplets to a different project. Afterwards I created an nginx ingress via Terraform and its Helm provider. The load balancer that the DigitalOcean cloud provider created for thetype: LoadBalancer
service of the nginx ingress Helm chart appeared in the default project.It would be nice if the load balancer was created in the same project as the cluster, ideally following the cluster when it is moved through projects.
An alternative new feature would be to allow specifying the project as an annotation to the nginx ingress service (which I can set via the Helm chart -- I already do that for
service.beta.kubernetes.io/do-loadbalancer-name
, cf. https://docs.digitalocean.com/products/kubernetes/how-to/configure-load-balancers/) This could be a newservice.beta.kubernetes.io/do-loadbalancer-project-name: "my-project-name"
annotation.Another alternative would be to create the load balancer using the
digitalocean_loadbalancer
Terraform resource, which does support theurn
attribute and can thus be moved to a specific project. Afterwards I could set thekubernetes.digitalocean.com/load-balancer-id
annotation on the nginx ingress service to make it use the existing load balancer instead of creating a new one. However, this would require me to configure aforwarding_rule
for this resource, which would conflict with the configuration set by the cloud provider.The text was updated successfully, but these errors were encountered: