►
From YouTube: Kubernetes SIG Architecture Intro and Update - Derek Carr, Red Hat & Davanum Srinivas, VMware
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes SIG Architecture Intro and Update - Derek Carr, Red Hat & Davanum Srinivas, VMware
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/ZeyZ
A
B
B
We
strive
to
be
flexible,
there's
a
lot
of
interest
in
using
kubernetes
in
a
wide
variety
of
use
cases,
and
so
it's
important
that
the
project
and
the
apis
and
concepts
we
present
enable
that
flexibility
of
use
and
where
the
core
project
itself
is
unable
to
deliver
the
the
function
that
users
may
desire.
We'd
love
to
work
with
our
contributing
user
community
to
figure
out
points
of
future
extension
in
general.
B
In
addition,
a
long-standing
community
value
in
the
project
is
to
ensure
that
the
community
is
more
important
than
any
single
product
or
company's
goals.
So
what
we
do
within
cig
architecture
is
often
trying
to
to
reinforce
guidelines
and
practices
to
to
ensure
that
the
community
is
meeting
that
need.
B
So
we
can
continue
to
scale
and
meet
the
needs
of
our
users
and
contributors,
while
kubernetes
is
further
along
in
its
maturity
curve
than
it
was
say
a
few
years
ago,
when
the
project
was
just
starting.
We
continue
to
try
to
be
an
inclusive
community.
We
invite
users
and
contributors
to
give
their
feedback
on
what
we
should
do,
what
we
should
do
better,
what
we're
not
yet
doing
to
meet
our
needs.
B
I
think,
as
we
talk
about
the
role
of
sick
architecture
and
areas
for
folks
to
help
contribute,
hopefully
you'll
learn
that
both
dimms
and
myself
are
friendly
individuals
who
look
forward
to
working
with
everyone
and
bringing
their
feedback
and
helping
the
overall
project
be
better
and
so
basically
never
hesitate
to
to
make
your
voice
heard
and
then.
Finally,
the
reason
your
voices
are
so
important
is
it's
important
that
the
project
doesn't
stagnate
right.
B
But
a
lot
of
people
when
they
interact
with
kubernetes
are
interacting
with
with
an
api
right,
a
source
of
truth,
and
so
we
have
some
more
horizontal
sigs
that
kind
of
build
that
foundational
machinery
things
like
api
machinery,
authentication
the
end
user
tools.
You
use
the
cli,
so
there's
a
lot
of
points
of
engagement
that
one
can
have
that
are
very
specific
to
domains
both
vertically
and
horizontally,
and
so,
when
we
think
about
sig
architecture,
we
think
about
what
we
can
do
to
provide
guidance
and
oversight.
A
Next
slide,
please:
okay,
so
talking
about
sig
architecture
itself.
You
know
we
looked
at
how
kubernetes
programmatic
project
is
organized,
but
we
do
have
some
organization
within
the
sig
architecture
itself
and
we
try
to
like
figure
out
how
we
could
do
our
day-to-day
work
and
what
do
we
need
to
concentrate
on
and
things
like
that,
so
on
the
left-hand
side,
we
are
talking
about
like
how
do
we
maintain
and
evolve
the
design
principles
right
and
but
on
the
other
side
we
also
have
to
figure
out.
A
How
do
we
actually
apply
this
on
an
ongoing
basis
with
the
incoming
issues
and
prs
and
stuff
like
that?
So
what
we
end
up
doing
is
we
have
a
bunch
of
people
working
on
some
aspects
of
asic
architecture,
for
example
the
conformance
definition,
code
organization
and
api
governance
and
stuff
like
and
things
like
that.
So
what
we
end
up
doing
is
we
divide
up
the
sig
architecture
into
multiple
sub-projects
and
that's
how
we
do
our
usual
day-to-day
work
next
slide,
please!
So
what
is
in
scope?
A
A
So
we
are
in
charge
of
the
conformance
tests,
api
conventions,
design
principles,
the
enhancement
process,
deprecation
policy.
You
know
the
whole
gamut
of
things
that
keeps
all
the
six
together
in
line
and
proceeding
in
a
forward
direction.
Next
slide.
Please,
and
how
do
we
do
this?
We
we
have
a
bunch
of
cross-cutting
processes
that
we
tend
to
set
up.
For
example,
the
conformance
sub-group
ends
up
doing
test
reviews
and
then
managing
expectations
around
what
tests
get
into
conformance
and
is
is
are
the
suite
of
tests
enough?
A
How
do
we
make
sure
that
we
increase
our
test
coverage
for
conformance,
and
you
know
things
like
that,
for
example,
yesterday
we
were
talking
about
like
how
do
we
have
conformance
profiles
where
we
look
at
different
aspects
of
conformance,
for
example,
something
that
could
be
highly
secure
but
not
available
across
all
the
providers
is
one
example
of
that.
We
also
have
an
api
review
process.
A
We
we
rely
on
api
review
to
help
us
a
lot
with
backwards,
compatibility
and
things
like
that,
as
well
as
forward
progress
like
simple
things
like
okay
does,
the
field
have
to
be,
it
has
to
support
like
multiple
things
like
ip
addresses
right,
it
doesn't
need
to
be
single
field.
Does
it
need
to
be
multiple
fields
like
and
we
in
what
would
be
useful
going
forward
and
things
like
that
so
apa
review?
A
If
we
done,
we
have
had
a
lot
of
experience
over
a
time
to
evolve
apis,
so
the
group
run
by
jordan
helps
figure
out
how
how
to
do
api
reviews
and
what
to
look
for,
and
we
try
to
write
down
all
the
things
that
we
know
as
well,
so
a
similar.
Similarly,
we
have
a
sub
project
that
looks
at
enhancements
and
how?
How
do
you
introduce
a
new
feature?
A
What
do
you
need
to
look
for,
and
we
have
like
a
template
which
captures
most
of
the
things
that
we
have
to
you
know
ask
so
people
who
are
just
joining
the
project
won't
have
to
like
turn
to
ten
different
people,
and
each
one
of
them
has
a
different
expectation
of
what
needs
to
go
into
the
enhancement.
You
know
proposal
itself,
so
we
have
processes
around
that.
A
So
what
are
the
kinds
of
issues?
Are
there?
It's
mostly
about
like
there
are
so
many
resources
that
we
haven't
given
at
us,
and
not
different
people
write
different
pieces
of
code.
So
how
do
we
make
sure
that
the
behavior
is
the
same
and
things
and
things
like
that?
And
there
are
always
pitfalls
in
the
process
and
sig
architecture
helps.
A
You
know
smoothen
out
our
paper
over
things
and
also
any
anything
that
where
there
is
a
conflict
between
people
from
different
things,
we
are
not
meant
to
be
like
a
last
court,
you
know
supreme
court
or
something
like
that.
We
more
mostly
think
about
how
do
we
make
sure
what
are
the
design
principles
that
are
involved
here?
What
what?
A
A
So
if
you,
if
you
are
in
doubt,
if
let's
say
you're
working
on
something,
what
do
you
do
so
you
just
start
a
mailing
list.
Thread
start
writing
a
proposal
with
details
and
then
come
to
us
for
guidance
if
needed
next
slide,
please
so
I
I
talked
a
little
bit
of
each
of
the
sub
projects,
but
let's
just
go
through
the
offshore
list,
so
we
have
the
architecture
and
api.
They
are
responsible
for
the
design
principles,
architectures
extension
patterns
we
have
this
is
run
by
jordan.
A
We
have
code
organization
which
talks
about
repository
structure,
branching,
rendering
dependency
management
go
modules,
stuff
like
that
which
is
code
organization,
that's
run
by
me.
The
other
one
is
conformance
definition
where
we
are
talking
about.
This
is
a
little
bit
of
a
different
animal
here,
so
the
the
conformance
itself
from
an
end
user
point
of
view,
is
run
by
cncf.
A
So
we
work
with
the
cncf
folks
who
actually
run
the
trademark
program
as
well
in
within
this
subgroup.
So
this
project
is
on
our
side.
It's
called
conformance
definition
and
we
review
approved
changes
to
the
test
suite
and
that
test
suite
is
in
turn
used
by
the
trademark
program
to
for
people,
for
the
different
providers
to
run
against
their
own
instances
of
kubernetes
and
then
do
a
self-certification
at
that
point.
So
enhancements
is
a
new
subgroup.
A
We
are
also
down
this
path
of
how
what
are
the
things
that
we
need
to
think
about
when
a
feature
needs
to
when
we
call
a
feature
to
be
production
ready?
What
are
the
things
to
look
for
there
and
we
try
to
insert
questions
into
the
enhancement
process
to
get
people
to
think
about
this?
You
know
what
kind
of
skill
are
we
looking
at?
What
kind
of
use
cases
that
we
need
to
support?
A
B
B
It's
important
that
as
an
end
user,
nobody
cares
about
which
individual
subgroup
created
that
part
of
the
project
when
they're
consuming
the
project.
It's
important
that
there's
a
consistent
design,
sensibilities
and
tastes
that's
applied
so
that
the
user
experience
for
how
the
users
consume
the
project
makes
sense,
no
matter
where
the
work
was
sourced.
B
Others,
part
of
the
goal
of
the
api
review
sub
project
is
to
provide
a
formalized
mechanism
for
new
reviewers
to
both
understand
how
changes
can
get
made
to
the
api
safely.
What
conventions
all
api
changes
which
follow,
no
matter
where
they
are
in
the
project
and
kind
of
make
sure
that
we
have
a
common
standard
of
practice
for
how
api
changes
are
evaluated
broadly,
which
is
often
extremely
important
in
knowing
how
to
evaluate
something
even
where
reviewers
might
not
have
specific
understanding
of
like
the
detailed
section
of
that
api.
B
It's
amazing
how
much
the
project
depends
on
highly
qualified
api
reviewers
to
keep
us
as
successful
as
possible,
and
if
individuals
have
an
eye
for
detail
and
a
good
user
experience
that
want
to
help
guide
the
future
of
kubernetes
api
structures.
I
strongly
encourage
everyone
to
to
join
this
sub
project
and
to
learn
and
hopefully
offer
your
expertise
for
future
contributors.
B
We
lean
on
the
shoulders
of
others
in
open
source,
who've
provided
libraries
and
utilities
that
we
want
to
use
to
basically
make
kubernetes
what
it
is
today.
So
things
like
run
c
or
container
d
or
container
runtimes,
or
a
number
of
live
c
advisor.
A
number
of
libraries
that
kubernetes
traditionally
would
vendor
into
the
code
structure
has
has
definitely
grown
over
time
and
in
the
early
phases
of
the
project.
B
How
do
we
make
it
that,
when
kubernetes
wants
to
take
advantage
of
a
new
capability,
one
of
the
issues
we've
been
talking
about
lately
is
just
how
to
roll
out
secrets
v2,
maybe
in
in
kubernetes
support,
and
that
might
require
changes
in
c
advisor
and
run
c
and
container
d
and
cryo
et
cetera,
and
you
need
to
eventually
get
the
cubelet
to
vendor
all
those
dependencies
appropriate
where
necessarily
and
not
cause
conflicts,
and
so
there's
this
general
issue
of
transitive
dependency
management.
That
is,
that
is
tough,
and
so
this
can
mean
oftentimes.
B
We
are
aspiring
now
on
the
kubernetes
project
to
make
sure
that
we
depend
on
fixed
release
versions
of
these
external
dependencies
so
that
we
can
very
easily
understand
when
cves
need
to
be
fixed
and
that
type
of
thing
we're
not
perfect
on
that
everywhere.
Right
now,
but
it
is
a
goal,
and
so
it's
an
interesting
process
to
work
through
to
figure
out
how
the
kubernetes
project
can
continue
to
scale
its
code
base
while
working
on
dependencies.
B
If
you
want
to
integrate
with
amazon
or
google
or
vmware
or
any
of
the
various
infrastructure
providers
that
might
exist,
often
those
libraries
bring
in
additional
back-end
dependencies
that
need
to
be
kept
up
to
date
with
the
project,
and
so
sometimes
we
look
at
dependency
management.
From
the
perspective
of
how
do
we
keep
vendoring
these
things
safely
and
then
other
times
we
look
at
dependency
management
on.
B
B
And
so
things
like
client
go
the
kubernetes
api,
the
cri
we're
constantly
looking
at
how
we
can
take
something
out
of
our
monorepo
of
kubernetes
kubernetes
and
get
it
structured
in
a
ways
that
allows
third
parties
to
build
on
our
tooling
without
needing
to
depend
on
the
entire
code.
So,
if
you're
in
general,
very
interested
in
figuring
out
dependency
management,
both
in
the
provider
and
consumer
side,
I'm
sure
dems
would
love
to
have
you
participate
in
the
code
organization,
subproject,
conformance
tests
and
promotion.
B
B
Config
maps
actually
bind
in
your
pods,
where
you
expect
a
subset
of
those
tests
that
test
overall
and
the
end
function
get
elevated
into
what
we
call
a
conformance
suite
and
that
conformance
suite
to
get
a
test
integrated
at
that
level
requires
like
a
higher
bar
of
review
for
a
variety
of
reasons,
one
that
the
original
test
as
it
was
written,
might
not
have
been
written
in
a
way.
That's
obvious
to
readers
of
that
test.
What
it's
really
testing
right.
So
it
takes
some
oversight
to
say.
B
B
This
is
an
interesting
thing
to
talk
through,
because
at
this
point
now,
kubernetes
has
grown
so
big.
There's
a
lot
of
specialization
and
a
lot
of
users
who
first
engage
with
the
project
will
write
some
code
and
then
say
this
is
a
great
idea
and
then
ping
maintainers
to
say:
hey,
can
you
just?
Can
you
merge
this?
B
And
so
when
we
talk
about
the
other
aspects
of
the
project,
around
api
review
and
overall
evaluation
on
design
conventions,
enhancements
kind
of
serve
two
purposes,
one
like
how
do
we
identify
units
of
change
that
are
large
enough
that
either
a
may
impact?
The
end
user
api
may
impact?
How
and
when
we
choose
to
deprecate
or
take
on
new
capabilities
or
may
impact
more
than
one
group,
for
example,
like
a
change
to
the
pod
definition
might
be
required
in
order
to
facilitate
a
use
case
desired
in
storage.
B
This
is
an
ever-evolving
process,
not
all
the
work
that
was
previously
done.
Kubernetes
has
a
corresponding
enhancement,
but
there
is
a
goal
as
we
go
forward
to
make
sure
that
every
significant
unit
of
change
has
a
corresponding
enhancement.
So,
as
a
community,
we
have
a
record
to
follow
and
as
end
users,
you
can
work
through
and
think.
Why
were
the
decisions
made
as
they
were.
B
What
is
the
change
you
want
to
make
and
over
what
set
of
releases?
Will
this
change
be
made
and
as
the
change
is
being
developed,
what
were
the
milestones
you're
looking
to
meet
in
each
scenario
and
the
production
readiness
review
is
more
like
asking
yourself:
do
I
have
the
right
metrics
around
this
feature
capability?
B
Sake
can
provide
guidance
on
how
to
appropriately
monitor
that
as
an
example
right,
in
addition,
like
there's
a
difference
between
the
user
documentation
and
the
admin
documentation,
if
you
are
rolling
out
a
capability,
for
example
like
setcomp
right
something
that
might
be
very
important
to
get
properly
handled
in
order
to
provide
the
overall
security
posture
you're.
Looking
for
as
an
end
user,
you
might
think
about.
A
B
You
know
kubernetes
has
a
job
api
and
you
know
my
company
or
my
customer
or
my
user.
They
just
they
got
this
really
important
use
case
right
and
kubernetes
kind
of
solves
it,
but
doesn't
solve
it
all
the
way,
and
so,
like
I'm,
really
interested
in
you
know,
building
a
new
type
of
variant
on
job.
I
think
it's
going
to
be
widely
useful,
but
I
just
want
to
get
it
in
the
core
right
now
and
provide
value
to
my
users
and
company.
Like
can
I
do
that,
like
what
should
I
do
here.
A
A
There's
been
so
many
different
features
that
we
ended
up
doing
outside
and
then
bringing
it
into
kubernetes,
and
there
is
also
things
that
we
have
talked
about
where
things
that
are
in
kubernetes,
we
try
to
move
out
to
external
projects
as
well.
So
let's
explore
a
little
bit
of
the
extension
points.
Do
you
want
to
go
to
the
next
slide?
Please
yep.
A
So
I
think
we
skipped
one.
We
can
go
back
one
okay,
so
what
we
try
to
think
about
is
how
do
we
avoid
bottlenecks?
For
example,
if
you
have
to
make
a
call
to
an
external
system,
then
how
do
we
make
sure
that
kubernetes
itself
doesn't
come
to
a
heart
right?
How
do
we
increase
the
now
supported
use
cases?
How
do
we
let
people
rapidly
iterate
and
not
have
to
wait
for
a
release
of
kubernetes?
A
B
A
A
B
Yeah,
so
you
know,
like
my
job
api,
it's
it's
mission,
critical,
it's
what's
paying
people's
paychecks,
you
know
so
like
my
company
is,
and
my
users
are
really
expecting
that
I
have
strong
validation
on
that
code
right
so,
like
I,
I've
tried
a
third-party
resources
earlier
in
the
life
of
kubernetes.
Now
I
hear
about
these
custom
resource
definitions.
B
A
B
To
interact
with
this
resource
so
being
able
to
have
it
pretty
printed
and
described,
and
all
that
looks
like
that's
something
I
should
look
in
a
little
more
detail
but
yeah.
It
looks
like
for
this
particular
use
case.
Kubernetes
shouldn't
be
a
blocker
for
me.
I
can
get
value
outside
of
the
core
project.
A
A
We
want
to
clean
up
reliability
and
we
make
things
more
reliable.
We
also
want
to
make
sure
that
the
features
that
we
have
that
are
in
alpha
go
to
beta
things
that
are
in
beta,
go
to
ga
and
we
are
trying
to
put
together
a
set
of
you
know,
processors
to
make
sure
that
we
force
the
features
to
go
ga
quickly,
and
you
know
we
have
to
solidly
go
behind
caps
cap
steps
and
make
sure
that
we
write
things
down
earlier
in
the
cycle.
A
A
A
If
you
come
there,
you,
you
can
be
a
fly
on
the
wall,
that's
how
all
of
us
started.
You
know
so
come
be
a
fly
on
the
wall,
listen
to
all
the
things
that
we're
talking
about
and
then
soon
you'll
get
the
hang
of
it
and
you
will
come
out
of
your
comfort,
comfort
zone
and
start
talking.
Talking
to
us,
you
know
use
all
the
asynchronous
stuff
that
we
do
project
boards
mailing
lists
slack.
You
know,
speak
up,
please!