Tier1 Gateway
Tier1Gateway
configures a workload to act as a gateway that
distributes traffic across one or more ingress gateways in other
clusters.
NOTE: Tier1 gateways cannot be used to route traffic to the same cluster. A cluster with tier1 gateway cannot have any other gateways or workloads.
The following example declares a tier1 gateway running on pods with
app: gateway
labels in the ns1
namespace. The gateway exposes
host movieinfo.com
on ports 8080, 8443 and kafka.internal
on port 9000.
Traffic for these hosts at the ports 8443 and 9000 are TLS terminated and
forwarded over Istio mutual TLS to the ingress gateways hosting
movieinfo.com
host on clusters c3
and c4
and the internal
kafka.internal
service in cluster c3
respectively. The server at
port 8080 is configured to receive plaintext HTTP traffic and redirect
to port 8443 with "Permanently Moved" (HTTP 301) status code.
apiVersion: gateway.tsb.tetrate.io/v2
kind: Tier1Gateway
metadata:
name: tier1
group: g1
workspace: w1
tenant: mycompany
organization: myorg
spec:
workloadSelector:
namespace: ns1
labels:
app: gateway
externalServers:
- name: movieinfo-plain
hostname: movieinfo.com # Plaintext and HTTPS redirect
port: 8080
redirect:
authority: movieinfo.com
url: "/"
redirectCode: 301
port: 8443
scheme: https
- name: movieinfo
hostname: movieinfo.com # TLS termination and Istio mTLS to upstream
port: 8443
tls:
mode: SIMPLE
secretName: movieinfo-secrets
clusters:
- name: c3 # the target gateway IPs will be automatically determined
weight: 90
- name: c4
weight: 10
authentication:
jwt:
issuer: "auth.mycompany.com"
jwksUri: https://auth.company.com/oauth2/jwks
authorization:
external:
uri: "https://auth.company.com"
includeRequestHeaders:
- authorization
tcpExternalServers:
- name: kafka
hostname: kafka.internal
port: 9000
tls:
mode: SIMPLE
secretName: kafka-cred
clusters:
- name: c3
weight: 100
Tier1 gateways can also be used to forward mesh internal traffic
for Gateway hosts from one cluster to another. This form of
forwarding will work only if the two clusters cannot reach each
other directly (e.g., they are on different VPCs that are not
peered). The following example declares a tier1 gateway running on
pods with app: gateway
labels in the ns1
namespace. The gateway
exposes hosts movieinfo.com
, bookinfo.com
, and a non-HTTP server
called kafka.org-internal
within the mesh. Traffic to movieinfo.com
is load balanced across all clusters on vpc-02
, while traffic to
bookinfo.com
and kafka.org-internal
is load balanced across ingress
gateways exposing bookinfo.com
on any cluster. Traffic from the source
(sidecars) is expected to arrive on the tier1 gateway over Istio mTLS.
apiVersion: gateway.tsb.tetrate.io/v2
kind: Tier1Gateway
metadata:
name: tier1
group: g1
workspace: w1
tenant: mycompany
organization: myorg
spec:
workloadSelector:
namespace: ns1
labels:
app: gateway
internalServers: # forwarding gateway (HTTP traffic only)
- name: movieinfo
hostname: movieinfo.com
clusters:
- network: vpc-02 # the target gateway IPs will be automatically determined
authentication:
jwt:
issuer: "auth.mycompany.com"
jwksUri: https://auth.company.com/oauth2/jwks
authorization:
external:
uri: "https://auth.company.com"
includeRequestHeaders:
- authorization
- name: bookinfo
hostname: bookinfo.com # route to any ingress gateway exposing bookinfo.com
tcpInternalServers: # forwarding non-HTTP traffic within the mesh
- name: kafka
hostname: kafka.org-internal
** NOTE:** If two clusters have direct connectivity, declaring a tier1 internal server will have no effect.
Tier1 gateways can also be configured to expose hostnames in the TLS passthrough mode. Tier1 gateway will forward the pasthrough server traffic to any tier2 pass through servers exposing the same hostname. In other words, To be able to leverage passthrough at tier1, it is a MUST that passthrough is configured at t2 IngressGateway as well.
** NOTE:** A hostname like abc.com
can only be exposed either in passthrough mode OR
in terminating tls mode(External/Internal servers), not in both the modes.
apiVersion: gateway.tsb.tetrate.io/v2
kind: Tier1Gateway
metadata:
name: tier1-tls-gw
group: g1
workspace: w1
tenant: mycompany
organization: myorg
spec:
workloadSelector:
namespace: ns1
labels:
app: gateway
passthroughServers:
- name: nginx
port: 8443
hostname: nginx.example.com
The Tier1Gateway above will require the corresponding, at least one or more, IngressGateway(s), e.g.:
apiVersion: gateway.tsb.tetrate.io/v2
kind: IngressGateway
metadata:
name: tls-gw
group: g1
workspace: w1
tenant: mycompany
organization: myorg
spec:
workloadSelector:
namespace: ns1
labels:
app: gateway
tlsPassthrough:
- name: nginx
port: 443
hostname: nginx.example.com
route:
host: "ns1/my-nginx.default.svc.cluster.local"
port: 443
Whenever traffic is to be sent from one cluster to another, one or more of the following would have to be true for it to succeed:
- Both clusters belong to the same network.
- Destination cluster network is not named.
- Organization Setting is set up to send traffic from source cluster to destination cluster.
ClusterDestination
Field | Description | Validation Rule |
---|---|---|
name | string | – |
labels | map<string, string> | – |
network | string | – |
weight | uint32 | – |
Tier1ExternalServer
Tier1ExternalServer describes the properties of a server exposed outside the mesh. Traffic arriving at a Tier1 external server is usually TLS terminated and then forwarded over Istio mTLS to all the lower tier2 clusters.
Field | Description | Validation Rule |
---|---|---|
name | string | string = { |
port | uint32 | uint32 = { |
hostname | string | string = { |
tls | tetrateio.api.tsb.gateway.v2.ServerTLSSettings | – |
clusters | List of tetrateio.api.tsb.gateway.v2.ClusterDestination | – |
redirect | tetrateio.api.tsb.gateway.v2.Redirect | – |
authentication | tetrateio.api.tsb.auth.v2.Authentication | – |
authorization | tetrateio.api.tsb.auth.v2.Authorization | – |
rateLimiting | tetrateio.api.tsb.gateway.v2.RateLimiting | – |
Tier1Gateway
Tier1Gateway
configures a workload to act as a tier1 gateway into the mesh.
Field | Description | Validation Rule |
---|---|---|
workloadSelector | tetrateio.api.tsb.types.v2.WorkloadSelector | message = { |
externalServers | List of tetrateio.api.tsb.gateway.v2.Tier1ExternalServer | – |
internalServers | List of tetrateio.api.tsb.gateway.v2.Tier1InternalServer | – |
passthroughServers | List of tetrateio.api.tsb.gateway.v2.Tier1PassthroughServer | – |
tcpExternalServers | List of tetrateio.api.tsb.gateway.v2.Tier1TCPExternalServer | – |
tcpInternalServers | List of tetrateio.api.tsb.gateway.v2.Tier1TCPInternalServer | – |
Tier1InternalServer
Tier1InternalServer describes the properties of a server exposed within the mesh, for the purposes of forwarding traffic between two clusters that cannot otherwise directly reach each other. Traffic arriving at a Tier1 internal server should be over Istio mTLS. After TLS termination and metrics extraction, it is forwarded to tier2 clusters based on the selection criteria.
Field | Description | Validation Rule |
---|---|---|
name | string | string = { |
hostname | string | string = { |
clusters | List of tetrateio.api.tsb.gateway.v2.ClusterDestination | – |
authentication | tetrateio.api.tsb.auth.v2.Authentication | – |
authorization | tetrateio.api.tsb.auth.v2.Authorization | – |
Tier1PassthroughServer
Tier1PassthroughServer describes the properties of a server exposed to the external world. Traffic arriving at a Tier1 passthrough server is not TLS terminated and rather forwarded over to all the lower tier2 clusters.
Field | Description | Validation Rule |
---|---|---|
name | string | string = { |
port | uint32 | uint32 = { |
hostname | string | string = { |
clusters | List of tetrateio.api.tsb.gateway.v2.ClusterDestination | – |
Tier1TCPExternalServer
Tier1TCPExternalServer is used to describe the properties of a TCP server
(used for opaque TCP or non-HTTP protocols) exposed to the external world.
If the protocol is known to be HTTP, then please use externalServers
as
it allows using HTTP-specific features.
Caveat - Currently, we don't support multicluster routing when Tier2 gateway settings are specified in the direct mode for TCP services. So please use the bridged mode.
Field | Description | Validation Rule |
---|---|---|
name | string | string = { |
port | uint32
Valid scenarios (for same port, multiple services)
Note on service port - If a service is exposed on port 6789 in the tier1 gateway, then it must be exposed on the same port with the same hostname (without wildcard) in the tier2 gateway as well. | uint32 = { |
hostname | string | string = { |
clusters | List of tetrateio.api.tsb.gateway.v2.ClusterDestination | – |
tls | tetrateio.api.tsb.gateway.v2.ServerTLSSettings | – |
Tier1TCPInternalServer
Tier1TCPInternalServer is used to describe the properties of a TCP server which is used exclusively within the mesh.
Field | Description | Validation Rule |
---|---|---|
name | string | – |
hostname | string | string = { |
clusters | List of tetrateio.api.tsb.gateway.v2.ClusterDestination | – |