You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, the controller only processes routes (HTTP, GRPC, etc) which contain a parentRef pointing to a gateway defined against the controller's gateway class. For example:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-hotel
spec:
gatewayClassName: amazon-vpc-lattice <<-- denotes a gateway we're managing in the controller
listeners:
...
and
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: inventory
spec:
parentRefs:
- name: my-hotel <<-- links this route to a gateway we're managing
sectionName: http
rules:
...
When these routes are reconciled, we create VPC Lattice services and associate them to the service network corresponding to the gateway or to the DEFAULT_SERVICE_NETWORK when ENABLE_SERVICE_NETWORK_OVERRIDE is set.
However, there are cases where we want to be able to create standalone VPC Lattice services that are not, by default, associated with a service network. This allows decoupling of service creation and ownership from service network membership, which is desirable in some scenarios.
This should not be a large change, but will require:
A mechanism to denote a "standalone" route should be processed by the controller but not associated to a service network
Look at logic which pulls values or validates the route against the gateway - may need updating
Conditionally execute service network association logic
(edited to focus on requirements not solution)
The text was updated successfully, but these errors were encountered:
For the standalone HTTPRoute idea, I think it’d be helpful to keep using the Gateway and GatewayClass, so we know the HTTPRoute is meant for VPC Lattice. We could then skip linking the Gateway with the VPC Lattice Service Network if a specific annotation or infrastructure annotation is defined on the Gateway resource.
When the annotation is applied to the Gateway, the controller reconciliation process could be adjusted to only create the VPC Lattice Service, without associating it with the VPC Lattice Service Network.
I think this method would help us separate service creation from service network management while following the standard Gateway API specification. What do you think about this approach?
I agree that sounds better. I've updated the original issue text to reflect the requirements more than the solution. I think we could put annotations either on the gateway or the route (or both, potentially) to provide the functionality.
Today, the controller only processes routes (HTTP, GRPC, etc) which contain a parentRef pointing to a gateway defined against the controller's gateway class. For example:
and
When these routes are reconciled, we create VPC Lattice services and associate them to the service network corresponding to the gateway or to the
DEFAULT_SERVICE_NETWORK
whenENABLE_SERVICE_NETWORK_OVERRIDE
is set.However, there are cases where we want to be able to create standalone VPC Lattice services that are not, by default, associated with a service network. This allows decoupling of service creation and ownership from service network membership, which is desirable in some scenarios.
This should not be a large change, but will require:
(edited to focus on requirements not solution)
The text was updated successfully, but these errors were encountered: