Helm Chart

[recharte]

Hi everyone,

We're excited to announce that we're moving forward with adding an official Helm chart for Percona Everest! 🎉 This will make deploying and managing Everest in Kubernetes even easier. To give you an early look, we've created a Proof of Concept (PoC) for the Helm chart, which you can check out here.

Please note that this is a real PoC—it's unpolished, lacks proper documentation, and contains some hacky scripts just to get things working. Full development hasn't started yet, and we want to involve you in shaping it from the ground up.

How can you help?

We’d love for you to try out the PoC and share your thoughts to help guide the next steps:

• How do you plan to use the Helm chart for Percona Everest in your Kubernetes environment?
• What key features or configurations would you find most valuable?
• Are there any advanced use cases or edge cases we should consider?
• How should we handle upgrades, rollbacks, or versioning to best suit your workflows?

Your feedback will be instrumental in shaping the development of the Helm chart. We look forward to hearing your insights and experiences with the PoC!

Cheers

[icc-garciaju]

Having a helm chart would allow automated and reproducible deployments.

Also it can be included as dependency for other charts as a bundle to initialize a full-featured cluster.

It looks like percona-monitoring is already included, thats good.

Also, being able to define backup repositories from the chart would be nice.

[travisghansen]

Great! Been waiting for this for a while. Couple considerations:

• we manage everything using argocd..by extension the use of helm hooks can be problematic so avoiding those would be great if applicable
• I see some resources in the repo that seem to reference olm..is it required to be running olm to use the chart?
• Is it possible to configure a watch all namespace setup for all the different flavors?

Thanks!

[mayankshah1607]

Hi @travisghansen, thanks for your feedback!

To address your first two points: OLM is an integral part of Everest's architecture, and we primarily rely on it to streamline the installation and upgrade processes for Percona operators, making it a necessary dependency. Due to the way OLM functions, certain imperative actions are required during installation, which is why we currently use Helm chart hooks to handle these one-time tasks. I understand that this adds some complexity, but I want to reassure you that we are planning to re-architect our installation process in a future release. Our goal is to make it more compatible with Helm and GitOps, ultimately phasing out the OLM artifacts and most of the hooks from the Helm chart.

Is it possible to configure a watch all namespace setup for all the different flavors?

In short, no, we currently don't support that setup. This was an intentional architectural decision based on stability and security considerations. By isolating the operator(s) to a specific namespace, we limit the impact of any issues to the databases within that namespace, rather than affecting all databases across the cluster. This also reduces the blast radius in case of any problems. It also enables a phased rollout of new operator versions—you can test a new version in one namespace first, and only proceed with upgrading other instances after successful testing.

With that said, there's also no technical restriction that stops us from implementing such a setup, and we can certainly look into this. :)

[travisghansen]

Thanks for the consideration! That all sounds great and I will continue to monitor the progress!

[travisghansen]

For what it’s worth on the blast radius front, we do this by rolling out updates through entire environments before ever hitting production clusters, but the intent is not lost on me.

Our approach to self-service for individual teams (which operate generally autonomously in namespaces) really fits the cluster-wide model much better…as cluster admins we offer the menu of items and they chose what they need, requiring them (or me) to also install the operator on a per-ns basis is a pretty cumbersome ask in our workflow. It’s simply much easier to say ‘we support these percona crds, enjoy’ and it ‘just works’.

[PrivatePuffin]

Agreed, our current design is per-application namespaces for additional easy isolation.
Which would mean a complete install of the operator for each application. Which is rather cumbersome and basically creates a blocker for even using Percona Everest at all.

[effespwnz]

Ingress resource to avoid port forwarding or creating ingress manually/separately?

[recharte]

We just released v1.4.0 with an official helm chart
There's also a document with instructions on how to integrate with ArgoCD.

Some of the requested features in this discussion are absent from this initial version but we plan to add them in the future.