Routes Resource Type design #110
Conversation
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
There was a problem hiding this comment.
This design spec needs to include examples of what the Routes resource type looks like and how it will be used in various scenarios (e.g. in conjunction with a container, etc.)
The design should also follow the template: https://github.com/radius-project/design-notes/blob/main/template/YYYY-MM-design-template.md
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
| 1. Deploy and configure their ingress controller of choice | ||
| 2. Create a Kubernetes Gateway resource |
There was a problem hiding this comment.
Can these be built into the Routes Recipe? It'd still be a platform eng concern, but being bundled into the Routes Recipe seems like the right unit of work.
There was a problem hiding this comment.
No. But when you install a Gateway Controller like NGINX, a Gateway resource will get created also. https://github.com/nginx/nginx-gateway-fabric/blob/main/charts/nginx-gateway-fabric/templates/gateway.yaml
|
|
||
| ### Miscellaneous Gateway routes properties | ||
|
|
||
| The following Gateways properties no longer supported since they are ingress controller-specific: |
There was a problem hiding this comment.
If the developer needs access to these platform-specific properties, how would that be enabled for them? Would the platform engineer need to customize the Radius.Compute/routes resource being used? Or would we consider adding a platformOptions property to enable passthroughs?
I think this consideration is especially important for the timeoutPolicy properties as that was something that was community-implemented due to user need (see PR#8739)
There was a problem hiding this comment.
These are not platform-specific properties. They are Contour properties. Timeout would be the exception.
There is a request and backendRequest timeout on the HTTPRoute. However, on an AWS ALB used with ECS, the timeout values are set on the ALB itself (not even the target group).
So I chose to defer support for timeouts in order to accomodate ECS in the future. This of course, is a two-way door and we can add timeout support for the Gateway API anytime.
WDYT?
|
|
||
| ### TLS configuration | ||
|
|
||
| Gateways expects the developer to provide a certificate stored in a Radius Secret. Because TLS is ingress controller-specific, TLS configuration is delegated to the platform engineer and their ingress controller of choice. |
There was a problem hiding this comment.
Would this be delegated to the Routes Recipe implementation and thus owned by the platform eng?
There was a problem hiding this comment.
No. The Gateway Controller is set up as a prerequisite outside of Radius. It's not part of a Recipe. Here is an example using AKS.
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Implementation of radius-project/design-notes#110 --------- Signed-off-by: Zach Casper <zachcasper@microsoft.com>
Implementation of radius-project/design-notes#110 --------- Signed-off-by: Zach Casper <zachcasper@microsoft.com> Signed-off-by: Andrew Matveychuk <andrew@andrewmatveychuk.com>
Implementation of radius-project/design-notes#110 --------- Signed-off-by: Zach Casper <zachcasper@microsoft.com>
5 participants
No description provided.