<p>To preface this I’m working on the GCE, and Kuberenetes.  My goal is simply to expose all microservices on my cluster over SSL.  Ideally it would work the same as when you expose a deployment via type=‘LoadBalancer’ and get a single external IP. That is my goal but SSL is not available with those basic load balancers.  </p>

<p>From my research the best current solution would be to set up an nginx ingress controller, use ingress resources and services to expose my micro services.  Below is a diagram I drew up with my understanding of this process.  </p>

<p><a href="https://i.stack.imgur.com/bGt6B.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/bGt6B.png" alt="enter image description here"></a></p>

<p>I’ve got this all to successfully work over HTTP.  I deployed the default nginx controller from here: <a href="https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx" rel="nofollow noreferrer">https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx</a> .  As well as the default backend and service for the default backend.  The ingress for my own micro service has rules set as my domain name and path: /.  </p>

<p>This was successful but there were two things that were confusing me a bit.  </p>

<ol>
<li><p>When exposing the service resource for my backend (microservice) one guide I followed used type=‘NodePort’ and the other just put a port to reach the service.  Both set the target port to the backend app port.  I tried this both ways and they both seemed to work.  Guide one is from the link above.  Guide 2: <a href="http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html" rel="nofollow noreferrer">http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html</a>.  What is the difference here?</p></li>
<li><p>Another point of confusion is that my ingress always gets two IPs.  My initial thought process was that there should only be one external ip and that would hit my ingress which is then directed by nginx for the routing.  Or is the ip directly to the nginx? Anyway the first IP address created seemed to give me the expected results where as visiting the second IP fails.</p></li>
</ol>

<p>Despite my confusion things seemed to work fine over HTTP.  Over HTTPS not so much. At first when I made a web request over https things would just hang.  I opened 443 on my firewall rules which seemed to work however I would hit my default backend rather than my microservice.</p>

<p>Reading led me to this from Kubernetes docs:  Currently the Ingress resource only supports http rules. 
This may explain why I am hitting the default backend because my rules are only for HTTP.  But if so how am I supposed to use this approach for SSL?</p>

<p>Another thing I noticed is that if I write an ingress resource with no rules and give it my desired backend I still get directed to my original default backend.  This is even more odd because kubectl describe ing updated and states that my default backend is my desired backend...</p>

<p>Any help or guidance would be much appreciated.  Thanks!</p>

<p>So, for #2, you've probably ended up provisioning a Google HTTP(S) LoadBalancer, probably because you're missing the <code>kubernetes.io/ingress.class: "nginx"</code> annotation as described here: <a href="https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers" rel="noreferrer">https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers</a>. </p>

<p>GKE has it's own ingress controller that you need to override by sticking that annotation on your nginx deployment. <a href="https://beroux.com/english/articles/kubernetes/?part=3" rel="noreferrer">This article</a> has a good explanation about that stuff.</p>

<p>The <a href="https://kubernetes.io/docs/user-guide/services/#type-nodeport" rel="noreferrer">kubernetes docs</a> have a pretty good description of what <code>NodePort</code> means - basically, the service will allocate a port from a high range on each Node in your cluster, and Nodes will forward traffic from that port to your service. It's one way of setting up load balancers in different environments, but for your approach it's not necessary. You can just omit the <code>type</code> field of your microservice's Service and it will be assigned the default type, which is <code>ClusterIP</code>.</p>

<p>As for SSL, it could be a few different things. I would make sure you've got the Secret set up just as they describe in the <a href="https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#https" rel="noreferrer">nginx controller docs</a>, eg with a <code>tls.cert</code> and <code>tls.key</code> field.</p>

<p>I'd also check the logs of the nginx controller - find out which pod it's running as with <code>kubectl get pods</code>, and then tail it's logs: <code>kubectl logs nginx-pod-&lt;some-random-hash&gt; -f</code>. This will be helpful to find out if you've misconfigured anything, like if a service does not have any endpoints configured. Most of the time I've messed up the ingress stuff, it's been due to some pretty basic misconfiguration of Services/Deployments. </p>

<p>You'll also need to set up a DNS record for your hostname pointed at the LoadBalancer's static IP, or else ping your service with cURL's <code>-H</code> <a href="https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#http" rel="noreferrer">flag as they do in the docs</a>, otherwise you might end up getting routed to the default back end 404.</p>
