►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
CNCF Research User Group - Bob Killen, University of Michigan
This session is open to those interested in running Kubernetes and cloud native platforms in a research context. The CNCF Research User Group’s purpose is to function as a focal point for the discussion and advancement of Research Computing using “Cloud Native” technologies. This includes enumerating current practices, identifying gaps, and directing effort to improve the Research Cloud Computing ecosystem. Mission statement: https://github.com/cncf/research-user-group
https://sched.co/Uaja
A
A
A
I
did
something
dumb:
I
need
to
also
introduce
the
other
people
involved,
so
the
other
co-chair
here,
Steve
Lynette,
it's
right
there
and
our
tech
lead.
Klaus
mah,
unfortunately,
could
not
be
here
today,
but
he
is
pretty
active
within
the
community
as
well.
So
if
you
could
you
see
that
poll
link
down
there,
please
pop
it
open.
B
C
A
A
Anyway,
we
are
seeing
an
increased
use
of
containers
well
everywhere,
we're
seeing
more
complex
workflows
and
not
just
for
the
sort
of
research
process
itself,
but
with
more
enterprises
and
all
sorts
of
groups
sort
of
getting
involved
with
you
know
more
machine
learning
things
like
model
lifecycle
are
becoming
more
important
and
sort
of
riding
on
that.
We're
also
seeing
more
adoption
of
things
like
streaming
data
and
eventing
based
on
that
data,
and
it's
something
that
has
been
historically
not
really
done
that
much
in
our
field.
A
We're
also
seeing
much
greater
use
of
interactive
science
gateway,
so
things
like
Jupiter
hub
these
days
like
that
is
sort
of
becoming
the
de
facto
standard,
especially
in
the
academic
setting
where
you
know
everyone's
getting
notebooks,
that's
their
first
real
experience
with
playing
with
this
stuff
and
backing
those
sort
of
you
know,
science
gateways.
We
see
a
much
greater
demand
on
sort
of
persistent
services,
a
persistent
services
supporting
those
things.
Historically,
you
know
you'd
have
something
like
your
login
node
in
your
workload
manager,
and
that
was
pretty
much
it
now.
A
Everyone
is
spitting
up
a
bunch
of
additional
services
to
just
completely
support
research,
and
all
of
these
things
have
actually
really
lend
themselves
to
kubernetes
and
sort
of
the
cloud
native
ecosystem
as
it
perform
or
provides
a
sort
of
platform
agnostic
api
that
sort
of
gives
us
very
good
primitives.
In
the
scheduling
of
these
different
workloads.
Oh.
A
Why
do
we
actually
want
a
for
our
user
group?
Well,
like
it
or
not,
we
are
a
much
smaller
subset
of
the
users
when
compared
to
something
like
Enterprise,
especially
where
they're
primarily
focused
on
services
and
they're,
not
gonna,
be
spinning
up,
you
know,
possibly
thousands
or
hundreds
of
thousands
of
jobs.
A
The
enterprise
type
services
also
tend
to
like
you
know
they
don't
tend
to
be
as
resource
intensive
and
there's
things
like
you
know.
We
don't
necessarily
want
in
packing
and
beyond
that,
we
require
like
more
advanced
scheduling,
to
support
things
like
MPI.
We
want,
you
know,
fair
share,
backfill
and
whole
slew
of
the
stuff.
That's
come
from
sort
of
the
classic
HPC
world.
A
That's
not
a
saying,
like
you
know,
this
stuff
doesn't
have
MPI
support.
We
do
see
a
little
bit
of
that
in
you
know,
keep
flow
with
the
MPI
operator,
cube
batch
in
the
upstream
project
and
volcano,
a
sort
of
a
more
cloud
native
batch
scheduler
and
all
of
which
are
actually
powered
by
the
upstream
cube
batch,
and
while
all
these
things
haven't
necessarily
been
forgotten
by
upstream,
they
have
very
largely
been
underrepresented.
A
So
the
mission
of
the
CN
CF
research
group
I've
been
involved
with,
like
kubernetes
the
scenes
you
haven't
spoken
with,
like
many
research
groups
over
the
past
couple
years.
Many
of
them
are
sort
of
you
know
grappling
with
the
same
sort
of
problems
and
developing
sort
of
solutions
and
workarounds
in
silos,
and
aren't
necessarily
sharing
this
information
with
each
other.
A
So
at
Cube
Connie
you
earlier
this
year
and
Barcelona,
a
bunch
of
us
actually
got
together
and
so
like
decided,
hey
and
we
needed
something
like
this.
We
need
a
place
where
we,
you
know
researchers,
sort
of
coordinate
their
actions,
bring
that
stuff
upstream,
we
weren't
quite
sure
at
the
time.
So
it
was
going
to
be
a
kubernetes
working
group.
Cn
CF
or
you
know,
working
group
who
raised
user
group
or
CN
CF
thing,
and
it
turns
out
that
CN
CF
research
user
group
was
the
one
that
won.
A
So
we
have,
you
haven't,
been
out
like
working
on
this
stuff
for
too
long,
but
we've
already
sort
of
identified
a
few
common
themes.
We
sort
of
hold
everyone
that
originally
got
involved
and
the
first
one
thing
that
really
counts
like
we
don't
really
know
who's
all
doing.
Research
on
like
ratings
and
research
using
this
stuff
and
everyone
sort
of
feels
like
they're.
You
know
alone
in
the
dark
sort
of
you
know,
humming
their
own
thing
seconding.
A
A
The
other
thing
is
like
urban
aids
itself.
You
know
lacks
sort
of
the
more
advanced
scheduling,
primitives
that
you
know
we
would
historically
use,
namely
being
MPI
and
Co
scheduling,
and
while
there
have
been
the
other,
like
big
thing,
is
we
again
mostly
coming
from
classic
sites?
Things
like
multi,
cluster
and
multi,
user
or
multi-tenancy
are
very
important
to
us
and
there
hasn't
been
like
a
focused
effort
on
getting
a
lot
of
that
stuff
going
upstream.
A
So
what
these
come
themes,
we
actually
started
just
a
couple.
You
know
small
little
missions
again,
this
is
fairly
new,
so
we
haven't,
you
know,
been
able
to
do
too
much,
but
we
created
a
Research
Institute
survey,
so
just
sort
of
asking,
like
you,
know,
who's
doing
what,
if
you're,
if
you're
interested
in
like
you
know,
sharing
if
you're
running
contains
at
a
site-
and
you
want
to
talk
a
little
bit
about
how
you're
doing
it.
A
This
helps
other
research
institutions
sort
of
discover
what
they're
doing,
and
you
know
they
might
ping
you
for
a
few
questions.
If
they're
trying
to
do
something
similar,
what
we
really
want
to
know
like
how
are
you
deploying
it?
How
are
they
managing
it?
How
are
they
handling
like
user
manager
and
things
like
that.
C
A
A
similar
effort
was
actually
done,
I
believe
in
the
OpenStack
community
talking
about
that
stuff
earlier
with
with
a
Steve
and
then
eventually,
you
know
we
might
get
something
more
concise
put
together.
Regarding
that
stuff,
we
also
have
a
just
it's
like
an
awesome
list
of
sort
of
helpful
resources,
so
some
best
practices
regarding,
like
you
know
how
do
you
run
big
clusters,
some
of
the
tools
out
there
like
volcano
Armada,
a
multi
cluster,
scheduler
and
they're,
like
a
few
other
like
little
random
things,
they're
sort
of
helpful
to
us
and
getting
started.
A
We've
also
been
meeting
with
some
of
the
groups
in
the
upstream
community,
like
the
multi-tenancy
working
group,
they're
working
on
a
hierarchical
namespace
controller,
to
sort
of
Wow,
subdivide
out
a
namespace
into
smaller
groups
and
apply
policies
down.
We
are
also
going
to
be
working
with
the
meeting
with
the
multi
cluster
sig
to
help
drive
some
of
the
more
that
stuff
upstream
and
with
that
out
of
the
way,
now
it's
actually
sort
of
like
dive
in
and
have
this
discussion.
A
Oh,
this
is
a
note
with
us
being.
You
know,
researchers
and
data
science,
he
type
people.
The
results
of
this
will
all
be
PR
later
into
the
CN
CF
research
he's
a
group
repo,
so
it'll
be
available
for
anyone
to
play
with
and
take
a
look
at.
If
people
want
I
can
I
think
it
will
will
save,
be
like
names
of
people,
but
I
can
sanitize
that
stuff
out.
C
A
E
A
D
E
Adam
Tillman
from
University
California,
San
Diego,
and
so
we
have
about
100
graduate
students,
you
I'm
sorry,
it's
all
good
yeah
okay,
so
we
have
about
a
hundred
graduate
students
that
are
running
various
either
batch
or
Jupiter.
Interactive
workloads,
data,
science,
machine
learning,
so
we've
got
a
GPU
CPU
cluster.
On
campus,
we
have
a
similar
platform.
D
C
Okay,
so
I'm
Ricardo
from
CERN
we've
been
using
corners
in
production
for
a
while
now
and
we
do
internal
services,
but
one
more
research-oriented.
We
do
offer
what
we
call
spark
as
a
service
where
people
can
just
click
a
button
and
get
a
spark
cluster
that
is
backed
by
a
kubernetes
cluster
and
they
submit
their
spark
jobs
there.
C
We
have
some
Jupiter
and
deployments
that
are
backed
also
by
corners
clusters,
and
this
is
both
for
running
the
notebooks
hosting
notebooks
and
also
offloading
like
larger
computations,
to
also
corners
clusters
and
we've
been
migrating
part
of
our
HD
Condor
batch
farm
to
host
it
on
coronaries,
so
basically
deployed
Condor
on
coronaries.
So
I
think
these
are
the
most
fitting
use
cases
we
have
for
this
community.
D
C
So
we
we
offer
a
kubernetes
as
a
service,
so
it's
very
easy
to
get
your
own
cluster.
So
in
the
end
we
get
way
too
many.
We
have
like
500
clusters,
but
of
those,
if,
like
there's
clusters
that
are
just
test
for
test
purposes,
there's
also
clusters
that
are
for
services
that
are
like
migrating
to
corners
from
traditional
VMs
and
physical
machines.
C
E
A
E
So
we've
got
the
cluster
that
I
personally
manage
is
a
kind
of
monolithic
and
kind
of
located.
A
single
site.
Pacific
research
platform
has
nodes
scattered
all
over
the
west
coast
of
the
US
and
then
I
think
they're
actually
running
multiple
control
planes
and
then
shifting
nodes
between
between
those
as
load
warrants.
D
F
I've
got
a
cold
is
all
about
ready
voice,
Jamie
from
G
research.
We
do
financial
research
over
in
London.
We've
got
quite
a
lot
of
kubernetes
in
production,
mostly
for
services
at
the
moment,
so
something
in
the
order
of
one
hundred
hundred
and
fifty
nodes,
multiple
clusters,
but
our
big
interest
is
working
out
how
to
migrate
our
large
Condor
infrastructure
so
similar
to
what
Ricardo's
go
in
a
way.
B
B
G
So
that's
great
I'm
on
the
I
mean
the
group
that
runs
summit,
but
my
team
specifically
runs
services
around
summit,
so
we
used
to
be
core
infrastructure
and
what
we
had
is
like
lots
of
scientists
like
to
use
lots
of
different
tools,
I'm
an
Operations
guy,
not
a
researcher
by
the
way,
but
they
come
to
us
and
they're
like
hey.
We
need
to
run
this
Maria
DB.
We
need
to
run
this
whatever,
so
we
moved
to
kubernetes
about
I
want
to
say
about
your
and
a
half
ago
in
production
we
rolled
it
out.
G
We've
been
running
it
for
about
two
and
a
half
years
now,
and
it's
really
nice.
We
provide
kubernetes
as
a
service
and
like
also
assistance
with
getting
things
into
kubernetes
to
run
all
of
the
ancillary
stuff
and
our
big
project
right
now
we're
working
on
is
trying
to
get
Jupiter
hub
as
a
service
right.
So
ideally,
there's
like
a
front
end
and
the
scientists
researchers
can
just
like
click
a
button.
They
get
a
Jupiter
hub
that
uses
their
allocation
on
all
of
our
really
big
clusters.
So
that's
what
we're
using
in
production
with.
D
A
D
A
A
D
C
Slurm
is
actually
one
of
our
small
use.
Cases
because,
like
the
main
batch
farm
is
actually
what
we
call
high
throughput
computing,
not
necessarily
HPC,
but
we
do
have
one
large
HPC
cluster,
where
we
run
slurm
and
what
we
are
looking
actually
is
what
was
being
described
before,
which
is
to
simplify
the
life
for
people
submitting
jobs
to
learn,
but
also
analyzing
the
output
data.
C
We
are
looking
into
offering
one
profile
in
the
Jupiter
hub
where
they
will
get
a
notebook
that
gives
them
access
to
the
slum
cluster
and
also
allows
them
to
use
notebooks
to
analyze
the
output,
which
is
like
something
that
is
not
trivial.
To
do.
It's
LARM.
You
would
have
to
copy
the
data
somewhere
else
and
do
your
analysis
so
having
this
in
a
gypped,
a
notebook
actually
I.
Think
it's
a
pretty
good
thing.
E
A
A
Multi-Tenancy
has
definitely
been
a
big
one
that
we've
seen,
especially
for
those
of
us
coming
from
the
classic
HPC
side.
We
are
where
we
are
used
to
sharing
a
large
sort
of
shared
POSIX
environment
and
there
definitely
hasn't
been
a
good
sort
of
translation
over
to
how
you
go
from
like
a
POSIX
identity
to
more
of
like
an
API
identity
where
things
are
running
things
with
services,
there's
definite
been
a
lot
of
efforts
to
sort
of
like
bridge
that
gap
a
little
bit,
especially
in
the
multi-tenancy
working
group
pointing
out
and
over.
D
D
I
I
So
we
actually
have
separate
environments
for
a
restricted
data
compared,
so
we
have
an
HPC,
restricted
data
environment
and
an
HPC
not
restricted
environment,
and
then
we
have
a
private
cloud
for
the
sent
does
the
same
thing.
Basically,
our
university
mandates
that
are
restricted
data
stay
separate,
the
ease
of
use,
so
that
you
know
that
you
know
that's
secure,
because
it's
over
there.
I
So
both
actually
we
whatever
we
build
on
Purim,
we
mirror
basically
and
whatever
we
build
in
the
cloud
we're
mirroring.
So
we
have.
We
are
building
in
public
a
restricted
data
environment,
then
we're
starting
with
AWS
and
then
we'll
slowly,
branch
out
other
things
as
as
people
a
sport
ins,
as
we
sort
of
we
don't
want
to
do
everything
all
at
once,
because
we
don't
have
the
people
to
do
that
and
so
start
one
place
leave,
even
though
the
researchers
were
clamoring
for
Google.
C
A
A
We
have
sort
of
solved
this
a
little
bit
like
we
have
a
set
of
tutorials
that
we
have
or
getting
people
sort
of
up
to
speed
on
kubernetes
and
part
of
that
tutorial.
If
it's
a
research
user,
we
we
get
super
hop
up
and
going
and
show
them
how
to
like
use.
You
used,
you
put
a
lab
and
that
sort
of
thing
you
know
question.
B
A
Chunk
know
that
is
something
that
is
a
I,
wouldn't
call
it
like
low-hanging,
fruit,
low-hanging
fruits,
the
wrong
word.
That
is
something
that
we
should
be
able
to
solve
fairly
quickly.
A
lot
of
us
now
have
experience
with
running
these
sort
of
things,
so
one
thing
that
was
identified,
as
is
building
that
common
best
practices
and
building
out
some
documentation.
A
D
Think
this
sum
relates
to
your
very
opening
question,
asking
saying
everyone,
this
room
or
researchers
but
I'm.
If
I
asked
you
how
many
of
you
are
actual
academics,
there
wouldn't
be
probably
that
many
I
imagine
right
there
or
custodians
of
research
infrastructure.
That's
why
I
tend
to
call
and
then
the
question
is:
how
do
we
make?
How
do
we
empower
ourselves
to
make
the
best
experience
for
our
research
users.
C
A
A
The
other
thing
is
just
you
know,
getting
end-user
feedback
for
some
of
this
stuff
a
lot
of
times.
You
know
something
gets
sort
of
deployed
and,
and
there
isn't
a
good
response,
there's
no
feedback
and
driving
a
stuff
really
really
requires
that
this
has
been
a
fairly
large
problem
in
the
multi
cluster
sig
they've
been
trying
to
get
more
end-user
feedback
regarding
some
of
the
stuff
that
they're
doing
and
for
the
most
part
it's
been
been
pretty
quiet,
they
they're
like
they
want
to.
You
know
accommodate
this
stuff.
D
C
A
H
A
That
I
think
it's
something
we
can
definitely
work
on,
especially
if
we
we
have
the
CN
CF
research
user
group
get
repo.
If
we
want
to
create
a
folder
in
there
and
start
like
dumping,
you
know
some
best
practice.
Some
of
the
documentation
for
stuff
that'd
be
great,
it's
essentially
accessible
to
everyone,
and
you
know
if
something
gets
out
of
date,
it's
just
a
PR
away
from
getting
fixed.
A
One
last
thing:
I
want
to
touch
on
this.
The
batch
by
batch
there's
a
couple
different
efforts
going
on
right
now
on
this.
For
those
of
they
don't
there's
like
queue
batch,
which
is
sort
of
an
upstream
project
to
sort
of
provide
the
base
batch
capabilities.
But
now
we've
sort
of
seen
a
lot
of
being
developed
outside
of
the
kubernetes
project
itself.
A
There
is
a
project
called
volcano
which
actually
is
developed
by
the
the
one
of
the
leads
of
six
scheduling,
who
is
in
a
X
IBM
er
and
they're,
adding
things
like
Hugh's,
fair
share,
backfill
the
stuff?
That's
you
know
pretty
stereotypical
the
things
that
we
work
with
and
then
recently
I
haven't
had
a
chance
to
play
with
it.
It
was
announced
at
SC,
but
Google
just
released
their
sort
of
K
batch
or
batch
on
gke.
A
A
C
J
C
J
A
Yeah
I'd,
actually
it's
still
in
POC
form.
It's
a
project,
I
developed
like
over
a
year
ago
that
would
you
like
an
LDAP,
look
up
and
pull
the
POSIX
identity
from
that,
and
basically
mutate
the
pod
to
run
the
pod
as
that
UID
and
GID.
But
that
does
have
some
other
problems
with
like
adding
that
identity
to
the
container
itself.
Yes,.
B
B
G
That's
that's
exactly
how
we
do
it
right
now,
so
on
all
of
our
kubernetes
hosts,
we
mount
GPFS,
we
mount
NFS
and
we
mount
lustre
and
we
on
every
namespace.
We
have
an
annotation
that
we
set
that's
their
specific
ID
of
their
project
and
then
we
use
OPA
to
force
they're
enforced,
that
their
pods
run
is
that
user,
ID
and
group
ID
and
then
and
then
host
mounted
up
into
the
container.
It's
not
perfect,
but
I
mean
that's.
A
A
J
A
Yeah
I
had
I
had
a
workaround
for
that
one,
but
essentially
it
would
in
a
net
container
that
would
add
the
identity
to
it
and,
like
you,
still
had
some
file
permissions
issues
depending
on
how
it
was
deployed,
but
for
the
most
part
it
worked,
but
we
are
where
I
think
could
now
passed
our
time.
So
I
just
want
to
toss
this
out.
If
this
is
stuff,
you
are
interested
in.
Please
join
the
mailing
list.
Please
join
it
on
some
of
the
calls
that
we
have
our
times
right
now
are
not
West
Coast
friendly.
A
A
K
A
K
H
K
K
K
A
C
H
A
A
K
K
social
kind
of
happy
hour,
so
after
they're
all
attendee
party,
and
it's
not
specific
for
back
up
ones
up
one
there
we
go
it's
not
specific
for
research,
but
it's
for
end
users
generally.
So
it's
six
minutes
walk
from
the
conference
center.
Please
come
along
and
just
go
and
meet
other
people.
There,
Thanks.
F
A
Now
we
should
do
that
outside
though
cuz
there's
a
line
of
people
out
there.
The
Alaska
thing,
if
you
go
to
this
present
a
the
presentation
from
earlier
the
PDF
of
the
research
user
group,
there's
a
bunch
of
links
to
the
other
sessions
that
are
irrelevant
as
a
sort
of
single
source
of
truth
for
them.