►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
SIG Architecture Intro And Deep Dive - John Belamaric, Google & Davanum Srinivas, AWS
Speakers: Davanum Srinivas, John Belamaric
SIG Architecture maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time. The SIG takes care of evolution of conformance definitions, API definitions/conventions, deprecation policy, design principles, and other cross-cutting concerns. In this talk, we will provide an introduction to SIG architecture, including its role and the various subprojects that support its activities. Additionally, we will provide a community update on the status of those efforts.
A
B
B
A
B
There
is
still
a
lot
of
things
to
do,
and
that's
why
we
are
here
and
the
purpose
of
the
Sig
architecture
is
to
serve
as
a
space
for
the
rest
of
the
things
in
kubernetes
to
come
together
to
hash
out
like
if
there
are
technical
decisions
to
be
made.
If
there
is
some
options
on
the
table
between
multiple
cigs,
how
do
we
come
to
a
single
consensus
that
kind
of
stuff
so
that
these
are
the
goals?
Typically,
that
guide
our
decision
making
process,
also
Okay.
B
For
example,
if
the
tendency
is
to
say
hey
every
release,
you
have
to
do
a
certain
thing,
then
do
we
do
it
manually
or
do
we
automate
out?
You
know
so
it's
automatic
when
we
push
a
tag
for
a
new
release,
then
boom
there's
some
stuff.
That
is
already
done
right,
so
community
over
product
or
company.
That
is
very
obvious.
B
You
know
we
work
for
you
know
we
compete
for
customers
right,
like
he's
working
for
Google
I
work
for
AWS
and
we
are
all
always
competing
and
cooperating
at
the
same
time.
Inclusive
is
better
than
exclusive
one
story.
I
would
like
to
tell.
Is
we
have
people
who
have
been
in
the
industry
for
like
20
years
in
IBM
research?
We
also
have
people
who
are
like
in
their
first
year
at
college
right
like
so.
A
B
B
B
Hey
here
is
the
set
of
things
that
you
need
to
do
here
is
how
you
get
out
of
it
and
in
the
end
the
talker
shim,
for
example,
was
hurting
our
progress
because
we
were
trying
to
support
an
extra
thing
built
into
kubernetes
that
shouldn't
be
there
right
like.
If
you
just
go
to
continuity
project
or
a
cryo
project,
you
will
see
there.
B
There
are
like
10
plus
contributors
right
and
we
were
asking
every
person
who
was
writing
a
PR
or
a
cap
for
node
to
say:
hey
now,
you
are
responsible
not
just
for
the
things
that
you
do
in
cubelet,
but
also
in
the
implementation
right.
So
that
was
a
bad
decision
that
we
had
made.
So
we
try
to
evolve
out
of
it
as
well.
So
we
don't
stay
stuck.
B
B
On
top,
we
are
a
CNC
of
project,
so
the
steering
committee
is
responsible,
for
you
know
anything
that
is
happening
with
the
project
right
like
if
you
need
funds
for
running
a
CA
job
on,
say
Alibaba
or
in
Azure,
or
you
know,
so
we
have
to
scrounge
the
resources,
talk
to
the
people
responsible
and
you
know,
find
funding
all
those
nice
things
that
we
have
to
do.
Plus
the
steering
takes
care
of
like
policies
for
the
you
know
how
we
govern
ourselves
as
well
right,
so
the
steering
is
right
on
top.
B
Similarly,
the
code
of
conduct
and
the
security
response
team
are
right
there
with
the
steering
committee
and
under
under
these.
You
know
on
the
top.
We
have
special
interest
groups.
We
have
it's
kind
of
like
evident
for
some
of
these.
We
we
have
sick
architecture,
which
is
us.
You
know
two
of
us
are
chairs
in.
B
B
You
know
we
have
this
almost
self-obvious
stuff
there.
So
if
you
are
interested
in
kubernetes,
you
would
typically
come
and
work
in
one
of
these
six.
If
you
have
something
to
do
with
storage,
then
you
go
to
sick
storage
and
then,
if
six
storage
and
Sig
node
are
working
on
something
together
and
they
need
to
resolve
something,
then
they
bubble
up
to
Sig
architecture.
So
that's
the
way
that
works,
and
we
have
you
know
other
groups
that
help
us
do
our
job
regularly
as
well.
B
So
that's
just
an
overview
of
the
project
itself
and
now
you
know
where
Sig
architecture
fits
into
this
whole.
You
know
Jenna
puzzle,
okay,
the
scope
of
the
architecture
Sig.
So
let
me
go
back
and
a
little
bit
explain
about
like
a
charter
right.
So
one
of
the
statements
I
made
just
now
was
the
steering
is
responsible
for
everything
right
in
kubernetes.
Now.
B
I
am
also
saying
that
if
anybody,
if
a
group
of
people
want
to
do
some
work
and
they
want
to
define
the
work
that
they
are
going
to
do,
then
steering
will
delegate
that
Authority
and
they'll
delegate
that
area
to
the
Sig
right.
So
we
we
try
hard
to
make
sure
that
six
don't
overlap
as
much
but
and
they
are
distinct
from
each
other
and
the
way
we
do
it
is
by
writing
down
what
things
are
responsible
for.
Each
six
are
responsible
for.
B
So
when
we
were
doing
Sig
architecture,
a
couple
of
things
that
we
ended
up
saying
was
you
know
that
will
be
the
group
that
will
like
collapse
every
all
the
technical
decisions
upwards
as
needed,
but
also
we
were
saying
that
hey.
If,
if
there
are
multiple
vendors
doing
kubernetes,
then
the
look
and
feel
for
an
application
that
is
being
deployed
on
kubernetes
should
be
the
same
right.
We
do
that
through
conformance
test
right
when
folks
want
to
come
up
with
a
new
API
for
doing
something.
B
We
do
EPA
reviews
to
make
sure
that
you
know
it
looks
right
and
there
is
it's
extensible,
it's
composable.
It
can
like
be
updated
over
a
period
of
time.
Like
imagine,
for
example,
one
problem
that
we
had
was
right
at
the
beginning
we
had
one
field
called
I,
you
know
IP
address
and
it
was
like
ipv4
right.
Then
we
said:
okay,
there
could
be
more
than
one
right
and
they
could
also
be
IPv6.
So
how
do
we
go
to
the
point
where
you
upgrade
the
cube?
B
Ctl,
you
upgrade
the
cubelet,
so
there
are
so
many
sign
and
then
there
is
things
that
are
in
the
cni
layers.
We
need
to
change.
So
how
do
we
lock
step
move
everything
forward
because
we
have
backward
compatibilities?
We
have
forward
compatibilities.
So
that
is
the
kind
of
things
that
we
codify
once
we
figure
out
like
okay,
this
is
a
bad
pattern.
Then
we
write
it
down
in
the
API
convention
right.
B
So
similarly,
we
ended
up
doing
many
more
things
and
we
are
also
the
last
one
is
very
important,
which
is:
how
do
we
change
ourselves
going
forward
right?
That
is,
we
have
enhancement
proposal.
In
fact,
the
first
proposal
to
the
process
was
what
is
the
enhancement
proposal,
and
what
does
it
look
like
right
so
that
this
is
the
scope
of
Sig
architecture?
B
A
A
So
we
have
a
bunch
of
people
who
actually
look
at
those
make
sure
that
they're
using
the
proper
naming
that
they're
doing
things
like
internally.
You
know
you
need
to
use
pointers
to
Strings,
because
you
can't
differentiate
between
an
empty
string
and
a
null
string
unless
you
use
a
pointer.
So,
there's
a
bunch
of
little
like
really
minute
details
that
need
to
be
reviewed
and
make
sure
that
all
of
these
apis
work
consistently.
So
all
the
tooling
on
top
of
them
Works
consistently.
A
So
we're
responsible
for
that
process
in
this
group
additionally
sort
of
adjacent
to
that
is
a
complementary
to
that
are
the
deprecation
policy.
So
we
all
know
what
happens
when
you
go
from
a
V1
Alpha
One
to
a
V1
beta
1
to
a
V1
API,
there's
a
certain
time
scale
and
a
certain
types
of
notifications.
We
have
to
do
so.
This
group
also
manages
that
process
as
well
as
those
those
policies
themselves.
A
The
the
production
Readiness
review
is
an
example
of
how
sick
architecture
puts
in
place
sort
of
quality
gates
for
the
rest
of
of
the
development
within
the
organization.
We'll
talk
about
that
a
little
bit
more
in
a
moment,
but
effectively
sort
of
this
slide
or
this
this.
This
set
of
processes
supports
that
scope
that
that
Dems
showed
in
the
previous
slide.
A
Of
course,
that
said,
we
tend
to
be
a
catch-all,
so
whenever
it's
not
clear,
whenever
there's
disagreement
among
cigs
or
within
a
Sig,
the
the
TLs
or
the
leadership
can't
agree.
They'll
often
come
to
us
we're
not
really
an
escalation
point
in
that
we
have
sort
of
the
authority
to
say
this
or
that
sigs
are
quite
independent.
However,
the
people
who
tend
to
participate
a
lot
in
the
Sig
are
very
senior
Engineers.
A
Many
of
the
people
who
started
kubernetes
participate
in
the
Sig,
and
so
people
tend
to
come
to
us
for
guidance
around
those
kind
of
decisions.
What's
going
to
fall
within
those
goals
and
those
principles
that
dims
talked
about
in
the
beginning
and
make
sure
that
that
we're
sort
of
staying
within
the
scope-
and
it
is
within
our
purview-
to
sort
of
publish
those
principles
and
and
require
people
to
to
sort
of
interpret
those
principles.
A
A
Operationally
we
do
this,
those
those
processes
we
showed
are
run
by
different
groups
of
people.
Those
are
sub
projects,
so
this
is
a
typical
structure
in
kubernetes
Tim's
talked
about
steering
committee
Charters,
cigs
sigs
then
take
responsible
area
of
Scopes
cigs
then
have
sub-projects
and
sub-projects
are
run
by
individual
people
who
actually
make
things
happen.
A
It's
not
just
those
little
things
I
talked
about,
but
it's
really
structuring
the
API
in
a
way
that's
going
to
be
familiar
to
our
users,
who
are
using
all
the
other
apis
within
kubernetes.
If
you're
interested
in
participating
in
this.
It's
really
great
there's
a
shadow
program,
so
we
can,
you
know
you
can
go
to
any
of
these
links.
You
can
come
to
Sig
architecture
on
slack
or
talk
to
us
afterward,
but
we
can
hook
you
up
with
the
right
people.
A
Essentially
you
you,
you
say
I'm
interested
in
shadowing
you
go
in
and
you
you
watch
other
people.
Do
these
these
reviews
or
you
go
in
and
actually
you
know,
take
a
pass
at
it
yourself
and
then
get
feedback
from
the
people
who
are
already
reviewers
and
approvers
and
and
I
actually
would
beseech
you
if
you're
interested
in
this
to
do
it,
because,
while
we
have
a
good
set
broad
set
of
of
reviewers,
we
have
a
very,
very
narrow
set
of
approvers.
A
There
are
four
people
in
the
world
who
can
approve
kubernetes
apis,
four
people,
three
of
them
work
at
Google
and
one
of
them
works
at
Red,
Hat
That's,
not
healthy,
I'm
from
Google,
but
I,
don't
think
that's
healthy
I
want
more
people.
I
can't
I
can't
go
to
you
other
companies
and
say
hey
bring
people
up
to
speed
on
this
right.
I
can
do
that
internally
and
we're
working
on
that
too,
but
that's
not
going
to
help
with
that
company.
So
so.
B
The
best
way
to
engage
is
just
come
and
go
to
our
GitHub
repository
and
look
at
pull
requests.
There
is
a
label
called
API
Dash
review,
so
that
is
where
the
API
reviews
get
triggered
right
and
it
just
if
you
just
watch
it
for
a
few
weeks,
you
will
get
a
sense
of
what
is
going
on
who's,
doing
what
how
they
are
doing
it
and
then
going
through
the
two
documents:
the
markdown,
the
files
that
you
see
there.
It
will
give
you
a
sense
of
like
okay.
B
They
face
this
kind
of
problem
before
so
they
codified
a
rule
for
making
sure
that
we
don't
run
into
this.
We
don't
paint
ourselves
into
the
same
Corner
again
and
again
so,
and
then
you
can
appreciate
what
we
are
trying
to
do
here
and
it's
not
just
new
apis.
It's
also
like
they
should
coexist
with
the
existing
apis.
That
is
very
important
too,
and
it
shouldn't
like
somebody
is
using.
Did
somebody
else
write
this
right
like?
Why
is?
Does
this
look
very
odd,
which
it
doesn't
feel
like
any
other
apis?
A
B
One
yeah
yeah,
so
one
of
the
bains
of
what
we
do
here
is
golang
comes
up
with
the
release
every
three
months
right
like
clockwork
so
and
they
don't.
They
support
only
three
going
backwards
right,
so
we
have
to
upgrade
kubernetes
kubernetes
to
newer
versions
of
go
and
that's
not
the
end
of
it.
We
have
a
lot
of
dependencies.
B
We
depend
on
it's
it's
crazy.
You
can
see
the
picture
there
right,
like
that's,
actually
part
of
the
picture,
that's
not
even
the
full
picture.
So
what
ends
up
happening
is
periodically.
We
have
to
revisit
all
the
go
dependencies
that
we
use
and
say
see
if
there
are
any
CVS
that
have
been
fixed
in
a
newer
release
or
some
performance
and
enhancements
that
we
need,
or
some
bugs
have
been
fixed.
B
That
has
been
troubling
our
users
for
a
long
time
and
we
have
to
upgrade,
and
when
you
upgrade
it's
not
just
one
dependency
upgrade.
The
dependency
typically
have
other
dependencies.
So
we
have
to
like
manage
the
upward
movement
of
all
the
dependencies
as
well.
So
typical
bottlenecks
are
like
hcd
dependency.
When
we
upgrade,
we
run
into
trouble
the
open
Telemetry.
We
ran
into
trouble
like
they
had
like
10
different
packages
that
we
needed
to
upgrade
to,
and
it
wasn't
very
clear
which,
which
one
works
with
what
right.
B
B
B
So
it
is
a
really
good
when,
when
the
effort
that
you
take
over
some
of
these
things,
when
we
want
to
drop
like
duplicate
dependencies,
you
know
Fork
of
one
thing,
but
it's
used
differently
by
two
different
packages
and
things
like
that.
It's
it's
a
very
satisfying
thing.
When
we
get
to
the
point
where
we
actually
reduce,
why
do
we
want
to
reduce
the
the
dependencies?
It
is
because
it's
all
the
dependencies
getting
to
buy
your
binaries
and
the
binaries
bloat
up.
B
A
All
right
enhancements
process
so,
as
Tim's
mentioned
earlier,
we
you
know,
kubernetes
has
grown
into
a
very,
not
only
large
projects
from
the
point
of
view
of
number
of
contributors
and
number
of
users,
but,
of
course,
a
very
impactful
project,
so
changes
to
kubernetes
have
the
possibility
to
cause
massive
damage
across
the
economy.
Frankly,
so
what
that
means
is
that
we're
way
past
years
past?
The
stage
of
you
know
just
willy-nilly
hey:
this
would
be
cool.
Let's
add
this
right.
A
We
we
need
to
be
extremely
cautious
and
mature
about
how
we
Implement
functionality
within
kubernetes
and
really
deeply
understand
the
implications
of
those
changes.
So
several
years
ago,
this
process,
this
kubernetes
enhancement
process,
was
defined
in
order
to
achieve
that,
and
essentially
what
we
do
in
this
is
every
you
know.
Obviously,
if
you're
fixing
a
bug
or
something
like
that,
you
don't
need
to
go
through
this
process,
but
it's
effectively
a
design
review
process
for
any
major
change
for
any
major
new
feature.
B
One
of
the
important
things
that
we
do
here
also
is
when
a
feature
comes
in,
it
comes
in
as
Alpha
right,
yes
and
then
from
alpha.
It
goes
to
Beta
from
beta
to
GA,
so
we
track
the
evolution
of
the
feature
and
when
you
get
to
the
ga,
you
can
drop
the
feature
gate
essentially
right,
like
you,
don't
need
the
trigger
it's
always
on,
but
when
it
is
an
alpha
and
beta,
it
is
good
to
have
the
feature
gates
to
like
toggle
it
on
and
off,
depending
on
whether
it
is
a
development
cluster.
B
A
Exactly
so
this,
this
is
the
process
by
which
we
come
to
consensus
by
process
by
which
we
track
every
time
you
go
through
through
that
those
stages,
you're
you're
gonna,
say:
okay
I'm,
promoting
this
particular
feature,
which
is
this
particular
cap
from
Alpha
debata,
and
it's
going
to
get
some
additional
reviews.
It's
gonna,
it's
there's
certain
criteria
that
are
laid
out.
That's
that's
sort
of
like
you
need
to
reach
this.
The
kept
author
says
before
I
go
to
Beta.
Here's
the
things
I
expect
to
get
out
of
the
alpha
release,
for
example.
A
So
this
is
the
process
by
which
we
do
that.
We
have
a
sub
a
sub
sub-project
team
that
manages
that
process.
In
conjunction
with
the
release
team,
the
release
team
actually
sort
of
runs
that
process
or
runs.
It
encourages
the
authors
of
those
caps
to
move
them
to
that
process,
but
but
sort
of
defining
what
the
contents,
what
the
criteria
are
is
is
done
with
this
team
here,
yeah.
B
Do
you
know
why
this
is
important?
This
is
important,
because
when
you
look
at
change
logs
for
a
release,
you
will
see
exactly
what
changed,
and
this
is
the
process
that
gives
that
information
to
us.
So
we
we
have,
we
would
have
written
it
down
for
you
in
the
change
log.
Otherwise
you
know
otherwise
it's
very
difficult
to
crack
with
the
amount
of
PRS
that
is
coming
in
it's
very
difficult
to
track.
What
is
going?
Who
is
doing
what
and
like
what
do?
A
One
other
area-
that's
the
responsibility
of
Civic
architecture,
is
conformance
testing.
So,
if
you
go,
you
know
if
you
look
at
eks
or
gke,
we're
all
what
are
called
we're
all
we
all
have
that
K
and
we
all
can
use
the
name
kubernetes.
So
the
cncf
owns
that
trademark
kubernetes
and
they
have
a
process
and
each
one
of
us
who
produces
a
either
a
hosted
kubernetes
or
a
distribution.
A
We
have
to
go
and
submit
a
bunch
of
test
results
showing
that
we
comply
with
a
certain
set
of
conformance
tests,
so
that
process
is
run
by
the
cncf
and
then
we
can
only
use
the
name
kubernetes
if
we
meet
those
tests,
but
actually
what
those
tests
are
is
what
the
the
conformance
sub-project
group
decides.
So
we
actually
choose
the
tests
that
Define
what
kubernetes
is
and
who
can
use
the
name
kubernetes.
So
over
the.
B
It
also
feeds
into
the
enhancing
process,
because
when
you
go
ga
in
the
enhancements
for
a
new
feature,
it
better
have
a
conformance
test
right
like
otherwise.
How
will
you
know
that
it
will
work
exactly
the
same
across
providers
right?
So
you
know,
so
we
make
sure
that
when
people
go
to
Beta
itself,
they
have
a
bunch
of
tests
that
will
test
the
conformance.
B
A
They
have
to
be
able
to
run
across
different
architectures.
If
there's
a
bunch
of
a
whole
set
of
criteria,
they
can't
rely
on
optional
features,
like
our
back.
In
fact
is
we
all
use
our
back,
but
actually
our
back's,
not
part
of
conformance,
because
you
don't
actually
have
to
turn
our
back
on
and
so
there's
some
there's
some
subtleties
there
right.
We
we
so
we've
had
a
team,
since
they
have
hired
a
team
of
folks
from
II.
A
A
95.7
so
this
started
at
like
60
or
something
a
couple
years
ago,
so
we
put
in
place
policies.
That
said
what
Tim
said
earlier,
if
you
go
to
GA
and
you're,
not
an
optional
feature,
and
you
meet
these
certain
criteria,
you
must
have
a
conformance
test,
so
we
didn't
dig
ourselves
deeper
in
that.
But
then
we've
been
backfilling
tests
for
for
a
couple
years,
so
we're
very
excited
to
see
that
that
moving
forward.
B
A
Rest
yeah
production
ready,
so
this
we
instituted
a
few
releases
ago,
I
think
20
1.21.
It
became
mandatory
in
that
kept
process.
We
added
one
more
little
gate
and
this
is
we
get
complaints
right,
we're
currently
in
a
position
where
we're
we're
putting
Gates
on
people
and
we're
creating
bureaucracy
in
their
minds.
But
it's
for
the
reason
I
said
earlier,
like
you
Chuck
something
into
kubernetes,
and
it
goes
out
to
you
know:
half
a
million
clusters,
you
know
and
all
of
a
sudden.
Nobody
can.
A
You
know
all
the
planes
are
down
for
you
know
three
days,
that's
a
real
problem,
so
we've
kind
of
put
these
gates
in
to
make
sure
that
developers
are
doing
what
what
they're
supposed
to
do,
one
one
of
the
things
and
we're
both
software
Engineers.
We
know
right
you're,
building
your
feature
and
you're
excited
about
it
and
you're
thinking
about
all
the
happy
path
and
you're
thinking
about
how's
it
going
to
work.
It's
going
to
work
great,
it's
going
to
do
all
this
great
stuff
for
people,
but
often
people
lose
sight
of
those
unhappy
paths.
A
So
production
Readiness
is
just
a
simple
set
of
questions
that
we
added
to
the
kept
process
where
we
we
make
people
think
about
all
those
unhappy
paths
we
make
people.
We
asked
them
the
simple
question
of
how
do
I
turn
this
thing
off.
If,
if
it's
not
working
right
and
we
make
sure
that
people
actually
have
implemented
those
feature
Gates
properly,
I
mean
it's
not
a
police
force.
It's
really.
A
So
having
now
this
actually
mandatory
for
the
last
a
couple
years,
we
every
year
do
a
survey
and
I'm
very
happy
to
say
that
in
our
most
recent
survey
we
asked
is
kubernetes
more
reliable
than
one
year
ago
and
three
quarters
of
the
operators.
Cluster
administrators
out
there
that
respond
to
the
survey
did
say
yes
and
another
20.
That
said,
they're
not
sure,
just
a
tiny
little
percent
said,
though,
so
we're
very,
very,
very
happy
to
see
that
sort
of
result,
yeah.
B
Yeah,
let's
get
we
run
short
of
time.
Slides
will
be
posted
for
sure.
So
you
know
check
three
slides
that
I
skipped
over
how
to
participate.
You
know
come
to
the
main
Sikh
architecture
meeting
come
to
the
sub
project
meetings
that
you
are
interested
in.
There
are
project
boards
mailing
list,
slack,
there's
one
URL!
You
can
find
the
information
for
the
rest
of
the
things
we
would.
We
would
like
you
to
ask
a
question
any
question.
It
doesn't
matter.
B
You
know
all
of
us
started
at
one
point
or
another,
so
we
don't
judge
you
for
the
question
that
you're
asking
please
speak
up.
Please
ask
please
ask
how
we
are
doing
things
and
why
we
are
doing
things
and
we
will
be
happy
to
walk
you
through
things
like
another
example
that
John
was
already
talking
about
was
some
of
the
Shadow
programs
that
we
are
running,
which
are
really
good
for
you
know
both
you
know.
B
A
Yeah
and
I'll
say
that
some
of
those
so
so
API
review,
for
example,
that's
going
to
probably
require
quite
a
bit
of
knowledge
of
kubernetes
and
apis
and
all
that,
but
like
production,
writing
is
actually
a
great
profile
of
a
person.
That's
doing
that
as
an
SRE
right.
It's
somebody
who's
who's.
They
don't
you
don't
need
to
know
the
kubernetes
code.
You
need
to
know
what
it's
like
to
have
10
000
clusters
and
and
have
something
broken
somewhere
and
you
don't
know
what
it
is
and
how
to
find
it
right.
B
B
All
you
need
to
do
is
like
figure
out
like
which
dependency
you
have
to
upgrade
and
what
version
you
need
to
upgrade
it
to
and
run
some
scripts
and
push
it
push
the
pr
and
the
CIS
jobs
will
yell
at
you
if
it
goes
red
and
then
you
iterate
right.
So
if
you
just
know,
go
that's
good
enough
for
you
to
start
with
in
messing
around
with
the
you
know,
code
organizations,
sub
project,
okay,
so.