prometheus-operator VS charts

The project repository for Prometheus-operator can be found here, The repo defines the CRDs and the controller. You can follow this documentation for the installation. which will require the creation of metrics exporters, node exporters, scrape configurations, etc.

Personally I use kubernetes, k3s is kind of lightweight, with the Prometheus operator.

https://k3s.io/

https://prometheus-operator.dev/

Kubernetes is not for everyone and is far from perfect but you already use Docker and you seem to seek many features offered by Kubernetes.

I see that the operator is a community-run project. Does anybody have any experience (positive or negative) on running the operator itself? I wonder if it is more for multi-tenant Prometheus. For single tenant Prometheus collection, I guess the big gain is abstracting scrape config into ServiceMonitor and PodMonitor resources? Is there anything else that this makes much better?

But in all honesty if you’re on k8s you’re probably best served by the Prometheus operator. It’ll give you all that and more, easily.

Try some monitoring.

It’s a common pattern [1] how else can users override the child objects you’re controller creates?

1 https://github.com/prometheus-operator/prometheus-operator/b...

The Prometheus operator is this one https://github.com/prometheus-operator/prometheus-operator

At a minimum, you want to look at your metrics using the Prometheus Operator. You can write alerts for resource requests.

Prometheus Operator is an independent project from the Prometheus project. I know, it can lead to confusion. In the official README you can find short comparison. Basically, Prometheus Operator does what an operator should do - provides Kubernetes native deployment and management of Prometheus and related monitoring components like Grafana or Alert Manager.

Both of these examples seem pretty obvious and something you wouldn’t mess up, but as your chart grows, so does your values.yaml file. A great example is the Redis chart by Bitnami. I encourage you to scroll through its values file. See you in a minute!

We will write a Terraform module that will take a list of configurations for each required RabbitMQ instance. Luckily for us, we don't have to write the Kubernetes yaml configurations since the helm charts by Bitnami does a great job of doing all the things we discussed above. All we need to do is leverage Terraform Helm Provider and deploy the chart with the required values for our use case.

💡  The full details of helm charts can be referenced in their associated GitHub Repository.

I have a configmap with the ndjson set up under data:, similar to https://github.com/bitnami/charts/issues/6159 and it's subsequent answer.

This way, you can easily deploy any Helm charts from this public repo - https://github.com/bitnami/charts/tree/main/bitnami in just minutes.

The Bitnami Github Pages themselves usually cover everything you need to know. Configure a values.yaml file, or modify that to your liking, and you run helm install, as written in their docs.

The actual reason that our pods are not coming up is found when we review the helm installation that we are trying to run. If you check the dependencies in the GitHub repository (https://github.com/bitnami/charts/blob/main/bitnami/drupal/values.yaml) you find out that persistent storage is enabled by default and set to 8Gi. Also, the helm package uses MariaDB and the database size is specified to a default of 8Gi, thus setting the minimum storage for this installation to be 16Gi.

We're using https://github.com/bitnami/charts/tree/main/bitnami/spark, but I have heard good things about https://github.com/GoogleCloudPlatform/spark-on-k8s-operator as well. Hudi should not need any long running deployments as per the docs https://hudi.apache.org/docs/0.5.1/deployment/#deploying

Bitnami has its own scaffolding published at https://github.com/bitnami/charts/tree/main/template