►
From YouTube: Kubernetes SIG Architecture Community Meeting 9-28-2017
Description
A
B
B
C
D
C
Brian
I
was
trying
to
just
Brian's
comment
that
it
should
be
empty,
see
for
fill
out.
So
if
it's
empty,
then
you
need
instructions
about
what
to
put
in
there
like
we're,
gonna
find
the
information
to
put
in
there
so
yeah,
it's
like
this
hack
for
comments
and
markdowns.
You
don't
see
it
and
github.
What
do
you
see
when
you
forward
it
yeah.
A
If
you
look
under
the
title
thing,
I
do
have
to
get
started
with
this
template
type
of
thing
and
I
wanted
to
to
be
clear
of
some
of
the
naming
dance
that
we're
gonna
have
to
do
based
on
like
well
you're,
not
going
to
know
what
the
sort
of
draft
number
is
until
you
submit
the
PR,
and
so
that
means
that
you
have
to
create
the
file
submit
the
PR
rename.
If
we
push
right,
that's
all.
C
A
A
The
thing
that
I
have
in
the
dock
right
now
is
that
is
that,
when
things
are
in
a
draft
state,
they
have
a
number
that's
based
on
PR,
and
we
know
those
will
get
in
unreadable
and
only
Brian
will
remember
him
because
as
a
special
gift
and
then
I'm
actually
being
respectful,
there
Brian
I
actually
think
it's
hard.
You
can
remember
this
stuff
and
then
I
think
as
it
moves
to
the
acceptance
stage,
then
we
sort
of
renumber
it
with
a
non
draft.
Dense
number.
C
A
A
C
I,
don't
want
to
keep
breaking
cross-links
between
proposals.
I
mean
the
move,
will
probably
do
that,
but,
like
we
refer
to
these
proposals,
all
over
the
place
in
many
different
forms
and
I'd
rather
us
get
a
I.
Don't
think
pull
request
is
a
good.
Is
a
good
number
like
each
of
these
like
if
these
are
important
enough
that
the
whole
project
is
organized
around
agreeing
to
as
the
director
for
the
project.
Why
wouldn't
they
have
their
own
number?
Like
I've,
never
seen
a
project,
it
doesn't
have
a
unique
numbering
scheme
for
their
proposals.
Yeah.
B
Where
we
settled
in
the
proposal
was
have
some
kind
of
temporary
number
and
then
once
it
was
approved,
it
would
get
assigned
an
official
didn't
sequential
number
so
that
there
would
be
short
and
memorable
and
we
wouldn't
have
trouble
with
collisions
and
we
wouldn't
have
trouble
with
RIBA
moves
and
all
that
kind
of
stuff.
So,
and
it
was
something
it
would
be,
something
that
an
editor
to
do.
So
we
just
need
like
a
placeholder
for
the
approval
state.
E
B
B
A
E
G
So
there
are
two
different
levels
of
these
brokers
and
they
have
a
fairly
sophisticated
permissioning
setup
that
allows
you
to
yeah
I,
see
those
eyebrows,
Joe
I
agree,
my
eyebrows
agree.
At
least
they
have
a
fairly
robust
permissioning
system
that
lets
you
expose
different
services
and
plans.
They
come
from
these
brokers
to
other
organizations
or
expose
them
to
everybody.
G
We
obviously
do
not
have
such
capability
in
kubernetes
right
now,
and
what
we
initially
have
done
or
Service
Catalog
is
that
brokers
and
services
and
plans,
which
are
things
that
come
from
brokers,
are
global.
They're,
not
namespaced.
I've
had
a
number
of
users
and
books
in
the
community
ask
about
whether
they
will
be
able
to
ever
have
a
namespaced
version
of
a
broker
and
attendant
plans
and
services,
and
so
the
problem
facing
us
is
potentially
will
have
namespace
and
non
namespace
versions
of
similar,
if
not
identical,
resources.
G
G
H
B
I
guess
my
question
is:
why
can't
you
access
a
service
in
another
namespace?
So
within
Google
we
don't
have
service
brokers,
but
we
do
have
lots
of
shared
services
and
those
shared
services
effectively
are
the
namespaces
corresponding
to
the
teams
that
run
them
and
we
have
like
10,000
of
these
teams
so
so.
G
G
H
Another
question
which
is
I
feel
like
this:
is
data
playing
off
and
is
it
do
we
really
believe
that
Corinna
days
should
take
on
data
play
not
like
the
reason
you're
trying
to
model
things?
This
way
is
because
the
service
you're
trying
to
emulate
the
off
model
of
the
service
broker
right,
and
maybe
we
should
just
say,
like
that's:
the
service
workers,
business
Fiona.
G
H
F
We're
just
to
be
clear:
it's
not
just
it's
not
just
a
cross-reference
problem
to
me.
It's
it's!
You
know.
If
you
want
a
particular
namespace
to
see
other
namespaces
services,
then
you
have
to
do
some
action
to
explicitly
make
that
visible
and
that's
a
lot
of
extra
resources
and
a
lot
of
extra
work
for
every
single
main
space,
because
it's
not
effective,
registering
that
service
broker
in
every
single
namespace.
A
So
I
mean
just
to
be
clear,
since
you
guys
are
doing
your
own
API,
aggregated
API
server,
you
know
you
can
you
these
don't
have
to
be
real
resources.
They
can
you
know
you,
can
you
can
implement
some
some
some
special
sort
of
surfacing
of
these
things,
as
virtual
mirrored
resources
that
are
read-only
into
all
those
namespaces
and
essentially
make
it
be
zero
storage?
Is
that
possible?
We
have
the
examples.
A
C
Have
examples
of
virtual
resources
today,
where
you
expose
them
and
I
think
named
conflicts
are
kind
of
more
the
challenge
there
and
like
this
gets
to
a
like.
So
the
real
question
this
is
all
right,
Brendon
was
or
Brian
was
leading
was
we
we
initially
put
some
things
in
namespaces
and
some
things
not.
There
have
been
a
lot
of
reasons
to
put
more
things
in
namespaces,
like
the
two
examples
would
be
like
nodes
versus
Florida
we
quota
and
namespaces,
so
that
you
could
do
segmentation.
C
There
are
lots
of
people
who
want
to
now
go
to
do
quota
across
namespaces
from
a
sugar
bucket,
which
requires
complexity
and
the
converse
you
want
to
say:
hey.
Here's,
a
node
for
your
namespace
that
you
see
a
virtual
version
of
is
these
same
same
problems
in
the
other
direction.
If
we
were
to
do
the
namespace
service
broker
service
catalog,
we
would
need
to
have
a
way
to
expose
all
of
that
with
the
security
things
for
existing
users
right,
but
we
might
also
have
to
go
make
a
hard
decision
about
what
we
want.
H
H
B
And
their
ongoing
proposals
about
how
to
manage
namespaces
introducing
you
know,
I
think
Joe
has
seen
the
proposal
you
know
so
I
think
we
will
need
to
do
something
there
to
support
more
complex
organizational
hierarchies
and
yaza
Tate.
At
the
term
hierarchies
I
mean
people
kind
of
people
are
trying
to
map
their
group
and
organization
mechanisms
on
to
the
plot,
namespaces
and
I.
Think
I
think
one
of
the
ways
to
do
that.
B
But
you
know
what's
coming
back
to
this
specific
question
since
we're
kind
of
getting
a
little
bit
off-track,
so
we
have
a
couple
of
patterns
in
the
system.
So
with
events
we
had
them
namespace
to
not
namespace.
That
was
not
didn't
really
work.
Well,
so
I
definitely
cannot
advise
that
we're
going
in
the
direction
of
having
all
events
be
namespaced.
So
the
like
you
know,
node
events
would
be
in
cubes
doumitt
or
something
like
that
and
it
does
simplify
the
model.
B
Openshift
has
some
since
clayton
mentioned
quota
has
some
for
things
that
are
by
default.
Namespace.
It
has
some
cluster-level
resources
as
well
like
cluster
resource
quota,
and
things
like
that.
So
that's
the
existing
precedent
that
we
have.
We
can
either
put
cluster
level
things
into
a
well-known
namespace
like
queue
system,
or
you
can
have
a
cluster
level
thing
and
a
private
names
based
thing.
And
then
we
assume
that
at
some
point
in
the
future
it
will
become
easier
to
manage
groups
of
namespaces
through
some
kind
of
policy
mechanism
like
glaybels,
actually.
C
A
really
good
point
projects,
one
thing
with
name
spacing
putting
things
into
places-
is
that
too
many
things
in
the
same
namespace
flattens
the
security
domain.
So
today,
if
you
can
get
access,
if
you
can
create
a
pod
and
cube
system,
you
access
to
every
service
account
and
every
static
pod
and
every
so
like.
A
I
think
some
of
this
is
guidance
and
encouragement
sort
of
it.
What
granularity
do
namespaces
work
and
and
my
gut
is
to
actually
make
namespaces
more
granular,
but
to
do
that,
we
need
to
provide
policy
mechanisms
that
exist
above
the
namespace
level
for
being
able
super-nice
these
I
don't
think
this
is
necessarily
hierarchy,
because,
whatever
hierarchy,
you
define
for
one
thing,
won't
work
for
another
thing,
but
I
think
it
does
have
to
be
something
that
that
sits
above
that
level
I
put
into
the
cube
arbiter
stuff,
which
you
know
starts
talking
about.
G
A
G
To
add
some
constraints
to
the
problem
space
here
we
are
very
close
to
shipping.
A
beta
I
think
that
a
number
of
folks
that
have
been
working
on
this
at
different
vendors
have
schedules
around
this,
so
I
think
the
question
for
me
at
this
point
is:
do
we
differentiate
the
name
of
these
global
resources
and
give
ourselves
room
to
add
namespace
versions
of
them?
So,
for
example,
do
we
call
our
current
global
resources
like
global
service
broker
and
global
service
class
and
global
service
plan
or
cluster
whatever
cluster?
Whatever
is
their
division?
G
C
F
C
B
B
So
moving
on
yeah,
so
let's
continue
to
iterate
on
the
proposal
stuff
online
and
we
have
another
topic.
So
I
did
go
back.
We
talked
about
when
I
was
sick,
prioritizing
the
backlog,
I
didn't
do
a
deep
prioritization
because
things
change
so
fast
and
until
we
have
more
people
actively
working
on
stuff,
it
didn't
seem
to
be
particularly
helpful.
Do
you
have
a
really
deep
backlog,
but
we
do
have
an
urgent
issue
that
has
come
up,
so
the
conformance
effort
is
moving
right
along
and
is
marching
towards
a
launch
of
the
initial
effort.
B
It
is
kind
of
being
coordinated
through
CN
CF
who's,
going
to
do
the
forcement
and
lo
going
and
all
that
kind
of
stuff.
But
the
mechanism
for
actually
executing
the
tests
is
owned
by
sleep,
testing
and
vetting
of
what
should
actually
be
tested
is
owned
by
sega
architecture.
So
I
asked
for
an
audit
of
the
existing
conformance
tests.
I
just
posted
a
link
to
the
spreadsheet.
I
don't
know
what
the
access
to
this
thing
is:
I
can
access
it
see.
I
can't
do
this,
my
friend
no,
it's.
B
Dev
can
write
to
it.
Please
don't
accidentally
hose
it.
We,
the
current
list,
was
auto-generated
by
sort
of
Bui
I
believe
and
we
met
he
asked
for
help
in
characterizing
the
tests.
Basically,
what
I
am
looking
for
is
a
description
of
the
api's
features,
behaviors
that
we
believe
are
tested
by
the
each
test.
A
short,
ideally
brief,
summary
so
that
I
can
review
it
and
say
yeah.
This
makes
sense,
almost
certainly
I
clean,
already
identified
at
least
one
thing
that
shouldn't
have
been
in
the
list
and
that
got
removed.
B
So
that's
part
of
what
we're
trying
to
do
here.
I
also
want
to
identify
gaps.
Gaps
are
probably
not
going
to
be
plugged
in
the
initial
version.
It
will
just
be
noted
that
this
is
not
tested
yet
but
expects
someone
to
write
a
test,
and
then
we
will
find
people
to
either
convert
existing
tests
to
conformance
tests
or
write
new
tests
to
cover
critical
behaviors
that
are
not
captured
by
the
existing
hundred-plus
tests.
B
B
So
we
may
need
to
ask
for
more
detail
to
be
added
for
some
of
these
tests,
so
we
can
actually
clarify
what's
really
tested,
but
another
issue
just
an
example
issue
that
already
came
up
that
I
haven't
had
time
to
respond
to
you
is
somebody
asked:
should
cover
nineties
all
communities
clusters
be
able
to
reach
out
to
the
internet,
so
I
haven't
really
I
have
an
opinion
about
that.
Although
I
don't
want
to
pre
influence
what
other
people's
opinions
are.
A
That
particular
issue
and
I
haven't
talked
to
Tim
what
his
thinking
is
on
this
stuff,
but
my
st.
Clair
is
driving
it
from
the
from
the
hefty
a
point
of
view.
I
think
we
need
to
tease
apart
conformance
verses,
verses,
useful
Diagnostics
right
because
I
think
you
know,
obviously
not
every
kubernetes
cluster
is
gonna
reek,
be
reachable
that
is
gonna,
be
able
to
reach
the
Internet
right.
B
A
B
There's
there's
there's
ingress,
so
there's
egress
and
there
are
firewall,
shows
all
kinds
of
stuff
like
that,
but
somehow
we
need
some
tests
that
usefully
test
that
networking
works
right
for
different
levels
of
reach
ability,
and
so
there
may
need
to
be
a
test
that
somehow
you
can
reach
something
outside
your
cluster
or
something
like
that.
I
don't
know
so
anyway.
I
haven't
looked
at
that
specific
issue
in
detail,
but
that's
it
just
an
example
of
the
kind
of
issues
we
want
to
come
out
of
this
on
it.
Yeah.
H
H
H
D
H
B
Our
API
coverage
I
believe
to
be
pretty
poor
in
terms
of
like
all,
especially
if
you
consider
the
error
cases
and
things
like
that,
the
me
used
to
have
a
fairly
rigorous,
complete
test
that
was
actually
developed
with
me
turned
on
off
at
the
beginning
to
verify
you
know:
if
you
have
access,
then
you
get
these
kind
of
status
codes.
If
you
don't
have
access,
then
you
get
these
kinds.
B
As
the
API
surface
has
grown
and
we've
added
more
features
are
I
think
our
coverage
has
drops
over
time,
but
we
don't
even
have
ever
can't
even
measure
the
coverage
right
now
so
I
think
that's
gonna
have
to
be
a
priority
for
next
year.
For
sig
testing
is
to
build
things
like
coverage
coverage
mechanisms,
and
then
you
know,
other
individual
teams
who
have
api's
will
need
to
build
tests
that
exercise
the
functionality.
B
Api
machinery
maybe
needs
a
test
that
just
does
requests
all
the
different
possible
requests
to
do
some
basic
API
coverage,
but
yeah
I
think
our
our
test
suite
is
likely
woefully
inadequate
both
of
api's
and
features
and
behaviors
like
do
pods
get
routable
IPs,
and
can
they
talk
to
each
other
stuff
like
that?
I
think
is
likely
pretty
poorly
tested
at
the
moment.
B
A
D
D
Try
out
the
whole
folder
here
in
a
minute,
but
these
are
the
three
that'll
probably
be
the
most
interesting
right
off
the
bat
Brian
to
you.
The
first
one
is
the
api's
I
tried
to
document
at
each
layer.
What
are
the
different
api's
that
we
currently
have,
including
beta
and
alpha
ones?
The
thing
that
I
didn't
include
here
that
I
was
not
sure
about
is
where
Service
Catalog,
felon
I
know.
You
had
included
that,
but
I'm
not
sure
whether
is
that
in
and
out
of
core
or
is
that
considered
ecosystem
I
wasn't.
B
So
it's
gonna
be
more
nuanced
than
that
and
we
have
you
have
in
your
diagrams
three
layers:
the
nucleus
application
layer
and
the
governance
layer,
the
governance
layer,
I
think
I
said
the
way
I've
been
thinking
about
them
is
the
nucleus.
Is
you
know
the
minimum
essential
functionality?
That's
not
not
pluggable.
It's
you
have
that
in
the
write
up,
the
application
layer
is
all
pluggable,
but
the
API
is
those
API
to
do
anything
useful.
The
governance
layer
is
like
totally
optional
so
and
it,
but
the
governance
layer
is
has
a
bunch
of
API.
D
But
then
we
get
to
this
idea
of
ecosystem
right.
I
just
dropped
another
link
into
a
diagram
here,
because
I've
done
a
couple
more
diagrams,
so
just
try
to
explain
that
difference
between
what
is
kubernetes
at
it's
at
its
core
or
whatever
word
versus
the
ecosystem,
because
I
don't
I
want
to
make
sure
that's
communicated
well
and
and
it's
easy
to
get
confused.
Yeah.
B
D
B
I
think
we're
gonna
have
to
refine
I,
don't
know
that
I
can
come
up
with
something
solid
off
the
top
of
my
head
right
now,
but
we're
gonna
have
to
refine
the
core
and
ecosystem
terminology,
because
you
know,
especially
as
we
flush
out
the
governance
for
the
project.
There's
a
whole
there
going
to
be
official
projects
which
are
that's.
B
Yeah
we'll
have
to
come
up
with
a
better
way
to
distinguish
things,
especially
as
we
come
up
with
more
clear-cut
rules
about
what
things
should
be
in
scope
for
the
project
as
a
whole
versus
out
of
scope-
and
you
know
I
think
you
pointed
out
previously
that
there
are
some
things
which,
if
you
squint,
they
seem
to
be
at
the
same
level.
But
we
currently
have
a
distinction,
because
you
know
some
are
official
criminales
projects
and
some
are
not
so
we
do
have
to
work
through
some
of
those
details
still.
I
And
wonder
if
it
wouldn't
be
useful
to
actually
draw
out
the
actual
dependencies
between
these
api's
rather
than
kind
of
philosophize
about
what
layers
things
should
be
considered
to
be
in
in
practice,
each
one
of
these
boxes
depends
on
some
other
set
of
boxes
except
the
ones
right
at
the
bottom.
Have
you
seen
my
long
document
Quinton
you've
written
lots
of
long
documents,
so.
B
I
D
D
E
B
Someone
challenge
is
that
layering
is
kind
of
aspirational
and
that's
right
now.
The
API
server
and
the
controller
manager
are
monolithic,
yeah
and
we're
trying
to
make
them
not
have
to
be
modeled
with
it.
We're
gonna
need
more
flexibility
in
how
we
produce
release
artifacts,
like
some
people
may
want
an
all-in-one
binary
for
mini
cube
or
hypercube.
Other
people
may
want
these
things
split
out
into
separate
components,
to
make
them
more
easily
pluggable
or
scalable
things.
B
Look
at
that
so
I
think
the
goal
is
to
get
code
dependencies
all
sorted,
so
we
can
move
things
into
their
proper
repos
for
more
independent
development
and
make
the
API
machinery
work
so
that
people
could
run
these
things
outside
the
nucleus
API
server,
a
controller
manager
as
possible.
We
may
even
want
to
read
bundle
some
of
the
components
that
we
don't
end
up
with
50
components
running.
We
might,
for
example,
want
to
combine
the
API
server
and
controller
manager
into
the
same
binary.
I,
don't
know.
B
A
At
this
now
and
and
and
I
can't
believe,
I'm
gonna
say
this
I
I
think
we
almost
need
another
layer
here,
because
when
I
look
at
the
nucleus,
there's
core
concepts
that
get
exposed
to
users
and
then
there's
a
set
of
api's
here
that
are
necessary
for
us
to
sort
of
bind
together.
This
sort
of
you
know
core
control,
plane
right
and
I'm.
Looking
at
specifically
like
the
token
Review
API
recently
vald
started
using
this
for
their
Authenticator
I.
Think
it's
a
mistake.
I've
called
them
out
on
that
and
I'm
talking
to
them
about
that.
A
Really.
That
is
like
nobody.
Besides,
like
the
cubelet,
you
should
really
be
using
that
with
the
way
that
we
do
tokens
right
now,
because
if
you,
if
you
do
it
some
other
way,
you're
encouraging
people
to
hand
these
tokens
around
willy-nilly
and
it's
a
bad
idea
so
like
things
to
actually
sort
of
like
what
we're
gonna
have
to
create
new
API.
A
So
as
we
explode
out
the
control
plane
and
as
we
do
more
aggregation
and
those
api's
are
not
necessarily
user
facing
like
pod,
they
really
feel
like
they're
in
a
different,
different
layer
or
different
different
group
than
something
like
pod.
Although
some
are
like
subject
access
review,
you
might
think
well,
yeah.
B
A
B
You
know
in
each
of
these
layers,
I
had
at
least
two
two
buckets
two
main
buckets
so
grouping
these.
According
to
those
buckets,
you
know
it,
nucleus
is
Apio
machinery
and
the
execution
inside
pods
and
nodes,
and
so
on
application,
layer,
deployment
and
routing
the
governance,
layer,
automation
and
policy.
So
I
think
it
would
be
helpful
to
group
according
to
those
two
separate
categories
in
each
layer.
So.
A
B
B
Libraries,
but
the
API,
the
nucleus,
API
server
itself
is
a
component
that
exposes
api's
like
component
status,
although
that's
an
API
hate.
Yes,
yes,
component
status
is
a
great
example
yeah,
but
any
any
case.
I'm
the
API
machinery
stuff
related
stuff-
that's
in
here
is
not
referring
to
the
generic
libraries,
which
is
like
G.
Rpc
is
G
RPC
of
auxin,
with
Jeremy's
I'm.
A
Thinking
like
like,
like
a
lot
of
the
authorization
stuff,
is
really
API
machinery
stuff,
as
we
have
ways
for
registering
and
tracking
components
within
a
system
configuring,
the
the
aggregation
of
the
API
server.
We
may
have
some
stuff
around
component
contagion
sort
of,
like
you
know,
admission
control,
hooks
yeah
yeah.
This
is
relatively.
B
But
it's
it's
really
it's
needed
by
developers
who
are
building
stuff
on
top
of
the
API
like.
If
you
look
at
the
discovery,
API
or
the
subject,
access
review
stuff
like
that
people
who
are
building
clients
will
need
to
use
these
API
so
yeah
on
the
API
machinery
side.
Very
few
of
the
API
is
other
than
event
are
actually
really
user
facing.
B
It's
really
all
the
execution
stuff
that
is
user
facing
at
the
nucleus
level,
which
I
think
is
actually
the
right
thing
right
like
the
nucleus,
is
the
foundation
for
building
everything
else,
and
most
users
don't
even
directly
use
for
the
most
part.
They
don't
directly
create
them
anyway.
I
mean
they
observe.
They
know
they
exist
yeah.
They
know
they
exist.
B
B
D
You
can
feel
free
to
edit
or
leave
comments
on
it
and
then
I'll
go
back
and
I
can
clean
them
up
and
try
and
make
them
consistent
and
and
that
kind
of
thing,
but
feel
free
to
leave
either
edit
them
or
make
comments.
If
there's
a
change
and
I
can
worry
about
cleaning
up
alignments
and
stuff
like
that
later,
okay.
D
I'll
put
them
into
you,
the
groupings
you
wanted,
I,
don't
know
what
you're
talking
about
so
I
can
do
that
bit.
But
if
there's
something
that's
in
the
wrong
layer
or
if
there's
a
comment
you
want
to
make
on
it,
go
ahead
and
feel
free
to
do
that,
but
that
grouping
one
I
know
what
you
meant
and
I
can
do
that.
Okay,.
D
D
I
D
B
So
I
imagine
the
first
consumer
to
be
kubernetes
contributors,
okay,
yeah
I,
know,
I
think
it
definitely
feels
like
an
inside
baseball
type
of
thing.
Cuz
most
to
you,
it
totally
is
I
know
trying
to
provide
some
clarity
for
so
we've
had
this
explosion
of
api's
and
yes,
we
will
have
to
expect
have
a
moratorium
on
new
api's
next
year
in
the
kubernetes
kubernetes
anyway,
we
have
about
60.
Now,
there's
a
constant
area.
Yeah.
B
So
yeah
with
that
many
api's,
it's
definitely
needs
to
be
made
clear
to
all
these
people
who
are
working
on
these
api's,
how
they
fit
into
the
bigger
picture
and
yeah.
What
what
things
can
they
depend
on?
Should
they
assume
that
there
must
be
an
implementation
in
the
system.
For
example,
I
did
I
deliberately
put
ingress
in
the
application
layer
today,
their
API
is
there
by
default,
but
it
has
no
implementation
by
default,
all
right.
Anybody
doing
anything.
B
What
needs
l7
load-balancing,
like
anybody,
writing
a
micro
service
or
a
web
app
and
deploying
that
needs
a
little
balancing,
so
I
want
batteries
included
default
implementation
for
ingress
like
this
is
one
of
the
number
one
things
that
people
like
about
swarm
compared
to
kubernetes.
It
definitely
should
be
pluggable
like
everything
else
in
the
application
layer
you
can
swap
out
the
scheduler.
B
You
can
swap
out
queue
proxy,
but
there's
no
good
reason
why
we
just
shouldn't,
have
all
seven
little
balancing
and
the
system
now
and
I'm
talking
to
Tim
about
that
stuff,
Tim,
Tim,
Hagen,
yeah
and
I
I.
Think
Tim
is
on
board
with
that
as
well
I'm
there.
So
we
I'm
not
necessarily
happy
with
the
current
ingress
API.
We
need
to
make
some
changes
to
it,
but
you
know
we
need
something
that
fills
a
roughly
Engrish
atoll
in
that
in
that
layer.
D
I
Would
assume
one
of
the
main
kind
of
consumers
of
this
would
be
applications
wanting
to
know.
You
know
how
much
of
kubernetes
do
I
need
to
install
in
order
to
get
this
application
to
work
properly,
where
it's
we
stand
on?
The
idea
of
having
is
that
what
these
layers
are
intended
to
be
that
you
can
install
a
red
layer
only
or
a
red,
plus
blue
layer
or
red
plus
blue
plus
green
sorry
I'm,
just
making
up
the
colors
because
I
didn't
the
picture
in
front
of
me
is
that
I.
B
Was
it
eventually
like
once
we
get
the
Governance
layer?
Api
is
moved
out
or
the
core
D
one
monolithic,
API
group,
and
we
get
API
aggregation
fully
fleshed
out
then,
and
we
move
all
the
code
around
then.
Yes,
it
might
be
possible
to
run
without
that
layer.
But
I
would
like
this
to
inform,
for
example,
what
resources
make
sense
at
a
home
chart.
My
opinion
is
the
governance
layer.
Api
is
probably
don't
belong
in
an
off-the-shelf
configuration.
B
Those
are
things
that
people
are
almost
always
want
to
kind
of
want
to.
Customize
I
would
like
to
see
some
tooling
to
auto-generate
some
of
that
stuff,
for
example,
I'm,
starting
to
see
our
back
rules
and
a
bunch
of
thumb
charts,
but
the
auth
policy
is
completely
pluggable.
Even
today,
right,
like
you
can
run
your
totally
different
auth
mechanism.
It
would
be
really
easy,
I
think,
to
write
a
tool
that
could
auto
generate
the
auto
policies.
You
need
from
the
resources
themselves,
so.
A
Quentin
I'm
going
to
actually
disagree
with
Bryan
here,
a
little
bit
when
he
first
wrote
this
document
with
the
architectural
layers.
I
think
there
was
some
confusion
on
whether
this
was
the
conformance
effort
or
not
the
conformance
effort
and
I
think
this
can
help
us
inform
sort
of
water.
The
API
is,
what's
the
behavior
that
we
need
to
be
conformant
but
I,
don't
think
layers
mean
conformance
and
I.
Think.
A
And
maybe
it's
just
wording
and
but
I
think
when
users
come
to
and
they're
like
well
what
type
of
cluster
or
do
I
need
to
run.
This
application
I
see
that
as
a
conformance
profile
versus
actually
a
layering
type
of
thing
right,
because
we
have
to
provide
some
guidance
to
users
of
like
will
this
application
work
on
this
cluster
and
I
and
I?
Think
I?
Don't
think
this
is
necessarily
it
completely.
B
D
A
D
A
A
D
We
can
say:
governance
is
optional,
so
in
conformance
testing
we
we've
got
an
easy
picture
to
say:
okay,
this
set
is
optional,
and
so
this
isn't
required.
So
if
you're
doing
like
portable,
you
know
charts,
you
can
say.
Oh,
we
shouldn't
do
anything
in
the
governance
layer
because
that's
entirely
optional
on
a
cluster,
but
everything
else
is
required.
Even
if
it's
pluggable
correct.
B
Yeah
I
mean
it's
a
little
bit
dual
purpose.
It
actually
Tim
had
started
the
document
and
it
was
more
geared
towards
conformance
and
then
I
kind
of,
took
over
and
took
it
in
a
different
direction,
but
yeah
it's
yes,
I
agree.
Ideally
we
should
be
able
to
you.
Have
these
delayering
in
form
those
kind
of
yeah
decisions
as
well
and.
A
I
want
to
be
careful
about
words
like
required.
It's
like
nobody
requires
you
to
do
anything.
What
we
can
say
is
that,
if
you
don't
include
these
things,
then
like
no
warranties,
it's
not
well
tested
you're
on
your
own
you're
off
the
map,
yeah
you're
not
guaranteed
that
an
off-the-shelf
company's
configuration
will
work.
I
One
of
my
to
be
clear.
One
of
the
reasons
for
my
questions
to
comment
earlier
was
that
I'm
not
totally
convinced
that
we
haven't
got
like
too
many
things
in
each
layer.
I
mean
I,
can
see,
there's
a
convenience
and
had
not
having
an
infinite
number
of
layers.
But
yes,
if
I
was
building
a
particular
kind
of
application,
let's
say
like
a
batch
processing
thing
or
something
and
maybe
I
don't
need
any
like
storage
and
I,
don't
need
any
l7
load.
Balancing
and
I
don't
need
any
of
that
stuff.
I
I
can
imagine
like
taking
a
subset
of
the
nucleus
as
it's
shown
on
the
diagram.
You
know
throw
away
all
the
storage
stuff
and
maybe
some
other
stuff
and
say
that's
what
I
need
of
kubernetes
and-
and
you
know
they
said
it
would
build
a
cluster
like
that
and
run
my
application
and
everything
should
work.
It's.
B
A
Wise
so
but
okay,
but
like
you,
can
build
a
non-conforming
cluster,
you
can
do
your
thing,
there's
no
guarantees,
it's
gonna
be
up
to
you,
but
I
will
say
and
if,
if
something
like
that
catches
on-
and
it
actually
becomes
something
that
a
lot
of
users
want,
then
let's
define
that
as
a
new
sort
of
conformance,
II
type
of
thing
and
then
let's
start
testing
it,
because
there's
obviously
user
demand.
So
I.
Don't
think
that
this
is
necessarily
like
Ryan
says
zero
chance,
I
would
say.