Kubernetes Dashboard
- Show closed items
- View on a roadmap
- Issuegitlab-org/gitlab#478379BacklogCategory:Kubernetes Management Customer feedback devops deploy feature addition group environments section cd type feature workflow problem validation
- Issuegitlab-org/gitlab#460279Category:Kubernetes Management customer devops deploy group environments section cd type ignore
- Issuegitlab-org/gitlab#438254BacklogCategory:Kubernetes Management GitLab Free GitLab Premium GitLab Ultimate devops deploy documentation frontend group environments section cd type ignore workflow design
- Epic#12345122Category:Kubernetes Management group environments
- Issuegitlab-org/gitlab#433238BacklogCategory:Kubernetes Management UX devops deploy feature addition frontend group environments section cd type feature workflow design
- Issuegitlab-org/gitlab#422441Backlog1Technical Writing UI text UX design-weight 1 devops deploy direction documentation environments parked feature addition group environments section cd type feature workflow refinement
- Issuegitlab-org/gitlab#365901Backlog5At riskCategory:Kubernetes Management GitLab Free Track Health Status [DEPRECATED] UX customer delivery-direction design-weight 3 devops deploy direction documentation frontend group environments missed:15.10 missed:15.11 missed:15.2 missed:15.4 missed:15.7 missed:16.0 missed:16.1 missed:16.10 missed:16.2 missed:16.4 missed:16.5 missed:16.6 missed:16.7 missed:16.8 missed:16.9 section cd type feature workflow ready for design
- Issuegitlab-org/gitlab#50801017.81Beautifying our UI Category:Kubernetes Management GitLab Free GitLab Premium GitLab Ultimate UX devops deploy documentation feature addition frontend group environments priority 3 release post item in review section cd type feature workflow complete
- Issuegitlab-org/gitlab#47402617.32bug functional devops deploy frontend group environments section cd type bug workflow complete
- Issuegitlab-org/gitlab#470050Backloganalytics instrumentation devops deploy group environments section cd workflow refinement
- Epic#1433826Aug 10 – Oct 11, 2024Category:Environment Management Category:Kubernetes Management group environments
- Epic#137933 37May 11 – Jul 12, 2024Category:Environment Management Category:Kubernetes Management GitLab Free GitLab Premium GitLab Ultimate UX design-weight 2 devops deploy feature addition frontend group environments release post item in review section cd type feature workflow complete
- Issuegitlab-org/gitlab#43268517.63Category:Kubernetes Management automation:ml automation:self-triage-encouraged customer devops deploy group environments missed:17.5 priority 1 section cd severity 3 type bug workflow complete
- Issuegitlab-org/project-templates/cluster-management#55
- IssueClosedgitlab-org/gitlab#432573BacklogCategory:Environment Management GitLab Free Nav request Rejected automation:ml devops deploy feature addition group environments section cd type feature workflow design
- Epic#113511324Aug 18, 2023 – May 10, 2024Category:Kubernetes Management group environments
- Issuegitlab-org/gitlab#391514Backlog5Category:Environment Management Category:Kubernetes Management GitLab Free GitLab Premium GitLab Ultimate UX design-weight 2 devops deploy feature addition frontend group environments section cd type feature workflow ready for development
- Show labels
- Show closed items
Activity
Implementation plan proposal
First iteration (~ 12 MRs)
- Create a new route and a controller for the dashboard. We can use
/-/kubernetes/<agent-id>/
- backend - Add a corresponding access level policy. We can limit the dashboard to developers or maintainers/owners - backend
- Handle the state where no agent ID was provided (design issue) - frontend
- Handle the state where the provided agent is unavailable or cannot connect to the cluster (design issue) - frontend
- Add a Vue router for the workload types: Pods, Deployments, StatefulSets, ReplicaSets, DaemonSets, Jobs, and CronJobs. Each of the pages should have an empty state and a loading state - frontend
- For each workload type page render - frontend
Second iteration (~15 MRs)
- Add agent info. We need to figure out how to request an agent. Currently, we need to specify the project in which the agent is available - backend, GraphQL, and frontend
- Add navigation. I believe at some point we'll need to integrate our navigation into the super sidebar - backend frontend
- Add overview page - frontend
- Add other pages: Services and Networks, Storage, Configuration, Namespaces - frontend
- Add filtering - frontend
Third iteration
- Implement CPU, Memory, Network, and Project data for the workload types. This will need further refinement.
- Add Flux and Helm resources pages.
- Add RBAC page.
@gitlab-org/ci-cd/deploy-stage/environments-group, could you please take a look at my plan proposal? I am happy to start creating issues if it looks overall good. We can then discuss it in the corresponding issues in detail.
- Create a new route and a controller for the dashboard. We can use
@anna_vovchenko Thank you for writing up! I have a few comments:
Add a corresponding access level policy. We can limit the dashboard to developers or maintainers/owners - backend
We should reuse
read_cluster_agent
policy in order to keep the authorization consistent across different pages.Ability.allowed?(user, :read_cluster_agent, agent)
should work out of the box as it takes care of the all of the underlying fundamental checks (See https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/policies/clusters/agent_policy.rb for more information)Add agent info. We need to figure out how to request an agent. Currently, we need to specify the project in which the agent is available - backend, GraphQL, and frontend
We can add the
user_access_authorized_agents
field to theUserType
. In a resolver, we can simply call::Clusters::Agents::Authorizations::UserAccess::Finder.new(current_user).execute
that returns all of the authorized agents for a specific user.@anna_vovchenko Thank you, this is great discussion starter!
We can limit the dashboard to developers or maintainers/owners
Developer role should be able to access it. What is available in the cluster is to be managed through Kubernetes RBAC.
Add a Vue router for the workload types: Pods, Deployments, StatefulSets, ReplicaSets, DaemonSets, Jobs, and CronJobs. Each of the pages should have an empty state and a loading state
Just to make sure we are aligned: the router should work with the browser url and we should be able to deep link to a list of failing pods for example. I imagine a link to failing pods like:
/-/kubernetes/<agent-id>/pods/?status=failed&namespace=my-namespace
.The above use case assumes that the user navigates to the cluster UI on the environments page, sees some failed pods, and clicks that box. Clicking there should lead them to a list of the failing pods with the environment's namespace selected.
For each workload type page render
Please, check how self descriptive the resource types are. See my question in the Kubernetes Slack
If Kubernetes kinds can not describe their preferred data, I recommend to design them one by one. In this case, the first iteration can show just the name of the resource
For example, the Flux
GitRepository
kind contains some data on what columns to show for each resource:If CRDs can have this data, I expect that built-in kinds have it too.
A set of single stats
I'd leave it out from the first iteration. There is no status field for every resource type. (e.g. ConfigMap)
A drawer for each item with additional information (only the description tab for now)
I think, we'll need to design these one by one. Again, not every kind has logs, CPU, Memory, etc.
Thanks for putting this together @anna_vovchenko - from what I gather, we are good from a design POV for iteration 1 with the two design issues currently open?
Feel free to reach out if you come across anything else!
I think, we'll need to design these one by one. Again, not every kind has logs, CPU, Memory, etc.
@nagyv-gitlab - Can you elaborate a bit more on what you mean by one by one? Could we potentially just design a robust (everything) drawer and just remove what is unneeded?
Could we potentially just design a robust (everything) drawer and just remove what is unneeded?
That might work. We can hide the field if the given resource does not have it.
I recommend looking into how others do it. There are quite a few dashboards for Kubernetes to see how much custom views we might need (HeadLamp, OpenLens + plugins, K9s, the "official" dashboard, ...)
@nagyv-gitlab - Great idea. One of my career development goals for September/October is to complete a competitive review - I wonder if the dashboard could be the opportunity to do this?
@anna_vovchenko It looks good, I don't have any questions at the moment. Shinya's comment above made sense to me
If CRDs can have this data, I expect that built-in kinds have it too.
I think that's a good pointer. Not necessarily in the first iteration, but I think it makes absolute sense to rely on the CRD additional printer columns later and with that have a "generic printer".
AFAIK, the built-in kinds don't expose a similar data in the API spec. Instead the printers (with the columns and their priorities) are defined here.