ingress2gateway

The provider generates a K8S API Gateway Listener for every host in every server defined in istio.Gateway.spec.Server.

Listener Naming Convention: To ensure uniqueness within the Gateway, listener names follow the format: $PROTOCOL_NAME-protocol-$NAMESPACE-ns-$HOSTNAME

Protocol Mapping:

TLS Mode Mapping:

The translator automatically manages connectivity between the Gateway and VirtualServices, especially when they reside in different namespaces.

ParentRef Generation: parentRefs for an xRoute are generated if:

1. The VirtualService can be exported to the Gateway's namespace (based on virtualService.Spec.ExportTo).
2. There is an overlap between the Gateway's Server.Hosts and the virtualService.Spec.Hosts.

ReferenceGrant Creation: If the Gateway and the VirtualService are in different namespaces, the translator creates a ReferenceGrant to allow the translated xRoute to successfully reference the translated Gateway.

Ingress2gateway uses a two-stage pipeline to translate resources:

1. Providers: These components read Ingress resources and provider-specific Custom Resource Definitions (CRDs), then convert them into a generic intermediate representation (IR).
2. Emitters: These components take the IR and produce the final Gateway API output.

By default, the standard emitter produces core Gateway API resources like Gateway and HTTPRoute. Other emitters can produce resources tailored to specific projects, such as EnvoyGateway BackendTrafficPolicy or GKE HealthCheckPolicy.

The NGINX provider supports two annotations for handling SSL redirects. Both annotations result in the same behavior: redirecting all HTTP traffic to HTTPS using a 301 status code.

• nginx.org/redirect-to-https: The standard NGINX annotation.
• ingress.kubernetes.io/ssl-redirect: A legacy annotation provided for compatibility.

The provider translates non-HTTP Istio VirtualService configurations into specialized Gateway API routes:

TLS Translation (TLSRoute):

• match.sniHosts $\rightarrow$ TLSRouteSpec.Hostnames
• route []RouteDestination $\rightarrow$ []gw.BackendRef

TCP Translation (TCPRoute):

• route []RouteDestination $\rightarrow$ []gw.BackendRef

When nginx.ingress.kubernetes.io/ssl-passthrough is set to true, the provider replaces the HTTPRoute for the Ingress with a TLSRoute in TLS passthrough mode. For each matching hostname, a new TLS listener (port 443, Passthrough mode) is added to the Gateway.

metadata:
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"

To ensure deterministic generated Gateway API configurations, ingress2gateway processes Ingress resources using a specific sorting order. This order also determines precedence when Ingress resources or routes conflict.

Precedence Rules:

1. Creation Timestamp: Ingress resources with the oldest creation timestamp are processed first and given precedence.
2. Namespace/Name: If creation timestamps are identical, resources are sorted by their namespace/name.

Conflict Handling: If an Ingress rule conflicts with another (for example, having the same path match but different backends), an error is reported for the resource that sorted later in the sequence. This logic follows the Gateway API conflict resolution guidelines.

The Istio Provider acts as a translator that converts Istio API entities into Kubernetes Gateway API resources.

Supported Translations:

• Istio Gateway $\rightarrow$ K8S API Gateway
• Istio VirtualService $\rightarrow$ HTTPRoute, TLSRoute, or TCPRoute (depending on the protocol)
• Cross-namespace references $\rightarrow$ ReferenceGrant and xRoute.parentRefs generation

Translation Logic:

• Fields with direct equivalents are translated.
• Fields that cannot be translated directly are logged and ignored. Users are responsible for handling these edge cases manually.