[
https://issues.apache.org/jira/browse/FLINK-16602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060590#comment-17060590
]
Yang Wang commented on FLINK-16602:
-----------------------------------
> About the deployer
The deployer means an external system that is used to start/stop/manager
different user's jobs. I think in many companies, they have their own deployer.
It is used to manage the lifecycle of the whole Flink job.
Since the deployer is running inside of the K8s cluster. In this case, the
submission always happen in the K8s cluster. So we do not need
Ingress/LoadBalancer to expose the webui/restServer. And the rest service is
not necessary to be created. This is also my original intention "rest service
is optional".
> How to access the Flink dashboard for users?
The deployer will have an internal web proxy to forward all the web traffic to
the Flink jobmanager service. So i strongly suggest to leave the rest port in
the internal service. The url for the dashboard could be
http://deployer-address/flink-ui/\{cluster-id}.
> About the headless service
Since the ipvs mode is the Kubernetes recommended ways for kube proxy from 1.8.
Then i think it we could use clusterIP for the internal service. Especially
when we have the rest port in the internal service.
> Customize annotations for LB type, Security Policy, etc. for rest service
I think it is a true requirement when the users are using LB to expose the
service. However, i think it is not against with leaving the rest port in the
internal service. It is harmless and leave us more possibility.
> Rework the Service design for Kubernetes deployment
> ---------------------------------------------------
>
> Key: FLINK-16602
> URL: https://issues.apache.org/jira/browse/FLINK-16602
> Project: Flink
> Issue Type: Improvement
> Components: Deployment / Kubernetes
> Affects Versions: 1.10.0
> Reporter: Canbin Zheng
> Priority: Major
> Fix For: 1.11.0
>
>
> {color:#0e101a}At the moment we usually create two Services for a Flink
> application, one is the internal Service and the other is the so-called rest
> Service, the previous aims for forwarding request from the TMs to the JM, and
> the rest Service mainly serves as an external service for the Flink
> application. Here is a summary of the issues:{color}
> # {color:#0e101a}The functionality boundary of the two Services is not clear
> enough since the internal Service could also become the rest Service when its
> exposed type is ClusterIP.{color}
> # {color:#0e101a}For the high availability scenario, we create a useless
> internal Service which does not help forward the internal requests since the
> TMs directly communicate with the JM via the IP or hostname of the JM
> Pod.{color}
> # {color:#0e101a}Headless service is enough to help forward the internal
> requests from the TMs to the JM. Service of ClusterIP type would add
> corresponding rules into the iptables, too many rules in the iptables would
> lower the kube-proxy's efficiency in refreshing iptables while notified of
> change events, which could possibly cause severe stability problems in a
> Kubernetes cluster.{color}
>
> {color:#0e101a}Therefore, we propose some improvements to the current
> design:{color}
> # {color:#0e101a}Clarify the functionality boundary for the two Services,
> the internal Service only serves the internal communication from TMs to JM,
> while the rest Service makes the Flink cluster accessible from outside. The
> internal Service only exposes the RPC and BLOB ports while the external one
> exposes the REST port.{color}
> # {color:#0e101a}Do not create the internal Service in the high availability
> case.{color}
> # {color:#0e101a}Use HEADLESS type for the internal Service.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
