feat(prometheus): Always enable Prometheus #86
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
prometheus.enable
optionprometheus.enableSidecar
optionThe intention is to always configure BindPlane to use Prometheus.
Migration path
Configuration
The following options can be removed from a user's values configuration:
prometheus.enable
prometheus.enableSidecar
StatefulSet
Single instance StatefulSet deployments can be upgraded without issue regardless of their Prometheus status.
Existing StatefulSets without Prometheus will be upgraded without issue. The new pod will contain a sidecar (additional container within the bindplane pod).
Existing StatefulSets with
prometheus.enableSidecar
set will be upgraded without issue and continue to use their sidecar.Deployment (High Availability)
When running as a Deployment, the chart will not deploy Prometheus as a sidecar, because this would result in one Prometheus container per pod in the deployment. It is expected that Deployment users will configure a remote Prometheus server on their own, separate from this chart.
Existing Deployments without Prometheus will start up fine but will not function until Prometheus is correctly configured.
Existing Deployments that contain Prometheus will continue to use Prometheus without issue.
Testing
Single Instance
Prometheus Previously Enabled
Single instance testing is easy because the output from helm is the same as before if Prometheus was already enabled.
always-on-prometheus
helm template --values ./values.yaml charts/bindplane > old.yaml
prometheus
options from the values filehelm template --values ./values.yaml charts/bindplane > new.yaml
Diff the results
Or checksum them:
Prometheus Not Enabled
If Prometheus was not enabled previously, you can use the following values file to deploy main and then upgrade to this branch:
Deploy the
epic/always-on-prometheus
branch to minikube (the branch we are merging into)git checkout epic/always-on-prometheus helm template --values ./values.yaml charts/bindplane | kubectl apply -f -
Note that bindplane has a single container (does not have a Prometheus sidecar container).
Upgrading can be done by deleting the statefulset and re-deploying. The delete is necessary due to the addition of a sidecar container. See this previous PR for details on why this is safe.
git checkout single-instance-prometheus-always-on kubectl delete sts release-name-bindplane template --values ./values.yaml charts/bindplane | kubectl apply -f -
Once deployed, the bindplane pod will contain two containers.
High Availability
WIP
Please check that the PR fulfills these requirements