Skip to content
This repository has been archived by the owner on Mar 19, 2024. It is now read-only.

Latest commit

 

History

History
148 lines (141 loc) · 7.03 KB

supported-features.md

File metadata and controls

148 lines (141 loc) · 7.03 KB
Raw

Supported Features

Below is a list of the Kubernetes Gateway API features supported in the current release of the Consul API Gateway.

Consul API Gateway version: v0.5.0 Supported K8s Gateway API version: v1beta1

Supported features are marked with a grey checkbox

Supported K8s Gateway API Features

  • GatewayClass

    • Spec
      • Controller Matching
      • Parameter specification introduction of GatewayClassConfig CRD and validation that only it is used
    • Finalizers
    • Status
      • Accepted
        • Accepted
        • InvalidParameters
        • Waiting no need to set directly, since it's the default, unreconciled status

  • Gateway

    • Spec
      • GatewayClass/Controller matching
      • Listeners
        • Name matching on route insertion
        • Port specification need to test listener merging behavior
        • Protocols
          • HTTP
          • HTTPS
          • TCP
          • TLS
          • UDP
        • Hostname matching
          • HTTP
          • HTTPS no SNI checks right now
          • TLS
        • Allowed routes
          • Namespace matching on route insertion
          • Route kind matching on insertion
          • Route rule selection for multiple route rule matches
        • TLS
          • Modes
            • Terminate
            • Passthrough explicitly not supported yet
          • Certificate References only single Kubernetes secret certificates supported for now
          • Options
            • "api-gateway.consul.hashicorp.com/tls_min_version"
            • "api-gateway.consul.hashicorp.com/tls_max_version"
            • "api-gateway.consul.hashicorp.com/tls_cipher_suites"
      • Addresses not supported
    • Deployment based off of a snapshot of GatewayClass configuration at time of Gateway creation as per spec suggestions
    • Status
      • Addresses
      • Listeners
        • Conflicted
          • NoConflicts
          • HostnameConflict
          • ProtocolConflict
          • RouteConflict unused due to the spec's confusion between when to accept a route or not, we choose not to accept routes that don't match whatever routing support the listener has
        • Detached
          • Attached
          • PortUnavailable unused, as the only time a port will be unavailable is if we can't schedule the Gateway due to host port binding, which will result in a gateway Schedule status of NoResources
          • UnsupportedExtension unused, not sure what the spec is referring to by "extensions" for listeners
          • UnsupportedProtocol marked for any non-HTTP/HTTPS protocols for now
          • UnsupportedAddress set if the user specified an address for the gateway
        • Ready
          • Ready
          • Invalid leveraged for anything that doesn't match spec guidelines, i.e. HTTPS protocol not specifying a TLS configuration
          • Pending
        • ResolvedRefs
          • ResolvedRefs
          • InvalidCertificateRef
          • InvalidRouteKinds
          • RefNotPermitted this is unclear from the spec, talks about setting RefNotPermitted on the route in one place, and on the listener in another -- pretty sure it shouldn't be on the listener
      • Conditions
        • Ready
          • Ready
          • ListenersNotValid
          • ListenersNotReady
          • AddressNotAssigned set when someone specifies an address for the Gateway, since we don't support them
        • Scheduled
          • NotReconciled
          • NoResources
          • PodFailed status added for when a deployment has crashed for some reason
          • Unknown for any potentially unhandled Pod scheduling statuses
        • InSync condition added to indicate synchronization with Consul
          • InSync if our latest attempt to sync to Consul was successful
          • SyncError if our latest attempt to sync failed, the condition message contains the sync error message

  • HTTPRoute

    • Spec
      • Hostnames
      • Rules
        • Route matching
          • Path-based matching
          • Header-based matching
          • Query-based matching
          • Method-based matching
        • Filters
          • Header modification
            • Set headers
            • Add headers
            • Remove headers
          • Request mirroring
          • Request redirecting
          • URL Rewrite
            • Path Prefix Rewrite
            • Full Path Rewrite
          • Extensions not supported
      • Backend Refs
        • Filters (see above)
        • References
          • Weights
          • Group/Kind only Kubernetes services with Consul entries supported for now
          • Name/Namespace lookups
          • Port check for existence, but ignored for Kubernetes services since we get our ports from Consul
    • Status
      • Parent status updates on insertion
        • Accepted note that all of these are custom since the spec doesn't define reasons for the conditions
          • Accepted indicates route accepted by the gateway parent reference
          • InvalidRouteKind rejected by the gateway because it doesn't match the listener allowed routes
          • ListenerNamespacePolicy rejected by the gateway because it doesn't match the listener namespace policy
          • ListenerHostnameMismatch rejected because of hostname mismatches between listener and route
          • BindError generic error for things like label parsing issues
        • ResolvedRefs note that all of these are custom since the spec doesn't define reasons for the conditions
          • ResolvedRefs indicates that we were able to resolve all route references to things like Kubernetes/Consul services
          • ServiceNotFound weren't able to find the referenced Kubernetes service
          • ConsulServiceNotFound weren't able to find the referenced Consul mesh service
          • RefNotPermitted weren't able to route across namespaces due to a missing ReferenceGrant
          • InvalidKind backend reference is an unknown or unsupported kind
          • BackendNotFound backend reference is a supported kind but does not exist

  • TCPRoute - we are limited by Consul's ability to only route to a single TCP-based upstream, so TCP-based Gateway listeners only support a single TCPRoute with a single rule with a single backend; otherwise, either the TCPRoute is considered invalid or the Gateway status is set as having conflicting routes.

  • TLSRoute - TODO

  • UDPRoute not supported

  • ReferenceGrant - Routes currently require ReferenceGrant for all BackendRefs, and do not support partial acceptance if any BackendRefs are unpermitted

    • From
      • HTTPRoute
      • TCPRoute
      • TLSRoute
      • UDPRoute
      • Gateway
    • To
      • Service
      • Secret

  • ReferencePolicy - Supported for backwards compatibility, will be removed in a future release