►
From YouTube: SIG Node Sidecar WG 2022-12-06
Description
Meeting notes and agenda: https://docs.google.com/document/d/1E1guvFJ5KBQIGcjCrQqFywU9_cBQHRtHvjuqcVbCXvU/edit#heading=h.m8xoiv5t6qma
GMT20221206-170520_Recording_1920x1120
A
Hello,
it's
December,
6
2022
are
still
2022.,
it's
a
signaled,
sidecar
working
group.
We
are
here
to
discuss
sidecar's
proposal
and
how
it
will
look
like
just
a
small
recap.
We
had
two
meetings
already.
You
can
find
those
meetings
in
this
agenda
dock
with
the
recording
links
and
on
those
meetings
we
discussed
what
idea
ideas
we
were
paused
before
it
was
rejected.
A
Also
we
do
discussion
what
properties
the
idea
of
having
group
of
containers
called
you
need
like
pre-init
containers,
so
some
other
name
will
satisfy
and
we
decide
that
it
will
satisfy
most
scenarios,
if
not
all
the
scenarios.
A
So
now
on
this
music,
you
wanted
to
speak
a
little
bit
about
yamu
and
how
this
can
be
expressed
in
yaml,
and
one
idea
was
to
discuss
each
property
of
containers
and
decide
whether
this
property
only
applicable
to
sidecar
or
mostly
applicable
to
sidecar.
So
it
can
be
applicable
to
everything
and
yamu
corresponsively.
We
either
need
to
have
this
property
universally
applied
or
applied
specifically
for
sidecars
or
even
be
implied
by
having
the
sidecars
but
I
think
all
these
questions.
But,
yes,
you
can
take
it
away
and
yeah.
A
Maybe
you
can
give
another
introduction:
if
there
is
any
questions
I
on
a
phone,
you
can
that
you
want
to
ask
now:
please
do
otherwise.
I
will
go
ahead
and
password.
Yes,.
B
Yes,
okay,
so
it's
it's
a
bit
of
a
reflection
that
we
had
first
with
Ramya
and
then
with
Tim,
so
we
were
thinking
about
how
how
it
should
you
look
like
in
in
in
the
Pod
spec
yaml,
so
first
ID
would
be
like.
Can
you
go
to
slide
two
like
we
Define
sidecars,
as
another
list
of
of
containers
called?
Let's
call
it
cycle
for
the
moment.
So,
like
a
pod
would
look
like
this,
so
let's
say
we
have
any
container
which
gets
some
secrets
from
Vault.
B
Then
we
have
one
Sidecar
and
then
you
have
like
the
normal
containers.
So
it's
your
sidecar
in
this
case.
So
as
you
can
see-
and
this
is
detailed
in
the
next
slide-
but
I
think
I
can
comment.
While
we
have
this
one
on
screen
just
see
my
notes.
B
So
this
is
mostly
via
the
the
restart
policy
that
is
specified
in
in
the
Sidecar,
and
the
idea
is
the
order
of
this
list
defines
the
starting
order
and,
and
this
order
is
reversed
for
the
stopping
order.
So.
B
Yeah,
that's
that's
the
proposal,
so
then
we
said
man.
Maybe
you
know
sidecar
is
not
a
good
word.
So
let's
try
to
to
find
a
more
generic
name.
So
if
you
go
to
slide
four,
then
we
take
the
decision
to
call
them
XXX
containers
because
we
already
have
init
containers.
So
maybe
we
have
like
XXX
containers.
That's
the
only
difference.
B
Then
we
can
take
this
ID
further
and
say
how
would
it
look
like
with
a
job?
So
that's
the
next
container
so
here
for
a
job
you
can
see.
Normally
we
have
an
implicit
restart
policy
for
the
whole
pod
to
never
and
then
we
still
have
our
XX
container
with
the
restart
policy,
always
so
as
as
we
mentioned
before.
B
If
when
the
job
is
done,
then
regardless
of
the
sidecar
should
run
all
the
time,
the
Pod
will
be
terminated
and
it
will
go
to
the
reverse
order
of
the
starting,
and
now,
let's
have
a
bit
of
a
recap
on
the
next
slide,
to
compare
the
the
three
different
list
of
containers
now
that
we
have
in
the
Pod
spec.
B
So
for
the
restart
policy,
do
you
need
container?
B
The
implicit
restart
policy
is
always
on
failure
and
it
cannot
be
changed,
whereas
the
restart
policy
of
all
containers
in
the
Pod
spec,
they
can
be
always
on
failure
or
never,
and
they
are
inherited
for
the
the
Pod
restart
policy
and
normally
they
cannot
be
changed
and
now
the
one
for
the
sidecars
it's
explicit
and
depending
on
the
usage,
we
can
set
it
to
always
or
on
failure,
and
then
this
translates
to
the
order
when
we
start
them
so
in
it
containers
they
should
start
before
containers
and
they
run
to
completion.
B
B
So
now,
if
we
take
some
specific
part
of
this
page-
and
we
highlight
them
in
the
next
one,
so
we
squint
a
little
bit
so
I,
don't
know
if
it's
you
you
see.
The
the
bold
a
bit
so
highlighted
is
like
on
failure
for
Conte
init
containers
and
sidecar
containers,
and
also
the
property
that
they
should
start
before
the
main
containers.
B
C
Hey
Matthias,
this
is
so
also
what
would
be
the
Behavior
if
an
xxx
container,
it
doesn't
start,
will
the
Pod
restart
or
it
will
have
no
impact
on
the
bot.
I
just
want
to
clarify.
B
C
Yeah
actually
I
I
want
I
mean
I
would
prefer
that
behavior,
because
in
our
production
deployment
the
workloads,
what
we
have
we
on
istio
container,
which
kind
of
proxies,
are
all
the
outgoing
API
connections,
so
I'm
just
correlating
to
that.
So
if
that
cycle
it
doesn't
come
up
the
the
part
it
essentially,
it
can't
do
anything.
So
you
know
I
would
actually
really
prefer
that
behavior.
If
that
doesn't
come
up,
the
pot
should
actually
restart.
B
Okay,
so
now,
if
we
squint
a
little
bit
more
on
next
slide,
we
could-
and
this
this
is
team's
idea.
Actually
when
we
were
discussing,
if,
if
you
move
the
restart
policy
to
the
other
side
of
the
equal
sign,
if
we
take
an
init
container
and
put
it
as
a
restart
policy,
always
it's
equivalent
to
a
sidecar.
B
So
yeah,
so
if
you
compare
to
the
to
the
other
slide,
is
just
remove
the
away
we
exchange
init
containers
and
and
sidecars
okay.
Is
it
clear
what
I
mean
so
the
conclusion
would
be,
but
we
need
to
to
refine
and
make
sure
it
works.
That
sidecars
are
just
init
containers
that
always
restart.
B
B
So
at
the
moment
when
we
were
discussing,
we
said:
okay
yeah,
we
have
this
XXX
container.
Do
we
want
to
deprecate
init
containers
and
just
use
those
ones?
What
I'm
proposing
is
actually
the
opposite.
We
should
keep
in
it
containers
and
and
just
enrich
them,
then
yeah
all
sort
of
questions
regarding
life
cycle
of
a
container
between
inside
the
pod.
B
How
do
we
yeah
do?
We
need
more
guarantees
for
ordering
or
because
one
one
drawback
is
that
since
we
we
use
the
The
Ordering
of
the
list,
it's
not
easy
to
insert
something
in
the
middle
of
the
list.
You
could
easily
put
it
at
the
end
of
the
list
or
at
the
beginning,
but
in
the
middle
it's
more
difficult
when
you
want
to
add
sidecars
at
at
admission
and
then
I
have
also
some
open
questions
from
my
side
on
the
next
slide.
B
So
it's
mostly
the
same
ID
but
I
applied
it
to
init
containers
instead
of
containers.
So
we
have
this
strong
isolation
between
con
domain
container
and
and
the
sidecar
and
the
unit
containers,
and
we
make
sure
that
everything
is
set
up
before
we
even
start
the
real
workload
of
the
pod,
then
we
need
to
sort
out
what
to
do
with
the
lifecycle
handlers
if
if
they
have
some
species,
if
there
are
some
special
cases
to
to
handle
and
yeah,
how
do
we
make
sure
we
we
can
tweak
the
grace
period?
B
Do
we
need
one
per
container
and
then
we
add
them
or
I?
Don't
know
this
is
like
open
questions,
so
that's
it
for
the
moment.
D
Hi,
this
is
Joe
I,
really
like
the
one
property
of
this
latest
design.
Is
that
you
don't
add
yet
another
class
of
containers,
which
means
that
our
Discovery
endpoints
will
have
like
an
explosion
of
the
ammo
which
is
kind
of
a
problem
right
like
if
you
go
and
look,
we
already
have
like
ephemeral
containers
in
it,
containers,
containers
and
they're.
Also,
all
of
our
very
large
when
you
look
at
like
their
open
API.
D
B
A
Yeah
one
interesting
side
effect
would
be
if
there
are
any
controllers
that
calculate
resource
usage
themselves
instead
of
relying
kubernetes,
and
they
will
need
to
understand
that
they
start
always.
Init
containers
should
be
accounted
for.
Duration
of
a
port
life
cycle,
foreign.
D
There's
I
don't
think
this
is
a
showstopper,
but
something
we're
gonna
have
to
consider
before
building
this
fully
is
there's
going
to
be
a
versions
Q
problem
where,
when
you
first
interview
this,
introduce
this
feature
versions
of
the
system
that
don't
know
about
this
new
field
are
gonna,
probably
accidentally
treat
these
new
init
containers
as
normal
in
containers,
because
they
won't
realize
that
always
isn't
is
a
thing.
B
Or
maybe
even
fail,
parsing
the
yaml
I
haven't
tried
what
what
happens.
D
It's
just
like
a
new
field.
Usually
what
happens
is
it
gets
ignored?
So
we
might
have
to
think
a
little
carefully
about
that
I'm
willing
to
also
help
try
and
think
about
that
I.
Don't
think
it's
a
showstop
right,
I
think.
If
that's
the
only
problem,
we
should
just
find
a
way
to
cope
with
it,
but
we
will
want
to
have
a
plan.
E
Yeah,
so
right
now,
if
we
could
go
back
to
the
slide,
deck
and
I
think
slide,
ten
or
nine,
maybe
new
slide
nine.
B
D
D
D
D
B
Yes,
absolutely
that's.
That's
one
good
idea,
one
good
part
of
this
of
this
one
you
can
really.
If,
if
you
need
like
the
Vault
to
to
be
run
before
you,
you
start
istio
and
then,
if
you
need
to
retrieve
I,
don't
know
another
certificate
through
istio
for
your
normal
application,
then
you
can.
You
can
do
the
ordering,
as
you
said,.
D
Yeah
I
actually
think
that's
a
pro
when
it
comes
to
composability.
There
are
certain
things
that
I
think
people
wouldn't
have
been
able
to
do
it.
The
other
way
that
they'll
be
able
to
do
I
can't
think
of
exactly
what
they'll
be,
but,
like
you
can
imagine,
people
have
like
steps
they
want
to
do
in
between.
A
You
know
I
wonder
if
it
can
be
smart
and
such
as
some
way
to
feed
this
new
design
into
Old
design
so
or
let's
maybe
create
fake
real
containers.
It
doesn't
take
any
resources
but
helps
with
accounting
of
resources
somehow
for
transition
stage.
It
may
be
a
good
idea
to
to
be
able
to
express
it.
A
Somehow
so,
let's
say,
I
have
fake
containers
that
is
defined,
but
kubert
wouldn't
even
take
it
into
account,
and
it
will
just
ignore
it
because
it
knows
that
it
only
taken
resource
for
in
it
for
new
unit
containers.
B
And
there
is
a
question
in
the
chat
from
Howard:
candidate
containers
have
probes-
probably
yes,
they
are
just
a
regular
container
in
the
in
the
list.
Now.
B
B
F
It
is
in
like
the
the
spec
like
if
you've
got
to
explain
it
shows
up
that
there's
some
I
don't
know
project
that
rejects
it,
no
probes
and
in
the
containers,
so
I
think
that's
fine,
like
we
can
probably
just
say
that
if
the
restart
policy
is
always
or
whatever
then
robes
are
allowed,
otherwise
they're
not
allowed
it's
just
something
that
we'll
need
to
take
mine.
That
also
means,
we'll,
probably
you
know
it's
an
implementation
work
to
make
it
work,
but.
F
D
A
Yeah,
we
need
to
think
about
extended
graceful
termination,
graceful
period
because
we
don't
have
it
now.
Today
we
just
send
zika
term
to
everything.
Okay,.
B
E
Currently,
the
pond
gets
the
sync
term
and
not
the
individual
containers,
and
so
this
might
be
problematic
to
send
them
to
specific
containers.
E
C
E
That's
how
it
currently
works.
The
whole
pot
gets
a
second
term
which
usually
gets
relayed
to
all
the
containers
by
cryo
or
containerdy.
A
Well,
I
mean
in
case
of
Grace
contamination.
We
first
kill
like
terminate
regular
contests
and
then
system
containers.
So
we
have
a
way
to
distinguish
about.
G
Oh
sorry,
go
ahead,
are
saying:
I
know
that
Lyft
made
a
patch
that
they
use
annotations
for
this,
and
there
is,
they
do
do
ordering
shutdown
with
basically
the
sidecars
get
something
after
the
I
haven't
looked
I
haven't
looked
at
the
code,
though
I'll
double
check
how
they
did
it,
I,
don't
think
they
made
any
changes.
The
interface
I
think
it
was
more
changes
the
cubelet,
but
there
could
be
some
ideas
there.
G
A
A
A
We
will
determination,
yeah
cancer,
before
in
containers.
This
is
taken
into
account
very
like
this
works
perfectly.
In
this
situation,
the
star
Behavior
can
be
different
from
poetry,
started
policy.
Yes,
this
is
exactly
what
we
indicate
with
this
flag.
So
basically
this
this
is
decent.
Like
item
requirement,
number
two
and
requirement
number
three
taking
care
of
perfectly
different
enough
to
allow
Futures
coupons
expansion.
A
You
know
I've
been
talking
about
some
resources,
evaluation
and
securities
I
think
they
are
in
in
it
containers
place,
so
you
need
containers
are
special
enough
from
regular
cut
layers
that
we
can
take
into
account
Advanced
resources
Aviation
for
them.
We've
been
discussing
that
other
types
of
resolution
is
not
very
significant
but
again
where
we
need
container
stage.
So
they
separate
enough
from
regular
containers
established
pattern
to
follow.
G
A
Sidecar
can
reliably
be
injected
by
web.
Hooks.
I
think
this
also
right,
if
python
doesn't
have
any
dependencies,
can
go
just
to
be
first
init
container
before
you
shy
enough,
you
can
go
last
minute.
Containers
and
you'll
be
taken
care
of
germination
ordering
yeah,
really
these
guys
that
we
need
to
have
more
this
specific
design,
but
I
think
this
can
be
taken
care
of
they're
special
enough.
A
H
A
A
D
A
Yeah
any
other
suggestions,
what
the
result
policy
value
may
be
for
this
kind
of
behavior.
D
A
D
The
I
I
think,
that's
I,
think
that's
a
good
one.
The
only
other
one
that
I
was
thinking
about
when
I
saw
this
design
is
the
future
proofing
we're
going
to
be
having
to
co-evolve
and
knit
containers
and
sidecar
containers.
So
any
fields
that
we
add
are
going
to
either
have
to
make
sense
for
both
we're
going
to
have
to
like
explicitly
have
like
validation
rules.
That
say,
you
can
only
use
this
field
if
restart
policy
is
set
to
X
on
something,
and
then
also
is
this
going
to
be
an
immutable
field.
D
A
Yeah
and
if
you
mistakenly
apply
this
field
to
regular
in
a
container,
then
you
kind
of
screw
it
right.
So
it
will
keep
restarting
the
same
container
and
it
will
keep
trying
to
initialize
things.
H
H
B
What
about
the
pre-stops
did?
Do
we
need
to
change
something
to
account
for
those
ambient
containers
or.
A
What
do
you
mean
how
to
handle
termination
properly.
B
No,
it's
like
you
know,
you
know
today
we
have
those
life
cycle,
hooks
that
and
maybe
it's
not
relevant
for
ambient
container,
but.
A
I
think
it
is
relevant,
it's
it
just.
We
need
to
Define
exactly
how
graceful
period
will
work
for
those
containers
and
what
we
what
we
can
commit
and
what
we
want
to
commit
on.
A
So,
typically,
when
we
stop
containers,
we
execute
pre-stop
hook
first
and
then
once
it's
and
and
start
a
timer.
If
please
stop
completed,
then
we
will
just
simulate
the
port
and
if
not
then
I
mean
we
will
terminate
it
anyway,
when
timeout
will
be
reached
right.
A
So
I
think
one
big
open
question
is
spell
out
exactly
the
determination
how
termination
will
work
foreign.
A
You
can
that,
even
if
it
was
that
seemed
like
like
evenly
make
it
work
as
it
works
today
with
regular
containers,
then
it
will
be
good
enough
for
majority
of
scenarios.
A
A
It's
extended,
Grace
with
termination
and
sequencing
of
determination
can
be
applied
more
broadly
than
just
ambient
containers.
B
D
I,
don't
know
notice
well,
as
I
should
but
I'm
willing
to
try
it
and
make
a
dent
in
that
this
is
Joe
Betts,
oh,
probably
ask
for
help
for
some
people.
A
So
I
think
other
things
we
can
do
is
to
just
write
down
all
we
discuss
to
Industry
meetings
and
say
that
we
almost
came
up
to
this
final
proposal,
and
this
is
something
that
you
I
mean
need
to
collect,
like
last
objections
for
the
design.
If
there
are
any
I
think
we
went
through
all
the
requirements
so
many
times
that
this
is
what
we
can
and
should
implement.
H
A
Yeah,
if
you'll
spell
out
all
the
determination
work
and
make
sure
that
we
know
how
it
works,
we
will
collect
last
objections
and
if
there
will
be
no
objections,
that
I
think
it's
good
enough
for
a
cap
for
127.,
that's
great
okay,
yeah
I
think
we
can
finish
this
meeting
today
earlier
taking
20
minutes
back.
If
there
are
any
last
comments,
please
go
ahead
and
say
incoming.
B
Sorry
sorry
I
didn't
notice,
yeah.
Okay,
thanks
thank.