<p>I am having issues in my current Kubernetes minikube set up getting pods to connect to ClusterIP services. My current setup environment looks like this:</p>
<pre><code>OS: Rocky Linux 8 Guest Hosted with VMware on a Windows 10 Machine
VMware has 'Virtualize Intel VT-x/EPT or AMD-V/RVI' enabled
Minikube (v1.24.0) is running with docker (Docker version 20.10.11, build dea9396) as its driver
</code></pre>
<p>To isolate the problem I have started using this simple <a href="https://github.com/rogertinsley/golang-k8s-helloworld" rel="nofollow noreferrer">golang hello world image</a>. Simply put, if you <code>wget url:8080</code> you will download an index.html.</p>
<p>After building the image locally I create a pod with:</p>
<p><code>kubectl run hello --image=hello --port=8080 --labels='app=hello'</code></p>
<p>The pod spins up fine, and I can exec into it. Inside the pod, if I run:</p>
<p><code>wget localhost:8080</code> or <code>wget 172.17.0.3:8080</code></p>
<p>I get the expected output of:</p>
<pre><code>converted 'http://172.17.0.3:8080' (ANSI_X3.4-1968) -&gt; 'http://172.17.0.3:8080' (UTF-8)
--2022-01-09 20:15:44--  http://172.17.0.3:8080/
Connecting to 172.17.0.3:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13 [text/plain]
Saving to: 'index.html'

index.html                                   100%[==============================================================================================&gt;]      13  --.-KB/s   in 0s     

2022-01-09 20:15:44 (3.11 MB/s) - 'index.html' saved [13/13]
</code></pre>
<p>Now, if I expose the pod with: <code>kubectl expose pod hello --name=hello-service --port=8080 --target-port=8080</code> the service is started as <code>hello-service</code> and describing it outputs the following:</p>
<pre><code>Name:              hello-service
Namespace:         default
Labels:            app=hello
Annotations:       &lt;none&gt;
Selector:          app=hello
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.101.73.45
IPs:               10.101.73.45
Port:              &lt;unset&gt;  8080/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.3:8080
Session Affinity:  None
Events:            &lt;none&gt;
</code></pre>
<p>The ports are set and the Endpoint exists, so from everything I've read this should work. So I exec back into the pod and try to wget the service and I get:</p>
<pre><code>root@hello:/go/src/app# wget hello-service:8080
converted 'http://hello-service:8080' (ANSI_X3.4-1968) -&gt; 'http://hello-service:8080' (UTF-8)
--2022-01-09 20:36:06--  http://hello-service:8080/
Resolving hello-service (hello-service)... 10.101.73.45
Connecting to hello-service (hello-service)|10.101.73.45|:8080... failed: Connection timed out.
</code></pre>
<p>The same happens when I try <code>wget 10.101.73.45:8080</code>, which of course makes sense because hello-service resolved to the correct IP in the previous wget.</p>
<p>Now, I'm no expert at Kubernetes, obviously, but this next part is weird to me. If I instead expose the pod with a nodePort, everything works as you would expect. Using the following definition file:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  selector:
    app: hello
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 8080
    nodePort: 31111
  type: NodePort
</code></pre>
<p>I can hit the pod from the nodePort. A simple <code>wget 192.168.49.2:31111</code> and I get the expected output:</p>
<pre><code>--2022-01-09 15:00:48--  http://192.168.49.2:31111/
Connecting to 192.168.49.2:31111... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13 [text/plain]
Saving to: ‘index.html’

index.html                                   100%[============================================================================================&gt;]      13  --.-KB/s    in 0s      

2022-01-09 15:00:48 (3.05 MB/s) - ‘index.html’ saved [13/13]
</code></pre>
<p>Anyway, I'm at my amateur wits end here. It's been a few days of trying to find similar issues that we're not just &quot;oh you did not label your container correctly&quot; or &quot;there is a typo in your port listings&quot; with little luck. I think this situation is unique enough to warrant its post.</p>

A. Diaz
<p>I've found minikube-based services do not allow a pod to get redirected back to itself, causing the timeout.  By increasing your replicas to 2, the service-url curl no longer times out as the sibling pod can then be reached.</p>
