►
From YouTube: Running Mesos Frameworks on Kubernetes with the Open-Source Universal Resource Broker - Fritz Ferstl
Description
Running Mesos Frameworks on Kubernetes with the Open-Source Universal Resource Broker - Fritz Ferstl, UNIVA
While Kubernetes continues to gain in popularity for cloud applications, many organizations run popular frameworks deployed on Mesos. The need to support multiple orchestration frameworks can result in added cost and complexity as organizations struggle to manage separate, siloed environments. Based on earlier work done for HPC users, Univa has contributed their Universal Resource Broker (URB) Technology to the Kubernetes community as an open-source project. The freely available software allows any Mesos compatible framework including (including Spark, Hadoop, Storm, Jenkins, Marathon and Chronos) to run along-side native Kubernetes services on a shared Kubernetes cluster providing the opportunity simplify environments and consolidate infrastructure.
In his talk Mr. Ferstl will discuss the challenge of running mixed workloads on Kubernetes, provide an architectural overview of the URB and provide a demonstration of the technology. He will also explain how Mesos users or application developers can get started quickly with the technology, and consider it for use in their own environments and applications.
About Fritz Ferstl
Fritz is the Chief Technology Officer at Univa where he helps set technical direction for the company while also spearheading strategic alliances in EMEA. Fritz is widely regarded as the father of Grid Engine software and its forerunners Codine and GRD. He ran the Grid Engine software business at Sun Microsystems and Oracle taking it from an upstart technology to one of the world’s most widely deployed workload management solutions. Under Fritz's leadership Grid Engine software was open sourced, and grew into a vibrant community. Fritz holds a Masters in Applied Mathematics from the East Bavarian Technical University of Regensburg in Germany.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
So
welcome,
and
thanks
for
everybody
actually
being
here,
I
was
almost
expecting.
I
would
be
speaking
for
in
front
of
a
completely
empty
room.
Lots
of
people
certainly
had
to
cut
flights,
so
so
the
topic
that
I'm
talking
about
is
up
here.
It's
probably
the
most
descriptive
speaker
title
that
you
will
ever
see
in
the
conference
so
pretty
easy
to
understand
what
it
is
about.
A
We
actually
have
products
that
do
work,
load
management
for
a
living
for
many
many
years.
We
do
service
lots
of
really
big
companies,
typically
fortune
100
companies,
with
some
of
the
biggest
clusters
that
you
can
find
out
in
the
industry,
so
like
300
thousand
cores
or
something
like
that
is
not
rare,
and
we
have
built
scheduling
solutions
for
those
types
of
customers
for
a
long
time
and
actually
the
part
of
the
product
portfolio
that
we
have
is
for
facing.
A
Kubernetes
is
bringing
some
of
the
NOAA
knowledge
that
we
have
gathered
over
the
years
into
that
in
in
the
community
space.
So
that's
part
of
what
we're
doing
there
just
by
way
of
further
enforcing
that
point.
So
we
have
customers
in
pretty
much
all
industries
and,
as
I
said,
pretty
big
names
doing
quite
interesting
things
so
they're,
usually
their
value
generation
chain
starts
with
our
product
where
we
manage
their
workloads
and
it's
absolutely
critical
that
our
stuff
runs
their
stuff.
A
They
have
pretty
complex
requirements,
and
so
we
have
lots
of
experience
with
scheduling,
workload,
management,
etc.
Now,
switching
over
to
the
product
that
we
provide
for
communities
the
product
family
is
called
nabobs,
it
does
a
number
of
things.
The
key
point
is
that
we're
trying
to
help
you
make
use
of
your
kubernetes
cluster
as
good
as
possible,
meaning
getting
the
most
out
of
it.
A
A
One
of
our
core
products,
which
is
called
name
ups
command,
which
provides
this
virtual
multi-tenancy
that
I
mentioned
from
an
architecture
point
of
view.
The
way
how
it
works
is
that
we
basically
have
implemented
a
scheduler
that
is
compliant
with
the
community
scheduler
interface,
so
it
can
be
used
as
a
six-second
scheduler
next
to
the
community
stock
scheduler
and
can
be
used
by
the
workloads,
and
it
provides
a
lot
of
functionality
on
top
of
what
the
stock
scheduler
provides.
A
To
give
you
a
little
bit
more
insight
in
that
architecture,
so
it's
actually
running
as
a
pod
itself
on
top
of
kubernetes,
it
talks
directly
to
the
communities
API
server.
So
from
a
end-user
point
of
view,
you
see
the
difference.
You
just
use
your
Kube
control
to
submit
your
work,
but
our
system
actually
gets
to
know
which
pods
it
is
supposed
to
be
scheduling
and
has
its
own
internal,
persisting
and
so
on
and,
of
course,
the
scheduling
component
that
decides
where
pods
are
running.
A
It
updates
the
API
server,
just
like
the
stock
scheduler
is
doing
it
for
the
administrator.
There
is
an
additional
line
of
interfaces.
If
you
want
to
configure
the
policy,
but
that's
only
for
the
policy
configuration,
so
we
have
a
REST,
API
web
UI
and,
of
course,
also
a
CLI,
the
types
of
policies
that
we
provide.
You
can
see
here
on
this
picture,
so
there
is
things
like
workload,
isolation
so,
for
instance,
runtime
quotas
or
access
restrictions.
A
Workflow
management
I
have
mentioned
that
already
we
can
affiliate
workloads
with
things
like
owners,
projects,
application
profiles
and
inflict
policy
on
workloads
that
have
a
certain
affiliation.
Then
we
have
node
selection
criteria,
for
instance
maximize
utilization,
so
as
opposed
to
just
doing
spread
or
PAC.
We
actually
look
at
the
resource,
consumption
and
place
resort
workloads
where
there
is
the
best
use
of
resources.
A
Basically,
for
these
workloads
and
then
the
most
important
thing
is
workload
priority,
so
we
do
provide
many
ways
of
actually
putting
priority
on
your
workloads
and
then
make
decisions
where
to
put
them
based
on
that
priority
and
pretty
important.
One
of
those
is
what
we
call
proportional
shares
a
picture
of
that
here
so
with
proportional
shares.
You
can
subdivide
your
kubernetes
cluster
in
different
partitions
and
each
of
that
partition
presents
a
represents.
A
A
From
a
general
point
of
view,
regarding
the
capabilities
that
we
bring
to
communities,
I
have
talked
to
a
couple
of
them
like,
for
instance,
this
advanced
multi-tenancy
that
I
just
had
in
the
previous
slide,
or
the
best-fit
scheduling
some
more
things
that
we
do
or,
for
instance,
automatic
eviction.
So
if
you
know
parts,
for
instance,
if
some
of
the
departments
that
I've
mentioned
don't
get
their
fair
share
of
resources
and
others
get
too
much,
then
we
will
automatically
evict
replicas
to
get
the
right
balance.
A
A
We
do
that
by
deploying
a
workflow
management
system
that
is
part
of
our
product
portfolio,
that
handles
non
containers,
workloads
and
we
have
containerized
that
as
basically
a
workflow
management
service
inside
of
kubernetes-
and
you
see
that
here
on
the
picture
to
the
left,
which
is
called
univariate
engine
so
now
switching
over
to
the
universal
resource
broker.
So
really
the
topic
of
the
talk.
A
So
what
is
universal
resource
broker?
It's
first
of
all
open
source.
It
is
a
implementation
of
maysa
compatible
resource
broker.
It
allows
you
to
run
basis
frameworks
really
seamlessly
on
kubernetes
cluster.
So
what
can
you
do
with
it?
So,
first
of
all,
you
can
share
resources
across
mesas
frameworks
and
stand
the
communities
applications.
A
A
A
Implementation,
where
you
run
you
know
missus
as
your
basic
infrastructure
and
then
kubernetes
as
a
a
framework
inside
then
you
still
need
to
know
how
do
I
manage
kubernetes.
How
do
I
manage
basis?
That's
not
necessary
here.
In
this
context,
your
pane
of
glass,
your
single
pane
of
glass,
is
kubernetes.
A
It
helps
you,
obviously,
if
you
want
to
transition
from
mises
to
kubernetes,
then
that
is
a
viable
option.
Let's
say
you,
you
have
some
frameworks
that
you
still
want
to
use
for
at
least
some
time.
Then
it's
very
easy
to
do
that
with
you
or
be
from
overall.
You
know,
architecture,
point
of
view.
What
it
looks
like
is
simply
you
have
your
shared
Mis,
kubernetes
cluster
and
then
on
some
part
of
it.
A
You
run
your
standard,
kubernetes
workloads
and
on
another
part
of
it,
you
run
your
missus
frameworks
and
Mase's
frameworks,
really
that
are
run
there
or
the
instances
the
replicas
they
just
show
up
as
regular
kubernetes
pods.
So
from
a
management
point
of
view,
from
point
of
view
of
like
monitoring,
diagnostics
and
so
on,
you
can
use
all
the
tools
set
that
is
available
in
kubernetes.
You
really
don't
need
to
worry
about
doing
something
different
there
and
also
from
the
missile's
framework
point
of
view.
They
don't
even
notice
that
they
don't
run
under
missiles.
A
They,
you
know
just
think
they
they
are
running
on
the
Missis
control,
a
few
technical
details.
So
how
is
it
actually
being
done?
So
we
have
implemented
a
shared
c+
bribery
that
pretty
much
reimplemented
last
library
that
missus
comes
with,
so
it
implements
the
missus
binary
interface.
We
also
have
provided
a
J&I
wrapper
so
that
you
can
have
your
Java
based
frameworks
talking
to
this
and
then
a
Python
wrapper
again
for
Python
based
frameworks,
we're
currently
working
on
the
HTTP
frameworks.
A
The
system
itself
is
a
master
broker
service,
which
is
a
Python
daemon
and
is
event
driven
through
G
event.
On
the
back
of
it,
there
is
a
read,
spaced
message:
bus
there
are
actually
multiple
implementation
of
backends
for,
u
RB
one
is
for
kubernetes
and
the
other
one
is
for
the
other
product
that
we
sell,
which
is
univariate
engine.
A
A
If
you
want
to
want
it
to
get
started
with
you
or
be
wanted
to
take
a
look,
how
it
works
on
over
tested,
it's
totally
freely
available
on
github,
it's
a
partial
license.
If
you
look
at
get
up
calm,
you
never
cooperation
and
what
you
will
see
is
basically
three
repositories.
One
is
called
you
or
B
core
which
contains
the
core
implementation
of
European
self
and
then
the
adaptors,
one
being
you
RB.
A
Kubernetes
and
then
your
B
grid
engine-
and
it
comes
of
course
with
some
rip
me
with
some
examples
like
marathon
spark
and
so
on
now
over
to
doing
a
little
demo.
I
do
not
believe
in
reliable
networks
at
conferences,
so
apologies
that
I
have
can
this
demo
just
playing
it,
but
it's
really
a
life
demo
that
I've
just
recorded
and
in
in
some
cases
I've
sped
it
up
a
little
bit
to
reduce
the
waiting
time.
A
So
what
I've
set
up
here
is
just
a
kubernetes
cluster
on
gke
simply
two
nodes.
That's
all
that
you
see
running
here
and
then
I
have
a
number
of
things
running.
If
you
look
down
you
have
this
watch
command
as
you
can
see,
and
it
just
filters
out.
Cube
system
stuff,
so
I
have
test
staff,
jobs
for
back-end
and
front-end
project
and
then
I
have
some
production
jobs
again.
I
have
some
back-end
and
front-end
controllers
running
and
down
at
the
bottom.
A
A
A
A
A
Okay,
so
you
saw
those
marathon
chops
coming
to
run
so
I'm,
just
deleting
them,
and
the
next
thing
that
I'm
doing
here
is
Chronos
again
just
the
simple
cromoz
test
jobs
or
creating
a
new
job
again,
some
sleeper
job,
nothing
exciting
here,
just
a
sleep
command
in
this
case
leave
20
seconds
and
I'm
going
to
start
that
job
every
30
seconds.
So
the
intended
behavior
is
a
job.
When
it
started
runs
for
20
seconds,
then
it
finishes,
and
after
10
seconds
we
should
see
another
job
being
started.
A
A
A
Yeah
so,
first
of
all,
the
Mason
framework
has
to
be
containerized
in
this
case
right.
So
in
this
case
we
don't
support
non
containerized,
but
containerize
frameworks.
We
currently
do
not
support
HTTP
we're
working
on
that
so
HTTP
frameworks
wouldn't
work
right
now
from
hardware
point
of
view,
good
question
regarding
GPUs
I
mean
we
have
as
a
company
lots
of
experience
with
GPUs.
A
We
actually
run
some
of
the
most
advanced
GPU
or
machine
learning
environments
in
the
world,
but
with
our
other
products
with
our
more
technical
computing
facing
products,
but
it
would
be
interesting
to
see
how
that
works
in
the
kubernetes
context.
That's
actually
something
that
we
have
not
tried
yet.