►
From YouTube: Keynote: Building Bridges: Cloud Native and High Performance Computing - Ricardo Rocha
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Keynote: Building Bridges: Cloud Native and High Performance Computing - Ricardo Rocha, Computing Engineer, CERN
Kubernetes and Cloud Native have taken over the modern IT deployments, but challenges remain in areas where its impact can still be much larger. The world of High Performance Computing (HPC), often air-gapped, tightly secured and with strong requirements regarding resource sharing for compute intensive workloads has yet to see its needs fully accomplished. This session will cover recent work where the last bits of the bridge are being finished.
A
I
think,
and
the
idea
dave
was
just
mentioning
earlier
about
a
batch,
but
the
batch
working
group
that
we're
forming
in
the
tag
runtime
of
the
toc.
One
idea
here
is
also
to
to
talk
about
this
today,
a
bit
I'll
cover
these
topics,
so
cloud
native
high
performance
computing,
I'm
I'm
a
computing
engineer
at
cern.
I
will
start
with
a
cool
picture
that
I
took
recently,
so
I
had
a
chance
to
go
down
to
the
atlas
detector
at
cern.
A
This
is
the
cavern
100
meters
in
the
ground,
and
I
think
this
picture
is
quite
nice
because
I
like
it
and
also
because
in
the
back
you
see
the
atlas
detector,
and
this
is
where
we
do
the
collisions.
We
have
this
big
particle
accelerator
where
accelerate
beams
of
protons.
We
make
them
collide
at
precise
points
like
this
one,
and
then
we
generate
a
lot
of
data
out
of
these
collisions
and
close
to
this
detector
on
the
ground.
A
We
also
have
an
online
farm
that
will
then
take
care
of
filtering
the
petabytes,
a
second
of
data
that
we
generate
to
something
we
can
manage
on
the
order
of
tens
of
gigabytes.
So
in
this
farm
it's
actually
a
really
interesting
thing,
because
back
in
when
we
started
doing
our
kubernetes
journey
in
2016,
just
one
year
after
this
team
reached
out
and
asked
us,
can
we
actually
use
kubernetes
to
modernize
our
systems
as
well.
So
in
2017
we
gave
it
a
go.
We
built
a
couple
of
thousand
node
cluster.
A
We
saw
a
lot
of
issues
trying
to
do
what
they
wanted
and
what
they
want
to
do
is
to
have
thousands
of
services
running
at
the
same
time
when
they
have
beam
so
that
they
can
do
the
things
I
mentioned,
but
when
there
is
no
beam-
and
we
have
these
periods
where
we
replaced
the
beam
with
a
new
one,
they
wanted
to
reuse
the
farm
to
do
simulation,
which
is
pretty
much
batch
workloads,
so
they
need
to
transition
from
one
to
the
other
very
fast.
They
need
to
schedule
pods
really
fast.
A
At
the
time
we
couldn't
do
this,
we
reached
out
to
six
scalability
that
we
also
heard
jasmine
talking
about
earlier,
and
they
actually
fix
these
issues.
And
today
we
can
have
a
few
thousand
node
clusters.
We
can
have
300
pods
a
second
we
just
heard
which
matches
their
their
needs
and
actually
the
next
generation
of
this
deployment
will
be
based
on
kubernetes.
So
I
think
it
was
a
really
nice
way
to
start
talking
about
cloud
native
and
high
performance
by
showing
this
this
example.
A
So
I'll
also
start
talking
about
high
performance
computing,
with
an
an
overview
of
what
it
means
and
you'll
hear
different
things.
But
I
took
this
one
which
says
that
high
performance
computing
is
most
generally
refers
to
the
practice
of
aggregating
computing
power
in
a
way
that
delivers
higher
performance
than
what
you
would
get
with
a
single
desktop
computer
or
a
workstation,
and
this
is
pretty
much
it.
These
are
the
two
key
points.
How
you
do
this
can
be
a
bit
complicated,
but
the
goal
is
really
to
solve
large
problems
in
science,
engineering
and
business.
A
This
is
a
problem
that
has
to
deal
with
really
large
physics
models
and
they
also
have
one
thing,
which
is:
they
have
to
do
it
quite
fast
with
the
deadline,
because,
if
you're
predicting
the
weather
for
today-
but
you
finish
that
by
tomorrow-
it's
not
so
useful
any
longer.
The
other
area
is
modeling
and
simulation,
and
I
take
aviation,
but
you
can
also
think
about
automotive
industry.
They
do
similar
things
and
then
medical
research
or
vaccine
development,
which
is
something
that
is
quite
recent
in
everyone's
minds
as
well.
A
A
This
is
the
list
from
november
last
year
and
you
can
see,
for
example,
fugaku
in
japan
summit
in
the
us
here
as
well
in
the
u.s,
and
you
can
see
they
are
pretty
large,
like
a
single
supercomputer
like
this
can
have
almost
eight
million
cores
and
they
measure
their
performance
also
in
teraflops
that
you
will
see
in
the
two
columns
after
they're.
Pretty
all
pretty
pretty
pretty
big,
I
put
a
picture
here
of
one
that
is
here
in
europe
and
it's
the
elder
said
in
germany.
A
The
reason
I
put
it
is
because
one
of
my
colleagues
that
I've
been
at
cook
on
earlier
with
as
well,
this
is
lucas,
heinrich
he
just
moved
to
the
center
and
he's
very
keen
on
pushing
cloud
native
and
kubernetes
also
to
transition
their
their
their
deployments
there.
So
I
I
wanted
to
make
a
reference
to
it
as
well,
but
coming
back
to
high
performance
computing,
why?
Why
am
I
talking
about
this?
A
Why
are
we
discussing
it
and
actually
there
are
things
that
are
quite
common
when
you
think
about
very
large
deployments,
you
think
of
large
clusters-
and
this
is
also
what
we
deal
with
in
in
cloud
native
deployments.
You
think
about
resilience,
failover
redundancy-
this
is
all
kind
of
common
themes,
but
there
are
some
that
are
not
so
common
for
most
deployments,
things
like
low
latency
if
you're
deploying
a
lot
of
different
jobs
that
need
to
communicate
with
each
other.
You
need
low,
latency,
you're,
probably
talking
about
deployments
within
fin
events.
A
They're
kind
of
special
in
this
respect
and
you're
talking
about
not
thousands
or
tens
of
thousands
of
services,
you're
talking
about
tens
of
thousands,
hundreds
of
thousands
millions
of
jobs
being
deployed
to
this
cluster,
so
very,
very
high
throughput
needed
done
scheduling
as
well.
Then,
if
you
get
your
deployments
in
and
they
land
on
the
nodes-
and
you
don't
get
the
performance
that
you
need
on
the
nodes
themselves,
then
that's
not
good.
So
numeral
awareness
is
also
very
important.
A
Each
of
them
will
have
a
different
need
in
software,
so
even
pushing
that
software
to
those
nodes
is
an
extreme
challenge,
and
these
are
things
that
have
been
slowly
fixed
in
different
projects
in
cloud
native.
Finally,
I
mentioned
advanced
advanced
scheduling.
I
will
talk
a
bit
more
in
detail
about
that
part
as
well.
A
Now,
if
you
would
be
a
colleague
of
mine
at
cern,
you
would
immediately
say
that
what
we
do
is
not
exactly
high
performance
computing
for
most
of
it,
we
do
what
we
call
high
throughput
computing,
which
is
very
similar,
but
not
quite.
The
description
is
usually
that
it's
a
computing
paradigm
that
focus
focuses
on
the
efficient
execution
of
a
large
number
of
loosely
coupled
tasks.
This
last
bit
is
the
important
one,
so
we're
not
talking
about
tightly
coupled
workloads
any
longer
that
are
typical
in
hpc.
A
We
are
talking
about
workloads
that
don't
have
this
kind
of
close
dependencies
and
they
are
very
independent,
sequential
jobs
that
can
be
individual,
scheduled
on
many
different
computing
resources.
What
we
add
here
is
that
we
start
talking
about
multiple
administrative
boundaries,
which
is
not
typical
in
hpc,
so
we
remove
one
complexity
and
we
add
another
one,
but
actually
that
one
is
very
close
to
the
cloud
native
definition.
If
you
go
to
the
cncf
website-
and
you
check
it,
you
will
see
that
it
talks
about
loosely
coupled
systems
as
well.
A
Now.
The
best
example
I
know
of
high
throughput
computing
is
actually
what
we
do
back
at
cern.
This
is
a
system
called
the
grid
that
we've
been
running
for
for
almost
two
decades
now,
and
it's
really
200
different
sites
across
the
world
all
connected
to
each
other.
But
our
users
see
it
as
a
giant
supercomputer.
We
deploy
the
jobs
there,
they
can
land
on
any
site
as
long
as
the
data
is
available
locally,
but
they
don't
really
talk
to
each
other.
A
If
they
fail,
we
can
retry
it
on
the
other
side
of
the
world
and
everything
keeps
going.
So
it's
really.
The
principle
is
quite
clear.
In
this
area,
so
htc
hpc,
we
drop
low
latency,
we
add
crossing
boundaries,
so
new
complexities,
the
last
bit
I'll
mention
was
advanced
scheduling,
so
we
talked
about
it.
We
heard
about
it
also
about
the
creation
of
the
batch
working
group
and
the
batch
system
initiative.
A
The
reason
here
is
that
when
we
think
of
pods
you're
already
a
bit
too
too
far
too
far
away
in
the
deployment,
when
we
think
about
these
things,
we
think
of
workloads
and
workloads
are
not
just
pods.
They
they
need
to
be
queued
earlier.
They
might
have
complexity
also
on
the
number
of
pods
involved.
So
what
we
like
to
think
is
really
about
the
workloads
themselves.
These
workloads
go
into
queues.
A
These
queues
can
be
from
different
tenants,
different
parts
of
your
teams,
different
projects
and
they
have
to
have
priorities.
So
the
idea
of
having
queues
in
in
the
cloud
native
system
in
kubernetes
is
something
that
is
really
important
for
us.
Then,
when
you
have
queues,
people
have
quotas,
you
don't
want
to
maximize
usage,
then
you
have
to
introduce
the
concept
of
fair
share.
A
So
if
someone
doesn't
have
enough
workloads
to
fill
up
their
quota,
you
want
to
maximize
usage,
then
you
allow
other
people
to
kind
of
still
for
a
bit,
but
over
time
you
want
to
give
everyone
their
fair
share.
And
finally,
we
talked
about
sending
a
lot
of
jobs
that
have
to
talk
to
each
other
for
for
hpc,
which
are
traditionally
mpi
jobs.
A
What
this
means
is
that
if
I
deploy
a
workload
that
needs
100
pods-
and
I
can
only
schedule
80
if
I
would
immediately
schedule
them-
they
wouldn't
be
able
to
do
my
job
and
they
would
just
take
up
resources.
So
we
want
to
make
sure
that,
when
the
if
these
requirements
exist,
we
only
schedule
them
when
all
the
resources
needed
are
available
and
we
maximize
usage
again
and
finally
array
jobs,
kind
of
jobs
that
are
common
in
their
characteristics.
A
When
I
was
thinking
about
this
topic,
I
actually
bumped
into
an
old
article,
at
cern
in
the
cern
courier
that
talked
about
a
null
shift
in
the
paradigm
that
we
were
using
and
what
you
see
here
on
the
right
is
actually
the
same
building
where
we
have
the
data
center
running
today,
but
it
used
to
be
quite
different.
We
had
mainframes
and
the
people
were
actually
working
inside
the
building
and
back
in
the
80s.
A
He
also
mentioned
something
that
says
software
development
would
be
a
challenge
for
this
transition
and
he
says,
fortunately,
some
of
us
had
been
working
with
created,
cern,
adding
some
facilities
to
unix
that
were
vital
for
mainframe
computing,
something
like
batch
scheduler
and
a
tape
drive
reservation
system.
So
this
kind
of
resonates
with
what
we
are
talking
about
batch
workloads
hpc.
All
these
things
are
requirement
requirements
and
they
ended
up
adding
these
capabilities
to
unix.
A
So
that
was
something
that
I
think
they
actually
called
the
system
back
in
the
days
shift,
which
is
really
what
was
happening.
A
big
shift-
and
I
think
we
are
kind
of
at
the
stage
where
we're
trying
to
do
this.
Similar
things
ben
is
also
the
responsible
of
introducing
tcp
at
cern,
which
is
pretty
pretty
amazing.
A
So
if
you
would
think
from
here
like
a
batch
schedule,
a
tape
drive
reservation
system
which
systems
would
actually.
We
would
still
be
using
today
we're
talking
about
the
80s
or
early
90s,
and
if
your
answer
is
batch
or
tape,
let's
see
like
if
you
talk
batch,
this
is
the
same
room
as
it
looks
today.
Large
data
center,
much
more
close
to
what
we
all
have
these
days
and
80
is
back.
A
So
we
are
using
batch
everywhere,
pretty
much
since
then,
but
if
you
said
tape,
reservation
system,
we
actually
also
use
tape,
and
I
just
put
it
here
as
a
curiosity-
we
we
have.
We
use
a
lot
of
tape,
we
put
all
the
data
as
backup
and
tape,
and
we
actually
recall
it
as
well
from
time
to
time
for
things
like
reprocessing
campaigns
and
to
prove
it.
A
I
actually
brought
one
here,
so
I
have
one
of
the
tapes
from
that
we
use
in
the
lhc
for
storage
and
what
I'll
do
is
like
if
you
bump
into
me
in
the
corridor,
and
you
guess,
how
much
storage
we
can
put
in
a
tape
like
this.
You
take
it
home
and
it
has
lhc
data
inside.
So
it's
a
nice
price
to
take
home
as
well.
A
Now,
finally,
I'll
try
to
do
a
quick
demo.
Hopefully
something
will
work.
But
when
I
was
on
tuesday
we
had
a
collocated
event
for
batch
and
hpc
and
there
were
a
lot
of
presentations
about
schedulers
and
I
talked
about
advanced
schedule
needs
and
all
these
things.
So
I
actually
there's
a
project
called
queue
which
is
very
interesting.
There
are
other
schedulers
like
volcano
or
unicorn
as
well,
but
the
presentation
shows
the
needs
we
have,
so
their
presentation
shows
very
much
the
needs
we
have
so
I'd
like
to
show
here.
A
So,
in
the
example
of
the
atlas
queue,
we
can
see
that
it
has
its
own
quota
and
it
goes
to
the
cluster
queue,
but
it
actually
can
borrow
resources
from
from
the
cms
queue
as
well,
if
needed
and
finally
like.
If
you
would
be
an
administrator
and
you
would
realize
that
all
the
queues
are
full,
everyone
is
complaining,
they
don't
have
resources
and
everyone
is
spending
their
workloads.
A
You
could
come
up
with
an
additional
cluster
queue
integrated
into
the
system
in
a
seamless
manner,
for
your
users
and
borrow
like
public
cloud
resources
and
and
kind
of
clean
up
the
cues
and
then
get
back
into
business.
So
that's
what
I
will
try
to
very
quickly
demo.
Now,
thanks
a
lot
for
google
for
helping
me
out
with
the
resources
as
well,
I
think
we
can
switch.
A
A
So
what
I
will
start
by
doing
is
editing
the
atlas
q
and
you
will
see
that
there's
something
that
is
blocking
it
from
going
and
borrowing
the
resources
from
cms,
so
I'll
drop.
That
which
is
this
maximum,
and
if
we
look
here,
the
number
of
workloads
will
be
increasing
in
a
bit,
hopefully
yeah.
So
it's
it
will
pick
up
on
the
on
the
number
of
workloads
that
should
be
deployed
yeah.
A
It
will
take
a
bit,
but
then
basically
you
get.
The
idea
is
that
atlas
would
have
a
number
of
workloads
running.
It
has
a
bunch
of
pending
workloads
as
well,
and
the
idea
is
that
we
start
sharing
resources
between
atlas
and
cms,
and
you
can
see
actually
there's
other
two
queues
that
are
borrowing
there.
So
it's
that's
why
it's
not
immediately
bumping
it
in
so
workloads.
Now
we
still
have
like
390
workloads
here.
So
what
we
want
to
do-
and
I'm
very
much
out
of
time
so
I'll
be
quick.
A
A
A
So
just
one
last
slide,
all
right,
so
kind
of
worked.
But
I
would
like
to
just
to
summarize
here
by
saying
we
are
almost
there
actually
a
lot
of
the
problems
we
we
had
have
been
solved
things
like
the
the
scheduling
problems
we
had
that
have
been
solved
by
api
priority
fairness
and
the
bits
that
we
missed
that
we
discussed
today
are
being
done
by
different
groups.