Kubernetes NGINX Ingress vs Istio Ingress Gateway

To handle traffic in web applications, architects can use any networking software capable of understanding the L7 layer- for managing HTTP requests. The networking software can be a mix of the following things:

• [Application/network] load balancers
• API gateway
• Ingress controllers (for Kubernetes workloads only)

With the growing adoption of Kubernetes around 2020, DevOps and architects started using Ingress controllers to handle traffic into their container workloads. Some organizations may use a mix of application load balancers (ALB), API gateway, and Ingress controllers; or just ingress. 

Please note: For ingress to work, one has to deploy an ingress controller in a cluster. Since Kubernetes as a project maintains AWS, GCE, and NGINX ingress controllers– these are also assumed as default Kubernetes ingress controllers. Throughout this blog, we will refer to NGINX ingress as the default Kubernetes ingress. Other players in the market that provide ingress controllers are HAProxy, Ambassador, Kong, Traefik, Istio, etc. 

Istio service mesh has recently been widely accepted to abstract the communication among microservices and simplify and secure the communication. Out of many compelling capabilities, Istio also provides its ingress controller. This article will explain the difference between Istio ingress and Kubernetes ingress. 

( In case you are interested, check API gateway vs Istio gateway)

Brief intro to Kubernetes NGINX Ingress

Kubernetes Ingress is an API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination, and name-based virtual hosting.

Features of Kubernetes NGINX Ingress

Kubernetes NGINX Ingress supports Kubernetes workloads natively and can easily be set up for load-balancing capabilities. 

• Integrated into Kubernetes; no other components are required
• Basic load balancing and routing capability are provided
• Easy to set up and utilize for simple use cases
• It can be supplemented with third-party plugins.
• Integrates with other Kubernetes resources like ConfigMaps and Secrets.

Limitations of Kubernetes NGINX Ingress

Kubernetes Ingress is a lightweight gateway for workloads and cannot handle advanced use-cases. Before using an Ingress, DevOps folks should consider the future demands in the ecosystem rather than myopic at the use-case at hand. The following are the limitations of Kubernetes Ingress:

• It operates only in the L7 layer and does not support L4 and L5. 
• NGINX Ingress is slow in catering to multiple requests per second. 
• mTLS within the cluster can be “painfully” achieved. HAProxy K8s Ingress provides ootb mTLS implementation only for traffic between ingress and back-end servers it caters to.
• In terms of traffic management and routing features, Kubernetes NGINX Ingress is less powerful
• Poor capability in terms of observability and telemetry

Watch the demo video on Kubernetes NGINX Ingress vs Istio Ingress

Introduction to Istio Ingress

Istio is the widely accepted open-source service mesh for managing and securing the communication between services and at the edge. Istio provides a data plane based on Envoy proxy, which can handle service-to-service communication. The Envoy proxy supports L3/L4 and L7 layers, and the same proxy is also used for Istio Ingress. 

Note: Istio offers both an Ingress controller and a Gateway. While writing this blog, Istio released 1.18.X; Istio provides the Istio Ingress for traffic management by default during the installation. Istio Gateway, which is based on Kubernetes Gateway API, is still in beta at the time of the writing this blog. 

Istio Ingress (Istio ingress gateway) and Istio Gateway can operate at the L4 and L7 layers to manage and secure traffic in cloud-native applications. The Istio committee led by Google and IBM has decided to provide the Istio gateway (built on top of Kubernetes gateway API) as a default resource for handling traffic at the edge. Refer the below image for sample implementation of Istio ingress.

In the next section, we will discuss only Istio Ingress, which is the default gateway until the Istio 1.18.X version. Istio Gateway and Istio Ingress support TCP, HTTPS, gRPC, etc.

Advantage of Istio Ingress Gateway

Since the Istio ingress gateway is part of the Istio service mesh, it has many features and extensibility. The list of features which can help architects in their app modernization journey are mentioned below. 

• Istio ingress gateway provides advanced traffic management and routing capabilities.
  • rate limiting
  • circuit breaking
  • failover, etc.
• Since Istio ingress uses Envoy, you can manipulate HTTP headers for requests and responses via Envoy
• Provides strong out-of-the-box security features like mTLS and access controls 
• Extensible policy controls for network and security management 
• Offers extensive telemetry and observability options
• Multiple load-balancing techniques and protocols are supported
  

Istio Ingress Gateway resources

Istio Ingress Gateway provides resources to carry certain network and security functionalities. The resources are:

1. Istio Gateway: Istio gateway resource is used to receive traffic from external sources. If you want to implement certificates for TLS authentication, Istio gateway resources can be implemented. 
2. Virtual Service: The Virtual Service resource is configured to route the traffic the gateway receives to back-end services. 
3. Destination Rule: The Destination rule defines the variations in deployments in Kubernetes and implements advance deployment strategies such as canary or blue/green. 

Tabular Summary of Nginx Ingress vs Istio Ingress Gateway

As per our experience, architects and engineering managers evaluate ingress gateway based on 3 critical dimensions- Network management, security management, and observability. The difference between the Nginx ingress controller vs Istio ingress gateway is mentioned below.

Conclusion

To conclude, you can use any Kubernetes Ingress controller, such as NGINX, but architects and the DevOps team must evaluate their future needs. If you are a small startup or a small project with 4-5 developers, then any ingress controllers would make sense; and the Istio ingress gateway is just another ingress controller. 

However, suppose you are a medium or large enterprise and prioritize security. In that case, the Istio ingress gateway should be considered instead of any Kubernetes ingress controller such as NGINX. If you want to extend the security from edge to all the service-to-service, then the same Istio data plane can be used; which would be easy without needing external tools or additional configurations. 

If you need advanced API management functionality in the Istio ingress gateway, such as billing visibility, protocol conversion, or integration with 3rd party Authn/z providers, then IMESH can help you.

About IMESH

IMESH helps advanced companies, unicorns and rocketship startups to implement Istio service mesh without any hassle. Simplify the communication of your microservices and achieve zero trust security with Istio. IMESH helps you in achieving enterprise-wide visibility of network performance, network logs, and security with service mesh. 
Talk to one of our Istio experts today.