[
https://issues.apache.org/jira/browse/FLINK-16025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Canbin Zheng updated FLINK-16025:
---------------------------------
Description:
The Service would always expose 6124 port if it should expose that port, and
while building ServicePort we do not explicitly specify a target port, so the
target port would always be 6124 too.
{code:java}
// From ServiceDecorator.java
servicePorts.add(getServicePort(
getPortName(BlobServerOptions.PORT.key()),
Constants.BLOB_SERVER_PORT));
private ServicePort getServicePort(String name, int port) {
return new ServicePortBuilder()
.withName(name)
.withPort(port)
.build();
}
{code}
meanwhile, the Container of the JM would expose the blob server port which is
configured in the Flink Configuration,
{code:java}
// From FlinkMasterDeploymentDecorator.java
final int blobServerPort = KubernetesUtils.parsePort(flinkConfig,
BlobServerOptions.PORT);
...
final Container container = createJobManagerContainer(flinkConfig, mainClass,
hasLogback, hasLog4j, blobServerPort);
{code}
so there is a risk that in non-HA mode the TM could not execute Task due to
dependencies fetching failure if the Service exposes a blob server port which
is different from the JM Container when one configures the blob server port
with a value different from 6124.
was:
The Service would always expose 6124 port if it should expose that port, and
while building ServicePort we do not explicitly specify a target port, so the
target port would always be 6124 too.
{code:java}
// From ServiceDecorator.java
servicePorts.add(getServicePort(
getPortName(BlobServerOptions.PORT.key()),
Constants.BLOB_SERVER_PORT));
private ServicePort getServicePort(String name, int port) {
return new ServicePortBuilder()
.withName(name)
.withPort(port)
.build();
}
{code}
meanwhile the Container of the JM would expose the blob server port which is
configured in the Flink Configuration,
{code:java}
// From FlinkMasterDeploymentDecorator.java
final int blobServerPort = KubernetesUtils.parsePort(flinkConfig,
BlobServerOptions.PORT);
...
final Container container = createJobManagerContainer(flinkConfig, mainClass,
hasLogback, hasLog4j, blobServerPort);
{code}
so there is a risk that the TM could not executing Task due to dependencies
fetching failure if the Service exposes a blob server port which is different
from the JM Container when one configures the blob server port with a value
different from 6124.
> Service could expose different blob server port mismatched with JM Container
> ----------------------------------------------------------------------------
>
> Key: FLINK-16025
> URL: https://issues.apache.org/jira/browse/FLINK-16025
> Project: Flink
> Issue Type: Bug
> Components: Deployment / Kubernetes
> Affects Versions: 1.10.0
> Reporter: Canbin Zheng
> Priority: Critical
> Fix For: 1.10.1, 1.11.0
>
>
> The Service would always expose 6124 port if it should expose that port, and
> while building ServicePort we do not explicitly specify a target port, so the
> target port would always be 6124 too.
> {code:java}
> // From ServiceDecorator.java
> servicePorts.add(getServicePort(
> getPortName(BlobServerOptions.PORT.key()),
> Constants.BLOB_SERVER_PORT));
> private ServicePort getServicePort(String name, int port) {
> return new ServicePortBuilder()
> .withName(name)
> .withPort(port)
> .build();
> }
> {code}
>
> meanwhile, the Container of the JM would expose the blob server port which is
> configured in the Flink Configuration,
> {code:java}
> // From FlinkMasterDeploymentDecorator.java
> final int blobServerPort = KubernetesUtils.parsePort(flinkConfig,
> BlobServerOptions.PORT);
> ...
> final Container container = createJobManagerContainer(flinkConfig, mainClass,
> hasLogback, hasLog4j, blobServerPort);
> {code}
>
> so there is a risk that in non-HA mode the TM could not execute Task due to
> dependencies fetching failure if the Service exposes a blob server port which
> is different from the JM Container when one configures the blob server port
> with a value different from 6124.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
