Reputation: 1060
I building a Kubernetes cluster on Google Kubernetes Engine (GKE). It is basically a Service
with an associated ReplicaSet
with a number of pods.
Those pods need to talk to each other for keeping consensus. For this end, a ClusterIP
seems a good fit, allowing intra cluster communication of the pods.
However, now I want to expose this Service to the world. My idea was to switch from ClusterIP
to NodePort
and couple it with an Ingress
, which seems to be the best practice.
My problem is that when I switch the Service
to NodePort
, I lose the internal communication of the cluster, i.e. pods can't talk to each other. As far as my understanding goes, NodePort
is a superset of ClusterIP
, so it should keep internal communication.
What am I doing wrong?
Edit with extra information:
I am referring to this example, an example of a Neo4j graph database.
The example deploys a StatefulSet
, in which pods need to communicate, among other things, for keeping consensus between the cluster.
With the provided setting, pods can talk to each other. If I change the Service to NodePort
, and fix the nodePorts
that are used (instead of choosing them randomly as it normally does), pods can no longer communicate.
Is this expected behavior, or am I missing something?
Upvotes: 1
Views: 839
Reputation: 22912
Indeed NodePort
is a superset of ClusterIP
, but to be clear, you do not need the service to be of NodePort
type for it to be exposed by IngressController. IC has access to endpoints (pods) directly, so there is no need to use anything but ClusterIP
.
Another thing is that ClusterIP service has no effect on pod-to-pod connectivity, and also it seems a bit weird that you would use service to allow consensus chatter (unless you have an svc per pod). For this kind of operations you might want to look closer at the StatefulSet concept
Upvotes: 1