►
From YouTube: Sponsored Keynote: Kubernetes as the Control Plane for the Hybrid Cloud - Clayton Coleman
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Sponsored Keynote: Kubernetes as the Control Plane for the Hybrid Cloud - Clayton Coleman, Architect for Kubernetes and OpenShift, Red Hat
A
Seven
years
ago
we
began
this
project
around
a
really
simple
idea:
orchestration
of
containers
with
a
declarative
api
model
designed
to
capture
intent.
Our
machines
would
realize
we
heard
clearly
from
early
adopters,
make
that
model
easily
extensible
to
new
concepts,
which
has
helped
us
standardize
how
teams
build
and
run
all
types
of
applications,
but
we
can't
rest
on
our
laurels.
What
do
we
need
to
do
to
improve
security,
make
new
application
abstractions
possible
and
continue
to
improve
resiliency
and
operational
flexibility
and
help
simplify?
A
What's
still
pretty
complicated
today
to
many
here,
kubernetes,
the
container
orchestrator
and
kubernetes
declarative
api
engine
may
seem
inextricably
linked,
but
what,
if
we
reverse
direction?
What?
If
we
could
let
kubernetes
the
api?
Take
the
lead?
What
would
kubernetes
look
like
without
pods?
What
would
be
the
basic
tools
in
our
podlust
toolbox?
A
These
are
some
pretty
powerful
tools.
Namespaces
can
subdivide
our
work.
Rbac
can
protect
it
secrets
and
config
maps
can
accept
generic
config
and
crds
can
allow
us
to
define
all
the
new
apis
we
need.
So
what
you're
seeing
is
a
really
simple
prototype
of
how
a
cube-like
control
plane
might
behave,
kubernetes
api
without
pods
containers
or
nodes,
but
all
the
extensibility
client
support
and
tooling
needed
to
integrate
declarative
apis
describing
a
much
more
integrated
world.
So
what
would
we
do
with
this
lightweight
control
plane?
A
Well,
we
can
do
quite
a
lot,
not
knowing
about
pods
the
crds.
I'm
installing
today
are
just
some
examples
of
existing
integrations
to
cube
that
program.
Things
off
clusters,
programming,
cloud
resources,
external
dns
or
load,
balancing
that
coordinates
across
clusters,
or
even
provisioning
databases
to
connect
back
to
apps
on
the
cluster
and
a
key
challenge
for
all
these
integrations
today
is
they
require
you
to
know
who
owns
the
integration.
A
Obviously,
as
we
put
more
and
more
stuff
together,
things
get
more
complicated
if
we
just
put
everything
together
in
a
higher
level
control
plane
that
doesn't
actually
solve
the
real
problem.
We
need
to
tease
apart
different
problems
from
different
teams,
use
cases
and
roles.
A
Maybe
we
wouldn't
need
to
do
as
much
subdivision
within
a
cluster,
so
I'm
currently
connected
to
our
prototype,
I'm
going
to
switch
to
another
cluster
hosted
by
that
same
server,
the
prototype
conveniently
generated
a
cube
config
and
I've
got
a
user
context,
so
you
can
see
that
the
first
url
and
the
second
url
have
the
same
host
my
local
system,
but
our
path
changed
and
it
included
the
name
of
a
cluster.
What
does
that
mean?
A
A
If
you
go
further,
imagine
having
instead
of
one
cluster
with
thousands
of
services,
what
if
we
had
a
thousand
little
clusters
each
running
one
service,
how
might
we
change
our
applications
and
the
way
that
they,
the
apis,
that
we
need
to
talk
in
order
to
bring
that
to
light
team,
a
and
team
b
collaborate
on
a
service
without
knowing
about
the
implementation
details
of
the
other?
But
of
course
we
won't
have
thousands
of
applications
to
run
unless
we
can
bring
them
all
to
our
new
lightweight
control
plane.
A
I
provide
location
and
credentials
to
this
crd
of
a
real
cluster
which
allows
us
to
go
and
import
the
apis
right.
It's
just
an
api.
The
cube
model
makes
this
easy,
and
you
know
this
is
a
demo.
So,
let's
throw
a
second
cluster
in
there
so
that
we
don't
have
a
new
single
point
of
failure.
You
can
see
that
we
grabbed
the
deployment
api
object
from
the
underlying
cluster,
which
allows
me
to
now
go
create
one,
but
this
server
doesn't
know
anything
about
deployments.
It's
just
an
api.
A
A
We've
made
it
so
that
the
application
author
doesn't
really
need
to
know
about
the
details
of
those
underlying
clusters
and
for
applications
that
are
shared
nothing.
This
integration
would
work
great.
You
can
see.
You
know
I
could
put
two
different
replicas
on
two
different
clusters
and
nobody
has
to
know
the
difference
to
an
application.
Author.
I've
said
here's
what
I
want
in
the
standard
way
that
I
do
today,
but
now
suddenly
my
control
plane
is
hiding
some
of
the
details
from
me,
and
this
brings
us
full
circle.
A
We've
gone
from
cube
to
api
now
back
to
a
full
cube
application,
maybe
seven
years
into
kubernetes,
we've
finally
come
to
the
point
where
we
can
define
our
applications
without
needing
to
know
about
pods
nodes
and
the
implementation
details
of
clusters.
A
I
think
this
is
a
great
start
to
some
of
the
ideas
where
we
could
go
in
the
future,
so
everything
I
showed
you
today
is
part
of
a
simple
and
delightfully
hacky
prototype
that
we're
calling
kcp
it's
just
a
way
to
explore
some
out
there
concepts
that
might
be
part
of
our
future.
If
your
work,
ideas
or
interests
intersect
with
ours
check
out
our
github
repository
at
kcp,
the
readme
covers
the
real
and
not
quite
real
parts
of
this
demo,
but,
more
importantly,
details
the
ideas,
inspirations
and
possibilities.