►
From YouTube: Kubernetes SIG Arch - KEP Reading Club 20220808
Description
KEPs discussed:
- Seccomp By Default
https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2413-seccomp-by-default
- Server Side Unknown Field Validation
https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/2885-server-side-unknown-field-validation
A
Hi
a
few
housekeeping
things
before
we
get
started.
This
is
a
kubernetes
community
meeting,
which
means,
as
other
kubernetes
community
meetings.
This
follows
the
cncfn
kubernetes
code
of
conduct,
which
boils
down
to
you,
know
be
excellent
to
one
another,
and
this
is
also
being
recorded
and
will
be
put
online
for
future
reference.
So
please
be
mindful
of
what
you
do
or
say
in
that
regard.
So
that
being
said,
we
are
having
this
meeting
after
a
month
or
so
or
after
two
months.
We
didn't
have
one
last
time
so
welcome
everyone.
A
I
see
a
lot
of
new
faces,
so
welcome.
Thank
you
for
joining
in
our
two
minute
brief
disclaimer
or
like
the
description
of
what
goes
on
here.
The
main
intent
of
this
meeting
started
off
as
getting
folks
familiarized
with
what
caps
are,
what
the
process
is,
what
a
cap
entails
and
if
you
need
certain
pieces
of
information,
do
I
look
into
a
cap,
or
do
I
look
into
something
else
and
like
if
I
do?
A
If
I
look
into
a
cap,
where
do
I
go
and
see
for
that
that
particular
piece
of
information
now
it
sort
of
evolved
more
into
you,
know,
folks
gather
we
read
a
cap
and
then
ask
questions
and
a
lot
of
these
a
lot
of
times.
A
These
questions
come
from
and
from
a
user
perspective
that
is,
people
on
the
call
usually
use
these
features
that
are,
that
is
that
the
cap
was
written
for,
and
these
questions
are
like
really
really
interesting,
and
then
we
sort
of
take
this
back
on
slack
or
if
the
authors
are
on
the
call,
they
sort
of
answer
that
and
then
like
follow-ups
happen
on
the
cap
itself,
a
few
of
like
cli
and
windows
had
a
few
caps
that
were
even
edited
because
of
these
interactions,
so
that
was
really
cool
to
see
and
also
like.
A
Obviously,
we
discussed
cabs
that
are
of
high
impact
for
a
particular
release,
so
that
folks
have
more
and
more
context
about
like
what's
going
to
happen
soon.
I
personally
haven't
been
doing
a
good
job
of
getting
comms
out
about
this
and,
like
I
should
probably
try
and
improve
that,
but
like
hopefully,
by
next
month,
we
we
should
have
more
people
on
this
call
so
that
we
can
get
the
word
out
right.
A
So
we
have
two
caps
today,
the
first
one
I
chose
from
like
the
major
themes
of
the
1.25
released
discussion-
that's
happening
on
github
right
now,
so
that's
the
second
by
default,
second
being
enabled
by
default
graduates
to
beta
in
1.25,
and
the
second
cap
is
server-side
unknown
field
validation,
which,
which
seemed
really
really
interesting
to
me
and
like
it's
also
a
few
pain
points
that
existed
before
in
crds,
and
things
like
that.
So
that
being
said,
this
is
the
agenda
link
in
case
you
don't
have
it.
A
What
we
do
is
we
set
a
10
minute
timer
we
take
some
time
read
the
cap.
10
10
minutes
is
not
a
hard
deadline.
So
like
take
your
time,
if
you
need
a
few
more
minutes
totally
fine
and
then
we
sort
of
open
it
up
for
discussions,
questions
comments,
concerns
and,
like
we'll
note
it
down,
take
it
back
on
slack
and
like
see
where
we
can
go
from
there.
So
I'm
going
to
start
a
10
minute
timer
and
then
we
can
get
start
with
the
first
skip.
A
Does
that
sound
good
so
far
like?
Are
there
any
questions
about
what's
happening.
B
Okay,
yeah.
That
sounds
good,
quick
question.
Do
we
typically
does
this
meeting
typically
review
caps
that
are
specific
to
like
sig
architecture,
or
is
it
like
any
capture,
fair
game?
All
all.
A
Caps
across
so
the
meeting
club
is
under
sick
architecture,
but
all
six
involved.
A
B
A
Okay,
so
too
many
tabs.
A
A
Okay,
then
we
we
can
probably
open
it
up
for
questions.
Comments
concerns
anything
at
all.
B
So
one
thing
I
noticed
that
they
didn't
really
discuss
was
sort
of.
This
is
probably
more
of
an
edge
case
but
like
if
you
have
a
cluster,
that's
running
both
like
container
d
on
some
nodes
and
then
docker
and
other
nodes,
and
if
you're,
relying
on
like
a
runtime
default
policy
versus
comp,
you
could
possibly
potentially
have
a
situation
where,
like
some
workloads,
run
on
some
nodes
but
not
other
nodes,
depending
on
the
container
runtime.
A
B
I
would
imagine
they're,
all
like
pretty
similar
would
be
interesting
to
get
a
take
on.
Like
is
container
d
like
you
know
the
same
as
docker,
or
are
there
like
some
like
important
differences
that
users
should
be
aware
of.
A
So
there
is
one
section
under
risks
and
medications
which
sort
of
talks
about
this,
but
not
sure
if
this
is
a
satisfactory
answer.
A
But
I
will
also
start
a
thread
on
slack
just
to
make
sure,
because
I
don't
understand
this
aspect
of
kubernetes
well
enough.
B
Yeah
yeah
yeah.
I
think
it's
also
like
perfectly
fine
just
to
expect
the
cluster
operator
to
have
a
better
idea
of
like
which
container
runtime
they're
running
and
like
which
sitcom
profiles
are
associated
with
that
runtime.
That
seems
like
perfectly
reasonable
as
well.
So
perhaps
it's
like
sort
of
outside
the
scope
of
this
kit,
but
just
so
like
the
first
thing
that
came
to
mind
is
like.
If
you
have
that
scenario,
you
could
potentially
have
like
unintended
consequences
to
that,
depending
on
like
where
the
the
workload
to
get
scheduled,
but.
B
Yeah
yeah.
I
think
this
may
really
be
more
of
a
scheduling
thing
right
where,
like,
if
you're
running
different
container
runtimes,
you
probably
want
to
make
sure
that
different
workloads
are
being
scheduled
appropriately
to
those
nodes
that
are
running
those
different
container
runtimes.
So
I
think
that's
a
good
point.
A
B
Then
the
the
second
thing
that
sort
of
came
to
my
mind
when
looking
through
this
was
that
they
they
had
the
two
alternative
approaches
listed
there.
But
I
feel
like
there
wasn't
too
much
discussion
like
I
mean
they
basically
list
the
advantages
of
their
their
approach,
that
they
chose
and
the
advantages
of
the
alternatives.
B
But
there
wasn't
too
much
discussion
on
like
like
the
decision
process
of
why
they
chose
the
approach
that
they
did
and
there's
a
little
bit
there.
So
I
don't
mean
to
be
like
they
entirely
skipped
over
that,
but
I
feel
like
they
could
have
used
a
bit
more,
a
bit
more
text
as
far
as
like
their
justification
or
choosing
the
approach
that
I
did.
A
Okay
yeah,
this
is,
I
feel
like
this
is
one
problem
that
kept
hope
to
solve,
like
bring
undocumented
context
into
the
documented
side
of
things.
But
it's
it's
it's
a
little
difficult
but
like.
If
those
conversations
did
happen,
they
should
be
part
of
the
cap.
Ideally
we
can
bring
it
up
with
folks
yeah
thanks
anna.
B
A
A
B
B
I
guess
sort
of
like
as
just
like
sort
of
a
one-off
comment.
One
like
surprising
thing
is
that
they
mentioned
that
memory.
Consumption
could
go
up
by
as
much
as
like
30
percent,
which
kind
of
struck
me
as
like,
quite
a
bit
more
than
I
would
have
expected,
but
they
also
like
specifically
like
make
a
note
about
like
why
that
is
acceptable.
B
A
In
in
general,
that
part
of
the
code,
which
is
like
around
strategic,
merge
patch
implementing
json,
merge
patch.
All
of
those
those
are
a
few
scalability
sensitive
codes
like
areas
of
the
code
base.
So
right
now
also
like
I,
there
is
an
issue
open
which
talks
about
how,
if
you
have
like,
if
you
have
the
number
of
label
selectors
that
you
have
in
your
cluster,
is
greater
than
a
certain
number.
A
A
But
if
you
were
to
use
this
for
automated
clients,
30
is
probably
like
not
an
easy
to
digest
number
yeah.
So.
B
B
A
A
Okay,
awesome:
I
will
take
these
questions
and
comments
back
to
slack
and
see
if
we
can
get
more
answers
or
if
I
misunderstood
something.
So,
let's
see
how
that
goes
thanks
again
for
joining
in
it
was
nice
meeting.
You
all
hopefully
see
you
next
month
again
for
some
of
the
other
major
themes
of
1.25
release.
So
thanks
again
have
a
good
local
time
zone.