►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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 Update - John Belamaric, Google & Derek Carr, Red Hat
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.
https://sched.co/ekGs
A
Well,
welcome
everyone
to
kubecon
north
america.
2020.
excited
to
give
you
a
presentation
today
around
very
interesting
sig
within
kubernetes
sig
architecture,
and
hopefully
we
can
give
you
a
background
and
how
you
can
get
engaged
and
what
our
role
within
the
project
is.
So
we
go
to
the
next
slide.
I'm.
A
C
B
A
A
A
So
with
those
like
framing
goals
in
mind,
we
kind
of
go
to
the
next
slide
here
and
we
try
to
say
like
well.
Those
are
great
goals
and
they
hopefully
allow
the
kubernetes
project
to
maintain
long-term
success,
but
that
only
works.
If
we
back
it
up
with
with
community
values
that
allow
activities
to
scale
so
one
of
the
earliest
things
we
did
within
kubernetes
was
to
define
a
governance
model
that
prioritized
a
distribution
of
responsibility
among
various
groups
within
the
project,
rather
than
centralizing
all
decision
making
within
a
small
few
of
individuals.
A
Generally,
we
think,
if
you
know
about
networking,
you
should
be
exercising
your
domain
and
networking
knowledge
and
have
autonomy
within
that
sig
and
same
with
you
know,
node
or
or
scheduling
those
people
who
work
closest
to
that
problem.
Space
know
it
best
and
when
we
interface
within
the
community,
we
want
to
make
sure
that
we're
representing
the
community
rather
than
an
individual
product
or
company,
need,
because
by
doing
that,
we're
ensuring
that
everyone
is
is
ultimately
being
successful
as
a
community.
A
You
know
we
always
strive
to
do
better
and
sick
architecture
is
no
different
than
the
rest.
So
we
we
want
to
make
sure
that
we're
inclusive
and
hearing
everyone's
viewpoints.
So
if,
after
seeing
this
presentation,
you're
inspired
to
join
us
in
a
sig
architecture,
meeting,
I'm
sure
john
or
myself
or
anybody
else
who
participates,
would
would
love
to
get
your
feedback
and
and
help
make
your
impact
known
in
the
community
and
then
the
key
point
here
on
the
community
values.
A
When
we
talked
about
the
project
wanting
to
ensure
that
it
keeps
advancing
the
state
of
the
art,
we
need
to
ensure
that,
like
our
community,
values,
evolve
and
don't
stagnate
themselves.
So
with
that
context
in
mind,
if
we
go
to
the
next
slide,
the
kubernetes
project
itself,
as
you
said,
is
composed
of
many
sigs
and
there's
kind
of
different
ways.
You
can
look
at
sigs.
Some
are
very
horizontally
oriented
right,
so
they
they
deal
with
the
guts
of
how
the
kubernetes
project
itself
works.
C
Sure
so,
as
derek
said,
sleek
architecture
fits
as
a
sort
of
project
scope,
sig
and
with
that
concept
of
distribution
is
better
than
centralization.
We
we
still
see
this
need
for
sort
of
consistency
and
for
a
consistent
bar
across
the
project,
for
that
is
bar
of
quality
and
also
for
things
like
apis.
C
We
have
consistent
set
of
conventions
that
we
want
to
use
so
that
the
apis
from
the
sig
network
and
the
aps
from
signal
function
essentially
the
same
manner
and
not
just
the
machinery
but
the
structure
of
the
api
and
the
conventions
around
naming
and
things
like
that.
Those
general
api
conventions,
design
principles.
You
know
we're
using
declarative
apis
with
these
reconciling
controllers.
Things
like
that
that
are
just
fundamental
to
kubernetes
those
live
within
this.
Within
this
sake.
C
So
what
are
some
of
the
other
issues,
so
it
happens
sometimes
that
that
a
question
will
come
up
through
a
sig
that
the
the
sig
doesn't
know
how
to
answer
they.
Don't
they
want
to
make
sure
that
it
works
in
a
consistent
manner
across
what
other
cigs
may
be
doing,
and
those
sort
of
things
will
come
to
sick
architecture
to
make
decisions
about
or
have
discussions
about.
Sometimes,
sigs
will
disagree.
The
people
within
the
sig
will
disagree,
and
you
know
at
times
they
brought
that
to
us
as
an
escalation.
C
C
The
I'm
not
sure
what
this
last
bullet
is
here.
I
didn't
put
it
on
here,
but
in
general
we
do
like
to
say
solicit
feedback
from
anybody.
In
order
to
do
that,
you
start
a
thread
on
our
mailing
list,
which
is
like
architecture,
you're
happy
to
join
it,
and
once
once
we've
got
a
thread
going.
We
try
and
resolve
what
we
can
on
there
before.
We
actually
talk
about
in
a
meeting
to
try
and
not
be
respectful
of
everybody's
time.
C
So
subprojects
we
have
five
cell
projects
within
within
sigma
protection.
One
is
the
the
api
review
sub
project,
which
essentially
documents
all
of
those
conventions
and
design
principles
around
the
api
and
also
runs
an
actual
review
process
where
every
time
there's
a
pr
that
comes
in
that
touches
an
api
there's
a
set
of
reviewers
and
approvers.
Who
will
review
that
change?
Make
sure
that
it's
adhering
to
those
conventions
and
often
give
very
good
advice
around
how
to
improve
your
api.
C
So
it's
a
it's
a
really
valuable
process
that
we've
seen
we've
gotten
great
results
out
of.
We
also
have
a
code
organization
sub
project.
So
here
again
is
one
of
these
larger
structural
things
that
the
sig
handles,
and
this
is
about
managing
our
dependencies
and
deciding
what
what
pieces
of
code
can
be
moved
out.
We've
got
a
set
of
staging
repositories
that
allow
us
to
sort
of
refactor
the
code
a
little
more
effectively
and
be
able
to
import
the
code
into
other
projects
more
effectively.
C
C
A
Awesome
well
thanks,
john,
so
many
folks
who
are
new
to
engaging
with
kubernetes.
When
we
talk
about
these
sub-projects,
they
are
literally
like
dedicated
meetings
that
folks
can
join
and
participate
in
if
they
have
a
particular
interest,
and
so,
while
sig
architecture
meets
at
a
sig
wide
level
at
a
bi-weekly,
cadence
and
topics
for
that
meeting
are
usually
generated
through
the
mailing
list.
A
Individual
sub-projects,
which
john
gave
an
overview
on,
have
discrete
meeting
times
to
just
focus
on
that
particular
activity
as
well.
So
one
of
those
ones
that
we
can
talk
a
little
about
was
around
api
review.
A
lot
of
people
who
engage
with
kubernetes
appreciate
the
fact
that
it
has
a
relatively
consistent
api
perspective.
A
So
there's
a
project
board
if
you're
interested
in
checking
out
the
activities
that
take
place
in
that
sub
project
and
as
well,
if
you're,
just
interested
in
understanding
like
the
design
philosophy
around
apis
and
changing
your
apis.
That
kubernetes
aspires
to
follow,
even
in
your
own
extension
projects,
which
we
talk
about
later,
like
as
an
ecosystem,
it's
great
if
we
can
all
be
aligned.
A
I
strongly
encourage
everyone
to
look
at
our
api
conventions.
Documents
like
really
deep
and
thorough
and
can
help
people
build
apis
that
fit
kubernetes
style
even
when
they're,
not
in
the
kubernetes
project.
Now,
api
review
is
required
for
anything
that
is
in
the
main,
kubernetes
karenity's
distribution.
So
when
we
talk
about
the
goal
of
the
community
being
portable
right,
no
matter
where
you
procure
kubernetes,
you
want
to
work
consist
consistently.
A
We
do
recognize
that
there's
a
growing
ecosystem
of
projects
around
kubernetes,
and
so
you
might
have
seen
some
things
come
up
around
things
like
the
usage
of
the
kate
style,
api,
namespace
versus,
say,
like
x,
dash
kate's,
io,
namespace,
and
so
where
we
talk
through
things
around
what
things
are
subject
to
api
review
and
the
process
around
that.
That's
a
lot
of
things
that
you
might
see
in
this
sub
project
and
we
would
love
participation,
but
there's
a
lot
of
great
lessons
and
things
to
learn.
A
Code
organization,
as
john
talked
about
like
kubernetes,
was
originally
just
one
massive
repo
right,
kubernetes
kubernetes,
and
we
are
building
on
the
output
of
many
other
open
source
communities
to
openly
do
what
we
do
in
kubernetes
right,
whether
that
is
some
of
our
earliest
dependencies,
where
c
advisor
or
run
c
or
docker
or
any
of
the
other
projects.
You
might
see,
get
vendored
into
a
typical
go
project
well
over
time.
A
Oh,
we
got
to
do
things
better,
and
so,
basically,
if
you're
interested
in,
like
taking
a
very
large
go
project
and
figuring
out
the
best
way
to
structure
it
across
a
reasonable
number
of
repositories
that
all
of
us
in
the
community
can
follow
like
this
is
this
is
the
place
for
you
and
as
well
as,
if
you're
interested
in
consuming
particular
sub
systems
within
kubernetes,
for
use
in
your
project.
That
may
not
be
well
factored
yet
to
meet
your
need.
A
I
think
everyone
in
the
community
wants
to
help
others,
but
they
want
to
help
it
in
a
way
that
they
know
that
they're,
providing
that
help
on
and
so
making
those
those
issues
known
can
help
us
figure
out.
Then,
as
john
talked
about
earlier,
what
things
we
should
maybe
promote
into
their
own
discrete
repo
that
you
can
depend
on
without
the
whole
thing.
So
that's
that's
code
organization
and
go
on
the
next
one
conformance
tests
and
promotion.
A
So
this
is
a
process
that
is
important
and
one
that
is
ever
evolving,
so
kubernetes
rapidly
expanded
in
its
earliest
formations
and
the
actual
set
of
projects.
Typically,
many
things
had
ede
testing
right.
We
want
to
make
sure
the
feature
worked,
but
not
everything
was
labeled
as
conformant
and
for
a
variety
of
good
reasons.
A
Right
there
were
maybe
integration
specific
to
particular
cloud
platforms
that
were
not
necessarily
portable,
and
but
you
still
want
to
make
sure
that
that
function
worked
right,
and
so,
while
we
have
a
very
large
and
rich
body
of
of
ede
testing
within
the
project
and
of
course,
these
things
can
always
improve
that
which
was
required
to
be
portable
across
everywhere.
You
can
consume
karenina's
is,
is,
is
a
smaller
set
and
you
know
has
to
be
expanded,
judiciously
right,
and
so
the
conformance
test
and
promotion.
Subproject
is
basically
evaluating
that
problem
right.
A
A
We
are
now
trying
to
go
back
and
say
well
what
can
we
do
to
supplement
those
gaps
within
our
testing
and
then
on
a
forward-going
basis?
How
do
we
ensure
that
our
project,
postures
and
positions
like
don't
allow
those
gaps
to
re-insert
them
back
re-insert
themselves?
Back
so
one
of
the
key
things
that
came
out
of
sig
architecture
was
like
this.
This
clarifying
statement
that,
like
you
know,
you
need
to
have
these
tests
before
you
can
promote
your
feature
to
beta
right.
A
They
might
not
be
labeled
yet
for
conformance
but
they're,
at
least
in
the
project
and
ready
to
go
in
case.
We
know
things
actually
were
being
properly
tested.
So,
if
you're
interested
in
helping
define
and
enhance
and
enrich
what
kubernetes
means,
no
matter
where
you
consume
it,
the
conformance
test
and
promotion
project
is
a
is
a
great
place
to
engage
with
that,
and
the
last
sub
project
here
was
around
enhancements.
A
The
history
lesson
of
kubernetes
is
sometimes
useful,
which
is
we.
We
had
a
small
group
of
engineers,
kind
of
collaborating
and
we
kind
of
had
a
rough
idea
of
let's
write
some
design
documents
on
what
we
want
to
do,
but
that
wasn't
really
very
formal
and
then
we
kind
of
evolved
that
a
little
bit
and
we
stuck
things
in
a
cube
community,
repo
and
kind
of
threw
our
ideas
out.
A
There
had
an
ad
hoc
way
of
of
of
getting
consensus
among
the
maintainer
community
and
then,
as
you
can
imagine,
over
years,
kubernetes
just
has
grown
right,
and
so
we
needed
to
scale
that
process,
and
so
now
we
have
this
enhancement
sub
project,
where
we
have
a
standard
enhancement
template
that
says
this
is
the
change
I
want
to
make.
This
is
how
that
change
can
be
tracked
by
the
release
team.
This
is
how
we
know
that
a
test
was
being
implemented
and
executed
for
this
enhancement.
A
This
is
how
we
can
appropriately
document
that
things
got
into
the
website
documentation,
so
our
users
know
how
to
consume
the
feature
and
then
a
clear
set
of
like
what
is
the
use
case.
My
feature
is
trying
to
do
what
component
areas
does
it
impact
and
then
we
from
that
we
can
kind
of
build
a
map
of
like
helping
you
navigate
the
community
to
know
these
are
who
you
need
to
approve?
These
are
the
sigs.
You
need
to
go
and
engage
and
ultimately,
hopefully
get
your
feature
idea
into
the
project.
A
A
C
C
Developers
in
our
community
are
you
know,
top-notch
professional
folks,
but
they're
also
developers,
meaning
they
think
about
their
users
and
how
their
users
are
going
to
make
use
of
these
features
to
to
do
whatever
it's
going
to
do.
Those
users
are
typically
application
developers
that
they're
thinking
about,
because
those
are
the
features
they're
mostly
building
for
so
production
readiness
review
is
intended
to
to
shift
to
shift
the
the
thinking
a
little
bit
from
to
the
to
the
operator
point
of
view.
C
So
as
a
person
operating
this
cluster
who
doesn't
necessarily
care
about
the
specific
features
that
they're
that
that
might
be
offered
by
a
sig,
but
they
care
about
making
sure
those
features
are
working
properly.
So
how
can
the
operator
best
ensure
that
whatever
you're
adding
is
serving
your
your
users?
C
C
Of
course,
we
will
work
with
you
in
any
way.
We
can
to
make
sure
we
that
that
the
future
meets
that
meets
the
partner,
and
I
don't
think
for
most
folks,
it's
a
hard
bar
to
meet
it's
just
now.
We
have
it
documented
now.
Operators
that
that
and
providers
that
consume
kubernetes
and
distribute
communities
actually
have
a
playbook
built
in
right
there
for
how
to
handle
certain
situations.
A
Excellent
john,
so
like
maybe
one
way
we
can
think
about,
kubernetes
now
is
like
obviously
it's
a
it's
a
container
orchestration
system
at
heart,
but
it
has
grown
to
be
kind
of
more
than
that
right.
It's
basically
a
platform
for
building
higher
order
platforms,
one
of
the
things
that
we
often
experience
in
kubernetes,
whether
it's
at
the
individual,
discrete
sig
level
or
those
who
want
to
engage
with
sig
architecture
is,
you
know
folks,
have
great
ideas
right.
A
They
want
to
use
the
enhancement
process
to
propose
their
new
feature,
they're
they're,
ready
to
sign
up
for
their
production
readiness
review.
They
got
their
api
all
spec
out.
They
want
to
get
their
api
review
and
they're
just
you
know,
ready
to
go,
and
so
john,
I
heard
that
you
had
an
idea
for
an
awesome
feature.
You
wanted
to
add
to
kubernetes,
and
maybe
we
could
kind
of
talk
through
a
right
way
of
navigating
your
interaction
with
the
community.
C
Yeah
absolutely
so
I
I
have.
I
have
a
little
side
project.
I've
got
going
where
I'm
trying
to
build,
build
my
own
launch
platform
for
rockets
that
go
to
the
moon
and
that
that
the
thing
is
that
I
haven't
been
able
to
build
the
rocket.
You
know
quite
quite
good
enough
to
reach
the
moon,
except
if
I
time
it
just
right
so
that
you
know
the
rocket
will
reach
the
moon
right
as
its
closest
approach
to
earth.
C
So
I
was
thinking
that
I
would
build
a
model
that
that
models,
the
the
orbit
of
the
moon
and
when
it
and
how
long
it
will
take
the
rocket
to
get
there
and
then
calculate
exactly
when
the
rocket
needs
to
launch.
But
the
problem
is
that
you
know
with
cron
job.
All
I
can
do
is
schedule
like
on
these
periodic
intervals
right.
I
can't
plug
that
in,
like
how
do
I
I
want
to
build
my
own
controller.
C
A
Yeah-
and
you
know
it's-
it's
rockets
you're
dealing
with
right,
so
I
assume
the
users
you're
working
with
or
your
your
community
you're
representing,
are
probably
both
important
and
full
of
cash
and
engineering
know
how
to
wanna
make
this
possible
right
and
also
you
want
to
get
that
rocket
to
space.
So
you
probably
want
to
be
able
to
deliver
that
value
to
your
user
at
a
at
a
prompt,
cadence
right.
So
maybe
what
we
could
do
is
ask
is
that
the
right
thing
to
get
into
kubernetes.
A
So
if
we
go
to
the
next
slide,
I
think
as
a
kubernetes
community,
like
our
goal
with
engaging
with
you
john,
is
like
we
want
to
make
you
successful.
We
don't
want
you
to
be
bottlenecked
on
our
api
review
process
on
the
cat
process
on
the
production.
Readiness
process,
if,
like
that
feature,
isn't
broadly
applicable
to
everyone
who
potentially
could
be
consuming
kubernetes.
A
When
we
talk
about
the
alpha
beta,
stable
progression
that
that
takes
time
right,
that
sometimes
is
measured
in
order
of
a
year,
maybe
a
little
bit
more
because
you're
going
through
discrete
loose
periods,
and
so
it's
actually
often
better.
If
you
can
fulfill
your
use
case
using
one
of
the
building
blocks
that
kubernetes
already
exposes
without
you
need
to
get
it
into
the
core
kubernetes
right
because,
as
as
we
said,
distribution
is
better
than
than
centralization.
A
I
don't
want
you
to
be
successful
if,
if
and
only
if,
we
bless
your
use
case
in
the
communities
projects.
So
to
that
to
that
concept
I
would
say
one
of
the
things
in
the
kubernetes
community
we've
done
is
is
listen
closely
for
where
new
extensions
are
needed.
So
let's
maybe
go
to
the
next
slide.
We
can
talk
through
your
example
right
so
like
you,
you
have
a
new
api
design.
You
have
a
new
model,
it
sounds
like
a
variant
on
jobs
like
have
you.
Have
you
looked
at
crds?
Have
you?
C
A
Yeah
so
like
we
have
a
lot
of
built-in
apis
and
kubernetes
that
you're
probably
familiar
with
things
like
pods
and
the
jobs
thing
you
were
looking
at,
but
like
there's
a
there's,
a
scope
to
what
we
offer
within
the
community
and
then
an
ability
for
you
to
kind
of
write
that
new
thing
yourself
right.
So
one
of
the
capabilities
that
was
added
was
these
things
called
custom
resource
definitions
right,
so
you
can
define
a
schema
for
your
new
job
type
and
you
can
then
use
you
can
tell
that
to
kubernetes.
A
This
is
my
schema
and
then
you
can
produce
instances
of
that
object
and
write
controllers
against
that.
So,
if
you're
wanting
to
use
like
kubernetes
as
a
platform
to
build
controllers
over
an
arbitrary
data
model-
and
you
want
it
to
follow
the
kubernetes
design
principles,
I
think
I
would
encourage
you
to
look
at
custom
research,
definitions
and
experiment
outside
of
kubernetes.
First.
A
A
What's
going
on
with
this
object
right,
like
you
call
people
get
pods
and
you
you
know
your
things
running.
So
one
of
the
things
that
we've
done
is
you
can
now
you
know
using
that
custom
resource
definition,
kind
of
advertise,
how
it
gets
displayed
in
the
cli
user
experience
so
like
if
there's
particular
attributes
you
want
to
show
about
when
that
rocket
needs
to
launch
or
when
that
job
needs
to
run.
A
A
But
if
john
had
an
alternative
example
where
he
could
identify
a
particular
use
case
or
nuance,
that's
probably
applicable.
That
would
empower
him
to
do
something
else.
I
would
say
coming
to
sick
architecture.
To
talking
through
your
initial
challenge
or
thought
is,
is
is
a
good
thing,
but
our
first
reaction
will
be
to
try
to
ask
if
we
have
the
right
tools
and
mechanisms
in
place
to
enable
you
to
be
successful
by
building
on
top
of
rather
than
within
kubernetes.
C
So
then,
the
question
then,
is:
where
do
we
go
from
here?
So
really?
The
entire
community
has
been
focused
on
these
extensions.
That
derek
was
just
talking
about.
We
really
want
to
make
sure
that
we
have
the
right
extension
points
and
so
there's
a
big
focus
on
that
continues
to
be
and
that
those
extension
points
work
as
much
as
possible
like
built-in
types.
C
We
also
we're
continuing
to
build
out
coverage
and
conformance
and
we're
trying
to
improve
the
quality
of
the
dot,
zero
release
and
we're
sort
of
trying
to
improve
the
overall
flow
of
features
through
this
system.
So
we
have
something
that
was
recently
added
where
things
need
to
go
to
ga
at
some
point,
we've
had
too
many
things
that
linger
in
beta
for
years
and
that
that's
a
problem
for
us.
So
these
are
the
the
main
things
we're
looking
at
as
well.
C
So
how
can
you
participate
in
this?
Well,
as
derek
mentioned,
come
to
our
meetings,
we
have
a
community
meeting
every
other
week.
That's
for
the
general
sick
architecture
and
then
most
subprojects
also
have
a
meeting
every
other
week.
The
schedules
are
there
on
the
community
schedule
and
we
are
really
eager.