►
From YouTube: Kubernetes as the Control Plane for the Hybrid Cloud Clayton Coleman Red Hat OpenShift Commons 2021
Description
OpenShift Commons Gathering at Kubecon/EU
recorded May 4th, 2020
Kubernetes as the Control Plane for the Hybrid Cloud (Long Version)
Speakers:
Clayton Coleman (Red Hat)
Joe Fernandes (Red Hat)
https://commons.openshift.org/index.html
A
A
B
A
So
openshift
is
our
hybrid
cloud
platform
and
it's
built
on
a
foundation
of
kubernetes
and
red
hat
enterprise
linux,
but
provides
a
comprehensive
platform
that
enables
enterprise
customers
to
build,
deploy
and
manage
applications
wherever
they
want.
If
you
attended
our
openshift
roadmap
session
at
commons
gathering
or
any
of
the
other
venues,
you
saw
a
lot
of
our
recent
work
has
been
around
how
we
add
new
and
better
capabilities
for
managing
multiple
openshift
clusters
across
multiple
environments.
A
Features
that
we're
developing
to
help
customers
manage
oak
shift
and
their
applications
across
a
hybrid
environment
are
the
same
ones
that
we
rely
on
ourselves
to
deliver
openshift
as
a
managed
cloud
service.
So,
as
you
can
see
from
this
slide,
openshift
is
available
as
a
fully
managed
cloud
service
across
all
the
major
public
clouds,
and
then
we
also
deliver
it
as
a
self-managed
software
solution
that
you
can
deploy
and
manage
yourself
wherever
you
want
to
run
it,
but
either
way.
Kubernetes
is
at
the
core
of
this
platform.
B
B
The
api
model
is
about
intent
right,
that's
saying
what
you
want
and
then
making
the
machines
go
realize
it,
because
we
have
other
things
to
do.
We
have
to
go
write
those
apps.
We
got
to
debug
those
apps.
We
don't
want
to
be
there
telling
the
machines
what
to
do
every
day.
That's
the
machines
can
do
that
for
themselves.
B
We
heard
clearly
in
the
early
phases
from
early
adopters.
We
needed
to
bring
new
concepts
in
like
declarative.
Apis
are
really
powerful.
Can
we
bring
new
concepts
alongside
all
the
ones
that
were
in
cuba?
That's
been
successful
beyond
our
wildest
dreams,
and
today,
seven
years
later,
a
huge
number
of
organizations
and
companies
and
individuals
run
services
successfully
on
top
of
kubernetes
in
a
way
that
standardizes
deployment,
and
so
we
need
to
ask
you
know
what
what
can
we
do
to
move
kubernetes
forward.
A
Talk
about
the
evolution
of
kubernetes
over
those
last
seven
years
and
how
it's
evolved
to
address
customer
needs,
and
this
is
just
one
way
to
look
at
it.
I
looked
at
it
in
terms
of
these
three
phases,
so
in
phase
one
of
our
kubernetes
journey,
the
kubernetes
api
and
the
core
primitives
and
declarative
resource
controllers
that
are
part
of
that
allowed
users
to
orchestrate
an
expanding
number
of
application
workloads-
and
we
saw
this
with
customers
and
partners
alike.
Yep.
B
And
you
know
this
is
the
the
evolution
of
kubernetes
has
been
driven
by
people,
putting
it
into
use
and
then
finding
gaps
and
helping
us
identify.
You
know
where
the
project
as
a
group
we
could
go
so
amadeus
is
one
of
the
one
of
our
earliest
kubernetes
clusters.
They
started
using
replication
controllers
for
their
long-running
services,
and
this
is
in
the
days
before
deployments.
They
realized
they
also
needed
a
solution
for
batch
jobs
and
at
the
heart
of
kubernetes.
B
We
we
anticipated
this,
but
you
know
through
that
community
collaboration
ahmedesque
was
actually
able
to
help
drive
those
features,
as
a
is
the
very
beginning
of
cuban.
Those
features
today
exist
as
part
of
that
you
know,
collaboration
in
the
community,
oh
yeah,
that's
right
and
also
like
before
I
forget,
like
couchbase.
One
of
our
key
partners
also
wanted
to
deploy
databases
and
containers.
B
People
who
put
their
time
in
in
the
community
to
make
sure
that
these
were
reliable
and
stateful
sets,
which
you
know
themselves,
have
gone
through
a
long
evolution
are
there
to
support
workloads
that
need
to
be
predictable
over
a
long
period
of
time,
and
that
was
through.
You
know
those
kinds
of
collaborations
that
was
possible.
B
Yeah
and
you
know
early
in
the
development
of
openshift,
we
made
the
decision
in
the
kubernetes
community
that
we
wanted
to
have
a
small
compact
core
functionality
that
wasn't
platform
as
a
service,
which
you
know
it
was
about
running
applications
and
obviously
the
scope
of
applications
is
practically
unbounded
working
in
openshift.
We
wanted
to
contribute
these
concepts
and
build
them
in,
but
we
had
no
way
to
do
that
within
kubernetes
itself,
and
so
you
know
at
overtime.
B
You
know
in
partnership
with
a
lot
of
folks
in
the
community
that
led
to
custom
resource
definitions
and
common
controller
logic
which
have
you
know
and
now
enabled
and
empowered
huge
amount
of
extensibility
over
the
years
custom
resources.
Let
us
put
the
config
for
the
cluster
on
the
cluster,
that's
something
that
the
cube
admin
project
has
used
as
well.
So
it's
this
this
idea
that
everything
could
be
extended
and
you
bring
new
concepts.
B
The
operator
pattern
is
really
about
hiding
complexity,
whether
it's
for
deployment
or
for
extending
kubernetes,
and
you
know,
through
the
work
we've
done.
That's
been
integrated
back
into
openshift
and
you
know:
we've
seen
a
huge
uptake
in
the
broad
ecosystem
of
people
extending
kubernetes
with
their
concepts,
and
we
think
it
can
go
further.
A
Yeah,
so
so
now,
in
this
third
phase,
we're
thinking
in
terms
of
lots
of
applications
spanning
many
clusters,
those
clusters
spanning
many
different
environments
and
so
really
what
we're
trying
to
do
now
is
explore
and
we'll
do
that
in
this
session.
How
can
we
better
leverage
that
kubernetes
api
to
manage
services
across
multiple
clusters-
and
you
know,
have
those
custom
clusters
running
across
different
clouds-
data,
centers
and
edge
environments,
yeah.
B
And
today,
in
a
sense,
we're
continuing
that
extension
pattern,
we're
bringing
new
concepts
we're
doing
it.
You
know,
depending
on
how
you
approach
the
problem.
Some
folks
are
building
this
out
from
their
cloud
console
projects
like
arc
or
amphos
within
red
hat.
We've
been
actually
thinking
about
this
as
what,
if
you
had
a
hub
cluster,
that
was
a
little
bit
of
your
management
cluster
for
all
your
other
clusters.
B
We
know
that
that's
not
enough
right,
there's,
there's
always
better
ways
to
subdivide
work,
and
so
some
of
the
the
learnings
from
you
know
the
very
early
days
of
kubernetes,
adding
new
concepts,
concepts
that
we
never
got
around
to
going
in
and
building
operators,
and
you
know
the
broad
ecosystem
of
people
plugging
into
cube,
and
then
this
multi-cluster
idea
is.
We
start
to
look
at
this
and
we're
kind
of
exploring.
How
can
we
take
some
of
those
ideas
and
compose
them
in
novel
ways?
B
B
B
I
think
that,
like
you
know,
this
is
the
simplest
architectural
slide
that
joe
and
I
could
find
of
you
know
all
of
these
concepts
and
there
is
a
huge
amount
of
detail
hidden
here,
but
you
think
about
these
pieces.
Most
of
us
think
you
know
these
are
all
part
of
q,
but
we
wanted
to
come
into
this
and
say:
well,
you
know
what
if
we
change
direction,
what
if
it
wasn't
about
all
these
other
pieces,
it
was
about
kubernetes
the
api.
B
What
would
it
look
like
without
pods
or
services
without
nodes
or
cubelets,
without
controllers
or
schedulers?
So
it's
like
I
like
to
call
this
talk.
Somebody
came
up
with
this.
The
other
day
is
like
nodes
where
we're
going.
We
don't
need
nodes.
So
it's
my
that's
my
doc
brown
impression
and
that's
about
as
good
as
it's
gonna
get.
So
while
I
start
sharing,
you
know,
if
you
can
team
me
up
yeah.
A
B
Yeah
and
just
to
continue
my
my
doc
brown
joke,
we've
gone
back
in
time,
so
this
is
you're
seeing
the
future
from
the
past.
So
just
pretend
like
the
kubecon
talk
has
already
happened,
you're
getting
a
deep
dive
and
I
promise
you,
you
won't
miss
anything.
So
what
would
kubernetes
look
like
without
pods?
So
this
is
the
first
question,
so
you
know
pretty
standard
command
line.
I
run
it.
What
if
the
server
told
me
what
doesn't
know
what
pods
are?
Oh,
okay,
you
know
that's
a
it's
an
interesting
idea.
B
What
what
can
I
do
without
pods?
So
I
tried
to
boil
down
the
list
of
all
the
resources
in
kubernetes.
You
know
you
have
name
spaces,
so
you
can
subdivide
your
work.
Different
teams
can
collaborate
together
on
similar,
but
not
identical
things.
You
know
you
have
rbac,
so
you
can
protect
your
resources,
you
know
secrets
and
config
maps
and
crds
that
lets
you
extend
and
lets
you
put
generic
data
there.
This
is
what
we're
calling
a
prototype
of
a
cube-like
control,
plane,
kubernetes
api
without
pods
containers,
nodes
with
extensibility
client
support,
tooling.
B
B
That's
right,
pure
pure
control,
plane,
cube,
focused,
you
know
it's
the
heart
of
the
api.
I
can
create
and
update
resources,
but
the
only
resources
there
are
the
resources
that
help
me.
There's
no,
there's
nothing
that
has
to
do
with
running
workloads.
It's
just.
What
do
I
need
to
integrate
anything,
and
so,
like
this
kind
of
comes
down
to
is
like
you
know,
what
can
we
do
with
this?
B
You
know
to
follow
up
on
your
question
joe,
so
you
know
there's
a
ton
of
integrations
actually
out
there
today
that
are
that
integrates
stuff
into
a
cube
cluster,
but
that
don't
actually
live
on
that
cluster,
so
cloud
resource
operators.
You
know
I
got
a
couple
of
examples
scattered
in
here.
We
actually
shortened
some
of
it,
so
you
can
actually
read
it
because
everybody
gets
really
long
with
their
names,
but
you
know
I
can
create
buckets
or
topics
I
can
create
functions.
B
These
are
all
features
that
exist
today
in
various
operators
and
extensions.
You
know
sometimes
you're
dealing
with
multiple
clusters
and
you
need
an
integration
that
lets
you.
You
know
work
and
say,
like
I
want
this
cluster
to
expose.
This
part,
and
then
I'll,
go
to
my
other
cluster
and
install
that
crd
and
kind
of
one
of
these
challenges
is
they
all
require
you
to
know.
A
So
you're,
basically
taking
all
those
kubernetes
primitives
that
we
described
earlier,
that
came
out
of
the
first
two
phases
of
the
project's
evolution,
users,
roles,
name,
spaces
controllers
and
so
forth,
and
really
applying
them
in
a
different
way.
Right.
So
you're
now
applying
them
to
kind
of
manage
services
or
apply
to
usage
that
really
spans
clusters,
and
you
know
spans
the
users
and
the
applications
that
run
across
those
clusters
right
absolutely.
B
The
more
I
add
it's
more
concepts
I
have
to
keep
track
of,
and
so
you
know
teasing
apart
those
problems
so
that
we're
talking
about
them
in
different
ways
helps.
You
know,
get
a
lot
of
things.
So
you
know
if
I'm
a
security
team
or
on
the
the
infrastructure
team.
I
may
not
want
to
know
about
higher
level
integrations
like
this.
That's
not
my
job,
that's
not
my
role,
and
so,
if
we
can
tease
those
apart,
what
are
the
things
that
would
help
us?
Tease
it
apart.
B
So
you
know
one
one:
real
challenge
is
multiple
teams
sharing
a
single
kubernetes
cluster
with
something
we've
been
exploring
for
a
long
time,
openshift
to
spend
a
ton
of
time
and
effort,
and
you
know
adding
tenancy
to
kubernetes
keeping
teams
apart
making
stuff
secure,
there's
a
lot
of
different
trade-offs.
There's
no
perfect
security,
there's
just
what
is
right
for
someone
at
the
time
and
this
better
or
worse,
you
know
a
single
cluster,
I
think,
is
still
one
of
the
strongest
boundaries
we
have.
B
It
led
to
a
real
question
that
I
think
is
is
super
exciting,
which
is
if,
instead
of
just
having
lots
of
clusters,
if
we
could
get
make
getting
one
more
cluster
really
really
cheap,
would
we
still
need
to
have
all
those
big?
You
know
physical
clusters
and
you
know
joe,
like
we
talk
about
this
all
the
time.
It's
a
key.
B
A
Yeah
definitely
you're
hiding
highlighting
a
challenge
that
you
know
that
we've
been
talking
to
customers
about
for
years.
You
know
not
just
openshift
customers,
but
kubernetes
users
in
general,
which
is
how
do
you
manage
tenancy
across
your
various
developers
and
teams
right?
We
saw
this
from
the
earliest
days
of
openshift.
Three
customers
would
start
with
a
single
cluster
start
with
a
small
team
and
then
inevitably
that
would
grow,
and
we
did
a
lot
of
work
around.
You
know
multi-tenancy
within
the
cluster,
to
address
that
right.
A
So
you
know,
if
you
saw
where
red
hat
invested,
our
resources,
it
was
in
into
evolving
features
like
name
spaces
and
quotas
and
roles
based
access
controls
and
then
even
additional
concepts
beyond
kubernetes
things
like
the
multi-tenant
openshift
sdn
to
segregate
application
traffic.
We
work
then
on
network
policies
and
more
so,
despite
these
capabilities,
customers
always
found
requirements
that
you
know
would
call
for
creating
yet
one
more
cluster
right.
A
So
so
all
the
tenancy
in
the
world
doesn't
eliminate
the
need
for
multiple
clusters
and
then,
as
the
number
of
openshift
clusters
grew,
so
did
the
need
for
more
multi-cluster
management,
and
we
already
discussed
that
earlier.
That's
really
what's
driven
our
roadmap
recently
around
bringing
in
better
multi-cluster
management
capabilities,
but
it
sounds
like
what
you're
talking
about
here
is:
how
can
we
make
it
easier
to
just
ask
kubernetes
itself
to
give
us
clusters
when
we
want
them,
and
then
you
know
make
them
available
for
what
we
need
them
for?
Is
that
right.
B
B
B
That's
provided
that
prototype
generates
a
cube,
config
file
that
actually
points
to
two
different
clusters,
so
they're
called
the
second
one
user,
and
when
you
look
at
the
config
line,
what
you'll
see
is
the
url
is
different,
and
so
it's
the
same
server.
But
I've
got
two
clusters,
so
there's
the
first
cluster
that
I
did
all
that
you
know
the
showing
you
didn't
have
pods
and
I
installed
crds
into,
but
in
this
second
cluster.
B
If
I
call
git
databases,
it
tells
me
it
doesn't
have
any
databases
and
that's
because
the
different
clusters
see
different
crds.
So
if
I
call
cube
control
get
crds,
there
are
no
crds.
So
in
a
sense
you
know
the
database
from
the
other
cluster
is
invisible.
The
new
tenant
can't
even
interact
with
it.
That's
like
a
pretty
hard
security
boundary
so
like
two
different
teams
on
the
same,
you
know
they're
talking
to
the
same
server
under
the
covers.
B
Maybe
there's
some
stuff
being
shared
but
to
each
individual
team
looks
like
two
completely
different
clusters.
So,
like
there's
a
lot
of
possibilities
in
here,
imagine
instead
of
one
cluster
with
thousands
of
services,
you
know
what,
if
we
have
thousands
of
little
clusters
each
running
one
service,
what
are
the
things
that
we
could
change?
Development,
wise
and
operations
wise?
That
you
know,
starts
to
split
that
problem
up.
A
Yeah,
it's
pretty
interesting.
It
also
aligns
with
you
know
some
of
the
work
we've
been
doing
lately
around
around
getting
smaller
clusters
right,
so
we've
seen
that
related
to
customers
who
want
to
run
kubernetes
at
the
edge
which
we've
tried
been
trying
to
enable
with
openshift,
whether
that's
in
a
three
node
cluster
configuration
a
distributed
worker,
node
or
even
single
node
clusters.
A
We're
also
doing
some
of
that
work
with
the
ibm
cloud
team.
Around
a
project
which
we've
called
hypershift
and
hypershift
is,
is
a
project
that
allows
you
to
deploy
kubernetes
in
a
managed
control,
plane
model.
So
what
that
means
is
you
have
a
central
management
cluster?
It's
running
control
planes
for
a
bunch
of
other
clusters
and
then
the
end
user
clusters
are
literally
just
the
nodes
that
they
bring
to
to
the
party.
A
Essentially,
so
you
know
the
cluster
could
be
just
their
one
node
and
they
get
assigned
a
control
plane,
so
kind
of
lots
of
interesting
concepts
that
have
been
coming
up
lately
around.
You
know:
how
do
we
make
these
clusters
smaller?
How
do
we
get
more
of
them?
And
it's
kind
of
interesting
to
think
about
in
this
context,
when
you
try
to
when
you're
saying,
let's
flip
the
view
here
and
think
about
you,
know
thousands
of
applications,
thousands
of
services
each
in
their
own
little
cluster
versus
you
know
putting
them
together
is
that
yeah.
B
B
You
know
you
don't
need
a
ton
of
stuff
and
actually
I'm
going
to
show
like
a
couple
of
examples
here,
but
you
know,
if
I
have
you
know
to
even
get
to
the
point
where
we
could
do
this.
Well,
I
need
you
know.
I
want
to
have
thousands
of
applications,
but
if
I
can't
bring
all
my
existing
applications,
it's
going
to
take
a
while-
and
you
know
that
would
be
it'd,
be
really
painful.
So,
like
a
big
idea
for
this
prototype,
is
you
know?
B
How
can
we
bring
as
much
as
possible
kubernetes
forward
without
having
to
change
everything?
So
you
know
what
if
we
could
connect
our
control
plane
to
existing
clusters,
so
you
can
turn
cube
the
api
server,
the
lightweight
control
plane
back
into
kubernetes
the
orchestrator.
So
I've
got
a
little
crd
here
and
you
know
it
is
a
it's
a
it's
just
pointer
to
a
cluster.
B
It's
got
a
cute
config
as
well,
and
I
got
a
secret
in
there
that
I'm
not
showing
and
then
I'm
gonna
apply
that
to
the
control
plane,
and
so
that's,
oh
okay.
It
looks
like
one
of
those
bugs
okay,
so
it
applied
the
resource
and
it's
created,
and
so
now
I've
got
this
created
and
I'm
gonna
go
ahead
and
create
a
second
one,
because
you
know,
if
you
just
have
one
cluster,
it's
not
a
really
good
demo.
B
So
we'll
do
two
clusters,
but
you're
gonna
get
the
same
error
again
yep,
so
it
went
and
created
the
clusters
and
there's
still
some
bugs.
I
said
it
was
a
prototype
right
so
by
installing
this
cluster.
What
have
I
done?
Well,
what
I've
done
is
I've
imported
from
those
clusters
all
of
their
resources
as
crds,
so
I
didn't
need
to
implement
that
that
other
cluster
is
handling
it.
So,
just
like,
we
added
those
crds
for
external
integrations.
What
if
cube
was
an
external
integration?
B
So
I'm
going
to
you
know
now
that
I
see
you
can
see.
Deployments
are
in
this
list.
Actually,
let's
scroll
back
up.
Yep
deployments
are
up
here,
and
so
I
have
a
deployment
and
I
ask
for
15
replicas
and
it's
you
know
connecting
to
two
local
clusters
and
I
just
run
keep
control,
apply
deployment
against
the
control
plane
and
it
goes
and
creates
it.
So
if
I
call
you
know,
get
deployments
now,
you'll
see
it.
B
B
If,
instead
of
just
you
know,
you
know
running
just
the
deployment,
what
if
we
had
a
little
controller
on
the
control
plane,
that
would
split
them
up
and
run
them
on
individual
clusters,
and
some
of
this
is
like
pretty
prototyping
we're
still
just
kind
of
hacking
this
together.
But
the
idea
would
be
that
you
know
you
define
your
app.
You
take
the
apps
that
work
today,
you
stay
on
the
high
level
details.
Instead
of
getting
down
into
the
weeds,
like
you
know,
we
want
to
focus
on
deployments
and
services
and
integrations
with
databases.
B
I
don't
want
to
be
dealing
with
this
low
level.
It's
like
we've
kind
of
come
full
circle.
You
know
from
cube
to
api
and
then
back
to
cube,
but
maybe
what's
different
this
time
around.
This
is
kind
of
like
the
big
idea.
That's
why
the
prototype
was
so
exciting.
Is
you
know
what,
if
we
just
didn't,
add
pods
back
right?
You
know
what
would
it
mean
to
have
a
cube
without
pods
we've
been
doing
this.
For
you
know,
seven
years,
I've
got
this
fully
running
application.
B
It's
got
these
other
clusters
out
there
doing
the
hard
work
you
know,
maybe
seven
years
into
kubernetes,
like
maybe
that
fourth
step
in
the
slide
that
joe
showed
is
like.
Maybe
we
should
be
thinking
about
applications
like
pods
nodes
clusters.
Those
are
details,
let's
think
about
applications,
services.
How
I
glue
things
up
to
me:
that's
hybrid
right.
It's
connecting
all
the
different
things,
not
just
pods
and
nodes,
but
all
of
my
application
in
any
cloud
in
any
environment
on-premise
you
know
hosted
service
or
not
like
trying
to
pull
it
together.
B
A
B
So
tomorrow,
when-
and
I
think
this-
this
is
the
session
before
the
day
before
kubecon,
so
my
talk
app
tomorrow,
we're
gonna,
we'll
publish
the
repository
and
it's
github.com
kcp
dash,
dev,
slash,
kcp
and
kcp
is
just
a.
This
is
a
prototype.
Kcp
is
an
arbitrarily
chosen
acronym
that
has
nothing
to
do
with
anything
about
kubernetes
or
control.
Planes
just
looks
that
way.
You
know
we're
we're
really.
Thinking
about
this
is
like
the
seed
of
a
bunch
of
ideas.
B
You
know
we
want
to
see
how
those
go
we're
not
too
opinionated
at
any
point
here,
our
got
our
goal.
Really,
I
think,
as
you
know,
joe
said,
is
like
we're
trying
to
bring
together
these
ideas
and
really
move
the
conversation
forward.
So
I
I'm
excited
to
be
here.
I
hope
everybody,
you
know,
loves
these
concepts.
You
know
please
reach
out
to
us,
and
I
hope
everyone
here
does
have
a
great
cucon
and
please
watch
my
much
more
compact
talk
now
that
we've,
given
you
the
insider's
preview
to
it.