Closing the Observability Gap: Building a Kubeflow Plugin for Headlamp - Alok Dangre, NIT Rourkela
Watch on YouTubeVideo summary
The video presents a specialized Headlamp plugin designed to bridge the observability gap for Kubeflow, addressing the common frustration of constantly switching between different tools to diagnose issues. Developed as part of the Malefix mentorship program, this plugin acts as a unified interface that directly detects and exposes Kubernetes APIs, Custom Resource Definitions (CRDs), and components without duplicating existing authoring workflows. By integrating seamlessly into the Headlamp sidebar, it allows users to navigate complex Kubeflow ecosystems with ease, automatically displaying only the relevant sections based on whether a team uses specific technologies like Notebooks, Katib, Spark, or Pipelines. This targeted approach ensures that operators can quickly access detailed views and list views for up to 16 custom CRDs, providing a streamlined experience that simplifies troubleshooting across various Kubeflow distributions.
The plugin significantly enhances debugging capabilities by offering granular insights into specific failure modes such as pending batches, unscheduled GPUs, or resource exhaustion. For instance, the overview pages allow users to immediately see reasons for delays, such as image pull failures, crash loops, or Out-Of-Memory kills, while detailed views help trace failing containers and pods. It also aids in resolving complex issues like missing tolerations for GPU resources or S3 connectivity problems by guiding administrators through condition messages and resource selectors. Furthermore, the tool helps identify infrastructure versus code failures, such as distinguishing between a broken controller loop in Katib experiments and worker node issues, enabling faster resolution of problems that might otherwise require deep manual investigation.
Beyond basic monitoring, the plugin provides advanced features like diff views for comparing pipeline versions to pinpoint configuration changes that caused failures, and topology maps for visualizing Spark application health and executor restarts. Users can inspect recurring CRDs to determine if a scheduled run failed due to scheduling logic or execution errors, and analyze training job details to understand why specific runtimes break after upgrades. The interface also supports comparing experiment results across different namespaces and versions, helping teams preserve context when analyzing model performance. Additionally, the integration of map views allows for real-time visualization of running resources, ensuring that errors can be spotted and acted upon immediately within a cohesive graphical environment.
In conclusion, this Headlamp plugin serves as a comprehensive diagnostic tool that empowers Kubeflow operators to manage their environments more efficiently by consolidating scattered information into a single, user-friendly dashboard. By automating the detection of CRDs and presenting clear pathways to debug specific components like pipelines, experiments, and Spark jobs, it reduces the time spent on manual troubleshooting and minimizes context switching. The presenter encourages users to explore the plugin, report any issues found, and contribute to its development, emphasizing that this solution is intended to guide operators through the intricacies of Kubeflow's diverse landscape. Ultimately, the project aims to make observability accessible and intuitive, allowing teams to focus on resolving root causes rather than navigating fragmented toolsets.
Read the full video transcript
Hello everyone. I'm Alok Adhangale. So,
I'm here presenting about the KubeFlow
plugin, which is made in a headlamp.
This is to provide the observability
lead lab
of
for the KubeFlow. For the operators and
other. This was the part of Malefix
mentorship, by the way.
And uh
So, the problem
is that
when we are using KubeFlow, we face some
issues and we have to constantly switch
between
the Kube config other. So,
avoiding this, the solution we have got
is to make a headlamp plugin. So, you
can directly visit and check all the
details in very easy user-friendly UI.
And uh
This This is the complementation, not a
duplicate. This This was the project
scope.
I did not reveal the KubeFlow's
authoring workflows. I'm focused on what
the Kubernetes API already knows and
what operator needs during the
diagnosis.
And that's what it takes.
The plugin grew in a
The bug plugins
were in a slide like a slide in a side
bar. So, I have covered the five
components and 16 custom CRDs and 39
detail views and list views out
for the whole plugin.
So, there is a plugin SDK for headlamp
and we directly detect the
APIs from
your system. When you should You only
need to download the
headlamp app and then install the
plugin. We directly detect all the CRDs
present and give you the UI friendly
user-friendly UI to navigate you through
Kubernetes and
Kubeflow APIs
to get through all the components and
CRDs.
So, this
sidebar
guides you to all the CRDs and the
components.
A team may run only Kubeflow notebooks
and
Katib or only Spark. The plugin probes
five different API families and parallel
exposes the sections that make a sense.
So, you can get to the section page and
directly navigate it to it.
Also, if you doesn't have any some uh
CRDs present, so it will directly detect
you and let you know about it.
So, this is the notebooks overview page
presentation.
And you can use it for examples like if
there is a pending batch,
but the pending is not enough. So, why
it is pending? So, you will get the
uh reasons about it like if the image
pulled back is off or crash
loopback is off or OOM killed or an
unscheduled reason. The overview page
helps you
and help you to see the CPU aggregates
and memory GPU names for distributions
and other imaging use.
So, you can directly resolve your
problem.
Here is the detailed documents list of
the Kubernetes servers.
I mean, the notebook servers present and
the notebook detailed page.
So, whenever a researcher see that their
notebook server never started, use the
list to locate the open and locate and
open the detailed view page to trace the
notebook CR and pods for failing
containers.
And you can debug it
accordingly.
So, now here is the resource details of
the notebooks. So, if the GPU is the GPU
of the notebook is unscheduled, read the
condition messages and then compare the
resources request selectors and
tolerations.
The example explanation is that the GPU
is contained
and this notebook is missing in the
required tolerations.
You can debug it.
So, now this is the profile CRD, which
will help you if a teammate cannot see
the shared name space. Then start the
profile page and verify the owner and
contributor list and then move the
Kubernetes
R back only
if the expected contributor is present.
So, to debug it if the
if by not getting and if
you want to edit it.
is the
uh
which have will help you
to check notebook if cannot reach the
S3, use the default or default view to
verify the
selector and the secret if it's
unmounted volumes.
So, there is this issue and admin admin
admission configuration problem and
application code. So, you can select
this and get the
uh fix.
Now, this is the plug pipeline's
component.
And this is the KFP CRDs
in the component.
It has the overview page here to see the
pipelines and pipeline version already
running
number of it.
So, you can check what it is.
How many of it's running.
So, if multiple teams report this failed
pipelines, so you can see the control
center like this overview page and check
whether which one is failing and why
investigate the failed workflow.
This This is the pipeline version
pipelines detail page
screenshot and
so you can see the
annotations and all the details like SDK
versions
to debug for inspect the pipeline
definition parameters and artifacts root
file.
This separates the definition regression
from an infrastructure or credential
failure.
The This is the pipeline version CRD
to get the and this is the diff view
which we have made to let you know the
differences in the previous versions.
So, if the version 8 fails and and
version 7 worked,
open the comparison
and find the change in the missed like a
parameter resource limit and connect the
change that change to the failed run.
This results in a spotted story for the
CRD.
This is the run CRD details page.
So, if the nightly running ex- training
running exceeded the limit
the SLA,
then a start and finish duration check
the start and finish duration and status
from here.
And then move the run CRD to the
Kubernetes workload responsible for the
delay.
They are
more sleep
details available in this page. The
screenshot is like limited here.
And this is the recurring CRD
Uh the pipeline component.
So whenever the schedule is reported did
not run,
check this enabled state and gone first,
then inspect whether the schedule
created a run.
This tells you whether this failure is
schedule or execution.
You can actually check all the details
and back links for that specific
pipeline version which is linked with
this recurring CRD.
This is the pipeline experiment CRD.
It is it This is the detail page of it.
This is used You can use it when the
team uses similar model and run things.
Start from the experiment resource to
preserve the intended group name to pick
name space and version context before
you compare the results.
So it eases the task
for you.
Now we are in the Katib component.
This is the dashboard or the control
panel for the Katib.
Uh it shows all the experiment trials
and suggestions running
and
details about it.
The latest running and the health.
So if the overnight GPU uses limits
expires,
use the Katib overview to find active
experiments and their trial budgets,
then distinguish the health source
activity
from a controller and worker problem.
And this is the Katib experiment CRD.
This is the detail page for it.
But so whenever all
trials completed but accuracy did not
improve, inspect this objective metric
target parameter
ranges and the best trials
are narrow or incorrect space is often
visible before reading the training log.
So, you can debug it much faster.
This is the trial CRD
details page.
This shows
one trial reports if one trial reports
in a not fine
or compare its assignment parameters
with the successful trials. Then open
the worker order logs.
We have all the uh
action buttons to see the current logs
and
the view of the JSON
for it.
Uh this is the suggestion CRD
details page
uh showing all necessary
things.
If the experiment stops creating trials,
inspect the suggestion lifecycle and
requests
count, then for
go to the suggestion control for which
is the exhausted
search from a broken
control loop.
So, here this is the Spark component
uh dashboard page. This list out the uh
number of Spark applications and
scheduled jobs running.
So, if a suggestion uh if a alert
suggestion reports
execution time, use this control panel
to find the affected namespace and
application. Then open its topology
rather than searching for the label.
This is the Spark application CRD.
The this is the list view to directly
list all the running ETL applications,
means
use the list to and state duration.
Identify the outlier and keep it in
space and attempt context as you drill
in.
This is the details page
for this application CRD.
And
this this is also in that page.
So, if the driver is unhealthy, but the
job is slow, the topology shows the
executor restarts and node placement.
Explain how repeated restarts on one
pressure node point to an executor
resource or schedule
drop.
Uh this is a scheduled application CRD.
And this is the details page of
This is We also have a diff view
button action button for this.
So, if the two details and aggregation
jobs overlap, inspect the schedule
concurrency policy and generated
application history.
This exposes a schedule policy issue
without treating the child application
as unrelated.
This is the training component with the
number number of training jobs running
it and the namespace run times cluster.
It also shows the recent training jobs
and run time coverages.
So, if the CPU queue is growing, use the
control panel to count the pending jobs
and identify the namespace and run time
possible before the investigation
investigating schedule capacity.
This is the training job CRD list view.
If older jobs using a different run time
succeeded, then the run time change
becomes the leading queue. So, you can
directly list here
uh according to the condition and
go to that specific rather than
going to some commands.
This is the training jobs uh CRD's
detail view page.
To see all its details.
This uh
So, if a full worker job remains
in initializing the
follow this training job details view
page to see the job set and job
worker. It's a good pod condition shows
the resource request that prevents
scheduling.
Uh this is the training run time and
cluster admin run time
details [clears throat] view page.
This is for training run time.
And uh this is called
cluster training run time details page.
So, even update upgraded run time breaks
all the new training jobs. Compare this
run time templates and batch preview.
This is uh here we have
preview buttons for to see the preview.
Highlighted and changed images you can
check
command environment variables for
default resource request.
Um
So, this is uh so
So, the here it is all about like you
can always inspect any CRD's by going
its overview list and details page.
Check the condition and state. What
containers running? This viewers are
back checks and grants. And you we also
have a map integration. So, you can
directly check uh the map view for your
Kubeflow resources running.
So, you can spot the error anytime.
Follow the topology and act on
context.
>> [clears throat]
>> So,
so you can go and check it out the
headlamp plugin. If you have any issues,
you can report it there and you can
make an issue and uh
let me know if anything's.
I hope you like this.
Uh
this all example to guide you so it can
help you for the specific uh CRD detail
space.