-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EPIC: High-Level Technical Plan migration plan #10363
Comments
Some more issues to handle: |
re: migration doesn't seem likely that we can share plugin code. we can export the complex parts of the plugin code as utility functions so that these can be re-used. |
I think that kubegateway likely shouldnt write statuses to deprecated objects. If implementors want to wrap kubegateway then they should be able to do so in a way where there is an extension point to handle additional status setting if needed |
It seems like it may be problematic to read a deprecated type causing internal state and resulting proxy config to change but not write any status noting that we did this. 🤔 |
Proposal for pluginsThis proposal is not very different than what we have today in ggv2; it needed to be updated, as we now Base interfaces: type ObjectSource struct {
Group string `json:"group,omitempty"`
Kind string `json:"kind,omitempty"`
Namespace string `json:"namespace,omitempty"`
Name string `json:"name"`
}
type Upstream struct {
// Ref to source object. sometimes the group and kind are not populated from api-server, so
// set them explicitly here, and pass this around as the reference.
ObjectSource `json:",inline"`
// prefix the cluster name with this string to distringuish it from other GVKs.
// here explicitly as it shows up in stats. each (group, kind) pair should have a unique prefix.
GvPrefix string
// for things that integrate with destination rule, we need to know what hostname to use.
CanonicalHostname string
// original object. Opaque to us other than metadata.
Obj metav1.ObjectMetaAccessor
}
type UpstreamCtx struct {
Upstream Upstream
KrtCtx KCtx
Client Ucc
}
type TranslationCtx struct {
KrtCtx KCtx
Client Ucc
}
// Upstream plugin, directly translates an upstream to a cluster
type UpstreamPlugin interface {
ApplyForUpstream(context.Context, UpstreamCtx, Cluster)
}
// Proxy plugin, translates a proxy IR to a gateway and its listeners
type ProxyPlugin interface {
// Returns new context for proxy translation.
// see definition of ProxyTranslationPass interface below.
// the object returned as ProxyTranslationPass may hold internal only state. It should not have global state, or
// state tied to the parent proxy plugin. it may read state from the ProxyPlugin (i.e. krt collections), but not modify it.
// could be called from multiple go-routines in parallel.
NewTranslationPass(context.Context, TranslationCtx) ProxyTranslationPass
} A translation pass of a "proxy". A proxy is the flattened representation of all our route rules in a listener. A translation pass must not do any IO (like dns resolution) or spawn any goroutines. For example:
Idealy: No errors returned in translation - translation semantics is that it always completes. Each type ProxyTranslationPass interface {
// called 1 time for each listener
ApplyListenerPlugin(
ctx context.Context,
pCtx *plugins.ListenerContext,
out *envoy.Listener,
)
ApplyVhostPlugin(
ctx context.Context,
pCtx *plugins.VirtualHostContext,
out *envoy.VirtualHost,
)
// called for each route rule
ApplyForRoute(
ctx context.Context,
pCtx *plugins.RouteContext,
out *envoy.Route)
// called exactly 1 time
// if a plugin emits new filters, they must be with a unique name (so different plugins can emit the same filters).
HttpFilters(ctx, ...)
} |
looking the plugins from the open source repo:
|
why do we want to keep VHost around? IMO we should do everything possible to get rid of this concept and map only to the Gateway API concepts, i.e.:
|
Initially this could be fine but we will need some way for users to create a static proxy to enable static gateway provisioning. I also think we should revisit our implementation in general here, related to https://github.com/solo-io/solo-projects/issues/7302 |
this is more of a sketch; i don't mind the specifics; i'm ok with doing the gw api semantics |
makes sense; maybe we can do 2 helm charts? so users can deploy gateway manually if they want to; and we will use the same chart for auto-deploy? |
to clarify a bit more: the idea here is to tweak the plugin model a bit so that each translation means a new call to |
Background
Solo.io is donating it's gloo-gateway project to the CNCF. As part of this process, we will need to restructure some of the code for the following reasons:
Goals
Non-Goals
Plan
Overview:
Order of operations:
Fix CI (should be done first)
Ideally this should be done first, so we have CI for the next steps.
Bisect gloo and KubeGateway
Goal:
Steps:
Opaque extendablity
Goal:
Steps:
Helm chart (can be done in parallel)
Questions / Discussion
go-control-plane
? it seems to support more features now than the solo-kit one.The text was updated successfully, but these errors were encountered: