►
From YouTube: Kubernetes - 3 Commonly Asked Questions
Description
In this video, James Watters, SVP Products at Pivotal, goes through the three most commonly asked questions with IT leaders around their adoption of Kubernetes.
1) How many times does Kubernetes release per year?
2) How many clusters will you need?
3) How mature is your SDN strategy?
To learn more about VMware Cloud Native Applications, visit https://www.vmware.com/solutions/cloud-native-apps.html
To learn more about VMware PKS, visit https://cloud.vmware.com/pivotal-container-service
A
Hey
so
I'm
James,
thanks
for
spending
some
time
with
me
today,
I
wanted
to
share
a
couple
of
the
observations
and
questions
that
I've
been
asking.
It
leaders
around
their
adoption
of
kubernetes
I'm
fortunate
enough
to
spend
60
70
percent
of
my
time
out
in
the
field
with
clients
seeing
how
their
container
adoption
is
going,
and
these
are
the
big
gotcha
questions
that
somewhat
independent
of
whatever
product
you
think
about.
You
want
to
get
right
with
kubernetes
in
an
enterprise
context.
The
first
thing
I
ask
everybody
who's
thinking
about
adopting
kubernetes
is
question
number
one.
A
Pace
is
a
critical
element
of
the
kubernetes
community
and,
if
you're
not
playing
to
their
pace,
you
might
be
designing
your
infrastructure
for
kubernetes
wrong
from
the
get-go
normally
asked
for
hands.
I
was
just
in
a
session
with
a
whole
leadership
team
around
this
and
different
different
answers
came
out.
A
The
the
core
answer
here
is
that
kubernetes
comes
out
four
times
a
year
for
major
releases,
and
you
know
probably
12x
plus,
if
you
include
miners
from
the
get-go,
this
is
cloud
paced
software,
it's
CI,
CD
centric
from
community
to
the
end,
and
the
big
gotcha
here
is
the
kubernetes
community
supports
it's
ap
is
for
only
n
minus
2,
and
so
that
means
from
the
beginning,
as
you're
designing
your
kubernetes
solution.
You
have
to
think
about
constant
updates.
A
How
are
you
going
to
keep
those
clusters
up-to-date,
because
in
an
N
minus
2
world?
That
means
you
have
9
months
at
best
from
any
deployment
until
that
API
is
no
long
supported
by
the
community.
Now,
a
big
reason
you're
doing
kubernetes
is
because
you
want
to
harvest
all
of
these
great
network
effects.
All
of
the
community
participation
all
of
the
new
things
that
are
happening,
so
don't
let
yourself
get
into
a
place
where
you're
not
ready
to
do
continuous
upgrades
of
kubernetes
that
end
barrier
really
could
hold
you
back.
A
I've
met
a
lot
of
enterprises
that
tell
me
hey.
James
are
really
excited
about
Cru
brandies,
we're
just
about
to
get
into
production,
but
now
the
version
that
we've
certified
is
a
year
and
a
half
old
it
took
us
that
long
to
do
it
so
from
the
start.
Think
about
the
constant
upgrade
ability
of
your
infrastructure
with
kubernetes
is
a
key
part
of
your
design.
A
So
that's
question:
one
I
can
always
tell
that
it's
an
important
one
to
these
organizations,
because
the
CTO
CIO
notebooks
come
out
right
away
and
they
start
taking
this
down.
In
fact,
just
finished
a
conversation
with
the
CTO
of
a
major
bank,
and
she
said
we
really
need
to
think
about
this.
Our
current
team
isn't
thinking
about
how
they're
going
to
keep
us
up
to
date.
The
second
big
question
when
large
organizations
are
looking
at
kubernetes
is
how
many
clusters
will
you
need.
A
The
answer
really
that
I
coach
folks
on
is
n.
You
need
to
be
able
to
build
a
cluster
on
demand
with
an
API
or
you're,
not
exploiting
kubernetes,
to
its
full
potential.
There's.
A
couple
of
reasons
for
this
number
one
is
that
the
security
and
multi-tenancy
model
of
kate's
does
not
have
hard
security
and
multi-tenancy
boundaries.
So
there
are
some
experts,
like
JS
Frisell
who've
written
from
Microsoft,
that
if
you
have
access
to
root
access
to
you,
one
node
on
a
kubernetes
cluster
and
you
gain
access
to
the
API,
there's
really
not
much
there.
A
A
This
allows
every
team
to
have
a
blast
radius,
that's
much
smaller
than
a
you
know,
datacenter
scaled
cluster.
It
allows
them
to
configure
the
global
variables
on
that
cluster
to
their
liking
and
to
get
it
right
for
them
make
sure
that
the
permissions
are
set
in
a
way
that
is
more
secure.
The
other
thing
that
happens
is
is
that
once
you're
able
to
programmatically
provision
clusters
getting
through
dev
test
prod
or
using
a
CI,
CD
centric
approach
to
cluster
management
becomes
part
of
your
natural
evolution.
A
So
we
like
to
coach
people,
the
answer
is
n,
and
it's
not
one.
Sometimes
people
like
to
think
of
you
know
containers
as
a
replacement
for
virtual
machines.
Those
folks
will
often
say
that
this
is
the
new
VM
and
therefore
they
use
one
large
cluster
I.
Think
that
the
how
many
cluster
questions
is
a
good
way
of
saying
that
the
container
does
not
replace
the
virtual
machine.
A
A
And
the
big
topics
here
just
to
hit
on
them
quickly
or
that
kubernetes
does
not
come
with
built
in
layer,
7
and
load
balancing
networking.
So,
as
you
declare
a
service
and
you
need
an
ingress
controller,
many
teams
have
to
go
out
painfully
and
do
a
ticket
or
a
request
with
their
f5
team
and
say
hey.
We
need
to
reconfigure
the
entire
global
load
balancer
for
the
company
to
set
up
this
ingress
controller
for
kubernetes.
That's
matching
a
fast-moving
kubernetes
community
with
a
slower-moving
networking
infrastructure
team.
A
So
a
lot
of
what
PKS
did
is
it
built
in
you
know
this
layer,
7
ingress
controller
on
demand
right
into
the
product,
so
you
have
to
have
a
mature
Sdn
to
do
some
of
these
programmatic
things,
especially
as
you're
constantly
upgrading
and
constantly
deploying
clusters
on
demand
you're
going
to
need
to
control
the
network
in
a
programmatic
way.
The
other
thing
that
kubernetes
doesn't
come
with
from
a
networking
perspective
is
it
doesn't
do
intra
cluster
or
cluster
to
cluster
layer
2
through
4
networking?
And
so
imagine
you
have
a
service
running
on
one
cluster.
A
You
want
to
make
sure
it
can
address
legacy
or
you
want
to
make
sure
it
can
address
a
service
running
on
another
cluster.
That's
not
an
out-of-the-box
networking
feature
kubernetes,
and
so
again
you
could
really
slow
down
and
get
out
of
the
speed
of
the
community
by
having
to
go
back
to
ticket
based
system,
to
make
a
request
to
the
networking
team.
Who
may
not
understand
you
know
container
networking
that
effectively.
A
A
So,
as
you
think
about
you're
kubernetes
strategy,
make
sure
your
the
ready
to
answer
these
three
questions
and
PKS
was
designed
from
the
start
to
answer
these
three
questions
and
more
for
all
of
our
enterprise
clients.
We
don't
want
you
to
have
to
fork
and
fries
kubernetes
in
order
to
use
it.
The
alternative
to
this
is
manual
install
of
an
out-of-date
version
of
kubernetes
that
might
have
proprietary
additional
software
to
try
to
help
you
secure
it.