[stable/prometheus-operator] prevent nodePort from constantly changing

[demikl]

Prevent nodePort from constantly changing when using a nodePort service on AlertManager and Prometheus and not specifying a fixed port number.

Signed-off-by: Mickaël Le Baillif mickael.le.baillif@gmail.com

Chart maintainers:
@vsliouniaev
@bismarck
@gianrubio

Is this a new chart

No.

What this PR does / why we need it:

Avoid assigning a new nodePort number when applying the "Service" manifests for prometheus and alertmanager. This is especially noticeable when these manifests are handled with a GitOps method, such as with FluxCD, because manifests are applied on a regular basis.

Why is the nodePort number modified when applying the generated manifest ? Because when prometheus.service.type is NodePort, or the same with alertmanager.service.type, and prometheus.service.nodePort (respectively alertmanager.service.nodePort is unassigned, the generated service manifest contains a key service.spec.ports.nodePort and with an empty value.

This PR remove this key from the manifest if the port number is unassigned.

Which issue this PR fixes

No related issue found.

Checklist

• DCO signed
• Chart Version bumped
• Title of the PR starts with chart name (e.g. [stable/mychartname])

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: demikl
To complete the pull request process, please assign bismarck
You can assign the PR to them by writing /assign @bismarck in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• stable/prometheus-operator/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @demikl. Thanks for your PR.

I'm waiting for a helm member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[demikl]

/assign @bismarck @vsliouniaev @gianrubio

[vsliouniaev]

I believe this is a non-backwards compatible change, since removing the nodePort entry from the service will cause an error on an upgrade. Are you able to confirm this isn't the case?

/ok-to-test

[demikl]

I have tested that the following workflow doesn't trigger any error :

1. using Helm to generate this manifest (removed labels and annotations for better readability) from template:

---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  ports:
    - port: 8000
      targetPort: 80
      nodePort:
      protocol: TCP
  selector:
    app: myapp

2. applying such a manifest in a running cluster, resulting in (random nodePort choosen) :

---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  clusterIP: 172.20.143.73
  ports:
    - port: 8000
      targetPort: 80
      nodePort: 32134
      protocol: TCP
  selector:
    app: myapp

3. modify the generated manifest to remove the nodePort entry:

---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  ports:
    - port: 8000
      targetPort: 80
      protocol: TCP
  selector:
    app: myapp

4. apply this new manifest:

• NO ERRORS
• the previously assigned nodePort stays the same (32134)

[scottrigby]

/hold

Let’s hold PRs to stable/prometheus-operator chart for a short time until prometheus-community/community#28 (comment) is resolved. If you want to help with that effort, to test etc, that would be great!

[scottrigby]

@demikl as a user and contributor, would you mind helping to review/test this PR? prometheus-community/helm-charts#1

No need to reply here. If you can, please just reply and help there. It would help this process move along faster. Thanks!

[scottrigby]

🚧 This chart is now deprecated.

Further development has moved to prometheus-community/helm-charts. The chart has been renamed kube-prometheus-stack to more clearly reflect that it installs the kube-prometheus project stack, within which Prometheus Operator is only one component.

If applicable, please re-open this PR there. Thanks!