►
Description
Though containers offer the same application portability and scaling capability when deployed on VMs or BareMetal servers, it is proven to be more performance effective on baremetals. However, there are several challenges to manage the lifecycle of bare metal nodes and Kubernetes under a single umbrella. There are many use cases, for example latency-sensitive applications like CDN, where application providers are made to tradeoff cloud agility with performance-oriented bare metal hosting. With the help opensource CNCF approach, we'll explain bridging this gap with services around dynamic bare metal provisioning, on-demand seamless Kubernetes cluster installation and application deployment orchestrator. With this feature, once can bring cloud-like agility to manage bare metal servers like virtual machines. We are managing 100’s of baremetal nodes distributed across different geo locations across world. Although we have validated the solution around baremetal, same can also be reused to private and public cloud deployments. This enables customers to avail best of both worlds without any tradeoffs, be it on infra flexibility or application performance or security. Also with the application orchestrator, one can easily adapt to distributed application deployment across clouds.
A
Thank
you
so
today,
we'll
be
talking
about
a
very
interesting
topic:
cluster
as
a
service.
So
we
we
are
from
data
communications
me
and
sachin
so
as
as
we
were
already
introduced.
So
we
are
mainly
working
on
two
kinds
of
offering
from
data
communication.
One
is
the
cloud
kubernetes
part
and
then
a
specific
version
for
the
edge
kind
of
deployments.
A
So
me
and
switching
we
both
are
working
on
a
very
similar
solution,
and
so
we
are.
We
are
presenting
a
part
of
that
solution
that
that
we
are
working.
So
the
agenda
for
this
presentation
would
be
basically
to
just
give
a
broad
overview
on
how
the
dc
edge
management
introduction,
tcl
edge
management
and
where
cluster
as
a
service
fits
in
and
why
trust
as
a
service
is
very
important.
A
So
when
we
say
cluster
service,
so
we
already
have
a
lot
of
tools
or
deployment
methods
that
we
have
upstream
like
keeps
tray
or
cops
for
installing
and
managing
kubernetes.
But
there
are
a
lot
of
pitfalls
with
that
in
managing
large
number
of
clusters
and
managing
our
days
day,
one
day,
two
kind
of
operations
on
that.
So
that's
where
the
upstream
project,
australia
is,
is
gaining
a
lot
of
attention
off
rate
under
kubernetes
group.
So
this
is
something
that
data
communication.
A
So
to
start
with,
so
from
from
our
tcl
perspective,
we
are
managing
hundreds
of
clusters
that
are
that
are
spread
across
globe.
So
essentially,
what
we
envision
to
provide
as
a
white
solute
over
white
solution
or
a
white
product
is
a
single
pin
of
class
where
a
user
can
come
in
and
he
can
manage
n
number
of
kubernetes
clusters,
and
so
once
once
a
user
has
provisioned
his
kubernetes
cluster
from
a
single
pane
of
glass.
A
A
Not
orchestrated
by
any
cloud
provider,
so
one
is
on
the
cluster
orchestration,
then
the
application
of
the
station
across
that
cluster.
So
when
we
say
application,
it
could
be
that
container
application
or
still
lot
of
applications
are
in
the
process
of
containerization.
For
them,
we
also
envision
to
provide
a
vm
orchestration
on
top
of
kubernetes,
which
is
also
quite
heavily
used
offline
and,
in
addition
to
that,
will
be
a
generic
monitoring
and
the
logging
capabilities,
along
with
our
native
detox
integration
and
their
second
integration.
A
So
I
will
I
so.
The
overall
session
will
be
split
into
two
parts.
Firstly,
I'll
initially
run
through
the
concepts
of
both
cluster
api,
how
we
explained
the
cluster
api
and
how
we
have
integrated
with
that
manager
and,
as
a
second
part
of
the
presentation
our
section
will
take
over
on
the
demo
part,
and
we
will
create
two
kubernetes
clusters
during
this
demo
and
we
will
see
how
it
comes
up
and
how
we
orchestrate
the
application
on
them.
A
So
as
as
you,
as
some
of
you
might
already
be
aware
of
cluster
api,
which
is
which
is
basically
a
single
set
of
apis.
That
has
been
that
has
been
open
source
from
kubernetes
community
and
it
is
being
used
heavily
now
to
speed
up
a
cluster
on
any
of
the
cloud
provider.
What
you
see
on
the
left
hand,
side.
The
first
block
is
the
extended
plus
the
extended
kubernetes
apis,
which
are
crds
using
which,
from
the
upstream,
what
we
can
do
is
like.
A
We
can
spin
up
cubadium
clusters
onto
any
of
the
cloud
provider
as
of
today,
and
that
has
been
extended
now
with
multiple
bootstrap
providers.
So
it
could
be
that
we
use
the
same
cluster
apa.
With
the
external
version.
With
the
same
principles,
we
would
be
able
to
spin
up
a
k3s
cluster
onto
any
of
the
cloud
provider
that
we
see
on
the
right
hand,
side
or
we
would
be
able
to
spin
up
openshift
clusters
for
openshift
use
cases
or
tata
iks,
which
is
a
tata's
version
of
kubernetes
service.
A
A
We
have
spread
across
like
more
than
28
locations,
which
which
accounts
up
to
around
150
servers
to
200
servers
which
are
managed
by
mass,
and
we
are
using
mass
as
a
interrupt
provider
to
spin
up
a
cluster
on
demand.
So
now,
once
once
the
kubernetes
cluster
is
installed,
that's
just
not
the
only
story,
that's
where
the
story
actually
begins
right.
So
that's
where
the
application
manager
comes
into
the
just.
So
now,
let's
say
let's
say
now:
we
there
is
a
specific
use
case
use
case
for
5g.
A
A
A
What
you
can
see
here
in
this
diagram
is
we
have
clustering
page
that
is
running
the
external
api
that
is
running
in
one
management
cluster
and
using
that
management
cluster.
It's
a
kubernetes
processor
that
could
be
running
anywhere
in
the
cloud
and
that
would
be
acting
as
a
single
control
plane
for
the
cluster
management,
which
will
be
used
to
spin
up
kubernetes
clusters
onto
any
of
the
cloud
providers
that
you
see
on
the
bottom,
so
it
could
be
on
any
cloud
provider
and
to
do
to
achieve
the
same.
A
We
want
one,
three
or
five,
and
similarly,
how
many
number
of
worker
nodes
we
want
and
operating
system.
For
that
then
under
managed
services,
we
will
specify
what
kind
of
application
needs
to
be
running.
So,
as
I
was
telling
earlier,
if
it
is
a
5g
edge,
so
then
we
all
we
have
to
do
is
create
a
template
that
is
required
for
the
app
manager
and
as
soon
as
the
cluster
is
up,
we
as
soon
as
the
customer
of
the
application
will
also
come
up.
B
A
Spike
can
happen
or
quite
frequently
on
an
unnoticed
scenarios.
So
under
such
situations,
ideally,
we
auto
scale
the
cluster
to
an
available
nodes.
If,
if
there
are
no
nodes
available
on
that
cluster
or
if
there
are
no
nodes
available
on
the
data
center
in
case
of
mouse,
then
the
cluster
api
will
be
integrated
to
an
umbrella
api
which
is
managed
by
oss
or
vss.
That
will
trigger
the
first
way
to
to
create
the
kubernetes
on
demand.
So
sometimes
we
see
the
traffic
spike.
There
is
no
resources
on
that
data
center.
A
A
A
Certain
drawbacks:
where
it's
not
a
single
api,
essentially
we
will
have
to
create
machine
deployments.
Machine
deployment
translates
to
the
worker
nodes
that
are
created
from
the
strategy
and
cubadium
control.
Plane
translates
to
the
the
control
plane
node
that
we
have
to
create.
So
then
there
are
others,
the
other
apis,
like
machine
templates,
cubadium
config
templates.
A
A
What
is
required
for
the
prescription
and
along
with
that,
was
the
integration
with
the
application
manager
where,
as
soon
as
the
cluster
comes
up,
it
will
create
a
kind
multicast
track,
which
is
which
is
an
extended
api
again
and
with
the
we
have
provided
a
native
integration
with
auto
scaler.
So
we
auto
scale
that
actually
this
is
available
upstream
cluster,
auto
scaler,
for
which
subscriber
acts
as
one
of
the
provider
like
how
aws
or
gcp
or
azure
can
act
as
a
cloud
product.
A
A
Yeah,
that's
on
the
cluster
api
part
where
we
could
do
the
cluster
orchestration.
So
now
coming
to
the
application
manager.
We
it's
again
custom
api
that
we
have
extended,
which
acts
as
a
globe
global
control
plane.
So
it's
a
kind
multi-cluster
app
using
which
we
can
we
can
we
can
deploy.
We
can
deploy
any
kind
of
any
kind
of
kubernetes
resources
that
you
see
here.
On
the
right
hand,
side
it
could
be
a
kind
deployment,
it
could
be
a
kind
virtual
machine.
A
A
So
this
might
be
seen
a
bit
analogous
to
the
cube
fed
or
the
argo
cd.
There
are
substantial
differences
coming
to
that
part
as
well
flip
fit.
For
example,
it
only
handles
this,
the
cd
part
of
it
app
manager.
What
we
have
is
something
there
is
both
ci
and
cd
flow.
Where
application
build
can
happen
it
can.
A
In
that
perspective,
a
bit
elaborated
information
on
the
same
app
manager.
So,
as
I
was
explaining
so
now,
it's
it's
the
kind,
multiple
strap,
that's
the
cid
that
we
have
developed
and
with
which
we
have
a
native
integration
to
the
gitlab
and
to
the
jenkins.
So
all
we
have
to
do
is
if
we
have
to
use
both
ci
and
cd
part
of
it.
A
So,
ideally,
we
trade
treat
them
as
stages,
so
the
applications
that
we
want
to
deploy
it
can
be
different
in
different
stages.
Each
stage
can
itself
consist
of
multiple
clusters.
What
you
see
on
the
right
hand,
side
the
stage
deployment,
so
a
developer's
cluster
could
be
in
number
of
clusters
where,
on
each
of
these
clusters,
the
application
would
be
required.
A
Similarly,
on
the
stating
there
could
be
a
number
of
classes
on
each
of
the
processors
it
could
be
declared
and
same
applies
to
the
production,
so
the
integration
with
the
cluster
page
that
we
have
done
is
mainly
for
the
cd
part
of
it.
So
as
soon
as
the
cluster
is
up,
we
have
the
applications
coming
up.
So
that's
where
the
cd
comes
in
and
with
this,
ideally,
we
can
offer
complication
cluster
as
a
service,
not
just
cluster.
A
B
B
Similarly,
on
the
worker
side
for
the
managed
application
that
needs
to
be
deployed
once
the
cluster
is
ready,
we
can
specify
what
managed
services
should
be
deployed
after
the
cluster
is
installed
like
for
this
particular
case.
We
are
mentioning
the
prometheus
and
the
fluency
should
be
installed.
Along
with
on
the
cluster
security,
we
need
to
install
oppa
security
once
the
cluster
is
ready.
B
B
B
B
B
B
So
we
can
see,
as
the
cluster
came
up
all
the
applications
that
we
specified
the
networking
driver,
the
oppa
security
policies
that
we
mentioned
the
fluency
and
the
prometheus
all
are
in
our
deployed
status.
Basically,
so
if
we
look
at
any
one
of
the
multi-cluster
app
so
in
the
detail
status,
we
get
to
know
what
all
the
resources
which
are
deployed
for
a
particular
application.
So
this
is
for
open
security,
so
we
can
see
the
cluster
role
rule
bindings.
B
B
D
B
B
B
So,
basically,
the
main
thing
is
from
the
single
api:
we
can
manage
the
cluster
life
cycle,
be
it
creation,
be
it
deletion
or
any
upgrade
suppose
if
you
want
to
upgrade
a
cluster,
so
we
just
have
to
change
the
cluster
version
here
and
apply
the
ml
again.
It
will
automatically
do
in
a
pipeline
format.
It
will
first
upgrade
the
control
plane
and
then
subsequently
the
worker
node.
A
D
A
That's
right,
yeah,
so
we
we
do
have
a
single
pane
of
glass
where
each
of
these
clusters
can
be
independently,
monitored
the
logging
for
the
same
for
each
of
the
cluster
for
each
of
the
applications
and
also
advanced
analytics.
If
you
want
to
do
on
top
of
those
data,
there
is
a
specific
analytics
framework
that
we
have,
that
is
integrated.
So
it's
going
to
be
one
big
orchestrator
under
which
transfer
service
is
one
module
that
we
presented
here.
D
A
A
A
bit
different
way
and
there
are
more
differentiators
when
it
comes
to
connectivity,
so
we
spoke
only
on
the
clusters
creation
application
onboarding.
Now,
if
those
applications
running
on
different
clusters
want
to
interconnect,
then
we
do
have
something
like
a
network
mesh
that
we
can
establish
for
for
these
applications
to
interconnect.
So
there
are
some.