chore: helm - add servicemonitor api condition

[splichy]

Fixes #N/A

Description
Add servicemonitor condition check if monitoring.coreos.com/v1 is available
This will prevent failure when Prometheus CRDs are not installed yet, e.g. during initial cluster installation, where we usually want to install Karpenter before other services

How was this change tested?

$ helm template karpenter . --namespace karpenter --set serviceMonitor.enabled=true -s templates/servicemonitor.yaml --api-versions monitoring.coreos.com/v1
---
# Source: karpenter/templates/servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: karpenter
  namespace: karpenter
  labels:
    helm.sh/chart: karpenter-1.2.1
    app.kubernetes.io/name: karpenter
    app.kubernetes.io/instance: karpenter
    app.kubernetes.io/version: "1.2.1"
    app.kubernetes.io/managed-by: Helm
spec:
  namespaceSelector:
    matchNames:
      - karpenter
  selector:
    matchLabels:
      app.kubernetes.io/name: karpenter
      app.kubernetes.io/instance: karpenter
  endpoints:
    - port: http-metrics
      path: /metrics
      
 $ helm template karpenter . --namespace karpenter --set serviceMonitor.enabled=true -s templates/servicemonitor.yaml
 Error: could not find template templates/servicemonitor.yaml in chart

Does this change impact docs?

• Yes, PR includes docs updates
• Yes, issue opened: #
• No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[netlify]

✅ Deploy Preview for karpenter-docs-prod canceled.

Name	Link
🔨 Latest commit	275ec59
🔍 Latest deploy log	https://app.netlify.com/sites/karpenter-docs-prod/deploys/67a9f2072c20c1000869e0e9

[jonathan-innis]

@splichy I don't have a huge issue with the change, but I'm curious why you can't just disable the use of the serviceMonitor if you don't have Prometheus enabled and then just enable the serviceMonitor once it gets installed

[splichy]

@jonathan-innis Yes, I can set servicemonitor.enabled=false, but that just adds an unnecessary manual step into deployment, as Prometheus is deployed in the next wave.
So this api availability check allows me to deploy Karpenter even if Prometheus is not installed yet, it's quite common practice across various charts.

[jonathan-innis]

So this api availability check allows me to deploy Karpenter even if Prometheus is not installed yet, it's quite common practice across various charts

But the question is that this CR won't then be installed once you enable Prometheus, right? You're going to have to some new deployment of Karpenter anyways, so why not just use that deployment to enable the serivceMonitor?

[splichy]

So this api availability check allows me to deploy Karpenter even if Prometheus is not installed yet, it's quite common practice across various charts

But the question is that this CR won't then be installed once you enable Prometheus, right? You're going to have to some new deployment of Karpenter anyways, so why not just use that deployment to enable the serivceMonitor?

We are using ArgoCD, so with auto-sync enabled it will install service monitor right after Prometheus, we are using sync waves where karpenter has higher priority than prometheus - it's a little bit chicken egg problem

[jonathan-innis]

we are using sync waves where karpenter has higher priority than prometheus

Ah, I got you -- that's interesting -- makes sense to me -- didn't even think about the GitOps auto-remediation use-case!

[jonathan-innis]

LGTM 🚀

[coveralls]

Pull Request Test Coverage Report for Build 13240939870

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 64.766%

---

Totals
Change from base Build 13213523731:	0.0%
Covered Lines:	5803
Relevant Lines:	8960

---

💛 - Coveralls