Additional Volumes¶

In certain situations, you may need to attach additional volumes or a ConfigMap that contains extra application configurations. To do this, add the following snippet to your values.yaml file:

global:
  extraVolumeMounts:
    - name: truststore-volume
      mountPath: /datarobot/bootstrap/admin/secure/truststore/truststore.jks
      subPath: truststore.jks
      readOnly: true
  extraVolumes:
    - name: truststore-volume
      configMap:
        name: truststore

This example will mount /datarobot/bootstrap/admin/secure/truststore/truststore.jks to all datarobot pods.

NOTE: dr-jobs and build-service pods will not mount this file.

Additional Labels and Annotations¶

For FinOps and SecOps, it is possible to add labels or annotations to the Datarobot Kubernetes deployment using this additional configuration in your datarobot-values.yaml.

Example to add labels:

global:
  extraLabels:
    customlabel=customglobalvalue

core:
  config_env_vars:
    KUBEWORKERS_OPTIONAL_JOB_LABELS_LIST: 'dynamicworkerlabel=customlabel'

Example to add annotations:

global:
  annotations:
    customannotation=customglobalvalue

core:
  config_env_vars:
    KUBEWORKERS_OPTIONAL_JOBS_ANNOTATIONS_LIST: 'dynamicworkerlabel=customannotation'

Additional Kubernetes Objects¶

There may be instances where you need to deploy additional Kubernetes objects. To facilitate this, the datarobot-app-chart allows you to include examples as demonstrated below:

extraObjects:
- |
  apiVersion: v1
  kind: Secret
  metadata:
    name: extra-secret
  type: Opaque
  stringData:
    extra-secret-key: extra-secret-data

NOTE: The new object will be included in the datarobot Helm release and will adhere to the same lifecycle.

Configure ImagePullPolicy¶

DataRobot supports the ability to set the image pull policy for all workloads. By default, this is configured to "IfNotPresent" to minimize network traffic.

However, this can be configured using the following configuration:

global:
  imagePullPolicy: Always

Security Context configuration¶

概要¶

DataRobot has already provided a secure configuration based on Kubernetes best practices. Customers may occasionally need to inject a custom security context into their Kubernetes manifests to align with their internal security policies or to comply with Kyverno or Gatekeeper. This can be achieved using the following parameters:

Configure PCS¶

mongodb:
  containerSecurityContext:
    runAsNonRoot: true
redis:
  replica:
    containerSecurityContext:
      runAsNonRoot: true
  sentinel:
    containerSecurityContext:
      runAsNonRoot: true
postgresql-ha:
  postgresql:
    containerSecurityContext:
      runAsNonRoot: true
  pgpool:
    containerSecurityContext:
      runAsNonRoot: true
rabbitmq:
  containerSecurityContext:
    runAsNonRoot: true

NOTE: For additional information, please refer to the bitnami documentation

Configure Datarobot Application¶

public-api:
  containerSecurityContext:
    runAsNonRoot: true
    seLinuxOptions:
      level: "s0:c123,c456"

NOTE: These parameters must be injected for each component

For additional information, please refer to the Kubernetes Documentation.

Running Datarobot Application on a Dedicated Node Group¶

要件¶

The Kubernetes administrator must configure the taint in a group of nodes using the label dedicated=DatarobotNodeGroup, for example.

NOTE: For additional information, please refer to the Kubernetes Documentation.

Configure PCS¶

Datarobot PCS uses bitnami charts. According to the documentation, this additional configuration must be added to your pcs-values.yaml.

mongodb:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "DatarobotNodeGroup"
      effect: "NoSchedule"
  nodeSelector:
    dedicated: "DatarobotNodeGroup"
postgresql-ha:
  postgresql:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "DatarobotNodeGroup"
        effect: "NoSchedule"
    nodeSelector:
      dedicated: "DatarobotNodeGroup"
  pgpool:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "DatarobotNodeGroup"
        effect: "NoSchedule"
    nodeSelector:
      dedicated: "DatarobotNodeGroup"
redis:
  replica:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "DatarobotNodeGroup"
        effect: "NoSchedule"
    nodeSelector:
      dedicated: "DatarobotNodeGroup"
rabbitmq:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "DatarobotNodeGroup"
      effect: "NoSchedule"
  nodeSelector:
    dedicated: "DatarobotNodeGroup"
elasticsearch:
  master:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "DatarobotNodeGroup"
        effect: "NoSchedule"
    nodeSelector:
      dedicated: "DatarobotNodeGroup"

Configure Datarobot Application¶

To configure the Datarobot Application, the following config must be added to your values.yaml.

global:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "DatarobotNodeGroup"
      effect: "NoSchedule"
  nodeSelector:
    dedicated: "DatarobotNodeGroup"

core:
  config_env_vars:
    #Node Group Selection for Dynamic-workers
    KUBEWORKERS_OPTIONAL_INSTANCE_TOLERATION: "dedicated=DatarobotNodeGroup"
    # Use either KUBEWORKERS_OPTIONAL_INSTANCE_SELECTORS_LIST (for node affinity) 
    # or KUBEWORKERS_REQUIRED_NODE_SELECTORS_LIST (for node selector)
    KUBEWORKERS_OPTIONAL_INSTANCE_SELECTORS_LIST: dedicated=DatarobotNodeGroup
    # Alternative: Use KUBEWORKERS_REQUIRED_NODE_SELECTORS_LIST for strict node selector
    # KUBEWORKERS_REQUIRED_NODE_SELECTORS_LIST: dedicated=DatarobotNodeGroup

Image Pull Secret¶

The image pull secret is a vital configuration that enables all pods to securely retrieve images from the image registry. DataRobot supports two methods for setting this up:

Using Helm
Manually creating a secret

Using Helm¶

Helm will automatically create the appropriate image pull secret using the following configuration:

global:
  imageCredentials:
    createSecret: "True"
    registry: "[YOUR REGISTRY FQDN]"
    username: "[YOUR REGISTRY USERNAME]"
    password: "[YOUR REGISTRY PASSWORD]"

Manually creating a secret¶

You can create the image pull secret using kubectl with the following command:

kubectl create secret docker-registry datarobot-image-pull-secret -n $NS \
  --docker-server="[YOUR REGISTRY FQDN]"  \
  --docker-username="[YOUR REGISTRY USERNAME]" \
  --docker-password="[YOUR REGISTRY PASSWORD]"

You can configure the Helm chart accordingly to utilize the image pull secret by specifying it in the values file

global:
  imageCredentials:
    name: datarobot-image-pull-secret

Multiple Registry¶

You can set up multiple image pull secret policies using the following syntax:

global:
  imageCredentials:
    createSecret: "True"
    registry: docker.io 
    username: "[YOUR DOCKERHUB USERNAME]"
    password: "[YOUR DOCKERHUB PASSWORD]"
    extraAuths:
    - registry: "private-registry.example.com"
      username: "[YOUR REGISTRY USERNAME]"
      password: "[YOUR REGISTRY PASSWORD]"