►
Description
- 00:00:00 - Welcome to TGIK!
- 00:03:30 - Week in Review
- 00:19:35 - Start of panel/interview
Episode notes at https://github.com/vmware-tanzu/tgik/tree/master/episodes/150/README.md
This week we are trying something new on TGIK! Joe is inviting the authors of "Production Kubernetes" on to talk about the book. Come, hang out and ask questions. Let's see how many of Josh, Rich, Alex and John we can get to join us.
You can get a FREE (in exchange for email) copy here: https://tanzu.vmware.com/content/ebooks/production-kubernetes.
You can also buy a paper copy book: https://www.amazon.com/Production-Kubernetes-Successful-Application-Platforms/dp/1492092304
A
Hello,
everybody
and
welcome
to
tgik.
We
are
trying
something
a
little
bit
different
this
time,
using
some
new
software
and
and
having
a
lot
of
guests
coming
on
and
joining
us.
So
let
me
go
ahead
and
introduce
everybody
here:
I'm
trying
this
stuff
out
all
right,
so
so
I'm
Joe,
Bida,
I'm
a
principal
engineer:
VMware
tanzu!
This
is
tgik
a
a
weekly-ish
broadcast
that
we
do
or
we
explore
a
bunch
of
topics
involving
kubernetes,
and
this
week,
I
invited
a
whole
bunch
of
folks
to
to
join
us.
A
I'm
going
to
be
co-hosting
with
with
Nova
here,
say:
hi
Nova,
you're
supposed
to
say:
hi
Nova,
oh
hey,
hi,
oh
you're,
you're,
awful
loud
something
happened.
There
we've
been
playing
around
with
mics
and
levels
and
stuff,
and
then
I'm
also
really
happy
to
welcome
Alex,
rich
and
John,
who
are
the
co-authors.
On
this
book
that
was
just
came
out.
A
We're
gonna,
try
and
keep
this
really
informal
and
have
some
chats
and
stuff
and
I
think
you
know
just
the
format
for
tgik
as
I
like
to
start
out
and
say
hi
to
all
the
folks
that
are
joining
us
from
all
over
the
all
over
the
world
and
I
think
we
have
some
new
capabilities
here
where
I
can
go
through
and
actually
start
highlighting.
Some
some
interesting
comments
here,
so
a
lead.
Thank
you
for
joining
us.
A
I
know
you've
been
with
us
for
so
many
of
these
episodes,
and
it's
it's
great
that
we
hit
150.
It
feels
like
episode.
100
was
just
like
I,
don't
know
yesterday,
I
don't
know,
but
time
doesn't
exist
now
as
far
as
I'm
concerned
and
like
yeah
I
think,
let's
see
we
have
Martin
from
the
Netherlands
and
welcome
Muhammad
from
Chicago
Eric
from
Dallas
Fort
Worth
popping
some
popcorn
here,
Michael
from
Australia
zabke
from
France
France
Tim
from
the
Bay
Area.
A
Let's
see
so
we
have
some
folks
from.
Let's
see
turkey
Scottsdale
Helsinki
Tehran,
you
know
I'm,
always
Blown
Away
oops
things
moved
on
I'm,
always
blown
away
when
I
see
all
the
folks
joining
us
from
all
over
the
world,
and
it's
always
great
to
be
able
to
to
to
welcome
everybody
and
and
say
hi
Morocco
Omar
from
Somalia
crazy
Osama
from
from
Saudi
Arabia.
A
You
know
things
that
are
happening
in
the
kubernetes
world
and
sort
of
notes
of
the
week
and
one
of
the
things
I'm
not
sure
I'm
going
to
play
around
with
our
software
here
and
see
if
I
can
go
ahead
and
actually
project.
Let's
see
if
I
can
make
things
big
enough,
that
we
can
do
this
and
then
I
would
love
for
the
rest
of
the
folks
to
be
able
to
comment
on
what's
going
on
here.
We
didn't
actually
practice
this
beforehand
and
I
probably
should
have
but
we'll
go
ahead
and
we'll
do
that.
B
A
So
those
who
haven't
been
paying
attention-
my
wife-
was
actually
hiking
the
the
Grand
Canyon
this
week
and
and
so
I
think
she
she
missed
all
this.
Maybe
she
was
lucky,
but
there's
this
absolutely
enormous
container
ship
like
I,
don't
even
like
the
scale
of
this
thing,
really
boggles
the
mind
that
ran
itself
aground
sideways
during
I
believe
a
sandstorm
right.
A
You
know
in
the
Suez
Canal
and
so,
like
you
know
the
entire
you
know,
shipping
world
is
totally
totally
turned
upside
down,
and
so
it's
really
really
crazy
to
see
that-
and
you
know
the
the
parallels
to
kubernetes
in
our
industry.
You
know
they
never
stop
right
yeah.
What
are
the
best
memes
that
you
guys
saw
on
this
I
mean
if
you,
if
you
can
pull
a
pointers,
bonus
points,
but
you
know.
B
B
It
was
really
informative
and
it
looks
like
the
pilot
of
the
ship
pulled
it
off
and
actually
nailed
it
and
did
like
a
really
fantastic
job
at
navigating
concerns
and
like,
even
though
like
something
bad
happened
in
the
middle
of
the
storm
like
from
a
production
standpoint
like
we're
actually
in
much
better
shape
than
we
could
have
been
otherwise
and
I.
Don't
know
that
to
me
was
kind
of
like
the
postmortem,
where
it's
like.
A
B
D
A
Yeah,
these
ships
are
absolutely
amazing.
Now.
My
understanding
is
that
like-
and
this
was
part
of
the
thread
that
Nova
was
talking
about-
is
that
there
are
professional
people
that
you
pay
big
money
to.
Who
are?
You
know?
You
know
allegedly
experts
on
navigating
these
types
of
waterways
and
so
you've
essentially
hand
control
of
your
boat
over
to
them,
with
the
idea
that
they're
not
going
to
run
at
a
ground.
A
A
A
Is
that
it's
all
it's
all
you
know
web-based,
and
so
there's
no
local
software
running,
and
so
it
makes
it
super
super
easy
to
get
to
get
guests
on
board,
because
you
essentially
just
send
them
a
link
and
then
you're
off
to
the
races,
and
so
that's
actually
been
working
out
really
well
all
right:
okay,
cool,
oh
man,
so
many
folks
to
say,
hi
to
Steve
and
George,
and
and
oh
there's,
Duffy
on
board
and
Tim.
Oh
man,
that's
awesome
all
right!
A
So
so
I
was
checking
and
okay
awesome
somebody's,
adding
some
of
the
you're
adding
the
threads
there
Nova
okay,
so
the
other
things
I
was
checking
like
right
at
to
see.
What's
new,
these
are
you
know,
George,
as
he
left
VMware
gave
us
all
his
cheat
codes
for
where
he
goes
and
finds
links
for
the
for
the
news
of
the
week,
and
there
was
the
one
thing
that
I
don't
wanna
I.
A
So
I
can
scroll
down
a
little
bit
and
you
can
see
you
know
the
it's
a
declarative
approach,
but
they
have
essentially
their
own
crd
that
talks
about
their
services.
The
Shaws
bring
a
bunch
of
stuff
in
there.
I
think
this
is
really
cool,
because
then
they
can
actually
have
a
very
you
know
great.
You
know.
Oh,
this
is
a
great
diagram
here.
They
have
a
great
sort
of
flow
where
they'd
use
this
to
actually
then
deploy
all
of
their
different
different
Stacks.
So
you
no
longer
have
sort
of
a
static
staging.
A
E
So
seeing
it
not
as
much
but
I
expect
to
see
it
a
lot
coming
up,
it's
one
of
those
evolving
trends
that
I
expect
to
see
more
and
more,
and
it's
it's
funny
that
some
colleagues
and
I
are
working
on
a
similar
kind
of
concept
for
using
custom
resources
to
instantiate
platform
services.
So
it's
it's
a
similar
idea
to
what's
going
on
here
and
I
expect
to
see
a
lot.
E
A
A
How
can
we
do
some
of
those
same
things
but
I
think
there's
always
going
to
be
a
need
for
those
that
need
to
take
it
to
the
next
level
need
to
go
further
and
start
really
customizing
it,
and
more
so,
but
I
think
it's
it's
interesting
that
so
these
folks
they
the
way
that
they
actually
broke
broke
it
out.
At
least
I
was
reading
a
little
bit
is
that
they
have
a
controller,
that's
relatively
stable
and
then
they
have
and
I
don't
know.
I
mean
I
assume
that
this
is.
A
You
know,
there's
there's
probably
some
open
source
to
go
along
with
this,
but
they
also
then
have
this
thing
that
they
run
as
a
job
to
bring
some
of
these
things
up,
but
that
I
think
is
written
in
Python.
So
it's
a
lot
more.
You
know
malleable
in
terms
of
being
able
to
update
it,
and
so
it's
going
to
be
interesting
to
see
if
we
can
find
ways
to
to
sort
of
capture
and
reuse
some
of
these
patterns.
That's.
A
Yeah
I
think
this
is
one
of
the
things
that
I
liked
when
I,
when
I
did
a
tgik
on
Kudo,
which
is
essentially
an
operator
toolkit
for
for
mostly
stateful
services.
But
it's
the
idea
is
that
the
the
core
is
relatively
stable,
but
then
you
can
do
a
bunch
of
like
bash
or
Python
scripts
or
whatever
for
doing
sort
of
the
the
stuff.
That
really
is
gonna.
You
know
you
want
that
to
be
a
much
more
malleable.
A
Think
this
is
just
spinning
up
essentially
namespaces,
but
I
think
you
know
looking
at
this
in
you
know,
connection
with
things
like
Cappy
and
really
moving
towards
the
the
base
infrastructure
being
more
malleable,
also
I
think
there's
more
room
to
to
be
able
to
actually
do
more
of
this
more
widely
yeah.
So
really
interesting.
Pattern.
C
Yeah,
this
reminds
me
a
little
bit
of
a
pattern
that
we
I
think
we
we've
seen
a
ton
which
is
using
operators
to
either
manage,
or
in
kind
of
like
instantiate
or
see
the
namespaces,
where
you
make
it
super
easy
for
teams
to
kind
of
just
come
in
and
request
a
namespace
and
then
there's
an
operator
that
just
sets
everything
up
for
them
sets
up
all
the
policies.
Then
the
networking
policies,
the
quotas
so
I-
think
we've
we've
seen
that
quite
a
bit
and
yeah.
This
seems
to
be
an
evolution
of
that.
A
I
know
that
whole
idea
of
like
capturing
everything
that
a
team
needs
into
a
crd
and
using
kubernetes
to
drive
that,
even
if
those
things
are
off
cluster
right,
like
you
know,
I've
seen
like
you
know,
heard
about
folks,
you
know
doing
something
like
you
know:
hey
every
team
needs
a
slack
channel,
so
let's
go
ahead
and
actually
create
the
slack
Channel.
Based
on
the
crd.
A
You
know,
oh,
maybe
we're
using
pagerduty,
let's
actually
set
up
and
connect
a
pager
do
to
automatically
based
on
sort
of
this
team
structure,
and
so
now,
all
of
a
sudden,
you're
you're
taking
kubernetes
such
as
a
generic
control
plane,
not
just
of
infrastructure
type
things,
but
also
really
configuring
all
the
other
resources.
That
teams
need
it's
kind
of
kind
of
crazy
stuff.
A
B
So
yeah
yeah
yeah,
so
I
I
follow
a
few
people
on
GitHub
and
I,
always
like
follow
like
the
the
people
in
all
different
parts
of
the
world.
This
is
something
that
came
up
today.
This
is
just
a
it's
a
it's.
A
lightweight
implementation,
that's
oci,
compliant
written
in
just
native
C
and
I
kind
of
look
at
this,
like
a
Bare,
Bones
container
run
time,
so
it's
it
basically
just
like
as
fireworks
or
firecracker,
is
to
VMS
I'm
kind
of
looking
at
this
as
to
fireworks
is
to
Containers.
B
So
it's
just
something:
I
want
to
check
out.
I've
I've,
obviously
grew
up
with
Docker,
then
I
moved
over
to
cryo,
CTL
and
cryo
for
all
of
my
kind
of
production
use
cases,
but
I've
never
really
found
just
like
the
the
Nitty
Gritty
Bare
Bones,
just
just
kind
of
run
a
container,
and
let
me
specify
compute,
storage
and
network
and
leave
me
alone
right
like
what
would
that
experience.
B
A
B
B
A
B
Well,
I
mean
I
I'd
like
to
follow
Linux
now,
and
what
I
found
is
that
usually
features
in
Linux
are
are
kind
of
like
set
the
pace
for
like
one
to
two
years
in
the
future
for
for
everything
else
and
Linux
512
will
be
coming
out
next
month.
We
just
got
I
think
five
eleven
seven
released
earlier
this
week,
but
this
is
relevant
because
we
were
talking
about
this
on
Twitter.
B
The
other
day
it
looks
like
Linux
is,
is
not
necessarily
giving
up
on
Swap,
but
it's
it's
getting
less
and
less
of
a
of
a
priority
for
the
colonel
team,
which
this
is
like.
This
is
huge
for
kubernetes
because,
as
we
all
know,
Swap
and
kubernetes
has
been
something
we've
all
been
kind
of
like
stuck
dealing
with,
or
rather
not
dealing
with,
as
we've
looked
at
how
kubernetes
runs
on
on
a
host.
B
A
Oh
man,
so
like
okay,
I'm
gonna,
ask
the
rest
of
the
panel
here
swap
like
you
know,
my
experience
at
Google
was
that
you
know
if
you
start
swapping
you've
lost
and
so,
like
you
know,
it's
like
nothing.
Good
happens
past
that
point.
It's
just
a
matter
of
like
how
badly
you've
lost.
How
do
you
deal
with
explaining
this
to
to
customers
to
folks?
You
know,
is
this
something
that
you
cover
in
the
book:
the
sort
of
the
realities
around
running,
swap
on
notes,
I've.
A
C
A
One
of
you
wants
to
send
a
link
to
Duffy.
We
can.
We
can
have
him
come
on
board
if
he's,
if
he's
up
for
it,
but
yeah
I
think
you
know
it
was.
It
was
interesting.
I
think
this
is
part
of
the
you
know
the
Google
doesn't
at
least
when
I
was
there
generally
didn't
use
swap
on
machines.
There
were
there
were
exceptional
cases
where
swap
would
be
used,
but
and
I
think
that
that
sort
of
point
of
view
definitely
infected
kubernetes
to
some
degree
but
yeah
cool.
A
I
think
there's
a
couple
of
things
number
one
is
that
if
you
do
it
naively,
it
ends
up
being
essentially
a
a
a
sort
of
a
shared
resource.
That
type
of
thing
where
that
isn't
necessarily
tracked,
and
then
the
other
thing
is
that
you
know
once
you
start
swapping
like
performance
Goes
to
Hell
right
and
so
things
technically
work,
but
from
a
point
of
view
of
a
reliable
Production
service
like
a
production
service.
That
swapping
is
not
really
working
right
from
to
any
definition
of
working.
Another.
B
Thing
that
was
brought
to
my
attention
was
like
a
lot
of
what
we
do
at
the
cuboid
level,
and
scheduling
totally
involves
this,
this
arithmetic
of
what
resources
do
we
have
available?
How
much
memory
do
we
have?
What
is
our
our
disc
pressure?
Look
like
all
this,
like
good
computer,
sciencey,
stuff
that
we
we
try
to
calculate
and
make
sense
of
at
runtime
and
and
swap
just
annihilates
all
that
it's
just
like
screw
you.
We
have
this
magic,
Dynamic
buffer,
that
we
may
or
may
not
use
and
there's
no
real
good,
Rhyme
or
Reason.
B
A
So
apparently,
thanks
George
for
doing
this
and
it's
gonna
be
a
little
bit
hard
to
read
I
apologize,
but
let
me
see
if
I
can
go
up
another
notch
or
two,
but
there's
a
there's,
a
link
to
a
document
there
for
those
who
want
to
go.
This
is
pretty
bleeding
edge
but
like
what
swapping
kubernetes
might
turn
into
I
have
no
knowledge
here,
but
it's
good
to
see
that
there's
progress
being
made
there
thanks
for
that,
George
appreciate
it
all
right.
B
A
A
Yeah,
why
don't
we
go
ahead
and
get
started
with
our
with
our
questions
and
I'll
start
us
off
here:
Rich
John
Alex,
you
all
can
decide
which,
which
one
you
want
to
start
with.
Tell
us
a
little
bit
about
yourselves.
Introduce
yourself
what
you
oh
and
the
first
thing
I
want
to
say
is
that
Josh
was
going
to
join
us,
but
he
he
let
us
know
this
morning
that
you
know
overnight.
He
got
super
sick.
It
sounded
like
you
know.
A
It
was
something
temporary,
but
that
means
that
he
had
to
tap
out.
So
he
he
will
not
be
joining
us
so
pour
one
out
for
Josh
we're
missing
you
buddy,
but
the
rest
of
y'all
tell
us
about
yourselves
how
you
got
to
to
hear
you
know
what
you're
doing
these
days
and
and
what
led
you
to
to
to
to
write
the
book.
E
I
can
go
first,
so
myself,
my
name
is
Rich
Lander
I'm
based
in
Tampa,
Bay
Florida
I
have
a
funny
accent,
because
I
grew
up
in
Australia,
but
I've
lived
in
Florida
for
about
20
years
now,
sunny
Florida
I
like
it
here.
It's
great
I
was
an
early
adopter
of
Docker
and
kubernetes.
That's
how
I
found
myself
on
this
podcast.
E
So
in
a
previous
life,
I
was
a
an
owner
and
an
operator
of
a
kubernetes
platform,
and
we
went
to
production
in
about
2016
on
AWS
and
I
worked
for
a
company
based
here
in
Tampa
and
after
that
I
worked
at
Cora,
West
and
then
heftio
and
now
VMware
as
a
field
engineer,
which
is
another
name
for
a
consultant
that
helps
Enterprises,
adopt
kubernetes
and
Cloud
native
Tech,
and
how
I
came
to
write.
The
book
was
well,
Joss
should
Josh
Rosso
suggested
it
and
I
thought.
E
E
D
B
A
And
so
so
you
know
I
when
Josh
started
things
up
was
the
whole
idea
is
that
you
know
we
brought
you
in
and
and
brought
all
y'all
together.
Was
there
anybody
that
he
invited
that?
That
said
now,
this
is
too
much
work.
Does
anybody
who
missed
out
on
the
book
do
we
know
we
can
ask
Josh
Josh,
isn't
here
to
tell
us
he.
D
E
D
C
C
A
B
B
Kubernetes
here
in
front
of
me,
and
it's
it's
as
a
fellow
O'reilly
author
I
had
a
little
section
of
like
my
friends
and
family
and
books
that
I've
gotten
autographs,
so
I
very
much
am
going
to
make
it
a
personal
journey
of
mine
to
go
out
to
each
one
of
you
and
get
you
to
sign
this
book
here.
So
I'm
super
excited
for
it.
Supporting
authors
and
Technical
authors
is,
is
so
important
today
when,
when
a
lot
of
the
the
physical
media
isn't
isn't
what
it
used
to
be
so
hats
off
to
all
of
you.
B
But
my
question
is,
and
the
reason
I
asked
is
because
somebody
asked
me-
and
it
was
a
good
question
which
was
it
takes
a
lot
of
personal
commitment
to
write
a
book
I
mean
when
I
when
I
was
going
through
it.
It
was
it
was,
you
know
we
had
to
navigate
children
and
schedules
and
work
and
emergency
rooms
and
all
kinds
of
stuff.
What
was
that
like
for
all
of
you
and
looking
back?
Do
you
think
you
would
do
it
again.
C
C
Yeah,
for
me,
definitely
a
very,
very
big
commitment.
I
couldn't
have
done
it
with
like
a
support
system
around
me.
So
I
have
to
say
thanks
to
my
wife,
who
was
very
very
supportive
throughout
the
process,
the
team
as
well.
You
know
Rich,
John
and
Josh,
where
amazing
co-authors,
to
work
with
and
yeah
I
think
it
was
overall,
an
amazing
experience
and
I
I.
Think
I
would
do
it
again
to
be
honest,
I
I,
loved
it
I,
don't
know
Rich.
What
do
you
think.
E
So
I
didn't
love
it.
It
was
a
very
rewarding
experience,
but
it
was
a
lot
of
early
mornings
and
weekends
and
there
were
a
lot
of
times.
I
thought.
Why
did
I
sign
up
for
this,
but
as
each
chapter
like
it
got
better
and
better
as
time
went
on
and
I
was
super
gratified
to
see
it
all
come
together
and
I
would
do
it
again,
I
would
like
to
not
do
it
in
parallel
with
a
full-time
job.
I
would
love
to
do
it
full
time
that
would
be
nice
but
yeah.
E
D
Think
one
of
the
things
that
made
it
easier
to
get
like
often
people
say
the
difficult
thing
is
getting
started
right,
but
I
think
one
of
the
easiest
things
where
we
took
a
chapter
each
of
a
topic
that
we'd
recently
done
in
a
lot
of
depth
for
some
other
thing
and
we
were
able
to
nail
those
first
chapters
fairly
quickly.
I
felt
like
kind
of
got
us
on
a
bit
of
a
roll
and
I.
D
B
D
E
C
E
A
A
Kubecon
book
signing
you
all
up
for
that
definitely
yeah
that'll
be
fun
yeah.
No,
it's
always
crazy.
To
do
that.
You
know
when,
when,
when
I've
done
that
in
the
past,
you
always
want
to
talk
to
everybody
and
get
to
know
them
a
little
bit,
but
then
there's
like
this
long
line
and
you're
like
sorry,
I
can't
do
it,
but
that
would
be
awesome
to
have
that
happen.
Awesome.
A
You
know
this
is
one
of
those
things
where
I
think
you
know.
Oh
sorry,
wrong.
One
here,
Tim's
asking
here,
you
know
when
I
was
when,
when
I
was
working
with
Kelsey
and
and
Brendan
in
in
kubernetes
up
and
running,
you
know
I
the
way
I
write
my
process
very
different.
That's
the
old
copy,
Nova
very
different
from
the
way
Brendan
or
Kelsey
right
Brennan
has
a
tendency
to
Splat
some
stuff
out.
It's
like
you
know.
A
We
have
editors
for
a
reason,
I'm
much
more
careful
about
things
and
you
know,
and
it
was
hard
to
get
a
consistent
voice
across
all
the
different
chapters.
When
you
have
multiple
authors.
Is
that
something
that
you
all
sweated
or
you
know
if
you
read
the
book
and
you
actually
say
oh
well
clearly
you
know
so
and
so
wrote
this
chapter
or
what
have
you.
E
So
I
don't
think
we
would.
We
tried
to
get
that
consistent
tone
and
voice,
but
it
happened
through
review
and
an
example
of
that
is
I
t
when
I
write
I
tend
to
construct
these
rambling
run-on
sentences
and
they
drive
Josh
insane,
so
he
he
would
hit
most
of
his
comments
were:
can
you
shorten
this
up
and,
like
summarize,
or
make
a
little
more
concise?
So,
in
the
end
the
result
was
more
consistent,
but
we
I,
don't
I.
E
C
A
C
A
I
think
that's
something
that
you
know
I,
think
all
of
us
on
here
have
actually
gone
through
this
process.
Like
writing.
The
stuff
is
one
thing
actually
getting
into
shape:
editing
working
with
to
make
sure
that
everything's,
consistent,
you'll,
probably
haven't
hit
all
the
Errata
yet
that
you're
gonna
get
you
know
it's
like
you
get
these
things
where
people
report
stuff
and
you're
like
it's
too
late
to
change
it.
Now
you
can,
you
can
fix
the
online
versions,
but
once
it's
in
print,
you
can't
fix
stuff
all
right.
A
So,
let's,
let's
dig
in
a
little
bit
more.
What
what's
your
favorite
part
of
the
book
in
terms
of
advice
for
for
users
and
and
then
sort
of
the
least
favorite
part
like
in
terms
of
where
do
you
think
you
brought
some
unique
insights
here
or
you
think
you
did
a
particularly
well
job,
a
particularly
good
job
of
explaining
something
difficult.
E
For
my
part,
I
think
my
favorite
part
of
the
book.
Unfortunately
it
wasn't
one
of
my
chapters-
it
was
chapter
one
which
was
kind
of
the
point
of
the
book,
was
to
highlight
the
fact
that
kubernetes
by
itself
is
not
enough.
There
are
a
lot
of
platform
services
that
need
that
need
to
be
laid
on
top
to
make
it
a
habitable
place.
For
the
tenants
for
your
application
teams
and
Josh
did
Josh
wrote
chapter
one.
He
did
a
good
job
of
driving
that
point
home,
and
that
was
my
favorite
chapter.
I.
E
Think
my
my
least
favorite
chapter
is
deployment
models
chapter
two
and
it's
not
because
of
the
content.
It's
how
relevant
it
is
three
years
ago
how
you
deployed,
kubernetes
and
and
your
deployment
model
is
really
relevant-
was
really
relevant.
Today
there
are
so
many
Open
Source,
Products
and
Commercial
product
open
source
projects
and
Commercial
products
that
it's
it's
table,
Stakes,
it's
not
as
important
anymore.
D
Yeah,
the
same
I
think
probably
the
first
chapter,
because
I
think
the
first
chapter
crystallizes
really
well.
What
we
were
trying
to
do
with
the
book,
which
is
just
be
a
guide
I,
mean
I,
think
a
lot
of
technical
books
that
go
out
of
days
so
quickly
because
it's
specific,
tooling
or
specific
commands
or
its
versions
or
it's
you
know
as
a
reader
of
technical
books
right
that
can
be
super
frustrating.
So
we
we
didn't
want
to
fall
into
that
trap
we
wanted
to
be.
D
This
is
more
of
a
philosophical,
pragmatic
experience,
driven
guide
and
we
just
happen
to
be
using
some
tooling,
but
don't
look
too
kind
of
like
blur
the
lines
there.
Don't
look
too
closely
at
that
and
I
think
chapter
one
is
the
most
philosophical
least
Technical
and
therefore
reflects
Our
intention
the
best.
That's
probably
why
I'd
say
chapter
one
but.
A
Yeah
I
know
it's
so
easy
to
make
these
comparisons
of
kubernetes.
To
being
you
know,
the
Linux
kernel,
but
I
think
that
analogy
works
well
when
you're
talking
about
like
a
Linux
kernel
in
and
of
itself,
isn't
that
freaking
useful
right?
You
need
all
the
supporting
structure
around
it
to
make
it
work
and
really
kubernetes
is
is
very
similar
in
that
way
where
it's
like
raw
and
Bare
Bones
kubernetes
yeah,
you
can
do
something
with
it,
but
it's
really.
A
A
C
Course
but
yeah
chapter
one,
definitely
and
then
to
play
on
what
what
you
were
just
saying:
Joe
I
think
you
know:
building
those
platform
services
on
top
of
the
foundation,
so
chapter
11
is
also
one
of
my
favorites
building
platform
Services,
which
kind
of
goes
into
that
and
how
to
extend
the
platform
and
how
to
you
know,
make
it
more
much
more
useful
than
it
is
by
itself.
So
yeah.
A
A
F
A
F
This
may
have
already
been
shared,
but
I.
Think
like
the
one
thing,
that's
interesting
about
rich
Alex,
John
and
I
is
that
we
come
from
a
field
perspective
of
just
going
in
and
trying
to
make
people
successful
with
kubernetes
and
it's
an
interesting
world
to
live
in,
because
at
the
end
of
the
day
we
typically
like
go
in
and
we
have
to
figure
out
how
to
make
it
work.
F
So
we
have
this,
like
absurdly
pragmatic
outlook
on
like
how
we're
gonna
get
to
where
we
need
to
go,
and
we
have
a
bunch
of
really
interesting
shared
experience
in
doing
that
so
like
in
short,
like
rich
and
I,
disagree
on
so
much
stuff
like
fundamentally
we
we
just
I
mean
not
really.
We
disagree
on
a
lot
of
stuff,
though,
and
it's
awesome
because,
like
it
speaks
to
like
our
experiences
being
very
different
and
helping
people
be
successful
with
Cuban
is
I.
Think
my
favorite
part
about
writing.
This
book
has
been
like
Alex.
F
This
paragraph,
you
wrote
like
I,
totally
disagree
with
it
like
what
were
you
thinking
and
he's
like
Josh?
It
makes
total
sense
like
here's.
My
like
it
was
a
good
opportunity
for
us
to
come
together
since
we're
so
often
distributed
with
big
customers
and
actually
share
our
experiences
with
each
other
and
I
really
enjoyed
that
about
writing
the
book.
So.
A
That's
a
really
great
question,
so
I'm
going
to
call
an
audible
here.
What
are
like,
amongst
the
four
of
you
all.
What
are
things
that
you
disagree
about?
Where
you'll
just
argue
it
and,
like
you
know,
Polar
Opposites,
you
know
in
terms
of
you
know.
Well,
I
mean
kubernetes
related,
but
if
there's
other
things
you
know,
that's
that's
you
know,
I,
guess,
that's
all
fair
game.
F
I
think
I
mean
one
area
that
I
know
has
been
a
passionate
topic
is
and
there's
a
chapter
in
the
book
about
this
called
the
abstraction
Spectrum,
which
is
like
the
notion
of
like
what
is
the
right
abstraction
like
there's
so
many
ways
that
you
can
do
this.
You
could
self-serve
kubernetes
clusters
to
individual
development
teams.
F
You
could
make
kubernetes
an
implementation
detail
that
developers
never
ever
ever
should
know
about
and,
like
those
philosophies,
I
I
think
you
know
more
so
than
like
you
can
fit
on
a
tweet
like
it
they're
valid,
depending
on
what
you're
trying
to
solve
for
in
your
approach
and
I.
Think
all
of
us,
based
on
our
experience,
have
done
things
from
trying
to
get
developers
on
board
of
the
cube
where
it's
completely
opaque.
But
then
you
know
maybe
rich
I,
don't
know.
If
you
had
more
of
this
opinion.
F
D
I
think
it's
interesting
as
well.
We
all
kind
of
beca
became
because
we
are
distributed
and
we
always
worked
on
different
projects
and
different
customers.
I
mean
occasionally
together,
but
usually
different
ones.
We
became
inadvertent
advocates
for
the
use
cases
of
the
customers
that
we
had
worked
with
so
I
don't
want
to
mention
any
of
them,
but
you
know
certain
customers
were
doing
this
and
someone
would
say
no
one
does
that,
and
so
my
three
customers
all
did
that
and
someone
was
like.
D
E
So
it's
just
browsing
through
the
book
to
jog
my
memory
and
it
was
the
last
one
of
the
last
disagreements.
Josh
and
I
had
was
around
showback
and
chargeback,
and
the
model
that
you
should
use
in
order
to
charge
back
usage
to
the
customer
and
I
won't
go
into
the
Gory
details.
But
in
the
end
we
compromised
and
just
presented
both
options
and
then
let
the
user
decide
let
the
reader
decide
what
what's
the
best
option
for
them.
C
B
Here
at
the
bottom,
but
I
found
this
good
one
because
I
always
get
this
one
and
even
when,
like
you
know,
I'm
like
oh
yeah,
you
know
I
wrote
an
O'reilly
book
like
the
first
comment.
I
always
get
is
like.
What's
with
the
Condor
on
the
cover,
and
then
you
have
to
go
down
and
explain
everything
but
I'm
gonna.
Let
let
you
guys
take
it
away
here.
What's
I'll
I'll
ask
the
question
in
like
the
best
interviewer
voice.
I
can
guys
what's
what's
with
the
dolphin
on
the
cover
here.
E
D
This
is
the
best.
This
is
the
funniest
story,
so
I
like,
if
you,
if
you
don't
know
a
rally,
never
lets
anyone
choose,
the
animal
I
think
super
super
early
on
they
did,
but
now
they
don't
because
I
guess
everyone
would
just
ask
for
their
own
animal,
and
we
got
told
really
early
on
all
kubernetes
books
are
birds.
F
D
F
Whale
yeah
and
what's
funny
about
that
picture,
is,
if
you
look
at
the
whale
it
looks
a
little
like
scratched
up
and
kind
of
beat
up,
so
it's
either
like
a
hint
at
environmental
justice,
or
maybe
just
representative
that,
like
kubernetes,
is
really
hard
to
do
and
you
get
kind
of
beat
up
in
the
process.
You
know.
B
Well,
I've
got
another
one
here
for
so
this
is
just
a
general
question
and
since
we
have
all
the
authors
here
and
I'm
sure
this
gets
covered
in
the
books,
what
what
is
your
answer
to
the
age-old
question?
What
do
you
think
do
you
have
one
big
shared
cluster
to
rule
them
all,
or
do
you
have
teeny
tiny
clusters
for
each
individual
use
case
domain
or
tenant.
F
Yeah,
it's
probably
like
one
of
the
conversations
we
start
off
with
when
we
work
with
customers
honestly,
because
they're
always
like
you
know,
I
I,
don't
know
like
when
you
think
about
like
the
old
papers
about
Borg
and
stuff,
like
that
I
think.
A
lot
of
people's
perception
is
like
I'm
gonna
bring
kubernetes
in
and
make
it
this
like
massive
sea
of
compute
in
my
organization,
and
what
gets
really
interesting
is
like
all
of
a
sudden.
You
have
these
general
purpose
clusters
and
somebody's
like.
Oh
and
now.
F
We
need
like
this
really
nuanced
Alpha
GPU
support,
and
then
the
question
you
have
to
ask
is
like
okay,
like
what's
the
problem
domain,
that
we
need
to
solve
this
for
and
then
like.
Do
we
actually
want
to
to
use
kind
of
a
brutal
term
like
poison
our
general
purpose
clusters,
with
a
lot
of
these,
like
more
nuanced
things
that
only
like
a
subset
of
teams
need?
So
it
is
still
an
age-old
question
because
it's
still
really
hard
to
answer.
E
Yeah
definitely
I
was
talking
to
some
field
Engineers
that
are
working
with
a
customer
just
this
week
about
that
question.
Yet
again,
and
there
were,
there
was
an
app
team
that
wanted
access
to
Cluster
level
resources
and
the
platform
Tim
didn't
want
to
give
it
to
him
for
good
reason,
and
so
there's
a
good
reason
right
there.
Among
many.
C
F
And
we
try
to
be
like
strategically
naive,
like
instead
of
like
Naval
gazing
about
it
super
hard
like
let's
just
get
started
and
get
clusters
up
and
like
learn
what
the
pain
points
feel
because
I
don't
know
like
honestly,
every
time
I've
tried
to
like
describe
how
we
should
size
clusters
I've
almost
always
been
wrong.
If
I
get
it
right,
someday
I'll,
let
you
know,
but
so
far
my
track,
record's,
not
very
good.
You
know
so
and.
B
Awesome
I
got
another
one
here
from
from
somebody
at
home.
I
can
just
fire
these
off
real
quick
go
for
another
yeah,
so
is.
Is
there
anything
that
that
one,
you
called
out
of
scope
on
day?
One
cough
cough
infrastructure
looking
at
Joe,
or
is
there
anything
that
that
you
ended
up
pulling
out
at
the
end
in
in
the
book?
And
if
so,
why.
E
C
I,
don't
and
I
don't
think
we
like
out
of
the
get-go
I,
don't
think
we
yeah
I,
can't
think
of
anything
that
we
kind
of
said
we
would
not
cover
I.
Guess
we
kind
of
wanted
to
do
not
a
like
a.
We
wanted
to
focus
on,
maybe
people
that
had
already
had
exposure
to
kubernetes.
So
we
won't
go
into
explaining.
You
know
the
the
like
the
kubernetes
basics,
so
maybe
that
potentially
could
be
but
yeah
that's
the
only
thing
I
can
think
of
so.
A
A
So,
let's
see
I'm
looking
at
our
question
list
here
and
we
have
so
many
good
questions.
I
guess
one
thing
you
know
there's
some
questions
early
on
advice
to
folks
who
want
to
write
a
book
aspiring
authors.
You
know
what
are
you
know
you
know:
do
it
don't
do
it?
Are
there
some
things
that
that
you
know
if
you
did
it
over
again?
You
would
have
these
lessons
that
you
would
that
you
would
be
able
to
tell
folks.
E
C
On
the
on
Joe's
question
around:
should
you
do
it
I
I,
again,
I
I,
loved
it
I
think
it
was
a
super
rewarding
experience.
If,
if
you
want
to
do
it,
definitely
try
to
do
it
even
if
it's
like
I
feel
like
you
can
even
self-publish
these
days.
So
it's
it's.
Definitely
a
rewarding
experience,
I
think
doing
it
as
as
a
team
as
well
like
the
discussions
we
have
along
the
way
were
about
were
essentially
invaluable.
F
Yeah
do
it
with
humans.
You
like
it
was
such
a
blast
like
having
the
conversations
that
we'd
have
multiple
times
a
week.
Probably
like
one
of
the
highlights
of
my
career
honestly
is
just
like
the
powwow
sessions.
We
do
just
talking
about
like
different
concepts
like
I
feel
like
we
just
don't
get
enough
time
to
do
that,
and
since
we
could
rally
behind
writing
a
book,
it
was
a
really
cool
experience.
Do.
D
It
I
think
everyone
has
some
unique
Insight
right,
you
know
like
so
no
one
will
pick
up
our
book
and
every
single
thing
will
be
new,
but
no
one
will
pick
it
up
and
every
they'll
know
everything
either
right
apart
from
maybe
Duffy
like,
but
you
know
everyone
has
some
unique
Insight
everyone's
gonna
learn
something
from
what
you
put
out
there.
Everyone
has
their
own
Viewpoint
their
own
experience.
D
You
know
like
it's
going
to
be
useful
for
someone
I,
think
if
you
just
go
with
the
intention
to
try
and
put
your
knowledge
out
there
and
help
someone.
You
know
a
you'll
learn
a
lot
more
about
it
yourself,
just
by
trying
to
teach
it,
but
also
you
know,
someone's
gonna
get
something
out
of
it.
So
for
sure.
B
A
All
right,
I
got
I
got
another
I'm
gonna
call
Steve's
question
here.
What
would
be
that
your
most
important
thing
to
do
when
productionizing
a
cluster
like
what
is
tier
number
one
and
it
depends,
doesn't
count
good
point:
Steve
We're
not
gonna,
allow
it
depends
what
what
is
your
first
thing
that
you
tell
folks
when
they're
when
they
wanna.
F
Make
make
sure
that
you're?
Not
this,
hopefully
doesn't
sound
like
it
depends
but
like
make
sure
that
you're
actually
understanding
the
developer
experience
you
want
to
deliver,
because
that
really
is
going
to
be
like
a
guiding
North
Star.
It's
like
a
mission
statement
that,
like,
if
you're
unsure
of
whether
you
should
deploy
X
or
configure,
why
you
can
always
come
back
to
that
Vision.
F
You
have
of
an
end
state
that
you
want
to
get
to,
and
it's
funny
I
think
we
run
into
a
lot
of
folks
who
do
not
do
this
like
they
go
in
and
they
say
we're
just
going
to
bring
up
kubernetes,
because
this
is
what
people
are
doing
now
and
that's
a
really
short-sighted
Vision,
because,
like
what
does
it
actually
mean
to
bring
up
kubernetes?
What
are
you
actually
trying
to
solve
for
so
I
think
the
most
important
thing
we
do
is
figure
out.
What's
the
end
state
that
people
want
to
get
to.
E
C
For
me,
I
think,
maybe
a
bit
more
tactical,
don't
get
into
like
analysis,
paralysis,
I
feel
like
it's
very
easy
to
try
to
analyze
every
single
detail.
You
know
kubernetes
is
super
extensible.
You
can
change
things
along
the
way
so
feel
free
to
experiment,
and
if
you
find
that
you
know
you
maybe
took
a
wrong
turn,
that's
fine!
You
know
you
can
always
fix
it
or
change
it
right.
So
that's
that's
another
one.
For
me.
D
Oh
yeah
I'm,
just
gonna
cop
out
and
piggyback
on
Josh
and
Rich,
and
just
say
this
the
number
of
times
where
we
see
organizations
that
have
kind
of
scuppered
themselves
before
they've
started
by
not
understanding
what
they're
even
trying
to
achieve
when
they
start
and
the
time
that's
wasted.
I
mean
it's
in
the
millions
of
dollars,
value
for
sure
and.
E
F
But
let's
be
real,
don't
use,
iptables
is
the
actual
advice
I'm
just
joking
yeah
iptables
is
like
a
great
example
actually
of
something
that's
similar
to
what
we're
talking
about.
Where,
like
a
lot
of
times,
folks
will
read
like
oh
I,
can't
use
IP
tables
like
I
need
to
use
a
cni
that
replaces
it,
and
it's
like
well
like,
maybe
eventually
possibly
but
like
do
you
actually
understand
the
problem
domain?
D
There
still
is
there
was
previously,
but
there
still
is,
and
people
will
read
everything
there
is
to
know
and
they'll
catch
on
to
one
blog
post
or
something
which,
like
you
know,
I'm
gonna
pick
on
service
mesh
is
fine,
I,
don't
hate
service
mesh,
but
there
was
a
time
six
months
ago
where
everyone
absolutely
had
to
have
a
service
match
right
and
when
we
spoke
to
every
single
person,
almost
you
know
you
don't
need
a
service
match
to
stop
at
this.
It
was
going
to
make
the
rest.
D
It
was
going
to
give
them
a
two
percent
increase
in
whatever
productivity
they
wanted
in
one
area
and
then
degrade
the
rest
of
the
cluster.
Their
security
increase
the
complexity
by
probably
50
in
every
other
areas.
It's
like
you
know,
let's
just
let's
just
sell
for
the
low
hanging
fruit
to
begin
with.
A
Well,
you
know
I
definitely
see
a
lot
of
customers
come
at
this,
like
you
know,
looking
at
that
cncf
landscape
and
and
view
it
as
like,
you
know,
Pokemon,
you
got
to
collect
them
all
right
and
you
know
no,
no,
you
start
simple
figure
out
what
you
need
as
you
get
that
experience
for
sure,
and
nobody
have
a
do.
You
have
a
question,
a
topic.
B
C
I've
actually
been
digging
into
autopilot
recently
and
I
haven't
dug
into
it
enough,
but
from
what
I've
seen
it's
kind
of
like
a
super
lockdown
and
again
I
haven't
dig
into
it
enough,
but
it
feels
like
a
super
lockdown
super
limited,
kubernetes
distribution.
That's
set
up
in
a
way
where
developers
have
like
the
safety
guards
that
we
kind
of
talk
about
in
the
book,
which
is
interesting,
but
at
the
same
time
there's
some
limitations.
So
you,
for
example,
you
can't
deploy.
If
I'm
not
wrong,
you
can't
deploy
admission
controllers.
C
E
B
Strong
plus
one
we
have
some
more
here
in
the
the
chat,
this
one
is
a
bit
of
a
logistics
question
for
the
authors
and
I
think
this.
This
is
just
relevant
for
for
everyone
right
now.
Were
there
any
challenges
with
with
the
constraints
of
the
state
of
the
world,
giving
given
the
events
of
last
year
and
this
year
with
with
writing
a
new
book
and
and
if
so,
is
there
any
tips
or
tricks
that
you
learned
that
you
might?
You
might
share
that
that
you
think
would
help
other
folks.
F
F
These
folks
were
too
and
yeah
I
I
think
it
it
made
it
a
little
bit
easier
and
it's
something
to
know
about
us
is
we've
been
distributed
team
for
a
really
long
time,
so
there
wasn't
this
transition
out
of
like
not
seeing
each
other
in
the
office
like
we
already
don't
expect
seeing
each
other
in
the
office,
and
that
made
the
progression.
Pretty
Natural
yeah.
A
B
B
F
Yeah,
it's
a
really
great
question
right,
because
sometimes
we
find
ourselves
trying
to
make
old
patterns
work
in
the
context
of
kubernetes
and
it's
kind
of
like
forcing
a
square
peg
into
a
round
hole
and
that
can
be
pretty
tough.
But
on
the
other
side
of
things,
when
you
already
are
adopting
a
kubernetes
initiative.
F
E
And
the
one
thing
I
that
occurred
to
me,
while
I
was
reading,
that
question
was
having
gone
through
that
transition,
one
of
the
things
that
helped
was
Finding
ways
to
reliably
automate
your
processes,
because
that
was
the
biggest
difference
for
me
once
upon
a
time
there
were
a
lot
of
manual
operations
and
finding
ways
to
declare
State
and
then
automate
realization
of
that
state.
Those
are
the
core
principles
you
need
to
revolve
around
the
tools.
F
Yeah
and
like
if
we
one
of
the
things
that
we
talk
about
in
the
storage
chapter
is
like
kubernetes
gives
us
a
lot
of
ways
to
provide
developers.
Primitives
where,
like
the
underlying
data
store,
could
hopefully
maybe
become
less
important,
like
you
think,
about
CSI
drivers
and
storage
classes,
and
if
we
can
set
up
a
self-serve
storage
model,
whether
it
be
backed
by
NFS,
whether
it
be
backed
by
EBS,
whether
it
be
backed
by
anything
as
long
as
developers
can
quickly
and
easily
access
storage
and
demand.
F
It
self-serve,
you're,
probably
going
to
be
in
a
pretty
good
place
and
developers
will
probably
like
that,
because
maybe
we
just
work
with
really
big
Legacy
companies,
but
usually
they're
filing
tickets
and
waiting.
You
know
eight
weeks
for
that
storage
to
become
available
right.
So
that's
a
huge
win
from
a
developer
standpoint.
A
So,
okay,
here's
another
question:
this
is
not
an
audience
question,
but
I'll
ask
it.
Are
there
any
sort
of
sub
Tweets
in
the
book
towards
customers
and
customer
situations
that
you
all
have
seen
you?
Don't
please
don't
name
names,
I,
don't
want
to
get
anybody
in
trouble,
but
like
are
there
any
times
where
you're
writing
stuff
and
you're,
like
oh
I,
know
who
I'm
pointing
this
one
at
yes,.
B
B
So
we
did
Joe
and
Craig
and
Brendan
did
a
panel
in
Seattle
and
like
it
was
like
2019.
It
was
years
ago
and
one
of
the
questions
we
asked
them
was
looking
back.
If
you,
if
you
knew,
then
what
you
know
now,
what
would
you
have
done
differently
and
listening
to
Joe
and
Craig
talk
about
you
know
we
should
have.
You
know,
managed
infrastructure
and
all
of
these
sort
of
early
kubernetes
1.0
questions
we're
now
at
like
the
200
level
and
the
question
now
I'm
going
to
ask
to
all
of
you
looking
back.
B
E
Yeah
templating
resources
to
be
deployed
to
a
cluster
and
and
don't
take
that
to
mean
never
use
templating.
It's
it's
a
good
solution
when,
when
it's
called
for,
but
in
my
my
feeling
is
it's
it's
it's
a
workaround.
There
are
much
better
Solutions
and
one
of
those
Solutions
is
using
custom
resources
and
controllers
instead
of
templated
resources
as
an
example.
F
F
One
time,
a
long
time
ago,
koroski
wrote
an
ALB
Ingress
controller
and
we
got
to
the
point
where
we
were
having
people
put
Json
inside
of
annotations
for
their
Ingress
manifests
yeah.
It
was
gnarly.
It
was
really
bad
and
I
think
that
just
spoke
to
the
need
to
have
like
some
provider
specific
plugable
models
where,
like
it,
is
great
to
have
a
generic
API
that
can
float
between
providers,
but
there's
also
always
going
to
be
some
provider
specific
details
and
remember,
like
a
lot
of
this
stuff,
was
pre-like
crd.
C
D
D
You
know,
I
know
there
was
efforts
towards
federations,
effort
tools,
and
now
we
talk
about
things
like
copyrout
and
multiple
clusters,
really
the
you
know
the
best
practice
and
there
are
tools
which
enable
easy
creation
of
clusters
where
it
ever
used
to
be
the
thing
but
I
think
now
the
ecosystem
is
struggling
to
keep
up
well,
how
do
I
route
traffic
between
these
clusters?
How
do
I
do
perhaps
on
multiple
clusters?
How
do
I
get
visibility
over
multiple
clusters?
It
feels
like
cluster
previously
was
the
top
level
resource
in
the
hierarchy.
A
The
and
I
think
one
of
the
lessons
is
that,
as
we
moved
from
sort
of
the
experience
on
a
single
node
to
The
Experience
on
a
cluster
from
like
Docker
to
kubernetes,
we
needed
to
create
sort
of
new
patterns,
new
Concepts,
because
you
just
can't
trade
a
bunch
of
nodes
as
a
single
big,
node
right,
there's,
there's
there's
just
fundamental
differences
there
and
I
think
there's
going
to
be
a
similar
transition.
As
we
move
from
a
single
cluster
to
multi-clusters,
where
you
just
can't
you
know,
you
know
you
have
multiple
clusters
for
a
reason.
A
You
can't
just
paper
over
the
fact
that
you,
you
know
that
that
these
are
multiple
clusters
and
so
figuring
out
the
right
abstractions
to
coordinate
across
clusters
without
just
pretending.
It's
a
big
cluster
is
going
I
think
to
be
to
be
take
some
time
for
us
to
actually
figure
those
things
out,
discover
those
patterns
and
and
make
them
usable.
B
This
is
something
that,
like
you
know,
came
up
on
Monday,
it's
it's
it's
a
real
thing
and
and
if
real
conversations
are
going
into
it
and
and
I
haven't
been
able
to
find
a
super
great
compelling
easy
button
for
any
of
this
yet
which
is
now
we're
at
the
cluster
cluster
level
of
of
managing
this,
and
what
does
that
look
like
from
an
infrastructure
perspective?
It's
it's
real.
A
So
there's
one
question:
now:
this
scrolled
off
the
screen
here-
and
this
is
getting
a
little
bit
and
and
I
I
have
an
agenda
here
and
nobody
wrote
Duffy
next
to
it.
But
I
don't
know
if
Duffy
asked
this
one
and
says:
when
do
you
think
the
benefit
of
using
aggregated
apis
becomes
valuable
in
comparison
to
having
resources
defined
as
extensions
crds
and
existing
API
server?
A
E
So
I
I
don't
know
about
interesting
stuff
coming
down
the
pike,
but
the
use
case
is
simply
the
kubernetes
API
has
a
structure
to
it
that
fits
certain
patterns
and
if
and
if
you
need
to
do
something
that
falls
outside
of
those
patterns,
that's
when
it's
a
good
idea
and
that's
when
it
makes
sense,
that's
what
it
makes
sense
to
me.
There
are
certainly
things
that
we
Implement
that
use
it.
Metric
server
is
one
that
comes
to
mind,
so
you
see
it
around,
but
I
don't
put
it
this
way.
F
Yeah
I
think
sometimes
it's
like
the
processing
complexity
in
the
amount
of
storage
that
you're
trying
to
do
for
a
lot
of
use
cases
that
I
run
into
it.
We're
kind
of
in
a
world
right
now,
where
crds
are
just
getting
like.
You
know,
put
in
a
humongous
dump
truck
and
just
boom
shot
into
clusters
right
and
I.
F
A
Yeah
the
one
place
that
I
think
you
know
we
see
it
as
Andrea
uses
it
to
actually
reflect
essentially
ephemeral
status
of
networking,
so
so,
essentially
exposing
a
bunch
of
data
that
you
don't
want
to
necessarily
persist
that
you
know
and
I
think
it's
similar
to
the
to
the
the
metric
server
is
there
and
some
unreleased
stuff
that
we've
been
playing
with
around
in
in
VMware
is
essentially
looking
at.
How
do
you
take
something
happening
in
one
cluster
and
actually
project
it
into
another
cluster
using
an
aggregated,
API
server?
A
B
If
we
want
to
keep
going
so
this,
this
is
just
kind
of
like
any
time
you
get.
You
get
people
together
to
work
on
a
project
in
general,
I
I
love
to
ask
this
question,
which
is
there
anything
that
that
you
learned
or
that
you
noticed
that
you
wouldn't
have
otherwise
noticed
or
learned
if
it
wasn't
for
working
on
the
book
together.
B
Like
was
there
ever
a
moment
when
one
of
you
was
working
on
this
one
part
of
kubernetes
and
another
one,
had
you
know
some
thoughts
on
it
and
then
next
thing
you
know
you
realized,
oh
we're
solving
the
same
problem
or
there's
some
overlap
here.
There's
an
interesting
relationship
that
nobody
noticed.
F
E
F
I
mean
it's
so
many
other
concepts
are
so
interwoven.
You
know
so
like
when
we're
talking
about.
You
know
cni,
for
example,
but
Alex
is
writing
the
Ingress
or
service
routing
chapter
right.
Those
are
closely
related
because
they're
all
about
like
how
the
packets
get
in
and
what
we
do
and
I
think
there
were
so
many
moments
where
it
was
like.
F
D
I
think
we
had
like
a
month
per
chapter
of
about
a
month
per
chapter
of
work
right,
maybe
five
weeks
of
which
three
and
a
bit
weeks
were
writing
and
then
we'd
push
it
all
up,
and
then
one
and
a
half
two
weeks
for
review,
so
which
kind
of
tried
to
stick
to
that
I.
Think
and
yeah
just
pushing
up
and
pulling
down
to
gear
and
then
periodically
sinking
to
O'reilly
I
think
we're
using
GitHub
but
I.
Think
one
of
the
interesting
things
to
go
back
to
the
previous
question.
D
A
lot
was
how
big
kubernetes
now
is
that
no
one
can
hold
it
all
in
their
head
and
I
would
read
someone's
chapter
like
CSI,
where
I
haven't
done
a
ton
of
work,
because
you
know
we're
pulled
in
customer
directions
quite
often
and
I'd
read
like
there's
no
way
that
works
like
that,
and
then
you
go
in
the
documentation
you
play
with
a
spin
up
a
cluster
you're
like
God.
Damn
it
does
do
that
or
like
you
come
back
to
someone
else.
D
A
A
I
know
you
know,
people
say
like:
oh
that
person
could
read
the
phone
book
and
I'd
listen
I'd
be
like
that
person
could
read
me
a
yaml
file
and
I'd,
listen,
yeah
all
right
and
then
our
buddy
Craig
here.
This
is
a
good
one.
What
has
been
the
most
surprising
thing?
You've
learned
about
kubernetes
during
the
book
or
otherwise.
So
maybe
some
of
these
examples,
the
you
know
around
sort
of
like,
is
that
how
it
works.
I
mean
Are.
There
specific
examples
that
you
all
want
to
pull
up.
A
F
I
think
okay
I'll
go
on
a
limb
here
and
it
might
make
me
sound
a
little
bit
silly
I
think
I
did
have
the
perception
when
I
first
got
into
kubernetes.
That
was
like
just
give
the
developers
kubernetes,
it's
so
freaking,
awesome,
I,
think
kubernetes
is
so
cool.
I
love
containers
like
heck,
yeah,
I,
love
this
stuff
and
then
I
had
to
take
a
step
back
as
I
got
deeper
into
and
realized
like.
F
Well,
that's
because,
like
I,
like
this
area
of
software,
like
somebody
who's,
perhaps
developing
a
spring,
app
might
just
find
it
to
be
a
massive
burden
to
like
learn
this
completely
new
technology.
At
the
end
of
the
day,
the
things
they
care
about
are
extremely
different
than
me.
So
I
think
what
surprised
me
the
most
about
kubernetes
in
general,
and
that
is
reflected
in
this
book-
is
simply
that
like
know
your
audience
really
well,
because,
like
wow,
you
might
be
really
excited
about
kubernetes,
your
developers
might
potentially
care
less
and
those
are
your
customers
right.
A
E
E
D
I
think
for
beer
was
that
kubernetes
isn't
magic,
I
mean
like
I,
I,
discovered
it
fairly
early
on,
but
it
was
always
sold,
or
always
it
was
read
as
like.
It's
a
magic
thing:
it's
just
you
throw
a
bunch
of
applications
up
there.
If
a
machine
dies
or
a
data
center
dies,
everything
automatically
gets
moved
everything
you
know,
except
if
there's
even
a
different
availability
Zone.
If
that
doesn't
work,
or
if
it's
using
a
special
type
of
database
that
doesn't
work,
you
need
to
set
up
replication,
you
need
to
and
I'm
like
wait.
D
These
are
all
the
problems
I
had
anyway.
What
is
actually
doing
right
so
I
think
just
the
realization,
like
you,
still
have
to
have
a
really
good
understanding
of
how
things
work
and
it's
not
magic.
It's
just
providing
you
with
a
really
good
standard
framework.
Instead
of
guard
rails,
instead
of
apis
and
way
of
understanding
the
world
to
be
more
efficient
and
better
at
doing
those
things.
But
there's
no,
you
know
there's
no
magic
secret
source
that
kubernetes.
That
makes
all
the
hard
things
go
away.
Right,
there's
still
hard
problems,
but.
C
C
Maybe
that's
that
maybe
that's
the
most
surprising
yaml
everywhere,
I
think
for
me
and
to
piggyback
on
on
John.
It's
it's!
It's
not
magic,
but
at
the
same
time,
there's
so
much
like
hidden
complexity
like,
for
example,
on
the
networking
side
and
like
all
the
service,
routing,
stuff,
iptables
and
like
contract,
and
all
these
things
behind
the
scenes
that
it
kind
of
abstracts
from
you
as
well.
So
it's
kind
of
an
interesting.
It's
not
magic,
but
it
is
kind
of
magic.
B
Okay,
it's
a
one-word
answer
where
you
could
obviously
answer
more
than
that,
but
a
lot
of
people
say
once
you
write
a
book
you'll,
never
do
it
again,
so
I
have
to
ask
after
writing
the
book-
and
you
know,
I-
have
a
physical
copy
here.
In
my
hand,
do
you
in
the
future,
have
big
hopes
and
dreams
and
aspirations
for
ever
writing
another
book
now
that
you've
gone
through
the
process.
F
E
F
Not
only
not
to
lean
into
this
too
much
but
like
working
on
it
with
you
all
was
what
would
make
me
want
to
work
on
a
book
again.
It
would
be
with
a
group
of
humans
where
it
would
be
an
opportunity
to
not
just
put
words
on
pages,
but
like
talk
about
things
and
learn
stuff
from
one
another
and
I
think
that
would
be
an
easy,
easy
sell
for
me.
B
Know
hard
way,
I
really
did
I
set
up
an
Amazon
notification
when
Josh
tweeted
about
this,
or
he
might
have
told
me
ever
forget
how
I
learned
about
it.
But
at
some
point
I
clicked
the
button
in
Amazon
and
the
reason
I
did.
That
is
because
I
I've
learned
the
hard
way
that
if
you
don't
actually
go
and
order
one,
it
takes
a
couple
weeks
for
you
to
get
one
from
O'reilly.
B
B
So
kind
of
we
we
also
did
the
the
heppio
sponsorship
thing
and
those
ended
up
in
the
supply
closet
and
that
kind
of
turned
into
I
I.
Don't
know
I,
guess
I
can
say
it
out
loud
now,
but
that
turned
into
my
secret
personal
stash,
but
yeah
I,
don't
even
have
a
copy
of
my
book
here.
I
have
a
copy
of
your
book
John.
So
maybe
we
can.
We
can
trade
because.
B
B
A
F
We
hope
you
like
it
and
genuinely
expect
to
find
a
lot
of
interesting
perspective
that
you
can
add
to
your
perspective
tool
belt
and
maybe
even
expect
to
disagree
with
some
stuff
in
the
book.
That's
that's
super
healthy.
You
don't
need
to
take
it
wholesale.
It's
not
a
manual!
That's
going
to
get
you
to
production
kubernetes!
It's
just
a
bunch
of
ways
that
we've
looked
at
the
space
and
been
successful
in
the
past.
D
C
A
B
We
have
ik.info
Justin,
is
he
set
it
up
and
he
he's
the
one
who
kind
of
manages
it,
but
it's
cool,
because
it's
like
that
that
I
can
just
drop
like
tell
somebody
off
the
cuff
or
whatever,
and
it's
got
like
a
little
bio
about
me,
a
little
bio
about
him
and
like
a
big
amazon
logo.
So
like
at
least
my.
A
All
right
well,
thank
you
so
much
y'all
for
joining
us
and
thank
you
for
the
audience
for
sticking
with
us.
Through
this,
you
know
great
book.
You
know,
love
hearing
the
stories
for
how
it
all
came
together
and
look
forward
to
the
next
one.
Maybe
in
a
little
bit,
though,
all
right,
thank
you!
Everybody
and
we'll
see
you
next
week,
not
sure
who's
going
to
be
presenting.
Maybe
I'll.