Apply recommendations through Helm or GitOps

Prerequisites and identity check

Use kubectl, jq and the Helm or Kustomize tooling for your workload.

Review the recommendation and match its cluster, namespace, workload kind/name and container to your source. Save the current resource values and source revision. If PRA or PRP owns those fields, change its policy instead; see vertical scaling diagnostics.

Insights export	Use in source
JSON, CSV or Markdown	Map each container’s recommended requests/limits to the chart values or workload manifest. These are not Helm values files.
Kustomize ZIP	Inspect target selectors and patches, then incorporate the resource patch into the existing overlay.
kubectl script	Inspect the proposed changes; translate them into source for GitOps-managed workloads.

Direct dashboard or kubectl changes to source-managed fields can be overwritten by the next GitOps reconciliation.

Helm values owned by a release

Find the chart value that renders the selected container’s resources; chart keys differ. Save the original values as values.before.yaml, edit values.yaml, then render both with the same release, chart version, namespace and values stack:

helm template RELEASE CHART --version VERSION --namespace NAMESPACE \
  --values values.before.yaml > rendered.before.yaml
helm template RELEASE CHART --version VERSION --namespace NAMESPACE \
  --values values.yaml > rendered.after.yaml
diff -u rendered.before.yaml rendered.after.yaml

Replace uppercase arguments with the release’s actual settings. Include all additional values files and overrides in both renders. Confirm that the intended container changed and review any chart-generated rollout/checksum changes. Preserve other containers and unmodified resource fields; limits must remain consistent with requests.

Manifest or Kustomize ownership

Edit the workload manifest or add the exported patch to its existing overlay. Example Deployment patch; replace identities and quantities with your selected recommendation:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
  namespace: production
spec:
  template:
    spec:
      containers:
        - name: worker
          resources:
            requests:
              cpu: 250m
              memory: 256Mi

Render before editing and again afterward:

kubectl kustomize OVERLAY > rendered.before.yaml
# Edit the overlay or incorporate the resource patch.
kubectl kustomize OVERLAY > rendered.after.yaml
diff -u rendered.before.yaml rendered.after.yaml

Reconcile, validate and revert

Confirm the target context and compare the rendered manifest with the cluster:

kubectl config current-context
kubectl diff -f rendered.after.yaml

Commit the source change for GitOps reconciliation, or upgrade a directly Helm-managed release using its existing chart version and complete values stack. For a Deployment, substitute the workload namespace, name and pod label selector:

NS=production
WORKLOAD=orders
SELECTOR='app=orders'
kubectl rollout status deployment/"$WORKLOAD" -n "$NS" --timeout=120s
kubectl get pods -n "$NS" -l "$SELECTOR" -o json | \
  jq '.items[] | {pod: .metadata.name, desired: [.spec.containers[] | {name, resources}], actual: .status.containerStatuses}'
kubectl top pods -n "$NS" -l "$SELECTOR" --containers
kubectl get events -n "$NS" --sort-by=.lastTimestamp

Confirm the new resources, successful rollout and restart counts. Compare latency, errors, CPU throttling and OOM events under similar demand. Lower requests alone do not establish node removal or savings.

If performance worsens, restore the previous values or manifest revision, reconcile through the same release process, and repeat these checks. Use Insights diagnostics if recommendations or live values remain unexpected.