<p>If I expose a (single) web service (say <code>http://a.b.c.d</code> or <code>https://a.b.c.d</code>) on a (small) Kubernetes 1.13 cluster, what is the benefit of using <code>Ingress</code> over a <code>Service</code> of type <code>ClusterIP</code> with <code>externalIPs [ a.b.c.d ]</code> alone?</p>

<p>The address <code>a.b.c.d</code> is routed to one of my cluster nodes. <code>Ingress</code> requires installing and maintaining an <a href="https://github.com/kubernetes/ingress-nginx" rel="nofollow noreferrer">ingress controller</a>, so I am wondering when this is justified.</p>

<p>I've now come across a first concrete example where I see concrete benefit from using <code>Ingress</code> over a <code>Service</code> with <code>externalIPs</code>.</p>

<p>A private Docker registry inside a Kubernetes cluster normally requires TLS credentials. With the Docker image <code>registry:2</code> one would have to mount those credentials e.g. from a <code>ConfigMap</code> into the container and have certain environment variables in the container (e.g. <code>REGISTRY_HTTP_TLS_CERTIFICATE</code>) point to them.</p>

<p>As long as one can tolerate insecure access to the registry inside the cluster this becomes easier to mange with <code>Ingress</code>. Certificates can be put into a <code>Secret</code> which the <code>Ingress</code> resource can point to (<code>kubectl explain ingress.spec.tls.secretName</code>). There is no more need to pay alternative detailed attention to mounts or environment variables. TLS connections will be terminated at the ingress controller.</p>
