Istio Gateway should be deployed separately from Istio deployment. The reason for it - the gateway architecture requires additional planning work. Below you can find an example demonstrates how Istio Gateway can be deployed after the architecture work is completed. The gateway will allow traffic reach out to the applications running inside of the EKS Cluster.
To deploy gateway in EKS cluster the following objects are required - Envoy Gateway Deployment, Pod and Kubernetes Service will be hosted in the EKS cluster. The creation of Kubernetes service (type LoadBalancer) will trigger creation of AWS Classic LoadBalancer (The example below is taken from Istio web-site (with slight changes)):
Namespace definition will look like this:
apiVersion: v1
kind: Namespace
metadata:
name: tid-ingress-ns
Service object will trigger creation of AWS LoadBalancer and will allow calls to reach to gateway pod.
apiVersion: v1
kind: Service
metadata:
name: tid-ingressgateway
namespace: tid-ingress-ns
spec:
type: LoadBalancer
selector:
istio: tid-ingress-gw
ports:
- port: 80
name: http
- port: 443
name: https
The Gateway Deployment will be placed in the namespace that we just created.
apiVersion: apps/v1
kind: Deployment
metadata:
name: tid-ingressgateway-gw
namespace: tid-ingress-ns
spec:
selector:
matchLabels:
istio: tid-ingress-gw
template:
metadata:
annotations:
# Select the gateway injection template (rather than the default sidecar template)
inject.istio.io/templates: gateway
labels:
# Set a unique label for the gateway. This is required to ensure Gateways can select this workload
istio: tid-ingress-gw
# Enable gateway injection. If connecting to a revisioned control plane, replace with "istio.io/rev: revision-name"
sidecar.istio.io/inject: "true"
spec:
containers:
- name: istio-proxy
image: auto # The image will automatically update each time the pod starts.
Role and Role bindings are also required per below. This allows the gateway to access kubernetes secrets. Kubernetes secrets are used to store TLS certificates.
# Set up roles to allow reading credentials for TLS
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tid-ingressgateway-sds
namespace: tid-ingress-ns
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tid-ingressgateway-sds
namespace: tid-ingress-ns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: tid-ingressgateway-sds
subjects:
- kind: ServiceAccount
name: default
To confirm that the steps worked as expected you can query tid-ingress-ns with the following command - kubectl get pods -n tid-ingress-ns
The result should show Ingress GW Pod running:
