### Get Help for Druid Operator Makefile Commands

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/dev_doc.md

Command to display help information for the Makefile, which lists all available commands and their explanations for the Druid Operator project.

```shell
# For help
make help
```

--------------------------------

### Install Hadoop Dependencies with Init Container (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This snippet demonstrates how to use an init container to download Hadoop dependencies for Druid. It mounts an emptyDir volume to store the dependencies and uses a Java command to pull them from a specified Maven repository. The `runAsInit: true` flag ensures this container runs before the main application container.

```yaml
spec:
  volumeMounts:
    - mountPath: /opt/druid/hadoop-dependencies
      name: hadoop-dependencies
  volumes:
    - emptyDir:
        sizeLimit: 500Mi
      name: hadoop-dependencies
  additionalContainer:
    - command:
        - java
        - -cp
        - lib/*
        - -Ddruid.extensions.hadoopDependenciesDir=/hadoop-dependencies
        - org.apache.druid.cli.Main
        - tools
        - pull-deps
        - -h
        - org.apache.hadoop:hadoop-client:3.3.0
        - --no-default-hadoop
      containerName: hadoop-dependencies
      image: apache/druid:25.0.0
      runAsInit: true
      volumeMounts:
        - mountPath: /hadoop-dependencies
          name: hadoop-dependencies
```

--------------------------------

### Deploy Sample Druid Cluster using kubectl

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/getting_started.md

Deploys a sample single-node Druid cluster using provided YAML files. This example is suitable for single-node Kubernetes environments like kind or minikube, utilizing local disk for deep storage. It also mentions how to deploy clusters with distributed deep storage.

```bash
# Deploy single node zookeeper
kubectl apply -f examples/tiny-cluster-zk.yaml

# Deploy druid cluster spec
# NOTE: add a namespace when applying the cluster if you installed the operator with the default DENY_LIST
kubectl apply -f examples/tiny-cluster.yaml
```

--------------------------------

### Coordinator Dynamic Configurations Example (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Provides an example of setting dynamic configurations for Coordinator nodes in the druid-operator. These configurations, such as segment balancing and replication settings, are defined within the 'coordinators' section under 'nodes' in the Druid manifest.

```yaml
spec:
  nodes:
    coordinators:
      dynamicConfig:
        millisToWaitBeforeDeleting: 900000
        mergeBytesLimit: 524288000
        mergeSegmentsLimit: 100
        maxSegmentsToMove: 5
        replicantLifetime: 15
        replicationThrottleLimit: 10
        balancerComputeThreads: 1
        killDataSourceWhitelist: []
        killPendingSegmentsSkipList: []
        maxSegmentsInNodeLoadingQueue: 100
        decommissioningNodes: []
        pauseCoordination: false
        replicateAfterLoadTimeout: false
        useRoundRobinSegmentAssignment: true
```

--------------------------------

### Configure Ingress for Broker Nodes in Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This configuration example shows how to set up ingress for broker nodes in the Druid Operator. It includes ingress annotations, class name, host rules, and TLS settings for secure communication.

```yaml
...
  nodes:
    brokers:
      nodeType: "broker"
      druid.port: 8080
      ingressAnnotations:
          "nginx.ingress.kubernetes.io/rewrite-target": "/"
      ingress:
        ingressClassName: nginx # specific to ingress controllers.
        rules:
        - host: broker.myhostname.com
          http:
            paths:
            - backend:
                service:
                  name: broker_svc
                  port:
                    name: http
              path: /
              pathType: ImplementationSpecific
        tls:
        - hosts:
          - broker.myhostname.com
          secretName: tls-broker-druid-cluster
...
```

--------------------------------

### Overlord Dynamic Configurations Example (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Demonstrates how to configure dynamic settings for Overlord nodes within the druid-operator. This is specified under the 'middlemanagers' section within the 'nodes' element of the Druid manifest, allowing for runtime adjustments to scaling and auto-scaling behavior.

```yaml
spec:
  nodes:
    middlemanagers:
      dynamicConfig:
        type: default
        selectStrategy:
          type: fillCapacityWithCategorySpec
          workerCategorySpec:
            categoryMap: {}
            strong: true
        autoScaler: null
```

--------------------------------

### Run Druid Operator Locally with Kubebuilder

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/dev_doc.md

Commands to set up a local Kubernetes cluster using kind, install Custom Resource Definitions (CRDs), and run the Druid Operator locally. Requires Kubebuilder and kind.

```shell
# If needed, create a kubernetes cluster (requires kind)
make kind

# Install the CRDs
make install

# Run the operator locally
make run
```

--------------------------------

### Add Configuration File to _common Directory in Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This example demonstrates how to add a custom configuration file, such as 'mapred-site.xml', to the '_common' directory of the Druid Operator. It involves creating a ConfigMap and referencing it in the Druid resource's 'extraCommonConfig'.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: hadoop-mapred-site.xml
data:
  mapred-site.xml: |
    <?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
    <configuration>
        <property>
            <name>dfs.nameservices</name>
            <value>...</value>
        </property>
    </configuration>
---
apiVersion: druid.apache.org/v1alpha1
kind: Druid
metadata:
  name: druid
spec:
  extraCommonConfig:
    - name: hadoop-mapred-site.xml
      namespace: druid
...
```

--------------------------------

### Helm Installation of Druid Operator

Source: https://context7.com/justtrackio/druid-operator/llms.txt

Installs the Druid Operator using Helm charts. Supports both cluster-scoped and namespace-scoped deployments. Requires adding the DataInfra Helm repository and provides commands for installation, uninstallation, and namespace configuration.

```bash
helm repo add datainfra https://charts.datainfra.io
helm repo update

# Cluster-scoped installation (watches all namespaces except deny-listed ones)
helm -n druid-operator-system upgrade -i --create-namespace cluster-druid-operator datainfra/druid-operator

# Namespace-scoped installation (watches specific namespace)
kubectl create ns mynamespace
helm -n druid-operator-system upgrade -i --create-namespace \
  --set env.WATCH_NAMESPACE="mynamespace" \
  namespaced-druid-operator datainfra/druid-operator

# Override default deny list
helm -n druid-operator-system upgrade -i --create-namespace \
  --set env.DENY_LIST="kube-system" \
  namespaced-druid-operator datainfra/druid-operator

# Uninstall (remove CRD annotation first for complete cleanup)
kubectl annotate crd druids.druid.apache.org helm.sh/resource-policy-
helm -n druid-operator-system uninstall cluster-druid-operator
```

--------------------------------

### Configure Additional Containers in Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This YAML defines how to add extra containers to Druid resources managed by the operator. It shows examples for both cluster-level additional containers and node-level containers for brokers.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: Druid
metadata:
  name: additional-containers
spec:
  additionalContainer:
    - command:
        - /bin/sh echo hello
      containerName: cluster-level
      image: hello-world
  nodes:
    brokers:
      additionalContainer:
        - command:
            - /bin/sh echo hello
          containerName: node-level
          image: hello-world
```

--------------------------------

### Install Druid Operator in Cluster Scope using Helm

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/getting_started.md

Installs the Druid operator in cluster scope using Helm. This command deploys the operator to manage Druid clusters across all namespaces. It also shows how to generate the manifest.yaml for alternative installation methods.

```bash
# Install Druid operator using Helm
helm -n druid-operator-system upgrade -i --create-namespace cluster-druid-operator datainfra/druid-operator

# ... or generate manifest.yaml to install using other means:
helm -n druid-operator-system template --create-namespace cluster-druid-operator datainfra/druid-operator > manifest.yaml
```

--------------------------------

### Build and Apply Kustomize Manifests (Shell)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Builds the deployment manifests using Kustomize and applies them to the Kubernetes cluster. This command is used to deploy the operator with the specified configurations.

```shell
kustomize build config/default | kubectl apply -f -
```

--------------------------------

### Get Druid Operator Deployment YAML (Bash)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Retrieves the current Druid Operator deployment configuration in YAML format for modification. This is the first step in updating a Helm-managed deployment.

```bash
kubectl get deployments.apps -n druid-operator druid-operator -o yaml > druid-deployment-temp.yaml
```

--------------------------------

### Build Druid Operator Docker Image

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/dev_doc.md

Commands to build the Docker image for the Druid Operator. Allows building with a default image name or a custom specified name and tag.

```shell
make docker-build

# In case you want to build it with a custom image:
make docker-build IMG=custom-name:custom-tag
```

--------------------------------

### Secure Metadata Storage Password (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This example shows how to secure the Druid metadata storage password using a Kubernetes Secret. A `Secret` object stores the password, and the `Druid` custom resource references this secret via `envFrom` to inject the password as an environment variable. The `runtime.properties` then uses a JSON configuration to read the password from this environment variable.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: metadata-storage-password
  namespace: <NAMESPACE>
type: Opaque
data:
  METADATA_STORAGE_PASSWORD: <PASSWORD>
---
apiVersion: druid.apache.org/v1alpha1
kind: Druid
metadata:
  name: druid
spec:
  envFrom:
    - secretRef:
        name: metadata-storage-password
  nodes:
    master:
      runtime.properties: |
        # General
        druid.service=druid/coordinator

        # Metadata Storage
        druid.metadata.storage.type=<TYPE>
        druid.metadata.storage.connector.connectURI=<URI>
        druid.metadata.storage.connector.user=<USERNAME>
        druid.metadata.storage.connector.password={ "type": "environment", "variable": "METADATA_STORAGE_PASSWORD" }
...
```

--------------------------------

### Install Druid Operator in Custom Namespaces using Helm

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/getting_started.md

Installs the Druid operator in a specific namespace, restricting its reconciliation scope. This allows for more granular control over where the operator manages Druid clusters. It demonstrates setting the WATCH_NAMESPACE and overriding the DENY_LIST, and generating manifest.yaml.

```bash
# Install Druid operator using Helm
kubectl create ns mynamespace
helm -n druid-operator-system upgrade -i --create-namespace --set env.WATCH_NAMESPACE="mynamespace" namespaced-druid-operator datainfra/druid-operator

# Override the default namespace DENY_LIST
helm -n druid-operator-system upgrade -i --create-namespace --set env.DENY_LIST="kube-system" namespaced-druid-operator datainfra/druid-operator

# ... or generate manifest.yaml to install using other means:
helm -n druid-operator-system template --set env.WATCH_NAMESPACE=""  namespaced-druid-operator datainfra/druid-operator --create-namespace > manifest.yaml
```

--------------------------------

### Configure Rules for Data Management in DruidIngestion (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Specifies rules for automated data management within a DruidIngestion CRD. This example demonstrates setting replication tiers and defining a period for data dropping, enabling automated data lifecycle policies.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: DruidIngestion
metadata:
  name: example-druid-ingestion
spec:
  ingestion:
    type: native-batch
    rules:
      - type: "loadForever"
        tieredReplicants:
          _default_tier: 2
      - type: "dropByPeriod"
        period: "P7D"

```

--------------------------------

### Run Druid Operator Tests

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/dev_doc.md

Commands to execute the test suite for the Druid Operator. Includes running unit tests and end-to-end (E2E) tests, which require a kind cluster.

```shell
# Run unit tests
make test 

# Run E2E tests (requires kind)
make e2e
```

--------------------------------

### Debugging Druid Operator Pods and Services

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/getting_started.md

Provides common kubectl commands for debugging the Druid operator and deployed Druid clusters. This includes retrieving pod names, checking logs, describing Druid resources, and verifying service, config map, and stateful set deployments.

```bash
# get druid-operator pod name
kubectl get po | grep druid-operator

# check druid-operator pod logs
kubectl logs <druid-operator pod name>

# check the druid spec
kubectl describe druids tiny-cluster

# check if druid cluster is deployed
kubectl get svc | grep tiny
kubectl get cm | grep tiny
kubectl get sts | grep tiny
```

--------------------------------

### Set Kustomize Namespace (Shell)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Configures the target namespace for Kustomize deployments. This command modifies the Kustomize configuration to deploy resources into a specific namespace.

```shell
cd config/default
kustomize edit set namespace druid-operator
cd ../../
```

--------------------------------

### Configure Namespace Watching for Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/dev_doc.md

Environment variables to control which namespaces the Druid Operator watches. Can watch all namespaces, a single specific namespace, or all except a deny-listed set.

```shell
# Watch all namespaces
export WATCH_NAMESPACE=""

# Watch a single namespace
export WATCH_NAMESPACE="mynamespace"

# Watch all namespaces except: kube-system, default
export DENY_LIST="kube-system,default"
```

--------------------------------

### Configure Hot/Cold Historical Pods in Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This configuration defines separate settings for 'hot' and 'cold' historical pods within the Druid Operator. It specifies environment variables, probe configurations, resource limits, and runtime properties for each node type.

```yaml
...
  nodes:
    hot:
      druid.port: 8083
      env:
      - name: DRUID_XMS
        value: 2g
      - name: DRUID_XMX
        value: 2g
      - name: DRUID_MAXDIRECTMEMORYSIZE
        value: 2g
      livenessProbe:
          failureThreshold: 3
          httpGet:
          path: /status/health
          port: 8083
          initialDelaySeconds: 1800
          periodSeconds: 5
      nodeConfigMountPath: /opt/druid/conf/druid/cluster/data/historical
      nodeType: historical
      podDisruptionBudgetSpec:
          maxUnavailable: 1
      readinessProbe:
          failureThreshold: 18
          httpGet:
          path: /druid/historical/v1/readiness
          port: 8083
          periodSeconds: 10
      replicas: 1
      resources:
          limits:
            cpu: 3
            memory: 6Gi
          requests:
            cpu: 1
            memory: 1Gi
      runtime.properties:
          druid.plaintextPort=8083
          druid.service=druid/historical/hot
    cold:
      druid.port: 8083
      env:
      - name: DRUID_XMS
        value: 1500m
      - name: DRUID_XMX
        value: 1500m
      - name: DRUID_MAXDIRECTMEMORYSIZE
        value: 2g
      livenessProbe:
        failureThreshold: 3
        httpGet:
          path: /status/health
          port: 8083
        initialDelaySeconds: 1800
        periodSeconds: 5
      nodeConfigMountPath: /opt/druid/conf/druid/cluster/data/historical
      nodeType: historical
      podDisruptionBudgetSpec:
        maxUnavailable: 1
      readinessProbe:
        failureThreshold: 18
        httpGet:
          path: /druid/historical/v1/readiness
          port: 8083
        periodSeconds: 10
      replicas: 1
      resources:
        limits:
          cpu: 4
          memory: 3.5Gi
        requests:
          cpu: 1
          memory: 1Gi
      runtime.properties:
        druid.plaintextPort=8083
        druid.service=druid/historical/cold
...
```

--------------------------------

### Securely Injecting Secrets and Druid Properties via Environment Variables (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This YAML configuration demonstrates the recommended method for securely injecting secrets and Druid properties using environment variables. It defines a Kubernetes `Secret` containing sensitive data like AWS credentials and Druid configuration values. The `Druid` resource then uses the `spec.env` section to load these secrets directly as environment variables, including mapping them to Druid properties using the `druid_` prefix convention.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: prod-druid
  namespace: druid
type: Opaque
stringData:
  # Sensitive values
  AWS_ACCESS_KEY_ID: "AKIA..."
  AWS_SECRET_ACCESS_KEY: "SECRET..."
  # You can map full property values here
  druid.metadata.storage.connector.password: "db-password"
  druid.metadata.storage.connector.connectURI: "jdbc:postgresql://..."
---
apiVersion: druid.apache.org/v1alpha1
kind: Druid
metadata:
  name: druid
spec:
  env:
    # 1. Standard Env Vars
    - name: AWS_REGION
      value: "nyc3"

    # 2. Loading Secrets
    - name: AWS_ACCESS_KEY_ID
      valueFrom:
        secretKeyRef:
          name: prod-druid
          key: AWS_ACCESS_KEY_ID
    - name: AWS_SECRET_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: prod-druid
          key: AWS_SECRET_ACCESS_KEY

    # 3. Mapping Secrets directly to Druid Properties
    # The Docker entrypoint converts 'druid_x_y' -> 'druid.x.y'

    # Maps to: druid.metadata.storage.connector.password
    - name: druid_metadata_storage_connector_password
      valueFrom:
        secretKeyRef:
          name: prod-druid
          key: druid.metadata.storage.connector.password

    # Maps to: druid.metadata.storage.connector.connectURI
    - name: druid_metadata_storage_connector_connectURI
      valueFrom:
        secretKeyRef:
          name: prod-druid
          key: druid.metadata.storage.connector.connectURI

  nodes:
    coordinators:
      nodeType: "coordinator"
      # ...
      runtime.properties: |
        druid.service=druid/coordinator
        # Note: AWS Keys and Metadata configs are NOT listed here
        # because they are injected via the 'env' section above.
        druid.metadata.storage.type=postgresql
        druid.metadata.storage.connector.user=druid
```

--------------------------------

### Update Controller Image Tag with Kustomize (Shell)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Updates the container image tag for the controller within Kustomize configuration files. This is typically done before building and applying the new deployment manifests.

```shell
cd config/manager
kustomize edit set image controller=datainfrahq/druid-operator:${IMG_TAG}
cd ../../
```

--------------------------------

### Override Default Probes for Broker Nodes in Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/examples.md

This YAML snippet demonstrates how to override the default liveness and readiness probes for broker nodes in the Druid Operator. It specifies custom paths, ports, and timing parameters for the probes.

```yaml
...
  nodes:
    brokers:
      kind: Deployment
      nodeType: "broker"
      druid.port: 8088
      nodeConfigMountPath: "/opt/druid/conf/druid/cluster/query/broker"
      replicas: 2
      podDisruptionBudgetSpec:
        maxUnavailable: 1
        selector:
          matchLabels:
            app: druid
            component: broker
      livenessProbe:
        httpGet:
          path: /status/health
          port: 8088
        failureThreshold: 10
        initialDelaySeconds: 60
        periodSeconds: 30
        successThreshold: 1
        timeoutSeconds: 10
      readinessProbe:
        httpGet:
          path: /status/health
          port: 8088
        failureThreshold: 10
        initialDelaySeconds: 60
        periodSeconds: 30
        successThreshold: 1
        timeoutSeconds: 10
      resources:
        limits:
          cpu: "4"
          memory: "8Gi"
        requests:
          cpu: "2"
          memory: "4Gi"
...
```

--------------------------------

### Broker Probes Configuration (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Specifies the liveness, readiness, and startup probes for Druid Broker nodes. It includes specific readiness and startup probe paths ('/druid/broker/v1/readiness') and different failure thresholds compared to other components. These are configurable via the DruidSpec.

```yaml
livenessProbe:
  failureThreshold: 10
  httpGet:
    path: /status/health
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
readinessProbe:
  failureThreshold: 20
  httpGet:
    path: /druid/broker/v1/readiness
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
startupProbe:
  failureThreshold: 20
  httpGet:
    path: /druid/broker/v1/readiness
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
```

--------------------------------

### Historical Probes Configuration (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Defines the liveness, readiness, and startup probes for Druid Historical nodes. It uses '/druid/historical/v1/readiness' for readiness and startup checks with higher failure thresholds and longer initial delays for startup. These settings can be customized in the DruidSpec.

```yaml
livenessProbe:
  failureThreshold: 10
  httpGet:
    path: /status/health
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
readinessProbe:
  failureThreshold: 20
  httpGet:
    path: /druid/historical/v1/readiness
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
startUpProbe:
  failureThreshold: 20
  httpGet:
    path: /druid/historical/v1/readiness
    port: $druid.port
  initialDelaySeconds: 180
  periodSeconds: 30
  successThreshold: 1
  timeoutSeconds: 10
```

--------------------------------

### Add Helm Repository for Druid Operator

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/getting_started.md

Adds the DataInfra Helm chart repository and updates the local Helm repository cache. This is a prerequisite for installing the Druid operator using Helm.

```shell
helm repo add datainfra https://charts.datainfra.io
helm repo update
```

--------------------------------

### Default Probes for Druid Components (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Defines the default liveness, readiness, and startup probes for Coordinator, Overlord, MiddleManager, Router, and Indexer components. These probes check the '/status/health' endpoint with configurable thresholds and timings. They are applied by default but can be overridden.

```yaml
livenessProbe:
  failureThreshold: 10
  httpGet:
    path: /status/health
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
readinessProbe:
  failureThreshold: 10
  httpGet:
    path: /status/health
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
startupProbe:
  failureThreshold: 10
  httpGet:
    path: /status/health
    port: $druid.port
  initialDelaySeconds: 5
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
```

--------------------------------

### Druid Operator Configuration Parameters

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/api_specifications/druid.md

This section details the various configuration parameters available for the Druid Operator, allowing for fine-grained control over Druid cluster deployments.

```APIDOC
## Druid Operator Configuration

This document outlines the configuration parameters for the Druid Operator, covering aspects like PVC management, container settings, security, and volume configurations.

### Parameters

#### Request Body Parameters

- **scalePvcSts** (bool) - Optional - When enabled, operator will allow volume expansion of StatefulSet's PVCs.
- **commonConfigMountPath** (string) - Optional - In-container directory to mount the Druid common configuration.
- **disablePVCDeletionFinalizer** (bool) - Optional - Whether PVCs shall be deleted on the deletion of the Druid cluster.
- **deleteOrphanPvc** (bool) - Optional - Orphaned (unmounted PVCs) shall be cleaned up by the operator.
- **startScript** (string) - Optional - Path to Druid's start script to be run on start.
- **image** (string) - Optional - Required here or at the NodeSpec level.
- **serviceAccount** (string) - Optional - Service account for Druid pods.
- **imagePullSecrets** ([]Kubernetes core/v1.LocalObjectReference) - Optional - Image pull secrets for pulling container images.
- **imagePullPolicy** (Kubernetes core/v1.PullPolicy) - Optional - Image pull policy for container images.
- **env** ([]Kubernetes core/v1.EnvVar) - Optional - Environment variables for druid containers.
- **envFrom** ([]Kubernetes core/v1.EnvFromSource) - Optional - Extra environment variables from remote source (ConfigMaps, Secrets).
- **jvm.options** (string) - Optional - Contents of the shared `jvm.options` configuration file for druid JVM processes.
- **log4j.config** (string) - Optional - Contents of the `log4j.config` configuration file.
- **securityContext** (Kubernetes core/v1.PodSecurityContext) - Optional - Pod security context settings.
- **containerSecurityContext** (Kubernetes core/v1.SecurityContext) - Optional - Container security context settings.
- **volumeClaimTemplates** ([]Kubernetes core/v1.PersistentVolumeClaim) - Optional - Kubernetes Native `VolumeClaimTemplate` specification.
- **volumeMounts** ([]Kubernetes core/v1.VolumeMount) - Optional - Kubernetes Native `VolumeMount` specification.
- **volumes** ([]Kubernetes core/v1.Volume) - Optional - Kubernetes Native `Volumes` specification.
- **podAnnotations** (map[string]string) - Optional - Custom annotations to be populated in `Druid` pods.
- **workloadAnnotations** (map[string]string) - Optional - Annotations to be populated in StatefulSet or Deployment spec. If the same key is specified at both the DruidNodeSpec level and DruidSpec level, the DruidNodeSpec WorkloadAnnotations will take precedence.
- **podManagementPolicy** (Kubernetes apps/v1.PodManagementPolicyType) - Optional - Pod management policy for StatefulSets.

### Request Example

```json
{
  "scalePvcSts": true,
  "commonConfigMountPath": "/druid/conf",
  "disablePVCDeletionFinalizer": false,
  "deleteOrphanPvc": true,
  "startScript": "/opt/druid/bin/start-cluster.sh",
  "image": "apache/druid:latest",
  "serviceAccount": "druid-sa",
  "imagePullPolicy": "IfNotPresent",
  "env": [
    {
      "name": "MY_VAR",
      "value": "my_value"
    }
  ],
  "jvm.options": "-Xmx4g -Xms4g",
  "log4j.config": "# Log4j configuration",
  "podAnnotations": {
    "prometheus.io/scrape": "true"
  },
  "workloadAnnotations": {
    "sidecar.istio.io/inject": "false"
  },
  "podManagementPolicy": "Parallel"
}
```

### Response

#### Success Response (200)

- **status** (string) - Indicates the success of the operation.

#### Response Example

```json
{
  "status": "Configuration applied successfully"
}
```
```

--------------------------------

### Configure Data Compaction in DruidIngestion (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/features.md

Defines compaction settings for a DruidIngestion CRD to optimize data storage and query performance. This configuration specifies the compaction I/O type, tuning parameters, granularity, and task priority.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: DruidIngestion
metadata:
  name: example-druid-ingestion
spec:
  ingestion:
    type: native-batch
    compaction:
      ioConfig:
        type: "index_parallel"
        inputSpec:
          type: "dataSource"
          dataSource: "my-data-source"
      tuningConfig:
        maxNumConcurrentSubTasks: 4
      granularitySpec:
        segmentGranularity: "day"
        queryGranularity: "none"
        rollup: false
      taskPriority: "high"
      taskContext: '{"priority": 75}'

```

--------------------------------

### Generate Druid Operator API Documentation

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/dev_doc.md

Command to update the API documentation for the Druid Operator. This should be run whenever changes are made to the CRD API.

```shell
make api-docs
```

--------------------------------

### Delete Deployment (Shell)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Deletes a specified deployment from a Kubernetes namespace. This command is used to remove the original deployment before applying the updated version.

```shell
kubectl delete deployment -n druid-operator druid-operator
```

--------------------------------

### Druid Operator Configuration

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/api_specifications/druid.md

This section details the configuration parameters available for the Druid Operator, which allow for fine-grained control over Druid deployments.

```APIDOC
## Druid Operator Configuration

### Description
Configuration options for managing Druid deployments via the Druid Operator.

### Method
N/A (Configuration Schema)

### Endpoint
N/A (Configuration Schema)

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body
- **podLabels** (map[string]string) - Optional - Custom labels to be populated in `Druid` pods.
- **priorityClassName** (string) - Optional - Kubernetes native `priorityClassName` specification.
- **updateStrategy** (Kubernetes apps/v1.StatefulSetUpdateStrategy) - Optional - Defines the update strategy for StatefulSets.
- **livenessProbe** (Kubernetes core/v1.Probe) - Optional - Liveness probe configuration. Port is set to `druid.port` if not specified with httpGet handler.
- **readinessProbe** (Kubernetes core/v1.Probe) - Optional - Readiness probe configuration. Port is set to `druid.port` if not specified with httpGet handler.
- **startUpProbe** (Kubernetes core/v1.Probe) - Optional - Startup probe configuration.
- **services** ([]Kubernetes core/v1.Service) - Optional - Kubernetes services to be created for each workload.
- **nodeSelector** (map[string]string) - Optional - Kubernetes native `nodeSelector` specification.
- **tolerations** ([]Kubernetes core/v1.Toleration) - Optional - Kubernetes native `tolerations` specification.
- **affinity** (Kubernetes core/v1.Affinity) - Optional - Kubernetes native `affinity` specification.
- **nodes** (map[string]./apis/druid/v1alpha1.DruidNodeSpec) - A list of `Druid` Node types and their configurations. `DruidSpec` is used to create Kubernetes workload specs. Many of the fields above can be overridden at the specific `NodeSpec` level.
- **additionalContainer** ([]AdditionalContainer) - Optional - Defines additional sidecar containers to be deployed with the `Druid` pods.
- **rollingDeploy** (bool) - Optional - Whether to deploy the components in a rolling update. If set to true, the operator checks the rollout status of previous version workloads before updating the next. This will be done only for update actions.
- **defaultProbes** (bool) - Optional - If set to true, this will add default probes (liveness / readiness / startup) for all druid components but it won’t override existing probes.
- **zookeeper** (ZookeeperSpec) - Optional - IGNORED (Future API): In order to make Druid dependency setup extensible from within Druid operator.
- **metadataStore** (MetadataStoreSpec) - Optional - IGNORED (Future API): In order to make Druid dependency setup extensible from within Druid operator.
- **deepStorage** (DeepStorageSpec) - Optional - IGNORED (Future API): In order to make Druid dependency setup extensible from within Druid operator.

### Request Example
```json
{
  "podLabels": {
    "environment": "production"
  },
  "updateStrategy": {
    "type": "RollingUpdate"
  },
  "nodes": {
    "master": {
      "replicas": 3
    }
  },
  "rollingDeploy": true
}
```

### Response
#### Success Response (200)
N/A (Configuration Schema)

#### Response Example
N/A (Configuration Schema)
```

--------------------------------

### Delete Namespace (Shell)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Deletes a specified Kubernetes namespace. This is used in the migration process to remove the old operator's namespace after the new one is deployed.

```shell
kubectl delete ns druid-operator
```

--------------------------------

### Add Sidecar Containers to Druid Pods

Source: https://context7.com/justtrackio/druid-operator/llms.txt

Demonstrates how to add both cluster-level and node-level sidecar containers, as well as init containers, to Druid pods. This allows for extending Druid functionality with custom agents or pre-processing steps. It requires defining the container image, command, and optionally volume mounts for init containers.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: Druid
metadata:
  name: druid-with-sidecars
spec:
  image: apache/druid:25.0.0
  # Cluster-level sidecar (applies to all nodes)
  additionalContainer:
    - command:
        - /bin/sh
        - -c
        - echo "Cluster-level sidecar"
      containerName: cluster-sidecar
      image: busybox:latest
  # Init container for Hadoop dependencies
  volumeMounts:
    - mountPath: /opt/druid/hadoop-dependencies
      name: hadoop-dependencies
  volumes:
    - emptyDir:
        sizeLimit: 500Mi
      name: hadoop-dependencies
  additionalContainer:
    - command:
        - java
        - -cp
        - lib/*
        - -Ddruid.extensions.hadoopDependenciesDir=/hadoop-dependencies
        - org.apache.druid.cli.Main
        - tools
        - pull-deps
        - -h
        - org.apache.hadoop:hadoop-client:3.3.0
        - --no-default-hadoop
      containerName: hadoop-dependencies
      image: apache/druid:25.0.0
      runAsInit: true
      volumeMounts:
        - mountPath: /hadoop-dependencies
          name: hadoop-dependencies
  nodes:
    brokers:
      nodeType: "broker"
      # Node-level sidecar (applies only to brokers)
      additionalContainer:
        - command:
            - /bin/sh
            - -c
            - echo "Node-level sidecar"
          containerName: node-sidecar
          image: busybox:latest

```

--------------------------------

### Debugging Druid Clusters with kubectl (Bash)

Source: https://context7.com/justtrackio/druid-operator/llms.txt

Common kubectl commands for monitoring and debugging Druid clusters managed by the operator. These commands help check operator status, logs, and deployed resources.

```bash
# Get operator pod name
kubectl get po -n druid-operator-system | grep druid-operator

# Check operator logs
kubectl logs -n druid-operator-system <druid-operator-pod-name>

# Describe Druid CR status
kubectl describe druids tiny-cluster

# Check deployed resources
kubectl get svc | grep tiny
kubectl get cm | grep tiny
kubectl get sts | grep tiny
kubectl get pvc | grep tiny

# Check DruidIngestion status
kubectl get druidingestion
kubectl describe druidingestion kafka-metrics

# Watch cluster pods
kubectl get pods -l druid_cr=tiny-cluster -w
```

--------------------------------

### Rules and Compaction Configuration (YAML)

Source: https://context7.com/justtrackio/druid-operator/llms.txt

Configure data retention rules (e.g., loadForever, dropByPeriod) and automatic compaction for Druid data sources using YAML. This ensures efficient data management and storage.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: DruidIngestion
metadata:
  name: ingestion-with-rules
spec:
  druidCluster: tiny-cluster
  ingestion:
    type: native-batch
    rules:
      - type: "loadForever"
        tieredReplicants:
          _default_tier: 2
      - type: "dropByPeriod"
        period: "P7D"
    compaction:
      ioConfig:
        type: "index_parallel"
        inputSpec:
          type: "dataSource"
          dataSource: "my-data-source"
      tuningConfig:
        maxNumConcurrentSubTasks: 4
      granularitySpec:
        segmentGranularity: "day"
        queryGranularity: "none"
        rollup: false
      taskPriority: "high"
      taskContext: '{"priority": 75}'
    spec: |- 
      { ... ingestion spec ... }
```

--------------------------------

### Druid CRD with Basic Authentication Configuration (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/druid_cr.md

Example of a Druid Custom Resource (CR) definition specifying basic authentication. It references a Kubernetes secret containing the credentials and sets the authentication type to 'basic-auth'.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: Druid
metadata:
  name: agent
spec:
  auth:
    secretRef:
      name: mycluster-admin-operator
      namespace: druid
    type: basic-auth

```

--------------------------------

### Kubernetes Secret for Basic Authentication (YAML)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/druid_cr.md

Example YAML definition for a Kubernetes Secret of type Opaque, used to store credentials for basic authentication. It includes fields for username and password, which must be base64 encoded.

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: mycluster-admin-operator
  namespace: druid
type: Opaque
data:
  OperatorUserName: <base64-encoded-username>
  OperatorPassword: <base64-encoded-password>

```

--------------------------------

### Apply Modified Deployment YAML (Shell)

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/kubebuilder_v3_migration.md

Applies a modified deployment YAML file to the Kubernetes cluster. This command is used after making manual edits to the deployment configuration, such as adding labels or changing names.

```shell
kubectl apply -f druid-deployment-temp
```

--------------------------------

### Native Spec Ingestion Configuration (YAML)

Source: https://context7.com/justtrackio/druid-operator/llms.txt

Configure Kafka ingestion using the Kubernetes-native YAML format for the ingestion specification. This defines data sources, schemas, and ingestion parameters.

```yaml
apiVersion: druid.apache.org/v1alpha1
kind: DruidIngestion
metadata:
  name: kafka-native-spec
spec:
  suspend: false
  druidCluster: example-cluster
  ingestion:
    type: kafka
    nativeSpec:
      type: kafka
      spec:
        dataSchema:
          dataSource: metrics-kafka-native
          timestampSpec:
            column: timestamp
            format: auto
          dimensionsSpec:
            dimensions: []
            dimensionExclusions:
              - timestamp
              - value
          metricsSpec:
            - name: count
              type: count
            - name: value_sum
              fieldName: value
              type: doubleSum
          granularitySpec:
            type: uniform
            segmentGranularity: HOUR
            queryGranularity: NONE
        ioConfig:
          topic: metrics
          inputFormat:
            type: json
          consumerProperties:
            bootstrap.servers: localhost:9092
          taskCount: 1
          replicas: 1
          taskDuration: PT1H
        tuningConfig:
          type: kafka
          maxRowsPerSegment: 5000000
```

--------------------------------

### Deploy Basic Druid Cluster with Druid CRD

Source: https://context7.com/justtrackio/druid-operator/llms.txt

This YAML configuration defines a basic Druid cluster deployment using the Druid Custom Resource Definition (CRD). It specifies the image, startup script, pod labels, security context, service settings, common configuration paths, JVM options, log4j configuration, runtime properties for Zookeeper, metadata storage, deep storage, extensions, and service discovery. It also includes volume mounts for data and deep storage, and detailed configurations for broker, coordinator, historical, and router nodes, including their respective runtime properties and JVM options.

```yaml
apiVersion: "druid.apache.org/v1alpha1"
kind: "Druid"
metadata:
  name: tiny-cluster
spec:
  image: apache/druid:25.0.0
  startScript: /druid.sh
  podLabels:
    environment: stage
    release: alpha
  securityContext:
    fsGroup: 1000
    runAsUser: 1000
    runAsGroup: 1000
  services:
    - spec:
        type: ClusterIP
        clusterIP: None
  commonConfigMountPath: "/opt/druid/conf/druid/cluster/_common"
  jvm.options: |-
    -server
    -XX:MaxDirectMemorySize=10240g
    -Duser.timezone=UTC
    -Dfile.encoding=UTF-8
    -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
  log4j.config: |-
    <?xml version="1.0" encoding="UTF-8" ?>
    <Configuration status="WARN">
        <Appenders>
            <Console name="Console" target="SYSTEM_OUT">
                <PatternLayout pattern="%d{ISO8601} %p [%t] %c - %m%n"/>
            </Console>
        </Appenders>
        <Loggers>
            <Root level="info">
                <AppenderRef ref="Console"/>
            </Root>
        </Loggers>
    </Configuration>
  common.runtime.properties: |
    # Zookeeper
    druid.zk.service.host=tiny-cluster-zk-0.tiny-cluster-zk
    druid.zk.paths.base=/druid
    # Metadata Store
    druid.metadata.storage.type=derby
    druid.metadata.storage.connector.createTables=true
    # Deep Storage
    druid.storage.type=local
    druid.storage.storageDirectory=/druid/deepstorage
    # Extensions
    druid.extensions.loadList=["druid-kafka-indexing-service"]
    # Service discovery
    druid.selectors.indexing.serviceName=druid/overlord
    druid.selectors.coordinator.serviceName=druid/coordinator
  volumeMounts:
    - mountPath: /druid/data
      name: data-volume
    - mountPath: /druid/deepstorage
      name: deepstorage-volume
  volumes:
    - name: data-volume
      emptyDir: {}
    - name: deepstorage-volume
      hostPath:
        path: /tmp/druid/deepstorage
        type: DirectoryOrCreate
  nodes:
    brokers:
      nodeType: "broker"
      druid.port: 8088
      nodeConfigMountPath: "/opt/druid/conf/druid/cluster/query/broker"
      replicas: 1
      runtime.properties: |
        druid.service=druid/broker
        druid.broker.http.numConnections=5
        druid.server.http.numThreads=10
        druid.processing.buffer.sizeBytes=1
        druid.sql.enable=true
      extra.jvm.options: |-
        -Xmx512M
        -Xms512M
    coordinators:
      nodeType: "coordinator"
      druid.port: 8088
      nodeConfigMountPath: "/opt/druid/conf/druid/cluster/master/coordinator-overlord"
      replicas: 1
      runtime.properties: |
        druid.service=druid/coordinator
        druid.coordinator.startDelay=PT30S
        druid.coordinator.period=PT30S
        druid.coordinator.asOverlord.enabled=true
        druid.coordinator.asOverlord.overlordService=druid/overlord
      extra.jvm.options: |-
        -Xmx512M
        -Xms512M
    historicals:
      nodeType: "historical"
      druid.port: 8088
      nodeConfigMountPath: "/opt/druid/conf/druid/cluster/data/historical"
      replicas: 1
      runtime.properties: |
        druid.service=druid/historical
        druid.server.http.numThreads=5
        druid.processing.buffer.sizeBytes=536870912
        druid.segmentCache.locations=[{"path":"/druid/data/segments","maxSize":10737418240}]
        druid.server.maxSize=10737418240
      extra.jvm.options: |-
        -Xmx512M
        -Xms512M
    routers:
      nodeType: "router"
      druid.port: 8088
      nodeConfigMountPath: "/opt/druid/conf/druid/cluster/query/router"
      replicas: 1
      runtime.properties: |
        druid.service=druid/router
        druid.router.http.numConnections=10
        druid.router.http.readTimeout=PT5M
        druid.router.defaultBrokerServiceName=druid/broker
        druid.router.coordinatorServiceName=druid/coordinator
        druid.router.managementProxy.enabled=true
      extra.jvm.options: |-
        -Xmx512M
        -Xms512M

```

--------------------------------

### Uninstall Druid Operator using Helm

Source: https://github.com/justtrackio/druid-operator/blob/master/docs/getting_started.md

Uninstalls the Druid operator using Helm. It includes a crucial step to remove the CRD annotation to ensure complete cleanup, as Helm by default does not uninstall CRDs to prevent data loss.

```bash
# To avoid destroying existing clusters, helm will not uninstall its CRD. For 
# complete cleanup annotation needs to be removed first:
kubectl annotate crd druids.druid.apache.org helm.sh/resource-policy-

# This will uninstall operator
helm -n druid-operator-system  uninstall cluster-druid-operator
```