Migrate off deprecated Service .spec.externalIPs (Kubernetes 1.36 deprecation)

Summary

Kubernetes 1.36 deprecates the Service .spec.externalIPs field (upstream KEP/issue kubernetes/kubernetes#137293). This is warning-only:

  • The field is not removed, has no removal date, and remains a GA field.
  • Applying a Service that sets .spec.externalIPs on K8s 1.36 now emits a deprecation warning, but functionality is unchanged.

No action was required for the 1.36 support bump itself (see gitlab-org/distribution/team-tasks#1829 / the support MR below) — this issue tracks the eventual migration so we're not caught out if/when upstream schedules removal.

Where the chart uses externalIPs

  • gitlab-pages custom domains — charts/gitlab/charts/gitlab-pages/templates/service-custom-domains.yaml renders externalIPs: {{ toJson $externalAddresses }} when the custom-domains feature is enabled. This is the one path that populates the field as part of normal operation (conditional on the feature).
  • gitlab-shell — charts/gitlab/charts/gitlab-shell/templates/service.yaml renders externalIPs only when the user sets .Values.service.externalIPs (commented out / empty by default → opt-in).
  • nginx-ingress (bundled subchart) — controller / metrics / webhook / default-backend / internal services all expose an externalIPs value that defaults to [] (opt-in).

Impact today

Low. Only the gitlab-pages custom-domains path emits the field by default (and only with that feature on); everything else is opt-in. On K8s 1.36 users of those paths will see a deprecation warning at apply time — no functional break.

Proposed follow-up

  • Track the upstream deprecation (kubernetes/kubernetes#137293) for a removal timeline / recommended replacement.
  • Plan a migration for the gitlab-pages custom-domains path (the only non-opt-in usage) to whatever upstream recommends as the successor before any removal lands.
  • Revisit the opt-in gitlab-shell / nginx-ingress values at the same time (likely just docs guidance).

Related