Istio Ingress Gateway in Kubernetes

Predominantly, Kubernetes has used an Ingress controller to handle the traffic that enters the cluster from the outside. Istio has replaced all the familiar Ingress resource with new Gateway and VirtualServices resources. They work in sync to route all the traffic into the mesh. Inside the mesh there is no requirement for Gateways since the services can access each other by a cluster local service name.

Let’s understand the working with a representation

• Firstly A request is made by a client on a specific port
• Then a load balancer on this port listens and forwards the request to one of the workers in theh cluster on same or a new port
• Inside the cluster the request is routed to the Istio Ingress Gateway which is listened on the port of the load balancer
• The Service forwards the requestto an Istio Ingress Gateway Pod which is managed by a deployment
• The Ingress Gateway Pod is configured by a Gateway and a VirtualService.
• The Gateway configures all the ports, protocol, and certificates.
• The Virtual Service configures all the routing information to find the correct Servicein it.
• The Istio Ingress Gateway Pod routes the request to the application Service.
• And lastly, the application Service routes the request to an application Pod which is managed by a deployment.

Ingress Gateway Service

The Ingress Gateway Service must listen to all the ports to be able to forward the traffic to the Ingress Gateway pods. Here we will be using routing to bring all the port numbers back to their initial state.

Note that a Kubernetes Service is not a real service, but, since we are using type: "NodePort", all the request will be handled by the kube-proxy provided by Kubernetes and forwarded to a node with a current running pod. Once on the node, an IP-tables is configured a request will be forwarded to the appropriate pod.

1
2# From the istio-ingressgateway service
3  ports:
4  - name: http2
5    nodePort: 30000
6    port: 80
7    protocol: TCP
8  - name: https
9    nodePort: 30443
10    port: 443
11    protocol: TCP
12  - name: mysql
13    nodePort: 30306
14    port: 3306
15    protocol: TCP

If we inspect the service, we will see that it defines more ports than we have describe above. So these ports will be used for all the internal Istio communication.

Ingress Gateway Deployment

It's a wrapper around the Envoy proxy and it is configured as the sidecars used inside the service mesh. When a Gateway or VirtualService gets changed, they are detected by the Istio Pilot controller and converts this information to an Envoy configuration and sends it to all the proxies, including the Envoy inside the IngressGateway.

Since container ports are not supposed to be declared in Kubernetes pods, we don't have to declare the ports in the Ingress Gateway Deployment. If we look inside the deployment we can see that there are a number of ports that are already declared anyway. We have to take care about the Ingress Gateway Deployment in SSL certificates. To access the certificates inside the Gateway resources, make sure that we have mounted all the required certificates properly.

1
2# Example represents volume mounts
3volumeMounts:
4- mountPath: /etc/istio/ingressgateway-certs
5  name: ingressgateway-certs
6  readOnly: true
7- mountPath: /etc/istio/ingressgateway-ca-certs
8  name: ingressgateway-ca-certs
9  readOnly: true
10
11# Example represents volumes
12volumes:
13- name: ingressgateway-certs
14  secret:
15    defaultMode: 420
16    optional: true
17    secretName: istio-ingressgateway-certs
18- name: ingressgateway-ca-certs
19  secret:
20    defaultMode: 420
21    optional: true
22    secretName: istio-ingressgateway-ca-certs

The Gateway

The Gateway resources are used to configure the ports for Envoy and also support for the Kubernetes Ingress. Since all the three ports are exposed with the servies, we need these ports to be handled by the Envoy. It can be handled by declaring one or more Gateways.

1
2apiVersion: networking.istio.io/v1alpha3
3kind: Gateway
4metadata:
5  name: default-gateway
6  namespace: istio-system
7spec:
8  selector:
9    istio: ingressgateway
10  servers:
11
12  - hosts:
13    - '*'
14    port:
15      name: http
16      number: 80
17      protocol: HTTP
18
19  - hosts:
20    - '*'
21    port:
22      name: https
23      number: 443
24      protocol: HTTPS
25    tls:
26      mode: SIMPLE
27      privateKey: /etc/istio/ingressgateway-certs/tls.key
28      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
29
30  - hosts: # For all the TCP routing this fields will be ignored, but it will be matched
31    - '*'  # with the VirtualService, We use * since it will match anything.
32    port:
33      name: mysql
34      number: 3306
35      protocol: TCP

VirtualService

The last interesting resource we have is the VirtualService, it used in concert with the Gateway to configure Envoy.

A general configuration for an HTTP(s) service

1
2apiVersion: networking.istio.io/v1alpha3
3kind: VirtualService
4metadata:
5  name: counter
6spec:
7  gateways:
8  - default-gateway.istio-system.svc.cluster.local
9  hosts:
10  - counter.lab.example.com
11  http:
12  - match:
13    - uri:
14      prefix: /
15    route:
16    - destination:
17        host: counter
18        port:
19          number: 80

Application Service and Deployment

The request have now reached the application service and deployment. These are normal Kubernetes resources.

Extras:

Debugging Istio Gateway

First we will use istioctl to check the configuration status of Istio Ingress Gateway:

1
2# istioctl proxy-status istio-ingressgateway-5586f47659-r64lb.istio-system
3Clusters Match
4Listeners Match
5Routes Match

If anything does not get synced with it, try restarting the ingress gateway pod once - it may be possible that it somehow an update got missed. If RDS looked good, we can check access logs of it.

1
2#kubectl get configmap istio -n istio-system -o yaml | grep "accessLogFile: "
3disable access log.\naccessLogFile: \"/dev/stdout\"\n\n# If accessLogEncoding

Once all the access logs are enabled, we can try torequest a few more times and check the logs on the Ingress Gateway:

1
2# kubectl logs -n istio-system istio-ingressgateway-5586f47659-r64lb | grep -v deprecated