►
From YouTube: Kubernetes Community Meeting 20191024
Description
The Kubernetes community meeting is intended to provide a holistic overview of community activities, critical release information, and governance updates. It also provides a forum for discussion of project-level concerns that might need a wider audience than a single special interest group (SIG).
See this page for more information! https://github.com/kubernetes/community/blob/master/events/community-meeting.md
Like what you see here? Continue the conversation on https://discuss.kubernetes.io
A
Hi
everyone
and
welcome
to
this
week's
kubernetes
community
meeting
hope
you're
all
having
a
fantastic
week.
My
name
is
Jonas
Rothman
and
I'll
be
your
host.
For
today,
before
we
start,
we
do
have
a
code
of
conduct
so
bleep,
please
be
excellent
to
each
other.
This
is
recorded
and
stream,
so
make
sure
you
don't
say
or
do
anything
that
you
don't
want
to
be
permanently
recorded.
A
B
Good
morning,
everyone
solidly
seconding
what
Jonas
said.
The
updates
are
fairly
short
and
sweet.
We
cut
the
third
alpha
released
on
Tuesday
fairly
successfully,
although
apparently
there
was
some
last-minute
live
shenanigans
going
on
so
there
the
process
was
recorded,
live
so
I
encourage
you
all
to
check
it
out.
B
If
you're
curious,
we
have
the
enhancement,
exceptions,
those
have
all
been
merged
and
they
are
being
tracked
next
week,
we'll
start
cutting
the
117
really
springe,
which
means
113
jobs
will
be
removed
for
adding
new
jobs
from
117,
and
we
are
also
cutting
the
first
117
beta.
So
that's
very
exciting.
B
A
C
Cool,
let's
see,
I
will
start
with
Zig
usability
I.
Guess
there
you
go.
Oh
car.
Can
everybody
see
my
deck
yep
yeah
cool?
Okay.
So
this
is
the
cig
usability
community
meeting
update
for
October
2019?
What
did
we
do?
Last
cycle?
We
started
a
new
cig
yay,
so
this
is
the
most.
This
is
the
newest
cig
for
the
kubernetes
community.
We
kicked
off
a
conversation
about
wanting
to
start,
maybe
a
sub
project
or
working
group.
C
Oh
well,
around
usability
and
accessibility
and
after
a
big
conversation
on
the
dev
mailing
list,
we
agreed
that
maybe
the
best
place
for
this
was
to
do
a
cig.
So
you
can
check
out
the
pull
request
if
you
want
to
see
the
whole
conversation,
but
really
what
we've
been
doing
in
the
last
couple
meetings,
since
we
suddenly
happen
a
month
or
two
ago,
is
getting
things
off
the
ground,
getting
things
organized
and
getting
started.
So
what
are
our
plans
for
upcoming
cycles?
C
What
we
want
to
look
at
holistically
is
usability
of
kubernetes,
both
from
a
community
and
a
project
perspective,
but
also
just
as
a
new
user
coming
to
kubernetes.
What
am
I
trying
to
do,
and
how
can
we
make
sure
that
we're
enabling
people
to
get
started
and
go
down
the
right
path
quickly
and
well,
so
part
of
that
is
starting
to
really
understand
who
are
the
users
of
kubernetes?
What
are
they
trying
to
do
when
they
come
to
our
project?
C
How
do
we
make
them
successful
and
then
how
do
we
make
kubernetes
accessible
for
a
wider
group
of
people?
One
thing
that
we
try
to
think
about
is
as
as
as
members
of
the
community,
a
lot
of
us
are
super
users
of
kubernetes
and
we
are
the
builders
of
kubernetes,
and
that
may
not
mean
that
we
really
understand
the
users
of
kubernetes
who
are
not
ourselves.
So
how
do
we
kind
of
make
sure
that
we're?
C
Instead,
looking
at
the
jobs,
people
are
trying
to
get
done
with
kubernetes.
So
you
know
what
is
like
at
their
end
goals,
since
kubernetes
I
mean
to
us
might
be
an
end
goal,
but
to
a
lot
of
people
as
a
tool
getting
towards
that
end
goal.
Now
we
also
have
been
talking
about
using
coop
con
as
a
user
study.
Opportunity.
C
Another
thing
that
we're
talking
about
a
lot
is
working
security
in
by
default
in
kubernetes
and
valerie
has
really
been
leading
the
charge
on
this,
and
she
has
a
session
at
the
contributor
summit
and
a
session
at
coop
con,
where
she'll
be
really
diving
into
this
and
so
kind
of
approaching
security
by
default
and
kubernetes
like.
How
do
we
do
that?
And
how
do
we
build
that
into
our?
C
You
know
what
people
get
when
they
grab
the
COO
connect
to
kubernetes
binaries,
how
these
plans
affect
you,
so
we're
really
looking
to
do
here
is
making
kubernetes
better
for
all
of
our
users
together.
If
you
have
ideas-
and
this
is
already
been
happening
organically-
which
is
awesome
if
you
have
kept
that
are
crossing
your
doorstep-
that
you
wants
to
come
and
present
like
bring
them
on
over
we'd
love
to
learn
more,
we
do
have
one
kept
from
one
of
the
co-chairs.
C
A
Himanshu
has
been
working
on
this,
and
so
this
is
a
kept
around
coop
cuddle
get
events
that
he's
been
driving.
So
currently,
events
can't
be
extended
to
meet
a
bunch
of
user
requests,
so
support
more
functionality
without
impacting
coop
Ketel
get
so
what
he
wants
to.
So
what
he's
proposing
is
to
move
this
to
a
new
to
a
new
command
events
for
Koob
cuddle,
that's
independent
of
coop
cuddle
get,
and
then
we
can
extend
that
to
address
user
requirements.
I
think
he's
presented
this
at
a
couple
different
cigs
so
far
I'm.
C
He
has
open
pull
requests.
If
people
would
like
to
check
this
out,
where
can
you
find
us?
We
have
four
chairs
me:
I'm,
Tasha,
Valerie,
Raji
and
Himanshu.
We
do
use
our
kubernetes
sig,
slash,
usability
repo
for
shared
objects,
there's
not
a
lot
in
there
yet,
but
that's
where
we
plan
to
have
like
a
single
point
where
you
can
discover
anything
that
we're
working
on
we
have.
This
link
will
take
you
to
all
of
our
meeting
notes
agenda
video
links.
C
C
I'm
trying
so
what
I
think
I
think
that,
honestly,
like
we
would
love
anyone
who
wants?
Who
takes
a
vested
interest
in
usability
to
attempt
I
think
it
is
a
really
awesome
opportunity
for
us
to
bring
in
more
people
to
the
kubernetes
community
who
don't
see
themselves
as
go
developers,
but
who
might
be
user
researchers
who
might
be
user
experience.
C
Designers
who
might
be
front
end
designers
like
I,
think
it's
an
opportunity
for
us
to
have
a
really
nice
place
for
more
people
to
collaborate
and
invest
in
the
usability
of
kubernetes
as
a
project,
and
so
I
want
to
make
it
like
a
very
like
a
place
where
all
of
those
people
know
that
we
would
love
to
have
you
here
and
we'd
love
to
have.
You
know
your
professionalism
and
just
sort
of
different
perspective
on
what
we're
doing
as
a
community.
B
C
C
So
this
is
the
multi,
a
tendancy
working
group
community
update
for
October
twenty
nineteen.
What
do
we
got?
What
we
did
last
cycles,
so
we
are
incubating
two
projects,
and
so
one
of
those
is
the
hierarchical
namespace
controller
led
by
Adrian
Ludwin
at
Google,
and
we
have
some
links
here
if
you'd
like
to
read
design
documentation
about
what
the
hierarchical
namespace
controller
is,
it
is
the
history
of
this
project
is
that
this
is
a
tenant
in
Google,
anthos
and
so
Google
anthos.
Has
this
really
nice
way
of
having
hierarchical,
namespaces?
C
That's
really
integrated
with
your
git,
workflow
and
so
Adrian
at
Google
saw
this
and
thought
that
this
would
be
something
that
would
be
really
great
to
upstream,
and
so
he
went
to
the
anthos
team
and
got
permission
to
start
up
a
project
that
is
a
more
agnostic
implementation
of
the
hierarchical
namespace
concept,
and
so
that
is
what
this
work
is.
It's
very
initial
I
have
a
couple
slides
to
kind
of
go
over
the
architecture.
Just
so
everyone
you
know
has
seen
it
I
think
it's
really
great
and
we're
seeing
some
good
progress.
C
Adrian
has
a
couple.
Other
engineers
are
also
working
with
this
on
Adrian,
but
we've
also
been
really
invested
in
the
ricci
internship
project
that
the
community,
the
kubernetes
community,
has
been
engaged
in,
which
seeks
to
bring
underrepresented
people
and
give
them
opportunities
to
get
started
as
contributors
to
kubernetes
projects.
So
right
now
we
have
three
outreach
e
candidates
working
on
the
hierarchical
namespace
controller
and
adding
some
pretty
cool
features.
C
So
that's
been
really
great
to
see.
Virtual
clusters
is
another
effort
led
by
fake
whoa
and
team,
and
they
presented
on
this
at
coop
con
in
Barcelona
and
they've
done
it
there's
a
bunch
of
documentation
if
you'd
like
to
check
it
out.
This
is
a
way
that
they,
internally
at
their
company,
have
been
sharing
kubernetes
clusters,
and
so
the
idea
is
that
a
lot
of
different
teams
want
complete
access
to
a
kubernetes
control
plane,
but
they
need
to
have
one
unified,
scheduler,
that's
really
accessing
and
providing
infrastructure.
C
So
it's
sort
of
a
layered
approach
to
having
like
a
what
they
call
here,
a
super
master
and
then
a
tenant
master,
and
so
that's
kind
of
this
virtual
virtual
clusters
concept.
So
that
is
another
incubation
project
that
we're
doing
and
I
included
a
link
to
the
architecture
there
so
a
little
more
about
the
hierarchical
namespace
controller
and
what
that
work
is
so
what
this
is
doing
is
propagating
policy
objects
from
parents
to
children.
C
The
current
the
current
code
that
we
have
in
the
prototype
is
a
hard-coded
list,
but
this
the
goal
is
to
have
that
be
configurable
by
the
end
of
the
year.
So
the
idea
is
here:
you
have
like
your
organization,
namespace,
your
are
back
your
network
policy
and
then
you
can
have
child
namespaces
under
that's
like
a
team.
Namespace
with
your
dev
are
back
and
your
team
secrets
and
then
there's
self
service
sub
namespaces
under
that.
C
So
staying
within
the
policy
that's
been
assigned
to
you,
you
can
your
team
can
create
additional
namespaces
to
deploy
applications
in.
So
you
don't
need
cluster
level
privileges
to
create
sub
namespaces.
This
includes
hierarchical,
oxi
checks.
So
if
you're
a
if
you're
a
sub
admin,
you
can't
you're
super
admins
from
having
access,
and
additionally
this
includes
integrations
via
kubernetes
labels,
so
a
namespace
would
receive
a
label
indicating
what
subtrees
they're
in
and
some
of
our
outreach
interns
have
done.
C
He
did
a
build
and
I
didn't
even
realize
it.
Yeah
Adrienne
made
this
slide.
Thank
You
Adrienne,
so
a
couple
words
about
the
hierarchic,
hierarchical
namespace
architecture.
So
it's
an
add-on
controller
based
on
coop,
builder,
controller,
runtime
and
other
projects.
It
has
two
major
aspects:
you
can
manage
the
hierarchy
configurations
and
you
can
manage
the
propagated
objects.
Namespaces
are
also
updated,
so
labels
are
applied
to
indicate
a
hierarchical
structure.
They
are
created
but
never
destroyed
for
sub
servant,
self-service
sub
namespaces
on
request,
and
then
problems
are
reported
by
a
conditions.
C
C
C
That's
kind
of
what
we
consider
hard
multi-tenancy,
which
would
be
complete
isolation
for
compute
storage
and
network
at
that
API
level,
and
it
means
people
could
different
tenants,
could
all
hit
that
master
API
from
their
namespaces
and
still
be
completely
separated.
So
that's
a
concept.
We
call
hard
multi-tenancy
and
we
see
that
as
something
that's
further
out,
so
in
the
meantime,
using
kubernetes
as
it
is
today,
we
call
that
soft
multi-tenancy,
because
if
you
have
tenants
hitting
the
API
together,
there
may
not
be
that
complete
isolation
that
you
would
want
from
hard
multi-tenancy.
C
That
kind
of
explains
our
it's
probably
a
concept
you
need
to
have
to
understand
over
at
map
so
step
one
kubernetes
today.
How
would
we
what?
What
is
it?
What
is
a
secure
single
tenant
cluster?
What
is
a
secure,
multi
soft
multi,
tenant
cluster
and
then,
as
we
have
those
benchmarks,
we
should
we
are
going
to
share
them
with
the
bug,
bounty
group
and
then
have
them,
try
to
hack
these
secure
clusters
and
give
us
feedback
and
then
iterate
on
all
of
these
tools.
C
In
the
mean
time,
we're
also
working
on
these
features
and
tools
to
improve
support
for
soft
multi-tenancy.
So
that
includes
the
hierarchical
namespace
virtual
clusters
and
a
tendency
CRD
that
we're
working
on
and
then,
as
we
work
on
these
soft
multi-tenancy
capabilities,
we
will
continue
to
see
what
needs
to
be
improved
at
the
API,
Machinery
and
authentication
layers
and
then
gather
those
requirements
and
put
together
feedback
for
those
SIG's
and
projects
so
for
upcoming
cycles.
What
are
we
doing?
C
We're
gonna,
keep
working
on
the
hierarchical,
namespace
controller,
we're
working
on
this
tenant
controller
v2,
which
we're
moving
to
use
the
hierarchical
namespace
controller.
The
virtual
cluster
work
is
continuing
and
we
also
have
this
really
cool
Mont,
a
tenancy
benchmarking
project
that
I
encourage
everyone
to
check
out,
read
and
provide
feedback
on,
and
that
is
providing
a
benchmark
for
having
a
secure,
multi,
tenant
cluster
and
there's
that
doc
is
awesome.
C
We
have
also
deprecated
a
previous
prototype
of
a
tendancy
controller,
so
that
is
in
still
the
code
still
up,
but
it's
not
something
we're
actively
working
on
and
then
some
leadership
position
changes
to
announce.
Since
our
last
update,
so
son
Sanji
of
Rampal
from
cisco,
is
a
new
co-chair
of
the
multi-tenancy
working
group
and
david
Oppenheimer
from
google
step
down.
C
How
can
you
get
started?
We
do
have
a
bunch
of
good
first
issue,
bugs
if
you'd
like
to
check
them
out
in
our
repo.
A
lot
of
them
are
HMC
related.
We,
as
I
mentioned,
we
have
been
working
with
the
kubernetes
mentorship
program
throughout
ricci
and
just
yesterday
a
Daniel
bastos
kicked
off
a
bunch
of
work,
so
he
so
the
hierarchical
namespace
controller
now
has
pre
submit
chicks.
So
that's
going
to
make
it
way
easier
for
people
to
continue
getting
started
in
this
work
and
contributing
to
it.
So
thank
you
Daniel.
C
Where
can
you
find
us?
The
chairs
are
me
Tasha,
Drew
and
Sanjay
bramble,
we're
both
on
slack
and
we
have
I,
would
direct
most
people
to
our
multi-tenancy
repo
under
kubernetes
SIG's,
to
check
out
the
code
and
see
how
to
get
started
and
also
under
Doc's.
We
have
links
to
all
of
our
architecture
documents
that
we're
updating
all
the
time.
If
you're
just
wondering
like
what
do,
I
ready
to
get
started,
that's
a
great
place
to
start.
C
C
A
C
Any
time
and
we'll
all
be
at
coop
con
doing
presentations
both
for
new
contributors
and
for
experienced
contributors,
so
we're
doing
an
intro
and
a
deep
dive
for
both
multi-tenancy
working
group
and
for
cig
usability.
So
if
you're
interested
in
either
really
a
deep
dive
into
these
subjects
or
in
I'm,
a
new
contributor
just
tell
me
how
to
get
started
and
tell
me
how
this
thing
works.
We
have
both
tracks
going
for
you.
So
please
stop
on
by.
A
Cool.
Thank
you
all
right.
Let's
move
on
to
announcements,
so
the
first
announcement
is:
please
make
sure
that
you
are
registered
for
the
kubernetes
contributor
summit.
The
contributor
summit
kicks
off
on
Sunday
evening
before
cube
con
and
that's
with
a
celebration,
a
contributor
celebration,
and
it's
going
to
be
a
lot
of
fun.
We'll
have
we'll
have
some
entertainment
and,
of
course,
we're
going
to
have
a
lot
of
people
there.
A
A
So,
if
you
are
a
current
contributor
and
you
still
have
not
registered,
make
sure
you're
registered
very
very
soon
we're
going
to
open
up
spots
on
October
28th
for
general
contributors,
so
the
sauce
might
go
very
very
quickly,
so
make
sure
that
you
register
very
very
soon
and
if
someone
could
put
that
link
into
the
chat,
so
people
can
just
click
it.
That
would
be
awesome.
A
Next
up.
This
is
for
cucumis
wall.
Please
start
populating
your
schedules
on
sched
org
for
both
cube
con
and
cloud
native
con.
This
helps
the
planners
select
the
right
room
size.
So
if
they
see
that
a
specific
session
is
getting
really
really
popular
and
there's
a
lot
of
people
who
want
to
be
in
that
session,
they
might
actually
move
that
session
to
a
larger
room
to
facilitate
and
all
the
people
don't
want
to
be
there
so
make
sure
that
you
use
sched
and
start
populating
your
schedules.
A
A
Another
announcement
is
that
the
format
of
this
meeting
the
community
meeting
is
changing.
We're
gonna
move
to
every
other
week,
starting
in
2020.
So
after
after
the
new
year,
we'll
start
moving
this
to
every
other
week,
but
for
the
rest
of
the
sessions
here
for
2019.
It
remains
unchanged,
we'll
keep
it
as
a
weekly
cadence.
A
A
F
So
we've
this
is
actually
a
discussion
that
we
have
a
github
issue
for
which
I
will,
which
I
will
link
someone
to
I
will
find
the
link
for,
but
the
big
idea
was
interest
and
participation
in
this
meeting
has
been
declining.
So
we
asked
people
why
showing
up
and
they're
like
there's
way
too
many
meetings.
F
So
what
we're
thinking
about
doing
is
maybe
having
four
or
five
six
updates
per
week,
and
you
know
instead
maybe
try
to
trim
down
the
amount
of
meetings
that
we're
having
for
other
people,
because
now
that
we
have
sub
projects,
SIG's
are
now
splitting
into
sub
projects
and
they
have
multiple
multiple
meetings
per
week.
So,
however,
I'm
kind
of
really
open
to
any
any
suggestions,
people
might
have
so
feel
free
to.
Let
me
know.
E
F
G
G
B
G
Perfect,
okay,
yeah,
so
I'm,
Jenny,
Buckley,
I'm
gonna,
tell
you
guys
a
little
bit
about
the
working
group
apply
and
what
we've
done
in
the
last
cycle
and
what?
What
we're
planning
on
doing
in
the
next
work
group
apply
was
formed
about
a
year
ago
to
own
the
problem
of
moving
cube
control,
applied
behavior
to
the
server
and
when
user
working
group
for
that,
because
it
doesn't
fit
exactly
into
any
of
the
existing
SIG's.
It's
closest
to
API
machinery,
but
Cube
control
ply
was
already
owned
by
SIG's
CLI.
G
So
our
original
purpose
for
the
working
group
was
just
moving
applied
to
sever,
but
as
we
did,
we
noticed
some
other
things
that
were
really
related
like
dry
run,
so
we
have
like
a
more
accurate
dry
run
as
well,
which
is
done
on
the
server
and
that's
on
all
API
endpoints.
That's
been
beta,
since
113
and
and
in
the
future.
Our
plans
are
to
work
on
some
improvements
due
to
server
side
apply
like
field
immutability
and
api
unions.
G
These
are
just
sort
of
related
to
queue
control
flag
because
they
rely
on
the
schema
of
the
objects,
but
they're
not
exactly
dependent
upon
it,
and
we're
also
going
to
improve
server.
Side
applies
performance
so
that
we
can
eventually
move
it
to
general
better
to
GA
and
we're
also
working
on
getting
dry
run
into
EGA.
G
So,
basically,
what
yeah
this
segues
working
group
works
closely
with
the
cig,
API
machinery
and
sig
CLI
and
there's
a
lot
of
people
this
affects.
So
if
you
write
a
controller,
then
this
will
make
your
life
easier.
You
can
use
you
don't
have
to
construct
strategic,
merge
patch
or
do
get
update
loops.
You
can
just
send
the
intent
and-
and
it
should
make
the
code
a
lot
smaller.
Also,
there's
some
side
effects
like
we're,
tracking
the
owners
of
single
fields.
G
G
G
Those
aren't
released
yet
for
planning
them
in
the
next
few
releases
and
service
I'd
apply
yeah,
we're
improving
the
performance
so
that
we
can
start
tracking
ownership
on
all
objects
and
the
cluster,
and
our
plan
is
for
that
to
be
in
117
and
with
server
dry
run.
We
want
to
move
this
CJ
as
soon
as
we
can,
but
we
don't
have
any
plans
yet.
The
reason
for
that
is.
If
we
move
this
to
GA,
then
we
can
test
it
can
in
conformance
tests,
and
it
will
be
more
consistent.
G
G
A
A
H
A
A
I
One
thing
later
today,
and
by
later
today,
I
mean
within
the
next
hour.
Sig
Multi
cluster
will
be
releasing
a
survey
on
multi
cluster
use
cases,
we'll
post
this
to
kubernetes,
dev
and
all
of
the
usual
places.
If
you
have
a
use
case
that
involves
running
managing
routing
traffic
to
multiple
kubernetes
clusters,
cig
multi
cluster
would
really
appreciate
it
if
you
filled
it
out
because
they're
looking
to
determine
direction
and
projects
for
the
next
year.