Per-client integrations
The pod is Running, but the queue is clogged or the database is slow. Integrations show each client’s services next to its clusters, with the credentials kept by Kubepier.
What it does
Each client gets separate menus for RabbitMQ, Azure Service Bus, MongoDB and Redis. A menu only shows up when that client has the access saved in the client form; without it, the menu does not exist.
What each form asks for
| Service | Fields | The menu shows up when |
|---|---|---|
| RabbitMQ | Management API URL, user and password | All three are filled in |
| Azure Service Bus | Namespace connection string | The connection string is filled in |
| MongoDB | Connection string and database name | The connection string is filled in |
| Redis | A redis:// or rediss:// connection string, or host, port, user, password, TLS and database | There is a connection string or a host |
Common rules
- Free: counts and status, read-only. Pro and Team: read messages and keys and open the panels. Purge and edit are admin-only: on the web, today; on desktop, from 2.7.0.
- The plan is checked on the server (web) and in the app’s main process (desktop), not only hidden on screen.
- On the web, each service has a Connection route: Direct (through the fixed egress IPs, which you allow on the service) or Through the cluster (through a restricted relay in one of the client’s clusters, for private services). On desktop, the connection leaves from your machine.
- Message bodies and key values are never stored, cached nor written to logs.
Queue dashboard
The RabbitMQ and Azure Service Bus menus open on the Panel tab (Dashboard on desktop): every client queue on one screen, with DLQ, trend and alerts on paid plans. On the web and on desktop.
Pod queues
On the pod screen, Kubepier reads the container environment variables, finds the RabbitMQ and Azure Service Bus queues it uses and shows each queue’s depth, on the web and on desktop, on every plan.
Dependencies panel (desktop)
On desktop, the pod shows the Apache Kafka, Amazon SQS, PostgreSQL, MySQL and Redis it uses, read from the container variables: from the value written in the pod or, when the variable comes from a ConfigMap (configMapKeyRef), from the value of that ConfigMap key, which the desktop reads with your kubeconfig. Only host, port and database (or queue and region, for SQS) show; user, password and URL or connection string parameters are dropped before the screen. Values that come from Secrets are never read: the variable shows only the "from a Secret" note. Variables loaded through envFrom are not included. For the ones running in the cluster, it shows how many Service endpoints are ready.
To read the ConfigMap, your kubeconfig needs get on configmaps in the pod’s namespace; without it, the variable does not show in the panel.