►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: Kubernetes Architecture SIG - Timothy St. Clair, VMware
This will go into deep coverage of SIG Architecture's subprojects including the KEP process, the API review process, conformance testing review, and code organization. Other topics may include the evolving definition of what is in and out of scope for the project, as well as the latest visualizations of the ecosystem. Attendees should have a much better understanding of project architectural layering, governance, and goals.
https://sched.co/MPjl
A
A
So
my
hope
is
that
this
should
be
kind
of
an
informal
conversation.
I
want
to
know
what
it
is
that
you
want
to
know
right
so
part
of
the
kubernetes
community
is
getting
feedback
right.
So
just
to
get
us
started,
my
name
is
Tim
st.
Clair
I
am
one
of
the
co
leads
for
sequester
lifecycle,
I
work,
conformance
cat,
Wrangler
I
work
as
a
sub
project
sort
of
TL
lead
for
sega
architecture,
a
steering
committee
member
and
a
senior
staff
engineer
at
VMware.
A
A
B
C
B
A
I'm
gonna
cover
some
of
that
I
actually
have
bits
of
that
in
my
slide
deck.
So
are
there
other
things
that
people
want
to
know
about
it?
This
is
your
conference.
This
is
your
time.
So,
if
you
want
to
know
things,
if
you
want
to
understand
it,
I
can
go
through
like
a
broad
overview.
But
if
there's
specific
questions
you
want
to
ask
I
really
want
to
know
what
your
feedback
is.
A
What
is
it
you
want
to
know
about
cigars
because
it's
like
a
row
shark
card,
like
the
architecture,
communities
has
many
many
pieces
so
that
I
can
go
into
different
facets,
but
there's
no
way
I
could
possibly
cover
all
of
it
in
a
timespan
like
30
minutes.
So
if
there's
particular
aspects
that
you
want
to
know
now's
the
time
to
ask-
or
you
can
just
feel
free
to
interrupt
along
the
way
and
I'll
pass
the
mic
along
to
oh,
you
see
it.
C
A
A
So
that's
the
common
theme
you
hear
right,
but
I
like
to
demystify
complexity
by
making
it
seem
ridiculous
right,
so
I
say
kubernetes
is
a
toaster
right
and
if
you,
if
you
take
a
step
back
and
you
think
about
how
a
toaster
works
in
unison,
you
apply
that
to
the
core
concepts
of
kubernetes.
It
demystifies
it
and
makes
it
very
simple
to
understand
and
all
of
a
sudden
the
patterns
start
to
emerge
over
and
over
and
over
again,
all
right,
so
declarative
versus
imperative.
Inside
of
the
system,
you
declare
a
given
state.
A
I
turned
my
toaster
to
light
brown
right,
I
hit
the
button
and
then
I
walk
away
for
a
while,
and
hopefully
my
house
doesn't
burn
down
and
my
toast
when
I
come
back,
should
be
light.
Brown
I've
declared
a
state
of
what
I
want
to
do.
I,
let
the
system
I
flip
a
switch
or
submit
my
toast
right.
Then
I
expect
the
system
to
rectify
that
loop
and
then
give
me
back
what
I
expected
right.
So
that's
that's
kind
of
the
basic
concept
behind
almost
all
the
core
/
motives
inside
of
kubernetes.
A
Another
important
piece
here
is
a
highlights,
consistent,
key
value
store
for
storing
what
is
the
declared
state
that
you
want
to
achieve
right
and
in
order
for
you
to
have
a
declared
state
and
also
to
figure
out
where
you
currently
are?
If
it's
not
highly
consistent,
that's
the
bad
feedback
loop!
Imagine
if
you
had
your
toaster
oven
and
you
said
you
wanted
light
brown
and
you
didn't
actually
have
temperature
control.
A
You
could
either
burn
your
house
down
or
you
could
have
never
have
toast
right
so
that
highly
consistent
key
value
store
is
the
way
by
which
you
can
achieve
that
feedback
signal
coming
back
into
your
system
over
time.
The
way
kubernetes
works
is
it's
a
very
rudimentary
feedback,
loop
system.
So
if
people
understand
control
theory
or
if
you
had
like
an
electrical
engineering
background,
their
llama,
the
people
would
think
of
things
like
PID
controllers
for
doing
fast
feedback,
loops
kubernetes
is
very
rudimentary.
A
Everybody's
good,
so
again,
if
you
have
bad
feedback
loops
and
a
part
of
the
challenge
of
crew,
Petty's
is
finding
that
signal
of
where
the
bad
feedback
loops
exist
inside
of
the
system,
because
there
are
some
sometimes
there's
noise
that
resonates
throughout
the
system.
You
can
burn
the
house
down
now
over
time.
A
So
with
that
in
mind,
taking
a
step
back
of
like
what
is
kubernetes,
then
then
seeing
the
broader
picture
of
what
are
the
pieces
of
the
puzzle?
What
does
sig
arch
do?
What's
the
scope
of
sig
architecture,
this
is
straight
out
of
the
Charter
sig
architecture
maintains
it
involves
design
principles
of
kubernetes.
It's
a
very
fancy
way
of
saying
that
provides
consistent
body
of
expertise,
around
conformance
testing,
API
conventions,
architectural
renderings,
design,
principles
and
deprecation
policy.
A
So
that's,
basically,
how
do
we
evolve
the
system
over
time?
Not
only
do
how
do
we
evolve
the
system,
but
it's
also,
the
conformance
aspect,
is
a
little
bit
different.
Is
that
how
what
are
the
expectations
that
we
are
trying
to
set
on
the
system?
So
that
way,
it's
consistent
across
the
ecosystem
of
providers
that
can
occur
that
could
exist.
A
Consistency
is
a
difficult
thing
at
times
in
part,
because
some
of
the
testing
mechanisms
that
we
currently
had
rely
on
behavior
inside
of
the
system-
that's
not
guaranteed
right,
so
we
have
to
make
sure
that
when
we
we
are
vetting
the
intent
test
Suites
that
we
are
creating
it's
relying
upon
the
guaranteed
contract
that
we
are
trying
to
uphold
right.
There's
a
lot
of
little
pieces,
there's
minutiae
inside
the
contract
that
we
don't
support.
So,
for
example,
we
don't
guarantee
that
the
error
messages
are
consistent
all
right.
A
So
if
you
get
a,
you
cannot
like
try
to
enumerate
your
error
state
space
and
expect
to
have
consistent
errors
over
time
that
that's
not
a
contract
that
we
uphold
right.
We
don't.
We
don't
uphold
conditions
either,
so
there's
condition
messages
that
occur
inside
of
the
system.
We
don't
uphold
that
as
consistent
over
time
either.
A
Another
important
aspect
is,
we
also
try
to
revise
and
modify
and
have
input
into
sort
of
the
design
process
or
keps
how
many
people
have
heard
of
kemp's
that's
a
fairly
decent,
so
those
are
kubernetes
enhancement
proposals
when
the
whole
system,
if
you're
gonna
change
an
API,
if
you
want
to
have
something,
it's
a
cross-cutting
feature
such
as
like
making
them
no
modification
that
percolates
into
the
controller
in
the
scheduler.
Those
things
require
a
cap
like
cig
architecture.
A
It
will
be
the
stopgap
review
for
anything
that
cuts
across
those
boundary
lines
and
it
is,
it
is
required
to
have
a
kept
in
place.
Usually
the
process
by
which
caps
are
reviewed
is
if
it's
underneath
a
given,
if
it's
mostly
underneath
a
given
subgroup
that
sig
chair
will
or
sig
TLS
will
review
that
individual
cap
and
try
to
make
you
know
flush
it
out
at
that
level
first,
but
then
will
recognize
that
this
cuts
across
in
that
case,
then
it
has
to
be
approved
by
cigar
ch.
B
Unto
caps
and
riding
Kipps,
so
one
thing
that
I've
heard
a
lot
about
at
this
conference
is:
there's
a
lot
of
people
who
there's
quite
a
bit.
There's
a
quite
a
few
people
out
there
who
are
new
to
kubernetes
or
they
want
to
contribute,
and
they
want
to
do
a
cap.
What
support
and
resources
are
there
out
there
for
people
who,
like
want
to
write
a
camp
like
what
would
you
suggest
for,
if
someone's
new
to
the
community-
and
they
perhaps
want
to
write
a
cap
yeah.
A
So
the
first
thing
you
usually
start
before
you
even
write
the
cap
is
you
have
an
idea
for
a
future
right,
so
I
want
there's
a
certain
aspect
of
kubernetes.
That's
missing
or
some
something
I
want
to
change.
So
typically,
you'd
start
with
your
individuals,
saying
that
you're
a
contributor
on
write-
and
you
discuss
that
with
the
TL.
A
This
even
see,
if
there's
time
to
try
and
fit
that
into
this
cycle
or
next
cycle
right
and
usually
what
the
TL
will
do
is
work
with
you
to
figure
out
what
are
the
boundary
lines
for
a
kept
for
the
feature
that
you're
trying
to
ask
the
most
important
thing
that
I
look
for
in
caps
is
not
necessarily
what
the
individual
goals
are,
but
I
also
really
really
look
for.
What
are
the?
What
are
the
non
goals
that
you're
trying
to
achieve,
because
proposals
can
sometimes
be
way
too
open-ended?
A
And
it's
it's
very
difficult
to
make
sure
that
you
put
the
sort
of
the
legal
mind
hat
on
to
sort
of
say:
where
does
this
stop
right?
So
so
long
as
you're
Lego,
brick
for
your
future
enhancement
is,
is
bounded.
Then,
if,
if
that
passes
that
first
part,
then
you
start
to
work
with
a
kept
with
the
TL
with
the
individual
sig
that
you're
working
with
and
then
then
bump
it
up.
Once
it's
been
reviewed
within
that
sig
up
to
Sagarika
texture,
so
you
would
you
would
work
closely
with
the
TL
/
chair.
A
You
can
also
work
with
the
PM
group
and
sig
architecture
itself
too.
So
there's
there's
many
channels,
usually
I'd,
say
try
to
start
with
your
city
first
and
that
chair
that
TL
and
they'll
be
there
to
help
you,
because
everything
inside
of
the
kubernetes
ecosystem
is
a
servant
set
of
leadership.
If
you
are
in
a
leadership
position,
your
goal
is
to
help
facilitate.
It
is
not
necessarily
to
rule
with
an
iron
fist
or
try
to
control
the
code
right,
yep
and
duplication,
posterior
mission
it.
So
what
are
some
cross-cutting
concerns?
A
There
are
a
lot
of
SIG's
working
groups
and
other
aspects
to
kubernetes.
It
is
the
second
largest
project
on
github.
So
if
you
are
looking
at
at
a
kubernetes
org
chart,
this
is
probably
the
best
example
of
what
exists
currently
today.
So
there
are
many
you.
There
are
several
user
groups
there's
only
one
noted
here
there
are
many
working
groups.
Working
groups
are
meant
to
be
ephemeral,
but
over
time
we
found
that
some
of
these
concepts
are
pretty
complicated,
so
they
hang
around
for
quite
some
time,
and
there
are
several
several
SIG's.
A
It
is
our
goal
within
Sagarika
texture
and
as
well
as
steering
to
kind
of
collapse
some
of
these
under
larger
umbrellas.
So
one
of
the
things
that
you're
seeing
now
too
is
it's
a
collapsing
of
SIG's
under
larger
umbrella
SIG's,
so
like
cloud
provider,
is
a
great
example
of
that.
So
cig
architecture
is
like
the
stopgap
to
help
evaluate
things
that
cut
across
this
entire
org
chart.
A
What
are
some
other
kinds
of
issues
that
aren't
mentioned
before
ambiguous
behavioral
questions
right?
There
are
there's
a
lot
of
concepts
in
kubernetes
right,
the
core
primitives,
the
core
ideas
behind
there
are
actually
only
about
less
than
a
dozen,
but
there
are
a
lot
of
things
built
around
it
right.
A
corpus
of
things
that
are
built
on
top
of
that
those
core
concepts,
so
ambiguous,
behavioral
behaviors
for
API,
is
a
good
example
right,
so
one
API
might
behave
a
certain
way
and
then
another
one
might
be
have
a
different
way.
A
A
good
example
of
this
is
storage.
Storage
has
a
very
unique
API
that
behaves
slightly
differently
than
a
lot
of
the
other
big
api's
so
trying
to
match
the
patterns
and
talking
with
Sagarika
texture
about
like
we
don't
expect
this.
We
want
different
behavior
unanswered
questions.
There's
a
lot
of
them.
You
will.
If
you
look
inside
of
the
code
structure,
for
example,
you
will
be
left
with
more
questions
than
answers,
because
it's
a
constant
work
in
progress.
A
There
was
ideas
of
trying
to
get
to
a
grand
vision
of
a
unified
field,
theory
of
where
we
want
it
to
be,
but
then
practicality
of
trying
to
get
there
became
very,
very
difficult
right.
So
we
kind
of
are
in
this
way
station
of
how
the
code
is
currently
structured.
Now,
there's
there's
a
lot
of
work
to
do
like,
for
example,
for
code
structure,
but
there's
it's
not
by
any
means
complete
and
help
is
wanted
at
any
time.
There
are
conflict
speak
across
chairs
right
and
this
happens
quite
a
lot.
A
You
know
open
source
come
for
the
code,
stay
for
the
drama
right,
so
sometimes
when
you're,
when
you
go
and
a
person
really
wants
to
promote
a
feature
right,
for
example,
getting
windows
to
GA
me
personally,
I
push
back
very,
very
hard
against
that,
but
I,
ultimately,
I
lost
right.
I
lost
for
one
cycle.
I
won
for
several
before
that,
because
we
want
to
make
sure
that
the
features
we
are
producing
have
a
cut
across
the
project
to
be
able
to
support
those
features
right
so,
and
sometimes
the
answers
are
not
complete.
A
We
have
to
sort
of
be
okay,
like
perfect,
is
the
enemy
of
the
good.
We
have
to
be
ok
with
the
idea
of
being
able
to
produce
a
feature
for
this
time
period
to
get
feedback
and
then
refine
that
over
time,
and
always
like
I
mentioned
before.
If
you
want
to
come
before
stick
architecture,
you
must
have
a
kept
pretty
much
to
be
able
to
have
a
conversation.
A
Circa
architecture
nowadays
is
is
basically
a
federated
group
of
sub
projects.
That
is
the
common
pattern.
That's
existing
now
and
kind
of
coming
up
across
the
entire
organization
or
chart
that
I
showed
earlier.
So
the
main
sig
architecture
group
basically
federates
out
most
of
its
work
items
to
these
individual
sub
projects.
There's
an
architecture
and
API
review
group
that
particular
sub
projects
led
by
Jordan
Liggett,
where
he
goes
through
and
will
review
individual
api's
and
it's
a
very
exhaustive
process.
A
Then
there's
a
chord
organization,
sub
project,
that's
run
by
dims
and
that
that
is
very
open-ended
in
a
kind
of
subjective
right
there.
There
are
objective
pieces
that
you
could
probably
say
are
non-controversial
and
there
are.
There
are
ones
that
taste
in
style
right
if
you're
looking
at
kubernetes
as
a
as
a
idiomatic
style
of
go
way
to
structure
your
posit
ory,
you
are
looking
in
the
wrong
place.
A
Kubernetes
is
a
very,
very
large
project
and
stretches
the
boundaries
of
what
most
people
had
even
expected.
So,
as
a
result,
there
are,
there
are
weird
et
or
sink
recedes
and
what
would
be
helpful
from
the
community
is,
if
you
have
like
experience
across
many
different
projects
and
you've
dealt
with
this
before
in
other
projects,
is
to
feedback,
then,
in
that
signal
right.
A
Echo
chamber,
like
we
need
diverse,
set
of
opinions
from
a
diverse
group
of
people
to
make
sure
that
we
are
doing
right
by
the
people
in
the
community
right,
because
if
the
person
comes
to
the
project
and
they're
just
in
shock
and
awe
when
they
first
come,
there,
that's
not
helpful
right.
We
want
to
be
able
to
unwrap
individuals
to
say,
like
you
can
start
here
first
and
then
this
makes
the
easier
second,
so
the
the
ideally
we
want
to
get
to
the
point
where
we
have
a
very
smooth
clean
transition
of.
A
A
Last
but
not
least,
is
the
conformance
definition
and
review
process.
That's
the
sub
project
that
I
lead
and
work
on
in
that
sub
project.
We
we
spend
a
lot
of
time
going
through
the
existing
test,
suite,
which
has
a
corpus
of
thousands
and
thousands
of
tests
right
now
and
trying
to
vet
them
and
get
them
into
a
good
enough
state
so
that
they
can
be
consumed
by
the
entire
community.
A
So
when
you
stand
up
a
cluster
in
the
wild
or
whether
it
be
on
geeky
eks
aks
by
yourself,
the
hard
way
whatever
you
should
always
run,
the
conformance
test
suite
against
your
cluster,
to
guarantee
that
that
what
you
are
running
meets
a
certain
criteria
set
of
expectations.
If
it
does
not
pass
a
conformance
test
suite,
it
is
not
officially
sealed
and
stamped
by
kubernetes,
and
there
are
a
lot
out
there
right.
A
So
if
you
are
using
a
hosted
service
offering
from
X
Y
Z,
you
should
run
the
suite
and
verify
and
talk
to
your
provider
to
make
sure
that
the
contract
that
we
uphold
or
the
API
behavior
that
we
expect
will
actually
be
matched
by
what
you're,
using
because
the
promise
of
kubernetes
the
whole
purpose
is
fundamental
level
is
to
be
the
abstraction
layer
that
you
can
write
across
different
providers
and
different
clouds
with.
If
that
abstraction
layer
doesn't
hold
true
and
we
develop
balkanization,
the
promise
of
communities
is
lost
right.
A
A
So
I
didn't
want
to
go
into
too
much
of
some
of
this,
so
there
are
links
inside
the
slide
deck
that
I
posted
online
API
review
has
a
well-defined
process.
There's
no
way.
I
can
possibly
go
through
all
the
details
of
what
an
API
review
is
in
this
in
this
deck.
But
what
I
do
want
to,
let
you
know
is
that
if
you
go
to
the
kubernetes
project,
there
is
a
project
board
that
exists.
A
So
if
you
are
ever
sees,
if
you
are
in
the
communities
project-
and
you
want
to
see
or
if
you
want
to
actually
promote
something,
the
bots
are
being
modified
and
currently
to
say
slash
project.
And
then
you
say:
what's
your
project,
you
are
project
you
are
working
on
that
will
get
you
on
the
project
review
board
in
order
for
you
to
actually
be
a
to
get
eyeballs
on.
What
you
are
working
on,
the
kurenai's
project
is
so
large.
A
If
you
just
submit
a
Rando
PR
odds,
are
it
will
not
be
seen
there's
just
way
too
much.
The
currently
there's
like
several
thousand
open
pr's
that
or
there's
a
thousand
open
PRS
and
several
thousand
open
issues
right
and
there's
a
there's
about
a
group
of
four
api
reviewers
right,
so
four
or
five
that
are
very
active
jordan's.
The
most
active
he's
really
like
the
the
standard-bearer
dealing
with
90%
of
the
api
reviews,
and
if
you
think
about
that
that
doesn't
really
scale,
so
we
need
automation
and
again
we
need
your
help.
A
So
we
have
a
bunch
of
documentation.
So
if
you
are
super
interested
in
API
structure
and
how
API
is
work,
I
highly
recommend
reading
the
document
that's
listed
here
and
going
and
shadowing
an
API
reviewer
write
it.
You
will
find
it
is
very
illuminating
to
understand
how
the
system
works
and
if
you
just
want
to
know
more
about
it,
that's
a
good
process
to
go
along
with
it,
and
there
are
also
our
recordings
that
already
exists.
A
So
you
know
you
don't
necessarily
always
have
to
shadow,
and
let
because
you
know
some
of
those
people
are
super
busy.
If
you're
serious
about
it.
You
should.
But
if
you
just
want
to
see
the
process,
there
are
recordings
that
exist
up
on
YouTube
today
that
actually
walked
through
the
process
in
totality.
A
Next,
the
conformance
and
test
promotion.
Again
we
have
a
project
or
just
like
the
other
one.
Currently,
our
project
board
that
we
are
working
on
is
a
lot
busier.
There
are
several
several
things
that
are
currently
in
flight.
There's
a
lot
of
things,
inbound
things
that
are
ongoing.
If
you
are
new
to
the
project
and
you
want
to
get
involved
from
the
outside
in
this
is
an
excellent
way
to
get
engaged.
A
You
will
sort
your
looking
at
it
from
an
external
behavioral
perspective
right
and
you're,
trying
to
guarantee
or
qualify
the
api's
that
currently
exists
so
doing
that.
Sometimes,
when
you
work
from
the
outside
in
it's
a
it's,
a
very
good
way
to
understand
how
the
system
works
and
functions,
and
sometimes
you
will
be
surprised
by
what
you
learned
like
I
didn't
know:
I
happened
that
happens
to
me.
I
mean
I,
worked
on
the
project
since
the
very
very
beginning
and
I'm
always
intrigued.
A
Every
now
and
again,
that's
new
didn't
know
that
or
the
knowledge
that
I
had
originally
is
now
no
longer
applies.
So
what
I
thought
worked
XYZ
years
ago
now,
when
I
test
it
out,
is
not
the
same
as
it
was
right
so
working
from
this
type
of
mindset
away
from
the
outside
in
helping
the
conformance
effort,
it
is
very
helpful
to
a
project
and
it's
a
great
way
to
learn
court
organization.
This
is
subjective.
A
It's
highly
subjective.
People
are
very
opinionated
too,
but
there
are
long-standing
opinions.
If
there
are
no
nodes,
there
are
unknown
unknowns.
The
the
no
nodes
is
there's
a
lot
of
current
work.
That
already
exists
that
people
want
to
that
need
help
right.
A
lot
of
the
code.
Restructuring
is
not
easy.
It's
go.
A
Go
does
not
do
well
with
like
shifting
stuff
around,
like
you're
gonna
have
to
update
every
file
right,
so
those
type
of
modifications
require
help,
so
there's
some
other
ones
that
require
more
heavy
lifting
right
in
the
ideal
world
in
the
fullness
of
time,
kubernetes
is
a
set
of
repositories
and
not
a
mono
repo
right.
That's
the
ideal
thing
that
we
always
tried
to
aim
for
it,
but
it's
kind
of
stopped
right.
It
stopped
in
part
because
api's
are
not
v1.
A
If
we
can
get
all
the
api's
to
a
well-defined,
stable
state,
we
could
federate
out
repositories
a
lot
cleaner,
because
we
have
so
much
churn
but
think
about
what
happens
every
time.
I
change
an
API,
the
the
code
is
structured
in
a
document
view
model.
So
if
you,
if
you
follow
old
patterns,
if
you're
like
super
old,
like
me
and
and
you've,
read
idioms
before
patterns
even
exist
in
your
patterns,
then
all
patterns
don't
apply
because
you
know
you
can
get
around
with
compiler
tricks.
A
Then
you
realize
that
it's
a
document
view
and
with
a
document
view.
That
means
your
dependencies
exist
all
over
your
code
and
the
API
is
the
contract.
So
if
you
want
to
be
able
to
restructure
something,
if
you
want
to
move
your
code
around,
if
you
want
to
change
some
very
simple
primitives,
all
of
a
sudden
those
things,
percolate
and
cut
across
the
entire
repository,
the
dependency
graph
is
huge,
so
code
restructuring
for
getting
things
out
of
the
repository
like
getting
the
the
componentry
separated
out
will
only
really
happen.
A
Once
api's
are
fully
promoted
to
2v1
once
they're
in
that
stable
state
they
can.
It
can
be
done
it
every
way,
but
there's
a
lot
of
other
meccans
that
can
occur
along
the
way
go
module
support
is
one
of
the
things
that
people
are
working
on
and
again,
if
you
want
to,
there
is
a
separate
project
board
that
you
can
take
a
look
at,
and
they
also
have
a
current
backlog
in
progress.
Dimms
is
the
lead
of
that
they
have
their
own
separate
meeting.
You
can
always
attend
that
too,
if
you're
interested.
A
So,
with
all
that
mind,
sig
architecture
has
broad
goals,
like
the
larger
group
sees
at
a
50,000
foot
view
of
the
the
landscape
like
where
we
ideally
want
to
go
with
the
project
right
I
do
in
in
the
fullness
of
time.
We
ideally
want
to
lock
down
the
core.
The
core
should
be
less
iterative
than
it
currently
is.
So
in
order
for
us
to
do
that,
we
need
to
promote
API
extension
mechanism
and
an
extension
policies
that
exist
inside
the
system.
A
A
lot
of
that
exists
today,
but
I
wouldn't
say
it's
fully
mature
right,
see,
RDS
are
still
in
beta.
We
need
CRTs
to
be
GA,
but
even
now,
even
after
that,
it's
gonna
take
some
time
before
all
of
the
feedback
loop
from
the
ecosystem
comes
back
in
to
play
it
so
that
we
kind
of
harden
things
and
modify
things
for
series
and
as
well
as
other
extensions.
A
What
we'll
probably
see
happen
to
over
time
and
I
already
see
it
today,
it's
highly
opinionated,
so
I'll
save
my
opinion
till
the
end.
If
people
want
to
ask
me,
what
that
would
opinion
is,
is
that
you
see
patterns
that
exist
out
in
the
ecosystem.
Some
of
those
patterns
become
fractal
and
then
the
same
pattern
that
exists
over
and
over
right
and
those
fractal
patterns
should
really
be
distilled
down
into
core
concepts
that
exists
inside
of
kubernetes,
because
why
reinvent
the
wheel
five
different
times
and
make
five
to
her
mistakes?
A
A
We've
gotten
to
a
really
good
state,
I
think
at
this
point,
as
far
as
like
maturity
of
the
organization,
but
we
still
have
a
problem
with
reliability
in
part
because
it's
tough
right.
This
is
a
distributed
system
and
it
requires
a
set
of
tests
that
go
beyond
the
standard
end-to-end
tests.
So
how
many
people
have
ever
installed
a
kubernetes?
You
know
1.14
dot,
anything
that
has
a
dot
zero
at
the
end.
All
right
have
you
used
it
in
production,
you're,
crazy
man.
A
So
so,
if
you
used
a
dot
zero
in
production,
you,
you
are
a
far
braver
than
90%
of
the
people.
I
know
if
you
use
it
in
dev
I
have
this:
is
this
is
kind
of
the
the
model
that
we
want
to
get
to?
Is
we
want
to
get
it
to
the
idea
where
we
sort
of
publish
things
as
a
dot?
Zero
is
a
good
dev
release
right
and
you
know,
update
your
dev
clusters
installing
a
dot,
zero
and
prod
has
no
the
number
of
PRS
that
we
get
after
we
release.
A
Kubernetes
release
depends
upon
the
cycle.
It
can
be
in
the
order
of
hundreds
that
we
get
shortly
afterwards,
because
all
of
a
sudden
it
gets
in
the
wild,
then
we
find
all
the
things
that
we're
missing.
Either
a
test
coverage
or,
like
oh
I,
didn't
know
we.
We
never
even
expected
that,
and
that
happens
all
the
time.
But
if
you
look
over
like
a
larger
timespan
like
we
have
graphs
of
this
and
like
the
114
series
currently
has
500
PRS
and
get
diff
between
that
and
the
actual
one
14.0.
A
So
that's
got
to
tell
you
that,
like
reliability
is
important,
having
people
help
to
focus
on
reliability
and
testing
and
actually
become
beta
testers
for
a
lot
of
these
things
and
if
they
are
ever
have
your
own
test
Suites,
which
I
know
people
that
use
it
in
prod.
Do
you
know-
and
you
have
your
own
qualification
procedures
for
your
next
kubernetes
release?
And
if
you
don't,
you
should
because
the
the
dodgy
release
is
not
guaranteed
another
thing
that
we're
focusing
on
it's
not
just
kubernetes
proper.
A
A
But
it's
a
great
way
to
like
learn
about
the
system,
to
learn
about
the
community
to
learn
about
how
things
function,
because,
without
help
from
the
community
things
won't
last,
this
is
this
is
something
that
we
all
kind
of
share
together
and
in
order
for
us
to
actually
lift
all
boats,
a
rising
tide
lifts
all
ships.
In
order
for
you
to
do
that,
you
need
to
step
up
and
contribute
right
like
we
need
you,
we
need
the
community
to
help
us
make
this
better.
A
A
So
so,
as
I
mentioned
before,
there's
all
these
different
areas
that
you
can
help
contribute
both
on
say,
architecture
and
across
the
project.
If
you
are
interested
in
Sync
architecture,
specific
things,
there
are
slack
channels,
there's
mailing
lists.
You
can
go
to
the
community
website
and
there's
a
separate
page
that
lists
on
all
the
details
that
exist
there.
All
the
sub
projects
have
their
meeting
notes
inside
there
too,
as
well.
So
if
you
want
to
attend,
I,
haven't
recommend
just
taking
a
look
at
the
project
board,
see
what's
interesting,
go
to
a
zoom
call.
A
You
know
and
stand
up
and
say,
like
hey
and
kind
of
interest
in
helping
out
you
know.
Is
there
anything
I
can
work
on
here
and
I
guarantee
you
no
one's
gonna
say
no
to
you.
There's
there's
more
work
than
there
are
people,
so
if
you
are
interested
in
helping
out
and
wanting
to
contribute,
feel
free
to
take
a
look
at
those
project
boards
reach
out
in
sig
architecture,
on
the
slack
channel
or
the
mailing
list,
and
just
speak
up
and
attend
the
meetings
with
that.
Thank
you.
A
C
I've
put
the
caps
in
general.
The
one
thing
that
we
found.
Actually
this
week
was:
if
you
have
submitted
a
cap
and
then
someone
just
has
a
question
afterwards.
The
only
way
around
that
for
them
to
get
the
question
out
there
without
posting
to
me
a
list
or
something
is
opening
up
PR
and
then
asking
like
in
specific
line.
What
do
you
mean
by
X
or
Y?
Do
you
know
any
way
around
that,
or
has
this
come
up
before
so.
A
Yeah,
so
if
there's
contention
which
can
exist
like
Ingrid,
that's
a
really
thorny
topic
right,
like
ingress,
has
not
been
like
fully
flushed
out
since,
like
the
initial
inception
of
it
right
and
I
know,
Dave
Cheney
has
very
strong
opinions
on
what
ingress
should
be
and
should
not
be
that
you'd
have
to
work
with
like
Hawkins
to
get
that
into
a
happy
state,
because
he's
got
long-standing
opinions
that
exist
there
as
well.
So
he's
the
chair
for
cig
networking,
I'm,
not
yeah
I'm,
not
good
architecture,
usually
won't
Trump.