<p>I building a Kubernetes cluster on Google Kubernetes Engine (GKE). It is basically a <code>Service</code> with an associated <code>ReplicaSet</code> with a number of pods. </p>

<p>Those pods need to talk to each other for keeping consensus. For this end, a <code>ClusterIP</code> seems a good fit, allowing intra cluster communication of the pods.</p>

<p>However, now I want to expose this Service to the world. My idea was to switch from <code>ClusterIP</code> to <code>NodePort</code> and couple it with an <code>Ingress</code>, which seems to be the <a href="https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer#background" rel="nofollow noreferrer">best practice</a>.</p>

<p>My problem is that when I switch the <code>Service</code> to <code>NodePort</code>, I lose the internal communication of the cluster, i.e. pods can't talk to each other. As far as my understanding goes, <code>NodePort</code> <a href="https://stackoverflow.com/a/41510604/4766124">is a superset of <code>ClusterIP</code></a>, so it should keep internal communication.</p>

<p>What am I doing wrong?</p>

<hr>

<p>Edit with extra information:</p>

<p>I am referring to <a href="https://github.com/neo4j-contrib/kubernetes-neo4j" rel="nofollow noreferrer">this example</a>, an example of a Neo4j graph database.</p>

<p>The example deploys a <code>StatefulSet</code>, in which pods need to communicate, among other things, for keeping consensus between the cluster.</p>

<p>With the provided setting, pods can talk to each other. If I change the <a href="https://github.com/neo4j-contrib/kubernetes-neo4j/blob/master/cores/dns.yaml" rel="nofollow noreferrer">Service</a> to <code>NodePort</code>, and fix the <code>nodePorts</code> that are used (instead of choosing them randomly as it normally does), pods can no longer communicate.</p>

<p>Is this expected behavior, or am I missing something?</p>

<p>Indeed <code>NodePort</code> is a superset of <code>ClusterIP</code>, but to be clear, you do not need the service to be of <code>NodePort</code> type for it to be exposed by IngressController. IC has access to endpoints (pods) directly, so there is no need to use anything but <code>ClusterIP</code>.</p>

<p>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 <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a> concept</p>
