[
https://issues.apache.org/jira/browse/FLINK-20830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480572#comment-17480572
]
Aitozi commented on FLINK-20830:
--------------------------------
Hi [~chesnay], [~wangyang0918], Sorry for bring up discussion again.
Although, the {{HEADLESS_CLUSTER_IP}} is not a concrete service type, but as
described in
[headless-services|https://kubernetes.io/docs/concepts/services-networking/service/#headless-services],
it's naturally supported by kubernetes, and it's an variant of {{Cluster_IP}}
which only depend on the dns server to do the routing.
In my test (a jobManager with exposed by the {{{}Headless_ClusterIP{}}}), It
can work well with Flink. Can we add support of expose the rest service with
type of \{{Headless_ClusterIP? }}If no objection, I can submit a pr for it.
Besides, after introduce the {{{}Headless_ClusterIP{}}}, I found the logic is a
bit mess, because we have to do some special process for {{Headless_ClusterIP}}
and {{ClusterIP}} and {{LoadBalancer}} when we get endpoint from it . So I
proposal to refactor this part to introduce the abstract class {{ServiceType}}
to represent the service type that Flink supported. It's in charge of the
* build, create a k8s service
* getEndpoint from a k8s service
* getRestPort from a k8s service
In this way, we can quite simplify the {{{}Fabric8FlinkKubeClient{}}}, And move
the service create and query logic to the serval subtype of {{ServiceType. }}
Looking forward to your ideas, Thanks.
> Add a type of HEADLESS_CLUSTER_IP for rest service type
> -------------------------------------------------------
>
> Key: FLINK-20830
> URL: https://issues.apache.org/jira/browse/FLINK-20830
> Project: Flink
> Issue Type: Improvement
> Components: Deployment / Kubernetes
> Reporter: Aitozi
> Priority: Not a Priority
> Labels: auto-deprioritized-major, auto-deprioritized-minor
>
> Now we can choose ClusterIP or NodePort or LoadBalancer as rest service type.
> But in our internal kubernetes cluster, there is no kube-proxy, and ClusterIP
> mode rely on kube-proxy. So I think can we support another type of
> HEADLESS_CLUSTER_IP to directly talk to jobmanager pod? cc [~fly_in_gis]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
