<p>We are trying to re-architect our Microservices and move them into Docker containers. We are going to use Kubernetes to orchestrate Containers. We have made some investigations on how should we use different technologies in combination with Kubernetes among others Istio to have the best of everything:-).</p>

<p>However the more we read on Internet, the more we become confused. We know that Kubernetes has ingress and “ingress controller” and to our understanding Istio maybe is better when it comes to inter-service communication and it addresses among others service discovery and circuit breaker challenges. But we don’t know if we can address all these problems by using only Kubernetes ingress?</p>

<ol>
<li>Why and when should (should not) you use Istio with  Kubernetes?</li>
<li>Why and when should you use ingress controller? </li>
</ol>

<p>Thanks </p>

user217648
<p>Addressing the questions:</p>

<ol>
<li><p>If you need <a href="https://istio.io/docs/concepts/what-is-istio/" rel="nofollow noreferrer">advanced network features</a>, such as advanced routing, circuit breaking, weighted deployments, encryption, etc., then is best to pick Istio. For "<em>simpler</em>" needs, where you only want to container orchestration, you can stick with Kubernetes only.</p></li>
<li><p>Ingress controller determines the behavior of the <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">Ingress object</a>, which in turn is used to expose the applications running within the cluster. This means that, each ingress controller has a different set of options/features, generally tied to layer 7 operations. <a href="https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/" rel="nofollow noreferrer">Whenver you're exposing your applications via Ingress, you're using an ingress controller</a>.</p></li>
</ol>

<p>Now, it is implied that the ingress controller <em>may</em> do thing like service discovery or circuit breaking. This is not the case. These features are addressed by the <a href="https://www.nginx.com/blog/what-is-a-service-mesh/" rel="nofollow noreferrer">Service Mesh</a> (Istio is one product that creates one within the cluster) and the goal of the Ingress object is to expose and often do some routing the services within the cluster.</p>

<p>You can think of Ingress as a gateway, allowing incoming connections in the cluster, path-based routing and SSL-termination. So it's basically running as an access point, whereas Istio will be running <em>within</em> the internal network, managing connections between the services without exposing them (although it can through ingressgateway), and adding a set of advanced routing features in the internal network.</p>
