A gateway is a dedicated Envoy proxy deployment paired with a Kubernetes Service, operating at the edge of the service mesh. It enables fine-grained control over traffic that enters or leaves the mesh. In Alauda Service Mesh, gateways are installed via gateway injection.
Gateway injection utilizes the same mechanism as sidecar injection to deploy the Envoy proxy into gateway pods. To deploy a gateway:
Deployment
and a corresponding Service
in a namespace visible to the Istio control plane.Gateway
and VirtualService
resources to control ingress or egress traffic.For nodes running Linux kernel versions earlier than 4.11 (e.g., CentOS 7), additional configuration is required prior to gateway installation.
Skip this section if your kernel version is 4.11 or later.
Prerequisites
jq
locally to process JSON in these steps.Procedure
Create a YAML file named gateway-injection-template.txt
that contains the default injection template for gateways.
sysctls
because net.ipv4.ip_unprivileged_port_start
is not available on old Linux kernels.CAP_NET_BIND_SERVICE
to the list of capabilities in order to allow gateways to listen on ports below 1024.Patch the default gateway
injection template for Istio
resource:
Wait for the control plane to return the Ready
status condition by running the following command:
This procedure explains how to install a gateway by using gateway injection.
The following procedure applies to both ingress and egress gateway deployments.
Prerequisites
Procedure
Create a namespace for the gateway:
Install the gateway and the Istio control plane in different namespaces.
You can install the gateway in a dedicated gateway namespace. This approach allows the gateway to be shared by many applications operating in different namespaces. Alternatively, you can install the gateway in an application namespace. In this approach, the gateway acts as a dedicated gateway for the application in that namespace.
Create a YAML file named secret-reader.yaml
that defines the service account, role, and role binding for the gateway deployment. These settings enable the gateway to read the secrets, which is required for obtaining TLS credentials.
Apply the YAML file by running the following command:
Create a YAML file named gateway-deployment.yaml
that defines the Kubernetes Deployment
object for the gateway.
Gateway
resources can select gateway workloads.sidecar.istio.io/inject
label to true
.
If the name of the Istio resource is not default you must use the istio.io/rev: <istio_revision>
label instead, where the revision represents the active revision of the Istio resource.auto
so that the image automatically updates each time the pod starts.serviceAccountName
to the name of the ServiceAccount
created previously.Apply the YAML file by running the following command:
Verify that the gateway Deployment
rollout was successful by running the following command:
You should see output similar to the following:
Example output
Create a YAML file named gateway-service.yaml
that contains the Kubernetes Service
object for the gateway.
spec.type
to ClusterIP
the gateway Service
object can be accessed only from within the cluster.
If the gateway has to handle ingress traffic from outside the cluster, set spec.type
to LoadBalancer
.selector
to the unique label or set of labels specified in the pod template of the gateway deployment that you previously created.Apply the YAML file by running the following command:
Verify that the gateway service is targeting the endpoint of the gateway pods by running the following command:
You should see output similar to the following example:
Example output
Optional: Create a YAML file named gateway-hpa.yaml
that defines a horizontal pod autoscaler for the gateway.
The following example sets the minimum replicas to 2
and the maximum replicas to 5
and scales the replicas up when average CPU utilization exceeds 80% of the CPU resource limit.
This limit is specified in the pod template of the deployment for the gateway.
spec.scaleTargetRef.name
to the name of the gateway deployment previously created.Optional: Apply the YAML file by running the following command:
Optional: Create a YAML file named gateway-pdb.yaml
that defines a pod disruption budget for the gateway.
The following example allows gateway pods to be evicted only when at least 1
healthy gateway pod will remain on the cluster after the eviction.
spec.selector.matchLabels
to the unique label or set of labels specified in the pod template of the gateway deployment previously created.Optional: Apply the YAML file by running the following command: