Unlike cluster administrators, developers and application owners typically do not have low level access to cluster wide resources. They are typically only provided with "project" or "namespace" roles. However, they need the ability to quickly debug and diagnose issues when they occur. To assist with this, the controller provides this persona with a number of turnkey facilities that
- Provide "deep visibility/insight" into the state of their workloads and
- Provide the means to quickly debug and diagnose issues with k8s resources associated with their workloads
- Provide both "current status" and "trends" of health.
All authorized users in a Project have access to the Project Dashboard that will give them a unified, at-a-glance view into the state of their clusters, workloads and activity.
A workload can comprise 100s or 1000s of distinct Kubernetes resources. The controller actively monitors the deployment status of all the k8s resources for a workload on remote clusters. To view the deployment status of a workload,
- Navigate to your Project and Select Workloads
A READY state for for deployment status means that all k8s resources associated with the workload were successfully deployed.
This section describes the various facilities available to developers to help them troubleshoot and debug issues with their workloads quickly and efficiently. Once the developer logs into their Project and navigate to their workload, they literally just have to click on the Debug button to get access to the developer tools.
Zero Trust Channel¶
The developer does not require inbound or privileged access to remote Kubernetes clusters to perform diagnostics.
- Everything is performed over the zero trust control channel between the managed cluster and the controller.
- The developer has to be strongly authenticated and authorized by the controller before they are able to access the built in developer tools.
- An audit log of all activity is maintained for compliance and governance.
Zero Trust Kubectl¶
The developer is provided a facility to launch a secure, web based kubectl shell to the remote cluster. The developer is taken right to the namespace where the workload is deployed to.
Multi Cluster Views¶
If workloads that are deployed to multiple clusters, the developer can seamlessly switch the developer tools view from cluster to cluster by selecting the "name of the cluster" on the top left.
Kubernetes events are a resource type in Kubernetes that are automatically created when resources have state changes, errors, or other messages that should be broadcast to the system. Events are an invaluable resource when debugging issues in your Kubernetes cluster. Developers are provided with a "pre-filtered" list of events for all resources associated with their workload.
Developers also have access to a pre-filtered list of all Kubernetes resources associated with their workload. All the resources are organized and presented in a manner that is intuitive and easy for the developer to process.
- Deployment Resources (Pods, Deployments, Replica Sets, Daemon Sets, Jobs, Cron Jobs)
- Load Balancers (Ingress, Services)
- Config and Storage (Secrets, Config Maps, PVCs)
- Access Control (Service Accounts, Roles, Role Bindings)
Pod and Container Trends¶
For all deployed pods and containers associated with the workload, the developer is provided visibility into "time series" data for the health and resource utilization trends.
For Containers in Pods
Developers are provided with the facility to quickly investigate and debug issues associated with their running Pods and Containers.
Developers are provided the facility to quickly view the "events" associated with their Pod.
For a pod, click on "Events" under actions
This action performs a "live retrieval" of pre-filtered list of events associated with this pod.
Developers are provided the facility to retrieve and view the logs associated with a specific container in a single click. This enables them to investigate issues quickly and efficiently.
For a pod, click on "Logs" under Actions. This will open a real time, zero trust kubernetes access (ztka) shell to the running container and present the developer with the Logs.
Exec to Container¶
There are scenarios where the developer may need to "exec" to a specific container so that they can investigate issues faster.
For a pod, click on "Exec" under Actions. This will open a real time, zero trust kubernetes access (ztka) shell to the running container.