North-South Traffic Management of Istio Gateways (with Answers from Service Mesh Experts)

Istio Gateway

The term “ingress” in the Internet community refers to the management of traffic from external access requests to services in a cluster. Ingress refers to the traffic originating from outside the local network and pointing to endpoints in the local cluster network. The traffic is first routed to public entries so that some local network rules and policies are enforced to determine which traffic is allowed to pass through. If traffic is not allowed to pass through these entries, it cannot connect to any services in the cluster. If the entries allow traffic to enter, they route the traffic to the appropriate nodes in the local network through proxies. An Istio gateway manages the ingress traffic.

How an Istio Gateway Works

Traditionally, Kubernetes uses Ingress controllers to handle traffic from the outside to the cluster. This is no longer the case while using Istio. Istio gateways use new Gateway resources and VirtualServices resources to control ingress traffic. They work together to route traffic to the service mesh. Gateways are not required within the service mesh because services access each other based on local service names in the cluster.

Figure 1: How an Istio gateway works

Load Balancing of Istio Gateways

A typical service mesh has one or more SLBs, also known as Gateways, which terminate transport layer security (TLS) connections from the external network and allow traffic to enter the mesh. Then, the traffic passes through the Sidecar gateway to the internal services. It is also common for applications to use external services. Applications directly call external services or, in some deployments, force traffic away from the mesh through dedicated egress gateways.

Figure 2: Gateway usage in mesh
Figure 3: Ingress gateway service of Istio
  • Secondly, Kubernetes Ingress APIs cannot express the routing requirements of Istio. Ingress does not have a common method to specify complex traffic routing rules, such as traffic splitting or traffic mirroring. The lack of specifications in this field leads each vendor to re-consider how to better manage the configuration of each type of Ingress implementation, such as HAProxy and Nginx. Ingress attempts to obtain a public intersection among different HTTP proxies. Therefore, it supports only the most basic HTTP routing.
  • Lastly, since no specifications are available, most vendors choose to configure custom annotations on deployment. Annotations differ with vendors and are not portable. If there are still no specifications available for Istio, more annotations must be used to explain all the functions of Envoy as the edge gateway.
  • HTTPS: port 443, which forwards traffic to port 30443.
  • MySQL: port 3306, which forwards traffic to port 30306.

Ingress Gateway Service

The IngressGateway service must listen to all the ports described in the previous section, so that it forwards traffic to IngressGateway pods. The Kubernetes service is not a “real” service. A request is forwarded to the node that runs the corresponding pod by kube-proxy. Kube-proxy is provided by Kubernetes. The node forwards the request to the appropriate pods based on the IP table configuration.

- name: http2
nodePort: 30000
port: 80
protocol: TCP
- name: https
nodePort: 30443
port: 443
protocol: TCP
- name: mysql
nodePort: 30306
port: 3306
protocol: TCP

Ingress Gateway Deployment

IngressGateway is deployed as an encapsulation based on the Envoy proxy. IngressGateway configuration is the same as the Sidecar configuration used in the service mesh. They are actually the same container image. While creating or modifying a gateway or VirtualService, the Istio Pilot controller detects the changes and converts the changes into Envoy configurations. The Envoy configurations are then sent to the relevant Envoy proxies, including the internal Envoy and the Envoy in IngressGateway.

Gateway Resources

Gateway resources are used to configure the Envoy port. In the preceding example, the IngressGateway service is used to expose three ports. Therefore, you must resolve these ports in Envoy. In addition, one or more gateways can be declared to support the multi-port capability. The following example uses a single gateway, but it can be defined in two or three pieces:

kind: Gateway
name: default-gateway
namespace: istio-system
istio: ingressgateway
- hosts:
- '*'
name: http
number: 80
protocol: HTTP
- hosts:
- '*'
name: https
number: 443
protocol: HTTPS
mode: SIMPLE
privateKey: /etc/istio/ingressgateway-certs/tls.key
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
- hosts: # For TCP routing this fields seems to be ignored, but it is matched
- '*' # with the VirtualService, I use * since it will match anything.
name: mysql
number: 3306
protocol: TCP

Gateway Virtual Service

VirtualService resources and Gateway resources work together to support the configuration of Envoy. The following is the basic configuration of a gateway VirtualService that supports HTTP services:

kind: VirtualService
name: counter
- default-gateway.istio-system.svc.cluster.local
- match:
- uri:
prefix: /
- destination:
host: counter
number: 80
kubectl port-forward istio-ingressgateway-xxxx-yyyy-n istio-system 15000

Debugging Ingress Gateway

Debugging network problems sometimes becomes difficult. Here are some useful commands for debugging.

kubectl -n istio-system port-forward $(kubectl -n istio-system get pods 
-listio=ingressgateway -o=jsonpath="{.items[0]}") 15000
Curl --silent http://localhost:15000/config_dump |jq .configs[3].dynamic_route_configs[].route_config.virtual_hosts[]
Figure 4: IngressGateway pod forwarded by the port
kubectl -n istio-system logs $(kubectl -n istio-system get pods 
-listio=ingressgateway -o=jsonpath="{.items[0]}") --tail=300
kubectl -n istio-system logs $(kubectl -n istio-system get pods 
-listio=pilot -o=jsonpath="{.items[0]}") discovery --tail=300
  • Visit http://localhost:15000/logging to view detailed logs.
  • Find more information in the root directory http://localhost:15000/.

About the Author

Wang Xining, senior technical expert at Alibaba Cloud, and technical owner of ASM and Istio on Kubernetes for Alibaba Cloud, specializes in Kubernetes, cloud-native, service mesh, and other fields. Earlier, Wang worked with IBM China Development Center and served as the chairman of the patent technology review committee. He holds more than 40 international technology patents in related fields. “Technical Analysis and Practice of Istio Service Mesh” introduces the basic principles and development practices in detail, and selects abundant cases and reference codes for download, to help users get started with Istio development quickly. Gartner believes that service mesh will become the standard technology of all leading container management systems in 2020. His book is suitable for all readers who are interested in microservices and cloud-native, and we recommend in-depth reading of this book.

Q&A About Istio

Q1) What are the bottlenecks Istio encounters in practical production environments and what are the common optimization methods to tackle them?

  • Tracking: This function integrates Tracing Analysis from Alibaba Cloud. It provides developers with various features, including trace restoration, request counting, trace topology, and application dependency analysis.
  • Monitoring: This function integrates capabilities of ARMS Prometheus and Grafana Dashboard, and the related documentation will be available soon.

Original Source:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store