►
From YouTube: Improving User Experience For Device... - Alexander Kanevskiy & Patrick Ohly & Kate Goldenring
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Improving User Experience For Device Consumption In Kubernetes - Alexander Kanevskiy & Patrick Ohly, Intel & Kate Goldenring, Fermyon
Speakers: Patrick Ohly, Alexander Kanevskiy, Kate Goldenring
Kubernetes is powerfully declarative with YAML being the UX to request all that a workload needs. Kubernetes has tried to maintain this defining characteristic even as scenarios continue to expand. The device plugin interface was introduced to Kubernetes back in v1.10 to enable requesting and reserving static hardware for workloads, such as GPUs for ML applications. What about other devices used by workloads? This talk will cover several stories of how different types of the devices can be used in Kubernetes clusters: - From traditional datacenters to small IoT centric devices. - From exclusively accessed to shared devices. - From local stateless devices to network attached devices. - From simple single-purpose devices to pipelines of devices. All these scenarios require both a simple yet flexible UX for users to request a variety of devices with various properties. Alexander and Kate will discuss projects and proposals in the Kubernetes ecosystem that are working towards this goal of connecting devices and workloads. They will also discuss how to get involved in this evolution to let workloads be utterly materialistic. Whatever the app needs, it shall get.
A
A
Let
me
introduce
myself
I'm
Alexander
kanyevsky
I
work
for
Intel,
less
formally.
People
call
me
Sasha.
Why
I'm
here?
Why
I'm
talking
about
this
subject
is
because,
in
my
work
for
Intel
for
many
years,
I
was
involved
with
enabling
different
kind
of
accelerator
devices
and
with
all
of
that
activity,
I
am
also
co-chair
of
container
orchestrated
devices
working
group
under
tag
runtime
in
cncf
we
supposed
to
have
one
more
speaker,
Patrick.
Unfortunately,
in
last
moment
he
was
not
able
to
travel
so
reminder
to
everyone.
Keep
safe,
keep
healthy.
B
Everyone,
my
name,
is
Kate
goldenring
I'm,
a
software
engineer
at
fermion
and
I,
come
from
more
of
an
iot
background.
I'm
co-chair
of
the
cncf
iot
edge
working
group
and
I
was
the
maintainer
or
is
the
maintainer
of
a
project
called
awkary,
which
kind
of
answers
this
question
of?
How
do
we
bring
small
iot
devices
into
our
kubernetes
clusters,
which
we'll
talk
a
little
bit
about
today?
B
So
I
want
to
start
by
talking
about
the
evolution
of
kubernetes,
so
kubernetes
started
as
a
tool
to
orchestrate
workloads
across
servers
in
the
cloud,
and
this
environment,
as
you
can
see,
is
fairly
homogeneous.
All
these
servers
have
similar
static
system
hardware,
and
you
can
kind
of
compare
that
to
a
neighborhood
where
all
the
homes
have
the
same
set
of
features.
B
They
all
have
bathrooms
bedrooms
kitchens
and
your
choice
of
where
to
live
is
boiled
down
to
a
decision
of
how
many
of
each
of
these
three
features
do
I
need
to
make
that
choice
to
live
there,
and
this
is
comparable
to
kubernetes,
where
you
have
your
workload
or
your
pod
is
trying
to
choose
which
node
it
is
best
suited
to
live
on
and
in
kubernetes
out
of
the
box.
Those
features
of
those
resources
are
compute
resources,
namely
CPU
memory
and
huge
pages,
and
behind
the
scenes.
B
What
happens
is
once
you
request
that
amount
of
resources
in
your
pod
specs?
So
in
this
example,
this
streaming
app
needs
100,
megabytes
of
memory
and
10
CPU
units,
the
cubelet
on
that
node
will
say:
okay,
that's
reserved
for
you
and
we'll
ensure
that
you
do
not
exceed
a
limit.
Also
specified
make
sure
that
you
don't
use
more
than
a
certain
amount
of
resources.
B
B
It's
not
just
how
many
kitchens
bathrooms
and
living
rooms
do
I
need,
but
it's
also
do
I
want
Hardware
flooring
or
carpeting
and
kubernetes
had
to
evolve
to
meet
this
expectation
of
wanting
to
have
that
same
declarative
experience
around
what
a
workload
needs
for
a
more
of
varied
hardware
and
that's
where
the
kubernetes
device
plugin
framework
came
in
and
that
came
about
in
kubernetes
1.10
and
around
2017,
and
what
this
does
is.
It
enables
you
to
create
extended
resources,
so
new
node
level
resources
in
your
cluster
and
the
way
that
works.
B
B
So
in
your
pod
spec,
which
is
where
we're
saying
this
user
experience
for
kubernetes
and
devices,
is
you
want
to
be
able
to
request
a
GPU
there
so
on
your
cluster,
you
create
a
device
plugin
on
the
Node
that
has
a
GPU,
and
what
this
is
doing
is
saying:
hey,
cubelet
I
have
a
GPU
here,
tell
API
server
that
and
then
now
you
can
request
it
in
your
pod
spec
and
that
ensures
that
your
streaming
application
is
deployed
to
node
a
not
node
B
and
behind
the
scenes.
What
also
happens
here
is
the
device.
A
This
current
device
plugins,
it's
not
really
possible,
so
people
coming
up
with
different
kind
of
workarounds.
One
example
here
is
what
like
a
cluster
administrator,
statically
Provisions
with
node,
when
labels
were
node
with
particular
type
of
a
device
and
when
user
needs
to
know
the
cloud
specific
label
to
use
in
the
node
selector
saying
I
want
GPU,
but
I
also
want
to
have
it
this
kind
doable,
maybe
not
so
user
friendly.
A
Similar
second
example,
is
you
have
a
device
it's
expensive
but
like
if
you
do
a
long-running
job,
it
justify
the
cost.
But
if
you
have
like
multiple
data
science,
scientists
who
are
just
doing
something
in
notebooks
and
from
time
to
time
running
like
short
period
tasks
which
require
computation
power,
it
becomes
really
expensive.
So
people
who
are
thinking
of
how
we
can
share
one
physical
device
between
multiple
containers,
multiple
ports,
again
people
come
up
with
different
workarounds.
A
A
How
its
majority
are
you
running,
but
it
also
can
use
some
accelerator
and
imagine
what,
if
you
want
to
use
in
a
way,
what
give
me
accelerator
I
can
use
it.
If
you
don't
have
okay,
fine
I'm,
full
back
to
a
CPU
with
current
device,
plugin
apis
like
if
you
try
to
say,
like
my
request,
is
zero
for
crypto
accelerator.
But
limit
is
one
it's
not
going
to
happen
well,
admission
controller
will
fail.
A
Next.
Use
case
is
for
more
complex
devices,
where
example
of
fpga
field
programming,
gate
array.
So
it's
something
what
you
can
say:
I
want
this
particular
type
accelerator,
but
when
please
load
the
function
like
this
hour,
I
want
to
use
compression
next
hour.
I
want
to
use
like
some
crypto
acceleration,
something
else
involuto,
so
user
needs
to
say
two
two
things:
what
kind
of
card
plus
what
what
function
we
come
up
with
again
with
our
workarounds,
so
we
created
this
here.
This
which
describes
these
are
devices
bases
the
function
name.
We
can
map
them
together.
A
We
can
have
admission
web
hook,
which
mutates
your
portsberg
from
user,
visible
string
of
resource
request
to
something
like
cryptic,
as
you
can
see
like
it
works,
but
again
it's
for
end
user,
not
the
best
experience
if
he
needs
to
debug
something.
So
we
need
something
better
and
that's
like
local
devices
and
Kate.
You
know
something
about
the
iot
devices
and
age
devices.
B
Yeah
so,
as
Alexander
mentioned,
there's
ways
that
people
are
using
param
trying
to
get
parameters,
optionality
and
sharing
with
local
devices
with
the
device,
plugin
interface
and
some
workarounds.
For
that
another
space
that
people
are
trying
to
expand.
The
idea
of
devices
in
kubernetes
is
iot
devices.
B
So
we
wanted
to
be
able
to
dynamically
say:
I
want
this
IP
camera
we
found.
We
can't
put
a
cubelet
on
the
camera
so
out.
How
else
could
we
bring
that
camera
into
the
cluster
and
in
general,
when
you're
trying
to
expand
the
functionality
of
kubernetes?
You
have
two
options.
You
can
either
build
a
kubernetes
operator,
which
is
something
that's
deployed
separately
of
kubernetes
and
it's
basically
a
custom
resource
definition.
The
word
resource
is
very
overloaded
in
kubernetes,
but
a
declaration
of
State
essentially
and
a
controller,
something
that's
reconciling
that
state
that
you
want.
B
The
other
option
is
to
amplify
kubernetes
itself
and
there's
a
process
for
that.
It's
a
kubernetes
enhancement
proposal
and
you
work
with
the
community
to
do
that,
and
it
requires
a
clear
understanding
that
this
is
something
that
everyone
needs
and
it's
a
very
important
issue
to
bring
to
kubernetes.
So
we
went
with
the
operator
model.
B
It
really
aims
to
abstract
away
the
details
of
device
Discovery
and
use
in
kubernetes
and
device
once
again
overloaded
term,
but
in
this
sense
those
iot
really
small
constrained
devices,
and
so
what
it
does
is
it'll
discover
the
devices
whether
across
the
network
or
locally
on
a
node
or
attached,
and
it
will
create
device
plugins
on
your
behalf.
So
instead
of
you
having
to
create
a
device
plugin
for
each
type
of
device,
you
have,
it
will
create
them
on
Discovery.
B
So
you
immediately
have
these
new
node
level
resources
and
then
it
also
can
optionally
deploy
workloads
for
you
immediately
afterwards,
and
if
we
look
at
once
again
the
yaml
user
experience
of
this,
we
have
a
second
piece
of
yaml.
Here
we
have
our
custom
resource
definition
and
in
ocri
that's
an
awkward
configuration,
a
very
simple
way
to
say
that
helps
you
configure
what
you
want
to
find,
and
in
that
configuration
you
say
what
you
want
to
find
by
specifying
what
protocol
you
want
to
use
to
find
that
device.
B
So,
once
you've
applied
this
to
your
cluster,
auquery
will
find
it
tell
the
cubelet
about
it
and
all
of
a
sudden,
you
have
these
other
resources
that
you
then
can
add
to
your
pod
spec.
So
now
you
can
see
here.
We
now
have
an
IP
camera,
we're
requesting
in
our
pod
spec
and
if
we
look
at
the
flow
of
this,
similarly,
the
first
thing
you
do
is
you
apply
awkward
to
your
cluster.
B
So
this
is
an
operator,
so
you
have
kubernetes
first
and
then
you
add
your
Helm
chart,
which
is
awkward
and
once
you've
applied
that
to
your
cluster.
You
then
tell
awkary
what
you
want
to
find
so
we're
back
at
that
configuration
creation
stage,
and
here
we're
saying
on
Biff,
because
we
see
that
IP
camera
and
we
want
to
find
it
and
then
akri
finds
it
and
it
represents
that
device
as
a
kubernetes
resource.
B
So
it
tells
cubelet
about
it,
which
tells
the
API
server
about
it,
and
then
it
also
creates
our
second
custom
resource,
which
is
an
awkward
instance
and
that
instance
helps
akri,
understand
the
device
and
regulate
the
use
of
the
device
across
nodes,
because
this
is
a
shared
device.
It's
not
physically
attached
to
OneNote,
it's
shared
by
multiple
nodes
and
then
once
again
you
can
go
in
and
create
your
pod
spec
apply
it
to
your
cluster.
And
now
you
have
your
streaming
application.
B
That's
using
that
camera
and
one
thing
to
note
about
the
device
plugin
interface
I
hinted
at
this
earlier,
but
when
you
allocate
a
pod
to
a
node,
what
happens?
Is
the
cubelet
basically
calls
into
the
device
plug-in?
So
it's
calling
into
awkward
and
saying
Hey
I
want
to
run
this
this
pod
here
and
it's
using
this
device
that
you're
controlling
and
then
you
and
then
it
also
asks.
Is
there
anything
else.
I
should
give
it,
and
so
here
we
say:
yes,
here's
some
connectivity
information.
B
B
So
it
immediately
knows
which
one
to
connect
to
and
can
start
doing,
the
work
that
I
was
intending
to
do
and
if
you
don't
want
to
create
that
pod
spec
yourself
to
with
point
to
the
exact
camera,
you
can
also
have
aquery
optionally,
deploy
the
workload
on
your
behalf
and
that's
just
in
the
extra
section
of
the
configuration
called
the
broker.
Spec,
so
here
we're
just
saying
every
time
you
discover
the
device,
every
node
that
can
see
it.
B
It
gets
this
workload
and
if
we
look
at
the
instance
more
in
detail,
so
this
is
the
representation
of
the
device
for
awkary.
You
can
see
how
it
handles
that
resource
sharing.
So
when
we
created
this
configuration
in
this
example,
we
said
only
three
workloads
are
allowed
to
use
this
device
at
once.
So
we
set
device
usage
to
three.
B
So
that
means,
if,
for
you,
try
to
deploy
four
pods
to
use
this
device,
one
of
them
will
not
run
because
that
resource
is
not
is
only
available
to
three,
and
so
that
helps
with
not
overloading
these
shared.
These
shared
iot
devices
and
you
can
also
see
their
under
broker
properties-
that's
what's
injected
as
environment
variables
to
any
workload
that
requests
it
and
so
back
to
what
could
be
better.
The
user
experience
so
awkward's
pretty
imperative
if
you're
choosing
to
create
your
own
pod
specs.
So
you
can
see
here
on
the
right.
B
You
have
to
specify
exactly
what
camera
that
aquery
discovered
and
created
the
instance
for
you
want
to
use.
Ideally,
you
could
be
a
little
bit
more
descriptive
in
your
pod.
Spec
say:
I
want
the
robot
arm.
That's
moving
fast
or
I,
want
the
precise
robot
arm
and
being
able
to
do
that.
All
in
the
Pod
spec
would
be
what's
ideal,
with
awkward
we're
getting
closer
to
a
more
generic
pod
spec
experience.
B
We
have
some
proposals
out
there
for
that,
and
that
would
be
through
changing
the
way
our
controller
works
and
if
you
use
that
to
deploy
the
applications
on
your
behalf,
you're
able
to
have
more
of
a
generic
experience,
but
there's
still
a
ways
to
go,
and
one
of
the
exciting
things
about
the
way
that
kubernetes
is
evolving
is,
as
Alexander
will
explain.
There's
now
a
kep
to
kind
of
change,
some
of
the
ways
that
we're
using
these
devices-
and
we
could
even
see
offery
being
put
on
top
of
that
which
is
dynamic,
resource
allocation.
A
A
So
we
try
to
step
back
and
think
what
will
be
ideal
or
more
extensible
way
to
specify
the
devices
in
kubernetes
would
be,
and
just
for
you
to
understand
what
kind
of
scenarios
we
are
trying
to
address.
We
are
trying
to
address.
First
of
all,
separation
of
claim
of
advice,
describing
I
want
this
and
here's
my
list
of
parameters,
and
you
have
a
name
for
it.
A
You
have
unique
ID
for
it
and
when
you
have
multiple
containers,
so
multiple
ports,
which
can
you
reference-
and
you
can
say,
okay
for
this
allocated
device,
now
I'm
going
to
use
it,
and
this
separation
allows
us
to
cover
pretty
much
everything.
What
we
can
imagine
right
now
so
like
two
ports
using
two
devices
at
the
same
host,
maybe
network
devices,
two
ports
sharing
one
device,
two
container
within
one
portrait
in
one
device
or
like
any
other
kind
of
things
like
multiple
ports,
sharing
multiple
devices
splitted
dynamically.
A
Instead
of
like
statically
I
showed
in
a
previous
example,
devices
might
be
interconnected.
Those
ports
might
be
running
on
different
machines
if
there
is
a
fabric
between
web
devices
like
outside
of
kubernetes
and
so
on.
So
this
is
what
our
working
group
is
actually
trying
to
do
and
the
process
for
it
is
not
fast.
A
So
all
of
those
discussions
started
between
Like
Us
in
Intel
and
Nvidia
like
almost
four
years
ago,
when
the
key
point
in
time
was
kubecon
North
America
in
San
Diego,
where
we
had
a
round
table
people
from
different
projects
like
Ronald
from
cryo
myself,
Mike
Brown
from
IBM
from
containerd
Renault
from
Nvidia.
We
said
together
and
and
said:
okay,
let's
think
how
devices
will
look
like
in
the
future
result
was
creation
of
container
orchestrated
devices
working
group
in
2020.
A
A
What
device
actually
means?
So
you
get
ID
like
Nvidia
gpu0
and
when
you
have
a
file
just
on
schemat
to
describe
what
this
Nvidia
GPU
is.
Actually
this
device
node
or
this
set
of
device
node.
These
volume
mounts
with
libraries
with
set
of
hooks
and
so
on.
So
all
the
implementation
details.
What
couplet
should
not
know
about,
and
while
it
works
on
the
low
level,
so
you
can
use
it
in
Port
one
you
can
use
it
in
current
run
times.
A
We
need
some
how
to
expose
it
to
end
users
like
to
report
spec
and
the
second
part
is
dynamic
resource
allocation.
It's
recap
what
my
colleague
Patrick
his
primary
driving
together
with
our
community
members,
like
I,
already
mentioned
on
previous
slide,
like
Nvidia
folks,
Kevin
and
I,
even
on
our
side,
they
had
Christian
and
many
hours.
So
we
are
trying
to
get
this
cap
done
in
a
way
what
you
will
get
more
possibilities,
more
flexibility,
how
to
use
the
devices
details
on
that
cap.
A
So
if
you
know
the
storage
world,
you
probably
know
we
the
pattern
we
are
trying
to
use.
You
have
a
claim.
You
have
a
parameter.
This
claim
can
be
as
a
separate
object.
This
claim
can
be
templated
inside
your
pod
spec,
where
actual
allocation
again
it
might
be
immediate.
It
might
be
like
once
ones
who
Port
arrived
so
delete
allocation,
but
the
thing
is
all
right:
you
get
the
clean,
you
specify
it
and
when
you
specify
what
my
container
is
going
to
use
wet
clean,
what
is
a
small
differences?
A
Well,
maybe
not
so
small
differences
how
it's
actually
implemented.
So
we
don't
have
a
separation
like
in
storage.
We
have
PVC
and
PV.
Here
it's
one
object:
it
has
all
the
status
information
all
we
can
all
the
communication
between
scheduler
between
the
driver,
which
implements
risk
claim
it
all
handles
through-way
API
server,
just
updating
patching
with
this
object
and
wet
simplified
life
and
simplified
implementation
of
I
think
a
lot.
A
Another
big
difference
is
set
of
parameters,
so
in
PVS
you
have
parameters
embedded.
So
when
you,
the
core
object
inside
the
kubernetes
API,
enforce
a
sound
set
of
fields
which,
which
is
needs
to
be
present
like
size
and
so
on.
Here
we
try
to
do
it
more
genetically,
so
the
parameters
are
stored
in
separate
object
and
you
have
a
possibility
to
reference
like
core
objects
like
config
Maps,
but
you
also
can
reference
your
series
and
your
sear.
This
Hema
can
actually
specify
which
parameter
some
undatery.
A
What
kind
of
types
those
parameters
needs
to
be,
and
so
on
so
again
for
your
driver,
we're
trying
to
give
you
as
much
flexibility
as
possible
how
it
looks
in
reality.
You
know
current
implementation,
so
this
is
example
of
board
spec,
which
has
embedded
claim
you
see
two
containers,
one
of
the
containers
is
actually
references.
I
want
to
use
a
my
resource
and
down
below
you
see
the
template
of
description
of
my
my
resource.
A
It
says
resource
class,
something
it
says,
parameters
and
has
a
pointer
the
type
of
object,
config
map
it
could
be
your
service
and
the
name
where
these
parameters
are
located.
Those
two
objects
is
example.
Here
is
what
class
is
mapping
where
the
name
of
a
resource
class,
what
you
have
in
your
cluster
to
actual
driver
implementation?
So,
for
example,
like
vendorfu
can
have
a
like
with
driver
for
GPU
and
you
can
have
like
gold,
GPU,
silver,
bronze,
GPU
and
so
on
handling
by
the
same
driver.
A
A
My
pull
request
right
now
is
open
for
review.
Hopefully
it
will
be
merged
soon,
but
who
knows,
the
pull
request
is
quite
big
because
we
need
to
touch
many
of
the
components
in
the
system
like
API.
Obviously,
the
controller
manager,
because,
like
it
handles
a
lifetime
of
embedded
claims
objects.
We
need
to
touch
scheduler
to
teach
him
how
to
how
to
use
this,
like
API
server
as
a
backend
to
to
talk
to
the
drivers.
A
It's
not
that
complex
or
not
wet
scary,
as
it
might
sound,
so
how
it
affects
the
vendors
vendor.
Obviously
don't
not
going
to
use.
We
need
to
re-implement
support
for
the
device.
It's
not
a
device
called
Unit
users
who
is
completely
separate.
Api,
you
implement
something
similar
what
Kate
described
in
in
a
career,
so
you
need
to
implement
your
controller,
which
knows
the
logic
for
your
device,
your
location
logic,
your
Discovery,
your
resource
tracking,
a
node
component,
is
simple
piece
of
code
documentation
how
to
use
it
as
well.
A
But
again
it's
not
that
scary
as
it
sounds
from
our
side.
What
what
we
are
doing
is
we
are
providing
the
helper
libraries,
which
is
part
of
the
pull
request.
What
I
mentioned
we
provide
with
test
driver
which
is
going
to
be
used
in
entry
test.
We
have
another
example
of
more
complex
driver
from
our
fellow
travelers
from
Nvidia.
A
It
really
allows
vendors
to
expose
all
the
features
of
Hardware
without
spending
too
much
time
or
complicating
too
much
code
of
core
kubernetes
so
with
I
would
like
to
say
please
if
you
are
interested
in
particular
like
enabling,
with
devices
or
just
using
the
devices,
please
join
our
communities
like
we
have
nice
ugly
Community
for
iot
devices.
We
have
generic
tag
run
time.
Our
container
Orchestra
working
group
please
reach
to
us
myself,
Kate
Patrick.
A
C
A
Yes,
absolutely
so
it's
not
something
what
will
immediately
replace
with
Device
plugins
device,
plugins
still
stays,
so
it's
just
a
new
API
which
allows
you
to
a
bit
different
usage
of
devices.
So
if
you
have
some
device,
which
you
are
happy
with
very
simple,
like
beam
counting
of
like
I
have
one
device
so
now
otherwise
another
device
and
I
don't
care
like
more
detailed
property
of
them
device.
Plugin
is
perfect
for
it
use
it.
A
The
question
is
like
it's:
it's
more
where,
as
a
device
vendor
you,
you
would
like
to
go
what
we
know
from
the
feedback
from
Nvidia
colleagues.
This
is
the
way
where
we
want
to
go
because
we
already
collected
a
certain
technical
depth.
Over
the
years
we
collected
certain
user
stories
which
we
cannot
solve
with
existing
scenarios
or
it's
more
expensive
for
them
to
to
solve
with
existing
device
plugins.
They
would
migrate
to
that
as
soon
as
it
will
become
available.