Conversation
Reviewer's GuideIntegrates the Kruize Optimizer as a first-class component in the operator by extending the CRD/spec, wiring image configuration and defaults, generating Deployment/Service resources for both OpenShift and Kubernetes flows, and updating the controller to deploy and wait on the new optimizer pod. Sequence diagram for deploying Kruize with OptimizersequenceDiagram
actor Admin
participant KubeAPI as KubernetesAPI
participant Reconciler as KruizeReconciler
participant Generator as KruizeResourceGenerator
participant Constants
participant KubeCtrl as KubernetesController
Admin->>KubeAPI: Apply Kruize CR (includes optimizer_image)
KubeAPI-->>Reconciler: Create/Update event for Kruize
Reconciler->>Reconciler: deployKruize()
Reconciler->>Reconciler: normalize cluster_type
Reconciler->>Generator: NewKruizeResourceGenerator(namespace, autotune_image, autotune_ui_image, optimizer_image, clusterType)
alt optimizer_image empty in CR
Generator->>Constants: GetDefaultOptimizerImage()
Constants-->>Generator: defaultOptimizerImage
end
Reconciler->>Generator: NamespacedResources() / KubernetesNamespacedResources()
Generator-->>Reconciler: Resources including kruize-optimizer Deployment and Service
Reconciler->>KubeAPI: Create/Update resources
KubeAPI-->>KubeCtrl: Reconcile deployments and services
KubeCtrl-->>KubeAPI: Pods running (kruize, kruize-ui-nginx, kruize-db, kruize-optimizer)
Reconciler->>Reconciler: waitForKruizePods()
Reconciler->>KubeAPI: List pods in namespace
KubeAPI-->>Reconciler: Pod statuses
Reconciler->>Reconciler: Check readyPods >= 4 and totalPods >= 4
Reconciler-->>Admin: Deployment complete with optimizer running
Class diagram for updated KruizeSpec and resource generationclassDiagram
class KruizeSpec {
+string cluster_type
+string autotune_image
+string autotune_ui_image
+string optimizer_image
+string namespace
}
class KruizeResourceGenerator {
+string Namespace
+string Autotune_image
+string Autotune_ui_image
+string Optimizer_image
+string ClusterType
+NewKruizeResourceGenerator(namespace string, autotuneImage string, autotuneUIImage string, optimizerImage string, clusterType string) KruizeResourceGenerator
+NamespacedResources() []client_Object
+KubernetesNamespacedResources() []client_Object
+kruizeDeployment() appsv1_Deployment
+kruizeService() corev1_Service
+kruizeDeploymentKubernetes() appsv1_Deployment
+kruizeServiceKubernetes() corev1_Service
+kruizeOptimizerDeployment() appsv1_Deployment
+kruizeOptimizerService() corev1_Service
}
class KruizeReconciler {
+deployKruize(ctx context_Context, kruize *Kruize) error
+deployKruizeComponents(ctx context_Context, namespace string, kruize *Kruize, clusterType string) error
+waitForKruizePods(ctx context_Context, namespace string, timeout time_Duration) error
}
class Constants {
<<utility>>
+GetDefaultAutotuneImage() string
+GetDefaultUIImage() string
+GetDefaultOptimizerImage() string
}
KruizeReconciler --> KruizeSpec : reads
KruizeReconciler --> KruizeResourceGenerator : constructs
KruizeResourceGenerator --> Constants : uses
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The Optimizer deployment hardcodes a lot of behavioral settings (URLs, intervals, target labels, datasource, profiles) in
Env; consider wiring these through the CR or config so they can be tuned without modifying the operator. - Names and labels for the optimizer component (
"kruize-optimizer", port 8080, etc.) are duplicated across deployment, service, and readiness logic; it may be safer to centralize these as constants to avoid subtle drift in future changes.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The Optimizer deployment hardcodes a lot of behavioral settings (URLs, intervals, target labels, datasource, profiles) in `Env`; consider wiring these through the CR or config so they can be tuned without modifying the operator.
- Names and labels for the optimizer component (`"kruize-optimizer"`, port 8080, etc.) are duplicated across deployment, service, and readiness logic; it may be safer to centralize these as constants to avoid subtle drift in future changes.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
config/samples/v1alpha1_kruize.yaml
Outdated
| cluster_type: "openshift" | ||
| autotune_image: "quay.io/kruize/autotune_operator:0.8.1" | ||
| autotune_ui_image: "quay.io/kruize/kruize-ui:0.0.9" | ||
| optimizer_image: "quay.io/rh-ee-shesaxen/optimizer:0.1-test" |
There was a problem hiding this comment.
Can we update the personal image reference to the official optimizer image? Since the operator is public on OperatorHub, using the official registry ensures reliability and follows distribution guidelines.
There was a problem hiding this comment.
Yes, that will be updated. I’ll raise a separate diff PR for it or may be we can wait.
The optimizer PRs are currently under review, once they’re all merged, I’ll create a build with the Kruize org.
There was a problem hiding this comment.
We can also cut a separate release for Optimizer integration if required
|
rebased my PR to mvp_demo |
|
@shekhar316 Tried building an image on top of PR 77 : I'm seeing |
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
Signed-off-by: Shekhar Saxena <shekhar.saxena@ibm.com>
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
|
|
||
| // waitForKruizeDeploymentReady waits specifically for the Kruize deployment to be ready | ||
| // before proceeding with optimizer deployment | ||
| func (r *KruizeReconciler) waitForKruizeDeploymentReady(ctx context.Context, namespace string, timeout time.Duration) error { |
There was a problem hiding this comment.
Can we use an init container here instead of timeout based waiting?
This would make the deployment more robust and eliminate the flakiness of time-based wait.
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
Signed-off-by: SHEKHAR SAXENA <shekhar.saxena@ibm.com>
|
@shekhar316 The init container approach is working and there are no network errors observed in optimizer pod: Just a follow up question on the labels:
Also I think there is syntax error with label current: |
Thanks Shreya for the detailed review. I think this issue is a known and needs a fix on kruize side. @pinkygupta-hub actually raised one PR for fixing this kruize/autotune#1733, but it seems the changes are not working for the labels. Follow up discussion - https://ibm-cloud.slack.com/archives/C0949JK1ABS/p1773636401427069 cc: @dinogun , @kusumachalasani |
For the current PR scope i.e optimizer integration the changes look good, the PR can be merged once the official Kruize-optimizer image is available. |
3 participants
This PR integrates the Kruize Optimizer component into the Kruize operator, enabling advanced optimization capabilities alongside the existing Autotune functionality.
Changes Made
1. API Changes (
api/v1alpha1/kruize_types.go)Optimizer_imagefield toKruizeSpecto allow users to specify a custom Optimizer container imageomitemptytag for backward compatibility2. Image Management (
internal/constants/kruize_images.go)DEFAULT_OPTIMIZER_IMAGEenvironment variable for overriding default imagequay.io/rh-ee-shesaxen/optimizer:0.1-testGetDefaultOptimizerImage()function for retrieving the configured image3. Resource Generation (
internal/utils/kruize_generator.go)kruizeOptimizerDeployment()to generate Optimizer deployment with:kruizeOptimizerService()to expose Optimizer on ClusterIP serviceNewKruizeResourceGenerator()to accept and handle Optimizer image parameter4. Controller Updates (
internal/controller/kruize_controller.go)kruize-optimizerto the list)optimizer_imageparameter5. Sample Configuration (
config/samples/v1alpha1_kruize.yaml)optimizer_imageconfiguration for referenceTechnical Details
Optimizer Configuration:
quay.io/rh-ee-shesaxen/optimizer:0.1-testhttp://kruize:8080http://kruize-optimizer:8080/webhookprometheus-1kruize/autotune: enabledSummary by Sourcery
Integrate the Kruize Optimizer component into the operator and deployment flows alongside existing Autotune services.
New Features:
Enhancements: