►
From YouTube: Multicluster Kubernetes Management Made Easy With Open Cluster Management - Joshua Packer, Red Hat
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
Multicluster Kubernetes Management Made Easy With Open Cluster Management - Joshua Packer, Red Hat
Speakers: Joshua Packer
Now that many people are deploying Kubernetes in production, they all have the same question: how do you manage multiple Kubernetes clusters? In this session, we’ll chat about the new CNCF Sandbox project Open Cluster Management (https://open-cluster-management.io) and how it can help you simplify multicluster container orchestration. Open APIs are evolving within the project for cluster registration, work distribution, dynamic placement of policies and workloads, and much more. Attendees will learn how they can use Open Cluster Management to take control of their sprawling infrastructure.
A
hello,
my
name
is
Joshua
Packer
and
I'm.
A
developer
at
Red,
Hat
I'm
excited
to
be
here
with
you
today
at
kubecon
2022,
to
talk
about
the
open
dash,
cluster-management.io
Community
I've
been
involved
in
this
community
since
its
Inception
and
now
at
its
present
status
as
a
cncf
Sandbox
project.
Its
core
focus
is
on
multi-clustered
fleet
scenarios
while
being
Cloud
vendor
agnostic
at
its
core.
This
project
enables
you
to
inventory
your
clusters
distribute
work
while
being
vendor
neutral
again.
It
works
with
almost
any
cncf
compliant
distro.
A
With
this
inventory
of
Fleet,
though,
you
can
extend
your
day
to
management
using
our
policy
configuration
and
application
add-ons
that
are
also
a
part
of
the
community.
You
can
still
build
your
own
add-ons,
though,
as
well
and
distribute
those
out
into
your
Fleet
as
needed.
There
will
be
a
separate
presentation
covering
both
these
areas
of
policy
and
application
in
the
kubecon
virtual
presentation
catalog,
but
in
the
next
30
minutes,
I'm
going
to
do
a
demo
of
how
to
get
started
with
open
classstar
management
and
talk
about
some
of
the
future
work,
that's
being
done.
A
Dash,
starter,
desk
management,
Dash
IO
is
the
organization
there's
the
ocm,
repo
that
has
details
our
community
repo,
where
you
can
find
the
schedule
for
our
weekly
calls,
as
well
as
our
API
definition
for
that
inventory,
control
and
our
enhancement
repository
if
you'd
like
to
submit
an
enhancement
and
or
contribute
in
general
to
the
project.
So
over
the
next
25
minutes.
Now
we
will
dive
into
open
cluster
management
and
take
a
look.
Let's
get
started
all
right.
Let's
dig
a
Little
Deeper.
Let's
look
at
how
open
cluster
management
works
with
your
Fleet
of
clusters.
A
When
we
look
at
this
diagram,
we
see
the
layout
of
how
open
cluster
management
is
deployed
within
your
Fleet.
We
start
with
what
is
a
hub
cluster.
This
is
a
single
entry
point
where
you're
able
to
manage
your
Fleet,
which
could
be
one
two
three
or
many
clusters
on
that
Hub
cluster.
We
run
the
registration
controller,
which
takes
care
of
making
sure
we
have
the
inventory.
We
also
run
controllers
like
placement
and
work
these
allow
for
targeting
of
clusters,
as
well
as
putting
manifests
or
payloads
of
manifests
onto
clusters.
A
This
is
also
where
the
policies
and
the
application
add-on
control.
This
is,
if
you
use
our
community
configuration
policy
or
application
subscription
policy,
as
well
as
there's
a
proxy
add-on
that
can
be
used.
All
of
these
controllers
run
on
the
Hub
to
facilitate
the
add-ons
capability
within
the
fleet
and
then
on
each
of
your
clusters
that
is
going
to
be
managed
by
The
Hub.
We
call
those
managed
clusters.
Literally,
there
is
a
resource
kind
called
manage
cluster
that
you
create
on
the
Hub
side.
In
each
of
these
managed
clusters,
we
have
a
cluster
lit.
A
So
in
this
diagram
we
have
one
Hub
controlling
three
managed
clusters,
each
of
them
able
to
do
work
as
well
as
report
on
status
and
run
agents
if
they're
defined
on
the
Hub.
What
this
does
is,
give
you
a
centralized
single
management
Point
through
an
API
in
kubernetes
with
which
you
can
manage
the
entire
fleet.
A
The
demo
that
you're
about
to
see
is
an
automated
version
of
this
quick
start
guide.
The
quick
start
guide
shows
using
kind
cluster
demonstrations
which
is
cncf
compliance,
the
provisioning
of
a
hub,
as
well
as
a
managed
cluster
or
Target
that
we
can
deploy
a
piece
of
work
which
is
kubernetes,
manifests
on.
A
A
Once
that's
done,
we
will
grab
the
CLI
and
we
will
start
to
install
open
cluster
Management
in
the
late
all
right,
we're
going
to
set
some
environment
variables
that
we
can
use
for
both
the
cluster
name
and
the
Hub
name,
and
we're
going
to
pull
the
CLI
tool
and
install
it.
Cli
tool
just
simplifies,
creating
a
number
of
kubernetes
resources
into
a
single
terminal
command,
so
first
things.
First
we're
going
to
deploy
The
Hub
cluster,
which
is
the
controllers
for
registration
and
inventory
they're,
also,
the
controllers
that
manage
placement
and
benefit.
A
A
So
here
we
see
the
main
cluster
manager
pod
has
been
set
up,
as
well
as
the
rest
of
the
control
plane
is
now
present.
So
we
have.
We
have
a
placement
like
I
mentioned
the
registration
as
well
as
the
work
of
the
web
hook,
which
allows
you
to
apply
the
manifests
into
the
fleet.
We
also
get
a
command
that
we
can
use
to
join
clusters
where
you
would
paste
the
command
and
then
add
the
cluster
name
and
any
additional
parameters.
A
So,
let's
get
started
we're
going
to
register
the
cluster.
This
is
cluster,
one
which
is
going
to
be
our
manage
cluster,
so
we
select
the
command
paste
it
as
well,
as
we
give
the
name
of
the
cluster
which
will
be
cluster
one.
We
set
the
context
for
where
this
runs,
so
we
run
the
command
on
the
manage
cluster
and
we
use
the
force
internal
endpoint
lookup
for
the
DNS,
because
we're
running
unkind.
A
So
we
execute
that
what
this
means
is
some
crds
are
being
created,
as
well
as
some
deployments,
which
will
bring
the
agent
controllers
online.
Once
the
agent
controllers
are
online,
they
will
reach
back
to
the
hub
and
register
a
join
request.
That
join
request
is
done
via
a
certificate
signing
resource.
That
resource
will
need
to
be
signed
on
the
Hub
then,
and
once
it's
signed
you
will
be
able
to,
or
it
will
continue
the
registration
at
which
point
you'll
be
able
to
see
inventory
as
well
as
apply
work.
A
So
let's
verify
that
the
controllers
are
online.
So
here
we
see
the
cluster
lit
registration
agent.
This
is
running
on
the
managed
cluster.
We
see
that
that
was
deployed
and
is
running,
and
now
we
look
for
that
certificate
signing
resource
which
we
see
was
created
but
has
not
been
signed
yet
on
the
Hub
again
here
we
see
the
context
of
the
Hub,
and
so
let's
do
that
signing
so
we're
going
to
accept
the
request
which
signs
the
CSR
see
that
we
did
that
on
the
context
of
the
Hub.
A
Now
that
the
cluster
one
has
been
signed,
it
will
be
imported.
We
can
validate
on
the
Hub
looking
at
the
managed
cluster
resource
that
it
has
been
joined
successfully.
We
see
it
set
to
true,
we
see
the
status
for
the
agent
is
available.
We
see
it's
been
there
for
60
seconds
or
so,
and
we
see
that
the
Hub
has
accepted
the
cluster,
meaning.
The
administrator
is
allowing
that
cluster
into
the
infrastructure
for
management.
A
So
now
we're
going
to
execute
some
work,
which
is
to
apply
a
manifest
and
that
can
be
a
custom
resource
definition
or
a
custom
resource
on
the
manage
cluster
that
we
have
now
present
in
the
hub.
This
is
done
for
each
managed
cluster.
There
is
a
namespace
created,
any
work
or
add-on
related
tooling
is
created
as
kubernetes
resources
in
that
namespace.
We
see
here.
There's
the
cluster
one
namespace
that
we're
going
to
be
using.
We
see
we're
going
to
create
a
manifest
work
called
work
test.
Cm
cm
is
for
config
map
and
inside
the
payload.
A
A
So
here
we
have
the
default
namespace
separate
or
specified,
as
well
as
the
context
on
the
cluster,
and
we
see
22
seconds
ago
that
the
work
tests
CM,
which
matches
the
name
of
the
definition
config
map
was
created
by
that
benefits.
Work
now,
if
we
had
deployed
something
like
a
deployment,
we
could
look
for
status
back
on
the
Pod
same
thing
for
replica
sets
as
well
as
services
or
even
custom
CRS,
and
you
can
path
back
the
status
into
the
Manifest
work.
A
A
One
of
the
key
kinds
that
we
find
here
is
the
manage
cluster
kind.
This
exists
on
the
Hub
and
is
a
representation
of
the
cluster.
It
is
what
the
cluster
lit
the
agent
we
saw
in
the
demo
connects
to
as
well
as
where
the
cluster
lip
provides
status
on
how
the
system
is
doing.
This
is
a
cluster
scoped
object
and
is
a
clear
representation
of
the
fleet
that
can
be
queried
against
in
kubernetes.
A
Manage
cluster
set
is
a
kind
we
haven't
spoken
of
yet,
but
you
can
think
of
this
as
groups
of
clusters.
What
you
do
is
you
use
a
manage
cluster
set
to
group
a
number
of
clusters,
and
then
you
can
grant
users
access
to
that
manage
cluster
set
or
you
can
bind
that
manage
cluster
set
to
namespaces,
and
any
resources
in
that
namespace
that
are
cluster
set
aware
will
be
able
to
access
the
Clusters.
A
This
is
a
way
for
managing
access
to
your
clusters
at
scale
instead
of
having
to
try
to
individually
apply
roles
and
role
bindings
to
each
user
service
account
Etc.
When
you
want
it
to
work
with
clusters,
you
only
have
to
do
that
once
to
the
cluster
set
via
a
binding
to
its
namespace,
and
then
all
clusters
present
in
that
cluster
set
can
be
accessed.
A
There's
also
the
latest,
which
is
the
extensible
section
in
prioritizers
that
we'll
talk
about
in
a
second
as
well,
but
to
go
back
to
how
placement
Works
placement
is
about
filtering
within
the
concept
of
the
cluster
set.
So
you
have
a
number
of
clusters
say
test
clusters
that
are
available
in
a
cluster
set.
A
You
can
apply
your
app
to
one
or
more
of
those
clusters
using
labels,
labels
such
as
North
America
or
labels
such
as
a
region
like
U.S,
east
or
even
more
detailed
labels
such
as
uat
or
Josh's
since
I'm,
the
presenter
cluster,
and
so
any
key
label
that
you
find
in
kubernetes
that
is
used
as
selectors
and
deployments
and
stateful
sets
Etc.
This
same
concept
applies
for
placement
resources,
so
you
create
a
custom
resource.
That
is
a
placement.
A
Proxy
is
just
as
it
sounds:
it
is
an
add-on,
that's
available
for
running
on
the
manage
clusters
and
it
exposes
the
API
server
for
that
cluster
on
the
Hub.
What
this
allows
you
to
do
is
Traverse
difficult,
Network
situations
and
or
to
expose
just
the
API
server
of
the
cluster
to
the
needed
individual.
A
The
managed
service
account
add-on
gives
you
the
capability
to
define
a
custom
resource
on
the
Hub
side
that
results
in
a
service
account
being
created
on
the
manage
cluster
side.
Once
this
service
account
is
created,
the
token
is
made
available
on
the
Hub
side,
giving
you
a
means
to
connect
to
that
cluster.
You
can
set
the
expiration
for
the
service
account
and
you
can
also
use
manifest
work
to
deliver
a
role
instead
of
rule
bindings
for
that
service
account
as
well.
A
This
ties
in
well
with
the
proxy
I
just
mentioned
in
the
sense
that
you
can
use
the
managed
service
account
add-on
to
create
a
service
account
a
managed
best
work
to
deliver
the
role
and
Rule
bindings
for
that
service
account
and
then
have
your
controller,
make
a
connection
from
The
Hub
to
the
cluster.
Using
that
service
account
token
via
the
proxy,
and
so
all
of
these
put
together,
give
you
a
perfect
conduit
for
connecting
to
and
managing
within
your
Fleet
of
clusters.
A
Now,
let's
talk
about
some
of
the
new
feature
work,
that's
underway,
a
prototype
that
was
presented
on
August
19
2022
by
one
of
our
community
contributors.
Yuchen
is
about
Standalone
ocm
control
plane
today,
the
control
plane
lives
on
the
Hub
and
is
pods
that
are
running
as
controllers
that
manage
the
inventory
that
we've
talked
about
earlier
in
this
presentation,
as
well
as
the
add-ons
and
the
placement
capabilities.
A
What
wasn't
maybe
made
quite
clear
is
that
the
data
plane
or
what
stores
the
inventory
data
has
always
been.
The
kubernetes
API
server
of
the
cluster,
where
ocm
or
the
registration
controllers
are
running,
and
what
this
prototype
does
is
turn
that
not
on
its
head
but
takes
that
data
plane.
That
is
the
hosting
cluster
and
moves
that
into
a
virtual
API
server.
A
So,
instead
of
using
the
API
server
and
etcd
of
the
Hub
server
to
store
artifacts
like
the
manage
cluster,
the
policy
add-ons
Etc,
we
make
a
change
and
use
a
virtual
API
server
running
on
a
cluster
with
an
NCD
backing
that
is
also
running
on
that
cluster.
This
was
made
possible
by
changes
that
were
made
to
the
registration
controllers.
The
placement
controllers,
as
well
as
that,
are
being
contributed
as
I
present.
This
changes
in
policy,
as
well
as
application
to
run
in
what
we
call
hosted
mode.
A
What
hosted
mode
gives
you
is
the
ability
for
the
controller
to
run
on
one
cluster
but
Point
its
API
input
to
another
URL.
This
allows
the
data
plane
for
these
controllers
to
be
a
virtualized
API
server.
That
could
be
a
completely
virtual
API
server,
pod
and
NCD
like
there
is
in
this
example.
If
you
go
and
watch
the
video
demonstration,
it
also
means
that
other
virtualized
control
plane
pieces
can
be
serviced
by
the
controllers
as
well.
A
A
Posted
mode
is
the
idea
that
a
pod
may
be
running
in
a
kubernetes
distribution,
but
its
data
plane
or
the
API
server
that
it's
pointing
to
is
different
than
that
kubernetes,
where
it's
running
this
could
be
a
virtualized
API
server
or
in
theory
just
another
kubernetes
distribution,
that's
running
with
a
different
API
server,
URL
hosted
mode
for
the
controllers
on
the
Hub
it
into
grooves,
such
as
the
Standalone
mode
that
we
saw
where
you
had
a
virtualized
API
server
as
well.
In
some
investigations,
we've
been
doing
using
kcp
as
a
data
plane
for
our
controllers.
A
Posted
mode
also
exists
on
the
agent
side
and
paste
hosted
mode
on.
The
agents
is
important
because
up
until
this
point,
we've
talked
about
how
an
agent
is
a
pull
technology
by
default,
the
agent
controller
runs
on
the
managed
cluster.
It
connects
back
to
the
hub,
looks
for
work
and
pulls
that
down
to
its
kubernetes
distribution
and
applies
it.
A
What
hosted
mode
does
is
flip
this
on
its
head
and
imply
that
you
can
run
the
clusterlit
agent
on
the
kubernetes
that
is
hosting
the
control
plane,
so
the
Hub
itself,
and
it
will
connect
to
an
API
server
that
is
different
than
that
cluster,
which
in
this
case
would
be
the
managed
cluster
or
remote
cluster.
And
so
in
this
type
of
scenario,
there
is
no
actual
pods
running
on
the
managed
cluster
itself
from
the
agent
and
the
cluster
lid.
A
They
are
running
Hub
or
maybe
even
on
an
intermediary
kubernetes
distribution
and
then
those
that
those
pods
are
connecting
out
to
the
final
managed
cluster
and
at
doing
their
work.
It
still
means
that
the
crds
for
manifest
work
etc
are
applied
to
the
system,
but
the
actual
pods
that
are
doing
the
execution
are
running
outside
of
that
cluster.
A
One
last
use
case
for
hosted
mode
is
to
support
multiple
hubs.
What
I
mean
by
that
is,
you
can
have
more
than
one
Hub
running
its
cluster
lid
for
a
managed
cluster
in
hosted
mode
and
those
cluster
Lids
which
run
on
those
two
individual
or
three
individual
hubs
can
all
point
to
the
same
manage
cluster.
A
Another
integration
we've
been
working
on
is
with
kcp
Dev.
We
take
a
look
for
those
of
you
not
familiar
with
what
kcp
is
it's
kubernetes-like
control
plane,
focusing
on
Independent,
isolated
clusters,
known
as
workspaces?
These
are
virtualized
API
servers
and
these
enable
an
API
service
provider
that
is
contained,
I,
guess,
we'd,
say
to
the
minimum
set
of
apis
required
and
is
able
to
obfuscate
the
Clusters.
A
A
So
in
ocm,
we
did
a
prototype
integration,
that's
available
today
for
folks
to
try
and
what
we
did
is
since
ocm
is
aware
of
all
of
these
clusters.
In
the
fleet
we
made
a
way
to
install
the
Sinker.
The
Sinker
is
the
key
part
that
connects
these
virtualized
API
workspaces
in
kcp
with
your
actual
clusters
under
the
covers,
and
again
since
ocm
is
about
Fleet
Management
and
has
knowledge
of
all
these
clusters.
A
It
only
made
sense
for
us
to
do
an
implementation
that
will
help
connect
these
virtualized
workspaces
to
the
fleet
of
clusters
that
we
know
about,
and
so
on
the
ocm
Hub.
We
do
both
a
cluster
set
where
we
bind
a
number
of
clusters
to
it,
and
then
we
bind
that
cluster
set
to
a
specific
workplace
workplace
workspace
in
kcp
and
then
what
happens
is
on
the
ocm
side
when
the
administrator
places
clusters
into
that
cluster
set
the
kcp
ocm,
integration
controller
makes
sure
that
the
Sinker
is
provisioned
on
those
clusters.
A
The
Sinker
points
back
actually
to
a
location
workspace
on
kcp,
which
then
makes
it
available
as
a
cluster
Target
or
sync
Target
or
workloads
in
these
virtualized
workspaces.
So
I
see
a
little
more
detail
of
how
that
works.
You
have
the
kcp
ocm
controller,
which
is
watching
the
workspace
and
through
cluster
management
add-on
gets
you
a
managed
cluster
add-on
that
is
responsible
for
putting
the
Sinker
with
a
manifest
work
down
on
the
manage
cluster
and
also
connects
to
the
manage
cluster
set
with
a
binding,
end-to-end
namespace,
and
it's
that
managed
cluster
set.
A
That's
actually
the
key.
Having
that
linked
to
a
specific
workspace
is
what
allows
the
different
clusters
to
be
chosen
as
Sinker
targets,
and
so
any
clusters
in
those
managed
cluster
sets
with
the
appropriate
labeling
on
them
will
receive
the
kcp
Sinker,
which
points
back
to
the
location,
workspace
and
is
able
to
surface
and
surface
and
service
the
virtualized,
API
control
plane
and
therefore
any
CRS
or
other
resources
that
are
activated
and
exposed
in
the
kcp.
A
So
this
is
a
cross-community
implementation
and
something
that
we
use
internally
already
and
have
verified
as
working
now.
This
project
is
changing
constantly,
mainly
because
kcp
is
under
heavy
development.
So
ever
so
often,
it
is
possible
that
that
there
is
a
break,
but
we
have
been
actively
maintaining
it
and,
as
of
the
last
two
releases
of
kcp,
we've
had
this
capability
functional
and
have
been
using
it
actually
to
test
out
and
build
kcp
development
environments
for
that
Community
as
well.
So
it's
a
nice
example
of
some
cross
community
work.