►
From YouTube: Kubernetes SIG UI Introduction and Updates - Sebastian Florek & Marcin Maciaszczyk, Shu Muto
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes SIG UI Introduction and Updates - Sebastian Florek & Marcin Maciaszczyk, Kubermatic; Shu Muto, NEC
SIG UI is the special interest group developing Kubernetes Dashboard. In this session the SIG UI leads will provide an overview of what was accomplished over the past year, including new views, functions, internationalizations, leadership changes etc. They will also share plans for the upcoming releases. The session will conclude with an open discussion and Q&A.
A
A
C
C
C
Kubernetes
dashboard
is
packaged
in
one
binary,
but
it
consists
of
the
front
end
and
the
backend
also
to
get
and
to
visualize
the
metrics
of
the
cluster
metallic
server
and
dashboard
metrics
script
needed
the
front.
End
is
written
in
typescript
run
in
browser
and
it
accesses
the
background
to
get
information
for
your
kubernetes
cluster.
C
C
C
C
C
C
Please
add
your
translations
to
this
file
for
your
translation
works.
You
can
all
use
a
development
container.
That's
the
script
that
scripts
on
our
repository
create
finally
create
prerequest
to
kubernetes
dashboard
repository
when
the
changes
added
into
the
front
end.
Your
translation
file
will
be
changed
also
so
keep
to
watch
our
blue
request,
labeled
language,
something
and
please
update
your
translation
file
after
the
requests
are
merged.
A
Like
me,
okay,
okay,
so
the
next
part
of
our
talk
is
roadmap.
So
we
have
recently
reached
the
state
where
we
support
most
of
the
kubernetes
resources,
so
the
most
important
ones
are
displayed.
You
can
get
some
information
about
them
using
kubernetes
dashboard,
but
the
problem
that
we
are
having
right
now
is
that
the
scalability
and
also
performance
in
the
biggest
clusters
is
not
that
good.
So
our
next
steps
that
we
are
going
to
take
will
be
connected
to
that
to
solving
that
problem.
A
The
container
that
we
have
right
now,
because
current
container
is
for
the
api
and
ui
and
it's
all
in
one,
then
we
also
wanted
to
do
styling
improvements,
implement
new
api
architecture
with
refactored
out
layer,
and
we
will
go
through
all
these
steps
to
show
what
we
want
to
actually
achieve.
So,
as
I
mentioned
already,
the
step
that
we
are
working
at
the
moment
is
splitting
api
and
ui
of
kubernetes
dashboard
into
two
containers,
and
first
container
will
be
kubernetes,
dartboard
ui
with
its
own
web
server.
A
We
have
started
soft
code
freeze.
That
means
at
the
moment
we
are
working
mostly
on
splitting
and
changing
the
project
architecture,
but,
of
course,
bugs
security
fixes
things
like
translations
and
updates
to
documentation
are
allowed
and
we
are
doing
them
so
the
next
step
after
we
will
finish
what
we
are
working
at
the
moment,
hopefully
within
a
month
or
two,
is
to
work
on
styling
improvements.
A
So
right
now
it's
possible
in
dashboards
to
apply
white
labeling,
your
own
styles,
but
it's
not
possible
yet
to
mount
the
custom
themes
into
the
container.
So
everything
would
have
to
be
pre-compiled
and
we
want
to
solve
that
problem
by
allowing
mounting
custom
themes
into
the
separated
ui
container
and
then
the
biggest
change
that
we
want
to
do.
And
I
think
sebastian
will
start
yeah
so
or
the
next
part.
B
So
we
will
also
be
able
to
slowly
migrate
to
the
new
architecture
by
like
disabling
and
connecting
to
the
new
endpoints
that
will
start
introducing
and
also
what
the
new
thing
that
we
would
like
to
use
is
the
graphql
api,
since
we
would
like
to
offer
a
bit
better
way
to
handle
leave
updates
in
the
dashboard
and
right
now,
it's
mostly
polling
in
intervals
and
with
the
graphql
api.
We
want
to
be
able
to
make
it
like
leave
updates
without
this
kind
of
workouts.
B
Let's
say
we
also
want
to
introduce
new
out
layer,
which
means
that
we
want
this
single
crochet
service
to
be
a
single
source
of
true
for
us
and
to
support
oidc
logging
into
idc's,
so,
for
example,
github,
google
and
stuff
like
that.
It
also,
of
course,
depends
how
your
kubernetes
api
is
configured,
but
we
want
to
support
all
of
that
and
thanks
to
splitting
our
services
and
resource
support
to
smaller
microservices,
that
will
actually
connect
it
to
each
other,
probably
through
grpc.
B
It
might
also
be
connected
to
a
slightly
factoring
of
the
dashboard
ui,
because
we
are
thinking
about
some
changes
to
maybe
hide
things
that
users
would
not
have
access
to
instead
of
showing
error
notifications.
But
this
is
more
of
a
user
experience
that
we
are
still
trying
to
figure
out
how
we
could
improve
that.
D
A
D
B
Also,
if
you
want
a
bit
more
complex
features
like
find
resources
that
are
connected
to
resources,
for
example,
on
the
pods,
let's
say
details:
you
want
to
get
all
own
owners,
events
connected
to
sports
and
there
are
like,
for
example,
storage
classes
and
volumes.
So
all
that
information
that
is
connected
to
your
resource,
then
well,
you
need
your
api.
You
need
your
own
logic
to
find
those
resources
and
to
return
to
the
ui
that
can
use
this
yeah.
A
And
second
thing
is
that
you
would
have
to
fetch
all
the
data
into
ui
so
into
the
browser.
So
all
the
logic
would
happen
into
the
in
the
browser,
so
the
resource
consumption
would
happen
would
be
on
the
front
end
side,
which
is
not
the
best,
because
we
want
to
move
that
to
the
back
end,
to
be
able
to
scale
it
to
split
it
into
containers.
So
that's
why
it
should
happen
on
the
backend
side.
B
F
B
B
There
were
some
issues
created
by
users
some
time
ago
that
were
actually
pointing
out
that
for
clusters,
with
an
example,
10
000
of
pods
or
like
100
or
more
nodes,
then
it
might
become
harder
to
use
dashboard,
especially
like
the
workloads
view
that
has
to
download
basically
whole
almost
the
whole
cluster
inside
this
single
port,
which
can
take
a
lot
of
space.
Of
course.
So
that's
why
we
are
aiming
to
split
those
into
separate
containers
with
services
and
have
some
caching
so
that
you
don't
have
to
re-fetch
over
and
over
again.