►
From YouTube: Kubernetes SIG Arch - KEP Reading Club 20220606
Description
KEPs Discussed:
1) Subresource Finalizers: https://github.com/kubernetes/enhancements/pull/3286
2) Graduate API List pagination to GA: https://github.com/kubernetes/enhancements/pull/3274
A
A
A
A
B
A
B
B
If
I
had
to
put
this
in
a
very
simple
way,
it's
essentially
a
way
to
add
role-based
access
control
to
the
finalizer
of
the
resource,
instead
of
making
that
finalizer
the
ability
to
change
and
update
and
do
operations
of
that
finalizes
depends
on
the
role
based
access
control
that
is
defined
at
the
resource
level.
Be
that
resource
whatever
it
is
with
storage,
for
example,
or
something
something
something
like
that.
B
To
that
end,
the
idea
is
to
add,
obviously
the
api
endpoint
that
enables
to
perform
the
that
operation
and,
if
I
understood
correctly,
there
also
some
additional
tooling
in
cube
ctl.
That
would
also
allow
for
the
manipulation
of
said
resources
and
and
that
that
is
the
main
takeaway
that
I
that
I
got.
A
Yeah
yeah,
I
I
unders
the
same
way:
the
the
cube
ctl
tooling,
that's
there
so
that
interestingly
got
merged
last
release.
So
there
was
a
feature
that
a
few
of
us
worked
on
called
cube,
ctl
sub
resource,
so
that
got
merged.
Last
year's
alpha.
Okay,
in
case
that's
of
interest
to
you,
you
know
like
go
use
it.
B
A
A
B
A
B
Yeah
I
took
a
quick
there's,
a
code
snippet
that
is
linked
in
the
somewhere
in
there,
which
I
took
a
a
look
and
I
sort
of
get
it.
Although
there's
a
lot
of
boilerplate
go
codes,
that
is
certainly
immediately
understandable
to
anyone
who
has
developed
this
to
a
wider
extent
than
myself,
but
it
seems
aligned
with
what
we
just
discussed.
Yeah.
B
A
B
A
B
A
B
A
Okay,
so
if
there
are
no
last
like
further
questions
or
comments
on
this
one,
maybe
we
can
do
the
next
one,
so
the
next
one
is
actually
not
a
new
feature.
It's
graduating
a
feature
which
has
been
in
beta
for
like
quite
some
time
now
to
ga,
and
this
is
also
something
that
I
am
helping
do
so
I
can
maybe
try
and
provide
some
context
as
in
when
we
go
through,
but
it
took
me
a
while
to
even
understand
what
the
goal
was
like
for
ga.
A
A
A
What
that
is
ultimately
going
to
translate
into
is
it's
going
to
translate
into
a
a
a
get
request
for
the
pods
endpoint
and
that's
going
to
get
all
the
pod
objects
from
hcd
through
the
api
server
and
return
it
back
to
the
client
now
the
problem.
One
of
the
problems
with
this
approach
is
that
let's
say
that
you
open
a
watch,
so
the
watch,
if
you're
not
aware,
is
this
mechanism
and
kubernetes,
which
gives
you
like
an
incremental
notification
feed.
A
A
This
would
mean
that
the
api
server
would
then
end
up
opening
multiple
watch
connections
to
hdd.
Also,
the
problem
with
this
is
that
you
can
only
have
a
certain
number
of
watch
connections
at
a
particular
point
of
time
and
beyond
which
things
are
going
to
start
degrading
for
you.
So
to
try
and
sort
of.
A
Make
this
more
efficient?
What
folks
then
ended
up
doing?
Was
they
made
a
cache
which
was
they
made
a
cache
in
the
api
server
itself
called
the
watch
cache
and
the
purpose
of
the
watch
cache?
Was
you
open
up?
One
watch
connection
to
xcd,
which
then
fills
in
all
events
and
objects
that
that
watch
connection
gets
and
it
fills
it
into
the
watch
cache
which
is
just
like
a
map
ultimately,
and
then
all
clients
then
open
up
connections
to
the
api
server
and
then
get
it
through
the
watch
cache
itself.
A
A
A
B
A
Yeah,
so
the
efficient
detection
of
changes
right
like
pagination
and
junction
that
right
now
is
in
beta
and
one
of
the
goals
to
make
it
ga
is
to
sort
of
unify
the
resource
version
semantics.
So
if
you
read
what
the,
if
you
read
what
right
now
the
resources
and
semantics,
are
it's
a
little
unintuitive
to
understand?
Okay,
so,
for
example,
right
like
if
you
specify
a
limit
and
a
continue
in
your
request,
the
the
request
will
directly
get
routed
to
a
lcd.
A
Yeah
yeah,
that's
one
of
the
reasons,
and
now
what
we
are
working
on
is
evolving.
The
watch
cache
in
a
way
that
we
can
support
pagination
through
the
watch,
cache
itself
and
the
movement
we
are
able
to
achieve
that.
We
can
sort
of
unify
the
behavior
of
these
resource
versions,
yeah
and
sort
of
get
rid
of
these
disparities
and,
like.
B
A
And
so,
okay,
let
me
if
you
look
at
the
code
right,
there
is
like
a
function
in
the
code
which
says
it's
literally
called,
should
delegate
list
so
like
it.
It
decides.
If
we
should
delegate
the
incoming
list
call
to
fcd
or
not
and
one
of
the
checks
there
is.
Is
it
a
limit
call
or
like?
Is
it
a
list
called
with
a
limit
parameter
or
is
it
a
list
called
with
a
continued
parameter
so.
A
Yeah,
so
this
is
actually
really
interesting
because
we
sort
of
try
and
mimic
how
hcd
does
things
internally,
but
in
a
minimal
way
in
in
the
api
server
itself
right.
So,
instead
of
an
indexer,
we
make
use
of
a
b
tree
and
sort
of
traverse
that
to
like
get
results
for
us
and
the
continuation
token,
which
we
generate
so
right
now.
The
continuation
token
has
a
deadline
which
is
about
five
minutes.
A
A
A
A
A
A
A
A
A
This
is
actually
like.
The
second
part
of
minimizing
lock
attention
there.
Initially,
what
we
did
was,
instead
of
making
everything
and
copying
it
under
a
lock.
We
sort
of
introduced
like
two
pointers
and
made
it
at
interval
pointing
into
the
cache
and
then
the
interval
sort
of
moved
forward.
Asynchronously.
A
Like
there's
a
a
lot
of
work
being
done
to
like
optimize,
this
part
like
it's,
it's
giving
really
nice
scalability
outcomes
for
us.
This
is
like
the
next
step
of
it,
which
is
like
really
exciting
to
me,
at
least
so,
if
you
are
interested
reach
out
to
api
machine,
your
scalability
or
just
comment
on
the
issue.
If
there
are
things
that
you
want
to
pick
up,
I'm
sure
like
people
would
love
extra
an
extra
set
of
hands.