►
From YouTube: Deep Dive: Kubernetes (UI) SIG - Jeffrey Sica, University of Michigan & Sebastian Floreks, Loodse
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Kubernetes (UI) SIG - Jeffrey Sica, University of Michigan & Sebastian Floreks, Loodse
The Kubernetes Dashboard is the primary way non-cloud-hosted Kubernetes clusters are managed and is a great introductory tool in a new cluster-admin's belt. The Dashboard, much like Kubernetes itself, is a complex beast with many moving parts. With a front-end written in Angular, and a back-end written in go, the project has a complex set of needs to support development. This session will dive into both the front-end and back-end development with the Dashboard as well as outline progress with the 2019 SIG-UI Roadmap.
https://sched.co/MPkX
A
B
A
All
right,
so
what
we're
gonna
go
through.
This
is
a
deep
dive,
but
every
every
presentation
needs
a
quick
little
intro
we're
also
going
to
go
through
code.
Walk
through
this
is
there
are
many
folders
in
the
kubernetes
dashboard
project,
but
we're
gonna
go
over
some
of
the
more
important
ones.
There's
a
quick
slide
on
best
practices.
If
you're
doing
kubernetes
dashboard
development.
We
want
to
talk
about
our
plans
for
the
next
year
and
beyond,
and
then
also
see
if
anyone
else
is
willing
to
are
interested
in
contributing
and
then
take
everyone's
questions.
A
So
hopefully
you're
here
and
you
know
the
kubernetes
dashboard,
but
if
not,
it
is
meant
to
be
just
a
generic
web
UI
for
you
to
interact
with
your
kubernetes
cluster
it'll.
Let
you
see
different
resources
interact
with
different
resources
and
kind
of
be
a
more
visual
friendly,
cube
cuddle
in
the
last
year
and
a
half
or
so
we
have
completely
rewritten
the
front-end
to
go
from
angular
version,
1,
technically
angular
version
6
7.
A
We
have
built
in
metric
server
support
now
that
heap
ster
is
fully
deprecated
and
removed.
The
metric
server
support
still
hasn't
been
merged,
but
it
is
like
it's
going
to
get
merged
and
essentially
once
we're
back
from,
you
can
and
we
have
applied
and
gotten
to
students
for
the
google
Summer
of
Code
and
will
touch
on
what
they're
going
to
work
on
later.
On.
B
Yeah,
so
I
will
explain
some
basic
folder
structure
that
we
are
using
the
project
for
all.
That
would
want
to
start
to
contribute.
So
first
we
have
this
I/o.
We
basically
taken
that
from
the
angular
team,
so
it
contains
all
the
build
artifacts
scripts
and
configurations
that
we
are
using
to
build
start
and
deploy.
Also
the
project
so
deploy
contains
our
recommended
and
alternative
setup
for
the
dashboard
recommended
recommended
one.
Is
they
want
that
we
are
using?
B
We
recommend
it
because
of
the
security
reasons,
the
core
team,
basically
and
first
on
us
to
introduce
that,
because
by
default,
if
you're
using
this
setup,
it
will
be
secure.
It
will
not
allow
privileges
to
be
escalated
and
stuff
like
that.
Also
it
allows
you
to
log
in
and
the
alternative
setup
is
for
more
advanced
users.
So
if
you
want
to
use
some
proxy
out
proxy
or
some
kind
of
SSO
that
you
have
inside
your
system,
then
this
is
the
option
for
you.
B
We
basically
just
pass
some
header,
authentication
header
and
it
will
add
our
port,
we'll
just
do
that
up
for
you,
then
we
have
the
gulp
directory.
This
is
like
legacy
directory
because
on
the
first
version
of
dart
board
were
using
gulp
pretty
heavily
and
we
didn't
Mike,
we
did
migrate,
yet
all
the
stuff
that
was
in
the
gulp,
in
example,
building
the
our
back-end.
But
we
are,
we
will
try
to
do
that.
B
We
will
do
that
eventually,
and
the
scripts
are
the
new
way
how
we
handle
our
building,
glinting,
formatting
and
basically,
all
that
stuff
in
the
project
and
all
the
stuff
that
we
moved
from
gulp
is
in
the
scripts
folder,
it's
mostly
bar.
That
is
run
using
NPM
and
node
modules.
You
know
we
just
it
is
NPM
directory
that
we
use
as
a
vendor
in
directory.
So
if
you
are
NPM
CI,
which
is
like
recommended
command
to
run
right
now,
it
will
generate
it
for
you
and
all
dependencies
in
there.
C
Yes,
so
the
next
folder
is
a
Searcy.
It
contains
all
the
sources
of
the
application.
We
have
basically
decided
to
split
it
to
two
major
folders.
One
of
them
in
his
back
end
and
back
end
contains
all
the
sources
for
a
back-end
part
of
the
application,
because
dashboard
has
two
layers
and
one
of
them
is
back-end
which
interacts
directly
with
kubernetes
api
server.
C
We
use
it
to
fetch
all
the
data
to
perform
all
the
operations
on
it
like
sorting,
pagination
and
stuff
like
that,
and
then
we
sent
it
to
our
front-end,
which
is
located
in
front
in
directory.
Front-End
is
written
in
angular
7
at
the
moment.
So
we
try
to
stick
to
the
newest
version
of
angular.
We
are
using
angular
material.
All
the
source
files
are
there
at
the
moment
there
is
a
vendor
folder
located
in
root
directory.
It
contains
all
the
dependencies
for
back-end
files.
C
We
are
using
that
at
the
moment,
but
we
are
planning
to
change
it
to
to
use,
go
mods
like
kubernetes
does
and
in
the
next
files
are
go
package
definition,
which
contains
definitions
for
every
dependencies
that
we
are
using
in
the
background,
and
also
package.json,
where
we
are
defining
the
dependencies
that
we
are
using
in
front
end
and
also
scripts,
that
we
are
using
so
basically
NPM,
start
and
p.m.
test
track
and
stuff
like
that.
C
Yeah,
so
we
would
like
to
share
some
of
the
best
practices
that
should
be
used
if
you
want
to
contribute
to
our
project.
First
of
them
is
always
clear:
node
modules
and
NP
run
NPM
CI
before
checking
out
PRS.
If
it's
the
best,
because
sometimes
you
can
run
into
issues
with
style
dependencies
or
someone
introduced
it
and
introduced
new
dependency
and
yeah.
It
should
be
done
every
time.
B
Yeah
then
we
have
our
test
tests,
definite
scripts.
That
should
be
run
after
every
change.
So
when
you
finish
your
feature
just
run,
NPN
test
or
an
NPN
run
check
to
check
all
static
things
like
if
the
code
is
formatted.
If
it
follows
all
the
rules
that
we
introduced
while
in
tears
and
also
if
it
passes
all
the
tests
and
that
we
have
added
then
for
the
local
development
you
can
use
mini,
cube
or
kind
that
is
like
the
fastest
way
to
start
the
cluster
I
think
right
now
kind
is
just
like
one.
A
Very
good,
oh
sweet
last
but
not
least
smaller
PRS
or
better
PRS.
There
are
honestly
fewer
dashboard
maintained,
errs
that
then
we
would
like.
So
our
time
is
kind
of
precious
and
we
only
get
to
work
on
this
a
little
bit
out
of
the
day.
So
if
you
can
submit
smaller
PRS,
we
can
review
them
faster
and
give
you
feedback
faster.
A
A
A
Just
a
little
bit
of
background
about
kind
kind
is
the
utility
that
all
of
cig
testing
is
using
to
do
to
do
kubernetes
testing.
In
the
background,
if
you're
doing
a
PR
against
kubernetes
kubernetes,
it's
going
to
spin
up
kind
clusters
and
run
tests
in
the
background.
The
reason
for
that
is,
it
is
very,
very
lightweight.
The
kind
binary
itself
is
like
10
megabytes
and
the
only
other
thing
that
it
needs
is
the
image
in
this
case
I
think
I
am
running
an
older
version
of
kind.
A
So
it's
pulling
down
one
thirteen
four,
but
there
is
already
a
one
14
version,
so
you
can
actually,
with
different
configs
spin
up
multiple
kind
clusters
and
run
end-to-end
tests
against
multiple
versions
of
kubernetes,
and
that's
one
of
the
things
that
we're
looking
into
in
the
future.
So
we
have
already
just
spun
up
our
cluster.
Let's
get
the
cube,
config
path.
A
So
when
you
clone
down
the
dashboard,
there
is
a
folder
called
NPM.
R,
see
it
sorry,
it
specifies
a
bunch
of
different
defaults
for
configs
locally.
One
of
them
is
where
your
cube
config
is.
So
we
want
to
override
that
with
where
kind
is
put
its
cube
config,
and
since
we
are
already
in
the
dashboard
folder,
we
can
actually
do
NPM
start
now
that
it
knows
where
the
kind
config
is-
and
this
is
starting
up
simultaneously
the
front
end
in
the
backend.
A
I
forget
where
it
is
somewhere
in
here.
It
actually
shows
that
hey
it
is
using.
Is
it
further
now?
Thank
you
so
yeah
using
cube
config
file
keep
connect
kind.
So
what
this
is
doing?
It
Forks
and
spins
up
a
back-end
going
server
or
going
process
and
the
JavaScript
front-end,
and
when
the
JavaScript
front-end
spins
up
it
actually
needs
to
bundle
everything
before
it
starts.
So
technically
we
could
go
to
localhost
8080
and
then
it
would
just
show
you
a
white
screen
and
you
would
see
a
lovely
message
here
that
says
hey.
A
A
Magic,
this
is
how
I
personally
do
my
development
locally.
All
the
time
I
was
going
from
mini
cube
to
kind,
but
kind
is
a
lot
faster
for
me,
and
even
though
this
is
a
Mac
laptop
running
docker
in
a
VM,
I
have
a
desktop
running
Linux
and
it
goes
much
faster,
but
that
was
still
a
lot
faster
for
me
than
mini
cube,
so
didn't
realize
this
is
gonna
turn
into
a
kind
and
a
dashboard
demo,
but
it
did.
B
B
B
C
Of
the
most
important
changes
was
basically
changing
the
way
how
we
are
loading,
the
resources
on
grouped
views.
So,
for
example,
when
you
are
entering
world
portal
page,
we
are
no
longer
sending
one
big
request
for
everything
inside
cluster.
At
the
moment,
each
one
of
the
components
is
sending
its
only
request.
That's
why
the
pilot
is
loading
much
faster,
so
performance
should
be
a
lot
better.
At
the
moment
we
have
also
added
few
of
the
nice
things
like
dark
mode
can
be
used.
C
C
You
can
basically
take
the
tokens
and
stuff
like
that
at
the
moment.
I
think
application
should
be
a
bit
easier
to
use
or
for
new
people
and
yeah
we
are
finishing
it
at
the
moment
should
be
done
really
soon.
The
release
should
happen
in
one
month.
We
don't
know
if
it
will
be
alpha
or
beta
release
at
the
moment,
but
it
will
happen.
B
So
on
our
roadmap,
we
have
still
many
things
and
one
of
them
is
off
support
better
right
now
we
rely
basically
only
on
service
accounts
that
are
ready
that
you
can
create
in
kubernetes,
but
we
want
to
add
that
we
make
it
more
seamless
experience
for
new
users
and
without
too
much
configuration
we
would
like
to
do
it
without
much
configuration
so
that
beginners
can
also
benefit
from
that.
That's
why
we
also
did
not
do
that
before
and
we
were
waiting
for
the
API
server
also
to
introduce
some
changes,
and
we
have
see
other
support.
C
But
at
the
moment
we
have
two
students
working
on
google
Summer
of
Code
program,
and
one
of
them
will
be
working
on
custom
research
definition
support
for
dashboard
yeah,
so
we
are
looking
forward
to
that
will
be
also
converting
current
system
of
dependencies
for
back-end
from
that
to
go
mod.
So
we
wanted
to
follow.
Kubernetes
kubernetes,
core
team
here
and
we'll
be
introducing
plugin
system
and
plug-in
system
is
really
feature
that
it's
really
wanted
from
the
people,
because
they
want
to
customize
dashboard
in
their
deployment
and
we
plan
to
do
it.
C
Generic
and
this
will
be
the
feature
that
will
be
also
worked-
that
also
one
of
the
students
from
district
will
be
working
on
it
and
yeah
we'll
provide
support
for
them
and
we
also
will
begin
pruning
the
back
end
code.
At
the
moment
we
are
using
a
client
go,
but
we
are
not
using
all
the
features
that
it
provides.
C
B
Yeah,
so
this
was
already
mentioned
that
we
have
students
working
on
the
g'tok
project,
so
I
think
we
could
skip
that
and
for
all
of
you,
you
can
contribute.
We
have
labels.
That
is
the
most
perfect
for
the
contributors
for
good
first
issues
that
you
can
start
to
work
on.
They
are
simpler,
so
anybody
should
be
able
to
just
take
a
look
and
try
this.
B
Then
you
can
also
propose
new
features.
We
have
many
good
proposals
that
we
will
take
eventually
look
at,
but
this
is
just
not
that
many
people
we
have
to
work
on
that
and
you
can
also
review
peers,
because
this
also
takes
so
much
of
our
time
that
we
can
do
everything.
So
if
you
are
willing
to
just
review
something
or
ask,
if
you
have
any
questions
for
us,
you
can
always
ping
us
and
any
help
will
be
appreciated.
C
So,
basically,
if
you
know
go
JavaScript
or
whatever
that
we
can
use,
you
can
contribute,
you
don't
need
to
know
whole
project.
You
can
just
help
us
with
improving
the
backend,
improving
front-end,
changing
something
small,
changing
viki's,
because
you
know
how
to
set
something
up
and
all
the
help
will
be
for
us.
A
So
if
you
have
any
other
questions,
we
three
are
in
slack
all
the
time
and
the
kubernetes
slack
channel
cig
UI.
There
is
also
a
mailing
list
and
the
the
link
to
the
dashboard
repo
was
on
the
previous
slide.
But
it's
also
here
as
well.
If
you
have
any
questions
that
you
don't
feel
like
asking
right
now
feel
free
to
email
them
or
send
them
in
slack.
But
at
this
point
we
are
happy
to
take
questions
or
show
random
stuff,
because
I
think
we
have
like
ten
minutes
left.
C
A
C
As
we
can,
because
you
can
change
front-end
part,
you
can
change
backend
part,
so
it
can
be
very
complex
and
tricky,
and
what
we
would
like
to
focus
at
the
moment
is
prepare
really
good
architecture
for
that
have
a
good
idea,
perhaps
not
finish
all
the
implementation,
but
it
needs
to
be
specified
and
done
really
good
to
allow
other
people's
using
it.
So
it
must
work
not
only
with
one
application,
not
plugging
for
one
application,
but
for
multiple
Dragons
ideas,
so
yeah
I.
B
C
B
Can
add
something,
so
we
were
thinking
from
technical
side.
We
are
thinking
about
dynamic
compilation
of
also
front-end
and
partly
exposing
some
back-end
mechanism
that
could
dynamically
expose
some
end
points
also,
but
well.
There
are
many
like
tricky
things
like
security
in
here
and
privileges
for
the
plugins.
So
probably
also
we
will
introduce
some
Miam
or
something
configuration
that
user
will
have
to
provide
to
configure
all
this
security
stuff
and
maybe
on
watch
which
views
you
would
like
to
see
the
plug-in
how
it
works.
C
Think
the
cap
is
being
created
at
the
moment
and
yeah
we'll
review
it,
because
until
until
we
couldn't
accept
and
said
say
which
proposal
was
accepted
from
the
student,
we
couldn't
review
it.
But
at
the
moment
we
know
who
will
be
working
on
it
and
now
we
can.
We
can
start
to
work
so
proposals
were
accepted
like
one
or
two
weeks
ago,
and
it's
yeah
we'll
be
working
on
that
and
also
from
the
technical
side
there
is
user
can
create
it's
his
own
API.
C
A
From
a
usability
side,
you
know
we
we've
worked
a
lot
on
getting
metrics
server
support
going.
Ideally
that
goes
away
once
the
plug-in
system
is
built
and
we
can
just
tie
dashboard
directly
to
Prometheus
rather
than
having
a
shim
of
a
container
that
scrapes
the
metric
server
and
then
other
plugins
like
cloud
provider,
specific
plugins
could
potentially
be
built.