Gateway API Compatibility

Learn which Gateway API resources NGINX Gateway Fabric supports and the extent of that support.

Summary

Terminology

Gateway API features has three support levels: Core, Extended and Implementation-specific. We use the following terms to describe the support status for each level and resource field:

• Supported. The resource or field is fully supported.
• Partially supported. The resource or field is supported partially, with limitations. It will become fully supported in future releases.
• Not supported. The resource or field is not yet supported. It will become partially or fully supported in future releases.

Note:
It’s possible that NGINX Gateway Fabric will never support some resources or fields of the Gateway API. They will be documented on a case by case basis. NGINX Gateway Fabric doesn’t support any features from the experimental release channel.

Resources

Each resource below includes the support status of their corresponding fields.

For a description of each field, visit the Gateway API documentation.

GatewayClass

NGINX Gateway Fabric supports a single GatewayClass resource configured with the --gatewayclass flag of the static-mode command.

Fields:

• spec
  • controllerName - supported.
  • parametersRef - not supported.
  • description - supported.
• status
  • conditions - supported (Condition/Status/Reason):
    • Accepted/True/Accepted
    • Accepted/False/InvalidParameters
    • Accepted/False/UnsupportedVersion
    • Accepted/False/GatewayClassConflict: Custom reason for when the GatewayClass references this controller, but a different GatewayClass name is provided to the controller via the command-line argument.
    • SupportedVersion/True/SupportedVersion
    • SupportedVersion/False/UnsupportedVersion

Gateway

NGINX Gateway Fabric supports a single Gateway resource. The Gateway resource must reference NGINX Gateway Fabric’s corresponding GatewayClass.

See the static-mode command for more information.

Fields:

• spec
  • gatewayClassName: Supported.
  • listeners
    • name: Supported.
    • hostname: Supported.
    • port: Supported.
    • protocol: Partially supported. Allowed values: HTTP, HTTPS.
    • tls
      • mode: Partially supported. Allowed value: Terminate.
      • certificateRefs - The TLS certificate and key must be stored in a Secret resource of type kubernetes.io/tls. Only a single reference is supported.
      • options: Not supported.
    • allowedRoutes: Supported.
  • addresses: Not supported.
• status
  • addresses: Partially supported (LoadBalancer and Pod IP).
  • conditions: Supported (Condition/Status/Reason):
    • Accepted/True/Accepted
    • Accepted/True/ListenersNotValid
    • Accepted/False/ListenersNotValid
    • Accepted/False/Invalid
    • Accepted/False/UnsupportedValue: Custom reason for when a value of a field in a Gateway is invalid or not supported.
    • Accepted/False/GatewayConflict: Custom reason for when the Gateway is ignored due to a conflicting Gateway. NGINX Gateway Fabric only supports a single Gateway.
    • Programmed/True/Programmed
    • Programmed/False/Invalid
    • Programmed/False/GatewayConflict: Custom reason for when the Gateway is ignored due to a conflicting Gateway. NGINX Gateway Fabric only supports a single Gateway.
  • listeners
    • name: Supported.
    • supportedKinds: Supported.
    • attachedRoutes: Supported.
    • conditions: Supported (Condition/Status/Reason):
      • Accepted/True/Accepted
      • Accepted/False/UnsupportedProtocol
      • Accepted/False/InvalidCertificateRef
      • Accepted/False/ProtocolConflict
      • Accepted/False/UnsupportedValue: Custom reason for when a value of a field in a Listener is invalid or not supported.
      • Accepted/False/GatewayConflict: Custom reason for when the Gateway is ignored due to a conflicting Gateway. NGINX Gateway Fabric only supports a single Gateway.
      • Programmed/True/Programmed
      • Programmed/False/Invalid
      • ResolvedRefs/True/ResolvedRefs
      • ResolvedRefs/False/InvalidCertificateRef
      • ResolvedRefs/False/InvalidRouteKinds
      • Conflicted/True/ProtocolConflict
      • Conflicted/False/NoConflicts

HTTPRoute

Fields:

• spec
  • parentRefs: Partially supported. Port not supported.
  • hostnames: Supported.
  • rules
    • matches
      • path: Partially supported. Only PathPrefix and Exact types.
      • headers: Partially supported. Only Exact type.
      • queryParams: Partially supported. Only Exact type.
      • method: Supported.
    • filters
      • type: Supported.
      • requestRedirect: Supported except for the experimental path field. If multiple filters are configured, NGINX Gateway Fabric will choose the first and ignore the rest. Incompatible with urlRewrite.
      • requestHeaderModifier: Supported. If multiple filters are configured, NGINX Gateway Fabric will choose the first and ignore the rest.
      • urlRewrite: Supported. If multiple filters are configured, NGINX Gateway Fabric will choose the first and ignore the rest. Incompatible with requestRedirect.
      • responseHeaderModifier, requestMirror, extensionRef: Not supported.
    • backendRefs: Partially supported. Backend ref filters are not supported.
• status
  • parents
    • parentRef: Supported.
    • controllerName: Supported.
    • conditions: Partially supported. Supported (Condition/Status/Reason):
      • Accepted/True/Accepted
      • Accepted/False/NoMatchingListenerHostname
      • Accepted/False/NoMatchingParent
      • Accepted/False/NotAllowedByListeners
      • Accepted/False/UnsupportedValue: Custom reason for when the HTTPRoute includes an invalid or unsupported value.
      • Accepted/False/InvalidListener: Custom reason for when the HTTPRoute references an invalid listener.
      • Accepted/False/GatewayNotProgrammed: Custom reason for when the Gateway is not Programmed. HTTPRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
      • ResolvedRefs/True/ResolvedRefs
      • ResolvedRefs/False/InvalidKind
      • ResolvedRefs/False/RefNotPermitted
      • ResolvedRefs/False/BackendNotFound
      • ResolvedRefs/False/UnsupportedValue: Custom reason for when one of the HTTPRoute rules has a backendRef with an unsupported value.
      • PartiallyInvalid/True/UnsupportedValue

ReferenceGrant

Fields:

• spec
  • to
    • group - supported.
    • kind - supports Secret and Service.
    • name- supported.
  • from
    • group - supported.
    • kind - supports Gateway and HTTPRoute.
    • namespace- supported.

TLSRoute

TCPRoute

UDPRoute

BackendTLSPolicy

Fields:

• spec
  • targetRef
    • group - supported.
    • kind - supports Service.
    • name - supported.
    • namespace - supported.
  • tls
    • caCertRefs - supports single reference to a ConfigMap, with the CA certificate in a key named ca.crt.
      • name- supported.
      • group - supported.
      • kind - supports ConfigMap.
    • hostname - supported.
    • wellKnownCerts - supports System. This will set the CA certificate to the Alpine system root CA path /etc/ssl/cert.pem. NB: This option will only work if the NGINX image used is Alpine based. The NGF NGINX images are Alpine based by default.
• status
  • ancestors
    • ancestorRef - supported.
    • controllerName: supported.
    • conditions: Partially supported. Supported (Condition/Status/Reason):
      • Accepted/True/PolicyReasonAccepted
      • Accepted/False/PolicyReasonInvalid

Note:
If multiple backendRefs are defined for a HTTPRoute rule, all the referenced Services must have matching BackendTLSPolicy configuration. BackendTLSPolicy configuration is considered to be matching if 1. CACertRefs reference the same ConfigMap, or 2. WellKnownCACerts are the same, and 3. Hostname is the same.

Custom Policies

Custom policies will be NGINX Gateway Fabric-specific CRDs (Custom Resource Definitions) that will support features such as timeouts, load-balancing methods, authentication, etc. These important data-plane features are not part of the Gateway API specifications.

While these CRDs are not part of the Gateway API, the mechanism to attach them to Gateway API resources is part of the Gateway API. See the Policy Attachment documentation.