The Istio Gateway should be deployed separately from Istio deployment, because the gateway architecture requires additional planning work.
These instructions explain how Istio Gateway can be deployed after the architecture work is completed. The gateway will receive external traffic and forward it to the applications running inside of the EKS Cluster:
To deploy an Istio Gateway in EKS cluster the following objects are required:
- Envoy Gateway Deployment
- Envoy Gateway Pod
- Envoy Gateway Kubernetes Service
These are hosted in the EKS cluster. The creation of Kubernetes service (type
LoadBalancer) will trigger the creation of an AWS Classic LoadBalancer or Network Load Balancer, depending on the EKS cluster configuration.
The example below is taken from the Istio 'Deploying a Gateway' documentation, with slight changes:
We begin with our Namespace definition:
The Service object will trigger creation of AWS LoadBalancer and will allow calls to reach the gateway pod.
- port: 80
- port: 443
The Gateway Deployment should then be placed in the namespace that we just created.
# Select the gateway injection template (rather than the default sidecar template)
# Set a unique label for the gateway. This is required to ensure Gateways can select this workload
# Enable gateway injection. If connecting to a revisioned control plane, replace with "istio.io/rev: revision-name"
- name: istio-proxy
image: auto # The image will automatically update each time the pod starts.
Role and RoleBindings may also be required. These allow the gateway to access kubernetes secrets, such as those used to store TLS certificates:
# Set up roles to allow reading credentials for TLS
- apiGroups: [""]
verbs: ["get", "watch", "list"]
- kind: ServiceAccount
To confirm that the steps worked as expected you can query
kubectl get pods -n tid-ingress-ns
The result should show Ingress GW Pod running: