-
Notifications
You must be signed in to change notification settings - Fork 33
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
Have Istio optional #645
Have Istio optional #645
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #645 +/- ##
==========================================
+ Coverage 80.20% 83.08% +2.87%
==========================================
Files 64 72 +8
Lines 4492 5704 +1212
==========================================
+ Hits 3603 4739 +1136
- Misses 600 639 +39
- Partials 289 326 +37
Flags with carried forward coverage won't be shown. Click here to find out more.
|
pkg/istio/external_authorizer.go
Outdated
return true, nil | ||
} | ||
|
||
func unregisterExternalAuthorizerOSSM(ctx context.Context, cl client.Client, kObj *kuadrantv1beta1.Kuadrant) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we're extracting too much. These OSSM functions do not belong to the istio
package IMO.
The decision of whether to activate Istio or OSSM should continue to happen in the base controller or some abstraction from where we fork towards one path or the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, moving back the logic to register either in istio or OSSM to the controller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good generally, left some comments regarding extra make
command in the some github workflows 🧑💻
ok, err := kuadrantgatewayapi.IsGatewayAPIInstalled(mgr.GetRESTMapper()) | ||
if err != nil { | ||
return err | ||
} | ||
if !ok { | ||
r.Logger().Info("Kuadrant controller disabled. GatewayAPI was not found") | ||
return nil | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should document or put into the log that the operator pod will need to be restarted because the disabled controllers are not reactively started when the dependencies are installed ? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great point. I would try to avoid the restart if we can. If we are to keep the pod running anyway, at least it could retry the conditions in a loop, setup the reconcilers automatically in case the state changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, ideally the controller should keep trying until it finds it.
I thought about implementing it. But I wanted to discuss first the implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be done in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verified, looks good to me anyway 👍
rebasing as there are conflicts with some files |
The operator runs even when Istio or GatewayAPI are not present
Co-authored-by: Kevin Fan <[email protected]>
Co-authored-by: Kevin Fan <[email protected]>
Co-authored-by: Kevin Fan <[email protected]>
Co-authored-by: Guilherme Cassolato <[email protected]>
…d cluster ips' CommitID: 3cd0fa9
type authorizer interface { | ||
GetExtensionProvider() *istiomeshv1alpha1.MeshConfig_ExtensionProvider | ||
} | ||
|
||
type ConfigWrapper interface { | ||
GetConfigObject() client.Object | ||
GetMeshConfig() (*istiomeshv1alpha1.MeshConfig, error) | ||
SetMeshConfig(*istiomeshv1alpha1.MeshConfig) error | ||
} | ||
|
||
type KuadrantAuthorizer struct { | ||
extensionProvider *istiomeshv1alpha1.MeshConfig_ExtensionProvider | ||
} | ||
|
||
// NewKuadrantAuthorizer Creates a new KuadrantAuthorizer | ||
func NewKuadrantAuthorizer(namespace string) *KuadrantAuthorizer { | ||
return &KuadrantAuthorizer{ | ||
extensionProvider: createKuadrantAuthorizer(namespace), | ||
} | ||
} | ||
|
||
// GetExtensionProvider Returns the Istio MeshConfig ExtensionProvider for Kuadrant | ||
func (k *KuadrantAuthorizer) GetExtensionProvider() *istiomeshv1alpha1.MeshConfig_ExtensionProvider { | ||
return k.extensionProvider | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were keeping these interfaces and functions at the abstract level. Does this mean that having a Kuadrant Authorizer became a Istio-specific thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it is an istio specific thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow. We won't deploy Authorino when integrating with Envoy Gateway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we will. But this "kuadrant authorizer" is not deploying authorino. The kuadrant controller is. The "kuadrant authorizer" is to register external auth in istio control plane. AFAIK, EnvoyGateway does not require any registration step in the control plane of EG. @adam-cattermole can confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand, @eguzki. My point is that this abstraction ("Kuadrant Authorizer config") has not been as much of an abstraction as it could be or originally intended.
At the level of the Kuadrant CR/Kuadrant deployment, configuring the Kuadrant Authorizer means ensuring that the Kuadrant deployment has all the configuration it needs for ext_authz requests to be sent to an instance of Authorino in the data plane, when handling traffic for the gateways in the scope of this Kuadrant deployment and it's applicable.
Because so far we only support Istio-based Gateway API controllers, it's easy overlook the difference, but I'm arguing for the decoupling of the abstraction that ensures the external authorizer is configured for a given Gateway API controller from the implementation details that get it done.
IWO, these interfaces belong to the Kuadrant controller and should be fixed to not know as much as they do today about Istio IMHO. In fact, they should not know anything at all about Istio. Only the Istio-specific implementations should know that the way to get the external authorizer configured (in their case) is by patching a "mesh config." Perhaps for other Gateway API controllers (e.g. EG), configuring the external authorizer at the level of the Kuadrant CR means something else; it could even be a no-op – but even that should be hidden behind the abstraction IMO.
Now that we are decoupling the controller from Istio, it looked like the right opportunity to fix this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That abstraction is not meant to decouple from gateway API provider. It is totally coupled to Istio.
type ConfigWrapper interface {
GetConfigObject() client.Object
GetMeshConfig() (*istiomeshv1alpha1.MeshConfig, error)
SetMeshConfig(*istiomeshv1alpha1.MeshConfig) error
}
type KuadrantAuthorizer struct {
extensionProvider *istiomeshv1alpha1.MeshConfig_ExtensionProvider
}
I think the intended design wanted to abstract from the different "flavors" of Istio. But actually, IMHO, there is no abstraction actually. It is something like: "if istioOperator -> do this; else if istio configmap -> do that; else if ossm -> do other thing; else panic".
Anyway, I get your point and I will try something I had in mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer to stab it in separate PR to unblock this one? It's all refactoring in the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Nice work, @eguzki. Let's unblock this and let to tackle the issue of the loosely coupled Gateway API controllers with the future refactoring for sure to come.
What
Part of #325
This is a preparation work for on-boarding EnvoyGateway on following up PRs. It is, essentially, moving Istio from being the required GatewayAPI provider to optional gateway provider. Among other things, being optional means that when Istio is not installed in the cluster, the kuadrant operator does not die. Additionally, make room for on-boarding other GatewayAPI providers.
github.com/kuadrant/kuadrant-operator/pkg/istio
package. Controllers should be the only one importing that package.github.com/kuadrant/kuadrant-operator/tests/bare_k8s
make local-k8s-env-setup
make test-bare-k8s-integration
github.com/kuadrant/kuadrant-operator/tests/gatewayapi
make local-gatewayapi-env-setup
make test-gatewayapi-env-integration
github.com/kuadrant/kuadrant-operator/controllers
make local-env-setup GATEWAYAPI_PROVIDER=[ISTIO|SAIL]
(Default Istio)make test-integration
github.com/kuadrant/kuadrant-operator/tests/istio
make local-env-setup GATEWAYAPI_PROVIDER=ISTIO
make test-istio-env-integration
Defined behavior
Verification Steps: run kuadrant in cluster without GatewayAPI provider
Kudrant CR status reports not ready status