Added an option to explictly override the name of the created Kubernetes service

danielmittelman commented 3 years ago

This PR adds the ability to explicitly define the name of the created Service object, to allow engineers to align their service name to their organization's naming conventions (spoken from personal experience).

The new behavior is as follows:

If service.nameOverride is not defined, defined as an empty value or an empty string (as is in the default values.yaml file in this repo), the name will default to the original generated value of ambassador.fullname
Otherwise, the Service will be created with the provided name

Services that were created with a previous version of this chart will not be affected by this change

danielmittelman commented 3 years ago

@nbkrause Can this PR be reviewed and considered for merge?

iNoahNothing commented 3 years ago

@danielmittelman Thanks for submitting this PR.

I am interested in what the usecase for this is and why you would want to have the Service name differ from the name of the Deployment and the rest of the resources managed by the chart.

danielmittelman commented 3 years ago

@nbkrause We have a multi-cluster, multi-regional architecture where each region is an isolated failure domain, and applications are deployed identically across the different regions. We also have Ambassador deployed in each of our regions.

For that we have the following naming convention for Kubernetes objects:

Deployments, DaemonSets, HPAs and other objects include the region alias in their name (for example - staging-eu1-application)
Service objects do not include the region name (for example - staging-application)

The reason for that is our desire to keep Ambassador's configuration consistent across regions, since we route traffic from Ambassador to the backend application's Service, e.g.

apiVersion: getambassador.io/v2
kind:  Mapping
...
spec:
  service: http://staging-application.namespace:port

This Mapping is deployed as is in all of our regions, which spares us the need to mutate the target service FQDN in the Mapping object per region.

It also makes it easier for us to configure our applications to send requests to other applications directly (not through Ambassador). When an application sends a request to http://staging-app2.namespace, it will always be routed to the application in the same Kubernetes cluster, so we don't need to write different secrets per region

Since we want to follow that naming convention across all of our Kubernetes entities, I would like to also control Ambassador's Service name to align it to our conventions

danielmittelman commented 3 years ago

@nbkrause any chance to get a response?

datawire / ambassador-chart

Added an option to explictly override the name of the created Kubernetes service #146