►
From YouTube: Kubernetes SIG API Machinery 20220907
Description
* [shyamjvs] Make gzip compression configurable on the apiserver (revisit of June 15th)
Switching to compression level 1 looks like an easy win for cpu and latency to last byte as measured by the client
The 20mb/s limit is actually a limit in the default golang gzip compressor
There is a non-standard, parallel gzip compressor that claims 100x improvement in throughput. Perhaps that would be useful to do a CPU analysis on
Adding the ability to specify compressed or not in a kubeconfig was well received
Idea for changing compression per resources -- david and daniel weren’t excited about adding knobs for this.
* [jpbetz] CEL for Admission Control KEP overview (slides, KEP)
How will we allow schema evolution for the configuration?
Secondary authorization check as a requirement for beta? not for a first alpha.
Joe was open to this. Tim Allclair had concerns, but didn’t get a chance to explain in the meeting. Daniel had previously had concerns, but brought up a use-case that would benefit
How is user information accessed?
Will we support a pattern of namespaced resources holding configuration for each namespace like quota?
* [deads2k] P&F 1.26 plans - v1beta3 or v1? (v1beta2 starts deprecation period in 1.26)
We need a v1beta3
A
A
time
is
flying
and
the
year
is
flying
by
so
I
don't
know
carpe
diems
easier
days.
So
thank
you
for
everybody
that
was
able
to
join.
We
have
three
topics
today
in
the
agenda
and
let's
get
to
them
right
away.
The
first
one
is
one
that
we
postponed
for
last
meeting.
We
wanted
daniel
to
be
able
to
make
it
daniel
is
here
she
am.
I
see
you
there
right,
okay,
very
good,
so
why
don't
you.
B
B
Now
I
just
put
a
link
in
the
chat
for
the
doc,
where
I
try
to
summarize
the
findings.
I
hope
I
think
it's
shareable,
so
I
hope
folks
can
open
that
okay
yeah,
so
so
I'm
not
sure
how
we
typically
do
these.
Since
it's
a
dock,
maybe
I
can
like
given
this
this
link,
I
can
have
folks
review
offline,
and
here
maybe
I
can
go
through
some
of
the
some
of
the
high
level
points.
If
you
prefer
that.
A
B
B
Only
then
the
server
tries
to
compress
and
just
to
note
here
as
we,
we
disabled,
that
for
local
controllers,
like
scheduler
controller
manager
and
stuff
later
on,
did
this
a
while
ago
to
to
save
on
the
cpu
cycles
and
and
stuff,
and
this
is
also
only
applicable
to
resource
type
apis.
So
all
the
streaming
type
calls
like
logs
for
proxy
for
portfolio.
They
don't
get
gzip
gzip
compass
today.
This
is
my
reading
of
the
code.
If
at
any
point
I'm
wrong,
please
correct
me
and
yeah.
B
B
C
B
I
I
tried
clarifying
that,
so
the
thing
is
for
a
lot
of
requests.
You
only
have
the
chance
to
decide
whether
to
gzip
compress
or
not
at
the
start,
because
once
you
set
the
sender
client
that
we
are
gzipping,
then
you
have
to
respect
that
or
if
you're
not
gzipping,
you
have
to
respect
that
throughout
because
for
someone.
C
B
D
B
B
Yes,
yes,
so
I
I
put
a
link
there.
Actually,
maybe
if
you
can
quickly
open
the
federaco
yeah
it
it
is,
I'm
just
trying
to
recollect
it
myself,
but
sorry.
I
think
that
is
the
wrong
link
it's
somewhere
down
below,
but
essentially
I
think
it.
It
is.
My
understanding
is
it's
whatever
the
response
is
sent
to
the
writer,
the
initial
so
for
most
calls.
D
Okay,
so
the
answer
is,
is
whatever
happens
to
be
so
after
we
have
done
whatever
we're
gonna
do
and
we're
about
to
call
the
write
function
on
the
thing
that
is
actually
going
to
emit
the
bytes.
It
is
the
size
of
the
first
thing
that
has
passed
to
this
write
function,
which
is
kind
of
a
random
way
of
doing
it.
But
okay.
B
B
Yeah
yeah,
so,
okay,
if
you
go
back
to
the
doc
yeah,
so
that's
the
state
and
also
we
hard
code,
the
gzip
compression
value
to
the
g
compression
level
to
four.
It
allows
one
to
nine
or
you
can
turn
it
off
altogether
or
one
to
nine
is
like
fastest
compression
to
highest
like
most
compression,
and
our
default
in
kubernetes.
Today
is
four
right.
So
what
I
found
through
these
experiments
and
I
think,
there's
a
spiral
set
of
experiments
that
was
also
done
by
machik
from
six
scalability.
B
We
actually
came
to
very
similar
numbers
there
and
what
is
the
impact
of
this
gzip
compression
on
these
responses
right?
So
I
created
a
benchmark
here
right.
I
explained
the
test
methodology
if
you
scroll
down
below
essentially
yeah
like
I,
I
took
like
a
big
box
for
the
api
server
and
a
big
box
for
the
lcd,
so
that
between
api
and
lcd
there
is
no
network
latency
in
those
kind
of
restrictions
and
then
for
client.
B
There
are
two
cases
I
take
a
small
client
like
so
essentially
a
client
is
nothing
but
I
created
a
program
the
code
also
for
that
is
linkedin.
It's
just
created
a
a
go
program
which
basically
creates
so
a
given
throughput
of
requests
spread
across
like
n
clients,
you
just
round
robin
and
make
clients,
but
all
of
them.
It's
a
go
program.
That's
running
on
the
on
this
client
and
the
vm,
for
that
is
like
two
cases.
B
B
So
if
you
go
back
to
the
dock
again
yeah,
so
there
are
a
bunch
of
test
parameters
which
we
can
tweak
like
the
sizes
of
the
apis
or
lcd
and
the
client
right
and
the
list.
Throughput
number
of
clients
used
the
size,
the
actual
volume
of
the
response
size-
and
there
are
two
other
parameters
which
I'll
talk
about
subsequently
is
one
is
the
entropy
of
the
objects
which
decides.
B
Actually,
how
much
does
do
you
actually
does
gzip
compress
right,
so
some
objects,
as
it
turns
out,
are
much
more
compressible
than
others,
for
example,
things
like
pods
and
nodes
right.
They
have
a
lot
of
repeating
substrings,
so
it
gzip
can
do
a
lot
compressing,
but
things
like
conflict
maps
and
secrets
where
you
typically
hold
a
base64
blob
of
data
that
isn't
it's
too
random
and
there
isn't
much
you
can
actually
compress
so
the
most
of
the
wins
you
actually
get.
B
There
is
basically
from
basically
like
huffman
encoding
converts
base64,
so
it
converts
every
byte
to
actually
six
bits
because
it's
base
64..
So
you
get
three
fourth
reduction
just
by
doing
huffman
encoding
and
then
the
final
thing
is
the
gzip
compression
level.
So
one
is
you
can
disable
it
all
together
or
you
can
also
change
the
levels.
Last
time
I
was
speaking
about
disabling
it
all
together,
but
just
also
want
to
bring
up
the
level
one
which
is
the
fastest
compression
and
yeah
and
show
like
how
much
it
is
offering
right.
B
So
if
you
keep
scrolling
down
at
any
moment,
please
pause
me.
If
you
have
any
questions
with
any
of
these
so
yeah.
Here
I
give
specs
of
the
instances
on
which
I
ran
the
on,
on
which
I
ran
the
tests,
along
with,
like
the
clients
network.
Bandwidth
is
one
important
factor
here
for
the
server
and
the
api,
so
api,
7
and
lcd
they're
big
instances.
B
Like
I
mentioned
earlier
and
yeah,
I
created
a
list
called
throughput
of
one
qps
right
and
each
list
call
returns
roughly
420
mb
of
response
size
like
420
mb
of
like
the
uncompressed
response
size
based
on
the
number
of
objects.
I
created
10
000
config
maps
each
around
like
42,
40,
42,
kb,
right
and
yeah,
and
then,
like
I,
compare
the
the
metrics
here
right.
So
if
you
scroll
down
further-
and
these
are
the
metrics-
I
I'm
looking-
I
was
I've
observed-
let
me
know
if
there's
any
additional
metric.
B
We
should
also
look
at
this
was
based
on
discussion
with
a
few
folks
last
time.
So
one
is
the
network,
bandwidth
usage
between
client
and
the
api
server,
and
also
api
and
lcd.
Just
for
the
aps
or
lcd.
There
is
no
gzip
compression
for
that
part,
but
just
for
posterity
to
make
sure
that
that
my
test
cases
are
actually
making
equal
number
of
requests
and
the
other
important
thing
is
cpu
memory
usage
on
most
importantly,
the
api
server
and
and
the
hcda
and
client2
and
the
final
is
the
list
request
latency.
B
So
this
one
is.
This
is
the
most
trickiest
one,
because
this
is
this:
takes
into
both
the
compression
time,
as
well
as
the
time
to
send
the
response
and
depending
on
which
beat
switch.
This
can
be
either.
This
can
go
up
or
go
down
in
certain
scenarios,
but
what
I
have
actually
observed
through
these
tests
is
even
for
really
small
clients
reducing
if
not
turning,
jesus,
reducing
gzip
level.
Four
to
one
still
reduces
the
illustrated
latency,
because
the
gains
from
the
gzip
is
actually
it
the
gains
from
gzip
network.
B
B
D
Additionally,
I
I've
got
an
additional
question
above
above
we
scrolled
past
something
that
said
the
you
tried
this
on
a
small
client
where
it
didn't
have
that
much
incoming
bandwidth.
I'm
actually
concerned
about
the
opposite
scenario,
where
api
server
doesn't
have
enough
outgoing
bandwidth.
Did
you
try
that
scenario.
B
Yes,
I
can,
I
think
this
someone
brought
this
up
to
me
even
like
within
my
team
earlier,
I
think
the
I
the
problem
I
had
there
was
I
needed
to
run
a
test
on
an
instance
where
cpu
is
high,
but
network
is
low
and
for
most
vms
that
are
like,
like
commodity
hardware
and
stuff,
most
vms,
that
are
available,
at
least
on
aws,
and
I
think
it's
kind
of
pretty
similar
across
providers
to
have
seen
this.
This
is
the
network,
it's
usually
more
so
it's
hard
to
get
a
box
or
you.
D
B
Yeah
so
so
one
thing
I
observed
there,
daniel
was
the
it
is
reaching
cpu.
So
I'll
show
it
subsequently
through
metrics
I'll
show
you,
but
it
is
reaching
highest.
It
is
using
cpu
faster
than
it
is
exhausting
network
bandwidth.
So
before
you
actually
are
able
to
saturate
the
the
network.
Throughput
like
you,
the
cpu
usage
grows
grows
really
high.
So
I
can
show
that
here,
but
okay,
can
you
start
from
the
top
of
the
matrix
federico
yeah,
so
request,
latency
with
user
without
gzip?
B
This
is
these
are
the
average
and
p99
values,
and
I'm
I'm
pretty
sure
at
this
point
that
these
are
actually
pretty
accurate
for
such
similar
setup
because
they're
at
least
two
different
experiments
from
other
independent
people
who
actually
came
with
the
same
number.
I
have
linked
that
subsequently,
the
match
x1
and
there's
another
one
a
while
ago
done
by
someone,
but
this
is
yeah
these,
and
these
are
like
some
sample
latencies
from
the,
and
this
is
clients.
B
E
B
Yeah
yeah,
so
one
was
benchmark,
but
this
these
are
more
end-to-end
tests.
So
the
me
and
marchette
both
of
us
didn't
pick
this,
but
that's
right,
yeah,
so
somewhere
around
20
to
25
mb
per
second
is
the
ghost
standard,
gzip
library,
okay
and
yeah.
So
one
thing
like
we
can
talk
about
it
later
is
one
thing
which
is
served.
Certified
surfacing
is
like,
if
there's
so
much
cpu
available.
Why
is
it
limited
to
20
mbps
20
mb
per
second?
B
Why
can't
it
happen
faster
right
and
the
problem
is,
I
also
inspected
the
goes
gzip
default
implementation
that
library
it
it
is
single
threaded,
so
it
does
not
actually
parallelize
blocks
of
the
rest
like
it
does
not
in
parallel
compress
blocks
of
the
response.
I
think
there
are
some
some
non-standard
implementations
of
that
written
by
some
authors
to
I
think
it's
called
pg,
zip
or
something
that
which
you
can
actually
parallelize
compressing
the
response.
So
the
thing
is
no
matter
how
much
cpu
throw
you
throw
at
it.
The
it's
still
one
single
core
routine.
B
That
is
just
like
taking
these
and
compressing
block
by
block
and
like
flushing
it
out
to
the
underlying
I
o,
I
o
writer,
that's
how
that's
how
it's
working
today,
okay,
so
so
yeah.
So
I
mean
if
you
actually
have
a
lot
of
lists
in
parallel.
It's
still
pretty
good,
because
all
those
core
routines
are
compressing
in
in
parallel.
But
if
there's
a
single
request,
you
are
not
making
the
most
out
of
the
cpu
there
so
yeah.
Can
you
keep
going
down
so
yeah,
so
p99
latencies
this?
B
The
left
side
is
with
gzip
right
side
is
without
using,
but
I
think
I
already
already
saw
the
numbers
there
and
you
can
see
the
hcd
the
lcd.
The
orange
metric
is
the
lcd
latency
and
there
you
can
see
it's
within
without
gzip
it's
very
similar,
and
that
is
how
it
should
be,
because
there's
no
gzip
involved
there
and
yeah
the
cpu
memory
usage
is
the
interesting
part.
So
cpu,
as
you
can
see,
drops
right.
B
If
you
turn
off
these,
it
was
a
pretty
steep
drop
actually
somewhere
from
45
to
like
10,
about
like
four
to
five
times
and
memory
also
dropped.
So
the
memory
dropped
is
an
interesting
fact,
and
I
I
don't
deep
into
it
I'll
explain
soon
why
that
is
happening
so
yeah
if
you
go
down
below
so
that,
so
the
memory
is
actually
an
indirect
effect
of
how
many
requests
are
are
held
in
memory
in
parallel,
if
each
request
becomes
slower
right.
B
B
Sorry,
maybe
I
can
go
faster,
sorry
daniel,
maybe
over
explaining
some
things,
yep
and
the
other
part
is
network
bandwidth
right.
So
the
red
line
is
the
interesting
one.
That's
the
api
server!
That's
traffic
sent
to
the
client,
the
red,
orange
and
green
lines
is
basically
between
aps
and
lcd,
and
that
remains
pretty
same
and
you
can
see
for
the
conflict
map
objects.
The
network
bandwidth
increased
by
about,
I
think,
40
to
50
percent.
B
B
Actually,
if
you
scroll
down
below,
I
gather
data,
so
we
from
I,
I
ran
some
script
across
like
3000
clusters
in
our
production,
and
these
are
production
clusters
and
I
gathered
samples
of
how
much
is
gzip
at
various
levels,
helping
various
object
types,
so
I
think
we
can
skip
past
the
cpu
profile.
The
cpu
profile,
mainly.
B
What
I
wanted
to
show
is
the
that
big
block
of
plate
compressor
is
actually
taking
up
a
lot
of
cycles
and
for
memory
you
can
see
that
it's
roughly
same
with,
and
without
only
thing
is
the
overall,
it's
bulged
by
a
factor.
So
this
is
gzip
level.
One
versus
four-
and
here
also
you
can
see
like
almost
2x
drop
in
cpu
and
and
memory
just
by
going.
B
D
B
B
B
Level
four
yeah,
sorry
yeah
I'll,
try
to
change
that,
but
yeah
and
the
other
interesting
part
is.
You
can
see
the
network
usage
which
almost
doesn't
change
because
for
configmarx
and
secrets
I
also
observed
is
level
four
level.
One
is
basically
the
same
compression
for
other
objects.
There
is
a
2x
factor,
but
but
for
conflict
secrets
map.
This
is
the
case.
If
you
go
down
below
this
is
the
most
interesting
part
actually
yeah.
So
this
is
where
I
collected
data
from
using
from
3000
customer
production
clusters.
B
These
the
font
might
be
a
bit
small
sorry
about
that.
But
these
are
the
distributions
for,
for,
for
each
object
type
at
various
gzip
levels.
What
is
the?
How
much
is
the
compression
factor?
This
is
a
distribution
of
that.
So
you
can.
So
if
you
basically
see
the
one
gzip
level
one
in
the
graph
right
below
that
is
gz
level,
four,
which
are
the
most
interesting
ones.
B
B
Instead
of
going
through
all
these
graphs,
you
can
look
at
that
table.
I
summarized
all
the
so.
This
is
for
endpoint
slices
services
and
so
yeah.
Can
you
go
back
to
that
table
real
quick?
I
recall
the
one
at
this
section,
so
so
people
can
take
a
quick
look
at
it.
Yep,
so
acr
is
average
compression
ratio
at
various
gzip
levels
for
various
object
types.
B
This
is
the
data
I
collected,
because
the
problem
was
any
test
I
was
running
was
with
synthetic
objects,
and
I
didn't
want
to
trust
myself
that
this
is
actually
realistic.
So
I
actually
went
and
sampled
this
from
production
and
you,
as
you
can
see,
secrets
and
config
maps
have
some
of
the
lowest
compressions
secrets
is
like
even
less.
D
B
D
Right,
so
thanks
thanks
a
bunch
shyam
for
this.
Let
me
just
say
what
this
implies
to
me
and
see
if
everybody
else
agrees
or
not
seems
to
me
that
it
would
be
reasonable
to
just
switch
our
compression
from
four
to
one
for
everything
and
the
other
thing
that
seems
reasonable
is
to
make
it
easy
to
opt
out
of
compression
like
a
setting
in
cube,
config
file.
I
think
you
can
already
do
it
in
code,
but
that
it
may
be
inconvenient
for
some
people.
D
C
D
E
So
I'm
looking
at
this
and
I'm
glad
I
finally
have
a
reason
for
why
we
seem
to
be
capping
out
20
megabytes
per
second,
and
I
think
my
question
is
a
little
bit
different.
My
question
is:
why
would
we
stick
with
a
poorly
performing
gzip
compressor?
The
the
link
that
you
provided
was
actually
to
someone
else's
repo
who
claims
that
he
has
a
compressor
that,
I
believe
it
says,
is
compatible
with
gzip
that
runs
10
times
faster,
and
that
would
seem
compelling.
B
So
just
one
thing
to
clarify
is
some
of
these
implementations
actually
parallelize
the
gzip
right?
That
is,
that
may
not
be
a
really
fair
comparison,
because
when
the
cpu
is
exhausted,
you
are
still
doing
only
as
much
work
as
as
you
have,
even
if
you
parallelize,
let's
see,
if
there's
enough
list
through
put
in
flight,
then
you
won't
get
much
wins
by
paralyzing,
so
that
benchmark.
I
am
I'm
a
bit
skeptic
about
like
that.
B
There
are
in
general,
but
I
think
you
bring
up
a
right
point,
which
is:
there
are
various
compression
algorithms
and
even
outside
of
gzip
there's,
I
think
zsh,
which
is
supposed
to
be
at
least
like
two
times
faster
for
similar
compression
ratios
and
stuff.
We
can
consider
alternative
compression
algorithms,
too.
I
think
the
default.
D
One
reason
to
stick
with
gzip
is
because
then
we
don't
have
to
change
any
clients
which
would
be
a
large
undertaking,
but
I
was
I
wasn't
saying
we
shouldn't
make
further
improvements.
I
was
saying
like
if
somebody
gave
me
a
change
to
switch
from
four
to
one
tomorrow,
like
ideal
gtm,
that
that
that
seems
pretty
like
a
pretty
clear
win,
doesn't
mean
we
shouldn't
continue
to
improve
it,
but
but
I
think
that.
B
D
B
B
So
I
think
I
think
okay,
so
maybe
another
thing
I
want
to
talk
about
is
like
a
bit
futuristic.
I
think-
and
this
is
an
idea
which
clayton
also
was
entertaining
earlier-
is
we
might
want
to
override
these
gzip
values
at
an
object
type
level,
because
there
is
a
issue
linked
at
the
bottom
of
this
is
just
an
idea.
You
might
shoot
me
down
totally,
but
I
just
want
to
mention,
because.
B
Because
what
why
you're
saying
is
for
secrets
and
config
maps,
we
can
technically
just
turn
jesus
all
together.
We
don't
have
to
stay
like
this.
One
will
basically
force
us
to
be
at
one
everywhere.
It
helps
a
lot
for
pods
and
nodes
is
what
we've
seen,
but
for
secret
for
secret,
even
one.
It
barely
helps.
D
D
B
E
Can
you
help
me
understand
how
that
compares
to
the
table
for
the
object
type
showing
the
average
compression
ratio
at
four?
I
believe
the
average
compression
ratio
for
configmaps
was
six
and-
and
I
might
be
misunderstanding
what
this
means,
but
I
would
have
thought
that
meant
that
I
should
expect
to
see
one-sixth
of
the
network
bandwidth
used.
B
Yeah,
so
because
this
this
is
from
real
production
clusters,
where
conflict
maps
might
be,
they
may
be
really
small
objects
right
and
they
may
be.
There
may
be
more
of
metadata
and
like
spec
in
those
fields
compared
to
objects
and
stuff,
but
secrets
is
more
prominent
actually
but
and
the
tests
I
used.
I
basically
created
a
huge
blob
of
data,
which
is
90
more
than
90
of
the
object
is
just
the
base64
stuff,
so.
C
D
E
E
B
B
Also
one
one
other
thing
is:
this:
is
comparing
gzip
disabled
versus
enabled
four
versus
one
is
like
a
much
lesser
drop,
because
that
that's
what
that
other
table
showed
and
the
basically
david
you
bring
up
a
very
good
point.
This
is
exactly
the
reason
I
collected
data
from
production,
because
this
is
the
first
thing
I
get
is
like
is:
is
your
workload
even
realistic,
so
yeah?
So
just
don't
consider
much
that
network
bandwidth
part
too
seriously.
D
C
D
C
D
Or
I
think
I
think,
if
we're
gonna
do
something
more
complicated
on
the
table,
we
should
also
consider
switching
to
a
faster
compression
mechanism
which
involves
changing
clients-
or
I
don't
know
intelligently,
like
measuring
network
bandwidth
to
this
client
and
deciding
what
level
to
use
automatically.
Based
on
that.
I
think
there's
a
lot
of
options
if
we're
going
to
do
something
more
complicated,
but
I
think
today,
just
turning
it
down
to
level
one
is,
should
be
a
big
win.
B
Correct
okay,
so
I
think
thanks
for
this
I'll
somewhere
I'll
cut
an
issue
and
summarize
the
what
we
decided
and
I
can
change
that
level
later
this
way.
I
think
basically,
four
things
I'll
quickly
summarize
four
to
one
the
other
is
we
might
want
to
have
cube
config,
a
disabled
compression
field
in
cube
conflict,
so
clients
can
disable
this
from
their
end.
B
D
B
F
F
I
wanted
to
quickly
gauge
the
the
sig's
level
of
interest
to
you
know,
consider
a
cup
for
this
in
126
and
then
also
gets
if,
if,
if
it
is
acceptable,
try
and
convince
somebody
to
be
willing
to
do
an
early
review
pass,
because
I
think
it's
going
to
we
try
and
do
this
like
the
week
before
the
deadline.
I
I
think
it'll
be
hard
to
get
the
reviews
done
for
it.
It's
a
bit
larger
of
a
thing
I
can.
E
F
F
F
F
Yeah
we
can
circle,
we
can
have
outside
discussion
on
that
as
needed.
So
this
is,
I
mean
for
anybody.
It's
not
clear
what
I'm
talking
about
this,
hopefully
kind
of
gives
you
some
clarity
on
just
the
most
basic
way
to
express
the
idea,
which
is
instead
of
having
a
web
hook
for
admission
control
extensions.
You
would.
F
This
has
to
do
with
the
fact
that
a
lot
of
use
cases
are
focused
on
policy
enforcement
and
in
many
policy
cases-
and
this
is
an
example
of
that
you
need
some
kind
of
configuration
data.
So
some
automated
examples
say
you
have
like
a
block
list
and
you
want
to
enforce
that,
like
the
meta
nade
and
like
the
object's
name
is
not
in
the
block
list.
This
is
just
a
really
simple
example
of
using
configuration.
F
So
one
of
the
big
things
we're
trying
to
figure
out
is:
how
do
you
handle
configuration
on
the
next
slide?
I
had
a
really
simple
way
that
this
is
kind
of
what
you
see.
If
you
actually
look
at
policy
enforcement
engines,
what
they
do
is
they
split
between
the
policy
definition
which
I'm
showing
here
on
the
left
and
then
the
policy
application
within
a
cluster,
so
the
policy
definition
is
usually
written
by,
like
you
know
the
owner
of
the
policy
framework,
they
don't
know
like
how
you're
actually
gonna
apply
the
policy
rules.
F
F
If
we
tried
to
retain
their
abstraction,
we
would
have
to
do
something
like
maybe
put
some
information
about
what
the
configuration
schema
is
into
the
definition
on
the
left,
and
then
maybe
we
generate
a
crd
for
that,
and
then
people
create
crs
to
conform
to
that,
and
then
we
have
all
the
information
we
need.
This
is
one
way
to
do
it.
I
have
two
other
ways
so
I'll
come
really
quick.
F
F
You
just
like
flatten
all
the
information
into
a
single
object,
and
so
here,
instead
of
having
the
configuration
being
in
a
bunch
of
objects,
you
just
have
a
list
of
configurations
each
paired
with
their
match
rules.
So
here
I
have
two
one
is
like
for
prod
and
staging
where
the
limit's
a
hundred
the
next
one's
for
test,
where
the
limit's
three
and
so
depending
on
which
match
you
get
determines
which
configuration
you
get.
If
you
match
multiple
configurations,
then
you
would
actually
just
run
the
expression
multiple
times
with
all
the
config.
F
E
So
this
is
g,
not
fully
understanding
what
you've
shown
here,
but
on
the
next
on
the
next
slide,
or
maybe
the
next
one
down
this
one.
These
rules
is
the
schema
for
these
rules
always
effectively
fixed
so
that
the
schema
for
whatever
referenced
type
you
chose
would
have
the
same
schema
over
and
over.
F
Yeah
exactly
so
here
I
mean
you:
could
you
could
even
maybe
infer
the
schema
right
this
one?
The
configuration
has
a
max
replicas
field,
which
is
an
int.
That's
literally,
the
only
thing
you've
got
another
configuration
might
have
multiple
fields
or
be
really
complicated,
but
that's
this
one,
and
in
this
case
it
does,
you
would
only
ever
have
one
configuration
schema
for
this
whole
thing.
So
then
each
each
of
these
rules
is
just
like
conforming
to
that
schema
in
its
config
section.
A
C
F
C
I'm
not
sure
I
guess
I
was
actually
just
trying
to
understand
the
topic
that
someone
brought
up.
You
know
again
they
got
into
the
answers
about
alpha
versus
beta.
You
know
the
question
was
someone
said
something
about
checking
often
involves
looking
at.
I
forget
exactly
the
term
used
secondary
objects
or
something
like
that
secondary.
E
A
C
Is
to
what
extent
we
want
a
complete
solution
out
of
the
box
or,
like
kind
of
how
complete
we
want
that
solution
to
be
because
with
something
like
the
second
option,
or
really
even
the
like
no
config
option,
it
would
be
pretty
straightforward
to
build
a
controller
that
accepted
you
know
any
type
of
api
you
want
and
kind
of
compiled
that
into
a
webhook
or
not
a
webhook.
A
cell
admission.
F
F
E
F
Yeah
in
this
in
this
one
very
near
the
top,
you
actually
declare
what
that
schema
is.
There
could
be
a
variant
on
this
where,
because
all
of
the
data
for
that
schema
is
contained
in
this
object,
you
could
even
try
and
infer
it,
but
I
think
there's
some
corner
cases
where
that
gets
really
messy
like
an
empty
list.
A
A
C
To
answer
the
question,
then,
I
do
understand
the
the
the
virtue
of
the
third,
which
is,
if
it's
you
know,
what's
really
needed.
Anything
else
can
be
layered.
On
top
of
this,
that's
great
except
I'm,
concerned
that
that
gets
to
a
performance.
Anti-Pattern
right.
If
you
get
in
the
business
of
requiring
frequent
updates
to
large
objects,
you've
hurt
yourself.
F
Yeah
the
practical
downsides
to
this
one
are
exactly
that
and
also
that
you
know
you
will
eventu.
You
could
invent
eventually
hit
the
size
limit
on
this,
so
anybody
that
was
writing
those
controllers
would
have
to
deal
like
with,
like.
Oh,
I
think,
I'm
getting
towards
the
object
size
limit.
I'm
now
going
to
generate
two
of
these
admission
control
things
and
and
split
my
my
match,
rules
across
them
or
something
like
that
and
if
you
were
instead
natively
implemented
one
of
the
first
ones.
F
C
F
Yeah,
that's
a
really
good
point.
Typically,
the
the
developer
that
builds
the
policy
rules
themselves
is
different
than
the
person.
That's
configuring
them
to
be
used
in
a
particular
cluster,
and
I
would
expect
that
a
lot
of
cluster
administrators
wouldn't
want
would
would
might
be
quite
a
bit
more
lenient
on
who
gets
to
set
up
some
of
the
settings
on
maybe
their
region
of
a
cluster.
Then
they
would
actually
like
redefining
the
policy
rules.
Yeah.
E
E
E
The
one
other
pattern
I've
seen
for
handling
this
is
to
actually
have
an
object
inside
of
the
namespace
that
a
namespace
admin
isn't
allowed
to
touch
an
example
of
that
would
be
say
quota
where,
in
cases
where
you
want
configuration
per
name
space,
you
can
actually
create
configuration
per
name.
Space
keeps
the
size
of
the
object
down
and
makes
the
rules
about
who
can
access
things
in
certain
namespaces
easy
to
maintain
via
rbac.
F
D
E
I
would
probably
be
biased
towards
having
the
separate
objects,
because
I
know
the
schemas
can
get
very
large
and
trying
to
evolve.
A
schema
over
time
is
something
that
I
will
also
be
asking
about
on
the
cap,
and
I
think
you
already
have
some
ways
for
you
to
manage
that,
and
I
don't
know
whether
you'd
have
to
reinvent
them
here
or
not.
But
that's
going
to
be
an
area
of
concern.
I
have.
F
D
F
That's
a
really
good
question.
I
hadn't
thought
about
per
user
rules.
I
can
look
at
that
as
some
of
our
use
cases
and
see
if
we
can
find
ways.
I
I
expect
that
almost
every
dimension,
where
somebody's
going
to
want
to
be
able
to
like
you,
know,
drill
down
to
that
they're
where
they're
going
to
want
to
over
time.
So
that's
the
sanity
check.
I
think
it
would
be
good
to
see
if
we
can
support
that.
So.
F
Well,
you
will
have
access
to
the
user
info
in
the
admission
request,
so
you
would
already
have
that
in
the
expression,
but
you
would
still
have
to
be
like
checking
every
single
object.
You
wouldn't
be
able
to
do
that
at
match
time,
although
I'm
not
sure
that
that
matters
as
much
anymore
since
you're,
just
like
sells
products
that
you
evaluate.
D
E
E
E
C
E
A
A
They
are
preparing
a
virtual
talk
for
kubecon
on
advanced
api
machinery
topics,
one
is
going
to
be
aggregated
servers
and
the
other
is
going
to
be
open
api
v3,
and
then
I
don't
know
about
the
rest
of
the
group.
Some
people
here
at
google
are
planning
to
go
to
kubecon
in
detroit,
so
we
may
see
each
other
in
person.
A
I
have
to
check
the
dates.
We
still
have
potentially
a
couple
of
meetings
before
qcon,
so
we
will
see
each
other
here
yet
reminder
we
still
do
twice
a
week
back
three
ashes
mike.
Thank
you
for
coming
to
join
us
and
everybody's
invited.
So
that's
all
for
now
for
today.
Thank
you
for
joining
hope.
You
have
a
good
wednesday.