►
From YouTube: Kubernetes WG K8s Infra - 2019-10-02
Description
GMT20191002 153227 k8s infra 640x360
A
I'm
starting
recording
now
and
at
the
beginning,
I
would
like
to
remind
ourselves
to
follow
the
code
of
conduct,
which
we
can
summarize
the
sentence
be
nice
to
each
other,
and
if
there
is
some
topic
you
want
to
discuss
at
today's
meeting,
please
feel
free
to
add
it
to
our
document
and
let
me
actually
open
it.
I.
A
A
C
Yeah,
so
they
give
a
quick
update.
I
have
the
AAA
cluster
up
and
I
brought
it
up,
because
I
didn't
understand
what
was
going
on
with
the
publisher
bot
stuff
I
took
one
that
I
did
understand,
which
was
GCS
web
and
I
brought
it
up.
I
thought
it
would
be
a
fun
time
to
try
using
the
manage
certificates
feature
from
gke.
It
works,
but
after
discussion
on
the
mailing
list,
I
agree
that
we
should
switch
back
to
cert
manager.
So
that's.
C
C
The
the
publisher
bought
configuration
I,
think
Nikita
shared
it
on
the
mailing
list
and
I
took
a
look
at
it.
It
wasn't
exactly
obvious
to
me
which
parts
are
yamo
that
I'm
supposed
to
keep
cuddle
apply
in
which
parts
were
examples,
and
so,
if
you
want
to
take
a
look
at
that
and
start
to
comprehend,
that's
in
the
clear
then
we
could
get
it
turned
up
in
the
new
cluster.
Ok.
E
D
E
Yeah
I
I
mean
I
also
got
the
stuff
on
about
it.
We
don't
really
have
any
concerns
about
moving
it
to
the
kid
start.
Io
repo,
but
I
was
I
mean
the
only
the
only
comment
I
have
is
so
it
has
the
github
token
for
the
kids
publishing
bot
account,
which
has
admin
access
to
all
the
station,
because
at
the
current
state
of
things,
I
think
it's
just
just
like
a
bunch
of
people
pissed
off
them
you.
E
C
D
Right
so
one
thing
here,
Nikita
is
like
Tim
said
we
should
be
like.
One
of
us
should
be
able
to
upload
the
secret
right
and
then
other
people
can
use
it.
Something
like
that
right
and
if
you
can
do
it
up
the
steps.
So
you
know
people
who
have
cluster
admin
can
update
the
cluster
whenever
needed.
But
then,
if
it's
just
messing
with
the
secrets,
then
you
you
know,
the
three
of
us
should
be
able
to
take
care
of
that
part.
D
D
E
C
E
C
A
C
Sure
I
mean
you,
you
have
org
admin
access
now,
so
you
should
be
able
to
access
the
cluster.
You
can
create
your
create
the
namespace
in
the
cluster
and,
if
you
feel
so
inclined
you
can
start
playing
with
the
are
back
and
the
Google
Groups
to
put
that
into
play.
I
haven't
actually
used
that
feature
myself
yet,
but
the
cluster
should
be
enabled
for
that.
F
I
might
be
missing
pair
of
contacts,
but
just
with
the
actual
restriction
of
who
can
do
what
what
like,
which
bear
we.
Why
are
we
trying
to
actually
defend
against
there?
I'm,
just
thinking
like
if
someone's
got
admin
access
to
a
cluster
that
contains
the
secrets
and
they
can
deploy
new
code
into
that
cluster,
then
it's
not
really
a
hard
security,
boundary
and
I
think
we
probably
agree
I
don't
know.
Do
we
will
agree
that
we
don't
need
that
hard
security
boundary,
because
I
think
we
should
probably
note
it
as
such.
F
C
That's
I
think
that's
a
great
point.
I.
What
I
want
to
do
is
vertical
eyes
access
so
that
namespace
by
namespace
we
have
a
group
of
people
who
have
effectively
full
admin
access
to
that
namespace
and
there
will
be
a
small
set
like
dims
who
have
access
to
everything.
But
for
for
most
people,
let's
say
we
hold
the
other
three
volunteers
who
are
gonna,
run
publisher,
Mott
and
take
alerts
for
it.
C
Then
those
three
people
can
probably
access
the
secret
and
everything
else,
but
the
people
who
run
GCS
web
cannot
write
and
I'm
just
using
Bart
as
an
example
here,
because
he
would
probably
actually
be
in
the
group.
But
somebody
who
I
want
to
make
sure
that
somebody
who's
out
of
the
group
can't
access
er,
cool.
E
C
A
C
G
Yeah
sure
so
we
have
been
going
through
a
security
review
at
Google
for
the
promotor
project
and
they
have
made
some
recommendations.
It
is
ongoing,
but
basically
there
had
been
some
points
raised
already
about
how
it
can
make
the
promotor
more
robust.
So
one
of
the
examples
from
the
biggest
one
that
has
come
up
so
far
is
you
know
how
we
have
in
the
promoter
manifest.
G
The
registry
destinations
service
account
key
information,
not
the
credentials
themselves,
but
like
the
name
of
the
service
account
that
and
the
images
that
we
want
to
promote
in
one
single
file.
They
made
a
suggestion
of
separating
those
two
parts
out.
So
basically
the
registries
field
would
be
separated
faded
out
from
the
images
so
that,
for
example,
somebody
cannot
make
a
PR.
You
know
silently
secretly
make
a
PR
that
changes.
You
know
a
little
thing
in
the
service
account
information,
along
with
the
images
that
they
want
to
promote.
G
So
and
of
course,
you
would
lock
the
registries
field
and
for
the
metadata
info
down
in
a
different
folder.
Probably
with
you
know,
more
restrictive
permissions
and
less
people
can
improve,
probably
like
it
would
be,
like.
Maybe
one
or
two
people
who
can
improve.
That's,
that's
my
guess,
because
that
would
probably
never
ever
change.
So
I
made
a
an
issue
tracker
for
that,
but
that
is.
C
The
update
I'd
also
like
to
can
I
extend
on
that
I'd
welcome.
Anybody
who
feels
like
they're
concerned
about
security
should
probably
be
paying
attention
to
this,
because
we're
going
to
realistically
we're
opening
the
door
a
lot
wider
to
a
lot
more
people
to
have
access
to
our
software
supply
chain
and
I
would
encourage
every
organization
who
cares
about
community
security.
In
fact,
we
should
probably
reach
out
to
the
prod
SEC
team
and
just
say:
hey
everybody
do
your
own
audits,
because
now
is
the
time
to
do
it
before
we
go
live
with
it.
G
A
C
I'm
at
the
airport,
so
I'm
gonna
tag.
You
can
you
send
a
separate
note,
Tim
all
clear
and
ask
him
to
get
the
prod
sec
group.
The
kubernetes
project
group
involved,
I,
don't
know
what
exactly
what
their
email
is
and
I
think
their
list
is
closed
but
turns
on
it.
So
he
can
loop
them
in
and
and
basically
say,
but
you
want
to
go
live
with
this
we'd
love
to
do
a
presentation,
all
the
project,
people
across
different
companies
and
we'd
love
them
to
do
an
audit
before
we
do
that.
C
A
C
I,
throw
one
more
point
out:
I
I
had
suggested
at
some
point,
maybe
a
few
weeks
ago,
that
we
should
use
only
GCB
and
no
human
push
access
to
the
staging
repos.
Our
internal
security
audit
strongly
endorsed
that
idea,
but
I
pushed
back
with
the
idea
that
you
know
this
is
a
large
community
with
a
large
diversity
of
people.
I
would
like
to
set
a
goal
of
like
six
to
twelve
months
that
we
push
from
strongly
recommending
people
to
use
GCB
requiring
people
use,
GCB
and
I.
C
H
C
H
We're
giving
you
a
year,
yeah,
I,
think
I
think
a
year
seems
reasonable.
I
I
do
potentially
have
concerns
about
how
difficult
the
process
might
be
for
on
ramping
folks,
because
there's
a
lot
of
things
that
can
go
wrong
in
the
process
as
we've
kind
of
discovered,
but
assuming
that
there
are
other
folks
other
than
yourself
Tim.
That
can
help
with
troubleshooting
those
types
of
issues
and
we
have
decent
documentation
for
on
ramping.
I
think
that's!
That's
pretty
reasonable!.
H
B
What
a
minute
we
should
also
put
an
emphasis
on
making
the
builds
reproducible
I
have
a
concern,
in
my
opinion,
I
have
a
concern
over
how
we're
going
to
approve
PRS
and
like
whether
or
not
they
build
with
GCB.
In
my
mind,
is
less
important
to
the
idea
that
if
we
built
it
with
GC
B,
we
would
get
the
same
result.
Right.
I
feel
like
that
to
me
is,
and
I'd
love
to
see
like
some
approval
flow.
That
was
like
built
with
a
different
thing
like
the
locally
and
come
up
with
the
same
shot.
C
Feel
really
good
if
I
just
knew
that
no
humans
were
allowed
to
push
to
staging
and
that
that
anything
that
was
in
staging
got
there
through
GC
b
and
everything
that
was
run
through
GC
p
was
triggered
through
github
pull
request
that
had
been
merged
so
that
we
have
a
nice
history
of
that
stuff.
I
think
we
can
do
better
even
than
that,
but
I'd
be
really
happy
if
we
could
get
that
far
this
year,.
A
C
Sorry
somebody
needs
to
board
their
plane
as
a
result
of
these
security
audits.
We'll
write
up
some
notes
and
encourage
that
that'd
be
a
directional
guidance,
but
not
a
required
at
the
moment,
and
that's
part
of
why
Katherine
looking
into
the
GCD
github
app,
wouldn't
streamline
this.
We
want
to
make
the
onboarding
of
this
as
easy
as
possible
so
that
people
don't
push
back
when
they
don't
have
to
ok.
A
A
C
D
Boss
coast
is
the
one
that
we
use
in
sick
testing
two
for
so
whenever
a
CI
job
needs
to
run
clusters
in
GCP
right,
then
we
ask
for
a
name
of
a
project,
so
we
do
a
HTTP
POST
and
we
get
back
the
name
of
a
DCP
project
to
use,
and
then
we
do
heartbeats
to
tell
Bosco's
that
okay,
we
are
using
this
project
for
X
amount
of
time
and
then,
when
the
time
expires,
we
stop
the
heartbeat
and
then
we
release
the
project
back
to
boss
pose.
So
it's
like
a
reservation
system.
D
C
C
As
soon
as
we
get
the
production
cluster
up
and
the
let's
set
a
benchmark
for
ourselves,
I'd
like
to
move
all
of
the
things
that
are
in
what
we
call
the
utility
cluster
today,
which
is
really
about
five
things.
It's
like
the
Cates
redirector
and
those
things
once
we
get
those
moved
over
to
Triple
A,
then
I
would
love
to
tackle
the
CI
and
prowl
and
other
problems
and
we'll
figure
out.
Then,
if
what
we
have
is
appropriate
or
do
we
have
to
adapt,
it
sounds
good.
B
Sorry
as
I
understand
it,
Bosco's
lease
is
basically
empty,
GCP
projects
or
MTA
SS
wipers,
and
so
it
sounds
like
what
you
were
more
suggesting.
James
was
not
like
using
terraform
to
create
a
cluster
but
more
just
to
create
empty
projects
and
then
I
think
what
you're
pointing
out
is.
If
we
were
to
do
that,
we
would
move
the
billing
of
some
of
that
into
the
CN
CF
billing.
B
C
I
C
Yeah,
that
would
be
weird
I,
don't
feel
quite
ready
personally
to
start
the
process
of
comprehending
all
of
that,
but
if
then
or
you
or
somebody
wants
to
start
or
has
good
documentation
on
how
we
might
want
to
move
this
all
over,
it's
like
sequencing
wise.
That
would
be
a
good
time
to
get
started
on
it.
D
C
A
A
D
Since
a
few
of
us
are
here,
who
are
you
know,
associated
with
sig
testing-
and
you
know
just
testing
in
general,
I
would
like
to
talk
a
little
bit
about
that.
You
know
Justin
Jason
sandwich
so
the
last
week,
I
spent
time
standing
up
end
to
end
test
from
kind.
So
the
kind
starts
you
know,
cap,
G
and
then
cap
G
starts
a
cluster,
and
then
we
run
the
conformance
test.
So
we
got
that
up
and
running.
D
So
that
seems
to
be
kind
of
stable
right
now,
but
then
the
the
questions
I
had
around
was:
how
do
we
get
all
that
infrastructure?
What
are
the
things
that
I
don't
know?
I,
you
know,
I've
XS
I
ran
some
make
commands
I
ran
some
stuff,
but
I
don't
know
what
they
do.
So
are
they?
What
is
the
infrastructure
behind
that?
That
we
need
to
move
to
CNC
of
infrastructure
that
that
was
basically
the
question
I.
H
H
So
I,
don't
think
we
actually
need
images,
for
you
know
the
the
versions
of
kubernetes
that
we
want
to
test,
but
ideally
the
way
that
we're
running
things
today
is
we're
basically
bootstrapping
cluster
API,
just
to
be
able
to
run
the
conformance
tests
against
a
given
version
of
kubernetes
and
I.
Don't
think
that's
really
the
ideal
situation,
long
term
so
I
think
potentially
having
essentially
a
longer
lived
cluster
API
management
server
that
could
then
be
used
to
spin
up
clusters
are
forgiving.
D
So
there
are
two
things
here
I
want
to
highlight
from
what
Jason
said.
One
is
the
image
that
we
mint
that
so
right
now
in
the
in
the
CI
job,
I
use
the
image
builder
Packer
to
create
the
image
every
single
time,
and
you
know
I
need
to
be
able
to
pull
this
image
from
somewhere
else
from
well-known
location
right.
D
That
would
that
would
be
the
immediate
concern
just
to
avoid
the
overhead
of
creating
the
image
for
every
CI
job
right,
that's
the
first
one,
then
the
other
one
is:
do
we
really
need
to
use
a
kind
and
start
the
initial
bootstrap
cluster,
or
we
can
keep
that
as
a
service
just
like
Bosco's.
So
we
run
one
instance
of
that
which
will
help
us.
You
know,
do
some
amount
of
CI
testing
by
requesting
a
cluster
from
from
from
the
bootstrap
one
I
mean
if
you're
signing.
I
B
D
Know
that
yet
because
the
number
of
variables
I
was
trying
to
enumerate
the
number
of
variables
this
morning
and
it
turned
out
to
be
like
8
of
them,
you
know
in
the
version
of
kind
the
version
of
cube
ABM.
The
version
loves
the
diploid
cluster,
the
version
of
cap
G.
You
know,
you
know
all
those
different
things
so
I,
don't
know
how
many
images
that
we
need.
But
then
is
there
a
way
to
like
move
the
images
to
the
projects
that
we
need
to
start.
You
know
cap
G
on
it
right
so.
H
Ideally,
we
wouldn't
be
baking
images
for
every
single
version
that
we
want
to
test.
Just
because
that's
going
to
be,
you
know
what
its
time
consuming,
but
the
other
thing
is
is
that's
introducing
yet
another
area
variability
where
we
can
introduce
flakes
I.
Think
as
long
as
we
have
the
ability
to
override
the
binaries
that
we're
using
for
tests
I
think
we
should
kind
of
stick
with
a
pre
known
version
that
we
would
have
to
have
some
type
of
process
around
about
updating
it
for
testing
purposes.
I
shouldn't.
I
I
Be
able
to
just
pull
those
so
so,
basically,
all
of
our
literally
today
side
modes,
those
dr.
Mendes
I,
would
just
want
clarify
that
so
interesting
testing
I'd
want
us
to
actually
run
those
images,
as
opposed
to
say,
Cuban
have
been
cluster
used
to
do
a
trick
where
it
would
take
the
binaries
that
belong
in
those
images
and
like
replace
them.
That
is
kind
of
misleading
from
perspective,
but
it
also
doesn't
necessarily
require
that
the
push
we
kind
of
just
post
their
release,
fireball
to
GCS
and
then
the
nodes
pull
down
the
car
balls.
H
I
B
I
D
I
I
D
I
Prg
might
be
a
thing
is:
if
we
move
CI
jobs,
someone
can
go
through
the
entire
of
like
Senate
Pro
you
can.
You
can
actually
move
the
job
over
to
the
other
cluster
too.
So
it's
not
a
pre
submit
unless
you're
gonna
move
a
whole
ego
and-
and
then
you
won't
have
this
issue
where,
when
we
go
to
move
the
state
of
which
projects
are
free,
our
Series
in
the
cluster
running
buildin,
so
you're
gonna
have
a
little
bit
of
a
fun
time
being
aware
of
which
PCP
projects
you're
currently
running
destined.
I
D
D
I
Think
anybody
has
any
special
knowledge.
There
I
mean
they're,
literally
just
UCB
projects
that
happen
to
be,
but
in
the
boscoe's
pool
and
there's
a
browser
discount
that
needs
access
and
I.
If
that's
not
documented,
it's
you
can't
readily
obtained
the
name
of
the
service
account
from
any
reason.
Well,.