►
Description
Container orchestration in Kubernetes is so popular today but it can be difficult to know whether container orchestration is right for you. These are just some of the questions and topics we get into today.
For the show notes and transcript: https://thepodlets.io/episodes/002-container-orchestration/
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Hosts
https://twitter.com/carlisia
https://twitter.com/joshrosso
https://twitter.com/apinick
B
C
A
And
I've
been
traveling
a
lot,
but
it's
been
good.
We're
doing
a
lot
of
interesting
work
with
some
some
cupertino,
these
clusters
running
and
an
on-premise
data
center,
which
is
something
we
see
less
and
less.
No.
The
cloud
providers
are
kind
of
taking
on
their
different
offerings,
so
it's
cool
to
cool,
to
hop
back
to
kind
of
the
bare
metal
and
virtualization
space
and
play
around
there.
Oh
that's.
B
Cool,
so
I've
actually
got
a
question
for
you
guys
kind
of
irrespective
of
container
registration.
But
how
do
you
guys
manage
travel
right
like?
How
do
you
keep
yourself
entertained?
How
do
you
keep
yourself
happy
while
you're
traveling?
For
me,
it's
a
lot
of
podcast,
which
is
great
now
that
I'm
doing
a
podcast
yeah.
C
A
Sleep
is
always
the
first
goal,
but
I
also
signed
up
for
your
YouTube
premium
and
the
offline
feature
is
fantastic,
so
there's
so
much
good
info
on
YouTube.
You
know
it's
great
to
like
go
to
the
cube
con
playlist
and
just
choose
offline
offline
offline,
and
then
you
have
all
that
time
on
the
plane
to
really
sift
through
talks
and
whatnot.
So
it's
been
really
really
cool.
C
B
C
C
A
B
So
this
week
on
the
podcast
we
are
talking
about
container
orchestration
and
kind
of
what
that
is
right
for
me,
like
container
orchestration,
is
the
idea
that
you
need
your
workloads
to
run
somewhere,
but
you
don't
necessarily
need
like
need
to
care
where
they're
running
and
the
way
that
this
has
been
done
traditionally
like
prior
to
container
registration
was
like
scheduling,
VMs
or
making
sure
these
processes
run
on
certain
computers
right.
There's
a
lot
of
automation
around
that
with
like
contain
20
containers
came
around.
We
needed
some
way
to.
B
You
know,
make
sure
that
they're
running,
and
it
also
enabled
us
to
not
need
to
care.
So
much
about
like
how
things
get
started.
All
that
everything
was
kind
of
packaged
in
a
container
was
container
ID
right,
and
so
they
need
to
just
be
some
way
to
run
them,
and
so
that's
kind
of
a
container
registration
came
in
is
that
kind
of
your
guys's?
Your
take
on
that
as
well.
Yeah.
C
I,
have
this
container
here
and
I'm
going
to
declare
that
if
he
fails
I
want
it
to
come
back
up
and
this
container
over
there?
If
it
fails,
just
keep
keep
that
States.
Don't
don't
do
anything
and
then
I
might
say:
hey
I
want
two
of
you.
Three
of
you,
I
want
to
the
orchestration
part
is
really
just
dictating
behavior
in
States.
B
A
A
B
B
So
very
controlled
process
like
initiation
based
on
these
instructions
and
that's
kind
of
all
the
container
is
a
lot
of
people.
Think
that
they're,
like
kind
of
like
a
VM
I've,
heard
that
a
few
times
where
I
go,
how
do
I
deploy
it
like?
What's
the
you
know,
the
kind
of
the
VMDK
for
a
container
and
it's
I
go
we
it's
just
a
process
that
runs
on
a
computer
in
a
very
controlled
fashion.
That's
literally,
it.
C
I,
so
frankly,
I
don't
remember
me:
it's
been
nice
for
my
first
time,
seeing
a
container,
it's
been
a
long
time,
but
I
don't
remember,
but
probably
maybe
trying
to
do
some
application
like
some
toy
application.
That
are
an
example,
application
and
I.
Remember
that
I
was
working
on
the
application
that
we
had
the
option
to
stuff
into
a
container
as
well,
but
I
I
personally
do
not
develop
the
development.
C
So
like
really
sometimes
well,
not
sometimes
he
has
kernel
level
applications
in
systems
and
he
has
API
level
system
and
for
our
the
for
you
to
develop
one
part
of
it
is
it
was
really
handy
to
be
able
to
start
all
of
these
different
systems
into
containers
and
have
containers
talk
to
each
other
and
we
weren't
using
the
in
production.
This
was
for
development,
but
it
was
amazing.
It
was
fantastic.
C
We
would
have
applications
developed
in
go
different
systems
that
needed
to
talk
to
each
other
and
we
would
have
applications
in
C
and
O
and
things
that
I
remember.
But
it
was
amazing,
so
everything
in
containers
and
then
we
had
a
tool
as
well.
There
was
sorta
like
kubernetes,
he
wasn't,
kubernetes
was
a.
It
was
developed
in-house.
They
were
castrated
all
of
these
things
and
you
know
if
something
fails,
bring
it
back
up
and
did
a
bunch
of
other
things
as
well.
Yeah
I
cannot
explain
the
difference
of
working
like
that.
C
B
That's
a
processing
unit
right
there
they're
kind
of
similar,
but
once
you
start
really
getting
into
the
key
use
of
it
it's
so
it
was
so
much
different,
so,
like
I
had
heard
like
during
this
process
of
switching
over
to
these
two
tools,
I
had
heard
of
docker
and
I
was
like
that's
something.
I'll
take
a
look
at
and
finally
like
by
shifting
over
Doven
shipped
I/o
I.
B
Finally
was
starting
to
like
oh,
this
is
what
docker
is.
This
is
how
we
use
these
and
then
like
kind
of
digging
into
containers
there,
and
so
it
was
an
interesting
switch
from
an
infrastructure
standpoint
to
like.
Oh,
this
is
how
we
people
use
containers
and
then
I
kind
of
actually
started
getting
me
into
development.
It
was
like
now
that
I
didn't
have
to
care
about
all
this,
like
overhead
of
like,
where
do
I
put
my
application.
A
My
experience
wasn't
too
dissimilar.
What
was
interesting
is
the
space
I
was
working
in
was
a
lot
of
legacy,
Java
applications,
so
we
kind
of
came
to
containers,
probably
a
little
bit
later
than
what
some
of
you
all
did
and
what
was
always
interesting
about
it
is.
You
know
we
started
to
really
see
the
value
of
containers.
Just
like
Carly
sue
was
saying.
A
We
started
packaging,
these
apps
up
and
they
ran
the
same
in
every
environment
and
and
just
really
changed
our
workflow
around
and
initially
it
was
just
like,
let's
figure
out
a
way
to
simply
start
these
containers
on
different
hosts.
So
you
know
whether
it
be
like
ansible
or
even
someone
going
on
a
host
and
typing
docker
run.
You
know
that
was
how
he
got
these
processes
to
start
and
as
the
adoption
of
containers
grew
and
grew,
and
more
and
more
containers
started
to
come
to
life
in
this
company.
A
The
need
for
orchestration
finally
became
obvious
right,
because
I
hadn't
heard
about
like
this
project
called
kubernetes
I'd
heard
a
bit
about
swarm,
maysa
and
was
always
just
like
I.
Don't
understand
why
you'd
ever
need
something.
This
complex
right,
but
eventually
you
hit
this
like
inflection
point
R.
It
just
becomes
insanely
obvious
that
your
life
is
potentially
going
to
be
just
chaos
without
something
that
can
actually
figure
out
hey.
You
need
to
run
this
container.
A
Let
me
figure
out
where
to
put
it
and
make
sure
that
it
starts
and
I
thought
that
was
like
a
really
interesting
progression
and
it
used
to
be
really
hard
also
to
navigate
the
options,
because
there
were
a
lot
of
options
and
there
still
are
there's
there's
swarm,
kubernetes,
openshift,
meso,
so
on
and
so
forth.
Yeah.
B
B
But
how
do
I
do
this
at
scale
even
like
remotely
at
scale,
and
so
every
like
a
bunch
of
people
started
doing
their
own
thing,
so
there's
kubernetes,
which
is
the
open
source
version
of
borg,
with
some
changes
to
make
it
more
friendly
for
other
people,
there's
docker,
docker,
swarm
and
then
maysa
Rancher,
but
then
curly
see
your
your
team
was
doing.
They
had
their
own
Orchestra.
A
lot
of
other
companies
have
their
own
orchestration
as
well.
B
So
it's
not
just
you
don't
need
like
this
project
to
do
or
any
of
these
projects
to
do
container
appreciation.
You
can
do
it
on
your
own.
If
you
need
to
right
so
like
if
we,
for
example,
we
could
take
a
look
at
uber,
they
aren't
using
a
project,
they've
they've
rolled
their
own
container,
orchestration
at
scale
and
I.
Think
that's
insane,
like
that's
crazy.
You
see
to
me,
but
that's
awesome
for
them
to
pull
that
off
right.
C
Our
construction
is
going
to
manage
that
for
me
ensure
that
the
service
come
up
they're
up
and
now
this
can
get
these
set
gets
kicked
off
and
that,
if
I,
if
I,
don't
need
to
scale,
I
still
need
to
do
this
right.
There
is
usually
some
sort
of
dependency
and
then
of
the
scaling
part,
which
is
also
I,
mean
it's
important
from
for
a
lot
of
companies.
But
it's
not
important
for
a
lot
of
companies.
Smaller
sized
companies
right
mm-hmm,.
A
So
I
guess
it
seems
like
the
common
approach
that
we've
run
into
at
least
with
kubernetes
and
I.
Think
it's
true
for
a
lot
of
these
different
systems
is
the
notion
of
reconciling
state
right.
So
we
start
off
kind
of
with
a
declarative
definition.
If
you
will
of
what
we
want
the
world
to
look
like,
and
that
could
be
some
app
running
with
some
amount
of
replicas
when
you
want
it
to
be.
A
You
know,
have
a
certain
amount
of
CPU
and
memory
available,
and
then
these
orchestrators
usually
can
just
take
that
declarative,
notion
and
and
sort
of
act
on
it
right
and
I
know
Nicolas
you're
really
close
to
kubernetes.
Would
you
want
to
speak
to
like
how
exactly
it
acts
on
those
things
like
when
you
give
it
that
declarative
API
object
like
what
its
gonna
do
behind
the
scenes?
Yeah.
B
So
in
kubernetes
there's
a
couple
different
systems
that
play,
and
this
is
something
that
I
find
really
fascinating,
there's
a
lot
of
reconciliation
loops
in
many
different
places,
and
so
in
Krita
Nettie's.
When
you
first,
you
know
declare
to
kubernetes
that
you
want
something
to
happen.
You
talk
to
the
api
server
and
the
api
server.
Then
modifies
the
SED
datastore
right,
so
the
dead
city
datastore
is
just
a
very
simple
key
value
pair
brain.
It's
like
the
brain
of
your
kubernetes
right
and
so
only
the
API
server.
C
B
Good
I
was
like
I
was
suddenly
second-guessing,
guys.
Oh
so
the
API
server
directly
communicates
the
city.
Several
makes
the
changes.
Then
the
controller
manager
is
in
a
reconciliation,
loop
saying
like
okay,
here's
what
I
think
the
world
looks
like
and
if
the
world
changes
based
on
like
the
what
Exedy
saying
so
like
the
controller
manager
maintains
actual
state
and
EDD
controls
expected
States.
B
If
any
of
them
are,
you
know
different,
it
will
then
kick
off
something
to
the
scheduler,
which
will
then
inform
the
various
nodes
in
the
cluster.
What
changes
they
need
to
do
to
reconcile
state,
and
so
then
those
changes
occur.
Controller
manager
sees
that
actual
state
matches
expected,
say
and
everyone's
fat
dumb
and
happy.
C
C
C
C
B
B
I
I,
actually,
to
be
honest,
I,
don't
really
know
much
of
the
difference
between
like
rancher,
lab
mesosphere
and
doctor
swarm
I
believe
that
they
all
act
very
similarly
to
kubernetes,
but
in
slightly
different
way,
and
this
is
something
that
I
meant
to
take
a
look
at
before
talking
about
it.
But
I
I
just
ran
out
of
time.
I'll
be
honest,
I
guess.
B
This
is
a
big
topic,
will
definitely
have
to
come
back
and
kind
of
launch
on
this,
a
bit
more,
but
I
I
think
they're
all
orchestration
on
all
these
orchestrators
work
in
the
same
function,
right,
they're,
the
same
fashion,
there's
what
you
want
to
happen.
What
actually
exists?
How
do
we
get
that
change
to
occur
right.
A
Yeah,
exactly
and
I
think
the
the
one
thing
to
add
to
is
these
systems
are
generally
making
like
really
informed
decisions
when
trying
to
reconcile
a
desired
state
right
and
by
really
informed
decisions.
I
mean
they're,
obviously
aware
of
a
lot
about
the
compute
resources
available
to
them,
so
one
big
benefit
adopting
container
registration
gives
you
is
things
like
the
scheduler
are
able
to
look
into
the
system
and
understand
you
know:
hey
based
on
resources
I
have
available
in
this
area.
A
The
idea
of
ensuring
that
we
can,
you
know,
know
the
resources
of
container
needs
and
then
pack
them
together
really
tightly
so
that
we're
utilizing
the
potential
hardware
or
cloud
resources
that
we're
paying
for
every
month.
So
a
lot
of
times
the
adoption
of
container
orchestration.
Is
this
really
elegant
way
to
move
our
workloads
around,
but
at
the
same
time
it's
a
way
to
really
utilize
the
things
we're
paying
for
and
potentially
cut
costs
over
time
as
well.
Yeah.
C
This
is
one
thing
that
I
find
fascinating
with
Alice
Kober.
Ladies
because
I
haven't
used
the
other
orchestrators
we
can
put
up,
let's
say
four
machines
and
four
instances
of
a
machine
and
deploy
kubernetes
on
it
and
say
in
south
copper:
Nettie's
I
want
these
men,
you
know
this
many
pipes
and
they
have
these
container
with
apps.
Obviously,
you
more
services
running
containers
and
I
don't
need
to
specify
even
where
anything
is
going
to
go.
It
just
spreads
the
loads
and
keeps
managing
and
monitoring
and
managing
what
needs
to
go
where
to
better
utilize.
B
And
I
think
that's
actually
an
important
distinction
between
the
different
container
orchestrators
that
exists
out
there.
If
I
recall
correctly,
I
believe
that
mesosphere
has
a
mechanism
that
can
kind
of
better
load-balanced
your
applicator,
you
containers
that
are
running
in
the
cluster,
at
least
better
than
the
way
it
can
make
a
kind
of
a
more
informed
decision.
B
Unlike
the
state
of
the
cluster
and
where
to
place
things
then
kubernetes
does,
and
that
might
be
one
of
like
the
key
differences
between
the
two
and
that's
something
that
I
hear
a
lot
in
the
kubernetes
community,
someone's
like
oh
well,
I
noticed
that
all
of
my
resources
are
kind
of
being
put
onto
one
computer
and
then
the
rest
of
them
aren't
even
being
utilized
at
all
like
what's
up
with
that
and
I
think
that's
important,
there's
something
that
is
important
to
understand,
which
is
the
bin
packing.
That
Joshua
was
talking
about.
B
B
It's
important
to
know
that
from
it,
the
capacity
of
like
at
least
in
kubernetes
and
like
most
of
these
orchestrators.
If
there
are
resources
to
be
utilized
it,
the
orchestrator
doesn't
care
for
the
most
part
like
mesosphere,
has
the
ability
to
kind
of
like
low
bounce,
as
I
said,
but
as
long
as
the
resources
that
are
available
on
one
computer
are
the
same
as
any
other
computer.
C
So
what
happens?
What
is
the
orchestrator
do
when
let's
say
you
have
four
instances
and
I
have
I,
have
what
I
have
stuffed
a
bunch
of
containers
in
there
and
I'm
thinking?
Well,
those
four
instances
will
give
me
plenty
of
memory,
but
I
have
a
leaky,
app
and
all
of
a
sudden,
my
rainbows
at
what
happens
so.
B
Sorry,
I'm
gonna
take
this
one.
This
actually
ties
in
to
why
I
love
container
registrations
from
a
cloud
native
perspective
and
that
this
is
kind
of
where
cloud
container
orchestration
is
cloud
native.
It
takes
in
account
the
elastic
nature
of
your
resources.
So
if
you
have
this
application,
that's
blowing
up
either
you
can
have
the
limits
and
limits
to
how
many
resources
the
application
can
utilize
or
you
can
use
auto-scaling.
B
So
we
have
in
urban
areas.
We
have
the
something
called
horizontal
pot
out
of
scaling
and
in
some
of
the
other
tools,
I'm
sure
they
have
the
same.
But
the
idea
is
like
as
you're
using
more
and
more
resources
in
the
pot.
It's
taking
up
this
much
memory.
It
then
needs
to
create
a
new
pod
right
and
so
or
a
new
container
right.
So
a
new
container
needs
to
get
orchestrated
and
then
another
one
another
one
another
one.
B
Now,
if
you
have
a
really
aggressive
application,
that's
acting
kind
of
maliciously,
that's
not
great,
because
that'll
take
up
all
the
resources
in
your
cluster
and
that's
not
good.
But
if
you,
if
you
just
have
a
very
like
spiky
application,
it
can
grow
with
its
needs
and
then
come
back
down
and
no
one
has
to
know
about
it.
Essentially
you're
your
Orchestrator
can
make
that
happen,
for
you
I
think
that's
really
cool
it.
C
A
Yeah,
the
nice
thing
is,
we
can,
in
most
of
these
orchestrators,
set
some
type
of
parameter
around
potential
cpu
that
we
want
to
make
available
and
memory
you
want
to
make
available
for
the
app
and
what's
nice
about.
This
is
at
least
speaking
to
kubernetes,
I'm
sure
it's
similar
for
others,
just
using
kind
of
some
of
the
underlying
technologies
that
already
existed
in
limited
linux,
like
nicholas,
had
mentioned
cgroups
we
have
the
ability
when
cpu
gets.
A
You
know
too
high
to
potentially
throttle
it
and
kind
of
slow
it
down,
or
at
least
limit
the
amount
of
CPU
it
can
use
in
given
cycles
and
with
memory.
If
we
start
kind
of
over
committing,
we
even
have
the
ability
to
potentially
kill
the
application
if
it's
starting
to
take
up
more
memory
than
it
actually
should
be
allowed
to
to
take
up
and
what's
what's
kind
of
interesting
about
kubernetes
and
in
other
orchestrators
is
they're
kind
of
self-healing
model.
A
Is
that
sometimes,
when
apps
are
doing
really
bad
things
like
leaking
memory
all
over
the
place,
you
might
not
detect
it
right
away
right,
cuz,
it's
actually
gonna
potentially
limit
or
kill
the
app
and
self-heal
it
by
bringing
it
back
up.
So
it
might
seem
like
your
app
is
still
online,
and
you
didn't
necessarily
realize
that
under
the
hood,
kubernetes
was
actually
restarting
it
and
trying
to
continually
bring
it
to
to
a
state
of
health
right.
So
you
have
a
you,
have
a
lot
of
abilities.
A
It's
like
everything
that
Nikolas
just
said
about
reading
how
much
information
or
resource
the
app
is
taking
and
potentially
scaling
based
on
that
or
even
setting
like
hard
limits
to
say,
I
want
to
throttle
my
app
or
even
potentially
kill
my
app
if
it
starts
to
act
badly
and
use
up
more
than
it
should.
So,
it's
a
really
cool
kind
of
declarative
way
to
approach
resource,
limiting.
C
B
No,
no,
it's
okay
and
that's
actually
something
that
I,
don't
think
a
lot
of
people,
including
myself,
work
on
that
much
is
the
throttling
aspect
right.
Most
people
are
like
okay,
well,
whatever
just
take
up
as
many
resources
as
we
need.
That's
what
it's
there
for,
but
maybe
you
shouldn't
always
be
doing
that
not
every
application
needs
to
expand
horizontally
or
vertically.
If
it's
a
saiful
set,
it
could
be
that
the
application
is
acting
poorly
and
you
need
to
be
like.
No,
you
actually
don't
need
that
many
resources
so.
C
B
B
But
if
you
have
observation-
and
you
have
monitoring
going
on-
you
can
see
like
oh
hey,
this
pod
is
like
restarting
every
20
minutes
like
that
it
shouldn't
it
doesn't
need
to
restart
every
20
minutes
like
clearly
the
application
is
running.
So
that's
not
a
bad
thing,
but
maybe
we
should
fix
that
right.
So
you
can
become
aware
of
what's
going
on
right
and.
C
B
Yeah,
that's
correct,
because
kubernetes
and
like
any
of
these
other
word,
shaders
are
doing
what
they
should
be
doing,
which
is
being
the
best
Orchestrator
they
could
having
like
that
package.
Now
that
you're
getting
into
something
that's
more
of
like
a
product
and
there's
something
wrong
with
products,
but
that's
not
what
these
projects
are
here
to
be
right.
How.
A
I
will
I'll
start
and
then
I
actually
think
Nicolas.
You
might
be
the
best
one
to
speak
to
this,
with
your
background
and
openshift,
quite
frankly
right.
So
it's
kind
of
like
these
orchestrators
are
a
primitive
in
a
way
for
how
we
eventually
build
a
platform,
and
that
platform
is
a
larger
thing
that
includes
potential
monitoring,
maybe
plugins,
to
continuous
integration
and
continuous
delivery
and
there's
a
lot
of
groups
or
companies
that
have
kind
of
that
whole
story,
or
at
least
parts
that
story
packaged
up
together.
A
C
B
C
But
your
your
description
is
the
descriptions.
Youtube
gave
are
very
valid,
it's
very
valid
because
a
project
by
itself
might
not
have
enough
value
for
let's
say
companies
and
bundling
they
probably
this
project
that
products
project
and
the
other
projects
which
ultimately
you're
building
a
product
with
a
purpose
right.
You
have
a
purpose
for
that
product
to
handle
a
specific
audience
for
that
product
set
of
users,
and
so
it's
very
distinct
from
taking
one
part
of
that
product
in
calling
it
a
product,
because
maybe
it's
not
enough
to
address
from
self
problems.
Mmm-Hmm.
A
Yeah
I
think
that's
like
an
important
distinction.
It's
almost
like
what
Nikolas
and
I
were
talking
about
was
more
about
the
distinction
between
what
an
Orchestrator
is
and
what
a
full
platform
would
be
right
and
I.
Think
Carly
CEA's
point
about
like
how
we
plug
in
the
monitoring
and
stuff
is
really
important,
because
you
know
just
like
we
were
talking
about
with
the
the
cloud
native
landscape
and
our
last
podcast,
like
kubernetes,
is
just
one
piece
of
the
overall
puzzle.
Kubernetes,
isn't
your
whole
platform
start
to
finish
right.
A
B
Very
nicely
put
so
I've
got
a
question
for
you,
guys
we've
kind
of
been
beating
around
the
bush
as
a
word,
but
it
to
me
it
seems
apparent
that
in
the
world
of
container
orchestration,
kubernetes
has
come
out
on
top.
It
isn't
to
say
that
it's
the
the
end
right
there
are.
There
could
be
something
you
know
that
comes
out
that
actually
beats
kubernetes
right,
but
for
now
it
seems
like
everyone
is
looking
at
kubernetes
and
I'm
kind
of
curious.
Why?
A
C
Can't
say
that
I
was
paying
attention
and
monitoring
that
space,
so
I
don't
know.
Of
course,
I
can
make
guesses,
but
Josh
just
said.
It
sounds
very
plausible.
You
know
that
he
had
Google
behind
it.
I'm
shorten
hurt
its
what
it
means.
It's
not
that
Google
is
not
that
we
need
to
be
fanboys
and
fangirls
of
Google,
but
by
having
a
company
like
that
sponsor
and
put
resources
behind
the
project,
they
also
gives
a
signal
down.
C
A
B
Yeah
absolutely
and
I
I
agree
with
actually
both
of
your
viewpoints,
its
corporate
sponsorship,
not
just
Google
I'm
gonna,
get
to
this
in
a
second
and
the
community
as
well,
and
also
some
of
the
functionality,
but
it
was
both
the
corporate
sponsorship
of
Google
and
Red
Hat
in
the
early
days
and
not
to
like
tout
my
old.
You
know
oh
yeah,
we
did
it,
but
it
was
Red.
Hat
had
a
big
play
in
too
early
kubernetes
as
a
supporter,
and
so
what
that
kind
of
did
was
established.
B
Hey
kubernetes
is
at
least
enterprise
an
enterprise
perspective
project
right,
it's
not
just
hey.
This
is
some
open
source
project.
It
may
or
may
not
work
if
it
if
it
doesn't
you're
kind
of
on
your
own.
If
you
had
a
company
like
Google
and
Red
Hat,
who
are
both
endorsing
this
project,
suddenly
enterprises
were
more
interested
in
taking
it
on
board.
Yeah.
C
C
B
So
for
perspective,
openshift
three
zero
zero,
which
is
when
I
start
first
started
getting
into.
It,
is
based
on
kubernetes
one
two,
which
is
pretty
early,
and
they
were
big
like
put
a
lot
of
resources
into
the
development
of
the
community
and
for
the
development
of
the
functionality
that
exists
right.
The
horizontal
pot
out
of
scale
that
we
still
use
a
today
to
do
today,
too,
is
due
in
a
large
part,
to
the
contributions
of
Red
Hat
right.
B
The
engineering
at
Red
Hat
is
kind
of
responsible
for
that
piece
right
and,
among
other
things,
right
and
so
with
them
at
play,
kind
of
getting
their
community
and
Google's
community
coming
together
and
then
able
to
organize
this
community.
That
I
think
is
a
big
piece
of
like
what
took
this
off
right
or
what
allowed
communities
to
take
off.
That's
how
grammar
works.
B
There's
also
some
pieces
of
like
functionality
that
I
think
were
kind
of
novel
to
kubernetes
in
the
early
days,
things
like
ingress
and
then
the
way
the
way
the
cubelet
worked
was
actually
kind
of
unique,
like
that.
How
just
low-level
the
commands
that
were
being
issued
by
the
cubelet
were
pretty
unique,
and
so
it
allowed
for
people
to
adopt
it
like
it.
The
things
that
were
happening
from
the
Cuba
perspective,
like
changes
to
your
IP
tables,
running
a
container
like
changing
the
cgroups
and
all
these
things.
Those
are
all
well-known
by
people
at
the
time.
B
So
there
wasn't
anything
like
arcane
happening.
It
was
just
hey
this.
This
process
just
blends
these
commands
and
that's
how
it
reconciles
state
right
and
so
I
think
that
that
kind
of
functionality
really
got
people
to
trust
what
was
happening,
and
so
you
know
it's
like
I.
Think.
The
trust,
trust
and
transparency
are
like
the
big
things
that
people
kind
of
keyed
into,
like
the
trust,
comes
from
the
enterprise
sponsorship
and
also
the
fact
that
what
was
happening
from
a
rudimentary
standpoint
was
pretty
simple,
and
so
people
could
wrap
their
heads
around
it.
B
A
I
think
that
piece
is
super-important,
like
you
know,
Nicholas
and
I.
We
came
from
Carla,
so
our
lineage
around,
like
open
source
kubernetes,
is
not
too
dissimilar
and
we
spent
a
lot
of
time
working
with
customers
in
pure
upstream
open
sore
kubernetes
and
actually
taking
some
of
their
issues
and
requirements
to
the
community
and
then
helping
shape
the
direction
of
kubernetes
in
micro
kind
of
ways.
A
You
know,
but
still
important
ways
to
that
company
and
I
think
companies
seeing
through
you
know
the
CN
CF
and
seeing
through
just
community
leadership
and
involvement
that
the
things
that
they
care
about
aren't
just
going
through
a
single
vendor
to
make
a
decision
as
to
whether
that
thing
should
be
included
but
is
being
part
of
a
larger
community.
Discussion
breeds
a
lot
of
confidence
in
this
project
in
the
long
term.
C
B
C
What
about
we
talk
all
the
time
and
every
people
who
are
in
this
area.
We
talk
about
all
the
time,
how
everybody
knows
kubernetes
and
but
I
want
to
challenge
you
to
to
say.
Do
you
think
that
everybody
knows
kubernetes?
Everybody
knows
the
purpose
of
carbonate
is
everybody
knows
if
they
should
be
using
kubernetes
are
not
like
people.
C
How
are
people
able
to
make
an
informed
decision
if
they
are
should
be
using
copper
dailies
because
I,
don't
think
everybody?
Everybody
knows,
I,
think
the
majority
of
companies
in
terms
of
in
terms
of
volume,
because
smaller
companies
I
think
I
would
guess
they
outnumber
the
bigger
companies
and
technologists
I
think
there
are
a
lot
of
people
not
clear
on
what
is
this?
That's?
Why
we?
Why
you're
here?
But
what
do
we
tell
them
like?
B
B
B
Absolutely
and
that's
something
we
actually
run
into
a
lot
in
the
field
is
when
we're
engaging
with
with
our
customers.
A
part
of
our
job
is
to
help
containerize
their
applications,
if
they're
not
already
there
right
and
trying
to
help
them
do
that
in
a
logical
manner,
but,
for
instance,
to
talk
about
like
to
give
an
example.
B
My
fiance's
company
uses
docker,
but
they
don't
use
kubernetes
or
any
kind
of
orchestration
because
they
don't
need
to
like
the
amount
of
like
the
resources
that
they're
using
and
the
amount
of
the
type
and
amount
of
work
that
they're
doing.
It
doesn't
make
sense
to
use
an
Orchestrator,
and
I've
actually
talked
with
some
of
the
engineers
about
it,
because
they
really
go.
Tell
me
about
this
kubernetes
thing,
and
I'm
like
this
is
kind
of
this
is
what
it
is
and
I
kind
of
finally
came
up
with
a
metaphor
where
it's
like.
B
Your
company
uses
the
containers
as
a
shovel.
If
we
brought
two
like,
let's
say
like
we're,
piling
a
field
right,
you've
got
a
plow.
If
you
were
to
use
kubernetes.
That
would
be
like
trying
to
plow
a
field
with
a
nuclear
bomb.
It's
way
more
complicated
than
you
need
to
do
sure
you
can
clear
a
lot
of
land
with
the
giant
bomb,
but
it's
that
is
way
more
than
you
guys
need
right
and
I
think
that
for
me,
that's
like
that.
B
B
A
Thing
that
I'll
say
is-
and
this
is
just
coming
from
experience
working
with
organizations-
is
let's,
let's
assume,
that
you
have
justified
kubernetes
for
yourself
and
by
the
way
I
super
echo
everything
Nikolas
just
said,
like
you
have
to
be
really
careful
and
determine.
Do
you
actually
need
to
take
this
thing
on
because
it's
still
hard
to
do
in
a
lot
of
ways
right,
but
it
looks
assume
you
have
taken
it
on
I.
A
Think
an
interesting
thing
to
have
empathy
about
as
often
times
infrastructure
DevOps
people
is,
you
might
know,
kubernetes
really
really
well,
but
that
doesn't
mean
you're.
Thousands
and
thousands
of
developers
have
any
idea
what
kubernetes
is
at
all,
and
that
is
a
massive
disconnect.
We
see
in
organizations
all
the
time
where
you
know
they're
trying
to
onboard
folks
on
to
kubernetes
and
they
haven't
fully
abstracted
kubernetes
away,
which
some
companies
do,
and
that
can
be
a
really
good
pattern
to
like
developers
deploy
their
apps
I.
Don't
even
know,
kubernetes
are
running
them
under
the
hood.
A
That's
that's
a
really
neat
pattern
as
well,
but
assuming
that
they're
just
trying
to
bring
developers
onto
kubernetes
they
don't
really
have
the
same
amount
of
empathy
for
them,
and
they
just
think
like
this
should
be
really
easy.
It's
just
a
bunch
of
yamo
files,
you'll
figure
it
out,
but
they
totally
forget
about
all
the
complexities
that
they
originally
learned
about,
like
how
it
is
pod.
The
pod
networking
work
and
things
like
that.
So
I
just
think
it.
A
You
know
to
your
question:
Carlie
yeah,
it's
interesting,
because
one
massive
group
and
a
company
can
know
a
lot
about
kubernetes
and
forget
what
it
was
like
to
learn
how
something
like
kubernetes
or
container
orchestration
worked
so
I
think
a
lot
of
that
is
kind
of
bridging
the
gap
and
really
having
some
amount
of
Education
to
bring
everyone
up
to
speed.
Even
in
the
same
organization.
A
C
Dying
to
have
an
episode
on
just
that
alone,
because
it
is
quite
challenging
when
you
frame
when
you
are
faced
with
kubernetes
I
mean.
The
very
first
thing
is
that
there
are
terminologies
that
you
haven't
seen
before
and
you're
like.
How
does
the
maps
for
what
I
already
know
and
then
sometimes
it
doesn't
map
it's
completely
new.
So.
A
B
Absolutely,
but
that
is
a
good
point
that,
like
even
I,
sometimes
forget
like
there's
like
well.
Why
would
I
want
to
raise
I'm
like
why?
Wouldn't
you
want
kubernetes
duh
like
it
works,
so
well
in
my
brain?
Why
don't
you
get
it?
You
know,
but
it's
good
to
take
a
step
back
right
out
of
yourself
and
you
know
be
empathetic
to
the
people
you're
talking
about
in
the
community
I
think
you
clearly
see
yeah
you
mentioned
that
we
we
should
be
wrapping
this
up
pretty
soon.
B
I
think
I
totally
agree
before
we
go
I
want
to
say
like
if
you
want
to
contribute
to
any
container
orchestration
but
kubernetes
in
specific,
since
that's
the
one
that
we
can
work
with
the
most
there.
We
totally
encourage
you
to
start
contributing
to
these
projects
like
with
kubernetes.
We
have
the
criminals
kubernetes
repo,
that
has
a
lot
of
information
on
how
to
start
contributing
I
believe
that
mesosphere
has
their
own
repos
and
the
information
online
available
for
them
and
I,
don't
know
and
I
believe
I'm,
not
sure.
B
B
B
Or
I've
seen
people
at
k8s
is
the
acronym,
and
what
that
means
is
that
there's
eight
letters
between
k,
NS
and
kubernetes.
That's
all
that
means
I've
seen
some
people
do
k-8
and
it
drives
me
up.
Every
wall
I
actually
start
constructing
walls,
and
it
continues
to
drive
me
up
them.
I'm
in
an
infinite
regression
of
walls.