Skip to content

Render Kubernetes resources in Environment index page

Release notes

How do you check the status of your applications running in your clusters? While the pipeline status and environment page views provided insights about the latest deployment runs, GitLab until now lacked insights about the running state of your deployments. This GitLab release allows you to get a quick overview of the primary resources in your Kubernetes environments.

This functionality works with every connected Kubernetes cluster. It does not matter if you used the CI/CD integration or GitOps to deploy your workloads. In a feature iteration we want to improve the experience for Flux users by showing the synchronization status of the given environment.

Summary

This issue is to implement https://docs.gitlab.com/ee/architecture/blueprints/gitlab_agent_deployments/#fetch-resources-through-user_access.

The design issue: #375449 (closed) and Figma link.

Task

After the user gained access to the agent, GitLab frontend fetches available API Resource list in the Kubernetes and fetches the resources with the following parameters:

  • namespace ... #{environment.lastDeployment.agent.kubernetesNamespace}
  • labels
    • app.gitlab.com/project_id=#{project.id} AND
    • app.gitlab.com/environment_slug: #{environment.slug}

If no resources are found, this is likely that the users have not embedded these lables into their resources. In this case, frontend shows an warning message There are no resources found for the environment. Do resources have GitLab preserved labels? See <troubleshooting-doc-link>.

For the fixed label discussion, please see Kubernetes visualisation fixed filters (#388407 - closed).

  • Documentations

Implementation plan

  1. Render Kubernetes overview based on the received value of agent.kubernetesNamespace for the environment
  2. Perform cluster connection when the user opens the Kubernetes overview
    • Render a corresponding error when access is denied
  3. Render cluster health status based on the status of the selected resources
  4. Render sync status (based on which data?) -> it will be implemented within the later iteration
  5. Render the agent info
  6. Render the Kubernetes pods
  7. Render the workload summary
  8. Render the services table
  9. Render the environment details based on the selected namespace, labels and other information (such as auto_stop_at value and external_url) -> it will be implemented within the later iteration

Watch API

#393002 (closed)

Frontend use Watch API instead of polling. For more details, See https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes. and example using the KAS User Access feature here #393002 (comment 1291133940)

Query details

GET https://<kas-proxy-url>/apis/apps/v1/namespaces/<namespace>/deployments
GET https://<kas-proxy-url>/apis/apps/v1/namespaces/<namespace>/daemonsets
GET https://<kas-proxy-url>/apis/apps/v1/namespaces/<namespace>/statefulsets
GET https://<kas-proxy-url>/apis/apps/v1/namespaces/<namespace>/replicasets
GET https://<kas-proxy-url>/apis/batch/v1/namespaces/<namespace>/jobs
GET https://<kas-proxy-url>/apis/batch/v1/namespaces/<namespace>/cronjobs
GET https://<kas-proxy-url>/api/v1/namespaces/<namespace>/services
GET https://<kas-proxy-url>/api/v1/namespaces/<namespace>/pods
Edited by Anna Vovchenko