Helm chart refactoring

[trial-danswer]

Description

[Provide a brief description of the changes in this PR]

How Has This Been Tested?

I used eksctl cli to provision a eks cluster in aws. The following is the config.yaml that I used to provision the cluster.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: onyx-cluster
region: us-west-1

nodeGroups:

• name: ng-1
  instanceType: m5.large
  desiredCapacity: 1
  maxSize: 2
  minSize: 1
  volumeSize: 80
  ssh:
  allow: true # will use ~/.ssh/id_rsa.pub as the default ssh key
• name: ng-2
  instanceType: m5.xlarge
  desiredCapacity: 1
  maxSize: 2
  minSize: 1
  volumeSize: 100
  ssh:
  publicKeyPath: ~/.ssh/id_rsa.pub
  iam:
  withAddonPolicies:
  imageBuilder: true
  autoScaler: true
  externalDNS: true
  certManager: true
  appMesh: true
  appMeshPreview: true
  ebs: true
  fsx: true
  efs: true
  awsLoadBalancerController: true
  xRay: true
  cloudWatch: true

addonsConfig:
autoApplyPodIdentityAssociations: true

addons:

• name: aws-ebs-csi-driver
  version: latest
  useDefaultPodIdentityAssociations: true
• name: eks-pod-identity-agent
  version: latest
  useDefaultPodIdentityAssociations: true

iam:
podIdentityAssociations:

• namespace: default
  serviceAccountName: default
  permissionPolicyARNs:
  • "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy"
    permissionPolicy:
    Version: "2012-10-17"
    Statement:
  • Effect: Allow
    Action:
    • "autoscaling:DescribeAutoScalingGroups"
    • "autoscaling:DescribeAutoScalingInstances"
    • "autoscaling:DescribeLaunchConfigurations"
    • "autoscaling:DescribeTags"
    • "autoscaling:SetDesiredCapacity"
    • "autoscaling:TerminateInstanceInAutoScalingGroup"
    • "ec2:DescribeLaunchTemplateVersions"
      Resource: '*'

The following are the commands used to provision a cluster, pull in latest sub-charts, and install onyx onto the new EKS cluster.

eksctl create cluster -f config.yaml # creates the 2 node eks cluster

helm upgrade dependency # upgrades the sub-charts

helm install onyx . # installs the onyx apps onto the cluster

[Describe the tests you ran to verify your changes]

Backporting (check the box to trigger backport action)

Note: You have to check that the action passes, otherwise resolve the conflicts manually and tag the patches.

• This PR should be backported (make sure to check that the backport attempt succeeds)
• [Optional] Override Linear Check

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
internal-search	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 27, 2025 10:52pm

[trial-danswer]

The appVersion maps to the onyx version for the apps. A user can set this value to deploy and pin the specific version of onyx.

[Weves]

nit: any reason we removed this comment?

[Weves]

what does this one do? It doesn't seem clear from this comment

[Weves]

also, is the below the right way to do secrets in helm?

[trial-danswer]

Helm does not have built-in secret management capabilities. However, there are several approaches to managing secrets in Helm deployments:

1️⃣ External Secrets Operator (ESO) – ESO allows Kubernetes to sync secrets from external providers (e.g., AWS Secrets Manager, HashiCorp Vault) by creating a SecretStore. Applications can then access these secrets based on namespace permissions and role-based access control (RBAC). More details: External Secrets Operator - AWS Secrets Manager

2️⃣ Helm Secrets Plugin – The helm-secrets plugin enables Helm to decrypt secrets on the fly when deploying charts. It supports encrypted values stored in Git (via SOPS) or dynamic retrieval from providers like AWS Secrets Manager using Vals.

3️⃣ GitOps-Based Secret Management (ArgoCD, Flux, etc.) – Tools like ArgoCD provide flexible secret management options, integrating with both helm-secrets and external-secrets, among others, to securely sync secrets in Kubernetes clusters.

Each approach has its own advantages, depending on security requirements and deployment workflows.