OpenEverest 1.13: Pod Logs Viewer, Dynamic Load Balancer Annotations and Rebranding

What if you could debug database issues without leaving your browser? No more kubectl commands, no more terminal juggling, no more context switching when every second counts during a production incident.

We’re excited to announce OpenEverest 1.13, and this release brings something special: a community contribution from Ankit Kurmi from Red Hat to ease the Load Balancer integrations, Viewing Logs directly from the UI and final rebranding from Percona Everest to OpenEverest.

Ease debugging with Pod Log Viewer

Debugging a database in Kubernetes is usually a pain. When a cluster hits a snag—replication lag, timeouts, or a failed backup—you need the logs immediately.

For many DBAs and developers, this used to mean a frustrating loop:

• No Access: Many users don’t have kubectl access or even know the underlying cluster details. They depend on someone else to “grab the logs.”
• Command Fatigue: Even with access, nobody likes hunting for pod names or typing kubectl logs -f ... for the fifth time that hour.
• Context Switching: Jumping between the OpenEverest UI for status and a terminal for logs is a massive time sink during an incident.

If you don’t live in a terminal, Kubernetes shouldn’t be a barrier to fixing your own database.

In OpenEverest 1.13, we’ve built the logs directly into the UI. No terminal, no kubeconfig, and no specialized K8s knowledge required. If you have access to the OpenEverest UI or API, you have the logs.

This change turns a multi-step chore into a single click. Whether you’re a K8s expert or just someone who needs to see why a query is slow, you now have everything in one place.

Give it a try: Head to any database cluster in OpenEverest and click the new Logs tab.

Integrate easier with Dynamic Load Balancer Annotations

If you’re managing dozens of database clusters, you know the struggle of keeping Kubernetes Service annotations in sync. Whether it’s setting up ExternalDNS, AWS Load Balancers, or monitoring tags, these values usually need to be unique for every single cluster.

The Problem: Manual Annotation Drudge

Previously, you had to manually define annotations for every database Service. If you wanted a unique DNS name like prod-mysql.example.com, you had to hardcode it every time.

This led to “Configuration Sprawl” - dozens of nearly identical Service configs that were a nightmare to update and prone to human error.

The Solution: “Set it and Forget it” Automation

In OpenEverest 1.13, Service annotations now support Go templating. You can now write one policy that automatically injects the correct values based on the database’s metadata.

How it looks in practice:

• Instead of hardcoding a hostname, you use a template: external-dns.alpha.kubernetes.io/hostname: "{{ .ObjectMeta.Namespace }}-{{ .ObjectMeta.Name }}.example.org"
• When applied to a cluster named my-postgres in the production namespace, OpenEverest automatically resolves the Service annotation to: production-my-postgres.example.org

Real-World Examples

You can mix static and dynamic values to automate your entire infrastructure:

• AWS Load Balancer Setup (Static): service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
• ExternalDNS (Dynamic): external-dns.alpha.kubernetes.io/hostname: "{{ .ObjectMeta.Namespace }}-{{ .ObjectMeta.Name }}.example.org"
• Version Tracking (Dynamic): custom.annotation/db-version: "{{ .Spec.Engine.Version }}"

Behind the Feature: Ankit Kurmi

This automation was brought to life by Ankit Kurmi (@Ankit152), a Site Reliability Engineer at Red Hat. Ankit spotted this challenge in our Good First Issues pool and realized it was the key to making OpenEverest scale for large platform teams.

“Contributing to OpenEverest was surprisingly straightforward; the project’s clear architecture made it easy to plug in my code and see an immediate impact on the infra stack. It’s rare to find an open-source project where you can go from ‘fork’ to ‘merged’ with such a low barrier to entry.” - Ankit Kurmi

Ankit’s work eliminates the need to create separate configurations for every cluster. Now, platform teams can define a “Golden Path,” and every new database created by developers will automatically get the right DNS, SSL certificates, and metadata.

Ready to try it? Head to Settings > Policies & Configurations in the OpenEverest UI to start building your dynamic templates.

Rebranding

As you know, OpenEverest was originally called Percona Everest. With the 1.13 release, we’ve finalized our rebranding - logos, docs, and everything in between.

OpenEverest is now a truly vendor-neutral project. We have some big plans and even bigger challenges ahead, and we’re looking for more collaborators to help shape the future of cloud-native databases.

Join the Community

Whether you’re a K8s pro or just starting out, there’s a place for you:

• Contribute: If you want to dive in like Ankit did, check out our Good First Issues and repositories.
• Chat: Join the conversation in the CNCF Slack (channel: #openeverest-users).
• Explore: See how we’re simplifying databases at openeverest.io/#community.