This blog entry is meant to host random discoveries noted during my work with Istio in general. The notes are expectingly blunt & without contexts (apologies).
Once istio is installed, it will expose several ports through NodePort. To see which istio-controller port is mapped to which port on the node(s), use the following command:
kubectl get svc istio-ingressgateway -n istio-system
The mapped PORTS are available in the output, for example:
If we request at
<nodeIP>:31380 now, the request is refused. It’s because there is no Gateway resource to declare the use of port 80 (which is mapped to 31380 as seen from the example output above)
To start using the mapping, we can deploy the following example Gateway resource:
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: foo-gateway namespace: foo spec: selector: istio: ingressgateway # use istio default controller servers: - hosts: - '*' port: name: http number: 80 protocol: HTTP
Declaring the use of the mapping is one thing. Declaring the service behind the istio-controller port is another thing. At this point, requests coming to the node’s port get routed to the port 80 within istio realm, but there’s nothing listening there yet. This is where istio VirtualService comes in. We can declare something like this:
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: foo-vs namespace: foo spec: gateways: - foo-gateway hosts: - '*' http: - match: - uri: prefix: / route: - destination: host: foo-app # the actual destination service port: number: 80 # the actual destination service's listening port
Now if there’s a real service accessible at
foo-app.<ns>.svc.cluster.local, it’ll serve the request coming into <nodeIP>:31380. Note that the
hosts are declared as wildcard for both the Gateway and VirtualService resources in the examples above. Feel free to experiment & fine-tune them to your likings in your own setups.
k8s Istio Gateway TLS Termination (i.e. tls.mode = SIMPLE)
From the example above, you may notice TLS traffic is also supported. In simple terms: HTTPS requests coming in can be decrypted & terminated at Istio Gateway, then the traffic goes to the
VirtualService behind can just be plain HTTP.
While we can provide direct paths to the cert & key files, if Istio is installed in k8s environment, this may be inconvenient. A more “k8s-native” approach would be k8s Secret, which is supported via the
tls.credentialName setting. Configuring this is a simple 2-step process:
Step 1: from your local (or any workstation), generate the k8s secret from the certificate file & key:
kubectl create -n istio-system secret tls <secret-name> --key=/path/to/key/file --cert=/path/to/cert/file
Step 2: configure Istio Gateway to use the correct tls mode & certificate info:
apiVersion: networking.istio.io/v1beta1 kind: Gateway # ... spec: # ... servers: - hosts: - '*' port: name: https number: 443 protocol: HTTPS tls: credentialName: <secret-name> mode: SIMPLE
NB: this is not the only possible setup, but it’s a typical example of how we can configure Istio for this purpose.