Configure the dakr-op write operator -- auto-apply mode, policy settings, and connection options.

Configuration

The Write Operator is configured via Helm values during installation.

Helm Values

Parameter	Default	Description
`operator.clusterName`	(required)	Unique cluster identifier from DevZero dashboard
`operator.clusterToken`	(required)	Authentication token for the DevZero control plane (may instead come from a Secret/ConfigMap via `operator.tokenFromSecret` / `operator.tokenFromConfigMap`)
`operator.endpoint`	`https://dakr.devzero.io`	DevZero control-plane endpoint
`operator.logLevel`	`error`	Logging verbosity: `debug`, `info`, `error`
`operator.replicas`	`3`	Number of operator replicas
`operator.features.argocdPatching`	`false`	Allow DevZero to manage fields on ArgoCD-owned resources

Pod Placement

To control which nodes the operator's pods can schedule on, set operator.nodeSelector, operator.tolerations, and operator.affinity:

operator:
  nodeSelector:
    nodepool: devzero
  tolerations:
    - key: dedicated
      operator: Equal
      value: devzero
      effect: NoSchedule

helm upgrade --install dakr-operator \
  oci://registry-1.docker.io/devzeroinc/dakr-operator \
  --namespace devzero-system \
  --reuse-values \
  --set operator.nodeSelector.nodepool=devzero \
  --set 'operator.tolerations[0].key=dedicated' \
  --set 'operator.tolerations[0].operator=Equal' \
  --set 'operator.tolerations[0].value=devzero' \
  --set 'operator.tolerations[0].effect=NoSchedule'

The same keys exist per component: scheduler.* (the bundled dz-scheduler), agent.* (the node agent), and webhook.*.

The operator runs hostNetwork by default, so at most one operator replica can run per node — keep operator.replicas within the number of nodes your nodeSelector/tolerations/affinity allow, or surplus replicas stay Pending.

Auto-Apply Mode

By default, the Write Operator surfaces recommendations in the dashboard for manual approval. Automatic application is governed by policies, not Helm values: recommendations that match a policy with autoApply: true arrive from the control plane with spec.autoApply: true on the WorkloadRecommendation CRD and are applied automatically; recommendations with no matching policy remain pending for manual review.

# A workload recommendation applied without manual approval
apiVersion: dakr.devzero.io/v1alpha1
kind: WorkloadRecommendation
spec:
  autoApply: true
  # ... container recommendations

See Policies and Rules for the policy vocabulary that decides which recommendations carry autoApply.

Managing Recommendations

View pending recommendations

kubectl get workloadrecommendations -A

View recommendation details

kubectl describe workloadrecommendation <name> -n <namespace>

Roll back a recommendation

Delete the WorkloadRecommendation CRD to revert the change:

kubectl delete workloadrecommendation <name> -n <namespace>

The operator will restore the original resource values.

ArgoCD Integration

Applying recommendations to resources owned by ArgoCD may cause applications to be marked as OutOfSync or replica counts and request/limits to get overridden, causing contention between what the dakr-operator is applying vs. what the argocd-application-controller deems necessary per GitOps configuration.

To enable DevZero to take ownership of the replica and request/limit fields:

helm upgrade dakr-operator \
  oci://registry-1.docker.io/devzeroinc/dakr-operator \
  --namespace devzero-system \
  --set operator.features.argocdPatching=true \
  --reuse-values

To reset this and have ArgoCD re-take ownership of those fields, set operator.features.argocdPatching to false and redeploy your applications.

Updating Configuration

Configuration changes require an operator restart:

helm upgrade dakr-operator \
  oci://registry-1.docker.io/devzeroinc/dakr-operator \
  --namespace devzero-system \
  --set <your-changes> \
  --reuse-values

kubectl rollout restart deployment/dakr-operator -n devzero-system

Admission Policies

On a cluster whose admission controller requires site-specific labels — an OPA Gatekeeper K8sRequiredLabels constraint, for example — the install is rejected before anything is created, because the chart's pre-install hook Job is denied. The dakr-operator chart accepts commonLabels, commonAnnotations, podLabels, and podAnnotations for this:

helm upgrade --install dakr-operator \
  oci://registry-1.docker.io/devzeroinc/dakr-operator \
  --namespace devzero-system \
  --set commonLabels.cost_center=platform \
  --set commonLabels.service_tier=infra

The same values cover the bundled dz-scheduler objects when operator.customScheduler=true. See Installing Under an Admission Policy for the full behaviour.

Configuration

On this page