argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.45k stars 5.3k forks source link

Helm "app.kubernetes.io/instance" label is not equal helm {{ .Release.Name }} #2871

Closed vukor closed 7 months ago

vukor commented 4 years ago

Describe the bug

After argo "cert-manager-elasticsearch" application was deployed the "app.kubernetes.io/instance" label in service/serviceMonitor resources is equals "cert-manager-elasticsearch" not source.helm.releaseName

To Reproduce

--- file requirements.yaml --- dependencies:

--- file values.yaml --- cert-manager:

rbac: create: true

webhook: enabled: false

cainjector: enabled: false

extraArgs:

Expected behavior

After deploying app I got next resources:

$ k get service cert-manager -o yaml
apiVersion: v1
kind: Service
metadata:
...
  labels:
    ..
    app.kubernetes.io/instance: cert-manager-elasticsearch # <--- should be "cert-manager"?
    ...
  name: cert-manager
...

$ k get servicemonitor cert-manager -o yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
...
  labels:
    ...
    app.kubernetes.io/instance: cert-manager-elasticsearch # <--- should be "cert-manager"?
    ...
  name: cert-manager
  ..
spec:
  endpoints:
  - interval: 60s
    path: /metrics
    scrapeTimeout: 30s
    targetPort: 9402
  jobLabel: cert-manager
  namespaceSelector:
    matchNames:
    - cert-manager
  selector:
    matchLabels:
      app.kubernetes.io/instance: cert-manager # <--- should be same as in service resource
      app.kubernetes.io/name: cert-manager

As you see the serviceMonitor resource have different "app.kubernetes.io/instance: cert-manager" string in spec.selector.matchLabels and Prometheus can't detect cert-manager's metrics. I believe, same issue affected not only in cert-manager chart.

Version

v1.3.1
vukor commented 4 years ago

Same for kube2iam chart

drekle commented 4 years ago

This is a bug affecting our prometheus-operator deployments.

jannfis commented 4 years ago

If I understood correctly, your Helm app wants to set the app.kubernetes.io/instance label and later use it for resource selectors. ArgoCD uses app.kubernetes.io/instance by default to indicate which ArgoCD application a resource that was deployed by it belongs to, i.e. indicates managed state.

You can change the name of the label from the default app.kubernetes.io/instance by setting the application.instanceLabelKey in argocd-cm to the name of a new label to use for it (refer https://argoproj.github.io/argo-cd/operator-manual/argocd-cm.yaml for more details). This will affect all managed applications and might trigger a re-sync of all of your applications, with unintended side-effects, so I'd suggest to test this change in a staging environment before. Maybe the less intrusive way would be a way to modify the name of the label your Helm app uses.

drekle commented 4 years ago

I was able to workaround this is issue by enforcing that either the releaseName and appName are the same.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-name
spec:
  source:
    helm:
      releaseName: my-app-name

From my reading this would work the same if releaseName was unspecified.

jgwest commented 7 months ago

Jann's comment is the correct solution, here.