ingress-nginx: Helm Chart installs fails with: metadata.name must be no more than 63 characters

We see this problem too, maybe I can help you understand why it’s an issue.

By default ingress-nginx helm chart will create admission service (and the others also, just admission is the longest at the moment) based on helm release name. For example I want to name my ingress-nginx helm release like:

• development-webshop-backend01
• development-webshop-backend02
• development-webshop-fe01
• development-webshop-fe02

In this case helm try to create services with names like this:

• development-webshop-backend01-ingress-nginx-controller-admission
• development-webshop-backend02-ingress-nginx-controller-admission
• development-webshop-fe01-ingress-nginx-controller-admission
• development-webshop-fe02-ingress-nginx-controller-admission

But it will fail on the backends because those service names are 65 characters long, because -admission and the other service name suffix added AFTER trimming the fullname at max 63 characters. Also another “problem” if you count the character numbers we have 28 chars max from the possible max 63 (less then 45% is usable because the static long names in helm chart).

Found there are 2 values that could help make it longer: fullnameOverride - this gives the ‘<release name>-ingress-nginx’ part in names controller.name - this gives the ‘controller’ part in names

so shortening those two to like: fullnameOverride: development-webshop-backend01 controller.name: ingrctrl

service names will be like this:

• development-webshop-backend01-ingrctrl-admission

which is only 49 characters, even could make it shorter a bit, but couldn’t change ‘admission’ (and metric, internal) static names.

So I guess documentation needs to describe bit more these service naming conventions, because there is a 63 character lenght limit which could be reached easily. Also would be nice to set ‘admission’, ‘metrics’ and ‘internal’ naming with variables, so if needed could be override.

The other issue, that if (without -admission etc.) names lenghts over 63 char it will be stripped and not the total generated names checked if it’s over 63 chars. So name will be stripped at 63 char but after that got the ‘-admission’ suffix, the install will fail because service name is over 63 chars. Which means there is no point to strip at 63 chars, strip it at 52 chars (so with -admission it’s still 63) or better doesn’t strip at all but check before install the max lenght so someone who install it will decide how to make it shorter. Why is it problem if helm strip last x chars to make it short enough? Because if someone installing multiple instances with same prefix names that long enough to be the same after stripping, thos will collide and can’t install the second one. Like if you say strip name at 52 char (before adding ‘-admission’ suffix) and there are names containing first 52 chars the same and continous with numbers, like:

• development-wordpress-webshop-backend-release-alpha-03
• development-wordpress-webshop-backend-release-alpha-04 both names will be stripped as ‘development-wordpress-webshop-backend-release-alpha’, so when you try to install the second one it will fail as service names can’t be longer than 63 characters and you find yourself in a painful process to figure it out how much is acceptable and how you could make it longer. This could be much easier if instead of stripping long names there is a warning before actually installing anything, that full service names couldn’t be longer then 63 chars which is constructed from this and this and this, so try to shorten it with those variables.

I am not sure if we are on the same page.

In https://github.com/kubernetes/ingress-nginx/blob/helm-chart-3.34.0/charts/ingress-nginx/templates/_helpers.tpl#L38 is the function ingress-nginx.controller.fullname with the content:

{{- printf "%s-%s" (include "ingress-nginx.fullname" .) .Values.controller.name | trunc 63 | trimSuffix "-" -}}

This function is truncating the name to 63 characters already and is being used inside the templates of the helm chart. So far so good.

BUT in the following templates a suffix gets added and this exceeds the max length restriction again. https://github.com/kubernetes/ingress-nginx/blob/helm-chart-3.34.0/charts/ingress-nginx/templates/controller-service-internal.yaml#L15

name: {{ include "ingress-nginx.controller.fullname" . }}-internal

https://github.com/kubernetes/ingress-nginx/blob/helm-chart-3.34.0/charts/ingress-nginx/templates/controller-service-metrics.yaml#L14

name: {{ include "ingress-nginx.controller.fullname" . }}-metrics

https://github.com/kubernetes/ingress-nginx/blob/helm-chart-3.34.0/charts/ingress-nginx/templates/controller-service-webhook.yaml#L11

name: {{ include "ingress-nginx.controller.fullname" . }}-admission

So even if I would make sure not to exceed the limit by truncating down to 63 characters it will continue failing! Please, read the code I provided.

I can’t solve this on my end.

We’re also seeing this issue, any idea when this will be resolved?

Fundamentally no fields with a max length should be created by concatenating two strings together unless the combined max length of these strings cannot exceed the total max length. To solve this it looks like the arbitrary strings (such as “admission”) could be shortened and helper functions could be added to make the strings in question both valid and unique.

I have given you the reason. This restriction is not on ingress-nginx, but on Kubernetes

Deeper, this is because following rfc1123 https://datatracker.ietf.org/doc/html/rfc1123 So there is nothing we can do here.

To what length should I shorten it?

Needs to be shorter than 63

@philnichol sure! Thanks!

As @blackluck said https://github.com/kubernetes/ingress-nginx/issues/7442#issuecomment-917402076

• We can set some suffixes as configurable items.

Of course, adding the validation you mentioned is also possible. Determine whether the final generated length exceeds 63