<p>I have configured a web application pod exposed via apache on port 80. I'm unable to configure a service + ingress for accessing from the internet. The issue is that the backend services always report as UNHEALTHY.</p>

<p>Pod Config:</p>

<pre><code>apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    name: webapp
  name: webapp
  namespace: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      name: webapp
  template:
    metadata:
      labels:
        name: webapp
    spec:
      containers:
      - image: asia.gcr.io/my-app/my-app:latest
        name: webapp
        ports:
        - containerPort: 80
          name: http-server
</code></pre>

<p>Service Config:</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  type: NodePort
  selector:
    name: webapp
  ports:
    - protocol: TCP
      port: 50000
      targetPort: 80
</code></pre>

<p>Ingress Config:</p>

<pre><code>kind: Ingress
metadata:
  name: webapp-ingress
spec:
  backend:
    serviceName: webapp-service
    servicePort: 50000
</code></pre>

<p>This results in backend services reporting as UNHEALTHY.</p>

<p>The health check settings:</p>

<pre><code>Path: /
Protocol: HTTP
Port: 32463
Proxy protocol: NONE
</code></pre>

<p>Additional information: I've tried a different approach of exposing the deployment as a load balancer with external IP and that works perfectly. When trying to use a NodePort + Ingress, this issue persists.</p>

<p>With GKE, the health check on the Load balancer is created automatically when you create the ingress. Since the HC is created automatically, so are the firewall rules.</p>

<p>Since you have no readinessProbe configured, the LB has a default HC created (the one you listed). To debug this properly, you need to isolate where the point of failure is.</p>

<p>First, make sure your pod is serving traffic properly;</p>

<p><code>kubectl exec [pod_name] -- wget localhost:80</code>  </p>

<p>If the application has <code>curl</code> built in, you can use that instead of <code>wget</code>.
If the application has neither wget or curl, skip to the next step.</p>

<ol>
<li>get the following output and keep track of the output:

<blockquote>
  <p>kubectl get po -l name=webapp -o wide<br>
  kubectl get svc webapp-service</p>
</blockquote></li>
</ol>

<p>You need to keep the service and pod clusterIPs</p>

<ol start="2">
<li><p>SSH to a node in your cluster and run <code>sudo toolbox bash</code></p></li>
<li><p>Install curl:</p></li>
</ol>

<blockquote>
  <p>apt-get install curl`</p>
</blockquote>

<ol start="4">
<li>Test the pods to make sure they are serving traffic within the cluster:</li>
</ol>

<blockquote>
  <p>curl -I [pod_clusterIP]:80</p>
</blockquote>

<p>This needs to return a 200 response</p>

<ol start="5">
<li>Test the service:</li>
</ol>

<blockquote>
  <p>curl -I [service_clusterIP]:80</p>
</blockquote>

<p>If the pod is not returning a 200 response, the container is either not working correctly or the port is not open on the pod.   </p>

<p>if the pod is working but the service is not, there is an issue with the routes in your iptables which is managed by kube-proxy and would be an issue with the cluster.  </p>

<p>Finally, if both the pod and the service are working, there is an issue with the Load balancer health checks and also an issue that Google needs to investigate.</p>
