►
From YouTube: What If... Kubernetes Core Pieces Could Be Extended with... Rafael Fernández López & Flavio Castelli
Description
What If... Kubernetes Core Pieces Could Be Extended with Pluggable WebAssembly Modules? - Rafael Fernández López & Flavio Castelli, SUSE
One of the most common use cases for WebAssembly are plug-in systems. We think this approach could be beneficial for many Kubernetes core parts. Thus, we decided to make Admission Controllers the first stop of this evolutionary journey. Kubernetes built-in controllers cannot cover all the scenarios an organization has. Therefore, Dynamic Admission Controllers are offered to have a flexible way to extend the core capabilities. These components run outside of the API Server, with the network sitting in between the source of the events and the code doing the actual evaluation. This increases latency and makes the final outcome less certain because new failure scenarios are introduced. That effectively means Dynamic Admission Controllers are less predictable than their built-in counterparts. This talk will show a prototype that leverages WebAssembly as a way to add custom controllers to the API Server. These components will be as predictable as the built-in ones. Moreover, this approach is useful for edge deployments too because it leads to more lightweight environments. This solution releases computation resources for the end user workloads running on constrained edge locations.
A
B
B
So
inside
of
this
room,
there
are
many
of
you
that
are
already
playing
experimenting
with
webassembly
building
cool
things.
Many
of
you
are
already
using
webassembly
to
build
functions
and
service
platforms.
This
is
a
fantastic
use
for
it.
Others
might
have
used
web
assembly
as
a
way
to
implement
plug-in
system.
So
you
take
an
existing
program
and
then
you
grow
it
by
using
plug-ins
to
add
new
features,
new
capabilities,
but
this
time
the
plugins
are
going
to
be
delivered
as
web
assembly
modules.
B
B
You
can
bring
your
own
scheduler,
you
can
bring
on
dynamic
admission
controllers,
and
this
is
the
last
point
the
dynamic
and
mission
controller.
This
is
what
we
are
going
to
be
talking
about
today.
So
kubernetes
has
some
addition,
admission
controllers
that
are
built
into
its
own
binaries
think
about
pot
security.
But
if
you
want
to
implement
new
rules,
then
you
have
to
resort
to
dynamic
admission
controllers.
They
work
in
this
way.
B
This
is
a
proven
technology
that
is
being
used
by
many
projects.
Many
open
source
projects
such
as
open
policy,
agent,
gatekeeper,
kaiver
now
and
last
but
not
least,
cuborden,
which
is
an
open
source
project
that
I
contribute
to
it's
a
project.
We
we
submitted
to
cncf
for
for
inclusion
instead
of
sandbox.
B
What
makes
keyboarding
different
from
from
the
other
projects
I
mentioned
is
the
way
of
writing
and
distributing
policies.
So
in
the
keyboard
and
case
you
can
take
a
regular
programming
language
or
you
can
use
rego,
which
is
the
query
language
introduced
by
open
policy
agent,
and
then
you
compile
this
policy
into
a
webassembly
module,
but
then
is
distributed
using
a
container
registry
and
then
is
executed
by
a
web
book
server.
B
Our
web
book
server,
which
is
capable
of
running
web
assembly-
and
you
know
it-
has
a
plugin
system
based
on
webassembly
that
allows
it
to
gain
more
and
more
policies
to
be
to
be
run.
So
this
is
something
that
is
working
it's
working.
Well,
we
are
pretty
happy
about
our
decision
to
embrace
webassembly
for
for
this
task,
but
I've
always
been
thinking
about
what,
if
you
know,
we
could
reuse
part
of
this
ideas
of
keyboard
and
straight
into
the
kubernetes
control
plane.
B
What
if
we
could
actually
run
policies
that
we
define
inside
of
the
control
plane,
making
them?
Basically,
like
admission
controllers,
you
know
the
ones
that
are
bundled
inside
of
it,
but
without
having
to
submit
all
this
custom
code.
For
our
you
know,
customer
specific
needs
into
the
upstream
kubernetes
repositories.
B
So
the
idea
basically
is
to
make
the
api
server
aware
of
webassembly
and
make
it
leverage
computational
units
written
using
webassembly
basically
have
a
sort
of
function
as
a
service
platform
inside
of
the
api
server,
which
is
there
to
evaluate
incoming
requests
about
and
use
policies
while
doing
that.
So
why
would
we
be
doing
that?
You
know
what
do
we
gain
from
doing
that?
I
think
there
are
a
couple
of
advantages.
So,
first
one
is
we
get
a
more
predictable
outcomes
when
evaluating
policies?
B
That's
because,
with
dynamic
admission
controllers,
the
api
server
is
reaching
this
web
book
server
and
then
is
is
waiting
for
an
answer
which
could
be
accept,
reject
mutate
or
it
could
be
nothing
so
a
timeout
or
it
could
be
an
http
status
code.
So
this
is
the
kind
of
unplanned
failures
that
you
have
to
take
into
account
when
you
register
a
web
book-
and
this
is
where
this
setting
about
failure
policy
is
going
to
determine
what
what
happens.
What
has
to
be
done
by
the
api
server.
So
you
can
pretend
like
nothing.
B
B
The
other
reason
is,
I
don't
know
about
how
you
feel
about
that,
but
you
have
kind
of
a
gut
feeling
that
a
lot
of
resources
inside
of
kubernetes
clusters
are
actually
used
to
run
infrastructure
code,
not
user
workloads,
so
take,
for
example,
the
keyboard
and
stack.
We
have
a
web
book
server,
which
is
there
waiting
for
requests
to
be
evaluated.
It
could
be
doing
a
lot
of
request,
processing
or
it
could
be
sitting
idle.
It
all
depends
on.
B
You
know
the
amount
of
load
that
you
have
on
the
on
the
on
the
infrastructure,
how
many
requests
are
being
sent
and
made
against
against
the
api
server
and
at
the
same
time
you
have
a
controller
which
is
there
doing
its
own
reconciliation,
loop
against
custom
resources,
and
it
could
be
doing
a
lot
of
reconciliations
or
it
could
be
doing
just
nothing.
So
what?
If
we?
Could?
You
know
get
rid
of
those
two.
B
You
know
pieces
of
a
stack
and
just
have
the
policies
being
run
on
demand
function
as
a
service
inside
of
the
api
server.
I
think
this
would
be
great
for
certain
scenarios.
Certain
environments
where
resource
usage
is
really
important,
think
about
edge
scenarios
where
you
have
limited
hardware
and
you
have
to
make
the
best
use
of
it
and
the
best
use
of
it
is
to
leave
as
much
space
as
possible
for
user
workloads.
So
if
we
go
ahead
with
this
experiment,
this
is
what
we
we
can
allow
our
our
users
to
to
do
so.
B
The
the
idea
that
we're
going
to
explore
and
that
I
actually
implemented
with
this
proof
of
concept,
is
to
basically
run
webassembly
policies
inside
of
of
api
server.
Now
big
disclaimer,
I
don't
know
how
this
is
going
to
end.
I
mean
this
is
working,
but
this
is
a
big
change.
Maybe
people
will
be
completely
against
that
and
I
get
it,
and
so
I
didn't
want
to
invest
too
much
time
and
and
energies
into
into
that.
I
don't
want
to
maintain
a
downstream
fork
of
kubernetes
just
to
have
this.
This
feature.
B
That
means
I
try
to
reuse
as
much
as
possible
from
the
keyboard
and
project,
because
we
have
plenty
of
web
assembly
policies
ready-
and
I
know
the
stack
so,
but
that
doesn't
mean
that
you
know
if
we
decide
to
go
further
with
this
poc,
it
doesn't
mean
that
we
have
to
embrace
the
world
keyboard
and
primitives
and
and
stack.
So
that
being
said,
what
I
have
done,
I
have
introduced
a
new
feature:
gate
inside
of
kubernetes
that
is
capable
of
running
this
keyboard
and
policies
capable
of
downloading
them
from
container
registries.
B
So
let's
see
that
in
action.
So
here
I
have
a
simple
k3s
cluster
made
by
just
one
node,
which
is
running
only
the
the
vanilla
k3s
stack,
so
there
is
no
keyboard
in
there.
This
is
a
patched
version
of
k3s,
but
as
the
feature
gate
I'm
talking
about
turned
on
and
this
feature
gate
I'm
talking
about.
It
has
its
own
configuration
file.
So
let's
take
a
look
at
that
here,
you
can
see
that
we
are
defining
one
policy
which
is
called
privileged,
which
is
being
downloaded
from
this
container
registry.
B
B
The
next
policy
we
have
over
there
is
called
trusted
repos,
and
this
one
is
interested
about
pod
events.
Creating
the
update
is
enforced
inside
of
a
default
namespace
as
well,
and
this
is
this
is
going
to
reject
the
containers
that
are
coming
from
the
docker
up.
So
if
you
try
to
create
a
pod
which
has
a
container
coming
from
the
docker
up,
this
policy
will
prevent
you
from
doing
that.
B
So,
let's
see
these
policies
in
action,
so,
first
of
all
we're
going
to
try
creating
a
privileged
container
inside
of
a
default
namespace,
and,
as
you
can
see,
this
is
being
rejected.
It
is
being
rejected.
We
get
back
a
notification
from
the
from
the
api
server
in
the
very
same
way
we
would,
with
with
a
dynamic
admission
controller.
B
Now,
let's
try
to
create
a
container
that
is
using
an
an
image
from
the
docker
app
the
alpine
image
and
again
the
creation
is
going
to
be
rejected
this
time
by
the
other
policy
we
have
enforced,
so
just
to
prove
you
that
this
can.
This
is
actually
working.
Let's
try
to
create
a
privileged
pod,
but
this
time
into
a
different
namespace,
the
task
namespace
and,
as
you
can
see,
the
creation
happened.
That's
because
the
policies
are
enforced
only
inside
of
the
default
namespace.
B
B
A
A
Well,
we
thought
about
maybe
logging
doing
something:
fancy
with
logging,
maybe
even
before
getting
into
them
into
memory
or
even
when
it's
at
rest.
So
if,
if
an
attacker
gets
into
your
machine,
they
cannot
even
get
the
locks
from
your
node.
Even
if
it's
on
memory
nah,
it
doesn't
sound
so
important.
I
mean
it's
important,
but
it
doesn't
sound,
so
cool
for
a
blue
of
concept,
authenticate,
authentication
or
authorization.
A
Well,
you
already
have
the
authenticating
proxy
yeah.
It's
not
super
nice
contouring
manager,
it's
just
a
controller.
Maybe
yes,
but
nah
garbage
collector
strategies.
You
can
use
finalizers
with
that
add
your
finalizer
whenever
you
want
and
then
delete
it
afterwards,
when
you
want
so
you
you
can
control
garbage
collection
in
the
end,
even
on
different
name
spaces
wherever
you
want
so
yeah,
it's
not
so
nice
and
yeah.
Maybe
it's
something
fancy
with
cd,
but
in
the
end
it's
just
grpc,
so
I
can
just
put
something
in
in
front
of
it
or
even
something
completely
different.
A
As
long
as
I
implement
the
grpc
protocol
and
that's
it
so
it's
like
yeah,
maybe
the
control
plane.
We
cannot
get
that
much
done
with
webassembly
right
now
thinking
out
of
of
of
the
top
of
our
head,
and
so
we
looked
also
thinking
about
the
data
plane,
so
control
pane
data
plane.
We
see
lots
of
different
people
doing
really
really
nice
stuff.
We
have
translate.
We
have
run
wassi
that
allows
you
to
run
wazi
modules.
On
container
d,
we
have
wasa
meds.
A
We
have
a
lot
of
different
things
and
we
are
talking
only
about
cube,
and
that
is
related
stuff
here,
where
you
can
run
out
of
kubernetes.
So
you
have
a
lot
of
things,
but
then
you
get
a
little
more
into
the
data
plane
like
what
we
understand
is
that
and
we
have
emboy
and
linker
d,
and
I'm
just
going
to
pick
up
two
examples
from
them.
So
with
emboy,
you
can
run
that
website.
You
can
run
with
assembly
today
on
your
http
filters.
A
The
thing
is
that,
and
this
this
is
something
we
see
right
now
on.
Almost
every
project
that
is
using
webassembly
is
that
you
need
to
provide
the
local
file
name,
the
local
file
name,
where
this
webassembly
module
is
or
you
can
provide
an
http
server.
Honestly,
I
didn't,
I
didn't
look
if
it
checks
for
for
certificates,
if
you
can
use
see
a
specific
cas
from
your
system,
but
in
any
case
there
is
something
clear
here
that
the
way
do
you
distribute.
A
A
A
A
If
I
know,
I
don't
know
if
you,
if
you
looked
for,
if
you
know
about
crew,
so
crew
is
the
package
manager
for
cube
ctl
and
basically
it
was
like
what,
if
we
try
to
build
something
that
is
crew,
wasn't
where
you
can
write
your
cube,
ctl
plugins
with
watson-
and
this
is
what
we
did
actually
most
of
the
work
has
been
done
by
fabio.
So
thank
you
for
that,
and
you
know
we
are
distributing
the
policies
as
we
are
doing
with
keywording
today
with
oci
distribution.
A
This
is
written
in
rust,
and
so
this
is
basically
what
we
use
for
using
oci
registries
in
order
to
distribute
the
wasm
modules
over
there
and
so
right
now
we
brought
two
plugins.
I
am
only
writing
this
one.
That
is
the
decoder,
and
this
one
is,
is
a
wasm
plugin
and
it's
a
wasi
in
the
it's
a
washi
program
in
the
sense
that
it
has
its
main.
It
has
everything.
So
it's
it's
it's
a
it's
a
full,
let's
say
was
it
program
and
then
there
is
the
second
one.
A
That
is
what
flavio
was
referring
to
as
the
easter
egg,
and
if
what
do
you
saw
that
he
ran
at
the
very
end,
keeps
it
l
keyword
and
was
actually
actually
a
clue
was
implying.
So
this
is
actually
you
know
working
and
we
are
really
happy
about
it.
So,
what's
better
than
one
demo,
it's
two
demos.
So
let
me
check.
A
A
A
A
So
now,
let's
create
one
secret
and
the
not
so
secret
things,
the
not
so
secret
thing
about
giving
the
secrets
is
that
they
are
not
really
secret.
So
what
I'm
going
to
show
is
how
we
can
show
the
contents
of
the
secret
itself,
so
I'm
going
to
create
one
with
keep
ctl
and
you
know
username
password
and
then
I'm
going
to
show
that
with
json
okay,
we
have
the
base64
over
there.
A
That's
fine!
So
now
I'm
going
to
run
the
qctl
decoder
plugin
that
I
just
downloaded,
and
this
is
going
to
show
the
contents
of
my
secret
current
secret.
So
you
can
see
that
and
it
shows
you
know
more
information
in
a
table.
So
it's
pretty
cool
and
also
what
happens
if
I
show
kubernetes
tls
type
secret
directly.
So
the
decoder
knows
that
and
it
will
show
this
in
a
different
way,
which
is
well
actually
I'm
showing
these
cities
from
kipp
ctl.
A
Yeah
and
they're,
showing
here
that
actually
the
keyboard
and
plugin
that
flavio
showed
before
is
the
other
plugin
that
we
support
and
that's
it
I
didn't.
I
don't
have
the
keyboard
and
installation
that
he
has
where
we
are
registering
events.
I
don't
even
have
keyboard
installed
here,
so
it's
going
to
be
an
empty
output
but
yeah.
That's
that's
the
idea.
A
A
So,
what's
nice
about
wassi
today,
so
the
really
cool
things
is
that
you
know
it
has
a
with
x
definition.
This
is
going
to
be
imported
to
wheat
soon.
I
think,
then
we
have
primitives
that
are
super,
useful
clock
file,
descriptor
primitives,
environment
variables,
command
line
parameters
and
also
initial
socket
support.
We
cannot
create,
as
we
were
saying
before,
we
cannot
create
outbound
connections,
but
we
can
create
inbound
connections.
We
can
listen,
and
so
we
have
inbound
socket
support,
and
this
is
this
is
really
cool,
and
you
know
what's
what's
next.
A
So
as
I
was
saying
network
connections,
we
have
wheat.
That
is
what
is
coming
after
after
the
wheat
x
and
yeah.
That's.
Basically,
it
also
saw
that
there
is
an
argument
limit
when
we
are
using
wheat
binding.
This
is
going
to
be
lifted
as
well,
because
this
this
will
change
with
a
new
binary,
so
this
is
going
to
be.
A
This
is
going
to
be
fulfilled
and
this
is
not
going
to
be
our
problem
anymore,
and
one
thing
that
I
love
about
these
examples
is
that
your
plugins
actually
are
complete
programs
in
the
sense
that
they
are
actually
going
to
try
to
say
they're
going
to.
They
are
reading
whether
you
have
provided
an
environment
variable
called
config
or
not.
If
you
don't
have
a
provided,
cube,
configurable
variable
it's
going
to
try
to
find
that
on
your
home
and
then
we
are
mounting
the
home
directory.
A
We
just
have
the
exports
and
we
call
to
that
and
then
we
do
a
lot
of
stuff
inside
of
the
guest,
which
is
super
nice,
because
you
know
going
always
marceline
and
marceline
some
json
are
putting
and
putting
that
to
the
to
the
host,
and
then
the
house
will
do
whatever
it
has
to
do.
You
know
we
can
do
better
than
that,
and
I
think
we
are.
We
are
doing
really
good
progress
there.