►
From YouTube: Kubernetes WG IoT Edge 20220615
Description
June 15 meeting of the Kubernetes IoT Edge Working Group. Container Orchestrated Device Working Group on the Container Device Interface and dynamic resource allocation KEP - Alexander Kanevskiy (Intel), Patrick Ohly (Intel). K0s approach to air-gapped edge environments - Jussi Nummelin (Mirantis)
A
A
B
The
work
split
is
basically
that
Sasha
has
been
driving
the
underlying
container
device
interface
work
that
has
been
progressing
several
container
runtimes
Now
supported
what
it
does
is
essentially
giving
a
container
orchestrator
like
kubernetes,
an
ability
to
inject
additional
devices
environment
variables
into
a
container
in
a
in
a
fairly
generic
format.
I,
don't
have
too
many
details
about
that
because
it's
been
moving
along
fine,
but
what
contentious
part
right
now
of
a
work
that
actually
needs
that
that's
really
leading
attention
right
now
is
the
dynamic
resource
allocation
and
scheduling
part
that
I've
been
working
on.
B
That's
where
we
are
taking
CDI
at
the
lower
level
and
try
to
think
about
what
a
kubernetes
API
might
look
like
that
actually
takes
advantage
of
these
new
capabilities
and
run
times,
and
it's
clearly
related
to
the
current
device,
plugin
API
and
its
limitations,
because,
as
you
know,
in
Agri
it
it
does
have
its
limitation.
It's
it's
supposed
to
be
used
for
node
local
resources.
You
have
workarounds
for
that
in
Agri.
B
B
B
B
B
So
our
approach
from
a
design
perspective
is
based
on
communication
through
the
API
server
by
updating
the
resource
claim
status.
That's
the
shared
scratch
space,
basically,
where
the
different
components
store
their
state
and
communicate.
What
the
current
state
of
a
resource
game
is
whether
it's
allocated
whether
it
needs
needs
to
be
allocated
for
for
a
certain
port
or
for
a
certain
node.
All
of
that
is
handled
by
the
resource
claim
status
and
the
results,
because
the
resource
claim
is
also
a
separate
object.
B
It
can
be
referenced
by
multiple
Parts,
however,
at
the
same
time
or
one
after
the
other.
So
if
you
have
a
complex
device,
that's
hard
to
set
up,
then
it
might
be
beneficial
to
just
have
a
resource
claim
created
once
for
that
device
and
then
amortized
for
cost
of
setting
up
that
device
by
running
multiple
Parts
against
it.
As
as
needed
later
on.
B
B
You
have
a
provisioner
which
is
a
resource
driver
that
handles
this
resource
class,
and
then
the
resource
claim
has
the
parameters
that
the
user
is
allowed
to
choose,
which
may
be
num
amount
of
ram
that
it
that
it
needs
from
a
GPU
or
for
an
fpga,
which
kind
of
program
is
supposed
to
be
pre-programmed
into
it,
and
then
the
port
spec
needs
to
be
extended
because
we
really
can't
use
the
existing
resource
fields
to
handle
resource
claims.
There's
nothing
where
we
could
reference,
but
we
could
use
an
annotation,
but
that's
not
a
proper
kubernetes
API.
B
So
we
are
proposing
to
have
something
new
in
reports
back
and
have
this
property
supported
by
core
kubernetes.
That's
that's
the
key
difference
compared
to
something
done
out
of
tree
with
annotations.
We
are
really
aiming
for
something
that
will
be
supported
by
your
future
kubernetes
out
of
a
box
and
ideally
also
will
become
a
requirement
for
a
conformant
cluster.
B
Secrets
are
not
part
of
your
official
API,
but
they
don't
need
to
be.
In
my
opinion,
these
can
be
additional
parameters
provided
as
part
of
the
driver
installation
in
in
some
custom
parameters,
some
custom,
tierd
or
or
just
really
the
parameters
that
the
the
deployment
of
the
resource
driver
itself
takes
the
content
for
pod
pod
parameters
or
programmer
parameters.
B
The
user
doesn't
well
well.
Yeah.
I
can
see
some
cases
where
these
parameters
might
be
something
that
the
user
needs
to
specify,
because
it's
his
credentials
that
can
be
handled
by
the
custom
parameters
that
the
resource
driver
supports.
We
we
fully
support
custom
parameters
with
crds.
That's
the
latest
iteration
in
the
cap,
where
the
resource
driver
creates
a
crd
that
describes
which
parameters
it
accepts.
That
needs
to
be
in
a
separate
object,
because
that's
how
crds
work
and
then
the
resource
claim
doesn't
actually
embed
the
parameters.
B
It
references
this
external
object
and
that
object
then
can
have
user
supplied
credentials
or
secrets
to
actually
get
access
to
a
resource,
and
that's
that's
outside
of
a
cap,
because
we
don't
make
any
assumptions
about
what
the
parameters
mean
they
get
published
and
referenced
in
the
in
in
kubernetes.
We
expect
resource
drivers
to
be
kubernetes
specific,
so
it's
not
as
generic
as
CSI
is.
We
don't
have
plans
to
support
other
container
orchestrators
simply
to
keep
it
yeah
to
keep
to
keep
it
simple
it.
This
is
kubernetes
specific.
So
what
what
a
resource
Drive
event?
B
Does
it
basically
watches
for
these
parameter
objects
and
can
take
whatever
it
needs
to
know
from
there?
We
don't
need
it
need
to
pass
it
through
some
generic
component,
like
we
do
in
in
CSI
with
a
sidecars.
It
is
a
bit
simpler
in
that
regard,
as
you
mentioned,
you
work
on
on
resource
claims,
I
also
decided
to
merge
resource
claim
and
persistent
or
persistent
volume
claim
and
persistent
volume
into
one
object
that
solves
quite
a
few
race
conditions
that
still
exist
nowadays
for
volumes
where
a
volume
might
leak.
B
A
B
B
It
implies
that
there
will
be
more
API
calls
to
update
that
state,
which
is
kind
of
one
of
the
objections
that
I'm
getting
from
the
reviewers,
that
this
is
putting
a
higher
load
on
the
API
server.
But
it
also
at
the
same
time,
is
more
secure
because
we
can
rely
on
hcd,
storing
an
atomic
update
and
not
losing
that
state,
and
it
also
protects
against
concurrent
modifications
of
that
same
resource
claim.
B
So
yeah,
that's
what
we
are
currently
discussing
in
the
dynamic
resource
allocation
Camp,
it's
under
review,
that's
I!
Think
that's
on
my
status
slide.
Let
me
perhaps
show
how
we
envision
this
whole
thing
to
be
implemented.
So
we
do
have
four
kubernetes
changes
that
we
need
to
make
as
part
of
the
cap
implementation,
there
will
be
a
new
controller
manager
or
controller
inverter
controller
manager
that
handles
embedded
resource
claims.
That's
modeled
again.
B
After
what
I
did
with
generic
FML
inline
volumes
for
for
volumes,
it's
the
exact
same
concept,
a
pot
spec
describes
everything
that
it
needs
from
a
resource,
but
then
the
controller
creates
the
actual
resource,
claim,
object
and
the
rest
of
the
components
almost
never
sees
or
needs
to
do
anything
with
the
embedded
information.
It
will
still
work
on
on
the
normal,
separate
resource
claim,
and
that's
also
where
we
store
the
updates
and
the
state.
B
Then
the
scheduler
needs
a
new
resource
plugin.
That
knows
that
a
port
that
reference
the
resource
claim
can't
be
scheduled
unless
the
resource
has
been
allocated
and
reserved
for
the
Pod.
These
are
two
separate
things
where
you
have
resource
claims.
That
might
be
persistent,
so
they
are
allocated,
but
they
are
not
really
assigned
to
that
to
the
part
that
needs
that
currently
wants
access
to
it
and
it
might
not
be
able
to
get
exclusive
access,
because
some
other
part
is
is
also
trying
to
get
that.
So
the
schedule
needs
to
know
about.
B
Where
can
I
run
the
Pod
checks
and
at
the
end
it
decides
that
there
might
be
some
suitable
nodes
and
it
will
try
to
allocate
the
resource
claim
for
both
nodes.
But
this
might
not
go.
Raw
right
might
not
go
well
because
it
had
outdated
information.
So
there
is
a
feedback
loop
described
in
more
detail
in
the
cap,
where
it's
trying
again
elsewhere.
Until
eventually,
everything
is
is
ready
for
report
and
only
then
part
of
the
pot
gets
scheduled
I.
Think
in
the
cab.
B
I
was
discussing
with
Kate
with
the
archery
handles
that
scenario,
and
we
make
we
may
come
back
to
that
later,
because
I
think
there
is.
There
are
some
challenge
with
doing
the
same
thing
with
Device
plugin
interface,
because
Cube
scheduler
has
an
incomplete
view
of
what
the
extended
resources
really
mean
if
they
are
shared
between
nodes.
But
let's
not
discuss
that
now.
It's
let
me
just
finish
here
and
let's
describe
the
resource
driver,
let's
see
out
of
tree
component,
so
couplets
when
it
sees
a
part
it.
B
It
needs
to
know
how
to
inject
and
where
to
get
the
CDI
description.
The
CDI
files
CDI
is
based
on
Json
files
to
describe
operations
where
the
container
runtime
needs
to
do
involves
files
get
created
by
the
resource
driver
on
the
Node
when
a
pod
is
scheduled
to
report
into
the
node
and
the
the
cubelet
needs
to
call
a
prepare
call
once
on
the
Node
before
it
can
actually
start
containers
and
that's
what
happens
locally
on
the
Node
between
the
resource
manager
or
I.
B
B
The
resource
driver
controller
that
runs
as
part
of
a
control
plane,
either
inside
the
kubernetes
cluster
or
potentially
outside
of
it
as
a
standalone
process.
That's
the
part
that
talks
with
the
scheduler
through
the
API
server
to
to
Mark
resource
game
as
allocated
and
internally
the
resource
driver,
controller
and
resource
cable
plugin.
They
still
need
to
communicate
somehow
with
each
other
or
track
which
resources
are
available
where,
but
that's
an
information
implementation
detail
of
a
resource
driver,
so
the
cap
doesn't
prescribe
a
certain
way
of
doing
it.
B
There
is
one
section
that
I,
where
I
outline
my
ideas,
how
it
could
be
done
with
crds,
and
it
sounded
like
RP
already
is
doing
something
like
that.
So
your
path
towards
using
Dynamic
resource
allocation
might
actually
be
fairly
easy,
but
of
course
that
that
would
need
to
be
validated
whether
it
makes
sense.
This
all
cap
needs
to
be
accepted
first
and
and
so
on,
but
at
least
it's
seems
conceptually
similar,
so
that
leads
me
to
current
status.
B
We
had
tried
to
get
this
cap
accepted
for
124,
but
there
were
too
many
open
questions
and,
as
always,
those
questions
just
came
up
when
people
actually
started
reviewing
caps
work
shortly
before
the
deadline,
so
we
never
fully
clarified
all
of
them
right
now.
Tim
Hawkins
is
our
main
API
reviewer.
He
had
some
questions
about
the
API
design,
so
we
need
to
finalize
that
scheduler
performance
is
a
major
concern,
because,
obviously
this
whole
cap
is
more
flexible.
B
It
tended
to
be
more
flexible,
but
with
flexibility
come
additional
costs
like
calling
out
to
the
resource
drivers,
one
way
or
another
to
do,
checking
off
of
where
resources
are
available
and
that's
harder
to
do
and
slower
it's
expected
to
be
slower
than
the
current
extended
resource
model
for
Simple
Resources.
But
that's
simply
the
price
that
you
have
to
pay
for
for
this
extra
complexity
and
I,
just
don't
see
a
way
how
to
make
the
current
model
flexible
and
fast.
So
something
has
to
give
here.
B
The
question
keeps
coming
up
whether
that
is
the
right
compromise
for
our
users.
We,
we
just
don't
know
yet
it's
part
of
the
challenge
that
we
have.
We
are
just
designing
this.
We
have
a
prototype,
but
we
don't
have
users,
we
don't
have
real
resource
drivers,
so
any
questions
about
is
that
good
enough
basically
has
to
wait
until
we
have
this
as
Alpha
and
potentially
with
some
multiple
resource
drivers
and
real
workloads
testing
this
implementation
before
we
can
decide
that
so
I'm
kind
of
trying
to
deflect
these
questions.
B
But
it's
it's
one
of
the
things
that
comes
up
and
the
last
point
is
just
the
auto
scalar
integration.
Six
scheduling
asks
for
that
and
and
sick
Auto
scaling.
People
are
also
looking
at
vocab.
The
underlying
problem
is
that
we
are
proposing
something
that
will
work
with
entry,
Cube
scheduler,
but
then
will
not
work
automatically
for
just
the
autoscaler,
which
is
an
out
of
tree
project
built
on
the
same
source
as
as
the
scheduler.
B
But
then
will
does
does
a
few
things
differently
and
six
scheduling
is
wary
of
adding
and
allowing
features
in
core
kubernetes
that
are
not.
Then
then,
can't
be
supported
by
the
autoscaler
I'm
again
questioning
the
attitude
a
little
bit,
but
it's
hard
to
argue
with
your
reviewers
and
perhaps
I
really
need
to
find
a
compromise
here.
B
The
problem
is
that
an
out
of
three
component
is
basically
now
blocking
entry
enhancements,
whether
those
additional
out
of
three
features
are
relevant
for
users
or
not,
and
talking
with
Kate
I
heard
that
aqui,
for
example,
or
Agri
users
are
not
using
Auto
scaling.
So
a
fictional
argument
is
based
on
Dynamic.
Resource
allocation
will
work
just
fine
without
cluster
Auto
scalar
support,
but
we
still
need
to
come
up
with
some
solutions.
So
the
current
idea
is
for
that
for
Alpha
in
125.
B
But
it
doesn't
have
the
latest
API
changes
from
vocab
revisions
that
we
are
currently
doing
for
125.
But
it's
good
enough
and
it
has
instructions
for
building
from
that
Branch
bringing
up
a
cluster
with
localhost
a
local
cluster
up
and
have
have
this
whole
thing.
Working
and
there's
also
an
example
driver
in
that
prototype
and
with
that
I
think
I
almost
made
it
with
enough
questions
for
for
five
millimeters
for
questions,
I'd
I.
B
B
C
B
C
D
C
Okay,
that
makes
sense,
but
you
have
to
have
a
one-to-one
relationship
between
resource
claim
and
resource
drivers.
So
I
guess
I'm
asking
these
questions
from
the
perspective
of
awkward.
You
would
make
sense
to
run
that
as
one
driver
and
be
able
to
create
all
these
different
types
of
resource
claims
for
different
types
of
devices
or
not
resource
claims,
but
be
able
to
create
I
guess
the
potential
for
users
to
create
resource
claims
for
various
different
types
of
devices,
rather
than
having
multiple
drivers.
A
B
It's
not
not
for
device.
The
device
of
course
exists
permanently,
but
it's
the
allocation
that
is
tied
to
the
life
cycle
of
a
part.
That's
what
I
call
ephemeral
that
basically
means
that
a
pod
starts
a
resource
gets
allocated
for
the
port
and
when
the
part
gets
deleted,
the
resource
claim
also
gets
deleted
and
deallocated
and
that's
creation
and
deletion
is
handled
by
kubernetes
compared
to
the
other
case
where
the
resource
claim
is,
or
the
life
cycle
of
a
resource
claim
is
managed
by
the
user.
That's
that's
the
key
difference.
D
So,
to
compare
to
draw
our
knowledge
Alliance
right
now,
device
plugin
interface
is
always
ephemeral.
Devices
so
like
as
soon
as
for
the
device
is
requested.
Where
allocate
it
comes
to
the
voice
plugin
and
when
report
is
done.
When
decides
what
this
this
device
is
not
taking
longer
than
we
use,
and
if
you
get
this
dialocate
call
to
the
West
plugin
apis
one
well,
it
will
be
the
allocate
call
so
in
in
line
in
reports.
Back
like
the
clean
template
will
be
getting
similar
life
cycle.
D
So
like
all
this
pipeline
is
something
what
you
will
accuse
it
up
at
once
and
one
when
you
all
can
use
it
for
for
a
long
period
of
time,
so
for
what
it's
too
better
to
have
different
life
cycles.
So
you
first,
you
do
a
location,
make
sure
what
is
done,
and
only
afterwards
you
start
to
start
reports
which
will
be
consuming
this
pipeline
abilities.
A
E
E
So
one
of
the
one
of
the
things
in
kind
of
unique
in
K
zeros
is
that
well
I
don't
know
unique,
but,
but
not
so
obvious,
at
least
is
the
fact
that
it's
it's
actually
packaged
as
a
single
binary.
So
so
we
do
it.
We
do
it
quite
differently,
as
as
k3s
does
it.
For
example,
so
where
K3
is
actually
compiles,
everything
in
like,
like
you,
you
actually
have
a
a
single
binary
that
runs
the
k3s
process,
that
Cube
API
server,
containerdy
and
cubelet
and
everything.
E
So
we
actually
packaged
the
the
K
series
binary
more
like
kind
of
like
a
self-extracting
binary,
so
we
actually
embed
other
binaries
into
the
single
golang
binary
by
just
it.
It
was
actually
as
easy
as
just
concatenating
the
files
into
into
the
end
of
the
file.
So
and
then,
of
course,
we
have
to
calculate
the
offsets
and
everything,
but
but
but
essentially
it's
it's
like
a
like
a
self
extracting
binary.
E
E
So
so,
if
you
want
to
run
kubernetes
we
are,
we
are
K
zeros.
You
just
installed
the
case
versus
binary,
and
that
contains
everything
you
need.
You
don't
have
to
worry
very
and
figure
out
that,
okay,
from
which
three
for
a
while
I'll
I'll
pull
my
containerdy
packages
and
from
which
repo
I'll
pull
my
kubernetes
packages
and
and
so
on.
E
A
E
E
Yeah
so
so
we
don't
really
have
to
worry
about
the
operating
system
packages
and
and
and
therefore
we
can,
we
can
kind
of
more
decouple
the
the
operating
system
and
then
the
kubernetes
components
life
cycles
from
each
other.
So
you
can
freely
upgrade
your
OS
and
everything
still
works,
and
you
don't
have
to
figure
out
kind
of
worried
Warrior
that
if
I
update
my
OS
packages
will
container
the
magically
upgrade
or
some
other
component
magically
upgrades
and
everything
breaks
down
and
whatnot.
E
If
you
run
like
single
node,
Masters
or
controllers,
you
might
might
want
to
save
some
resources
and
and
run
it
with
coin
and
sqlite.
Only.
We
all
know
that
that's
it
is
it's
quite
almost
as
hungry
as
for
resources
as
the
API
server.
So
but
but
I
said
you
can
you
can
you
can
run
with
that
with
basically
any
zero
runtime?
If
you,
if
you
want
to
install
docker,
just
install
Docker
and
run
it,
but
we
just
don't
embed
all
of
them.
Of
course,
that
would
be
a
humongous
binary.
E
So
one
of
the
one
of
the
kind
of
unique
things
in
case
xeros
is
is
is
a
feature
that
we
call
like
control,
plane,
isolation
so
and-
and
it's
it's
actually
quite
quite
a
bit
more
than
the
usual
isolation
by
using
using
tanks
and
tolerations.
So
you
you
can
actually
actually
place
your
controller
and
worker
nodes
really
separate
from
the
network
point
of
view.
E
E
So
what
it
actually
means
is
that
is
that,
by
default
in
k00s
the
controller
nodes,
they
don't
run
in
workloads.
So
when
you
spin
up
a
k-0s
controller
process,
it'll
create
the
API
server
at
CD
and
all
the
typical
control
plane
components,
but
it's
actually
running
those
as
what
I
usually
call
naked
processes.
So
there's
no
container
they're
running,
there's
no
cubelet
running
even
static,
manifests
or
or
anything
on
the
on
the
controller
nodes.
So
they
are
just
like
your
playing
Linux
processes.
E
E
E
I
mean
there's
no
wire
back
to
the
filter
stuff
like
node,
selectors
or
colorations
or
whatnot,
and
that's
actually
a
pretty
big
hole
in
my
opinion,
in
the
in
the
Arabic
system,
and
also
the
fact
that
the
the
cni
needs
to
work
from
node
to
node
and
and
Etc.
So
it
kind
of
assumes
that
the
network
is
flat-ish,
at
least
of
course,
you
you
can
do
a
lot
of
fancy
things
with
bgps
and
whatnot,
but
but
but
then
again
you
really
have
to
do
it
at
work
always
for
the
network.
Configuration.
E
And,
and
the
API
and
cubelet
connection
is,
is
something
that
that
that
that
has
always
kind
of
bugged
me
a
bit
that
the
the
API
requires
always
direct
connection
to
the
cubelets.
So
when
you
get
do
this
usual
Cube
CDL
get
locks
and
whatnot,
the
API
is
actually
calling
the
cubelet
directly
usually
and
all
this.
This
basically
boils
down
to
quite
limited
deployment.
Architectures.
E
E
So
now,
when
my
my
Cube
API
wants
to
call
the
cubelet
say
on
a
on
a
node,
a
it'll
actually
connect
to
the
server
via
local,
unique
socket,
and
then
this
connectivity
server
actually
then
pipes
the
connection
for
this
reverse
tunnel
to
the
agent
and
then
the
agent
forwards,
the
connection
into
the
cubelet
to
get
the
logs
or
execute
yourself
into
a
pod
door.
Whatever
you
you
want
to
do
so.
This
really
allows
kind
of
this
kind
of
like
a
not
disconnection
but
but
but
kind
of
like
a
network
level.
C
E
C
E
E
The
the
use
case
is
basically
that
they
they
wanted
to
have
a
super.
Fine-Grained
controls
on
on
how
they
deploy
applications
and
the
workloads
that
are
actually
collecting
data
from
different
different
kind
of
robotic
systems
and
and
the
Machine
already
that's
actually
doing
the
assembly,
jobs
and
whatnot.
E
E
E
Let
me
see
if
I
can
actually
pull
out
quickly.
One
of
these
I
have
this
some
of
these
boards.
So
there
there
are.
These
super
kind
of
Raspberry
Pi
size
a
bit
bigger
than
a
raspberries,
but
there
is
kind
of
industrial,
great
controllers
that
are
actually
running
kubernetes
I.
Don't
have
them
plugged
on
right
now
so
yeah,
that's
that's
been
pretty
cool.
F
So
so
I'll
be
honest,
I
I
am
part
of
a
company
that
actually
makes
its
own
hardware
and
Industrial
grade
controllers
and
everything.
So
one
question
is:
are
the
the
k0s
workers
over
here
that
you
show
in
the
figure?
Are
they
actually
scheduled
from
the
controller
themselves
or
are
they
actually,
let's
say
hard
coded
onto
each
each
controller
per
se
like
the
way
you
mentioned
it
over
here?
F
If
you
know
what
I
mean
right
like,
for
example,
SMD
site
has
a
has
a
can
bus
controller
right
and
the
can
bus
is
then
available
from
your
operating
system
on,
let's,
say,
slash:
Dev
slash
can
zero
whatever.
So,
how
do
you?
How
does
the
controller
itself
figure
out
if
assembly
site
worker
node
actually
has
that
file
descriptor
or
some
form
of
U
Dev
Discovery
protocol,
or
something
like
that.
F
E
This
case,
the
the
at
least
as
far
as
I've
been
following,
of
course,
I'm
I'm,
not
an
expert
on
this
industrial
devices
and
I
O
buses
or
anything
so,
but
but
as
far
as
I
know
that
in
in
this
case,
the
the
the
scheduling
kind
of
scheduling
logic
regarding
the
devices
and
their
capabilities
is,
is
kind
of
like
a
human
action.
So
they
know
that
that
okay,
this
node,
is
actually
connected
to
that
robotic
system.
So
we
can
deploy
this
sort
of
data
collection.
Applications
on
that
node.
F
Yeah
I
think
that
that
pretty
much
answers
my
question
because
I'll
be,
let
me
be
honest
and
learned
about
it.
It's
since,
coming
from
the
industrial
Edge
side,
it
is
quite
conservative
when
it
comes
to
understanding
what
actually
happens
on
the
on
the
floor
itself.
Right
like
so
for
example,
chances
are
you
buy
a
controller?
You
first
have
to
sit
down
program
it
accordingly
to
your
needs,
and
then
you,
let's
say
figure
out
a
way
to
extract
that
data
and
probably
send
it
somewhere.
F
C
E
E
So
when
you,
when
you,
when
you
set
up
k0's
clustered,
you
don't
get
much
bells
and
whistles,
so
you
get
Upstream
conform
and
kubernetes
and
that's
about
it.
So
we
we
don't
bundle
and
force
people
to
use
like
these
deals
and
other
large
bits
and
pieces
so
and
and
I
said,
especially
the
worker
nodes.
E
Air
gap
setups
are
supported
out
of
the
box
and
and
I
mean
we.
We
don't
do
any
any
like
like
big
Magic
on
air
gap
setups,
but
but
I
think
the
the
way
we've
built,
K,
zeros
and
and
how
we
package
package
it
is,
is
actually
quite
simple,
so
I
mean,
if
you,
if
you
have
this
typical
air
gap,
kind
of
your
cluster
runs
in
a
bunker
case,
then
you
don't
have
to
worry
about
installing
different
OS
packages
and
whatnot.
E
E
What
k0
does
for
the
image
turbo?
Is
it's
actually
on
a
when
it
boots
up.
It
finds
the
finds
the
terrible
in
a
in
a
specific
location
kind
of
predefined
folder
in
a
in
a
in
a
disk
gun,
and
then
it
automatically
Imports
the
images
for
containerdy
and-
and
you
can,
you
can
of
course
have
multiple
turbo
files
for
your
own
application
images
or
whatever
you
need
to
need
to
run
on
the
nodes.
E
What
we
have
found
out
is
is
that
the
cube
Cube
lip
image
carpet
collector
can
cause
some
gray
hair,
unfortunately,
or
if
I'd
have
here,
it
would
be
gray
already,
but
but
the
the
main
problem
is
that
there's
no
like
like
configuration.
But
okay,
whenever
you
run
the
garbage
collection
on
images,
don't
touch
these
ones,
because
these
are
system
images,
so
don't
go
and
remove
them.
E
C
E
A
C
So
as
of
now,
we
have
all
the
same
links
meeting
times,
slack
Etc,
but
we're
going
to
start
gradually,
transitioning
that
over
to
cncf,
so
having
a
different
Zoom
link
having
a
different
agenda
hosted
by
the
cncf
I
think
we're
going
to
move
our
slack,
but
that
one's
a
little
hard,
because
I
think
we
do
have
a
good
slack
history.
So
maybe
there
is
something
we
can
do
around
that
of
staying
in
kubernetes.
A
Okay,
thanks
Kate
and
we're
out
of
time.
So
thanks
everybody
for
attending
we'll
get
the
recording
of
this
up
soon.
If
the
speakers
can
drop
a
link
to
your
deck,
that
would
be
nice
either
patch
the
link
to
the
deck
right
in
the
agenda
note
stock
or
if
you
have
trouble
accessing
that
drop
it
in
the
slack
Channel
and
then
I'll
update
the
agenda
node
stock.
Later
thanks
so
bye,
everybody
and
we'll
see
you
at
the
next
meeting.