Cluster Proactive Policies

​

Reference Rules

• ClusterProactivePolicy is cluster-scoped and references a ClusterAutomationStrategy.
• Helm can generate ClusterProactivePolicy resources from scope, but they can also be managed directly with manifests or GitOps.
• By default, only one same-kind cluster proactive policy contributes to a workload. With globalConfiguration.multiPolicyContainerRightsizingEnabled: true, different container/resource targets can come from different policies; PolicyEvaluation resolves overlapping targets. See Multi-Policy Container Rightsizing.

​

Field Reference

​

Example

apiVersion: rightsizing.kubex.ai/v1alpha1
kind: ClusterProactivePolicy
metadata:
  name: platform-prod-proactive
spec:
  scope:
    containers:
      - api
      - worker
    labelSelector:
      matchLabels:
        team: platform
      matchExpressions:
        - key: environment
          operator: In
          values:
            - production
            - staging
    workloadTypes:
      - Deployment
      - StatefulSet
      - Rollout
    namespaceSelector:
      operator: NotIn
      values:
        - kube-system
        - kubex
  automationStrategyRef:
    name: platform-conservative
  weight: 50
  safetyChecks:
    maxAnalysisAgeDays: 5

​

Notes

• Use cluster proactive policies when a platform team needs one recommendation-driven policy across many namespaces.
• Helm-managed policies accept the same list through scope[].containers.
• Start with narrow namespace and label selectors, then widen scope after verifying the selected-policy behavior in events and controller logs.
• Model is included in default workload types. Use spec.scope.workloadTypes: [Model] when you want to restrict scope to KubeAI Model objects only. Recommendations and rollback state are stored on the Model owner, then inherited by model-owned pods.
• GPU scheduler behavior still comes from the referenced ClusterAutomationStrategy; proactive recommendations only supply the desired GPU request value.
• If you need per-namespace ownership instead, use namespaced ProactivePolicy.
• EXPERIMENTAL: Recommendations can now include gpu.gpuOverallOptimal, which is applied as a proactive requests.gpu target. See the GPU Sharing with KAI guide for more information.