# Istio gateways

## Traffic ingress concepts
Ingress is entry points that allows traffic go into the local network. The traffic is first routed to an ingress point and the ingress point enforces rules and policies about what traffic is allowed into the local network.

If the ingress point allows the traffic, it proxies the traffic to the correct endpoint in the local network. If the traffic is not allowed, the ingress point rejects the traffic.

Virtual IPs - a type of ingress point known as a reverse proxy.


Virtual hosting - multiple services from a single access point. We need a way to decide which virtual host group a particular request should be routed to:
+ HTTP/1.1, we can use the `Host` header
+ HTTP/2, we can use the `:authority` header
+ TCP connections, we can rely on `Server Name Indication (SNI)` with TLS


## Istio ingress gateways
Istio has the concept of an *Ingress Gateway* that plays the role of the network ingress point.

Additionally, Istio’s ingress gateway handles load balancing and virtual-host routing.


We’ll start by exploring two Istio resources: Gateway and VirtualService.

### Gateway resources
To configure an ingress gateway in Istio, we use the Gateway resource.

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istioinaction.io"
EOF

Let’s see whether our settings took effect:

istioctl -n istio-system proxy-config listener deploy/istio-ingressgateway

Next, we set up a virtual host to route traffic from port 80 to a service within the service mesh.

### VirtualService resources
We’ll use the *VirtualService* resource to get the traffic comes into the gateway to a specific service within the service mesh.

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-vs-from-gw
spec:
  hosts:
  - "webapp.istioinaction.io"
  gateways:
  - coolstore-gateway
  http:
  - route:
    - destination:
        host: webapp
        port:
          number: 80
EOF

we can run our commands to list the listeners and routes:

istioctl proxy-config route deploy/istio-ingressgateway -o json --name http.8080 -n istio-system

Let's test:

curl http://localhost/api/catalog -H "Host: webapp.istioinaction.io"

### Istio Ingress Gateway vs Kubernetes Ingress
Kubernetes Ingress have some limitations:
+ The first limitation is that Kubernetes Ingress v1 is a very simple specification geared toward HTTP workloads
+ The second is the Ingress specification only considers port 80 and port 443 as ingress points, this severely limits the types of traffic a cluster operator can allow into the service mesh. For examples, Kafka or NATS workloads or direct TCP connections
+ Annotations of configuration between vendors vary and are not portable

=> Kubernetes Ingress doesn’t allow for that.

Ultimately, Istio decided on a clean slate for building ingress patterns and specifically separated out the layer 4 (transport) and layer 5 (session) properties from the layer 7 (application) routing concerns. Istio Gateway handles the L4 and L5 concerns, while VirtualService handles the L7 concerns.

### HTTP traffic with TLS
Creating a Kubernetes secrets to store certificates and keys.

kubectl create -n istio-system secret tls webapp-credential --key webapp.istioinaction.io.key.pem --cert webapp.istioinaction.io.cert.pem

The default gateway is run in the `istio-system` namespace, so that’s where we put the secret.

Now we can configure our Istio Gateway resource to use the certificates and keys:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istioinaction.io"
  - port:
      number:
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: webapp-credential
    hosts:
    - "webapp.istioinaction.io"

Updating it, and if we call the service as we did in the previous section, by passing in the proper `Host` header, we will see error as below:

*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:443
* stopped the pause stream!
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:443

Let’s pass in the proper CA certificate chain to our curl client:

curl -v -H "Host: webapp.istioinaction.io" https://localhost/api/catalog --cacert ca-chain.cert.pem --resolve webapp.istioinaction.io:443:127.0.0.1


For HTTP redirect to HTTPS

tls:
  httpsRedirect: true

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    tls:
      httpsRedirect: true
    hosts:
    - "webapp.istioinaction.io"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: webapp-credential
    hosts:
    - "webapp.istioinaction.io"

### Serving multiple virtual hosts with TLS
Istio’s ingress gateway can serve multiple virtual hosts, each with its own certificate and private key from the same HTTPS port (port 443).

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https-webapp
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: webapp-credential
    hosts:
    - "webapp.istioinaction.io"
  - port:
      number: 443
      name: https-catalog
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: catalog-credential
    hosts:
    - "catalog.istioinaction.io"

curl -H "Host: webapp.istioinaction.io" http://localhost:80/api/catalog

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog-vs-from-gw
spec:
  hosts:
  - "catalog.istioinaction.io"
  gateways:
  - coolstore-gateway
  http:
  - route:
    - destination:
        host: catalog
        port:
          number: 80
EOF

curl -H "Host: catalog.istioinaction.io" http://localhost:80/items

### TCP traffic
Istio’s gateway is powerful enough to serve not only HTTP/HTTPS traffic but also any traffic accessible via TCP.

Let's deploy simple TCP server.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tcp-echo-deployment
  labels:
    app: tcp-echo
    system: example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tcp-echo
  template:
    metadata:
      labels:
        app: tcp-echo
        system: example
    spec:
      containers:
        - name: tcp-echo-container
          image: cjimti/go-echo:latest
          imagePullPolicy: IfNotPresent
          env:
            - name: TCP_PORT
              value: "2701"
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
            - name: SERVICE_ACCOUNT
              valueFrom:
                fieldRef:
                  fieldPath: spec.serviceAccountName
          ports:
            - name: tcp-echo-port
              containerPort: 2701
---
apiVersion: v1
kind: Service
metadata:
  name: "tcp-echo-service"
  labels:
    app: tcp-echo
    system: example
spec:
  selector:
    app: "tcp-echo"
  ports:
    - protocol: "TCP"
      port: 2701
      targetPort: 2701
EOF

In the following example, we expose port 31400 on the default `istioingressgateway`.

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: echo-tcp-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 31400
      name: tcp-echo
      protocol: TCP
    hosts:
    - "*"
EOF

Any host:

hosts:
  - "*"

Checking service is listening for TCP.

kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name == "tcp")]}'  | jq -r

Now that we’ve exposed a port on our ingress gateway, we need to route the traffic to the echo service with VirtualService.

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tcp-echo-vs-from-gw
spec:
  hosts:
  - "*"
  gateways:
  - echo-tcp-gateway
  tcp:
  - match:
    - port: 31400
    route:
    - destination:
        host: tcp-echo-service
        port:
          number: 2701
EOF

> **NOTE** If you’re running in a public cloud or a cluster that creates a LoadBalancer for the istio-ingressgateway service, and you can’t connect as shown next, you may need to explicitly add a port to the istio-ingressgateway service on port 31400 and use targetPort 31400 for this to work correctly.

Let's test.

telnet localhost 31400

### Traffic routing with SNI passthrough

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: sni-passthrough-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 31400
      name: tcp-sni
      protocol: TLS
    hosts:
    - "simple-sni-1.istioinaction.io"
    tls:
      mode: PASSTHROUGH
EOF

In our example application, we configure the application to terminate TLS for the HTTPS connection using certificates. This means we don’t need the ingress gateway to do anything with the connection. We won’t need to configure any certificates on the gateway.

All the gateway will do is inspect the SNI headers and route the traffic to the specific backend, which will then terminate the TLS connection. The connection will “pass through” the gateway and be handled by the actual service, not the gateway.

Next, we define a VirtualService to specify routing rules.

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: simple-sni-1-vs
spec:
  hosts:
  - "simple-sni-1.istioinaction.io"
  gateways:
  - sni-passthrough-gateway
  tls:
  - match:
    - port: 31400
      sniHosts:
      - simple-sni-1.istioinaction.io
    route:
    - destination:
        host: simple-tls-service-1
        port:
          number: 80
EOF

### Ingress gateway access logs
A common feature for a proxy is logging every individual request that it processes. These access logs are helpful for troubleshooting issues. But in the production, Istio access logs is disabled when using the *default* profile.

You can turn on access logging with the following command:

istioctl install --set meshConfig.accessLogFile=/dev/stdout

A better approach is to enable access logging only for the workloads for which you are interested in using the *Telemetry* API. For example, to show the access logs of only the ingress gateway workloads:

kubectl apply -f - <<EOF
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: ingress-gateway
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  accessLogging:
  - providers:
    - name: envoy
    disabled: false
EOF

Istio configuration can be applied in different scopes:
+ Mesh-wide
+ Namespace-wide
+ Workload-specific

###### tags: `istio`