gardener/dashboard

Purpose and topology

Gardener Dashboard is a Kubernetes/Gardener management dashboard: a browser SPA backed by a Node.js API that reads and mutates Gardener resources. It is a Yarn monorepo with deployable frontend/backend, shared Kubernetes and operational packages, and Helm charts. Primary runtime entry points are frontend/src/main.js, backend/server.js, and backend/lib/server.js.

Browser application

The Vue/Vuetify SPA owns login, project selection, cluster (“Shoot”) and Seed administration, credentials, terminals, quotas, and member workflows. Routes render views; composables and stores encapsulate UI state and API operations.

• frontend/src/main.js

• frontend/src/router/index.js

• frontend/src/store/index.js

UI-to-server traffic is centralized through the API composable; WebSocket/socket state supports live backend-dispatched resource updates.

• frontend/src/composables/useApi/index.js

• frontend/src/composables/useSocketEventHandler.js

• frontend/src/store/socket/index.js

Backend HTTP, authentication, and API boundary

The backend is a Node.js server/application with middleware, authentication/authorization, OpenAPI exposure, health checks, REST route registration, and Socket.IO-style IO dispatch. It is the trust boundary between browser sessions and Kubernetes/Gardener APIs.

• backend/lib/app.js

• backend/lib/server.js

• backend/lib/routes/index.js

Routes map dashboard resources—projects, shoots, seeds, credentials, terminals, tickets—to service-layer operations, rather than exposing Kubernetes access directly to the frontend.

• backend/lib/routes/shoots.js

• backend/lib/routes/projects.js

• backend/lib/routes/terminals.js

Gardener/Kubernetes resource services

Backend services implement domain operations and transform/authorize access to Gardener custom resources and Kubernetes resources. They cover Shoots, Seeds, projects/members, quotas, cloud profiles and credentials, managed seeds, and terminals.

• backend/lib/services/shoots.js

• backend/lib/services/projects.js

• backend/lib/services/cloudProviderCredentials.js

The shared Kubernetes client provides HTTP access, resource-group definitions, errors, pagination, and informer primitives. Kubeconfig/client configuration determines the Kubernetes API connection and authentication behavior.

• packages/kube-client/lib/Client.js

• packages/kube-client/lib/resources/GardenerCore.js

• packages/kube-config/lib/ClientConfig.js

Live state, cache, and event propagation

The backend watches selected Kubernetes resources, maintains caches, and propagates changes to connected UI clients. This separates expensive API watches/listing from browser requests and supplies real-time project, shoot, seed, and managed-seed updates.

• backend/lib/watches/index.js

• backend/lib/cache/index.js

• backend/lib/io/dispatcher.js

Underlying cache/informer machinery supports list/watch reflection, local stores, and backoff behavior.

• packages/kube-client/lib/cache/Informer.js

• packages/kube-client/lib/cache/Reflector.js

External integrations and operations

The backend integrates with OIDC/JWT security, Kubernetes API servers, GitHub (ticket synchronization and verified webhooks), and Prometheus-compatible metrics. Request/session pooling and logging are shared package concerns.

• backend/lib/security/jose.js

• backend/lib/github/SyncManager.js

• packages/monitor/lib/metrics.js

Deployment model

Docker packages the application; Helm deploys dashboard runtime resources (Deployment, Service, Ingress, config/assets, OIDC/GitHub/kubeconfig/session secrets) and application RBAC. A separate identity chart deploys supporting identity infrastructure.

• Dockerfile

• charts/gardener-dashboard/charts/runtime/templates/dashboard/deployment.yaml

• charts/gardener-dashboard/charts/application/templates/dashboard/clusterrole.yaml