►
From YouTube: TGI Kubernetes 140: A tour of Kubernetes 1.20
Description
Come hang out with Jorge Castro and friends as we look at what's new in Kubernetes 1.20
00:00:00 - Welcome to TGIK!
A
Welcome
everybody
it's
friday.
That
means
thank
goodness.
It's
kubernetes
episode,
number
140,
I'm
gonna
be
your
host
today,
george
castro,
my
very
first
tgik
after
helping
run
things
in
the
background
here.
This
is
what
I
look
like.
This
is
my
face
and
join
with
another
person's
first
time
here,
co-hosting
and
hopefully
not
last
wink
wink.
If
you
think
jeremy
is
a
great
presenter
and
has
a
great
knowledge,
maybe
we
can
convince
him
to
come
back.
Jeremy
ricard,
please
introduce
yourself,
hey.
B
I'm
I'm
jeremy,
I
was
the
kubernetes
120
lead,
so
you
may
have
seen
me
sending
emails
about
dates
and
stuff.
This
is
what
I
look
like
I
work
at
vmware.
I
work
on
an
internal
vmware
platform
for
people,
shipping,
sas
services
and
stuff
so
doing
a
lot
of
like
operation,
stuff,
sre
kind
of
work
and
then
building
some
components.
On
top
of
it
for
to
make
it
easier
for
people
to
use.
A
Awesome
awesome
and
if
you're
new,
to
the
show,
welcome,
say
that
you're
new
to
the
show
in
chat.
One
thing
we
do
is
let
us
know
where
you're
listening
in
from,
because
we
do
like
to
say
hello,
jeremy,
where
you
from
where
are
you
listening
in
from
here.
A
Yeah
trivia
for
the
group,
someone
from
michigan
is
named
a
michigander,
that's
a
weird
one.
So
let's
see
who's
around
la
maddie
and
waleed.
I
cannot
tell
you
how
happy
it
is
that
you
are
here
after
years
of
being
together
having
both
of
you
here
with
this
show.
I
really
appreciate
that
joe's
here
from
seattle,
I'm
guessing
marco
chuppy.
I
know
every.
I
know
where
a
lot
of
people
are
from
already
marco
chappies
listening
in
from
dc
eric
welcome,
dallas
fort
worth
sevy
hello.
A
Let's
see
who's
there
ooh,
I
guess,
did
you
do
music
paul
for
the
intro?
That's
fancy
yeah
yeah,
alison
dowdney's,
here
she's
from
london
in
the
uk,
just
moved
there
from
new
zealand,
hello.
Who
else
have
we
got
going
on
here?
Martin
says
good
evening
from
the
netherlands
awesome.
I
knew
someone
was
gonna
point
out.
Your
nine
inch
nail
shirt
jeremy,
I
told
you
it
was
gonna-
be
great
dan
from
the
podcast
is
here.
Welcome
dan.
A
Let's
see
krcare4
from
scottsdale
sema
from
paris
borco
from
ottawa,
canada
juka
did
I
say
that
right,
hi
from
helsinki.
I
hope
I
got
that
one
right,
michael
from
phoenix
robert
from
poland
ashutosh.
I
hope
I
got
that
one
right
from
the
uk
wow.
Oh,
my
goodness,
sebastian
from
kirkland
washington
here
comes
marky
jackson,
marky.
You
just
moved
to
san
diego
right
massimiliano
from
italy,
muhammad
from
paris,
red
panther
from
texas-
oh
my
goodness
wow.
So
many
people
showed
up.
A
I
guess
we're
going
to
have
to
do
a
good
job
today,
jeremy
from
north
dakota
keep
telling
us
where
you're
from
and
we
will
periodically
come
to
the
group
and
make
sure
we
shout
out.
We
are
very
proud
of
the
diverse
set
of
people
and
listeners
that
we
always
get
and
just
really
put
some
excitement
into
it.
I
know
it's
friday.
A
We've
been
working
hard,
we
are
about.
Some
of
us
are
about
to
go
on
holidays
soon,
so
we
we
did
want
to
shake
things
up
here,
a
little
bit
so
one
of
the
things
we
noticed
and
we're
going
to
cover
this
things
like
the
docker
shim.
I
know
we've
already
had
people
asking
questions
and
we
do
have
the
release.
So
jeremy
was
the
release
manager
for
1.20
and
one
of
the
things
I've
noticed
during
this
last
tail
end
of
the
year
when
it
comes
to
technical
content.
A
When
it
comes
to
people
explaining
things
about
kubernetes
right,
you
we
come
on
the
show,
you
see
terminals
and-
and
you
know
we
break
clusters,
and
we
have
you
know
years
worth
of
funny
moments
where
we're
doing
tech
things
and
things
are
working
and
not
working.
One
thing
we
haven't
done
and
because
I'm
a
community
manager
disclaimer,
not
an
engineer.
That's
why
I
brought
jeremy
with
me
is
one
of
the
things
I
would
love
to
help.
A
Socialize
is
not
just
the
technical
aspects
of
kubernetes,
but
how
the
project
works
and
is
organized,
so
those
of
you
that
are
using
kubernetes,
professionally
or
whatever
it's
great
to
know
how
the
cubelet
acts
and
things
like
that
and
all
that
kind
of
good
tech
stuff,
but
it
also
great
to
have
in
your
toolbox
the
processes
that
kubernetes
does
so
that
when
you
have
that
information,
you're
able
to
make
better
technical
decisions,
so
we
thought
about
hey
the
release.
Just
happened,
it
is
shipped.
A
There
are
certain
things
that
we
discovered,
as
I
watched
the
docker
shim
news
spread
over
the
internet,
that
we
could
probably
do
a
better
job
explaining
how
things
work
around
here.
So
what
do
you
all
think
about
that?
Let's
see,
did
we
get
a
thumbs
up
of
that?
Otherwise
we're
spinning
up
a
cluster,
no
we're
not
speaking
today,
so
hey
yousef
from
morocco
awesome
all
right.
So
the
way
the
show
works
if
the
first
time
we
do
the
news
for
a
little
bit.
A
We
kind
of
talk
about
some
things
that
are
happening
around
the
kubernetes
community
and
then
we'll
go
into
our
topic,
which
is
our
favorite
things
in
1.20,
and
then
jeremy
is
going
to
give
us
like
that
insight
into
what
it's
like
to
release
this
thing,
and
hopefully,
by
the
end,
you
will
not
just
know
where
this
stuff
comes
from,
but
my
goal
here
is
for
you
to
learn
how
the
release
manager
does
some
of
the
things,
because,
as
many
of
you
know,
volunteers
make
this
project
happen
and
the
release
team
is
one
of
the
best
places
to
shadow
and
to
dive
into
the
project,
so
we're
gonna.
A
Do
our
best
to
you
know
to
do
that
justice,
so,
let's
get
started
first
of
all,
let's.
A
Font,
that's
crank.
Oh,
am
I
cranking
up
the
font
all
right
how's
that
I
think
that's
better,
all
right!
So,
first
of
all
jeremy,
it
has
been
a
busy
week
last
when
it,
when
two
weeks
ago,
wait
last
tuesday.
So
this
week
we
only
have
a
point
release.
I
don't
have
much
to
say
here
other
than
congratulations,
we'll
get
into
1.20
itself,
but
yeah.
There's
a
1.17.16
point
release.
A
If
you
don't
know
each
of
our
releases
have
a
changelog
directory
and
they
will
tell
you
the
differences
as
well
since
the
last
point
release.
So
you
can
check
those
out
here
and
there
are
links
and
everything
that
you
need.
So
that
is
a
useful
site
there
and
we
will
get
to
an
even
more
useful
site
where
we
can
dig
into
that
big
news
this
week,
jeremy
and
we're
going
to
start
with
you
here
is
all
right.
B
Yeah,
so
I
think
it's
scarier
than
when
it
came
up
in
the
release
notes.
I
think
it's
scarier
than
what
it
actually
is
so
yeah.
You
know
the
word
deprecation
comes
in
and
I
think
people
are
you
know.
Is
that
going
to
immediately
impact
me
and
the
short
answer
is
not
immediately
there's
a
whole
bunch
of
processes
about
how
features
graduate
and
then
how
they
go
away
in
kubernetes
and
it's
you
know
you
can
find
the
documentation
for
all
this,
but
essentially
when
something
becomes
deprecated,
you
have
three
releases
before
it
goes
away.
B
So
in
120,
what's
happening
is
a
piece
of
code
is
being
deprecated
from
the
cubelet
docker.
You
know
was
kind
of
the
original
container
runtime.
It
was
kind
of
really
tightly
integrated
into
the
cubelet.
B
Then
I
think
in
one
five
support
for
container
runtime
interfaces
came
in
and
when
that
happened,
you
know
cuba
was
updated
to
use
these
cri
implementations
using
using
that
api
docker
didn't
implement
one
of
those
things
because
it
predates
cri
right
like
it's
cri
stuff
came
after
docker
was
a
thing
docker
at
the
time,
didn't
go
and
go
back
and
build
a
cri
implementation,
because
container
d
is
really
that
implementation
container
d
came
out
of
docker
became
the
cri
implementation,
so
a
lot
of
people
have
been
using
it
forever,
though.
B
You
know
like
this
yeah,
this
docker
shim
piece,
that's
in
cubelet
and
and
really
what's
happening
here,
is
that
it's
gonna
be
removed
and
it's
gonna
be
removed.
For
a
couple
reasons,
one
cri
is
getting
ready
to
start
moving
through
that
graduation
process
in
120.
It
moves
to
beta
so
that
it
can
start
to
go
to
to
ga
after
that,
but
it
really
means
it's
ready
to
use
and
it's
been
ready
to
use
for
a
while.
The
second
thing
is
that
the
docker
shim
code
bit,
you
know
like
the
path.
B
If
you
look
through
the
the
cubelet
code,
it's
just
an
extra
set
of
things
to
maintain
when
bugs
are
found,
it's
just
extra
stuff
that
has
to
be
maintained.
So
it's
time
for
it
to
go
so
really
what's
happening
here.
Is
that
you're
just
getting
notice
so
starting
in
120
when
the
cubelet
starts
up
you'll
get
a
warning
message,
that's
really
the
extent
of
it,
and
I
think
this
blog
post
is
really
really
good.
I
definitely
recommend
people
go
and
read
it.
B
It
gives
you
all
the
details,
all
what
to
look
out
for
get
you
on
that
journey
to
start
using
container
d
or
cryo
or
you
know,
docker's
marantis
is
going
to
build
a
cri
implementation
around.
A
I
wanted
to
link
to
that
there,
because,
even
if
you
want
to
stick
with
what
you
got,
marantis
definitely
has
a
project
here,
cri-docker
d,
so
jeremy,
I'm
going
to
tell
you
what
I
learned
from
this.
You
know
be
one
of
the
persons
that
had
to
stay
up
really
late
to
get
this
blog
out.
A
So
one
thing
I've
noticed
is,
I
feel,
like
a
lot
of
people
have
conflated
the
word:
docker,
there's
docker,
there's
capital
d
docker
as
in
docker
inc,
there's
the
docker
cli
and
I
think,
when
people
just
look
at
that
part
of
the
stack
they
kind
of
say
all
docker
yeah,
because
I
actually
did
meet
someone
who
was
like
is
docker
on
my
mac
still
going
to
work
right
and
it
was
like
right
and-
and
I
think
it
also
kind
of
shows
how
we
need
to
keep
an
eye
on
what
developers
themselves
see
us
right
in
the
other
way.
A
Right,
like
you,
can't
just
be
like
it's,
not
it's
not
their
fault,
they
don't
you
know
they
don't
know
all
the
intricacies
of
cooperating
like.
We
don't
want
you
to
know
this
stuff
right.
Do
tell
me
this,
though,
when
it
comes
to
what
is
the
difference
between
debra
just
to
be
explicit
here,
deprecation
and
removal
are
two
different
things.
That's
also
something
I
think
we
conflate
what
what
are
the
current
timelines
for
each
one
like?
Is
there
a
rule
like
if
you
announce
something,
is
it?
B
Removal
work,
there's
a
policy
generally
around
rest
api
things
and
another
core
things
that
make
up
the
project
and
when
something
becomes
deprecated,
there
are
three
three
releases
before
it's
removed,
so
there
will
be,
you
know,
probably
in
123,
I
think,
is
when
that's
going
to
happen
so
you'll
have
time
you'll
be
able
to
migrate
over.
I
think
a
really
important
thing
you
know
going
back
to
like
the
conflation
terms
is
you
know
when
people
think
of
like
docker
they're
thinking
of
the
image?
B
Probably
the
thing
that
you're
deploying
is
tools
there's
all
kinds
of
stuff,
but
when
you
think
of
like
I'm,
gonna,
deploy
this
docker
image
or
this
docker
container
to
my
my
cluster,
really
it's
an
oci
image.
Now
that
became
a
spec
as
well,
so
there
are
other
runtimes
that
can
run
those
same
things
and
that's
going
to
continue
to
work.
You're
not
going
to
the
thing
you
have
been
building
will
still
work
going
forward
using
container.
A
B
A
A
A
This
is
like
a
there's
like
a
standard
around
this
and
people
collaborated
stuff
like
there's,
you're,
not
gonna,
wake
up
one
day
and
the
format
changes
like
there's,
actually
a
process
and
a
mailing
list,
and
all
that
all
of
that
kind
of
stuff-
and
I
feel
like
maybe
some
people
weren't
aware
of
this,
and
I
think,
if
anything,
you
know
having
people
be
aware
that
run
time,
spec
and
images
back
and
stuff
are
a
thing.
Probably
you
know
makes
a
lot
of
people
feel
a
little
bit
more
confident
about
it.
A
I
literally
had
a
friend
from
nasa
emailed
me
and
he
was
like
what
are
you
doing?
This
doesn't
affect
me,
but
what
are
you
doing
and
I
was
like
whoa
yeah?
I
should
words
can
be
difficult,
so
that's
good
and
like
we
said,
if
you
still
want
to
roll
with
what
you
got
cri
docker
d,
is
there
maintained
by
the
mirantis
folks
and
less
things
for
us
to
put
in
core?
A
You
know
always
a
good
day
when
we
remove
something
in
core,
so
we
didn't
have
a
tgik
last
week
and
the
reason
was
this
because
kubernetes
had
its
contributor
celebration
if
you've
gone
to
a
kubecon
cloud
native
con
a
few
days
before
the
contributors
get
together,
basically
twice
a
year
is
the
only
time
that
contributors
have
face-to-face
meetings
get
to
know
each
other
have
that
kind
of
stuff.
So
with
kovid
we
weren't
able
to
have
that.
A
So
we
did
a
contributor
celebration
instead,
where
we
just
had
a
bunch
of
fun
and
there's
some
links
that
I
wanted
to
show
some
people
here.
There
was
the
great
cloud
native
bake
off,
which
was
literally
a
virtual
cooking
competition,
paul
czar
who's,
helping
us
stream
here
today
helped
put
this
together
and
the
panel
was
fantastic.
The
cakes
were
fantastic,
a
famous
cook
from
the
travel
channel
came
to
say
hello
and
couldn't
pronounce
kubernetes,
because
that's
just
how
we
roll
so
that's
really
good.
A
We
also
had
two
sessions
of
the
most
excellent
kubernetes
challenge,
which
was
a
party
trivia
game
from
the
folks
from
devopspartygames.com
that
came,
and
that
was
a
good
time
and
we
have
all
that
stuff
on
youtube
and
we
have
our
contributor
awards.
These
are
peer
awards
that
the
kubernetes
sig
co-chairs
and
leads
nominate
folks
for-
and
it's
just
like
an
important
thing
that
we
that
we
take
seriously.
You
know
celebrating
people's
achievements
and
things
like
that.
So
that's
definitely
on
there
and
I'm
one
of
the
presenters.
A
So
I
had
to
wear
a
jacket.
It
was
uncomfortable
and
then
the
last
bit
dan
and
rob
put
together
a
tour
of
ci
and
kubernetes,
which
is
kind
of
an
inside
look
on
how
the
project
runs.
Ci,
it's
all
public,
so
it's
not
inside
on
purpose.
But
it's
like
a
really
great
tour.
If
you've
ever
wondered
about
ci
how
the
project
does
that,
so.
B
That
kind
of
yeah-
sorry
that
was
that
was
awesome.
Just
I
wanted
to
give
my
extra
recommendation.
You
should
go
watch
that
video,
because
it
was
super
useful
if
you've
ever
like,
wondered
why
something's
flaking
or
trying
to
like
dig
through
like
what
is
test
grid.
It's
there's
so
much
really
really
cool
information
inside
of
there.
A
Yeah
yeah,
so
that's
what's
happening
in
core.
We
we
always.
I
do
the
notes
usually
for
the
hosts
on
the
week
and
I
try
to
do
core
stuff
and
then
ecosystem
stuff
to
kind
of
you
know,
keep
them
organized
here.
Let's
look
in
the
chat
who
who've
I
miss.
Oh,
my
goodness,
the
chat
is
hopping
today.
Do
you
do
do
you
think
we'll
do
better
than
one
of
joe's
episodes.
A
A
Xerox,
yeah
exactly
the
photocopy.
Let's
see,
who
else
is
there?
It's
really
interesting
with
the
release
cycle,
change
of
21?
Hey.
So
if
you
have,
we
have
the
release
manager
here.
So
if
you
have
any
questions,
hit
them
up
and
chat,
we
did
three
releases
this
year.
Why?
Let's
get
into
this
one?
Why.
B
Would
three
releases
this
year,
so
I
think
the
the
reason
we
had
three
releases
this
year
was
just
because
2020
was
so
unprecedented.
B
It
was
a
year
right
like
a
lot
of
bad.
Things
happened
to
a
lot
of
people,
a
lot
of
just
uncertainty,
and
it
was
just
it
was
hard,
so
yeah
when
119
was
happening,
we
kind
of
took
the
the
temperature
of
the
community.
It
was.
B
I
got
to
be
a
shadow
for
the
lead
of
that
release.
You
got
to
be
involved
in
a
bunch
of
discussions
and
conversations,
and
there
was
actually
a
lot
of.
I
don't
know
a
lot
of
feelings
from
the
community.
B
B
What
what's
gonna
happen?
Let's
can
we
just
do
a
bug
fix
release?
Can
we
just
not
do
anything
right
now?
Yeah,
I
think
there's
no
great
answer.
I
think,
depending
you
know,
no
matter
what
we
did,
there
were
going
to
be
people
that
agreed
and
disagreed,
but
what
we
ended
up
doing
was
lengthening
the
process
just
to
make
it
to
address
a
couple
things
one.
We
wanted
to
make
the
code
freeze
period
longer,
just
to
make
sure
we
were
delivering
something
that
was
stable
as
people
are
upgrading
and
doing
you
know
version
bumps.
B
It
would
really
suck
during
2020
to
to
add
extra
anxiety
and
stress
by
like
releasing
something
that
was
kind
of
kind
of
hard
to
use.
We
we
explicitly
asked
people
not
to
put
in
any
heartbreaking
changes
like
when
116
happened
and
a
lot
of
apis
went
away.
You
know
that
would
be
difficult,
so
we
explicitly
ask
people
minimize
the
things
that
would
show
up
in
this.
No
really,
you
must
pay
attention
before
you
upgrade
and
then
you
know
like,
as
the
release
was
unfolding.
B
We
also
wanted
to
give
time
for
kubecon
just
to
have
a
break
in
there
for
that.
Just
relieve
pressure
and
stress,
as
we
got
towards
the
end
of
the
release,
we
ended
up
delaying
a
little
bit
more
because
ci
was
not
in
the
great
great
space
so
shout
out
to
dan
and
and
rob
again.
B
We
worked
really
closely
with
sick
testing
and
a
whole
bunch
of
other
groups
to
to
make
the
ci
more
reliable
and
just
give
us
a
better
signal
overall
that
led
to
a
really
long
code,
freeze,
which
I
think
queued
up
a
lot
of
stuff
for
120
120
is
actually
the
biggest
release
that
has
happened
in
a
in
a
long
time.
There
were
45
things
tracked
for
it,
including
three
deprecations
normally
like
117,
was
the
kind
of
corresponding
release
last
year,
and
there
were
only
22
things
in
that
release.
So.
A
B
Kind
of
twice
as
large
there
had
been
conversations
about
whether
four
releases
or
three
releases
for
the
year
was
really
the
right
thing
to
do.
Do
we
need
to
slow
it
down?
Do
we
need
to
speed
it
up
and
I
think
that
that
hasn't
been
decided
yet.
So
the
original
question
was
what's
going
to
happen
in
121,
will
the
cycles
change
and
you're
going
to
see
some
communications
on
that
coming
out
really
soon?
B
There
is
an
open
issue
on
github.
That's
actually
been
converted
to
a
discussion
that
stephen
augustus
opened.
It's
got
a
lot
of
feedback.
There
seems
to
be
a
really
strong
preference
to
three
releases.
There's
a
couple
of
things
like
the
the
support
policy
is
three
releases
right
now,
so
that
kind
of
extends
things
out
to
a
year
just
by
default.
It
takes
the
pressure
off
of
the
release
team.
It's
a
very
you
know,
hectic
thing
to
do
the
release,
there's
so
much
stuff
that
has
to
happen
in
kind
of
a
short
time
frame.
B
So
no
decision
has
been
made
yet
but
you're
going
to
see
some
comms
coming
out
pretty
soon
and
that
will
there
will
be
a
decision
made
probably
in
early
january.
And
how
does
it.
A
You
know
I've
been
on
the
release
team
myself.
How
does
I
envision
especially
as
a
release
like?
Does
it
look
like
a
nasa
room
where
someone's
like
go?
No
go
flight
like
yeah
like
it's,
everyone
has
their
little
headphones
and
it's
just
like.
B
So
this
time
around,
actually
the
friday
before
the
release,
we
were
getting
a
little
sketchy
because
there
were
there
were
some
tests
checked
in
around
a
new
feature
called
api
priority
fairness,
something
new,
but
it's
graduating
to
beta
this
time
around
and
as
as
part
of
their
getting
ready
for
ga
and
the
subsequent
release.
B
They
started
to
add
more
end
to
end
testing
and
it
turned
out
those
tests
weren't
great
tests,
in
the
sense
that
you
couldn't
really
get
the
throughput
you
wanted
so
like
what
apf
does
is
really
allow
you
to
classify
requests
like
go
into
the
ad
like
the
admin,
server
or
admin
request,
go
into
the
api
server
and
you
can
say
like.
I
need
at
least
70
requests
per
second
to
be
handled
for
this
type
of
request,
and
it
just
turned
out
like
in
the
the
ci
infrastructure.
B
It
was
very
flaky
whether
we
could
hit
those
or
not
yeah.
So
we
ended
up
working
with
those
contributors
to
back
that
test
out
for
120
because
it
wasn't
really
necessary,
but
it
was
giving
us
really
bad
signal
and
like
one
of
the
the
go
no-go,
things
is
you're.
Looking
at
ci
signal
have
we
been
green
for
the
last
couple
of
days
and
at
that
point
we
definitely
hadn't.
There
were
other
things
in
the
mix
too.
B
That
kind
of
hid
that
one
it
was
checked
in
like
way
before
committed
way
before
we
found
it,
but
there
were
other
problems
kind
of
leading
up
to
that
week,
but
definitely
it
is
like
a
go
no-go
on
a
zoom
meeting
like
we're
all
in
zoom,
so
the
day
day
of
release.
We
do
that
final
no-go,
but
I
think
we
we
know
generally
a
few
days
beforehand
and
it's
just
kind
of
making
sure
that
things
are
are
good.
A
Yeah
yeah
real,
quick
taco
says
you
all
need
to
add
something
to
the
notes
actually
paul.
If
you
could
post
this
in
tgik
dot,
io,
slash
notes,
we'll
always
send
you
to
the
notes-
and
we
always
commit
these
to
our
github
repo,
which
we
have
a
link
in
here
somewhere
I'll,
make
sure
it's
in
the
in
the
show
notes
so
feel
free
to
come
in
and
help
us
crowdsource
the
notes.
There
are
some
good
things
in
1.20
that
you
just
started
to
talk
about,
and
I
want
to
get
to.
A
But
let's,
let's
bust
out
the
quick
thing
so
jeremy,
you
were
recently
on
google's
kubernetes
podcast
and
we
listened
to
that
and
I
kind
of
wanted
to
make
sure
that
we
were
covering
the
same
things.
So
if
you,
if
you
want
to
listen
to
definitely
way
more
germy
than
me,
definitely
check
that
out,
and
you
also
did
something
called
the
cloud
native
kitchen.
What
is
this
about?.
B
Yeah,
so
there
was
this
free
conference
this
week
it
was
pretty
cool
like
if
you're
looking
for
stuff
to
look
at
over
the
next
you
know
weeks
or
so.
If
you're
taking
break
at
all,
it
was
a
free
conference
and
a
lot
of
people
actually
did
it
from
their
kitchen.
So
I
did
with
ellison.
Do
you
have
a
hat
yeah?
I.
A
Do
it's
upstairs
the.
B
Speaker
gifts
were
an
awesome,
chef
hat
and
an
apron,
but
allison,
and
I
did
like
a
an
iron
chef
style
deployment
contest
where
we
got
before
the
when
the
thing
started.
Jeff
told
us
the
thing
you're
gonna
go
deploy,
so
we
had
20
minutes
to
go
and
and
make
that
it
was
super
fun,
but
there
are
a
whole
bunch
of
great
talks
on
that,
so
they're
all
available
for
free.
B
If
you
want
to
go
back
and
look
at
any
of
them,
I
think
there's
such
good
content
coming
from
like
a
bunch
of
people
in
the
system,
a
lot
of
kubernetes
things
stuff
about
opa
other
other
things
that
are
kind
of
in
space.
A
Yeah
yeah
and
next
we
have
for
you
another
interview
that
the
we
purposely.
I
was
purposely
looking
for
interviews
and
youtube
vids,
because,
if
you're
going
to
the
holidays,
while
you're
taking
some
time
off,
work
and
drinking
eggnog,
you
know
give
you
something
easy
listening
for
the
background
there,
but
sarah
novotny,
you
know
someone
I've
considered
one
of
my
mentors.
A
I
did
an
interview
with
dan
here
on
the
podcast
and
probably
a
nice
succinct
history
of
kubernetes
and
if
you've
never
quite
understood,
why
we're
always
talking
about
community
and
community
and
why
that
is,
you
will
not
find
a
better
person
to
explain
it
to
you.
I've
listened
to
it
three
times
I
even
booked
a
call
with
her
this
morning
to
talk
about
all
the
stuff
she
she
talked
about
because
it
was
really.
A
It
was
really
great
and
that's
something
that
I
hope
everyone
here
gets
a
chance
to
listen
to
she's,
always
a
great
listener,
and
I
guarantee
you
will
learn
something
about
something:
yeah
yeah
yeah
and
I
hear
obvious
celebrated
their
fourth
birthday
party.
So
that's
on
youtube
there.
So
hat
tip
alex
the
next
one
we
got
here.
This
was
interesting
jeremy.
I
did
not
know
that
you
were
all
up
into
spring
and
things
like
that,
but
this
is
an
article
we
found
about
spring
boot
on
kubernetes
with
builtpacks
and
scaffold.
A
Do
you
want
comment
on
this?
One
real,
quick
here,
yeah.
B
I
think
it's
a
cool
just
a
cool
overview
of
making
it
a
little
easier
to
use
some
of
these
tools.
With
java
I
mean
the
spring.
Boot
is
probably
one
of
the
biggest
like
kind
of
frameworks
that
people
use.
We
actually
have
a
whole
bunch
of
tenants
that
are
java
based
and
almost
all
of
them
are
using
spring
boot.
It's
funny
like
I'll
look
through
stack,
traces
and
stuff
and
see
stuff.
So
this
is
it's
walking
you
through
how
like
how
to
use
that?
B
How
do
you
scaffold
with
that
and
the
build
pack
support?
That's
built
into
it,
so
just
making
it
much
easier
to
you
know,
get
your
code
running
in
a
cluster
without
having
to
worry
about
how
the
image
is
going
to
be
built.
Build
bill
packs
are
taking
care
of
that
for
you.
How
scaffold
is
going
to
help
you
with
that?
I'm
going
to
send
this
to
a
couple
people
that
that
we
have
we've
actually
had
people.
B
A
lot
of
our
tenants
right
now
are
using
helm
and
a
lot
of
them
are
looking
at
alternatives,
and
I
think
this
is
a
an
interesting
one
to
look
at
for,
like
it's
just
like
their
inner
dev
sort
of
stuff.
Awesome.
A
And
if
you
have
questions
put
them
in
chat,
if
I
miss
it
ask
again,
this
is
interesting,
so
I
put
this
one
the
cncf
google
has
given
had
a
grant
to
say
it
was
a
nine
million
dollars
over
three
years
for
the
cncf
to
help
with
infrastructure
thanks
google,
but
you
are
knee-deep
in
this
stuff.
Can
you
give
us
an
insight
like
how
many
like
do?
A
We
know
how
many
instances
like
how
big
is
this
like
what
what
happens
when
we're
doing
a
pullbroker
like
how
much
stuff
are
we
building?
I
know
tim
hawking
is
kind
of
like
hinted
at
that.
It
is
a
lot
of
stuff.
It
is.
B
A
B
I
mean
it's
not
just
the
building
stuff
right,
like
google
cloud
has
a
whole
bunch
of
services.
One
of
them
would
be
like
gcr,
where
containers
are
stored
and
all
of
that
stuff
happens
in
google
cloud
right
now.
That's
where
the
infrastructure
has
historically
been-
and
this
is
you
know,
just
keeping
the
lights
running.
There's
a
lot
of
stuff.
That's
still,
moving
over
from
google
hosted
infrastructure
to
to
community
hosted
infrastructure.
Where
tell
me
a.
A
Bit
about
this
sorry
to
interrupt
you,
because
I
hope
you
would
go
to
this-
tell
me
a
little
bit
about
what's
happening
here
with
like
the
infrastructure
as
far
as
who
owns
it,
and
because
the
project
itself
is
going
to
start
to
take
on
this
burden
right,
and
I
want
to
make
sure
to
talk
about
that.
Working
group.
B
Yeah,
I
think
the
the
real
key
differentiation
is
that
when
kubernetes
was
you
know
in
its
infancy
and
evolving,
a
lot
of
the
infrastructure
was
in
google
controlled
accounts.
B
We
do
the
same.
When
I
worked
at
microsoft,
we
did
the
same
kind
of
thing.
There
were
azure
controlled
accounts
that
some
open
source
things
were
in
and
really
what's
happening
here
is
that
the
control
of
those
things
is
being
given
to
not
to
control
those
direct
things,
but
things
are
being
migrated
to
accounts
that
are
controlled
by
the
community,
so
funded
by
the
community.
There's
money
that
comes
into
that,
I
think,
there's
still
work
to
go
there.
B
We
actually
had
a
like
one
of
the
problems
that
led
to
our
ci
signal
kind
of
flub
was
there
was
a
a
project
in
google
that
was
still
hosting
images
and
somebody
deleted
it
because
they
weren't
sure
if
it
was
still
being
used
or
not
and
it
had
to
be
restored
and,
like
that's
another
thing
that
needs
to
be
transferred
to
the
community.
B
A
Yeah
and
joe's
saying
it
seemed
a
good
idea
at
the
time-
and
this
is
just
one
of
those
things
where
we've
been
talking
about
this
migration
and
doing
it
for
so
long
and
there's
a
working
group
that
I
think
you
want
to
mention
yeah.
That's.
B
Group
kate's
infrastructure
great
place
to
go
go
for
that.
I
mean
it's
a
big
big
effort
right
like
there.
A
B
Many
things
involved
when
you
think
about
the
the
scope
of
what
needs
to
be
tested
for
kubernetes.
When
you
submit
a
pull
request,
there's
tons
of
jobs,
it
tests
all
kinds
of
features
yeah,
all
you
know
it's
very
complicated
and
definitely
could
use
more
eyes
and
more
help.
Yeah.
I
think
it's
an
underserved
area.
You
know
it's
not
super
flashy
right,
like
people,
don't
think.
Oh,
let's
make
ci
better
yeah.
A
Yeah,
this
is
a
quick
one.
I
found
this.
I
run
into
cube
cuddle
cheat
sheets
all
over
the
web
all
the
time.
This
is
the
sheet
cheat
and
this
one
is
so
thorough.
I
can't
even
I
can't
even
I
can't
even
begin
to
talk
about
it,
but
I
thought
this
would
just
be
a
cool
link
here
in
the
notes
shout
out
to
eon01
whoever
you
are.
That
is
definitely
a
very
thorough
one,
and
I
always
dig
that
this
one
is
cool.
A
The
cncf
actually
has
a
transparency
report
now
about
the
kubecon
cloud
nativecon,
so
you
can
come
in
here
and
see
how
many
people
registered
attendance
rate,
and
I
just
thought
that
was
really
interesting.
I
think
it's
really
cool
that
the
cncf
is
kind
of
you
know,
opening
up
the
the
books
there
to
kind
of
show
us
these
events,
because
I
know
it
could
be
frustrating
to
attend
a
virtual
event
and
wondering
is
anyone
even
watching
and
apparently
with
22
000
registrants.
A
Someone
is
definitely
watching,
so
this
is
really
good
right,
like
it's.
It's
good
to
see
like
it's
almost
split
gender,
wise.
We
we
always
try
to
I've,
helped,
select
talks
at
qcon
and
we're
always
looking
for
new
speakers
and
things
like
that,
and
I
think
it's
just
really
great
that
the
cncf
is
making
this
information
available
so
that
we
can
all
get
better
at
it.
So
I
think
that
is,
and
then
lastly,
we
have
a
link
here
from
someone
in
chat.
A
What
is
this
k0s?
The
kubernetes
distribution?
I'm
always
curious,
like
who's
trying
to
do
the
most
clever
one,
because
you
got
like
micro,
cades,
k3s,
k0s,
so
look,
look
container
d
out
of
the
box
see
already
solving
problems
for
you,
so
yeah
awesome
thanks
for
that.
I
I
haven't
played
with
this
myself.
I
don't
know
anything
about
it,
so
I
can
neither
endorse
nor
criticize,
but
definitely
something
to
check
out
thanks
to
whoever
dropped
that
in
the
notes.
A
Okay,
now
on
to
the
meat,
1.20
jeremy,
what
are
you
into?
The
first
thing
you
talk
about
is
non-inclusive
language
and
cube
admin
yeah.
B
I
think
there's
tons
and
tons
of
stuff
to
talk
about
in
the
project,
but
I
really
think
this
is
a
great
one.
There's
a
whole
lot
of
work
happening
in
the
community
to
address
non-inclusive
language.
There's
a
whole
initiative.
That's
been
formed
around
it.
B
This
one,
I
think,
is
just
cool
to
see,
come
in
120
and
really
what's
happening
here
is
a
new
label
and
a
taint
were
added
to
cube
admin
for
the
things
that
are
going
to
be
control,
point
notes
so
right
now
there
is
a
master
node
label
and
tanked
there's
a
new
one
called
control
plane,
which
makes
you
know,
makes
it
more
clear
what
it
is
and
it's
much
more
inclusive
language.
B
So
you
know
the
things
that
are
there
will
continue
to
exist
for
a
little
while,
there's
a
in
the
cap
or
in
the
issue
it
kind
of
walks
through
what
phases
are
going
to
happen
there.
But
I
think
this
is
just
a
great
feat,
a
great
thing
to
come
in.
B
A
And
I've
always
felt
control.
Plane
is
a
better
description
anyway.
You
know
be
more
explicit.
Be
more
is
also
really
great.
Also
shout
out
to
the
kubernetes
github
administration
team
yeah.
We
have
one
who's
been
working
diligently
with
github
on
maine
and
master
in
github
itself,
because
that
that's
definitely
a
lot
of
work
and
and
to
make
sure
that
it
doesn't
disrupt
things.
So
big
shout
out
to
that.
That
is
working
group
naming
quick,
george
pro
tip.
If
you
go
to
google
and
you
type
kubernetes,
oh
goodness,
sigs.yaml.
A
If
you,
if
you
actually
go
to
the
rendered
page
here,
and
we're
going
to
talk
a
little
bit
about
the
about
the
contributor
site
in
a
second,
oh,
no,
that
was
a
spoiler
okay.
People
are
asking
chat,
what's
happening
with
psps.
B
Yeah,
that's
a
great
question.
One
of
the
things
that
I
called
out
down
here
is
that
perma
beta
is
kind
of
going
away.
There
are
a
whole
lot
of
things
that
have
been
in
beta
forever.
Right,
psp
is
one
of
those
ingress
was
one
of
those
things
as
well,
but
ingress
has
gone,
has
gone
ga
now
so
what's
happening
with
psp's.
I
think
it's
it's
open
to
debate.
B
What's
going
to
happen,
cig
security
has
taken
up
the
mantle,
so
tabby
and
ian
are
definitely
looking
at
what
what
can
be
done
to
push
that
along.
They
will
be
working
on.
You
know,
with
the
goth
to
to
kind
of
figure
out
what
that
looks
like
what
a
replacement
or
an
evolution
looks
like
the
question
really
comes
down
to,
what's
going
to
happen,
to
features
that
are
beta
now
yeah
in
119
there
was
a
policy
change,
a
kept
that
came
in
this
one's
important.
Everyone
pay
attention.
B
It
really
says
that
things
have
to
progress
within
three
releases.
If
they
don't
progress
within
three
releases,
so
say
you
have
like
v,
one
beta
one.
It
needs
to
either
go
to
like
v,
one
beta,
two
or
v.
You
know
whatever
some
some
new
beta
version
and
then
you
have
to
deprecate
the
old
one
or
it
needs
to
graduate
to
stable
ga
or
it
needs
to
be
deprecated,
and
then
the
deprecation
train
kind
of
runs
for
that
automatically.
B
The
timer
starts
right.
The
timer
starts
yeah,
okay,
it's
pretty
cool
too,
because
as
new
features
are
coming
in,
they
have
to
have
these
feature,
these
flags
basically
added
into
the
code
so
that
it
becomes
automated.
You
can
start
to
report
on
some
of
these
things
too,
another
one
that
came
in
with
119.,
so
those
things
take
effect
in
120,
so
starting
in
120.
B
Not
single
digits
yeah,
I
mean
along
those
lines.
Cronjob
has
been
beta
since
one
five,
you
know
that's
it's
it's
a
nuts
time
frame
for
those
things
to
be
around,
so
those
things
are
going
to
go
either
to
stable
or
to
to
go
away
and
yeah
psps
falls
into
that
bucket.
Psp
has
been
beta
for
a
long
time
and
nothing
has
really
pushed
it
along
another
fun
like
another,
one
that
we
use
all
the
time.
So
we
use
psps
on
my
team
and
something
called
pod
disruption.
B
A
The
code
and
we
call
it
that
someone
write
down
death
clock
that
is
we're
going
to
make
that
an
official
term
the
reason
the
reason
I've
been
kind
of
like
poking
at
you
to
say
these
things
is,
for
the
first
time
ever.
Deprecations
removals
and
getting
stuff
from
alpha
beta
to
ga
are
all
on
a
clock.
Now
right,
there
is
no
thing
that
lingers
anymore
is
that
is
that
an
accurate
statement.
A
B
Can
stay
in
alpha
and
you
can
do
versions
of
them,
and
I
mean
really
that's
what
should
happen
right
like
things
that
are
there.
The
important
thing
with
beta
is
that
they're
on
by
default,
so
people
start
to
depend
on
them
the
alpha
things
they're
not
on
by
default
right,
so
you
could
put
them
in
make
changes
like
dual
stack.
Ipv4
ipv6
support
is
alpha.
It
was
delivered
in
117,
maybe
okay,
a
new
version
of
it
has
come
in
120.,
they've,
rewritten,
a
whole
bunch
of
it,
and
it's
still
alpha.
B
You
know
to
use
it.
You
have
to
turn
it
on
the
beta
things
are
on
by
default,
so
you
are
you're
going
to
get
them
and
when
there's
a
change
to
it,
there's
a
change
to
it
and
people
really
do
depend
on
them.
We
just
upgraded
all
of
our
clusters,
my
day,
job
to
116..
B
A
So
question
for
you
just
for
a
philosophical
point:
why
is
our
beta
opt
out
instead
of
opt-in
for
features?
I'm
sure
someone
made
that
decision
at
some
point.
I
think
it's
to.
B
Start
getting
feedback,
you
know
like
right.
You
want
to
really
ensure
that
these
things
are
being
used
and
exercised
when
they're
turned
on
by
default.
They
also
go
through
all
the
testing
flows.
Things
are
alpha
like
they're
excluded.
I
think
that
just
having
them
on
by
default,
just
gets
them
on
that
path.
To
especially
with
this
new
policy,
gets
them
on
the
path
to
getting
that
thing
stable
and
making
a
little.
A
A
B
Gotta
tell
me
this
one:
this
is
a
great
one,
turns
out
that
if
you
have
exec
probes
and
you'd
specified
a
timeout,
it
wasn't
honored.
If
you
didn't
specify
a
timer,
it
wasn't
honored,
it
would
just
run
until
completion,
so
the
default
is
one
second
in
120
this
was
fixed.
B
So
it's
really
like
a
bug
fix,
but
it's
a
pretty
impactful
bug
fix
right,
so
it's
actually
put
behind
a
feature
gate
it's
on
by
default.
But
if
you
have
problems
like
you've
defined
an
exec
probe
in
no
time
out,
it's
gonna
take
one.
Second,
we
actually
had
some
folks
from
microsoft
pop
in
that
work
on
the
aks
engine,
and
we
had
a
lot
of
discussion
about
whether
this
was
the
right
way
to
go
or
not.
B
Signaled,
you
know
ends
up
having
the
call
and
they
they
pushed
this
one
forward.
But
like
the
cast
team
early
kiss
engine
team
had
some
tests
that
used
exec
probes
didn't
specify
a
timeout,
so
suddenly
they
upgraded
to
120
and
oops
longer
than
one
second.
So
this
is
just
a
good
one.
B
To
be
aware
of,
I
think
one
of
the
themes
I
saw
as
the
release
was
happening
is
that
a
lot
of
things
are
going
to
stable,
there's
a
lot
of
focus,
put
into
fixing
things
of
the
past
and
just
making
the
project
better
overall,
and
then
this
is.
This
is
an
important
one
right
like
you,
when
you're
running
in
these
exec
probes,
it
probably
makes
sense
to
have
a
reasonable
timeout
on
these
things,
so
that
you
know
you
have
an
assurance
that
the
probe
is
actually
working
and
not
just
hanging
out
forever.
So.
A
B
The
release
team
doesn't
really
have
that
that
kind
of
power
we're
okay,
we're
enabling
everybody
to
deliver
these
things,
and
it
really
comes
down
to
the
sigs
that
are
responsible
for
this
code.
So
in
this
case
this
is
a
sig
node
thing
and
signate
had
a
lot
of
discussions
about
it.
When
you
click
through
this
issue,
you
can
find
the
pull
requests
and
there's
lots
of
discussion
that
happen
on
a
lot
of
these
things.
B
They
give
you
a
lot
of
context,
I
think,
even
with
the
with
the
docker
shim
one
on
the
the
cap,
so
these
things
all
come
from
caps
right
correctly,
we'll
get
the
caps
there's
so
much
discussion
that
goes
on
these
things
that
you
can
get
a
lot
of
great
information,
a
lot
of
context,
if
you
know
where
to
find
them
and-
and
there
was
a
lot
of
great
discussion
back
and
forth
on
this
one-
I
think
in
the
end
like
it
is
impactful
because
it's
broke
it's
it's
fixing
something
that
people
probably
came
to
depend
on
or
just
didn't
know
they
were
depending
on
which
is
cool.
B
The
feature
flag
is
there,
you
can
set
it
to
get
the
old
behavior
back,
which
will
go
away
eventually
too,
to
kind
of
get
you
on
the
path,
but
just
just
a
good
one
to
be
aware
of.
I
think
I
think
go
ahead.
A
Oh,
I
was
gonna
say
a
question
from
the
audience.
If
you're
ready,
yeah
yeah
waleed
has
how
do
you
know
which
sig
it
will
be
for
a
specific
resource
feature.
B
Yeah,
that's
a
question
that
you
can
answer
a
couple
of
ways:
one
you
can
kind
of
think
of
the
functionality.
So
if
it's
something
that
relates
to
the
cubelet
behavior,
that's
going
to
be
signode
if
it's
something
that
relates
to
like
the
cron
job,
for
instance,
that
would
fall
under
apps.
But
really
the
way
to
do
it
is
to
look
at
the
caps.
They're
gonna
be
like
the
source
of
truth
and
everything,
and
they
have
an
owning
cap.
B
So
like
every
feature
or
enhancement
that
comes
into
the
project
is
gonna
land
with
with
some
owning
sake,
and
I
think,
like
for
psps,
maybe
you're
asking
that
as
a
follow-up
question,
that's
owned
by
sigoth
right
now,
security,
I
think,
is
newer,
but
the
original
psp
implementation
was
owned
by
sigoff.
So
you
can
find
all
this
like
when
you
look
at
any
given
enhancement.
It's
like
in
this
directory,
the
keps
director
in
this
repo,
the
caps
directory,
is
where
you'll
find
all
the
things
that
are
merged
there
we
go
here.
We
go.
B
You
can
pick
any
one
of
the
sigs
they're
all
organized
by
sig.
Some
of
it
does
predate
as
joe
mentioned.
It's
pretty.
Yeah
caps
are
a
newer
thing,
yeah
most
everything
that
was
like
a
design
proposal
before
that's
continuing
to
evolve
like
it
wasn't
ready
to
go
ga
or
beta
we're
actually
requiring
all
of
those
things
to
be
updated
into
caps.
So
there's
older
things
that
are
migrating
into
that
new
format,
but
they
definitely
are
things
that
are
alright
outside
of
that
scope,
so
yeah
yeah,
you
can
find
here
we
go.
B
Here's
the
docker
shim
one,
so
there's
two
pieces
in
here.
There's
like
the
readme
file,
the
smart
down.
You
can
find
a
ton
of
stuff
in
it
and
then
you
can
find
a
kept.yaml
file
because,
like
everybody,
loves
yaml
yeah-
and
this
has
metadata
and
it'll
show
you
like
who
the
authors
are
who's
responsible
for
doing
the
reviews
and
then
also
like
the
owning
sig
and
the
participating
six.
B
So
you
can
find
like
tons
and
tons
of
great
information
in
these
things,
spoiler
for,
like
a
few
minutes
later,
we're
working
on
making
a
lot
of
a
lot
of
this
stuff,
more
transparent
and
easy
to
find.
A
Yeah
joe's
finally
gonna
get
his
kept
website,
so
so
there's
a
reason
I
want
to.
I
wanted
to
talk
about
this
specifically
because,
as
I
was
reading
the
docker
shim
news,
you
read
on
the
internet,
people
saying
comments:
why
did
they
do
it
this
way?
Why
did
they
do
this?
And
if
you
actually
drill
down,
there
is
a
kept
for
it,
and
if
you
find
the
issue
in
the
thing
you
could
read
it
and
you
can
actually
see
the
maintainers
talking
about
all
the
things
that
people
were
talking
about.
A
So
one
of
the
reasons
I
wanted
to
bring
this
up
is
this
repo-
and
I
know
some
of
you
out
there
have
kubernetes
or
devops
or
something
in
your
job
title,
and
I
cannot
tell
you
how
much
time
you
can
save
by
learning
just
this
repo
and
how
to
keep
track
in
here
now
we
don't
want
to
send
people
to
raw
github
repo.
So
one
of
the
things
that
you
know
we've
been
working
in
for
a
long
time,
and
this
is
way
too
complicated
is
this
should
be
a
website.
A
You
should
be
able
to
go
to
caps,
kubernetes
dot,
io
search,
see
which
one's
open
click
a
little
sig
label.
You
know
which
ones
which
ones
are
assigned
to
me,
which
one
are
signs
today.
You
know
where's
the
discussion
at
cross
linking
to
the
github
issues,
definitely
hear
you
on
that,
and
there
are
people
who
are
working
on
on
doing
that.
Do
you
give
us
any
insight
on
that?
A
little
bit.
B
Yeah,
so
there's
actually
an
open
issue
to
create
a
caps
website
extracting
some
of
this
metadata
out
and
building
it
into
an
easy
to
use
sort
of
site,
I
dropped
a
link
to
that
in
the
in
the
notes.
B
Awesome,
I
think,
there's
there's
like
two
paths
really,
if
you're
just
interested
in
like
a
summary
of
information,
that
will
definitely
be
the
place
to
go,
especially
as
we
start
to
mature
the
process,
around
collection
of
caps,
which
is
another
one
that
I
linked
if
you're
interested
in
collaborating
on
any
of
these
things,
though,
like
the
github
repo,
is
totally
the
way
to
go,
you
can
find
like
when
pull
requests
are
open
to
move
one
into
from
provisional
to
implementable,
different
states.
Yeah,
let's
see
what
you
got,
122
are.
B
Open
and
and
when
you
come
in
here,
you
can
do
like
a
code
review
for
this
feature
right
like
in
the
cap.
It's
going
to
define
all
kinds
of
stuff
like
known
issues
or
risks.
Mitigations
yep
defined
test
plans
use
cases
all
kinds
of
crazy
stuff,
and
this
is
really
your
opportunity
to
come
and
be
involved
in
discussing
some
of
these
things
and
giving
your
input,
like
my
team's
super
interested
in
whatever
the
next
psp
thing
is
going
to
be
because
we're
going
to
be
using
whatever
it
is.
B
A
Yes,
to
use
some
of
these
things,
yeah
and
that's
part
of
the
reason
I
wanted
to
bring
this
up
and
spend
some
time
on
it,
because
there
have
been
certain
issues.
I
know
certain
things
where
I've
heard
developers
say:
oh
if
I
only
got
some
real
feedback
on
this
from
like
someone
who's
using
it
in
anger,
so
caps,
capsule
2021,
is
going
to
be
what
we're
rallying
around
and
steven
augustus.
If
he's
listening,
he
says
going
to
try
to
drop
by
today.
A
That's
definitely
one
of
his
jams
for
the
year,
I'm
going
to
add
another
one
that
I
like
to
use:
relnots
rell
notes.kates.io.
If
you've
heard
of
this,
tell
us
in
chat.
If
you
haven't
heard
of
us,
I
want
to
know,
I
don't
know
how
good
we
are
about
sharing
our
obtuse
urls,
because
that's
what
we
do,
I'm
actually
working
on
kate's
dot,
io
logo,
so
that
like,
if
you
ever
wonder
if
you
ever
need
the
shade
of
blue
or
the
logo,
it
takes
you
to
like
the
little
marketing
page.
A
But
so
I
think
this
one
for
a
few
reasons.
So,
first
of
all,
this
is
one
of
those
places
where
you
don't
need
to
be
distributed.
Systems
engineer
it's
just
a
web
front
end.
So
if
you
don't,
you
know
if
you're
looking
for
stuff
to
do-
and
this
is
like
what
you
do
you
don't
you
don't
have
to
be
scared
about.
You
know
digging
into
something
stuff,
so
we
always
kind
of
need.
People
with
all
sorts
of
skills
front
ends
documentation.
A
What
not,
but
what
I
like
about
this
is
that
you
can
break
it
down
by
component.
So
you
can
say
you
know
what
let
me
look
at
cloud
provider
today.
Okay,
here
they
are
and
then
you
can
look
at
at
the
notes.
So
as
you
I
know
it
looks
kind
of
crazy
kind
of
jank
right
now,
but
as
you
start
to
drill
down
into
each
of
these
labels,
it
kind
of
really
gives
you
a
good
view
of
what's
happening.
A
So
I
use
this
actually
in
conjunction
with
the
github
release,
notes
that
link
to
them
and
then,
if
I
have
questions
I
can
come
in
and
you
can
drill
one
on
each
individually
and
it'll.
Take
you
to
that
pull
request
where
you
can
sit
there
and
you've
got
the
entire
history
right
there.
So
that
is
definitely
awesome.
A
I
I
have
a
joke
that
I
tell
people
is
like
if
you
have,
if
the
word
architect
is
in
your
title,
that
enhancements
repo-
and
this
thing
your
jam,
it
should
be
on
your
list,
so
anyone
else
got
anybody
any
tips
on
this
one.
Oh
it's
a
I'm
glad.
It's
I'm
glad
and
sad
that
it's
the
first
time
some
of
you
have
seen
this.
So
that's
good
to
go,
but
yeah
jeff
was
working
on
this
for
a
while.
I
don't
know
who's
on
working
on
it
now,
but
you
can
definitely.
A
You
can
definitely
like
browse
around
here.
There's
all
sorts
of
goodies.
I
see
a
cup
section,
do
you
you?
Don't
you
don't
think
it's
well
show
me
the
caps
that
might
be
okay,
all
right.
Oh
there's
a
caps
label.
Oh
okay,
all
right!
Some
work,
some
works.
Some
work
left
to
do,
but
this
one's
just
a
malformed
colon.
I
think
right-
am
I
right
yeah
yeah
yeah.
A
So
this
is
why
you
see
some
of
this
metadata
on
top
of
caps,
because
we
need
that
stuff.
So
we
can,
you
know
joe
famously
said:
hey,
I'm
gonna
shove,
these
through
hugo
and
I'll
be
done
in
a
weekend,
and
that
was
three
years
ago.
Yeah.
B
We're
working
through
a
lot
of
that
right
now
with
sick
docs
another,
and
you
know
it
takes
a
a
lot
of
people
to
make
these
yeah
show
up
and
be
awesome.
A
B
This,
I
think,
there's
two
cool
alpha
features
that
are
coming
in
120
or
came
in
120
around
metrics,
so
this
one
is
really
about
exposing
a
new
metrics
endpoint
on
the
scheduler,
so
you
can
hit
that
with
prometheus
or
something
else
and
it'll
give
you
a
time
series.
It
will
show
you
the
request
limits
for
all
the
stuff
running
in
your
cluster.
Give
you
a
better
idea.
You
know
selfishly.
B
I
want
this
because
I'm
a
cluster
operator
gives
you
the
you
know
like
a
better
kind
of
holistic
view
of
the
cluster,
to
do
things
like,
let's
figure
out
capacity
planning
or
how
are
we
doing
with
like
actual
utilization,
so
this
one's
pretty
cool.
I
think
it's
an
awful
feature
again,
so
you
have
to
turn
it
on
with
the
feature
flag,
yep
and
there's
a
second
one.
B
If
you've
used
the
horizontal
pod,
auto
scaler
before
you
know,
you
can
get
like
pod
metrics
like
cpu
utilization
and
scale
based
off
of
that,
but
it's
for
the
whole
pod,
which
can
can
actually
be
a
little
misleading
right
like
if
you've
got
one
one
container
in
there.
That's
causing
all
of
the
problems.
B
You
might
lose
that
because
it
might
fall
into
an
overall
tolerance
for
the
pod.
So
another
alpha
feature:
that's
coming
in
120
is
the
ability
to
do
that
just
on
the
container
within
the
pod.
So
you
can
say,
like
I
really
really
care
about
this
java
application
that
that
maybe
has
a
bad
memory
leak.
Let's
drive
the
hpa
off
of
that
instead
of
the
whole
pod.
So
I
think,
like
those
two
things
together
are
pretty
cool.
B
A
I
I
one
of
the
things
I
like
about
the
the
kept
structure.
Is
they
tell
you
goals,
non-goals
proposal
like
I
feel
like
if
you're
an
operator
like
you,
could
totally
explain
this
to
your
boss
in
in
a
way
that
can
you
know
hey?
What's
the
tl
dr
on
this
right,
they
got
the
user
stories
here,
risk
of
mitigation
design
details-
and
this
is
just
now,
if
you're,
seeing
this
for
the
first
time.
A
B
Yeah,
so
this
was
in
119,
and
this
is
just
it's
a
blog
post
and
then
I
think
we
also
linked
to
the
actual
kept
that,
like
everything
that
comes
in
is
a
cap
even
policy
things,
and
this
is
a
blog
post,
really
giving
you
more
details
about
that
required
transition
from
beta.
This.
A
B
Of
the
things,
so
the
first
thing
in
there
is
that
tags,
including
when
an
api
was
introduced,
are
now
required.
So
that's
the
ability
to
do
a
lot
of
automation
around
this
stuff,
one
that
kind
of
goes
hand
in
hand
with
this.
Is
jordan,
liggett
added
a
feature
or
an
enhancement
in
in
119
as
well?
That
will
tell
you,
when
you're
using
deprecated
api,
so
this
can
kind
of
go
hand
in
hand,
giving
you
a
really
good
view
about.
What's
happening,
helping
you
prepare
for
some
of
these
things.
B
So,
like
the
the
116,
you
know
like
we
had
a
big
blog
post
about.
Oh
no
there's
a
lot
of
things
going
away
helpful
warnings
ahead,
yeah.
This
is
a
great
one.
So
now
you'll
actually
get
back
a
header
telling
you
like,
when
you
do
a
api
call,
you'll
get
back
a
header
that
tells
you,
if
you're,
using
that
it
also
generates
metrics
that
you
can
scrape,
which
is
super
cool
for
cluster
operators
when
you're
using
ctl
it's
exposed.
As
like
a
warning
message.
B
Our
migration
was
a
ton
of
people,
didn't
know
they
were
using
these
deprecated
things
and
there
wasn't
a
great
way
to
report
them
back
and
then,
when
you're
trying
to
scan
like
as
a
cluster
operator,
it's
hard
to
know
like
because
things
get
converted
to
preferred
versions,
things
maybe
get
stored
in
helm
releases
and
you
don't
really
know
like
what
they
actually
sent.
B
B
There
was
some
discussion
about
whether
crown
job
should
go
or
should
not
go
should
go,
should
not
go
and
the
same
thing
in
119.
Should
it
go,
should
it
not
go,
there's
a
lot
of
things
that
have
to
happen.
I
think
to
make
that
one
go
to
ga
and
I
think
stepping
stone
for
that
is
in
120
a
new
crown.
Job
controller
was
added.
It.
B
Feature
you've
got
to
turn
it
on
with
yes
with
a
with
a
feature
flag,
but
it's
going
to
start
that
process
of
getting
you
to
the
point
where,
like
crown,
job
will
eventually
go.
B
Ga,
and
I
think
all
of
these
things
are
just
building
on
top
of
the
maturity,
the
product
of
the
project
and
and
pushing
us
in
the
direction
of
of
getting
away
from
these
things
that
may
or
may
not
go
away
and
give
people
real
assurances
that
this
thing
that
I'm,
depending
on
this
crime
job
or
this
deployment
yeah
be
around
because
it
will
be
a
stable
thing.
Eventually.
A
Yeah
yeah
and
now
that
we're
actually
going
through
the
cap.
This
is
nice.
Here's
what's
coming
in
120,
121,
122!
Here's
the
plan,
nice
yeah.
B
I
really
like
that
one.
The
cups
are
great
like
if
you
go
through
and
you
have
any
questions
about
stuff.
They
they're
the
place
to
go
if
you're
gonna
make
a
a
proposal
for
a
new
enhancement
like
there's
a
lot
of
stuff
to
write
down,
but
it's
good
that
there's
a
lot
of
stuff
to
write
down,
because
it's
really
forcing
you
to
go
through
this
great
design
process
and
think
through
all
of
the
the
gotchas,
and
you
know
just
build
a
more
mature
thing.
Yeah.
A
A
They
have
that
without
having
to
be
an
archaeologist
right,
they
have
that
that
context
and
they
could
spin
up
quicker
right
and
then,
of
course,
you'll
be
thanking
your
future
self
in
a
year
when
you're
wondering
why,
while
the
cron
job
is
acting
slightly
different
from
what
it
did
before
or
whatever
it
is,
yeah
good
to
know
all
right,
so
we
got
a
few
other
ones
here
and
then
I'm
kind
of,
except
for
time
here
it's
fixed
yeah.
B
B
Yeah,
so
when
you're,
when
you're
thinking
about
like
I
want
to
know
dates
about
the
release
or
a
link
to
the
enhancement,
tracking
spreadsheet
or
any
of
the
other
stuff
who's
on
the
release
team,
you
used
to
have
to
go
to
the
sig
release
repo,
so
there's
tons
and
tons
of
github
repos
right
now
on
the
case
contributor
website,
which
is
a
super
dope
place
to
go
for
all
kinds
of
stuff.
B
If
you
go
to
slash
release,
it
will
tell
you
all
the
information
about
the
latest
release
and
it's
pulling
it
from
github,
so
we
make
changes
to
the
yeah,
the
timelines,
all
that
stuff
will
be
reflected
in
this
page.
So
you
can
go
to
this
and
you
can
say
when's.
The
release
going
to
be
151
will
be
starting
soon.
So
when
that
that
kicks
off,
probably
the
second
week
of
january,
this
will
be
updated
with
all
the
information
about
the
121
release,
the
dates
you'll
be
able
to
see.
B
When
do
I
need
to
have
my
code
in
by?
When
can
I
expect
this
release
to
happen
and
instead
of
having
to
look
about,
you
know,
go
dig
through
github
repos
again,
like
there's,
just
more
information
being
surfaced
and
way
easier
to
consume
ways,
but
this
is
also
showing
you
things
like.
When
are
the
release
meetings,
if
you
want
to
come
and
listen
to
them,
because
they're
all
public
check
this
out,
yeah.
A
The
tlpr
schedule,
so
I
use
I
use
this
a
lot
right
because,
where
it's
like,
oh
what
day,
are
we
on
or
whatever
kate's
dot,
dev
slash,
release
myself
and
others?
We've
been
trying
to
make
rememberable
urls
that
you
can
put
on
a
t-shirt,
and
you
know
this
is
a
contributor
site.
A
We
are
going
to
talk
about
this
a
little
bit,
but
another
one
is
kate's,
not
dev
and
kubernetes.dev
are
obviously
you
know
those
are
aliases,
so
it's
fine,
but
calendar
is
also
one,
so
another
george
pro
tip
will
always
take
you
to
the
calendar.
A
Remember
that
yaml
file
that
I
showed
you
and
it
was
like
a
hot
mess,
here's
an
entire
thing
that
has
the
calendar
on
it,
and
this
is
the
kind
of
place
where
we're
thinking
caps
with
a
search
engine,
and
we
put
events
on
here.
The
you
know
the
contributor
guide
this
this
this
kind
of
stuff.
A
So
a
lot
of
people,
I'd
like
a
big
shout
out
to
bob
killen
on
this
on
this
work
here,
but
yeah
case
dev,
slash
release
actually
helped
me
find
some
things
that
I
that
I
also
want
to
point
out
to
the
crowd.
This
one
will
help
you
at
work.
I
promise
enhancement
tracking
sheet.
What's
that
yeah,
if
you
click
through
whoa.
B
Okay,
two
things
for
this
one:
hopefully
we're
gonna
get
rid
of
this
starting
in
122.
yeah
spreadsheets
are
not
anybody's
favorite
thing.
B
Cloud
native
spreadsheets
cloud
native
spreadsheets,
so
right
now
what
happens
during
the
release?
Is
you
know
people
submit
enhancements
whatever
they
they
target
them
for
a
given
release?
Sometimes
they
don't.
Sometimes
they
just
have
this
issue
running
and
they
don't
know
they
need
to
tell
the
release
team.
That's
going
to
be
in
this
or
they
don't
know
that
it
needs
to
be
milestone.
B
So
what
the
release
team
does
currently
is
comb
through
all
of
the
open
issues.
So
if
you
went
to
the
kubernetes
enhancements
repo
under
issues,
there's
a
there's,
a
tracking
issue
for
everything
right
and
they
comb
through
and
you,
if
you
look
at
any
one
of
those
things,
you'll
see
pings
from
like
the
117
enhancement
team,
the
118,
whatever.
Eventually
it
just
becomes
kind
of
this
back
and
forth,
and
we
extract
information
out
of
it
and
put
it
into
the
spreadsheet.
So
this
will
tell
us
what
things
are
going
to
be
in
the
milestone.
B
What
things
so
at
the
beginning
of
the
release,
we'll
see
a
whole
bunch
of
things
that
are
maybe
tracked
things
that
are
at
risk.
Maybe
they
don't
have
all
the
things
done
for
their
need
to
be
done.
There's
different
tabs
too,
like
this
is
the
dashboard
it's
showing
you
yeah
yeah.
B
I
think
at
this
point
it's
probably
all
tracked
or
removed
for
milestone
like
when
we
got
to
code
freeze,
if
things
didn't
make
it,
they
got
removed
from
milestone
right.
So
this
is
just
right.
Now
is
a
great
way
to
figure
out.
What's
going
to
be
in
the
release,
what's
not
and
kind
of
keep
track
of
these
things.
It'll
also
really
helpfully
link
you
to
because
we
have
to
keep
track
of
that
stuff
for
the
release.
It'll.
Try
to
link
you
to
like
okay
website
prs.
B
If
you
want
to
read
the
document
yeah
or
the
actual
implementations,
but
let's
pause
for
a
second
spreadsheets
are
not
the
best
way
to
work
stuff
and
the
process
we've
been
using
to
collect
enhancements
is,
is
super
labor-intensive
and
it
you
know
it's
it.
It's
it's!
It's
front-loaded
for
the
the
release,
so
the
enhancements
lead
in
the
shadows
and
people
that
are
like
apprenticing
to
do
that.
That
role
have
spent
a
lot
of
time,
and
it's
very
very
easy
to
miss
these
things
too.
B
So
one
of
the
things
we
in
the
enhancements
project
undertake
architecture.
Let's
put
that
hat
on,
we've
been
trying
to
think
about
how
to
make
this
process
better.
How
do
we,
you
know,
build
off
of
what's
been
happening
with
the
kep
process
so
like
when
you
were
scrolling
through
those
things
and
it
had
like
the
risks
and
the
mitigation
and
stuff?
That's
a
markdown
file
right,
not
really
easy
to
process
to
parse
those
things
out
with
automation
like
you
can,
but
it's
really
free
form
text
right
now,
right,
there's
also
a
kept.yaml.
B
In
there
that's
got
stuff,
that's
meant
for
tool,
consumption
or
for
automation,
consumption.
We
want
to
do
the
same
thing
for
the
release
process,
so
we
have
an
open
cap
that
I
linked
into
the
the
notes
that
people
can
go
actually
get
feedback
on
that
we
want
to
launch
for
122.,
so
we're
going
to
during
121
we're
going
to
refine
this
build
some
tooling
around
it.
B
B
Folder
and
inside
of
that
you'll
see
the
same
thing,
kind
of
things
that
are
represented
here,
so
there
will
be
proposed,
there
will
be
tracked
removed
from
milestone,
buckets
and
then
in
each
one
of
those
buckets
will
be
a
small
yaml
file
that
this
basically
gives
you
all
the
information.
That's
in
the
spreadsheet
yeah,
it's
cool,
because
we'll
do
a
couple
of
things
like
we'll
be
able
to
validate
the
status
of
that
kep
automatically.
B
We
won't
have
to
go
back
and
like
dig
through
a
bunch
of
things,
we'll
be
able
to
look
at
the
state.
Is
it
provisional
or
not
provisional
sure
targeted
for
this
milestone
and
if
it's
not
update
the
man,
the
stuff
for
us
automatically
when
it
merges
in,
but
the
other
thing
that
does
is
allow
us
to
build
a
manifest
of
all
the
things
that
are
in
the
release
or
removed
from
the
release.
Whatever
that,
we
can
then
turn
into
another
website.
B
We
can
augment
the
kept
website,
which
is
a
separate
effort
like
they're,
both
kind
of
happening
in
parallel
right.
You
know
they're
both
aimed
at
doing
the
same
thing,
making
this
whole
thing
more
transparent,
but
it'll,
allow
you
to
say
like
really
easily
122
what
came
in
121
or
123
what's
planned
and
then
you'll
be
able
to
go
back
historically
and
look
at
some
of
the
stuff
and
it'll,
be,
I
think,
really
nice
for
people
yeah
for.
A
Sure-
and
I
think
it's
great
for
those
of
you
out
there
who
are
kind
of
like
you-
see
what
you're
doing
at
work
right
and
you're
frustrated
about
your
own
tech,
debt
and
stuff,
and
here
we
are
here,
we
are
showing
you
our
manually
assembled
spreadsheet
right
so,
like
don't
feel
bad,
you
know
it's
fine.
We
all
have
something
to
improve
so
that
the
things
here
I
watch
kenny
coleman.
Do
this
by
hand
like
he's
sharing,
while
he's
working
on
it
and
now
he's
just
like
yeah.
B
A
We're
definitely
winding
down
here
soon,
but
I
do
want
to
give
it
a
few
minutes
here
for
the
audiences.
You
have
any
questions
for
for
jeremy
or
any
release
or
any
process
at
all
savvy
says.
I
suggest
a
contribution
how
to's,
where
to
start
episode
in
tgik
style,
if
not
done
before.
Indeed,
I
know,
I
know,
there's
a
lot
of
tour
videos
that
we've
been
trying
to
do
over
time
and
a
lot
of
that
is
just
lack
of
time.
A
But
if,
if
that's
something
that
you
want
to
tackle,
definitely
let
us
know
as
and
let
kubernetes
know
so,
I'm
using
the
term
us
somewhat
interchangeably.
I
apologize.
I
just
realized,
there's
us
here
at
tgik
and
then
there's
us
and
kubernetes.
We
wear
multiple
hats
sometimes,
and
this
one's
a
confusing
one
for
me.
So
does
anybody
have
any?
Is
there
anything
else
you
want
to
cover
here,
1.20
wise?
Perhaps
a
wink
wink
pitch
on
how
people
yeah
get
involved
in
helping
121.
B
Yeah,
so
just
selfishly,
I
think
the
release
team-
I
don't
know
selfishly,
but
I
think
the
release
is
a
great
place
to
get
involved.
If
you
haven't
been
a
contributor
before
or
if
you
are
a
contributor
and
you've
never
kind
of
gone
through
the
release,
process
and
you're
interested
in
how
a
sausage
is
made.
B
There
are
two
main
roles
on
the
team
or
two
like
classes
of
roles.
You
have
the
release,
lead
and
then
you've
got
sub
teams
under
that
and
sub
teams
are
led
by
a
person
and
each
one
of
those
sub
teams
would
be
like
enhancements
or
docs
or
release
notes.
All
of
them
are
focused
on
doing.
You
know
that
one
function
that
makes
the
release
successful
and
then
each
one
of
those
teams
has
a
number
of
shadows
and
the
shadows
are
really
like
those
apprentices
and
that's
open
to
everybody.
B
B
The
shadow
application
process
starts
with
a
form,
so
there
will
be
a
form
sent
out
probably
next
week.
Okay,
and
on
that
you
know,
it'll
ask
you:
it'll,
go
to
the
kubernetes
dev
website
or
sorry
mailing
list
and
then
it'll
also
be
posted
in
like
say,
release
on
the
cooper
eddie
slack
and
some
other
places.
B
Yeah
on
the
release
team,
there
are
the
enhancements
team,
the
ci
signal
team,
the
bug,
triage
team
and
maybe
really
go
through
and
like
help
us
categorize.
What
makes
up
the
this
will
help
you
out
too,
I
think
is
the
one
you
want
book.
Triage
looks
at
like
issues
and
pr's
that
have
been
have
been
opened
and
helps
kind
of
ensure
that
they're
being
handled
correctly
comms
helps
write
the
blogs
so
like
the
the
release,
blogs
that
come
out
after
they
work
with
contributors
to
help
write
those
things.
B
A
B
The
121
enhancement
or
ea
will
be
taylor,
who
was
the
118
release,
lead
only
doyle
on
twitter
super
great
guy
to
work
with.
He
was
the
lead
for
119..
I
enjoyed
working
with
him
immensely,
so
he's
going
to
be
the
the
ea
generally.
It's
one
of
the
previous
release
leads
he's
actually
the
first
one.
That's
done
it
twice.
I
think
okay,
previous
to
him,
was
tim,
pepper
and
then
yeah.
So
there's
a
few
people
that
haven't
done
it
yet,
hopefully
yeah.
B
Is
that
that
right,
yeah,
okay
yeah,
so
it's
just
a
great
way
to
come
back
and
help
you
know
share
what
you've
learned
be
an
advisor
and
one
of
the
great
things
they
do
is
help
to
run
the
shadow
program
so
making
sure
that
the
shadows
are
getting
what
they
need
out
of
it.
Helping
us
course
correct
during
the
time
I
think,
there's
probably
four
or
five
people
that
get
picked
to
be
shadows
for
each
one
of
those
roles.
B
B
A
B
Yeah,
so
the
retro
is
the
last
kind
of
artifact
or
ceremony
of
the
release
process
and
it's
one
of
my
favorites,
because
you
do
a
retro.
You
figure
out
like
what
works.
What
didn't
work
this
time
around?
We
really
tried
to
embrace
a
synchronicity
and
be
more
inclusive
of
time
zones.
So
you
know
generally,
in
the
past,
the
release
leads
have
all
been
in
the
us
most
likely
on
the
west
coast,
whereas
the
people
on
the
team
have
been
kind
of
distributed
in
121.
B
I
think
an
awesome
thing
is
that
lee
is
going
to
be
nabaroon
and
he's
in
india,
so
he'll
be
the
first
person
to
leave
the
release
outside
of
the
us
interesting
that
that
happened.
You
know
we
can't
expect
everybody
to
to
meet
at
the
same
time
right
sure,
11
30
p.m.
For
him,
if
we
do
the
same
same
times
as
normal,
so
one
of
the
things
we
did
this
time
around
was
kind
of
split
into
time,
zone,
centric
things
and
then
did
async
handoffs
between
the
teams.
B
That
is
great
that
worked
pretty
well.
We
tried
using
hackmd
for
a
while.
We
tried
using
google
docs
for
a
while
to
capture
stuff.
We
tried
using
both
for
a
while
turns
out
like
using
both
is
not
a
great
idea,
so
you
know
in
the
retro
we
talk
about
a
lot
of
those
things
and
we
write
down
like
what
we
want
to
continue
to
do
when
we
open
issues
to
really
like
go
fix.
B
Things
like
go
update
the
handbooks,
if
you're
interested
in
shadowing
while
we're
packing
that
topic
real
quick
in
the
sig
release
repo.
Maybe
it's
linked
off
of
here.
There
are
handbooks
for
each
one
of
these
roles
and
it
tells
you
exactly
what
you
do
so
it'll
give
you
a
really
great
idea
like
what
what
do
I
do
during
week?
Two.
What
do
I
do
during
week?
B
Four,
I
think
they're
just
great
sources
of
information,
even
if
you're
not
going
to
shadow-
and
you
just
want
to
know
more
about
the
process-
they're
really
great
sources
of
info.
A
Yeah
awesome,
and
with
that
the
last
question
was:
how
do
I
get
started
kates.dev
and
then
click
on
docs
and
slash
guide.
This
is
a
great
place
to
get
started
actually
because
I'm
always
looking
for
help
on
this
guide.
This
is
one
of
the
first
major
things
I
worked
on
with
people
and
it's
there's,
there's
always
room
for
improvement
for
everything
I'm
proud
of
it,
but
there's
always
things
you
can
you
know
with
improving
that
we're
going
to
wrap
it
up?
Jeremy.
We
thank
you
so
much
for
coming.
Thanks
for
having
me
everybody
here.
A
We
really
appreciate
you
coming
out
and
taking
the
time
what
does
the
future
hold
for
me
yeah
if
you're
following
me
on
twitter,
I
am
moving
on
from
vmware
but
similar
to
duffy.
The
kubernetes
community
is
a
family,
so
I
am
not
expecting
to
actually
go
somewhere
different.
I
will
be
involved
in
the
kubeflow
community
here
in
the
future,
so
stay
tuned
for
that.
But
you
will
definitely
see
me
at
cubecons
and
coming
to
hang
out
and
there's
a
lot
of
good
vmware
stuff
happening
in
2021..
A
Don't
worry,
joey
won't
spoil
it,
but
we
got
really
great
people
here
and
just
a
big
shout
out
to
thanks
the
audience
like
being
here
in
tgik
being
in
the
background
gathering
the
news,
links
and
just
my
job
is
kind
of
sit
there
and
watch
chat
and
just
see
you
all
learning
and
supporting
each
other
and
just
really
forming
a
great
community
and
then,
when
we
actually
go
to
physical
cube
cons.
A
Getting
to
meet
you
and
talk
to
you
and
stuff
has
just
been
a
fantastic
experience,
and
I
know
all
the
other
hosts
past
present
and
future
feel
the
same
way
and
at
that,
what
do
y'all
think
about
jeremy?
B
A
So
I
really
glad
that
you
all
listened
in
this.
I
know
this
was
a
format
change.
Let
us
know
if
you
like
it.
Do
we
add
more
of
these?
Do
you
want
only
tech
stuff?
Should
we
bring
in
different
things,
we're
always
looking
to
improve
the
show,
as
this
is
like
episode,
140
or
150,
or
something
we've
done
a
lot
of
these,
so
we're
we're
getting
you
know
we're
getting.
I
don't
want
us
to
get
too
comfortable,
you
know,
so
we're
definitely
always
looking
at
your
feedback.
A
So
with
that.
Thank
you
very
much.
Thanks
to
paul
czar
in
the
background,
doing
paul
was
really
upset.
You
were
on
the
spreadsheet
for
way
too
long
man
you
move
on
from
the
spreadsheet.
Don't
you
don't
want
to
scare
them
so
with
that
happy
holidays
to
those
of
you
celebrating
with
that
tgik
is
out
and
we
will
we're
done
for
2020
in
case,
that's
not
obvious,
and
we
definitely
look
forward
to
seeing
you
in
2021.
So
with
that
cheers
everyone
and
remember
it's
friday,
don't
touch
anything
in
production.