Customizing your Deepfactor Portal Deployment in K8s – DeepFactor

We understand that different enterprises have different policies for Kubernetes clusters and hence we provide a rich set of customizations for our Deepfactor K8s portal installation. You can specify an override.yaml file while deploying our helm charts in your cluster. We provide some common customization scenarios below

Storage Class
The default value for the storage class is set to empty which means Kubernetes will use the default Storage Class of the cluster to provision the volumes. You can use a different storage class by setting the storageClassName value in override.yaml as shown below.
```
storage:
  storageClassName: <storage-class-name>
```
Volume size
We create 4 volumes for our StatefulSets and the default values for them are as follows:
1. Postgres - 100Gi
2. Clickhouse - 300Gi
3. ArchiveStore - 100Gi
4. SymbolService - 5Gi
  
  You can change the volume sizes by setting the following values in override.yaml
```
postgres:
  storage:
    requests: <volume-size-for-postgres>

clickhouse:
  storage:
    requests: <volume-size-for-clickhouse>

archivestore:
  storage:
    requests: <volume-size-for-archivestore>

symbolsvc:
  storage:
    requests: <volume-size-for-symbolsvc>
```
  If you want to update the size of a particular volume, then just add the section related to the volume. For example, if you want update the volume size of Postgres to 10Gi, you can set the following values in override.yaml.
```
postgres:
  storage:
    requests: 10Gi
```

Image registry, image, tag and pull policy
If you intend to pull Deepfactor container images from your private repository, then you can update the image registry, name and tag for each service in override.yaml as shown below.

# Make sure that registry name end with a '/'.
# For example : quay.io/ is a correct value here and quay.io is incorrect

deepfactorImageRegistry: <registry_name_with_a_slash_at_end>

apisvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

alertsvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

authsvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

cvesvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

depchecksvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>
  
eventsvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

notificationsvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

proxysvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

symbolsvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

statussvc:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

nginx:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

dfwebscan:
  webScanDriverImageName: "<image_name_with_repository>:<image_tag>"
  webScanInitImageName: "<image_name_with_repository>:<image_tag>"
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

archivestore:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

clickhouse:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

postgres:
  image:
    tag: <image_tag>
    repository: <image_name_with_repository>
    pullPolicy: <image_pull_policy>

Disabling ingress deployment
If you already have an ingress controller that you would like to use to expose Deepfactor service, then you can disable ingress deployment by providing the following values in override.yaml.
```
ingress-nginx: 
  enablemodule: false 
nginx: 
  ingress: 
    className: <ingress class name> # nginx
```
Changing ingress from deployment to daemonSet
```
ingress-nginx:
  controller:
    kind: DaemonSet
```
To configure ingress with external IP refer to - https://docs.deepfactor.io/hc/en-us/articles/4669229905427-Deploying-Deepfactor-Portal-using-external-IP
nodeSelector for pods

If you would like to schedule Deepfactor pods on specific nodes, you can set the nodeSelector parameter for each Deepfactor deployment. An example is shown below

apisvc:
  nodeSelector:
    disktype: ssd

For each of the Deepfactor microservices, you can override quite a few parameters. The default values for one of the deployments are shown below for your reference.

apisvc:
  replicas: 1
  name: apisvc
  initContainer:
    name: init-dfapisvc
    image:
      registry: ""
      repository: public.ecr.aws/deepfactor/alpine
      pullPolicy: IfNotPresent
      tag: 3.13
  image:
    repository: df/apisvc
    pullPolicy: IfNotPresent
    # Overrides the image tag whose default is the chart appVersion.
    tag: 2.0-966
  service:
    annotations: {}
    labels: {}
    clusterIP: ""
    enableMetrics: true
    externalIPs: []
    loadBalancerIP: ""
    loadBalancerSourceRanges: []
    servicePort: 8081
    grpcPort: 8082
    sessionAffinity: None
    type: ClusterIP
  ingress:
    annotations:
      kubernetes.io/ingress.class: nginx
      nginx.ingress.kubernetes.io/backend-protocol: GRPC
      nginx.ingress.kubernetes.io/client-body-buffer-size: 1M
    extraLabels: {}
  annotations: {}
  podAnnotations: {}
  podLabels: {}
  nodeSelector: {}
  tolerations: []
  resources: {}
  securityContext: {}

Articles in this section

Customizing your Deepfactor Portal Deployment in K8s Follow

Comments

Articles in this section

Related articles