►
From YouTube: Resize Your Pods In-Place With Deterministic eBPF Triggers - Pablo Chico de Guzman & Vinay Kulkarni
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.
Resize Your Pods In-Place With Deterministic eBPF Triggers - Pablo Chico de Guzman, Okteto & Vinay Kulkarni, Futurewei Technologies
Cloud-native community has long desired the ability to resize pods in-place because pod restarts are expensive for long-running applications and disruptive to services. To resize pods, we commonly rely on Vertical Pod Autoscaler (VPA) to observe usage, recommend, and reactively enact resource updates.
An alternative approach is to resize pods based on deterministic events. For example, you can capture events with eBPF to detect when a CPU-intensive command is going to be executed, and proactively resize the pod CPU accordingly. In this talk, Pablo will show an interesting use case where remote development environments run inside pods. These pods need minimal resources when a developer is writing code, but need significantly higher CPU & memory when a developer issues a “build” command or runs a battery of tests. In-place resize is mandatory in this scenario, otherwise, the development experience would be broken on every pod restart.
Vinay will then talk about the current in-place pod resize feature design, which is soon landing as alpha in Kubernetes. He will go over the CRI changes, discuss the design rationale & trade-offs. He will then lay out the next steps and discuss what the community can do to help to drive this feature to a rock-solid GA over the next year.
A
B
A
Cool,
so
this
is
the
agenda
of
the
talk.
We
are
going
to
introduce
the
idea
of
cloud
native
development
environments,
the
problems
that
they
solve
and
also
some
of
their
challenges.
One
of
them
is
to
make
them
cost
effective,
so
we
will
analyze
the
different
challenges
there
and
then
we
will
introduce
a
feature
coming
soon,
it's
in
place,
but
resize,
and
the
idea
with
this
feature
is
that
you
can
modify
that
request
and
the
limits
of
a
running
Pod
without
restarting
the
bottom.
A
After
that
we
will
see
a
demo
using
in
place
battery
size
and
evpf
to
optimize
the
infrastructure,
utilization
of
cloud
native
development
environments,
and
we
will
finalize
with
some
takeaways
okay.
So
let's
talk
about
Cloud
native
development
environments
and
first,
let's
see
the
current
state
of
the
Earth.
A
Okay,
so
most
companies
are
moving
to
kubernetes
and
microservices
for
the
right
research
right.
They
solve
many
problems
in
production
environments,
but
they
also
come
with
some
challenges,
and
one
of
them
is
that
they
make
make
it
harder
to
mimic
your
production
environment
in
your
local
deaf
environment,
even
with
tools
like
Docker
local
kubernetes
distributions,
like
mini
Cube.
You
need
to
install
this
software
run
all
these
micro
services,
so
there
are
several
issues
there.
A
One
of
them
is
that
you
may
run
out
of
CPU
and
memory
in
your
laptop,
so
things
go
very
slow
or
even
stop
working.
You
need
to
maintain
local
configuration.
So
if
there
is
something
wrong
in
your
Dev
environment,
it's
very
difficult
to
replicate
the
same
problem
in
other
laptop
or
it's
very
hard
for
anyone
else
to
troubleshoot.
What
is
the
issue
and
if
you
are
using,
for
example,
multi-repo,
it's
not
trivial
to
orchestrate
the
build
pools
and
deploy
of
all
these
containers
running
locally.
A
So
what
most
people
do
is
to
assume
an
environment,
disparity
between
deaf
environments
and
production
and
I
think
this
is
wrong
because
at
the
end,
what
you
are
doing
is
Shifting
right.
Your
testing
efforts.
Ideally
a
developer,
should
be
able
to
deploy
a
deaf
environment
and
test
end-to-end
all
the
changes
that
they
are
doing
before
even
sending
a
bull
request.
A
But
if
you
are
not
able
to
do
that,
you
need
to
send
a
PR
wait
for
the
continuous
integration
job
to
validate
your
changes
or
even
worse.
You
need
to
merge
and
wait
for
an
staging
or
intelligent
environment
to
be
a
credit
and
then
do
the
final
end-to-end
tester,
and
if
there
is
an
issue,
you
need
to
start
again
work
on
your
local
deaf
environments
and
a
PR
and
all
those
things.
So
all
this
cycle
reduces
the
developer
productivity,
a
lot
and
also
the
developer
happiness.
A
So
the
solution
that
we
propose
is
cloud
native
development
environments,
and
this
is
a
high
level
view
of
this
methodology.
The
idea
is
to
have
a
single
kubernetes
cluster
served
by
all
the
Developers,
and
every
developer
is
working
on
a
different
name
space
and
you
can
have
as
much
isolation.
You
need
between
them
spaces
using
the
standard
kubernetes
objects.
A
So
the
idea
is
that
on
each
name,
space
the
developer
is
able
to
deploy
a
full
replica
of
the
application,
which
is
much
more
realistic,
because
this
is
running
in
kubernetes.
With
your
hand,
chats
using
your
network
configuration
security
policies,
the
same
thing
that
you
do
in
production
and
it's
fully
replicable,
because
it
doesn't
depend
on
your
local
configuration.
A
You
should
be
able
to
deploy
any
commit
from
any
git
repository
and
everything
happens
in
the
cluster
in
the
cloud.
So
it
doesn't
depend
on
your
local
configuration
and
anyone
in
your
team
can
go
there
and
check
it
out
because
it's
available
for
everyone,
so
in
order
to
adopt
this
methodology,
is
very
important
that
for
the
developer,
the
deaf
experience
is
the
same,
and
to
do
that
there
are
several
open
source
projects
like
potato
the
presence
deal
garden
and
many
more
and
more
or
less.
A
The
goal
of
these
Dev
tools
is
to
provide
this
experience,
so
the
developer
keeps
working
locally
on
their
IDE
and
the
application
is
hot
reloading
on
remote
immediately
and
you
can
even
set
configure
your
debater
set
breakpoints
and
all
those
things.
So
that's
key
for
developer
adoption.
If
you
need
to
change
the
developer,
workflow
people
listen
are
not
going
to
adopt
it,
but
with
these
tools
you
can
have
a
realistic,
applicable
and
and
fast
iteration,
remote
Dev
environments.
A
So
that's
the
solution
and
I'm
going
to
talk
about
one
of
the
problems
with
this
approach
and
is
that
you
need
to
run
all
these
environments
in
the
cloud
and
it
could
be
an
impact
in
your
Cloud
wheel,
right,
which
is
skd,
but
good
news
is
that
kubernetes
is
very
good
to
optimize
resource
allocation.
That
means
that
all
the
containers
running
in
the
same
node
they
may
serve
the
CPU
and
the
memory
available
in
the
node.
A
So,
for
example,
if
you
are
building
your
application
and
you
need
a
spike
for
CPU
and
memory,
the
memory
and
the
CPU
of
the
node
is
available
for
your
container
and
when
you
are
done,
the
same.
Cbr
memory
is
available
for
other
containers,
so
that
is
very
helpful
to
optimize
your
infra
utilization
and
also,
if
you
need
more
nodes
in
your
cluster,
the
cluster
will
allow
the
scale
up
and
down
as
needed
automatically.
A
A
So
that's
good,
but
for
development
is
a
little
bit
different.
What
usually
happens
is
that
when
the
application
is
booting,
you
need
more
CPU
and
memory
to
boot,
your
to
put
a
strap
your
your
application
and
then
after
a
while
in
development,
you
don't
usually
have
that
many
incoming
requests
right.
So
after
a
while,
you
need
less
CPU
and
memory
to
keep
your
application
running.
A
A
So
for
the
make
Command
you
need
more
CPU,
but
the
vertical
product
of
the
scalar
is
reactive.
So
there
is
a
delay
between
you
start
using
more
CPU
and
until
the
BB
and
the
vertical
product
was
killer,
updates
the
the
request
of
the
pot.
So
in
this
case
I
don't
have
in
in
a
in
enough
requests
here
to
run
my
main
command,
then
the
requests
have
updated,
but
I'm
not
using
this
CPU.
Here
then,
the
vertical
product
Skillet
update
the
request
again
and
I
don't
have
two
CPUs
available
for
the
main
command.
A
A
So
what
we
did
is
an
adult
solution,
for
this
is
a
custom
scheduler
basically,
and
with
that
solution
with
I
don't
have
time
to
talk
about,
but
with
that
solution
we
were
able
to
run
AP
boards
per
node
without
affecting
the
developer
experience.
So
this
is
huge.
It's
10x,
infra
savings,
and-
and
there
is
a
lot
of
potential
to
solve
this
problem
properly.
Our
other
solution
is
not
ideal.
A
It
requires
a
lot
of
effort
to
maintain
the
solution
and
to
configure
the
solution
for
different
customers,
but
it
shows
us
the
potential
of
solving
this
problem.
So
the
question
is:
if
there
is
a
better
way
to
solve
this,
and
with
that
in
mind,
I'm
gonna
pass
to
Rene
to
talk
about
in
place
for
resize
and
PDF.
B
B
Okay,
well
not
exactly
light
speeds,
we're
being
extra
cautious
and
there
are
good
reasons
for
that.
The
pr
is
big
and
it
touches
critical
components
and
kubernetes
and
mistakes
can
be
costly,
so
it's
imperative
that
we
stage
it
in
a
responsible
way.
What
really
matters
is
that
we
get
across
that
finish
line.
B
If
you
guys
are
really
nice
to
me,
I
will
leave
this
PR
to
you
in
my
will:
okay
enough
grief
for
my
PR.
So
let's
take
a
look
at
what
really
changed.
The
first
thing
we
did
was
we
made
you
have
the
container
spec,
and
that
is
the
resources
field.
We
made
it
mutable
for
CPU
and
memory
when
you
do
that.
What
it
lets
you
do
is
it
lets.
B
You
update,
send
a
patch
to
your
pod,
spec,
saying:
I
want
the
container
I
started
out
with
one
CPU,
but
I
want
two,
thus
you're
expressing
desired
resources
for
the
Pod
and
then
kubernetes
goes
to
work.
Doing
what
it
does
best,
which
is
you
know,
get
the
actual
State
equal
to
the
desired
state.
So
with
that
with
the
ability
to
specify
a
desired
state
of
resources,
we
need
a
way
to
Signal
the
user
who's
specified
the
request.
B
What's
the
status
of
their
request,
and
for
that
we
introduced
a
new
field
called
resize
in
the
Pod
status.
This
status
holds
one
of
these
four
values.
When
you
have
a
pending
request
for
resize,
the
interesting
one
is
in
progress
where
which
should
be
the
default
case.
That
means
that
the
kublet
was
able
to
allocate
the
memory
or
CPU
that
you
wanted,
and
it's
working
on
it
with
the
runtime
to
make
it
happen
proposed.
As
the
initial
state
where,
when
your
API
server
looks
at
your
request,
it
makes
sure
that
the
request
is
valid.
B
B
So
that's
a
signal
that
you
may
need
to
evict
your
pod
and
ask
the
scheduler
to
schedule
a
new
instance
to
another
node
where
you
can
get
five
CPUs
and
deferred
is
the
case
where
the
node
has
six
CPUs,
but
another
pod
is
using
two
CPUs
there
and
it's
possible,
but
just
not
now
it's
your
choice.
Do
you
want
to
wait
or
do
you
want
to
evict
and
get
five
CPUs
elsewhere?
B
We
added
a
couple
of
more
Fields
the
resources
allocated
field
in
the
container
status.
It's
a
persistent
way
of
telling
what
is
it
that
the
in
the
in
progress
pod
status
is
driving
towards
and
the
resources
field
in
the
container
status?
I
know
there
are
a
lot
of
these
fields
in
here,
but
the
resources
field
in
the
container
status
tells
you
the
actual
State,
as
reported
To
Us
by
the
runtime.
So
that's
what
is
actually
on
the
container
on
your
containers.
B
Lastly,
we
have
a
new
field
called
resize
policy.
This
was
introduced
for
one
reason:
there
are
some
Legacy
applications
where,
like
Java
applications
which
are
using
the
xmx
flag,
they're
not
able
to
take
advantage
of
increased
capacity
of
the
Pod
without
restarting
it's
just
the
those
applications
need
them.
So
you
have.
We
want
to
give
the
users
a
way
to
specify
hey.
This
is
my
application
needs
to
be
restarted.
B
B
So
what
does
it
really
involve?
I
touched
upon
this
earlier
we
have
changes
to
the
API
server,
cubelet,
scheduler
and
runtime.
There
is
a
lot
to
go
into
here,
but
I
will
focus
on
one
thing:
the
kublet,
so
cubelet
admission
of
a
resize
request
is
interesting
here,
because
this
PR
introduces
a
new
race
condition
where
the
resize
request
is
racing
with
a
pod
that
may
just
have
been
scheduled
to
that
node
and
kublet
is
the
ultimate
Authority
and
it
will
it's
a
gatekeeper.
B
Going
to
one
of
the
best
ways
to
really
look
at
how
this
works
is
to
go
through
it
step
by
step.
So
let's
do
that
now.
Consider
this
example
here.
What
we
have
here
is
a
node
where
you
have
a
pod
with
40
Milli
CPUs
allocated
to
it.
Now
you
desire
to
give
it
80
Milli
CPUs.
So
it
starts
with
a
patch
to
the
Pod
spec.
The
API
server
validates
this
spot
spec
the
patch
and
then
updates
the
object
store.
In
this
case,
we
update
the
hcd.
B
Now
the
next
step
is
watch
is
triggered
for
the
scheduler
and
kubelet.
The
scheduler
takes
that
looks
at
that
watch
and
updates
its
podcast
and
uses
that
to
do
the
do
the
max
of
desired
and
actual
so
that
it
doesn't
compete
with
resize.
That's
going
that's
in
progress,
and
in
this
case,
let's
assume
that
the
kublet
was
able
to
successfully
allocate
the
the
resources
that
was
requested,
80
Milli
CPUs,
so
it
does
the
admit,
pod
resize.
B
Now,
in
this
case,
we
are
increasing
the
CPU,
so
the
Pod
C
Group
C
group
settings
are
initial,
are
set
first
and
then
it
goes
and
talks
to
container
D
the
runtime
via
the
update
container
resources,
CRI
API,
asking
containerdy
to
allocate
80
Milli
CPUs
for
the
pods
containers,
and
now
the
container
d
goes
to
work.
It
updates
the
configuration
for
the
Pod
and
next
time
a
container
status.
Cri
API
comes
in
it
reports
back
to
the
group.
Let's
say:
yes,
your
pod.
B
Its
containers
have
80
Milli
CPUs
that
triggers
a
generation
of
update
status,
update
to
the
Pod
where
it
patches
the
power
status,
saying
the
resize
is
now
complete.
The
Pod
has
80
Milli
CPUs
and
we
have
come
full
circle.
So
that
is
the
happy
golden
path.
Now
one.
There
is
a
Nuance
to
this.
That
I
want
to
touch
upon
your
pod
may
have
more
than
one
container
and
you
may
be
resizing
more
than
one
container.
B
At
the
same
time,
you
may
be
giving
more
resources
to
some
and
taking
more
taking
resources
away
from
other
containers
in
all
these
cases.
What
we
do
is
we
order
the
resize
such
that
the
decreases
for
container
resize
are
done
before
the
increases
are
invoked
and
if
there
is
a
net
increase
to
the
Pod
C
group
values
due
to
the
resize,
then
the
part
c
groups
are
ordered
first
and
then
the
containers
are
resized
and
vice
versa.
B
Why
is
this
important?
Let's
take
the
scenario
you
have
a
system
where
you
have
two
gig
of
memory
available
to
the
pods,
and
you
have
one
single
pod
running
on
that
system.
It
has
two
containers
there.
They
take
one
gig
each
and
we
desire
to
give
C1
.5,
gig
and
cut
memory
for
C2,
make
it
0.5
gig.
Now
the
Pod
hasn't
changed.
B
The
pods
resources
are
the
same,
but
if
we
did
C1
and
then
C2,
we
are
oversubscribed
and
this
request
will
fail
and
the
Pod
will
end
up
in
a
bad
state
for
this
reason
that
we
want
the
runtimes
to
not
only
support,
update
container
resources,
CRI
API,
but
do
so
in
a
synchronous
and
transactional
manner.
If
we
don't
do
this,
then
the
downstream
request
to
update
the
policy
groups
might
fail
and
the
Pod
will
be
in
a
bad
State
and
when
I
say
synchronous
and
transactional.
B
What
I
mean
here
is
that
don't
queue
a
task
and
say:
okay,
I
will
apply
this
later.
We
need
that
a
or
nay
whether
it's
succeeded
or
it
failed,
and
if
it
failed.
What's
the
reason
for
failure
in
the
context
of
that
update
container
resources,
CRI
API
call
one
other
thing
that
got
introduced
to
the
to
The
Container
status.
Cri
API
is
a
resources
field.
B
This
is
what
allows
the
container
runtime
to
tell
us
to
tell
kublet
what
resources
are
actually
configured
on
the
pod,
I
guess
you're,
starting
to
see
why
this
feature
is
a
little
complex
right
and
lastly,
there
is
C
group
V2.
It's
here.
More
and
more
OSS
are
shifting
to
C
group
V2.
There
are
a
bunch
of
desirable
features
to
this.
For
us
in
particular,
we
are
interested
in
the
ability
to
specify
memory
requests
at
the
container
level.
We
did
not
have
that
in
C
group
V1.
B
There
is
another
talk,
I
believe
it's
on
Friday,
it's
by
David,
Porter
and
Ronald
Patel
about
C
group,
V2,
I
highly
recommend
attending
that
if
you
can
okay,
so
this
is
the
fun
stuff
we.
What
can
we
do
with
ebpf
for
in
place
boundary
size
as
Pablo
has
laid
out?
We
have
a
problem
here.
We
have
the
use
case
here
with
the
remote
Dev
environments.
There
is
this
workload
where
there
are
spikes
and
the
reactive
approach
that
we
have
with
vpa
is
not
good
enough.
So
how
do
we?
How
can
ebpf
help?
B
B
What's
interesting
here
is
that
when
we
look
at
the
requests,
the
resources
that
we
have
requested,
we're
requesting
four
CPUs,
which
is
good
enough
to
you,
know
edit
code
and
build,
but
we
have
curated
and
cherry-picked
a
value
of
50
meg
for
memory
that
is
sufficient
to
edit
code
and
edit
code
with
a
lightweight
editor
like
VI,
but
not
enough
to
build.
If
you
try
to
hit
the
make
Command
with
this
much
of
memory,
the
ohm
killer
will
come
along
and
take
care
of
things.
B
B
You
go
to
the
node
on
which
the
Pod
is
running
and
tell
python.
Hey
run
this
for
me
and
you're
set
looking
more
closely.
There
are
two
parts
to
it.
The
first
is
the
abpf
code
itself.
This
code
attaches
to
the
exact
exec
ve
system.
Call
that's
the
system
call
through
which
all
the
commands
in
the
system
that
are
executed
go
through.
You
do
LS,
it
goes
for
exec,
you
do
make.
It
goes
through
LS.
B
That's
it
it's
very
simple:
isn't
it
well
not
so
much
this?
The
only
good
thing
about
this
code
is
that
it
fits
on
one
PowerPoint
slide.
It's
it's
very
inefficient.
Everything
that
you're
doing
in
the
system
is
getting
traced
to
a
trace
file.
I
actually
tried
it.
It's
really
slow
and
it's
of
limited
use,
so
you're
in
your
container
you're,
happily
writing
codes.
Somebody
else
doesn't
make
another
container
and
you
resize
that's
not
great
right.
B
So
let's
do
something
a
little
less
dumb
for
the
demo.
So
BPF
also
offers
this
facility
of
maps
which
is
a
way
for
talking
to
the
appf
program
and
having
it
be
more
configurable
than
this.
What
we're
going
to
do
is
we're
going
to
use
the
BPF
maps
to
tell
the
abpf
program
to
focus
on
only
specific
containers
and
in
that
container
focus
on
specific
commands.
How
do
we
do
that?
B
The
containers
have
C
group
ID,
so
we
specify
the
C
group
ID
as
a
key
in
the
bbp
in
the
ebpf
maps
and
in
the
value
we
specify
the
list
of
commands
that
we
are
interested
in
tracing
this
will
let
us
only
trace
the
commands
from
the
containers
that
we
are
interested
in
that's
good.
But
how
does
the
user
tell
this
to
us?
Well,
we
resort
to
the
good
old
annotations.
B
We
have
defined
annotation
called
abpf
resize,
which
contains
cname
the
container
name
that
we're
interested
in
and
the
commands
that
we're
interested
in
in
this
case
make,
and
of
course,
what
do
you
want
to
resize
to
so
we
specify
these
three
things
with
these
three
things.
The
Pod
Watcher
thread
or
process
can
configure
the
BPF
maps
and
the
program
can
trace
exactly
what
we
need
with
that.
B
All
we
need
to
do
is
initiate
the
resize
when
we
see
the
trace
and
of
course
we
are
lazy,
kubernetes
people
we
are
going
to
go
to
each
node
and
say:
hey
python,
run
this
code.
Hey
python,
run
this
code,
we're
going
to
ask
kubernetes,
do
it
we
added
a
Daemon
set
and
kubernetes?
Does
the
hard
work
for
us?
B
B
Can
everyone
see
the
the
terminal
screens?
Okay,
all
the
way
in
the
back?
This
is
the
hardest
part
to
get
okay,
great.
Okay.
What
you're,
looking
at
here
is,
is
a
local.
All.
These
terminals
are
sshed
into
a
local
VM
called
abpf
resize
and
we're
running
a
local
kubernetes
cluster.
A
local
cluster
here
with
In-Place
bodary
size,
feature
gate
enabled
that
means
we
can
resize
our
pods
without
restarting
the
power
or
containers.
B
The
first
step
is
to,
of
course,
deploy
the
build
pod
and
I'm
doing
that
here.
With
this
yaml
deployed
it's
going
to
take
a
moment
there.
It
is
so
we
have
the
Pod
running
here.
The
good
build
pod.
We
can
exec
into
this
part
edit
code
and
build
code,
and
we
have
this
window
up
here-
shows
the
stats
it's
using.
It's
using
600.
B
600
KB
it's
using
under
1B
MB
of
memory,
and
then
you
have.
We
can
do
one
more
thing
here.
We
get
the
cube,
build
pod
in
Json
format
and
query
the
status
resources
allocated
the
new
field
that
we
introduced
for
this
feature.
That
tells
us
what
the
cubelet
has
allocated
for
your
pods
pod
and
its
containers.
In
this
case,
we
are
focusing
on
the
build
container.
That's
container
zero.
B
Now,
let's
take
a
look
at
let's
edit
some
code,
so
I'm
going
to
exec
into
the
build
part
and
LS.
This
is
the
kubernetes
125
release
branch
that
I've
gotten
the
Pod
for
this
demo
get
status,
shows
us
that
if
you're
looking
at
the
memory
values,
we
are
at
42
Meg
it's
under
what
we.
So
we
have
50
we're
under
that
and
we
use
the
lightweight
editor
like
vim
and
edit
some
code.
B
B
Let's
try
there's
one
way
to
find
out,
so
it's
going
to
run
really,
oh,
so
it
got
killed.
Well,
that
was
fast.
This
is
expected
right.
We
have
50
meg
and
make
is
trying
to
allocate
more
than
50
and
we
just
don't
have
it
and
the
ohm
killer
came
along,
came
along
and
pretty
much
told
us
to
go,
kick
rocks.
B
So
what
can
we
do?
We
have
choices.
We
have
options
we
can
use.
We
can
schedule
the
Pod
with
five
gig
and
you
won't
have
to
worry
about
it.
Of
course,
your
bank
account
won't
be
happy
and
you
could
use
you
could
rely
on
vpa
when
vpa
sees
this
events
out
of
memory
events,
it
will
resize
the
Pod
for
you,
but
it's
not
great
developer
experience,
so
there
is
another
way.
Fortunately,
let's
take
a
look
at
what
ebpf
can
do
for
us.
B
So,
with
this
command
I'm
going
to
deploy
the
Daemon
set,
it's
going
to
show
up
here.
It
takes
a
moment
to
initialize.
Now
it's
running,
we
can
know
that
the
program
is
up
and
running
by
looking
using
the
BPF
tool
to
list
the
map
entries
so
I'm
going
to
run
that
again.
So
there
is
a
map
entry
here
now
we
can
get
into
the
details
of
this
by
doing
a
dump
of
this
map,
entry.
B
67.,
so
what
we
see
here
is
a
key
one,
four,
seven,
five,
two,
that
is
the
C
group
ID
of
this
container,
in
which
I
just
executed
the
make
Command,
which
you
know,
got
killed
by
ohm
killer
and
it's
telling
the
BPF
program
hey.
If
you
see
this
container
execute
a
make
Command
then
please
trace
it.
So
now,
let's
try
this
again,
let's
see
if
it
works.
B
Oh
keep
an
eye
on
this
window,
the
top
left
top
right
corner
window
with
the
15
Meg
value,
that's
being
watched
as
I
hit
the
make
Command.
Here
we
go
so
we're
at
five
gig
and
the
container
seems
to
be
happy.
It's
allocating
whatever
it
needs
and
the
make
is
making
much
better
progress
than
it
did
before,
so
that
my
friends
is
the
magic
of
ebpf
for
you.
B
B
We
we
want
the
run
times
to
be
able
to
support
in
place
resize
if
you're
working
with
runtime
or,
if
you're
a
maintainer.
Please
consider
adding
support
for
In-Place
resize
to
your
runtime.
We
don't
want
the
user
to
have
to
worry
about
whether
whether
this
works
with
my
runtime
or
not.
We
want
it
to
just
work.
It
shouldn't
even
be
something
that
people
think
about.
B
We
have
one
more
slide
to
go
and
it's
the
one
that
everyone
is
waiting
for.
The
title
says
it
all
right.
So
please
scan
this
QR
code.
It
will
take
you
to
a
place
where
you
can
live.
You
can
leave
feedback
for
us
and
please
tell
us
what
you
found
useful
and,
more
importantly,
what
we
could
do
better
and
we
love
to
hear
from
you.
We
love
the
feedback
so
and
thank
you
for
being
here.
Thank
you
for
being
such
a
great
audience.
It's
been
a
pleasure
with
that.
I
will
conclude
this
talk.