Why should you care about Istio Gateway

This article is reprinted from: ServiceMesher

If you want to break down the monolithic architecture, a big advantage of using Istio to manage your microservices is that it takes advantage of the configuration of an entry model similar to that of traditional load balancers and application distribution controllers.

In the load balancer world, virtual IP and virtual servers have long been considered concepts that enable operators to configure inbound traffic in a flexible and scalable manner (Lori Macvittie has some thoughts on this).

In Istio, the Gateway controls service exposure at the edge of the grid. Gateway allows users to specify L4-L6 Settings, such as port and TLS Settings. For L7 Settings of Ingress traffic, Istio allows you to bind gateways to VirtualServices.

This separation makes it easy to manage the traffic flowing into the grid, just as virtual IP is bound to a virtual server in a traditional load balancer. This enables traditional technology stack users to migrate to microservices in a seamless manner. This is a natural progression for teams used to holistic and edge load balancers, without having to consider radically new ways of configuring networks.

One thing to note is that routing traffic in a service grid is different from bringing external traffic into the grid. In the grid, you can distinguish between abnormal parts of normal traffic because Istio can communicate with all applications (compatible with Kubernetes) by default as long as they are in the service grid. If you do not want to communicate with certain services, you must add policies. A reverse proxy (similar to a traditional load balancer) captures the traffic coming into the grid, and you must specify exactly which traffic is allowed into the grid.

Earlier versions of Istio utilized Kubernetes’ Ingress resources, but the recently released Istio V1 Alpha3 API leverages Gateway to provide richer functionality, as Kubernetes Ingress has proven inadequate to meet the requirements of Istio applications. The Kubernetes Ingress API combines the specifications of L4-6 and L7, which makes it difficult for different teams in an organization with separate trust domains, such as SecOps and NetOps, to have Ingress traffic management.

In addition, the Ingress API is not as expressive as Istio’s routing capabilities for Envoy. The only way to do advanced routing in the Kubernetes Ingress API is to add annotations for different entry controllers. Separate concerns and trust domains within an organization require a more efficient way to manage entry points, which can be accomplished by Istio Gateway and VirtualServices.

Once traffic enters the grid, it is a good idea to provide separate concerns for VirtualServices so that different teams can manage traffic routing for their services. The L4-L6 specification is usually something that SecOps or NetOps might care about. The L7 specification is of primary concern to cluster operators or application owners. Therefore, a proper separation of concerns is critical.

Because we believe in the power of team responsibility, we think this is an important competency. Because we believe in the power of Istio, we are committing RFE to the Istio community, which will help enable ownership semantics for traffic management within the grid.

We are pleased that Istio has released version 1.0 and are happy to continue contributing to the project and the community.