►
From YouTube: KBE Insider: Clayton Coleman
Description
Settling for traditional resources can seem convenient when trying to learn a new skill or technology, but it is far from the most effective way. One must learn how to speak about it, apply it in the real world, what the use cases are, and so on. And what’s the best way to do that? Hearing from industry experts who have been around it, studying it, mastering it, writing about it for years. KBE Insider, hosted by CNCF Ambassador Chris Short and Developer Langdon White, lets you reach those people, hear what they have to say, and interact with them.
Learn more at https://www.kubernetesbyexample.com/community/kbe-insider
A
A
A
A
A
A
A
A
B
Good
morning,
good
afternoon,
good
evening
and
welcome
to
the
very
first
live
episode
of
kbe
insider,
it's
a
very
new
show.
I
will
hand
it
off
to
my
very
illustrious
friend
langdon
white,
to
tell
you
a
little
bit
more
about
it,
but
I'm
very
excited
to
have
the
show
coming
on
the
channel
and
the
folks
that
are
helping
us
with
it
are
awesome.
So,
yes,
thank
you
very
much.
Langdon
tell
us
a
little
bit
more
about
the
show.
C
Definitely
so
I'm
lagna
white,
as
you
may
know
me
from
another,
show
called
the
level
hour
you
know
and
other
places
on
the
channel.
You
should
definitely
come
check
out
other
things
that
we
do
here,
but
this
show
is
specifically
about
kind
of
in
in
combination
with
a
site
we
kind
of
relaunched
during
summit.
I
guess
two
weeks
ago
now
and
called
kubernetes
by
example,
and
kubernetes
kubernetes
by
example.com.
C
So
you
can
kind
of
try
to
get
a
deeper
understanding
of
what
kubernetes
is
and
how
it
functions
and
it
kind
of
takes
a
multi.
What
we're
trying
to
do
with
the
site
is
like
take
a
multi,
multi-learner
approach,
and
so
so
there's
like
video
content,
there's
also
like
actual
like
training
class
style
content,
there's
written
content
so
that
you
know,
depending
on
what
kind
of
learner
you
are,
you
can
kind
of
approach
it.
C
You
know
in
the
best
way
that
works
for
you,
so
that
was
kind
of
one
aspect
of
it.
But
as
part
of
that,
we
also
wanted
to
do
some
live
content.
You
know
because
we
know
a
lot
of
people
as
we've
seen
with
the
openshift
tv
channel
right,
I've
really
started
to
engage
with
the
kind
of
twitch
or
streaming
style
of
of
content
understanding,
so
this
show
is
kind
of
a
nod
to
that.
We're
trying
to
to
deliver
that
type
of
content
as
well.
C
But
specifically,
what
we're
doing
with
this
show
is
to
try
to
give
you
some
of
the
philosophy
in
a
sense
behind
kubernetes
or
the
ethos
or
whatever
word
you
like
to
use,
but
it
really
helps
when
you're
trying
to
learn
something
new
to
understand
what
its
goals
are
or
why
it's
trying
to
do
that.
You
know
because
then
things
become
more
intuitive
when
you
are
looking
at
the
actual
content
because
it
all
starts
to
fit
together
because
you're,
you
understand
the
larger
block.
D
D
So,
as
you
may
know,
cube
turned
seven
this
month
so
with
that
we
wanted
the
first
week
so
a
couple
weeks
ago
to
be
the
introduction
to
kubernetes.
So
we
definitely
wanted
to
talk
about
some
some
news,
some
latest
news,
but
we
also
wanted
to
talk
about
the
five
tips
we
wish.
We
knew
sooner
about
kubernetes
and
we
learned
that
those
are
successful.
Automation
requires
diligent
auditing,
ignore
kubernetes
pod
labeling
at
your
budget's
peril.
D
Understand
your
application's
resource
needs,
don't
play
around
with
etcd
and
you
don't
need
to
go
it
alone.
So
those
were
the
five
tips
that
we
wanted
to
bring
to
you
so
that
you
know
them
before
you
know
you
actually
had
to.
There
was
style
escape,
which
was
the
first
malware
to
target
windows,
containers
that
broke
out
of
cube
clusters
to
plant
backdoors
and
raid
notes
for
credentials,
which
was
pretty
important.
D
It
was
everywhere,
people
were
kind
of
freaking
out
about
it,
and
then
we
wanted
to
bring
a
case
study
for
you.
So
flipkart
is
india's
leading
e-commerce
company
and
they
actually
recently
adopted
open
ebs
for
storage
on
kubernetes
and
some
of
the
key
lessons.
The
q
platform
team
at
flipkart
has
learned
from
this.
Migration
was
that
being
production
ready
is
really
important.
Obviously,
managing
storage
resources,
creating
a
volume
group
construct,
lvm
partition
and
disk
failure
response.
D
He
told
us
that
we
have
to
try.
We
should
try
using
kubernetes
like
an
app
server
for
smaller
teams,
instead
of
treating
it
like
a
centralized
cloud,
and
then
we
had
david
lenthicum,
who
said
it's
time
to
get
more
aggressive
with
kubernetes
as
kubernetes
is
really
mature.
Now
I
just
mentioned
it
turned
seven
he's
saying
it's
time
to
take
some
risks
and
develop
the
next
generation
of
applications.
D
He
even
said
that
perhaps
we
can
weaponize
it
to
build,
build
a
better
business,
and
then
we
also
gave
you
the
top
25
kubernetes
experts
to
follow
on
twitter,
whether
you're
just
learning,
kubernetes
or
you're.
Already
a
seasoned
container
buff
you'll
need
the
right
right
resources
available,
such
as
tutorials
and
monitoring
tools,
which
is
kind
of
what
we're
trying
to
give
you
with
the
kbe
website
anyways,
and
this
also
includes
following
the
right
people
on
twitter
as
well.
Who
can
open
your
eyes
to
what
you
can
do
with
kubernetes?
D
So
that
was
a
quick
highlight
of
what
we
talked
about
since
we
launched
on
the
kbe
news
section,
I'm
going
to
drop
some
links
in
the
chat
as
well
in
case
you
guys
want
to
go
to
the
articles
and
and
see
what
they're
talking
about,
but
you
can
always
come
on
the
kbe
news
section
of
the
kb
website
to
to
see
what's
going
on
in
the
world
of
kubernetes
and
keep
yourself
up
to
date
on
what's
happening
and
with
that
I'm
giving
it
back
to
chris
short.
Take
it
away.
B
Yes,
I
think
it's
vitally
important
that
if
you're
mucking
with
fcd
that
you
do
not
come
up
with
that
cdd
unless
it's
just
to
give
it
the
performance
profile
that
it
needs.
So
thank
you.
Mina
awesome
work,
gordon
tilmore
dropped.
The
lincoln
chat
to
the
overarching
news
page,
so
yeah
feel
free
to
drop
any
of
those
links
in
mina.
So
langdon
we
have
a
special
guest
with
us
right
like
we
do.
We
should
probably
introduce
this
special
guest
of
ours.
C
C
A
C
A
And
I've
been,
you
know,
you
know
for
the
last
seven
years
since
just
before
kubernetes
was
publicly
announced,
like
I've
been
a
part
of
the
project
and
I've
kind
of
shifted,
my
role,
you
know,
so
I
still
contribute
heavily
well
I'd
like
to
say
I
contribute
heavily.
It's
maybe
a
trickle
compared
to
what
what
I
was
lucky
enough
to
be
able
to
do.
For
the
first
three
four
years
I
participate
in
cig
architecture
and
a
number
of
cigs
kind
of
trying
to
help.
You
know
smooth
over
the
gaps.
A
You
know,
we've
got
a
pretty
effective
community
system
these
days,
where
you
know
sig,
contribex
and
the
community.
That's
built
up
around
kubernetes
all
the
people
who
participate
from
big
companies
to
individuals
using
it
in
their
home
labs,
we've
kind
of
got
a
pretty
good
system,
and
so
I
kind
of
function
almost
as
a
kind
of
a
background
cog,
just
making
sure
that
stuff
ticks
over.
I
spend
a
lot
of
time
focused
on
kind
of
the
thorny
or
gnarly
issues
and
try
to
help
you
know,
teams
that
work
within
red
hat
or
teams.
A
You
know
across
companies
or
individuals
try
to
catch
trends
early,
so
you
know
things
that
are
important
in
kubernetes.
The
project
and
coordinates
has
a
really
you
know,
firm
boundary
and
there's
a
whole
bunch
of
stuff
out
there.
I
kind
of
try
to
help
people
move
across
that
interface.
So
is
it
something
that
kubernetes
needs
to
improve?
A
Okay,
let's
sort
out
and
work
with
some
teams
and
people,
and
you
know,
bring
together
the
folks
who
care
about
an
issue,
and
sometimes
it's
you
know
around
or
above
kubernetes,
and
I
spent
a
lot
of
time
with
openshift
and
the
openshift
community
and
people
using
you
know
kubernetes
in
production,
and
I
spend
a
lot
of
time
listening
to
what
they
say
and
then
saying.
Well,
you
know
that's.
A
A
When
you
start
hitting
limits
when
you
hit
the
kind
of
what
is
kubernetes
grade
for
and
what
is
kubernetes
not
great
for
when
you
start
hitting
those
limits
trying
to
help,
you
know
think
about
where
kubernetes
can
go
or
where
the
ecosystem
around
queries
can
go
or
how
kubernetes
itself
should
change.
So
it's
kind
of
a
it's
a
mishmash
of
big
I've
read
a
lot
of
powerpoint
presentations,
and
I
do
most
of
my
coding
in
powerpoint
these
days.
A
But
but
it's
a
lot
of
communication
and
you
know
helping
people
helping
people
come
together
and
find
like.
You
know
that
lucky
person
who
also
cares
about
the
same
problem
as
you
that's
actually.
What
I
really
enjoy
is
when
I
can
connect
to
people
who
have
the
same
problem
and
then
they
can
go
fix
it
in
kubernetes.
We
can
get
it.
We
can
make
the
world
a
little
bit
better
a
place
every
day
right
right.
C
Yeah,
I
would
actually
like
to
explore
the
communication
part
of
the
problem,
a
bunch
more,
but
before
we
do
that,
I
would
like
to
ask
you
and
we're
we're
trying
to
set
up
a
some
a
theme
here
of
when
we
do
the
show
you
know.
Can
you
tell
us
a
little
bit
about
like
how
you
got
into
open
source
to
begin
with,
like
what
brought
you
into
the
that
community
or
into
that
world?.
A
So
it
was
really
interesting.
I
went
to
work
for
this
company
called
red
hat
and
I
certainly
had
to
use
I
used
open
source
prior
to
that.
I
actually
worked
at
ibm.
Ironically
enough.
You
know,
started
out
of
college
worked
at
ibm
in
north
carolina
for
like
10
years,
and
I
was
like
you
know.
I
did
a
lot
there
and
I
you
know,
I
knew
open
source
and
I
kind
of
was
familiar
with
it.
A
bunch
of
friends
worked
at
red
hat
and
they're
like
we're
working
on
this
really
cool
thing.
A
A
You
don't
go
out
and
just
make
something
and
then
hope
people
use
it
and
you
don't
go
focus
only
on
the
customer
and
don't
think
about
how
community
can
benefit
the
customer
and
then
like
partners.
You
know
that
could
be
anybody,
but
it's
other
people
trying
to
make
stuff
that
matters
that
they
can.
A
You
know,
keep
going
for
a
long
time,
and
so
you
know
communities
are
diverse
things,
but
there's
kind
of
a
customers
and
partners
help
kind
of
anchor
that
community,
and
so
for
me
that
was
actually
really
helpful,
because
you
know
I
got
a
lot
of
stuff
to
do.
I
love
programming,
but
I
like
having
a
purpose,
and
that
was
a
really
great
purpose
to
have
so
I
enjoy
that.
You
know
it's
that
constant.
You
know
feedback
loop
between
something,
that's
awesome
that
someone
has
shared
and
a
lot
of
these
days.
A
A
lot
of
it
is,
you
know
large
companies
or
people,
an
engineering
team
at
a
large
company.
We
say
like
we
made
this.
We
want
it
to
be
useful
and
there's
a
there's.
A
lot
of
question
marks
after
well.
You
know
here's
this
open
source
stuff,
like
what
happens
if
that
company
goes
away,
what
happens
if
those
people
don't
want
to
work
on
it
anymore,
so
trying
to
figure
out
that
loop
is
has
been.
C
C
You
know
is,
is
a
lot
about
communication
between
those
groups
so
and
then
kind
of
more
specifically,
you
know
when
we're
talking
about
kubernetes
what
what
okay,
so
you
got
pulled
into
the
container
world
pretty
quickly
when
you
got
connected
to
red
hat,
what
brought
you,
because,
once
you
said
nine
years
so
like
that's
a
little
bit,
you
were
doing
a
little
bit
of
stuff
before
kubernetes
launched
what
brought
you,
what
made
you
think
kubernetes
this
thing,
this
container
thing's
got
some
legs.
Maybe
this
kubernetes
thing
does
too.
A
A
Like
you
know,
containers
existed
before
that
openshift
used.
You
know
there
are
different
parts
of
it
c
groups
and
process
containment
and
linux
and
lots
and
lots
of
stuff.
You
know
docker
kind
of
crystallized.
They
had
that.
Like
three,
you
know
pieces
you
could
download
something
which
then
we
all
download
stuff
off
the
internet
and
run
it
as
rude
on
our
systems.
That's
like
what
we
do
and
you
can
get
a
reproducible
environment
and
then
it
it
mostly
just
worked,
and
that
combination
like
that
year.
A
I
remember
like
this,
this
sense
of
like
excitement-
and
you
know
everybody
was
you
know
this
could
be
the
next.
You
know
big
thing
because
it
was.
It
was
something
that
worked
well
put
together
in
a
novel
way,
a
little
bit
like.
Maybe
like
the
first
iphone
right.
You
know
it
was
the
the
world
before
docker
and
the
world
after
docker
are
very
different,
and
so
you
know
through
that
year
you
know
we
were
on
openshift
we've
been
done
for
a
while
and
we're
like.
We
need
to
get
you
know.
A
A
I
think
brendan
and
tim
brennan
burns
and
tim
hawkins
did
a
demo
for
us
of
their
at
the
time
it
was
called
the
seven
lit,
which
is
the
with
the
the
prototype
cubelet
that
they
built
internally
at
google
and
they
showed
some
ui
we're
like.
Oh
that's
interesting,
you
know
we're
working
on
some
stuff
too.
A
You
know
tell
us
like
tell
us
if
you're
gonna
launch
this
and
we
got
a
call
like
one
weekend,
I
think
it
was
the
end
of
may
or
the
beginning
of
june,
just
before
dockercon
and
they're,
like
hey,
we're,
actually
going
to
go
through
with
this.
Are
you
guys
in
and
we
were
like
sure,
sounds
awesome
and
we
had
kind
of
been.
You
know
it
was
kind
of
one
of
those
like
fortuitous
accidents
for
us,
which
is
it
was
the
right
place
in
the
right
time
for
us
to
be
like.
A
We
think
this
is
an
awesome
idea.
We're
willing
to
do
it
in
the
open,
we're
willing
to
work,
we're
willing,
to,
I
don't
say,
throw
away,
but
we're
willing
to
throw
away
everything
that
we
did
before,
because
it
used
containers
and
even
kubernetes,
like
it
wasn't
really
about
docker
containers.
It
was
about
generic
containers
right.
It
was
about
containers
at
scale
and,
like
a
lot
of
you
know,
docker
works
great
on
your
local
laptop
and
then
that
scaling
up
factor
everybody
was
building
their
own
container
orchestration
systems.
But
this
one
felt
like
it
had
like.
A
A
We
know
some
we've
got
a
lot
of
like
experience,
so
on
openshift
we
had
a
bunch
of
experience
and
like
dev
loops
on
top
of
containers
versus
dev
loops
on
top
of
vms.
Or
what
happens
when
you
want
to
do
something?
That's
more
complex
than
a
12-factor
app
like?
How
do
you
do
a
development
or
a
software
update
loop
for
a
database?
A
So
even
from
those
early
days
like
we
were
thinking
about
you
know
we
were.
We
had
a
lot
of
compatible
world
views,
so
we
launched
they
launched
it
kubecon
I
got
or
at
dockercon
that
year
in
2014
or
I'm
getting
my
years
wrong,
but
yeah.
This
is
how
long
it's
been
at
this
point
and
we
I
was.
I
think
I
was
one
of
the
first
contributors.
A
I
got
like
the
commit
bit
on
the
repo
and
it
went
public
and
we
all
showed
up
in
slack
or
it
wasn't
even
slack
at
that
time.
I
think
it
was
pre-slack.
We
were
using
a
bunch
of.
I
think
we
decided
to
use
slack
very
early,
but
we
showed
up.
We
showed
up
in
chat
and
we
started
opening
github
issues
and
you
know
it
kind
of
snowballed.
I
mean
there
was
nothing
really
in
the
repo.
It
was
a.
It
was
a
basic
idea.
A
It
was,
you
know,
it
wrote
some
stuff
into
ncd
and
then
the
cubelet
had
this
really
janky
loop,
and
now
we
have
you
know
it
wrote
back
forth
and
we
added
an
api
layer
and
we
designed
some
apis.
We
came
up.
You
know
some
of
the
ideas
that
we
had
around
like
declarative,
config
and
being
able
to
keep
control
apply
like
those
were.
The
seeds
of
them
were
there,
but
it
took
you
know
years
to
see
them
realize
that
was
that
was
a
really
awesome
period.
C
That's
all
yeah,
I
mean
you
know,
and
I
I'm
not
sure
if
I'll
get
the
number
right,
but
I
mean
I
think
it
probably.
It
also
helped
right
that
you
know
both
red
hat
and
particularly
google
right
google
had
this
was
like
their
third
try
or
something
of
like
orchestrating
at
scale
for
their
own
internal
stuff
right.
C
It
was
kind
of
a
lot
of
what
was
maybe
it
was
even
the
fourth
try
right,
like
you
know,
and
and
one
of
the
things
that
I
think
people
particularly
who
are
new
to
software
or
are
outside
the
software
world.
Don't
realize,
is
you
know
we?
It's
actually
really
good
for
us
to
rewrite
things,
often
from
from
scratch,
because
then
we
make
we
recognize
some
of
the
choices
that
we
made
early
on.
C
That
may
not
have
been
the
best
choice,
you
know,
and
then
you
know,
because
you
know
the
thing
evolves
or
whatever
it's
been
so
nice
in
the
past.
I
don't
know
10
or
15
years
right
that
even
less
than
that
that
our
software
has
actually
gotten
so
kind
of
rebuild
quickly.
You
know
so
like
languages
like
python
and
stuff.
You
know
make
it
so
you
can
redo
things
much
more
efficiently
than
you
ever
used
to
in
the
big
waterfall.
You
know
development
models
of
the
early
2000s.
A
Well-
and
I
mean
you
know-
there's
it
was
interesting
too,
because
I
think
you
know
a
lot
of
the
googlers
brought
things
that
didn't
work
or
experiments
and
investigations,
and
you
know
in
a
bit
of
a
change
for
google.
They
were
very
willing
to
to
kind
of
share.
I
always
joked
with
brian
grant,
who
was
one
of
the
google,
architects
and
kind
of
helped.
Even
even
today,
brian
kind
of
his
twitter
is
on
the
list
of
the
top
25
and
brian
always
has
these
great.
A
You
know
insightful,
you
know,
connections
and
he
was
we
used
to
joke
that,
sometimes
on
github
issues
that
he'd
drop
a
paragraph
of
summary
about.
You
know
how
how
they
thought
about
a
particular
problem,
and
I
would
laugh
and
I'd
be
like
that's
like
10
million
dollars
of
r
d
research
and
and
your
engineering
time
and
pain
and
effort-
that's
been
nicely
summarized
into
a
single
paragraph
so
that
we
can
avoid
it.
A
So
there
was
a
lot
of
there's
a
lot
of
knowledge
sharing
and,
to
be
honest,
you
know
the
way
that
we
envisioned
cube
in
the
early
days.
I
don't
think
is
the
cube
that
we
have
now
there's
certainly
a
lot
of
areas
where
the
whatever
we
there
even
early
on
you
know
there
was
a
probably
most
cube
clusters.
C
Well,
that's,
I
think
what
we
want
to
talk
about
a
little
bit.
More
is
actually
specifically
what
you
know.
What
did
you
have
in
mind
there
like?
What
what
are
some
of
the
examples
of
you
know
the
places
where
you
see
the
biggest
change
happening
or
the
biggest
you
know
biggest
opportunities
in
a
sense
going.
You
know
in
kind
of
the
next
steps,
so.
A
And
this
is
I'll
say
this
sounds
bad.
Just
off
the
surface.
Kubernetes
has
calcified
a
bit,
which
is
when
you
have
a
big
mature
project
with
lots
of
people.
You
know
kind
of
helping
in
little
areas.
It's
not
like
when
you
have
a
small
team
right.
I
think
everybody
in
the
world
knows
like
when
you
have
a
small
team,
you
do
a
bunch
in
one
direction
and
you
kind
of
sketch
out
a
an
arc,
and
then
you
had
to
fill
in
the
details
and
you
filled
those
details
over
time.
A
So
you
you
add
fixes,
or
you
go
figure
out-
that
the
stuff
you
hacked
together
in
a
weekend.
You
know
I
have
a
pr
open
right
now
to
kubernetes,
which
is
a
really
subtle
issue
in
the
cubelet
and
all
of
the
code
that
I'm
changing.
Has
you
know
it's
five
years
old
or
more
and
it's
stuff
that
it
mostly
works?
A
But
just
as
you
know,
as
as
contributors
come
and
go,
you
know
as
we
get
busy.
So
like
folks
on
signal.
Like
there's
a
lot
of
you
know,
we
got
kind
of
got
a
second
or
third
generation
of
sick
node
contributors
going
through
now.
There's
a
lot
of,
I
won't
say:
domain
knowledge,
that's
lost,
but
you
got
to
bring
it
back
into
context
and
everybody's
busy.
So
there's
a
lot
of
layers
of
cube.
A
A
You
know
clusters
like
what
do
you
actually
want
when
you're
doing
local
iterative
development
or
when
you
want
to
test
something
locally
or
when
you
want
to
test
just
the
basics
of
an
idea
around
something?
That's
declarative
right
so
like
on
our
laptops,
we
have
git
repos
and
we
run
commands
all
day
long,
but
when
we
start
checking
things
into
source
control,
we're
trying
to
we're
trying
to
describe
the
idea
and
then
have
it.
You
know
survive
for
a
long
time.
A
It's
a
git
ops
and
like
the
idea
that
you
know
your
source
code
or
your
configuration
or
documentation
like
you,
put
them
in
source
control
and
you
can
see
their
history
and
you
can
capture
your
idea
and
even
though
you
know
the
code
and
configuration
are
kind
of
different
they're,
really
not
sometimes
they
have
external
dependencies
like
libraries
and
sometimes
they
depend
on
external
systems
or
apis.
That
might
change,
but
you
know
you've
seen
like
those
infrastructure
as
code
ideas
where
you
have
you
write
some
code
and
it
goes
and
changes
the
system.
A
There's
a
lot
of
similarities
when
you
do
that
local
development,
like
most
people
sitting
down
like
they
just
got
to
learn
a
concept
and
they
hope
it
doesn't
change
so
like
in
languages.
You
get
like
a
an
api
contract
from
your
your
language
like
go
and
the
the
go
team
tries
not
to
break
you
and
your
dependencies.
Sometimes
you
use
stuff
from
people
who
don't
really
care
about.
A
You
know
long-term
thinking,
right,
open
source
says
a
lot
of
this.
You
write
a
library,
someone
gets
bored
move
on,
they
just
burned
out
and
they
leave
it.
And
what
do
you
do
is
someone
who
consumes
that
dependency
that
api,
conversely,
like
cube,
is
designed
to
be
kind
of
flexible
and
the
most
successful
thing
about
kubernetes
beyond
just
basic
deployment.
Is
that
extensibility,
where
people
were
like
hey,
like,
I
can
add
an
api
that
api
represents.
You
know
some
idea
that
cube
doesn't
have.
A
I
can
add
to
it,
trying
to
figure
out
like
a
way-
and
this
is
kind
of
like
the
big
idea
that
I
talked
about
at
kubecon
was
apis
are
really
important,
but
you
don't
always
need
like
a
full
cube
cluster.
So
what
if
we
can
kind
of
tease
apart
the
config
and
the
defining
the
world
like
an
api
for
code,
we
have
them
all
the
time
like
docker
files
are
an
api
right
or
a
travis
yaml
file
that
you
stick
in
your
git
repo
that
tells
the
ci
system
that's
an
api.
A
Those
are
just
represented
as
config
in
your
code
and
they
define
a
process
or
whatever
so
having
something
really
small.
That
kind
of
lets
you
deal
with
a
loop
that
you
could
take
source
code
and
config
and
put
it
into
a
git
repo
and
then
have
it
show
up
on
a
local
thing
that
you
can
then
deploy
to
other
systems.
A
A
You've
got
a
definition
of
your
application
and
you
put
it
in
source
control,
and
then
you
put
it
on
one
of
those
clusters,
sometimes
you're
doing
git
ups
or
sometimes
using
a
tool
like
argo
or
sometimes
it's
something
you've
built
yourself.
In
fact,
a
lot
of
a
lot
of
big
companies,
almost
every
large
organization
running
kubernetes,
has
some
system
on
top
of
kubernetes
that
tells
kubernetes
what
to
do.
Sometimes,
that's
a
light
touch
like
it
just
makes
some
changes
deploys
your
code,
sometimes
that's
a
whole
platform.
A
That's
been
built
on
top,
that
might
be
older
than
kubernetes.
It's
been
evolved
or
adapted
or
you're
in
the
process
of
tearing
it
down.
So
we
think
of
tend
to
think
of
kubernetes
like
when
we
talk
about
it.
It's
like
it's.
This
thing
it
provides
value,
but
what's
really
important
is
all
the
stuff
around
it
that
people
use
whether
it's
the
development
side
story
or
whether
it's
the
control
story.
A
If
you
could
just
run
one
of
these
locally,
we
could
tie
it
into
other
systems,
not
just
kubernetes,
but
maybe
docker
compose
or
tying
it
into
system
d
or
if
you
hate
systemd,
you
can
tie
it
into
bash
the
idea
that
kind
of
the
the
stuff
that
you
you
create
a
deployment
in
the
service.
What
does
a
deployment
a
service
mean?
It
can
be
a
little
flexible,
so
we're
kind
of
exploring
in
this
idea
right
now,
but
it's
a
lot
of
big
ideas
and
it's
really
early.
A
So
it
doesn't
really
we're
kind
of
trying
to
get
to
that
point
where
we
can
show
a
prototype
that
feels
awesome
as
awesome
as
docker.
Did
I
don't
I
I
will
be
very
humble
and
say
I
don't
think
it's
going
to
feel
as
awesome
as
docker
did
that
first
time
that
I
used
it,
but
we're
looking
for
that.
You
know:
what's
the
what's
some
stuff,
that
kind
of
shakes
off
the
the
boringness
and
the
resiliency
of
cube
and
says
here's
some
new
ideas:
where
can
we
go
with
them.
C
So
so,
specifically
around
that,
so
it's
funny
like
systemd,
I
actually
think,
is
a
great
example,
because
I
think
systemd
in
kind
of
concept
is
a
really
good
one.
One
of
the
things
I
don't
like
about
systemd
is
that
it's
an
interface
with
an
embedded
implementation
all
the
time
and
what
I
really
wish
systemd
was
was
an
interface
and
then
had
plugable
implementations.
C
So
what
I
I'm
kind
of
curious
about
is
is
with
what
you're
describing
you
know.
Where
are
there
similarities
to
kind
of
that
systemd
id
or
even
the
linux
kernel
right
in
the
sense
that
you're
you're
looking
at
starting
to
offer
kind
of
an
api
with
almost
plugable,
implementations
or,
and
then
also
your
at
least
some
of
the
stuff?
A
You
know
like
I
think
you
could
use,
and
this
is
the
beauty
of
computers
which
is
just
really
fun
to
like,
sometimes
be
like.
I
could
use
this
to
solve
any
problem,
and
then
you
go
through
the
list
and
you're
like
which
problems?
Would
people
really
need
to
be
solved
and
which
ones
people
not
care
about?
A
I
do
like
the
idea
of
you
know
what
is
a
deployment
a
deployment's
like
it's
got
an
image
in
it
and
we've
got
some
containers
and
it
assumes
that
something
can
set
up
a
whole
bunch
of
containers
on
the
same
network
and
if
you've
got
that,
if
you've
got
something
underneath
it
that
can
do
it.
Maybe
not
every
flag
is
useful,
but,
like
you
know,
people
have
been
doing
docker,
compose
translation
to
cube
and
cube
back
to
back
or
composed
for
a
really
long
time.
A
One
of
the
things
like
thinking
about
you
know.
The
problem,
though,
is
like:
if
you
have
a
docker
image,
you
can
run
it
anywhere.
Okay.
Well,
like
what
does
that
look
like
on
a
system?
Most
people
don't
care,
they
just
want
to
see
what
the
image
runs
like.
So
you
got
to
follow
some
rules,
but
there's
a
lot
of
like
declarative
style
problems
that,
if
you
could
make
it
really
easy
to
be
like
well,
you
know
I
don't
need
a
and
going
back
to
pre-kubernetes.
A
There
was
a
lot
of
people
looking
at
system
d
at
a
large
scale,
coreos
did
fleet
and
it
was
a
system
to
unit
and
it
got
put
on
individual
machines.
A
lot
of
those
ideas
are
still
useful.
What
does
a
unit?
Look
like
it's
just
your
api,
so
like
a
unit
file
for
system
d,
and
so
we're
kind
of,
I
would
say,
making
it
really
easy
to
come
up
with
new
apis.
A
I
think
there's
a
lot
of
room
for
if
you
want
to
declaratively
control
a
whole
bunch
of
machines
like
let's
say
you're
at
the
edge,
and
you
have
tens
of
thousands
of
machines,
one
of
the
ideas
has
been
well.
I
don't
have
to
use
a
deployment
to
create
something
at
the
edge.
I
just
want
some
of
those
pieces.
You
know
I
might
want
to
say
I
want
to
run.
A
A
Maybe
my
you
know
my
special
distribute
this
to
thousands
of
machines,
whether
it's
ansible
or
something
that
kind
of
flexibility
being
able
to
do
that
alongside
the
applications
that
are
going
to
talk
to
that
edge
device
might
actually
be
useful,
and
sometimes
it
isn't
right.
Two
different
teams
have
different
life
cycles,
so
we're
kind
of
trying
to
open
the
door
to
not
just
cube,
and
I
like
to
use
the
example
here
is
like.
A
A
You
know
a
service
like
mongodb
atlas,
or
something
like
that.
You
know
the
idea
that
I
really
just
wanted
to
find
my
app
and
I
talked
to
stuff
like
sql
databases
or
nosql
databases.
I
don't
really
care
about
the
details.
Could
we
make
that
easier
as
a
loop
that
you
could
do
together,
so
you
could
deploy
both
check
them
both
in
to
get
have
a
get
apps
flow?
A
That
just
applies
them
to
a
server
that
kind
of
loop
we're
still
really
early,
but
I'd
like
to
we'd
like
to
show
those
demos
and
we
actually
are
kind
of
prototyping
towards
that
kcp
project.
We're
getting
a
lot
of
ideas
like
this.
It's
still,
this
is
still
super
early,
but
you
know
I've
heard
from
others
in
the
community
like
this
is
really
interesting.
I've
been
doing
something
like
this.
Could
we
work
together
and
that's
what
community
is
all
about?
So
that's
kind
of
where
we
are
today.
C
B
A
Feel,
like
all
of
computing
is
a
yes
and
kind
of
conversation
where
we
never
get
rid
of
anything.
We
either
reinvent
it.
We
redesign
it
or
we
just
keep
using
it.
So
I
actually
think
we're
all
very
close
to
the
same
thing.
That's
right
and
you
know
the
interesting
thing
is
we
keep
getting
better
at
all
of
it
right.
So
why
was
virtualization
invented
because
it
really
really
sucks
to
deal
with
bare
metal,
and
you
know
the
the
first
days
of
a
vm.
A
I
I
remember
the
first
day
at
work
that
I
fired
up
a
vm
and
I
was
like
well.
This
is
really
slow
and
janky,
but
I
could
see
how
this
could
be
awesome
and
it
was
a
little
bit
like
the
first
time
I
fired
up
docker
right
it.
It
gave
me
something
new
and
then,
over
the
years,
like
virtualization
matured,
you
know,
but
like
it
wasn't,
just
virtualization
got
better.
It
was
linux
changed
or
the
types
of
apps
we
wrote
for
vms
changed
or
we
developed
new
tools
that
made
dealing
with
vm.
A
Does
it
matter
whether
it's
version
you
know
and
like
this
is
apis
are
really
important.
If
the
api
works,
you
don't
really
care
what
version
it
is.
I
think
we're
getting
to
a
point
where
you
probably
want
to
not
care
what
infrastructure
it
runs
on.
You
want
it
to
run
well
in
all
of
the
places
and
if
the
open
source
community
does
its
job
right
and
that's
really
all
of
us
just
working
on
our
own
best
interests
collaboratively
that
idea
of
oh
it's
a
place,
I
can
run
apps.
A
A
You
know,
as
I
was
saying
before,
like
connect
out
to
other
services
like
I
don't
want
to
have
to
make
a
decision
about
where
my
dependencies
can
run
because
I'm
running
on
kubernetes,
I
just
want
to
use
a
dependency,
find
me
a
database
somebody's,
giving
me
that
database
in
a
dev
flow,
though
I
might
spin
up
a
really
cheap
local
copy.
How
do
we
give
that
flexibility
to
both
extremes?
That's
that's
kind
of
where
we're
going.
I
think.
B
A
A
Systemd
changed
a
lot,
but
I
think
linux
is
better
for
it.
I
certainly
did
not
grow
up.
You
know
doing
rc
init
scripts
and
you
know
in
it
and
and
every
time
I
had
to
debug
something
in
an
apache
start
script
where
I
was
like.
Why
am
I
reinventing
starting
a
linux
process
500
times
poorly,
because
I
don't
understand
bash
as
well
as
people
who've
been
doing
it
for
20
years?
A
You
know
for
all
of
like
those
flaws
is
like
you
come
and
you
take
the
system
that
underlying
system
is
still
there,
the
new
system
layers
on
top
and
it
solves
a
bunch
of
problems.
I
hope
that
somebody
comes
up
with
a
super
awesome
idea
and
that
the
cube
ecosystem
is
flexible
enough
to
be
like.
Oh
we'll,
just
integrate
that
too
or
we'll
get
integrated
too.
Like
that's,
I
think
what
makes
you
know.
Tech
awesome
is
it's
up
to
us
to
really
adapt
to
change.
C
C
You
know,
so
I
think
the
ideas
that
you're
going
to
talk
about
with
kubernetes
make
a
lot
of
sense
to
me
and
kind
of
show
like
and
getting
back
to
what
I
was
talking
about
at
the
beginning
of
the
show
kind
of
understanding
the
ethos
behind
a
tool
chain
or
whatever,
like.
I
really
do,
think
that's
one
of
the
things
about
kubernetes
right.
It's
like
you.
You
can't
really
do
anything
in
kubernetes
without
using
crds
right.
It
even
has
its
own
slang
right.
C
C
You
know
or
or
other
things
like
that.
So
I
think
that,
recognizing
you
know,
a
propensity
for
change
can
make
you
a
better
again
you're
you're
trying
to
become
more
active
in
kubernetes.
I
think
that's
a
real,
important
message
to
take
away
that
you
know
kubernetes
is
about
being
able
to
change,
and
so
you
you
make
trade-offs
to
do
that,
and
so
actually
what
I
would
kind
of
like
to
ask
is:
do
you
see
any
of
those
trade-offs
where,
where
does
it
make
it
tougher
that
it
is
so
flexible.
A
So
I
think
kubernetes,
and
I
think
this
is
a
complaint
and
it's
a
valid
criticism
of
kubernetes,
which
is
it's
just
complex
enough
to
solve
eighty
percent
of
your
problems
and
let
you
be
able
to
solve
the
twenty
percent
that
it
doesn't
solve.
Someone
a
microsoft
word
architect
made
this
comment
a
long
time
ago
of
they
found
that
everybody
uses
20
of
the
function
in
word,
but
everybody
uses
a
different
20
percent.
A
I
don't
think
cube's
quite
that
there,
but
it's
like
it's
a
complex
system,
because
the
problem
is
trying
to
solve.
Is
you
got
a
bunch
of
machines?
You
need
to
define
something
that
lets.
You
survive
any
one
of
those
machines
going
down
and
you
want
it
to
be
stable
enough
that
you
can
go
predict
it.
The
people
writing
cue
are
not
perfect
and
they're
not
magical.
A
They
can't,
you
know,
predict
exactly
how
all
these
things
would
play
out,
and
so
a
cube
is
a
reasonably
complex
system,
but
it's
probably
about
as
simple
as
it
can
get
to
represent
the
problem.
It's
trying
to
solve
that
next.
Gen,
though,
is
what's
the
simpler
ideas
that
keeps
the
core
and
toll
factor.
Apps
are
like
a
great
example:
12-factor
apps
work
until
they
don't
when
they
stop
working,
because
you
have
a
problem,
that's
more
complex.
A
You
have
to
go,
build
a
second
system
to
do
it,
and
I
think
you
know
one
of
kubernetes
successes.
Is
you?
Don't
have
to
have
a
second
system
to
run
the
vast
majority
of
software
in
the
world,
so
you,
instead
of
percent
of
apps
being
twelve
factor
and
you
gotta
go,
have
a
different
system
for
the
other
twenty
percent.
I
think
cube,
move
that
that
ratio,
which
is
cute,
can
run
ninety
seven
percent
of
applications,
and
you
can,
with
some
effort,
make
the
other
three
percent
work
or
tie
them
in.
A
What
we
have
to
be
open
to,
though,
is
what
makes
it's
more
complicated.
What
are
the
layers
on
top
that
make
it
easy,
and
the
answer
is
there's
nobody.
You
know,
there's
teams
that
do
self-service
on
top
of
kubernetes
and
there's,
and
that
worked
for
a
long
time,
but
then,
as
people
got
more
and
more
clusters,
self-service
doesn't
work.
So
that's
like
another
angle
with
like
kcp,
which
is
most
teams.
Most
individuals
in
an
organization
are
looking
for
something
to
help
them
self-service
their
development
journey.
A
That's
flexible
enough
that
they're
happy
and
when
the
infrastructure
teams
need
to
put
these
rules
in
because
they're
afraid
of
security
breaches
that
cost
the
company
hundreds
of
millions
of
dollars
or
expose
customer
info
or
result
in
like
if
you're
a
hospital-
and
you
know
hospital
applications
are
a
little
a
little
more
formalized.
But
there's
like
big,
complex
masses
of
software
that
run
our
lives.
A
You
gotta
have
some
responsibility
there
that
balance
between
a
development
team,
yoloing
it
and
an
infrastructure
team
saying
you
can't
do
anything
is
where
all
of
us
who
make
software
for
a
living
eventually
sit,
whether
it's,
whether
you
know
it
or
not,
and
so
I
think
one
of
the
things
like
maybe
not
kubernetes
sits
as
an
infrastructure
piece.
I
think
the
problem
we're
all
trying
to
solve
is
how
do
we
get?
How
do
we?
Let
people
accomplish
most
of
the
things
they
want
to
accomplish
easier
without
thinking
about
it?
A
A
I
want
to
really
focus
that
ecosystem
of
people
who
want
to
make
self-service
and
control
that
the
developers
doing
anything
they
want
and
the
pro
and
the
operations
teams
or
the
security
teams
or
the
sre
teams
or
the
cso
whose
job
is
on
the
line.
If,
if
we
get
it
wrong,
we
want
to.
We
want
to
tighten
that
and
have
like
a
really
tight
loop
between
those
two
teams
and
everybody
builds
their
own
approaches.
Today.
A
I
think
that's
the
real
opportunity,
it's
not
about
cloud,
it's
not
about
on-premise,
it's
not
about
edge
you're,
building
an
app
and
it's
got
to
run
someplace.
How
do
you
get
that
interface
right
between
the
teams?
I
think
that's.
What
kubernetes
is
a
a
first
stage
of
and
there's
plenty
of
other
projects
that
are
going
to
be
completely
unrelated
to
cube
like
terraform.
Does
this
great
ansible?
Does
this
great
get
github
through
their?
You
know
source
code
actions
as
a
part
of
this
story.
A
C
Yeah
yeah
one
of
the
things
I
actually
kind
of
regularly
use.
This
example
is,
like
you
know,
software
you
know
has
is
ridiculously
young
compared
to
most
of
the
other
kind
of
human
exercises.
Right,
like
you
know,
we've
been
doing
medicine
for
several
thousand
years
right.
You
know,
whereas
computer
science,
you
know,
even
you
know,
even
in
academia
right
is,
I
don't
know
it's
put.
C
You
know,
arguably
in
the
nearing,
maybe
80
years
old
or
something
maybe
a
hundred,
you
know,
but
that
is
a
ridiculously
short
amount
of
time
and
it's
evolving
at
a
ridiculous
pace.
Right,
and
so
I
I
regularly
talk
about
it's
funny,
because
we're
still
trying
to
solve
that
same
problem
of
when
I
you
know
was
first
starting
new
development.
You
know
I
would
yell
down
the
hall
to
the
guy
who
was
running
the
the
server
room
and
be
like
okay.
C
What
version
of
php
can
I
use
right,
because,
because
that
guy
is
the
one
who's
going
to
have
to
operate
it
right?
And
so
I
would
never
build
anything
without
knowing
that
I
can
actually
put
it
into
production
and
I
think
in
some
ways
we're
trying
to
not
formalize
but
we're
trying
to
make
that
communication
scale,
because
now
it's
not
just
me
and
the
one
guy
down
the
hall
with
one
server
right,
we're
talking
global
we're
talking.
C
You
know
thousand
person,
development
teams,
we're
talking
thousand
person,
sre
teams,
plus
sysadmins
plus,
you
know
a
database
submit.
You
know
like
all
these
people
involved
now,
so
we're
trying
to
articulate
that
same
conversation
in
a
way
that
is
flexible
enough.
That
we
can,
you
know,
actually
have
all
of
the
conversations.
A
Well,
and
not
just
flexible
enough,
but
explainable
right
like
we
talked
about
an
ai
explainable,
there's
so
much
power
available
in
modern
infrastructure,
whether
it's
a
cloud
service
or
what
you
can
do
locally
is
that
one
person
can
spend
10
million
dollars.
You
know,
as
someone
made
a
joke
the
other
day,
I
I
thought
it
was
awesome,
which
is
one
person
can
spend
10
million
dollars
in
a
day
if
they
have
the
right
controls
or
the
right
quotas
on
a
cloud
that
power.
A
A
How
do
we
know
what
you're
spending
the
money
on
and
what,
if
you
have
hundreds
of
people
in
different
places,
spending
you
know
building
stuff,
you
don't
want
to
stop
them
from
building
stuff,
because
the
goal
for
most
organizations
most
engineers
most
teams
is,
I
just
want
to
get
this
one
thing
going,
and
then
I
wanted
to
keep
working
forever,
even
though
we
would
say
like.
Oh
of
course,
we're
going
to
do
tests
and
ci
and
we'll
have
a
you
know,
rigorous
release
cycle
and
the
reality
is
it's
like
99
of
it
is
like.
A
A
How
do
we
build
those
kind
of
layers
of
of
interface,
which
is
like
yep,
I'm
building
my
app
I'm
done.
Somebody
else
can
use
that
interface
productively
and
I
think
we're
kind
of
we
were
like
bracketing
down
right.
We
had
12
factor.
You
know.
Paths
was
a
little
too
a
little
too
too
far
up
yeah
too
far
up
the
stack
and
we
had
virtualization
and
kubernetes,
and
you
know
different
types
of
things
that
integrate
with
terraform,
like
you
can
do
amazing
things
with
terraform
and
ansible,
like
you
know,
deploy
huge
fleets.
A
I
gotta
admit
some
days,
I'm
like
I
don't
really
want
to,
because
each
of
those
little
bits
are
designed
by
an
individual.
They
take
somebody
else's
api
and
they
make
their
own
api
on
top
of
it,
I'm
not
depending
on
the
cloud
provider
not
to
change
their
api,
I'm
depending
on
the
open
source
volunteer
who,
out
of
their
time,
built
the
interface
between
you
know
this
representation
of
an
api
provided
by
a
cloud
provider.
A
A
You
know,
I
can
just
say,
like
here's,
99.99
of
all
apps
that
you'll
ever
need
to
build,
go
run
them
on
whatever
infrastructure,
I'm
not
going
to
think
about
it
anymore
and
we're
getting
close.
I
mean
I
don't
you
know
in
the
next.
Like
five
ten
years
I
mean
a
lot
of
we've
learned
a
lot
like
when
I
started.
We
were
talking
about
infrastructure
as
code
or
sorry
when
I
started
talking
about
infrastructure
as
an
api
or
api
driven
infrastructure.
Nobody
talks
about
that.
Now
they
talk
about
declarative,
config
or
declarative
infrastructure
or
infrastructure.
A
As
code
we
take
it
for
granted.
I
think
another
10
years,
where
we're
much
further
down
that
scale
of
there's,
probably
a
standardized
way
to
deploy
every
application
you
ever
need.
Someone
adds
a
new
one.
You
don't
have
to
change
your
tooling,
you
just
add
a
new
api
right
and
that's,
I
think,
where
I
want
kcp
and
cube
and
things
that
you
know
that
we
work
on
to
how
do
we
help
people
bridge
that
layer.
C
You
can
write
code.
That
does
it
that
you
can
actually
just
drop
your
key
in
there
and
publish
it
by
accident
because
you
can
just
automate
the
whole
thing
so
cautionary
tear
don't
do
that.
But
on
the
flip
side,
I
think
it's
really
impressive,
that
we've
come
so
far
along
that
I
don't
reference
it
on
a
piece
of
paper
anymore
right.
I
just
embed
it
somewhere
and
magic
happens.
You
know,
and
it
really
it
it
feels
especially
to
anybody.
Who's
ever
had
to
swap
a
hard
drive
in
a
server.
C
C
A
C
C
I'll
give
that
back
to
you
right,
we
should
we
should
at
the
beginning
of
this,
of
the
show.
You
know
what
it's
going
to
be
every
month.
We
can
just
actually
pause
for
a
second
and
tell
people.
This
is
a
good
time
to
do.
Your
open
shift
upgrade
watch
the
show
and
it'll
be
done
when
the
show's
over
or
thereabouts
yeah.
C
There
you
go,
we
could
segway
it'd
be
like
getting
a
cup
of
coffee
except
even
better,
so
so
clayton
thanks
so
much
for
coming.
We
really
appreciate
you
putting
up
with
a
little
bit
of
you
know,
noisiness
with
our
our
first
kind
of
production
episode.
You
know,
do
keep
in
mind.
We
did
do
a
behind-the-scenes
kind
of.
Why
are
we
doing
this?
C
Show
episode
with
a
couple
of
people
who
are
more
in
the
background,
and
you
know
you
should
go
watch
that
on
kubernetes
by
example,
I
think
we
put
in
the
link
earlier
and
then
obviously,
if
you
weren't
able
to
catch
this
whole
show
it
will
be
on
the
youtubes.
You
know
in
perpetuity,
or
at
least
as
long
as
google's
around
so
you
know,
please
go
check
it
out
there
we'll
be
back
again.
Our
cadence
is
gonna,
be
the
last
tuesday
of
the
month.
C
B
C
So
we'll
be
back
and
between
now
and
then
we
will
announce
who
our
next
guest
will
be,
and
it
will
be
another
insider
from
inside
the
kubernetes
world.
But
again
thanks
so
much
for
coming.
Thank
you
to
the
audience
for
showing
up
and
we
had
a
couple
questions.
We
appreciate
it
and
we'll
see
you
next
time.