[FLINK-37893][k8s] Make REST service port name configurable by 1fanwang · Pull Request #28047 · apache/flink

1fanwang · 2026-04-27T08:55:51Z

What is the purpose of the change

The Kubernetes REST service exposed by the JobManager hardcodes its port name to "rest" (Constants.REST_PORT_NAME). Operators in environments that enforce port-naming policies — for example, service meshes that route by port name, or organizations with strict port-name conventions — cannot align Flink's rest service with those policies.

This change adds a new config option kubernetes.rest-service.port-name (string, default "rest") that controls the port name on the REST Service. The default preserves existing behavior, making this a purely additive change.

Brief change log

New config option kubernetes.rest-service.port-name in KubernetesConfigOptions (default "rest")
New getter KubernetesJobManagerParameters#getRestServicePortName()
ServiceType#buildUpExternalRestService uses the configured name instead of Constants.REST_PORT_NAME
ServiceType#getRestPortFromExternalService no longer filters ports by name. Flink always builds the rest Service with a single port, so the lookup can simply return that port; this lets the reader work for any configured name without plumbing it through the abstract getRestEndpoint signature on ServiceType (which would change a public surface and require updating all subclasses).
KubernetesResourceManagerDriver#updateKubernetesServiceTargetPortIfNecessary reads the configured port name from flinkConfig when updating the rest service's target port in host-network mode

Verifying this change

This change added tests and can be verified as follows:

ExternalServiceDecoratorTest#testDefaultRestServicePortName — verifies the default port name "rest" is used when the option is unset
ExternalServiceDecoratorTest#testCustomRestServicePortName — verifies a custom port name ("flink-rest") propagates to the built Service
ServiceTypeTest#testGetRestPortFromExternalServiceWithDefaultName — verifies the reader works for a Service with the default port name (back-compat)
ServiceTypeTest#testGetRestPortFromExternalServiceWithCustomName — verifies the reader works for a Service with a custom port name
ServiceTypeTest#testGetRestPortFromExternalServiceFailsWhenNoPorts — verifies the error path when the Service has no ports
All 106 existing tests in the kubeclient/services/decorators packages continue to pass (mvn -pl flink-kubernetes -Dtest='*KubeClient*,*ServiceType*,*ServiceDecorator*,*JobManagerDecorator*,KubernetesResourceManagerDriverTest,KubernetesUtilsTest' test)

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): yes — KubernetesConfigOptions is @PublicEvolving. Adds a new option (additive).
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: yes — affects native Kubernetes JobManager Service builder and KubernetesResourceManagerDriver. No behavior change at default.
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? config option withDescription (auto-generated into the Flink config docs)

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

The Kubernetes REST service exposed by the JobManager hardcodes its port name to "rest" (Constants.REST_PORT_NAME). Operators in environments that enforce port-naming policies (e.g., service meshes that route by port name, or organizations with strict port-name conventions) cannot align Flink with those policies. This change adds a new config option kubernetes.rest-service.port-name (string, default "rest") that controls the port name on the REST Service. The default preserves existing behavior, making this a purely additive change. ServiceType#getRestPortFromExternalService no longer filters ports by name. Flink always builds the rest Service with a single port, so the lookup can simply return that port; this lets the reader work for any configured port name without plumbing the name through the abstract getRestEndpoint signature on ServiceType. KubernetesResourceManagerDriver#updateKubernetesServiceTargetPortIfNecessary reads the configured port name from flinkConfig when updating the rest service's target port in host-network mode.

flinkbot · 2026-04-27T09:02:12Z

CI report:

0cf59c1 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

@flinkbot run azure re-run the last Azure build

…CE_PORT_NAME The new kubernetes.rest-service.port-name option was missing from the generated config docs, which made ConfigOptionsDocsCompletenessITCase fail in the flink-docs surefire integration-tests step.

Efrat19

Thank you for this contribution
LGTM % minor notes

Efrat19 · 2026-05-06T06:47:48Z

+        final List<ServicePort> ports = externalService.getSpec().getPorts();

-        if (servicePortCandidates.isEmpty()) {
+        if (ports == null || ports.isEmpty()) {


Also if .size() > 1?

Good catch — added a check that throws when the Service has more than one port (the invariant comes from buildUpExternalRestService building exactly one). New test testGetRestPortFromExternalServiceFailsWhenMultiplePorts covers it. 0cf59c1

Efrat19 · 2026-05-06T06:57:09Z

                .withSelector(kubernetesJobManagerParameters.getSelectors())
                .addNewPort()
-                .withName(Constants.REST_PORT_NAME)
+                .withName(kubernetesJobManagerParameters.getRestServicePortName())


Could you update container port name as well?
InitJobManagerDecorator.java#L192

Done — InitJobManagerDecorator#getContainerPorts now reads the same configured name. I broadened the option's description to reflect that it covers both the Service port and the container port. New test testMainContainerRestPortNameWithCustomConfig covers it. 0cf59c1

…Service Address review feedback on the FLINK-37893 PR: - Make `kubernetes.rest-service.port-name` also apply to the JobManager container's rest port (InitJobManagerDecorator), not just the Service. Service meshes and policy engines that inspect port names end-to-end (svc -> pod -> container) need both to align. - `ServiceType#getRestPortFromExternalService` now rejects Services with more than one port. The invariant that the rest Service has exactly one port comes from `buildUpExternalRestService`; throwing on violation makes the contract explicit instead of silently picking ports.get(0). - Broaden the option's description to reflect the wider scope. - Add tests: - `InitJobManagerDecoratorTest#testMainContainerRestPortNameWithCustomConfig` - `ServiceTypeTest#testGetRestPortFromExternalServiceFailsWhenMultiplePorts` 108/108 tests pass under `./mvnw -pl flink-kubernetes -Dtest='*KubeClient*,*ServiceType*,*ServiceDecorator*,*JobManagerDecorator*,KubernetesResourceManagerDriverTest,KubernetesUtilsTest' test`.

1fanwang force-pushed the FLINK-37893-rest-service-port-name branch from fc792bc to 43d6396 Compare April 27, 2026 09:02

[FLINK-37893][docs] Regenerate kubernetes config table for REST_SERVI…

35300c8

…CE_PORT_NAME The new kubernetes.rest-service.port-name option was missing from the generated config docs, which made ConfigOptionsDocsCompletenessITCase fail in the flink-docs surefire integration-tests step.

Efrat19 reviewed May 6, 2026

View reviewed changes

github-actions Bot added the community-reviewed PR has been reviewed by the community. label May 6, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FLINK-37893][k8s] Make REST service port name configurable#28047

[FLINK-37893][k8s] Make REST service port name configurable#28047
1fanwang wants to merge 3 commits intoapache:masterfrom
1fanwang:FLINK-37893-rest-service-port-name

1fanwang commented Apr 27, 2026 •

edited

Loading

Uh oh!

flinkbot commented Apr 27, 2026 •

edited

Loading

Uh oh!

Efrat19 left a comment

Uh oh!

Efrat19 May 6, 2026

Uh oh!

1fanwang May 7, 2026

Uh oh!

Efrat19 May 6, 2026

Uh oh!

1fanwang May 7, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

1fanwang commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is the purpose of the change

Brief change log

Verifying this change

Does this pull request potentially affect one of the following parts:

Documentation

Was generative AI tooling used to co-author this PR?

Uh oh!

flinkbot commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CI report:

Uh oh!

Efrat19 left a comment

Choose a reason for hiding this comment

Uh oh!

Efrat19 May 6, 2026

Choose a reason for hiding this comment

Uh oh!

1fanwang May 7, 2026

Choose a reason for hiding this comment

Uh oh!

Efrat19 May 6, 2026

Choose a reason for hiding this comment

Uh oh!

1fanwang May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

1fanwang commented Apr 27, 2026 •

edited

Loading

flinkbot commented Apr 27, 2026 •

edited

Loading

1fanwang May 7, 2026 •

edited

Loading