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:-).
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?
Thanks
Addressing the questions:
If you need advanced network features, such as advanced routing, circuit breaking, weighted deployments, encryption, etc., then is best to pick Istio. For "simpler" needs, where you only want to container orchestration, you can stick with Kubernetes only.
Ingress controller determines the behavior of the Ingress object, 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. Whenver you're exposing your applications via Ingress, you're using an ingress controller.
Now, it is implied that the ingress controller may do thing like service discovery or circuit breaking. This is not the case. These features are addressed by the Service Mesh (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.
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 within 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.
My short answer in my opinion is no, Istio is not a "must" in a Kubernetes cluster.
In one of the migration projects I have worked, there was already a centralized governance/control and observability. So the requirement didn't include Istio.
But, nevertheless, we had a Proof-of-Concept to evaluate which features Istio has better/worse versus our setup. Local setup of everything is possible with a Docker Desktop and a local K8s cluster.
If you assess that the microservices setup you have does not have a good inter-connectivity, governance, observability that Istio has to offer, I suggest to give it an effort to try out with a couple of your applications even just locally. You will see actual pro's and con's.