# 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.
```bash
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:
```bash
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.
```bash
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:
```bash
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.
```bash
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:
```yaml
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
```
```yaml
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).
```yaml
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
```
```bash
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.
```bash
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`.
```bash
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:
```yaml
hosts:
- "*"
```
Checking service is listening for TCP.
```bash
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.
```bash
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
```bash
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.
```bash
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:
```bash
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:
```bash
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`
Sign in with Wallet
Connect another wallet