►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Let
me
briefly
introduce
myself,
I'm
a
software
engineer
at
fibromatic,
mostly
focusing
on
service
and
application
management
on
cubometric
kubernetes
platform
and
I'm
one
of
the
core
maintainers
of
tube
carrier
project
before
we
dive
into
cube
carrier.
Let's
talk
about
kubernetes
operators.
Operators
are
software
extensions
of
kubernetes
which
make
use
of
customer
resources
to
manage
application.
Life
cycle,
including
deployment
upgrades
and
backups
operators,
are
working
nicely
in
single
cluster
scenario.
A
However,
in
the
multi-cluster
scenario,
imagine
you
have
hundreds
of
clusters
or
thousands
of
clusters
managing
application.
Resources
in
every
single
cluster
can
be
complicated
and
the
process
needs
to
be
automated.
Relying
on
a
single
operator
does
not
scale
very
well
in
those
complicated
scenarios.
A
A
A
Then,
let's
talk
about
cube
carrier
in
more
details,
so,
as
I
mentioned
in
previous
slides,
there
are
two
different
types
of
clusters
in
cube
carrier.
One
is
a
management
cluster.
We
call
it
service
hub.
Another
one
type
is
service
cluster,
which
will
be
registered
by
service
providers
and
run
application,
workloads
and
service
instances.
A
A
One
is
a
pro
platform
operator
which
will
operate
the
entire
management
cluster
and
the
managers
could
carry
an
installation
and
the
cubecarrier
accounts
and
another
one
is
a
service
provider
which
will
manage
service
clusters,
for
example,
register
them
to
keep
carrier
management
cluster
and
also
a
service
provider
will
manage
operators
and
the
service
instances
which
are
running
in
the
service
cluster.
A
It
has
a
dedicated
namespace
to
isolate
the
resources
from
each
other,
and
the
cubecarrier
will
create
our
backup
permissions
automatically
for
each
account
to
achieve
multi-tenants
so,
and
so
those
are
basic
concepts
and
the
high
level
overview
of
cubecarrier
architecture.
A
Now,
let's
move
to
the
demo
session
in
the
demo,
I
will
show
you
how
to
manage
a
radius
database
as
a
service
across
multiple
clusters
by
using
cubecarrier.
A
So,
firstly,
let
me
present
today's
demo
setup,
I'm
using
kubromatic
kubernetes
platform
to
create
clusters
in
different
providers,
as
I
mentioned
in
previous
slides
cube
carrier
work
with
any
kubernetes
operators,
any
kubernetes
distributions.
A
Okay,
let
me
share
my
terminal
with
you,
so
so,
as
we
mentioned,
we
have
four
clusters
and
you
can
see
this
is
the
management
cluster
and
the
the
rest
of
the
clusters
are
for
the
service
cluster.
One
two
three
and
the
first
thing
I
would
like
to
show
you
is
about
the
account
that
we
mentioned
in
cube
carrier.
A
A
This
is
a
similar
to
the
subjects
in
the
cluster
row,
binding
and
row
body
of
kubernetes
object
and
the
cube
carrier
will
create
our
back
rules
and
role
bindings
for
the
users
here
to
make
sure
that
those
users
can
have
access
to
this
account.
A
So
this
is,
as
I
mentioned,
this
is
an
example
of
the
provider
and
let
me
show
you
some
examples
of
the
tenant,
so
here
are
examples
of
tenants
account
and
you
can
see
the
rule
is
tenant
and
currently,
in
our
system
we
have
already
four
accounts
created.
Let
me
go
through
them
one
by
one
with
you,
so
the
first
one
is
the
radius
provider
which
will
be
providing
radius
database
services
in
our
demo
and
there's
another
three
accounts
are
tenants.
A
A
So
so
now
we
have
registered
the
service
cluster
to
to
cubecarrier
and
we
have
already
deployed
the
radius
operator
on
each
of
them.
The
nexus
thing
is
to
let
cubecarrier
to
discover
the
crds
of
radius
operator
in
the
service
cluster.
How
can
we
do
that?
We
can
do
that
by
creating
a
catalog
entry
set.
A
So
here
is
an
example
of
catalog
entry
set
and
if
you
look
into
the
discover
configuration-
and
there
is
a
crd
field-
which
you
can
specify
the
cr-
the
name-
that
you
would
like
to
let
a
cube
carrier
to
discover
from
the
service
cluster.
In
my
case,
it's
a
radius
crd
and
also
in
the
exposed
config
you
can
specify
which
fields
of
the
crd
you
would
like
to
expose
to
user.
A
A
A
A
So
you
can
see
there
are
two
offerings
objects
that
are
available
for
the
user
and
those
offerings
are
explained
by
the
names,
for
example,
for
the
first
one.
A
Okay.
So,
as
I
already
mentioned,
we
only
expose
the
service
to
tenant
a
and
the
tenant
b,
but
not
tenancy.
We
can
verify
that
by
checking
the
offerings
objects
in
every
tenant
namespace,
so
you
can
see
for
tenant
a
and
tenant
b.
They
have
two
available
offerings,
but
for
tenancy
there
is
no
offering
in
tenancy.
This
is
because
our
catalog
object
that
we
created
before
doesn't
select
tenancy,
so
tenancy
cannot
see
the
radius
services
okay.
So
it's
time
to
create
a
service
for
the
tenant
for
the
radius
service.
A
A
And
the
you
can
see,
the
real
workload
is
actually
created
in
the
service
cluster,
not
in
the
management
cluster,
and
we
can.
We
can
do
the
we
can't
create
another.
We
can
create
another
service
for
the
tenant
a
but
in
service
cluster.
Two.
A
And
another
thing
I
would
like
to
mention
is
that
all
the
service
instances
in
the
service
cluster
will
be
isolated
for
every
tenant.
For
example,
if
I
create
another
instance
for
tenant
b
in
service
cluster,
two.
A
A
A
A
Okay,
so
now
the
new
service
cluster
is
ready,
which
is
a
service
cluster
three
and
since
for
the
service
cluster
3,
we
have
already
deployed
the
radius
operator,
so
our
our
cat,
our
catalog,
will
automatically
discover
the
radius
service
from
service
3
and
make
it
available
for
both
tenant
a
and
tenant
b.
Let's
try
to
get
the
offering
object
for
tenant
a.
A
So
it
is
quite
easy
in
cube,
carrier
to
register
a
service
cluster
and
make
the
services
available
to
the
end
user
by
the
carrier
service
hub.
Okay.
This
is
all
this
is
all
about
today's
demo,
if
you
have
any
questions,
you
can
send
me
an
email
or
you
can
create
issues
on
our
project
page
on
github
or
if
you
are
interested
in
more
advanced
topics
about
cubecarrier,
you
can
check
out
our
documentation
thanks
for
your
joining
and
attention.