Expose Istio

In this section you will expose Istio and the services running behind it using the NGINX Ingress Controller.

What You’ll Need

Procedure

  1. Go to your GitOps repository, inside your rok-tools management environment:

    root@rok-tools:/# cd ~/ops/deployments
  2. Specify the subdomain to use for serving:

    root@rok-tools:~/ops/deployments# export SERVING_SUBDOMAIN=<SUBDOMAIN>

    Replace <SUBDOMAIN> with your subdomain. For example:

    root@rok-tools:~/ops/deployments# export SERVING_SUBDOMAIN=${GKE_CLUSTER?}-serving.${SERVING_DOMAIN?}
  3. Specify the NGINX class to use. Choose one of the following options based on which NGINX you are using:

    The Serving NGINX is used by default. Continue with next step.

    Edit rok/expose-serving/overlays/deploy/kustomization.yaml and enable the ingress-class patch:

    patches: ... - path: patches/ingress-class.yaml
  4. Edit rok/expose-serving/overlays/deploy/kustomization.yaml and enable the xff patch:

    patches: ... - path: patches/xff.yaml target: kind: EnvoyFilter name: xff-trust-hops
  5. Edit rok/expose-serving/overlays/deploy/patches/xff.yaml and set value for xff_num_trusted_hops to 1:

    value: 1

    Note

    GCLB is a TCP proxy and as such we have onle L7 proxy in front of Istio: NGINX.

  6. Edit rok/expose-serving/overlays/deploy/kustomization.yaml and enable the ingress-host and ingress-tls patches by uncommenting the corresponding snippet. The final result will look like this:

    patches: - path: patches/ingress-host.yaml target: kind: Ingress name: istio-ingress - path: patches/ingress-tls.yaml
  7. Render the patch for Ingress rules:

    root@rok-tools:~/ops/deployments# j2 \ > rok/expose-serving/overlays/deploy/patches/ingress-host.yaml.j2 \ > -o rok/expose-serving/overlays/deploy/patches/ingress-host.yaml
  8. Render the patch for TLS termination:

    root@rok-tools:~/ops/deployments# j2 \ > rok/expose-serving/overlays/deploy/patches/ingress-tls.yaml.j2 \ > -o rok/expose-serving/overlays/deploy/patches/ingress-tls.yaml
  9. Edit rok/expose-serving/overlays/deploy/kustomization.yaml and enable the certificate related snippets. Choose one of the following options based on who manages your SSL certificates.

    Enable the corresponding resource and patch:

    resources: ... - ../../base/certificate.yaml patches: ... - path: patches/certificate.yaml

    Enable the corresponding resource and patch:

    resources: ... - ../../base/certificate.yaml patches: ... - path: patches/certificate.yaml

    Enable the secret generator for the TLS secret:

    secretGenerator: - name: knative-serving-ingress-tls-secret files: - secrets/tls.crt - secrets/tls.key type: "kubernetes.io/tls"
  10. Configure your certificate. Choose one of the following options based on who manages your SSL certificates.

    Edit rok/expose-serving/overlays/deploy/patches/certificate.yaml, set both commonName and dnsNames to your subdomain and specify the ClusterIssuer name in issuerRef:

    spec: commonName: arrikto-cluster-serving.serving.example.com # <-- Update this line with your SERVING_SUBDOMAIN dnsNames: - arrikto-cluster-serving.serving.example.com # <-- Update this line with your SERVING_SUBDOMAIN - "*.arrikto-cluster-serving.serving.example.com" # <-- Update this line with your wildcard SERVING_SUBDOMAIN issuerRef: name: arrikto-self-signing-issuer

    Note

    Include your wildcard subdomain as well.

    Edit rok/expose-serving/overlays/deploy/patches/certificate.yaml, set both commonName and dnsNames to your subdomain and specify the ClusterIssuer name in issuerRef:

    spec: commonName: arrikto-cluster-serving.serving.example.com # <-- Update this line with your SERVING_SUBDOMAIN dnsNames: - arrikto-cluster-serving.serving.example.com # <-- Update this line with your SERVING_SUBDOMAIN issuerRef: name: letsencrypt-prod

    Warning

    Let’s Encrypt does not support issuing certificates with wildcard subdomains using HTTP01 validation.

    Put your SSL certificate under rok/expose-serving/overlays/deploy/secrets/tls.crt and your private key under rok/expose-serving/overlays/deploy/secrets/tls.key.

  11. Commit your changes:

    root@rok-tools:~/ops/deployments# git commit -am "Expose Istio via an NGINX Ingress"
  12. Apply the kustomization:

    root@rok-tools:~/ops/deployments# rok-deploy --apply rok/expose-serving/overlays/deploy

Important

If you are not running ExternalDNS, you have to create the wildcard DNS record manually, for example, an A record pointing to the address of your GCLB. Othewise, connect to your GCLB directly using its address and pass the correct Host header.

Verify

  1. Verify that you have successfully created the Ingress object for Istio. Ensure that the HOSTS field includes both your subdomain and your wildcard subdomain. Wait until the ADDRESS field shows the IP address of your load balancer:

    root@rok-tools:~# kubectl get ingress -n knative-serving NAME CLASS HOSTS ADDRESS PORTS AGE knative-serving-ingress nginx-serving *.arrikto-cluster-serving.serving.example.com,arrikto-cluster-serving.serving.example.com 10.42.42.42 80, 443 1m
  2. Verify that the SSL certificate is READY. Choose one of the following options based on who manages your SSL certificates.

    Check that field READY is True.

    root@rok-tools:~# kubectl get certificate -n knative-serving NAME READY SECRET AGE knative-serving-ingress-tls-certificate True knative-serving-ingress-tls-secret 1m

    Check that field READY is True.

    root@rok-tools:~# kubectl get certificate -n knative-serving NAME READY SECRET AGE knative-serving-ingress-tls-certificate True knative-serving-ingress-tls-secret 1m

    Troubleshooting

    The certificate does not become READY.

    Ensure that Let’s Encrypt can reach your GCLB at port 80. This is required for the HTTP-01 challenge. Update loadBalancerSourceRanges of your ingress-nginx Service to allow all CIDRs, at least temporarily.

    Your Certificate will be stored directly in a Kubernetes secret. Proceed to the next step to verify its contents.

  3. Inspect the TLS secret and verify that the SSL certificate has the expected CN and SAN:

    root@rok-tools:~# kubectl get secrets -n knative-serving knative-serving-ingress-tls-secret \ > -o jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -text ... Subject: CN = arrikto-cluster-serving.serving.example.com ... X509v3 extensions: ... X509v3 Subject Alternative Name: DNS:"arrikto-cluster-serving.serving.example.com" DNS:"*.arrikto-cluster-serving.serving.example.com"

Summary

You have successfully configured Istio and exposed served models to the outside world.

What’s Next

Optionally, you can integrate Rok and Arrikto EKF with external platforms or projects.