feat: get helm config from a well known configmap

[faiq]

This deploys a helm chart with our helm addon configuration for CAREN's configuration. Other components are not expected to interact with this on a per cluster basis. This also allows the user some flexibility/insight into what addons are deployed.

The config map contains information such as version, chart name, and repository url.

The next step would be adding a field under clusterConfig.addons called helmRegistry which would be used in conjunction with this configmap to support pulling helmCharts from private registries.

See this example below for examples of the configmap and it being used to generate helmchartproxy.

$ kubectl get cm default-helm-addons-config -o yaml
apiVersion: v1
data:
  aws-ccm-config: |
    defaultChartName: aws-cloud-controller-manager
    defaultChartVersion: ""
    defaultRepositoryUrl: https://kubernetes.github.io/cloud-provider-aws
  aws-ebs-csi-config: |
    defaultChartName: aws-ebs-csi-driver
    defaultChartVersion: v2.28.1
    defaultRepositoryUrl: https://kubernetes-sigs.github.io/aws-ebs-csi-driver
  cilium-config: |
    defaultChartName: cilium
    defaultChartVersion: 1.15.0
    defaultRepositoryUrl: https://helm.cilium.io/
  cluster-autoscaler-config: |
    defaultChartName: cluster-autoscaler
    defaultChartVersion: 9.35.0
    defaultRepositoryUrl: https://kubernetes.github.io/autoscaler
  nfd-config: |
    defaultChartName: node-feature-discovery
    defaultChartVersion: 0.15.2
    defaultRepositoryUrl: https://kubernetes-sigs.github.io/node-feature-discovery/charts
  nutanix-csi-config: |
    defaultChartName: nutanix-csi-storage
    defaultChartVersion: v2.6.6
    defaultRepositoryUrl: https://nutanix.github.io/helm/
  tigera-operator-config: |
    defaultChartName: tigera-operator
    defaultChartVersion: v3.26.4
    defaultRepositoryUrl: https://docs.tigera.io/calico/charts
kind: ConfigMap
metadata:
  annotations:
    meta.helm.sh/release-name: cluster-api-runtime-extensions-nutanix
    meta.helm.sh/release-namespace: default
  creationTimestamp: "2024-04-04T16:01:07Z"
  labels:
    app.kubernetes.io/managed-by: Helm
  name: default-helm-addons-config
  namespace: default
  resourceVersion: "3895"
  uid: f5726498-2a3b-4f5f-81df-0a55b7bd349d

here is an example of a generate helm chart proxy

- apiVersion: addons.cluster.x-k8s.io/v1alpha1
  kind: HelmChartProxy
  metadata:
    creationTimestamp: "2024-04-04T17:24:49Z"
    finalizers:
    - helmchartproxy.addons.cluster.x-k8s.io
    generation: 1
    name: node-feature-discovery-faiq-settings-from-cm-3
    namespace: default
    ownerReferences:
    - apiVersion: cluster.x-k8s.io/v1beta1
      kind: Cluster
      name: faiq-settings-from-cm-3
      uid: 94d04222-84ca-41e0-ba19-5e2696ec1206
    resourceVersion: "28667"
    uid: 054e16d1-3c23-4a5c-8a39-3e408b7d6c4d
  spec:
    chartName: node-feature-discovery
    clusterSelector:
      matchLabels:
        cluster.x-k8s.io/cluster-name: faiq-settings-from-cm-3
    namespace: node-feature-discovery
    options:
      enableClientCache: false
      install:
        createNamespace: true
      timeout: 10m0s
      upgrade:
        maxHistory: 10
    releaseName: node-feature-discovery
    repoURL: https://kubernetes-sigs.github.io/node-feature-discovery/charts
    valuesTemplate: |
      master:
        extraLabelNs:
          - nvidia.com
          - beta.amd.com
          - amd.com

      worker: ### <NFD-WORKER-CONF-START-DO-NOT-REMOVE>
        config:
          sources:
            pci:
              deviceLabelFields:
                - "class"
                - "vendor"
        tolerations:
          - effect: NoSchedule
            key: node-role.kubernetes.io/master
          - effect: NoSchedule
            key: node-role.kubernetes.io/control-plane
      ### <NFD-WORKER-CONF-END-DO-NOT-REMOVE>
      image:
        tag: v0.15.2-minimal
    version: 0.15.2

[supershal]

Is there any consideration about how many versions (X-??) of an add-on helm chart CAREN should be supporting between creating cluster and upgrading it to next version?

[faiq]

Is there any consideration about how many versions (X-??) of an add-on helm chart CAREN should be supporting between creating cluster and upgrading it to next version?

No and there was none previously either. Each DKP release will have set addons that we support

[dkoshkin]

Great changes, just had a question on aws-ccm

[supershal]

a dev doc or readme about how a developer can change add-on helm configuration would be nice.

[faiq]

I added the warning. As far dev docs go, we don't really have a structure for using them and I don't really think its needed at this point either

[supershal]

Thanks for the improvement.