►
From YouTube: Kubernetes: One Cluster or Many?
Description
In this video, Cornelia from Pivotal talks about multi-cluster Kubernetes from PKS.
To learn more about PKS, click here: https://cloud.vmware.com/pivotal-container-service
A
Hello,
my
name
is
cornelia
davis,
I'm
senior
director
of
technology
at
pivotal,
and
what
I
want
to
talk
to
you
about
today
is
multi
cluster
kubernetes.
So,
let's
begin,
let's
start
with
the
general
kubernetes
architecture.
Kubernetes,
of
course,
has
a
whole
bunch
of
nodes.
We
sometimes
call
these
the
worker
nodes
and
that's
where
your
workloads
are
going
to
land.
That's
where
your
docker
images
are
going
to
land,
so
we've
got
a
whole
bunch
of
workers.
We
also
have,
above
that
we
have
what
I
would
consider
the
control
plane.
A
A
A
The
scheduler,
which,
of
course,
is
responsible
for
scheduling
the
containers
onto
the
worker
nodes
DNS,
which
is
used
for
service
discovery
of
all
of
the
workloads
that
are
deployed
onto
the
workers
on
the
worker
nodes
themselves.
We
also
have
some
components,
things
like
the
cubelet
or
the
cube
proxy,
which
is
involved
in
networking.
A
So
these
are
all
the
various
components
and
we
have
the
cubelet
here
and
we
have
the
cube
proxy
here
as
well
that
lives
on
each
one
of
the
workers,
and
so
these
are
all
of
the
components
now
when
it
comes
to
actually
leveraging
this
we're
going
to
take
this
just
like
the
shared
compute,
storage
and
network.
These
nodes
are
shared
resources
as
well,
and
so
we're
going
to
share
those
resources
across
a
bunch
of
different
tenants.
So
we
might
have
tenant
one
which
is
using
some
of
the
capacity
across
all
of
these
different
workers.
A
That's
tenant
one,
and
then
we
also
have
let's
say
tenant
number
two,
and
it's
utilizing
some
of
that,
and
we
might
have
some
other
tenants
here
as
well.
Now
the
abstraction
that
kubernetes
provides
for
these
various
tenants
is
namespaces,
so
each
tenant
would
get
their
own
namespace.
So
this
is
namespace.
One
and
tenant
gets
namespace.
Two.
A
Now
this
is
the
basic
setup
of
a
kubernetes
cluster.
Now,
if
we
take
a
look
at
this,
though
we
talked
about
these
various
namespaces
in
these
different
tenants,
which
is
really
about
isolating
this
shared
resource
of
workers,
but
if
we
take
a
look
at
the
architecture
here,
what
we
can
see
is
that
there
are
a
whole
bunch
of
components
that
are
shared
components.
The
API
server
is
shared
across
all
of
these
different
tenants.
The
controller
manager
is
a
shared
resource.
A
The
scheduler
is
a
shared
resource,
as
is
DNS,
and
these
various
components
that
live
on
the
workers
as
well
all
shared
components.
Now
there
are
some
implications
of
these
shared
components.
The
first
thing
is
that,
because
those
components
are
shared
across
the
different
tenants,
what
we
end
up
with
is
what
I
would
call
soft
multi-tenancy
and
if
you
take
a
look
at
the
way
that
the
community
talks
about
it.
A
In
fact,
the
kubernetes
community
refers
to
the
tenancy
constructs
in
kubernetes
is
really
kind
of
a
soft
multi-tenancy
see
if
I
can
spell
that
right,
and
that
is
because
some
of
these
shared
resources,
something
like
DNS,
is
not
tenant.
Aware.
There's
a
single
DNS,
so
when
tenant
one
publishes
services
into
DNS
tenant,
two
who's,
also
using
the
same
DNS,
can
in
fact
see
the
services
that
have
been
published
into
the
dns
by
tenant
one.
So
that's
really
soft
multi-tenancy
there's
various
degrees
of
tendency
in
kubernetes,
but
it's
relatively
soft.
A
Okay
and
finally,
this
is
one
single
kubernetes
cluster,
so
that
one
kubernetes
cluster,
all
of
the
tenants
across
it,
are
using
this
same
version
of
kubernetes
so
same
kate's
as
we
sometimes
call
it
version
so
tenants.
One
and
two
are
both
using
version
1.1
of
kubernetes,
for
example.
Now
this
is
kind
of
typical.
This
is
what
people
typically
think
of
when
they
think
about
doing
kubernetes.
But
what
I
want
to
do
today
is
I
want
to
suggest
a
possibly
surprising,
different
way
of
dealing
with
kubernetes
in
your
enterprise.
A
A
Now.
This
control
plane,
of
course,
has
the
API
server.
It
has
the
controller
manager
it
has
DNS.
It
has
the
scheduler
all
of
those
things
over
here
now,
you'll
start
to
notice
something
here
that
I've
got
multiple
instances
of
these
things.
That's
really
kind
of
the
key,
so
I've
got
DNS
and
I've
got
my
my
components
that
are
living
here
on
the
workers
as
well.
Now,
all
of
this
all
of
these
clusters,
these
multiple
clusters
that
I
have
here
are,
of
course
running
over
the
top
of
the
same
shared
compute.
A
A
A
Now
that's
interesting
now,
if
we
think
about
the
things
that
we
looked
at
over
on
this
side
of
the
board,
let's
think
about
those
characteristics,
as
we
go
now
notice
that
I
already
pointed
out
that
things
like
the
API
server
and
the
DNS
are
no
longer
shared
across
different
tenants.
So
the
first
thing
that
we'll
notice
is
that
if
tenant
one
publishes
a
service
into
its
DNS,
it's
not
seen
by
tenant
two
because
tenant
two
has
their
own
DNS.
A
A
A
So
that's
a
win
right
from
the
beginning
now.
The
second
thing
is
that
you'll
notice
here
that
in
terms
of
operations
or
even
in
terms
of
bad
things,
that
can
happen.
What
we're
doing
is
we're
limiting
the
blast
radius,
if
you
will
so
if
I
have
to
do
some
operations
and
I
have
to,
for
example,
patch
the
operating
system.
That's
running
on
all
of
these
nodes
down
here,
I
can
do
so
on
this
tenant
without
affecting
this
tenant
over
here.
A
So
that's
a
big
one
as
well
now,
the
other
thing
that
you
can
do
when
you're
doing
this
is
that
each
one
of
the
clusters
can
have
different
configurations.
A
lot
of
the
config
that
happens
in
these
clusters
happens
around
things
like
the
API
server.
A
lot
of
configuration
is
encapsulated
in
the
way
that
you
start
the
API
server
or
the
way
that
you
could
start
the
controller
manager
and
again
these
things
are
not
shared,
so
you
could
have
different
configurations.
A
So
you
can
see
here
that,
while
we
think
kind
of
traditionally
of
having
one
large
kubernetes
cluster
that
we've
broken
down
into
various
namespaces
for
tenancy,
we
can
see
what
some
of
the
downsides
of
that
are,
but
by
taking
advantage
of
what
we
have
20
years
of
maturity
and
virtualization
technology,
we
have
the
ability
of
affording
all
sorts
of
benefits.
Now
the
final
thing
that
I'll
leave
you
with
is
you
might
be
thinking.
A
Well,
my
goodness,
are
you
actually
suggesting
that
I
have
dozens
or
maybe
hundreds
of
clusters
for
different
tenants,
because
I'm
gonna
have
hundreds
of
different
tenants
and
that's
in
fact
exactly
what
I'm
suggesting
is
that
you
have
multiple
tenants
and
many
many
tenants,
dozens
or
hundreds
of
them?
Now
you
might
be
thinking
how
am
I
possibly
going
to
be
able
to
manage
that?
Well
that
right,
there
is
a
big
part
of
the
value
proposition
of
pivotal
container
service.
Pkas
doesn't
just
provide
you
a
kubernetes
cluster.