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.
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# From the istio-ingressgateway service2 ports:3 - name: http24 nodePort: 300005 port: 806 protocol: TCP7 - name: https8 nodePort: 304439 port: 44310 protocol: TCP11 - name: mysql12 nodePort: 3030613 port: 330614 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.
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# Example represents volume mounts2volumeMounts:3- mountPath: /etc/istio/ingressgateway-certs4 name: ingressgateway-certs5 readOnly: true6- mountPath: /etc/istio/ingressgateway-ca-certs7 name: ingressgateway-ca-certs8 readOnly: true910# Example represents volumes11volumes:12- name: ingressgateway-certs13 secret:14 defaultMode: 42015 optional: true16 secretName: istio-ingressgateway-certs17- name: ingressgateway-ca-certs18 secret:19 defaultMode: 42020 optional: true21 secretName: istio-ingressgateway-ca-certs
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.
1apiVersion: networking.istio.io/v1alpha32kind: Gateway3metadata:4 name: default-gateway5 namespace: istio-system6spec:7 selector:8 istio: ingressgateway9 servers:1011 - hosts:12 - '*'13 port:14 name: http15 number: 8016 protocol: HTTP1718 - hosts:19 - '*'20 port:21 name: https22 number: 44323 protocol: HTTPS24 tls:25 mode: SIMPLE26 privateKey: /etc/istio/ingressgateway-certs/tls.key27 serverCertificate: /etc/istio/ingressgateway-certs/tls.crt2829 - hosts: # For all the TCP routing this fields will be ignored, but it will be matched30 - '*' # with the VirtualService, We use * since it will match anything.31 port:32 name: mysql33 number: 330634 protocol: TCP
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
1apiVersion: networking.istio.io/v1alpha32kind: VirtualService3metadata:4 name: counter5spec:6 gateways:7 - default-gateway.istio-system.svc.cluster.local8 hosts:9 - counter.lab.example.com10 http:11 - match:12 - uri:13 prefix: /14 route:15 - destination:16 host: counter17 port:18 number: 80
The request have now reached the application service and deployment. These are normal Kubernetes resources.
First we will use istioctl to check the configuration status of Istio Ingress Gateway:
1# istioctl proxy-status istio-ingressgateway-5586f47659-r64lb.istio-system2Clusters Match3Listeners Match4Routes 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#kubectl get configmap istio -n istio-system -o yaml | grep "accessLogFile: "2disable 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# kubectl logs -n istio-system istio-ingressgateway-5586f47659-r64lb | grep -v deprecated
Design your deployments the way you want. Drag-and-drop your cloud native infrastructure using a pallete of thousands of versioned Kubernetes components. Say goodbye to YAML configurations. Have your cloud native deployments automatically diagrammed. Deployments configured and modeled in Designer mode, can be deployed into your environment and managed using Visualizer. Discover a catalog of best practice cloud native patterns