►
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
Component Standard Working Group - Leigh Capili, Weaveworks & Michael Taufen, Google
The Component Standard Working group is charged to develop a standard foundation (philosophy and libraries) for core Kubernetes components to build on top of. Areas to standardize include configuration (flags, ComponentConfig APIs, ...), status endpoints (healthz, configz, ...), integration points (delegated authn/z, ...), and logging. In this talk we will outline current progress and challenges and how new contributors can get engaged.
https://sched.co/UahD
A
B
A
So
today
we're
going
to
start
out
with
just
a
little
bit
of
history,
of
kind
of
some
of
the
problems
we
were
solving
last
year
and
how
this
working
group
got
started
and
then
we'll
talk
a
little
bit
about
our
working
here
today.
Some
of
our
current
projects
contributors
some
of
our
mentorship
efforts
and
also
how
you
all
can
get
involved.
C
So,
just
like
the
bit
of
the
history
component,
we're
gonna
just
make
sure
we
hit
the
basics
so
that
we're
not
assuming
anything
the
kubernetes
style
API.
It
looks
a
little
bit
verbose
and
you
might
be
used
to
seeing
these
things,
especially
by
the
end
of
this
conference,
and
maybe
all
of
that
looks
a
little
bit
much.
But
when
we
have
these
things
in
the
amyl
file,
we've
got
a
kubernetes
object.
It's
got
some
really
nice
properties
that
we
can
use.
C
That
really
are
the
foundation
for
all
of
our
tooling
and
the
way
that
kubernetes
enables
an
entire
ecosystem
of
tools
to
be
built.
What
does
API
machinery
really
mean?
There's
a
core
portion
of
this,
and
the
first
key
idea
is
that
when
we
have
API
machinery
we
get
versions,
we
get
schema,
that's
versioned
all
right,
so
we
have
this
version
of
the
API.
This
version
of
the
API,
this
version
of
the
API
and
there's
three
components
to
this.
That
kubernetes
calls
the
GVK.
You
might
see
this
in
the
code.
C
It
stands
for
group
version
kind
right
and
that
three
section
component
right
there
is
represented
in
this
API
version
and
kind
field
that
you
see
on
everything
I
know
definitely
that
when
I
first
started
using
kubernetes
I
was
a
bit
tired
of
writing
this
over
and
over
again,
but
when
you've
specified
the
API
version.
This
gets.
C
You
several
guarantees
all
right
so
right
here
we
see
the
group
is
Apps
and
then
the
versions
of
e1
the
kind
is
deployment
and
the
things
that
we
get
when
we
specify
this
GVK
are
that
we
now
have
a
stable
plat
form
to
ensure
behavior
when
things
are
asking
us
about
operating
on
a
specific
GVK.
This
means
that
something
like
the
API
server
can
serve
multiple
versions
of
the
API.
At
the
same
time,
we
have
a
version.
Deprecation
policy
that
you
can
read
about
in
the
community.
C
Repo
I
believe
is
where
that
Docs
and
then
now,
as
a
user
or
as
somebody
who's
building
a
system,
you
can
write
config
such
as
a
v1
deployment
and
for
as
long
as
the
API
server
continues
to
support
that
config.
Even
when
there's
a
v2
or
v2
alpha
one
that
you
know
that
that
configure
is
going
to
work
the
same
way,
so
your
config
is
good
and
it's
also
supported
by
multiple
tools.
C
We
have
help,
could
CTL
customize,
multiple
different
tools
that
can
use
these
api's
but
to
basically
read
write,
parse
them
and
build
on
that
common
layer,
and
then
now
users
have
an
upgrade
path.
Also
lets
you
do
things
like
conversions
and
some
of
these
more
advanced
things,
validation.
Api
machinery
serves
us
in
many
ways
that
we
take
for
granted,
but
our
core
to
the
project.
C
A
That
all
sounds
great
most.
You
are
probably
familiar
with
that
from
working
with
kubernetes
so
like
what's
actually
the
problem
like
we
use
these
animals
every
day,
they
mostly
get
the
job
done.
That's
great.
So,
first,
let's
take
a
step
back
if
you've
used
a
UNIX
style
computer
system
in
the
past,
you're,
probably
familiar
with
the
command
line.
You've
got
these
four
commands
which
your
program
is
installed
on
the
system
and
most
of
them
take
flags
that
describe
some
kind
of
configuration.
A
A
With
all
these
components,
things
get
a
lot
more
complicated,
our
flags
still
sufficient,
because
today,
even
though
all
the
things
in
your
cluster
are
configured
with
these
nice
animals,
all
of
the
components
running
the
cluster
at
self
are
still
configured
with
command
line
flags.
So,
if
you've
ever
configured
a
kubernetes
cluster
from
scratch,
you've
probably
seen
something
like
this,
which
is
a
little
bit
harder
to
work.
With
it's
hard
to
read
it's
hard
to
write.
A
A
However,
they
are
not
versioned
independently
from
your
kubernetes
version
and
if
you
have
paid
attention
to
kubernetes
versioning
in
the
past,
you'll
know
that
we
use
semantic
versioning
and
every
release.
We
increment
the
minor
version
which
suggests
that
everything
should
just
continue
to
work
and
there
should
just
be
some
new
features.
However,
all
of
the
api's
in
the
api
server
are
versioned
independently
from
that
and
over
there
breaking
changes
are
communicated
in
those
versions.
What
do
we
do
for
command
lines?
A
Well,
actually,
we
just
have
a
policy
that
says
if
you
pay
attend
release,
notes
and
if
you
appear
to
pay
attention
to
warnings
in
your
logs,
will
tell
you
when
things
are
gonna
break,
and
you
should
just
make
sure
you
pay
attention
to
that.
So
there's
actually
nothing
in
the
overall
kubernetes
version
that
expresses
breaking
changes
in
admin
facing
component.
A
So
that's
problem
problem.
Number
two:
is
that
tools
can't
understand
these
all
of
these
sort
of
custom,
special
structures
that
are
embedded
in
these
arbitrary
strings
and
the
command
line
are
only
known
to
the
component,
that's
parsing
them
and
the
libraries
that
do
that
aren't
available
anywhere
for
anyone
to
consume.
So,
if
someone
says,
could
you
write
something
that
can
generate
a
command
line?
Config
for
the
cubelet?
You
have
to
go
into
the
code
figure
out
what
it's
doing,
try
and
replicate
it
and
hope
it
doesn't
change.
A
The
same
thing
is
kind
of
true
on
the
internal
implementation
side.
It's
a
problem
because
every
time
you
invent
another
structure
in
there,
so
you
invent
a
new
kind
of
list,
that's
separated
with
a
different
separator
or
you
wanted
to
use
less
than
or
greater
than
signs
in
some
kind
of
map
type
structure,
because
it
looked
better
for
resource
constraints.
A
A
Well,
it's
something
that
we
in
the
community
of
started
to
call
component
config,
that's
kind
of
a
term
of
art,
for
it
and
all
it
is,
is
use
kubernetes,
style,
api's
to
configure
components
to
people
like
them,
because
they're,
readable
and
writeable,
or
what
we're
used
to
in
kubernetes.
They
have
clear
stability
policies
that
are
expressed
in
the
same
way
as
all
the
other
kubernetes
api
is
that
people
are
used
to
working
with
via
the
API
server
and
tools
like
them,
because
the
animal
is
a
common
format
with
wide
support.
A
The
API
version
in
kind
and
other
API
machinery,
characteristics
and
kubernetes
are
supported
by
a
lot
of
kubernetes
centric
tools
like
customize
and
helm,
and
so
by
avoiding
all
these
sort
of
non-standard
structures
in
command
lines.
We
stopped
preventing
inner
operations
start
enabling
it
so
these
versions
scheme
has
really
helped
everyone,
and
so
what's
actually
our
progress
so
far
in
doing
this
well
about
a
year
ago,
I
was
working
on
it
a
lot,
and
so
we
managed
to
get
the
qubit
to
a
view.
One
beta
one
API
for
a
component
config.
A
We
had
a
few
other
groups
in
the
community,
pick
up
the
idea
and
start
to
implement
it
in
components
like
cube
proxy
and
keep
scheduler,
and
so
those
are
currently
sitting
at
D
1,
alpha,
1,
cube
ATM
was
really
enthusiastic
about
it
and
is
actually
totally
driven
by
component
config,
kubernetes
style
api
is
today
and
it
can
generate
the
configs
for
the
other
components.
But
that
said,
we
have
this
large
in
progress
migration
across
that's
taking
place
across
multiple
releases.
A
Many
of
the
components
in
kubernetes
have
hundreds
of
options,
and
so
it
just
takes
a
lot
of
time
to
kind
of
argue
about
what
should
the
structure
of
this
thing
be
when
we
transform
it
into
yamo?
Should
we
because
we're
actually
inventing
a
new
version?
Should
we
change
some
defaults
and
make
it
more
secure
and
all
those
things
make
this
kind
of
migration
take
time
so,
as
I
moved
on
to
other
projects
inside
of
Google
other
people
working
on
it,
maybe
they
started
University
or
they
wanted
to
focus
more
on
their
families.
A
It
gets
harder
and
harder
to
find
time
to
work
on
this.
So
what
we've
realized
is,
rather
than
just
putting
more
Sharan
people
who
are
already
working
on
it
to
get
work
done
when
they
can't.
We
actually
need
to
start
bringing
more
and
more
people
in
to
our
working
group
and
into
the
community
to
work
on
these
things
and
create
more
sustainable
leaders.
A
So
that
was
a
big
reason
that
we
started
working
group
components
standard
unless
to
further
this
component
config
work,
and
then
we
realized
that
there
are
some
other
areas
with
a
lot
of
refactoring
and
standardization
that
are
needed
in
the
project.
So
we
didn't
just
make
it
work
in
group
component
config,
we
made
it
working
group
components,
standard
and
we're
really
excited
about.
C
Sometimes
people
ask
us
okay.
Well,
what
does
component
standard
do?
I
mean?
We've
talked
a
little
bit
about
that.
But
how
do
you
concisely?
Explain
you
know
to
somebody
what
the
value
of
an
infrastructure
portion
of
the
project
like
has
to
kubernetes
on
users
and
vendors
folks
who
are
relying
on
this
platform,
and
we
say
that
when
you
want
something
to
work
the
same
way
across
kubernetes
components,
then
you
should
come
here
and
to
get
a
little
bit
more
to
our
mission
statement.
C
We
want
to
develop
a
standard
philosophy,
a
standard
set
of
libraries,
a
standard
approach,
that's
cohesive
across
all
of
the
kubernetes
components.
So
as
we
build
and
maintain
the
project
that
it
just
works
right
and
if
you
have
a
CDE
and
you
have
to
patch
the
vulnerability
and
a
single
component
becomes
much
more
difficult
than
if
authentication
is
in
a
central
place.
So
some
of
those
areas
beyond
what
component
config
has
already
been
discussed
by
Mike
the
flags
and
the
API
is
associated
with
that
the
generation,
the
tooling
the
linting
and
testing.
C
There's
things
like
status,
endpoints
right.
So
how
do
you
know
that
the
API
key
server
is
configured
correctly
right
and
if
you're
running
a
security
conformance
tools
and
how
does
it
know
that
it
shouldn't
have
to
parse
command
line
in
order
to
figure
out
they're
using
the
right
options?
And
it
probably
gets
that
from
the
process
table.
So
the
integration
points
like
the
delegated
authority
zatia?
If
you
want
to
plug
that
into
something
that
you
write
on
top
of
kubernetes,
that
should
definitely
be
standard.
C
It's
a
security
surface
and
then
instrumentation
logging
and
metrics
of
the
project,
which
are
important
for
understanding
how
it
performs
debugging
in
production-
and
you
know
instrumentation-
is
its
observability
for
the
project
and
it's
a
pretty
key
point
all
the
details
about
how
some
of
the
the
details
about
how
some
of
these
things
should
be
implemented.
Some
of
the
context
where
they
are
non-conforming
with
each
other
is
available,
starting
in
kept
32
and
onward.
B
A
So
we
have
a
bunch
of
different
projects
in
those
areas
that
we
just
talked
about.
A
major
focus
right
now
is
continuing
these
flag
to
config
migrations.
We
have
people
working
on
qubit,
Cupar,
Q,
proxy
cubes
scheduler
and
the
controller
managers
right
now.
We
have
also
been
doing
some
work
around
strict
decoding.
What
that
means
is
in
the
past.
If
you
wrote
this
configuration
file
handed
it
over
to
your
component
and
you
made
a
typo
in
one
of
the
field
names
that
field
would
just
be
ignored
and
set
to
the
default
value.
B
A
A
big
improvement
in
usability
we've
got
some
improved
testing
coming
in
we're
doing
some
cleanup
in
some
of
the
flag
backwards,
compatibility
layers
that
we
implemented
with
the
original
migration.
Again
we're
standardizing
and
breaking
out
some
of
these
common
server
endpoints.
We
have
someone
new
to
the
working
group,
who's
working
on
a
structured
logging
solution
across
the
project,
and
it's
actually
been
really
fun.
At
Keep
Calm
we've
had
more
and
more
people
come
to
us
and
say:
hey
I
want
to
help
with
like
improving
this
other
endpoint
or
there's
this
other
area
like
with
TLS.
A
That
I
think
could
be
more
standard
across
the
project.
Like
can
I
help
you
guys
out
doing
that,
and
it's
been
really
cool
being
here
at
cube.
Con
we've
got
a
lot
of
interest
yeah,
so
one
of
the
other
things
that
we
started
doing
back
in
september
has
to
kind
of
realize
that
our
time
was
getting
thinner
in
terms
of
being
able
to
focus
on
the
technical
stuff
was
that
we
need
to
start
creating
more
sustainable
leadership
in
our
community
and
especially
in
our
working
group.
A
So
we
sent
out
an
offer
for
direct
mentorship
for
folks
who
are
interested
and
a
list
of
projects,
and
we've
got
15
people
who
are
now
working
on
key
projects
in
our
working
groups
of
mentorship
group,
some
of
whom
we've
actually
gotten
to
meet
of
coupons.
Yes,
not
a
lot
of
flow,
it's
been
really
cool
and
so
you'll
see
these
people
around
the
community.
More
and
more,
there
they're
doing
more
and
more
to
help
out.
Some
are
ramping
up,
some
have
since
MPR's
already,
and
that's
actually
what
the
next
lines
about
yeah.
C
And
were
hugely
grateful
for
the
for
the
time
that
people
are
taking,
you
know
to
move
kubernetes
forwards.
Kelsey's
keynote
like
really
struck
a
chord
with
me
right.
We
all
get
together
with
each
other
and
we're
drafting
along
as
push
this
project
and
folks
have
differing
constraints
and
different
things
that
they're
looking
to
accomplish
some
people
will,
you
know
like
primed
to
be
leaders
and
the
future
leaders
of
the
project
and
other
folks
have
that
five
minutes.
C
Other
folks
have
that
three
hours
a
week
and
it's
been
really
exciting
to
meet
people
and
and
see
that
they
like
pick
up
projects
and
accomplish
things,
and
so
some
of
these
areas
that
we've
talked
about
and
the
past
about
six
months,
we
started
shipping
patches,
there's
a
core
implementation
portion
of
this
component
config.
The
strict
serializer
thing
that
Mack
Mike
talked
about
with
the
usability
of
configs
dropping
on
node
fields.
C
A
C
And
then
kind
of
the
meta
task
right
is
that
there's
a
huge
wall
using
kubernetes
lots
of
resources,
developing
kubernetes,
especially
when
you
get
into
the
guts,
helping
people
build
a
proficiency
and
then
building
the
documentation.
The
community
that
allows
people
to
continue
like
having
ownership
of
the
core
is
a
really
exciting
thing.
That's
happening
in
this
working
group,
there's
other
things
that
are
happening.
We
have
an
open
core
implementation
library
for
the
testing
in
conformance
of
component
config
api's,
making
sure
that
it's
not
easy.
C
You
know
to
assemble
things
with
API
machinery,
so
how
do
we
ensure
that
they
stay
correct
and
that
things
are
uniform
across
all
of
these
components?
We
could
do
that
with
a
test
suite
and
that
the
exceptions
will
now
be
built
into
the
code
so
that
we
know
where
things
are
not
conformant
right
and
then
also
there's
this
area
of
flag
and
config
handling,
with
components
and
historically
in
the
project.
C
We've
had
some
complex
logic,
such
as
in
the
couplet
to
make
sure
that
flags
could
override
component
config
api's
as
a
backwards
compatibility
layer
so
that
people
can
continue
operating
the
couplet
in
the
way
that
was
necessary.
But
then
moving
towards
this
component.
Config
and
other
components
saw
that
and
either
chose
or
did
not
choose
to
implement
it.
For
various
complexity
reasons,
as
well
as
the
constraints
of
maintaining
the
project
and
so
Mike
published
this
legacy
flag,
prototype
library
which
has
merged
in
kubernetes
eggs.
C
And
then
we
have
another
contributor
that
has
this
coup
proxy
prototype,
which
is
open
for
reviews
on
how
we
can
get
legacy
flag,
perhaps
working
as
a
uniform
way
to
do
overrides
as
we
support
the
backwards
compatible
interface
of
flags
for
operators.
So
how
you
can
get
involved
with.
Obviously,
we've
got
a
couple
work
streams
and
then
there's
folks
who
are
working
with
the
project
that
you
can
reach
out
to.
C
But
then
we've
got
normal
kubernetes
governance,
which
means
that
we
have
an
open
meeting,
that's
available
on
the
public
and
it's
recorded
to
youtube
so
that
you
can
a
synchronously
consume.
The
meeting
notes,
which
are
in
a
Google
Doc
format
and
then
the
actual
video
and
audio
on
YouTube,
and
then
we
have
the
mailing
list,
there's
also
an
office
hours
office
hours
is
great
because
you
can
just
jump
on
and
hang
out
with
this
like.
B
A
Of
people
were
looking
for
a
space
where
they
could
come
and
ask
kind
of
questions
and
get
more
one-on-one,
in-person
support
and
so
mm-hmm
every
Tuesday
for
an
hour.
We
have
an
office
hours
where
I'll
sit
in
there
or
Leo
sitting
there
on
video
for
an
hour,
and
anyone
can
drop
in
whenever
it's
convenient.
For
them
ask
questions.
We
do
code
deep
dives.
We
do
code
reviews,
sometimes
kind
of
whatever
people
need
to
keep
their
progress.
Moving.
Mm-Hmm.
C
The
Google
Group
is
a
part
of
the
permissions
model,
and
if
you
join
that
it's
public
you
just
have
to
join
it,
then
you
get
the
calendar,
invites
you
get
the
messages
from
the
Google
Group
forum,
and
it
also
gives
you
edit
permission
to
our
meeting
notes
so
that
you
can
participate
and
schedule
things
that
you
want
to
talk
about
ahead
of
time.
Our
github
has
the
readme
that
is
kind
of
how
you
get
all
of
this
information.
C
If
you
were,
you
know
finding
us
online
and
in
the
github
readme
we
have
it's
inside
of
the
community
repo
kubernetes
community.
We
have
links
to
the
project
board.
We
have
information
about
all
of
this.
We
have
a
schedule
for
when
the
calls
are
held.
So
you
can
just
go
to
that
one
place
and
get
connected
with
all
of
this,
and
then
we
really
need
help
with
project
management.
So,
if
you're
watching
this
or
you're
here
right
now-
and
you
are
a
project
manager
has
experienced
like
just
helping
keeping
things
organized
task
management.
C
If
you
only
have
a
little
bit
of
time-
and
you
can
spend
that
a
little
bit
of
time,
helping
keep
the
project
and
more
organized,
that
would
be
super.
Super
helpful
we'd
be
very
grateful
because
the
influx
of
work
has
just
you
know:
it
creates
a
project
maintenance
burden
and
then,
if
you're
a
developer,
the
important
thing
is
to
keep
your
eyes
out
for
places
where
standardization
needs
to
happen
and
bug
fixes
or
re
factors
in
the
code
need
to
occur.
C
If
an
issue
isn't
open
about
the
thing
that
you
find,
please
open
it
with
the
issue
label.
If
you're
reading
an
issue
you
mean
as
a
user
and
you're
like
oh,
that
behavior
seems
kind
of
non-standard,
or
we
should
think
about
how
to
make
that
uniform.
Then
we're
able
to
add
that
to
our
project
management
triage
with
just
labeling
w/g
component
standards.
So
please
do
that
and
then.
Lastly,
in
addition
to
Mike
and
I,
there's
also
Stefan
Jumanji
from
Red
Hat,
who
helps
a
chair
of
the
project
and
then
on
slack.
C
We
have
to
slack
channels
the
first
being
the
main
group
general
chat
and
then
also
the
specific
mentorship
program
chat,
which
is
a
better
place
to
you
know
if
you
feel
a
little
bit
uncomfortable,
it's
a
comfortable
place
to
ask
beginner
questions,
requests
one
on
one
time
schedule
problem
solving
with
your
peers
posts.
You
know
things
that
are
you
know
it's
just
a
little
bit
more
dedicated
that
space
for
the
mentorship
and
yeah.
Please
come
join
the
call
get
involved
with
us.
C
A
C
B
D
B
D
B
A
Other
pieces
have
published
their
API
is
in
the
staging
repos,
so
I
think
that's
something
we
can
revisit
in
the
future,
and
that's
that
has
come
up
a
few
times
in
meetings.
Another
thing
that's
come
up
is
finding
ways
to
export
like
conversion
functionality
between
versions
having
that
internal
type,
be
private,
makes
it
really
hard
for
tools
to
like
consume
a
library
that
lets
them
do
the
conversion
on
behalf
of
a
user.
So
those.
C
Reason
why
the
internal
library
is
private
is
because
it's
an
implementation
detail
of
the
API
machinery,
so
we
can
add
things
in
there
and
change
it
without
having
any
kind
of
guarantee
or
parity
with
the
external
type,
which
is
the
important
interface.
But
yes,
the
defaulting
and
conversion
logic
is
one
of
them,
one
of
things
for
component
fit
config,
UX,
and
so
we're
actually
really
interested
in
what
we
said
earlier.
Basically,
we
need
to
capture
this
because
we
we
need
to
expose
some
sensible
interface.
There's
a
couple
approaches
that
people
have
about.