Kubernetes istio gateway - ghdrako/doc_snipets GitHub Wiki

In real-world scenarios, we need to interact with components outside the Kubernetes cluster. There are many applicable use cases. For example, applications running inside the cluster may interact with a database deployed outside the cluster. Similarly, there can be user applications deployed in the cluster. These applications will need to be accessed from the Internet.

Ingress

The term ingress is defined as an entry facade. It is a location that provides service access to all externally originated requests. The ingress is configured using an Istio gateway. It is an edge component that is used to expose services outside the cluster. It can be used to expose HTTP as well as TCP services. The gateway provides capabilities such as TLS termination and request forwarding. In most production clusters, a gateway is configured in conjunction with a Kubernetes load balancer service. In such scenarios, the Kubernetes service creates a cloud-based L4 load balancer. The load balancer has a public IP address that can be accessed by the world outside the Kubernetes cluster. When the load balancer receives a request, then it delegates the request to the matching Istio gateway. The gateway then uses Istio traffic routing and dispatches the request to the appropriate service version. Istio also applies the necessary telemetry and security to the gateway.

virtual hosting

Hosting multiple different services at a single entry point is known as virtual hosting. We need a way to decide which virtual host group a particular request should be routed to. With HTTP/1.1, we can use the Host header; with HTTP/2, we can use the :authority header; and with TCP connections, we can rely on Server Name Indica- tion (SNI) with TLS.

Istio gateway

ingress gateway plays the role of the network ingress point and is responsible for guarding and controlling access to the cluster from traffic that originates outside of the cluster. Additionally, Istio’s ingress gateway handles load balancing and virtual-host routing.

kubectl -n istio-system exec \
deploy/istio-ingressgateway -- ps

The Istio gateway can be compared to the Kubernetes ingress resource, but unlike the ingress resource, the gateway does not have any traffic routing rules configured with it. The gateway delegates all inbound traffic to a virtual service and applies the relevant routing configuration. In summary, the gateway works at L4, L5, and L6 only.

If we want to send requests from the external world, we need to create the following ingress gateway:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: chapter4-gateway
  namespace: chapter4
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "sockshop.com"
    - "mockshop.com"

This is also equivalent to defining a load balancer. In the servers property, we are defining the following:

• hosts: These are one or more DNS names exposed by the gateway. In the preceding example, we are defining two hosts: sockshop.com and mockshop.com. Any other hosts apart from these two will be rejected by the Ingress gateway.
• port: In the port configuration, we define port numbers and the protocols, which can be either HTTP, HTTPS, gRPC, TCP, TLS, or Mongo. The name of the port can be anything you like to use. In this example, we are exposing port 80 over the HTTP protocol.

To summarize, the gateway will accept any HTTP request over port 80 with the host header of sockshop.com or mockshop.com.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway    # gatway name
spec:
  selector:
    istio: ingressgateway    # which gateway implementation
  servers:
  - port:
      number: 80             # ports to expose
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istioinaction.io" # host(s) for this port

Our Gateway resource configures Envoy to listen on port 80 and expect HTTP traffic.

$istioctl -n istio-system proxy-config listener deploy/istio-ingressgateway
ADDRESS       PORT MATCH DESTINATION
0.0.0.0 8080  ALL  Route: http.80
0.0.0.0 15021 ALL  Inline Route: /healthz/ready*
0.0.0.0 15090 ALL  Inline Route: /stats/prometheus*


$istioctl proxy-config route deploy/istio-ingressgateway -o json --name http.8080 -n istio-system
[
{
"name": "http.8080",
"virtualHosts": [
{
"name": "blackhole:80",
"domains": [
"*"
],
}
],
"validateClusters": false
}
]

Our listener is bound to a blackhole default route that routes everything to HTTP 404.

Secure Sockets Layer

Istio gateways provide complete support for SSL exchange. We can set up an SSL certificate exchange in the gateway. Alternatively, the gateway can act as a pass-through medium. This way, SSL termination can be handled by HAProxy or Nginx running in the Kubernetes cluster. Before we can enable SSL, we need a certificate and a private key.

Configure istio-ingressgateway-certs

Kubernetes provides good support for secret management. We can create a named secret in the cluster. A pod can then be configured with the .spec.volumes[].secret.secretName attribute. Kubernetes will mount the named secret on the specified file location of the pod.