►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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.
What Container Runtime Do I Need? - Abubakar Siddiq Ango, GitLab
Speakers: Abubakar Siddiq Ango
Docker made container technology approachable and easy to adopt, but the recent need to replace Docker has opened up several options and complexity, which can be daunting to someone new to Container technologies. Knowing what runtime engine is suited for what type of use case is crucial in making the right choice when reaching for a replacement. In this talk, Abubakar will start with a brief primer about what the Container runtime does, the common ones available, what they have in common and what sets them apart. We will also see different use cases applicable to different container runtime engines. At the end of the talk, the listener will be better informed in choosing the most preferred runtime engine for their workload.
A
Hi
welcome
to
my
session
and
I
hope.
You
are
having
a
great
time
in
Detroit
and
our
workers
dig
angle
and
I'll
be
talking
to
you
about
container
on
time.
Our
first
introductions,
I,
am
a
developer
evangelism
program
manager
at
gitlab.
Mainly
my
role
is
to
find
new
ways
in
creating
content
and
also
helping
my
team
create
the
right
content,
builds
off
leadership
and
can
catch
results
from
the
first
leadership
now
I'm,
also
a
Google
developer
expert
in
cloud
and
a
cncf
Ambassador
I'm,
currently
based
in
The
Hague
Netherlands.
A
A
What
are
containers
this
session
is
meant
for
people
who
are
new
to
Containers.
I
would
like
to
learn
more
about
how
containers
work.
In
the
background
of
starting,
we
assumption
that
the
person
listening
to
this
does
know
a
lot
about
containers.
Now
traditional
deployment
of
applications
once
you've
built
your
software
or
your
team
have
developed
that
awesome
projects
you've
been
working
on,
they
can
either
deploy
it
by
just
installing
it.
Oh,
create
a
VM,
install
a
patio,
install
nginx
and
ship
the
application
to
the
right
folder
and
it
runs.
A
A
Then
came
virtualization
virtualizations,
where
there's
a
layer,
an
extra
layer
on
top
of
the
operating
system,
which
is
the
hypervisor
and
the
function
of
it,
is
to
create
isolated
environment,
virtual
machines
that
contain
operating
system
binary
and
everything
necessary
application
to
run.
But
this
it's
like
a
virtual
machine.
A
So
now,
but
after
so
many
years
it
containers
has
evolved
to
being
able
to
deploy
an
application
with
all
the
dependencies
it
needs
any
container
while
still
having
access
to
the
host
resources
or
the
host
resources
disabled.
The
host
system
is
able
to
access
the
resources
of
the
container,
so
this
happens
instead
of
in
virtualization,
where
you
have
an
A
hypervisor
or
a
software
that
manages
the
creation
of
virtual
machines
in
terms
of
containers,
because
containers
are
mainly
a
group
of
processes
that
are
running
on
the
host
machine
but
isolated
from
other
resources.
A
There's
what
we
call
here,
runtime
container
runtime,
that
talks
to
the
canal
uses
the
canal
to
create
this
isolation
for
your
containers
and
all
the
resources
that
your
container
needs
through
function.
The
main
difference
between
virtualization
is
the
virtual
machines
are
completely
isolated
from
the
host
machine
for
virtualization.
While
for
containers,
your
containers
are
just
a
group
of
processes.
A
Running
on
the
host
machine
were
isolated
from
other
group
of
processes
that
are
running
now.
If
we
look,
basically
how
containers
are
created
is
declined.
Stocks
for
most
of
us
are
used
to
Docker,
desktop
Docker,
see
a
library
just
it
will
talk
around
Docker,
exed,
Stockard
and
so
on,
and
so
for
Docker
build
and
the
client
communicates
with
your
Docker
finds
a
application
of
CLI
communicate
with
the
runtime.
A
The
runtime
is
the
one
that
does
all
the
building
of
the
images
all
the
buildings
of
the
containers
and
communicating
with
the
operating
system,
the
canal
to
do
what
is
required
for
the
canal
to
run
now,
when
your
container
images
are
built,
your
client
also
communicates
with
the
registry
where
images
are
stored
and
can
be
pulled
from
any
time
they
are
required.
Basically,
an
image
is
a
specification
of
how
your
container
should
be
built
when
it
wants
to
run
now.
A
A
It
made
containers
to
to
be
more
easier
to
use.
You
just
need
to
download
the
binary
set
it
up.
You
have
the
docker
CLA
client,
you
have
Docker
demon
running
on
your
system
and
it
creates
the
containers.
But
one
thing:
Docker
did
very
well
which
later
became
a
disadvantage.
Kind
of
is.
It
makes
it
very,
very
easy
to
use
that
when
the
use
of
container
evolved
to
more
complex
use
cases
like
container
orchestration
in
degree
server
environments
during
deployment
at
scale,
it
was
difficult
to
adapt
Docker
to
those
use
cases.
A
Aside
from
Docker
now,
let's
look
under
the
hood
a
bit
of
what
a
container
actually
does
in
the
background
we
know
a
container
basically
is
just
an
isolation
of
processes,
a
group
of
processes
that
are
running
to
execute
or
to
run
your
application.
You
have
your
application.
You
have
the
dependencies
that
your
application
needs
to
run
so
those
dependencies
running
that
have
been
executed
to
run
your
application
runs
as
processes
on
the
host
Linux
environment
now,
but
it
has
an
isolation,
for
example.
A
What
fastest
does
he
has
access
to?
If
it's,
if
you're
within
your
container
CD
slash,
is
executed?
Where
should
it
present
as
the
root
file
system
of
your
operating
system?
If
the
home
director
is,
if
someone
within
the
container
says
okay,
CD
and
tile
symbol,
which
is
home,
we
actually
go
to,
should
it
go,
it
won't
definitely
go
to
the
home
of
the
host
operating
system
of
the
root
user
of
the
host
operate
system.
A
But
a
folder
has
been
designated
for
that
group
of
processes
for
your
container
to
be
seen
as
its
home
now
and
all
this
happen
with
the
use
of
features
of
Linux,
which
are
namespaces
c
groups
and
CH,
which
will
be
looking
more
into
those
now.
The
first
one
is
seeing
truth
now
when
a
process
is
running
on
your
system
on
your
Linux
machine
CH
root
can
limit
where
it
accesses
on
your
file
system,
let's
say,
for
example,
in
the
slide
image
you're
seeing
here
we
have
our
main
Roots
directory
slash
and
we
have
home.
A
We
have
me,
then
within
me,
we
create.
Let's
say
we
created
a
folder
called
tests
and
within
that
test,
folder
we're
not
created
other
system
folders
like
bin
user
and
VAR.
Then
we
jail
a
particular
process
into
the
test
directory
now
drilling
the
process
into
that
Health
directions
that
any
time
means
anytime.
The
process
tries
to
access
a
root
directory.
It
doesn't
go
to
the
parent
root,
it
goes
to
its
own
new
Roots,
which
is
basically
inside
tests,
not
the
main
route.
A
So
this
is
one
way
to
make
sure
processes
or
groups
of
processes
are
limited
to
a
particular
directory
or
section
of
the
file
system.
They
won't
be
able
to
have
access
to
other
parts
of
the
file
system
to
make
any
modification
now.
This
is
not
like
the
most
secure
thing,
because
definitely
there
are
ways
giving
the
right
amount
of
skill
or
given
the
right
amount
of
programming
you
can.
You
processes
can
definitely
jump
out
and
access
the
host
file
system
now
here's
another
representation
of
of
it.
A
A
A
A
A
So
your
container
can
have
its
own
PID
name
species
whereby,
if
there
is
a
a,
if
you
want
to
check
on
pid1
it
there's
a
specified
process
that
is
running
pid1
and
for
network
resources
like
devices
Port
Etc,
there
can
be
an
isolation
of
okay.
This
is
the
eth1
or
eth0
of
your
container
are
not
necessarily
tied
to
the
main
ETF,
zero
or
eth1
of
the
host
operating
system.
So
basically,
namespaces
provides
an
isolation
for
your
container
or
your
group
of
processes
to
tell
them
that.
A
Okay,
these
are
all
the
resources
you
have
access
to,
and
these
are
all
the
resources
within
your
own
environment,
like
your
own
namespace
that
you
can
use
now.
You
have
other
name
sources
like
multi
points
you
have
IPC,
you
have
a
host
and
domain
name
spaces
that
containers
can
take
advantage
of
from
the
namespace
feature
of
Linux.
Now
the
next
thing
is
c
groups,
which
is
for
resource
control.
Now
we've
said
from
the
beginning:
your
container
is
basically
a
group
of
processes
that
are
that
are
executing
towards
a
common
goal.
A
Maybe
running
your
specific
application.
Now
your
container
the
process
within
your
container
can
be
allocated.
Oh,
you
all
should
share
one
gigabyte
of
memory
and
this
number
of
CPU
and
the
secrets
ensures
that
those
processes
stay
within
the
limits
that
has
been
specified
for
them.
If
any
of
the
processes
uses
more
memory
than
allowed
and
they
get
killed
or
and
killed
out
of
memory
kill
or
if
they
start
using
too
much
CPU
than
required,
they
start
getting
slowed
down.
A
So
c
groups
allows
you
to
specify
resource
limitation
for
the
set
of
processes
within
your
container.
Now,
the
image
used
here
is
from
Julia
Evans.
She
creates
very
awesome
representation
of
common
of
terms
of
topics
in
technology.
You
can
visit
on
Twitter
to
check
out
some
of
the
awesome
illustrations
dashes
that
they
have
done
now.
A
A
One
thing
Docker
did
at
some
point
was
to
look
at
oh
there's
a
need
to
have
a
more
representation
within
the
community,
and
one
way
they
can
do
is
to
give
back
to
the
community,
so
they
decoupled
the
docker
binary
into
container
the
runc
and
contributed
it
to
the
community
Through.
The
open
container
initiative.
A
A
It's
like
the
default
that
is
being
used
and
managed
under
oci
as
it's
like
the
main
oci
runtime.
Now,
if
you
look
at
this
illustration
here,
it
shows
where,
when
you
execute
Stockard
Docker
compost,
the
instructions
are
sent
to
Docker
d
and
Dr
D
is
like
demon
the
container
engine,
that's
receiving
instruction
and
passing
it
down
to
container
d.
Now
between
container,
you
have
the
container
Edition,
which
abstract
some
of
the
low
level
interactions.
A
That
needs
to
be
done
with
the
main
runtime,
which
is
oci
runtime,
that's,
run
C
and
run
C
at
the
end
of
the
day,
creates
all
the
Linux
processes
that
is
required
for
your
container
to
run
now,
as
time
went,
the
community
decided.
Okay,
let's
have
a
standard.
Different
tools
are
coming
up
on,
creating
and
managing
containers.
Let's
have
a
standard
that
is
agreed
on.
Okay,
this
is
what
a
container
should
be
called.
These
are
the
things
the
container
should
do.
This
is
how
your
container
should
be
created
and
so
on
and
so
forth.
A
A
It
is
usually
used,
along
with
a
container
manager
like
container
D
or
Docker
itself
now,
and
this
ensures
the
Heavenly
standard
ensures
that
containers
work
the
same
anywhere
without
your
laptop
on
the
server
or
Cloud.
So
there
won't
be
it
works
on
my
system.
If
it
works
on
your
system,
it
should
work
anywhere
else.
Now
then,
in
if
we
look
at
the
cnco
landscape,
there
are
a
couple
of
containers,
runtimes
that
are
that
have
graduated.
We
have
container
D,
we
have
decree.
A
Iot
is
the
kubernetes
interface
that
was
created
for
runtime
interface
that
was
created
for
communities
to
ensure
that
it's
able
to
communicate
with
different
runtimes.
Now
we
have
a
couple
of
others,
I'm
going
to
be
looking
at
some
of
them
and
they
they
create
and
handle
containers
differently.
Now
the
first
one
is
containerd.
A
Basically,
it
manages
the
complete
container
life
cycle
of
the
host
operating
system,
which
includes
like
image,
creation,
storage,
supervision
and
execution,
and
everything
around
networking
that
ensures
that
it
container
works,
and
it
does
this
by
talking
to
the
low
level
runtime
container
runtime,
which
is
run
C
now
run.
C,
basically,
is
the
low
level
CLI
tool
that
does
all
the
spinning
and
running
of
the
containers.
A
According
to
oci
specification,
that
is
standard
oci
specification
for
Conti
for
creating
containers
so
that
if
a
container
is
created
with
Docker
or
with
a
builder
with
any
runtime
at
all,
it
should
work
regardless
at
any
level
now
run.
C
was
initially
developed
by
Docker
like
initial
area,
but
it
was
donated
to
oci
as
like,
the
first
runtime
spec
compliance.
That's
the
oci
created
like
a
specification
runtime
specification,
and
this
is
like
the
first
one
that
is
compliant
with
the
entire
specification.
A
Now
then,
we
have
creio
now
container
runtime
interface,
now
I,
don't
remember
the
meaning
of
the
oh
but
yeah
creative.
Now
it's
an
implementation
of
the
kubernetes
container
runtime
interface
so
which
enables
any
oci
compatible
runtime
to
be
able
to
work
with
kubernetes.
So
you
can
say:
oh
I
want
to
use
container,
D
or
I
want
to
use
this
or
I
want
to
use
that
in
my
kubernetes
cluster
I
want
to
use
Docker.
A
So
this
container
on
time
interface
allows
you
to
be
able
to
use
previously
kubernetes
both
tied
to
docker,
but
with
the
container
runtime
interface
of
kubernetes
allows
you
to
be
able
to
choose
richer
on
time
to
use
or
you
want
to
use
runc
or
you
want
to
use
device
or
in
the
background,
or
you
want
to
use
something
else.
In
the
background
you
to
run
your
containers,
you
can
do
that
with.
A
A
It
allows
you
to
be
able
to
run
ruthless
containers
as
containers
that
run
within
the
context
of
the
currency,
login
user
and
except
if
it
has
limitations
by
the
way
where
there
are
certain
activities
that
your
containers
cannot
do,
except
when
you
specify
privileged
flag
to
allow
them
to
then
execute
those
commands.
But
if
your
use
case
doesn't
require
any
privileged
use
cases,
podman
is
like
one
of
the
features
for
you
that
is
more
secure
because
it
doesn't
need
any
root
level
access.
Now
we
have
build
that
build.
That,
basically
is
for
building
containers.
A
It
doesn't
run,
it
doesn't
do
any
execution.
It
basically
builds
your
container
images.
You
can
use
podman
with
Builder
I
think
podman
actually
uses
builder.
In
the
background
to
build
images.
Now
we
have
a
Scorpio
which
is
for
inspecting
images
and
also
publishing
your
images
to
do
a
container
registry.
Now.
A
Looking
at
around
C,
we've
talked
before
about
Ron
C,
but
basically
the
goal
of
Rossi
is
to
make
a
standard
for
how
containers
run
anyway
completely
and
the
primary
features
of
vonsi
is.
It
supports
a
full
linuxilium
species.
All
the
non-linear
spaces
run
C
supports
with
a
PID
or
network
command
points.
It
supports
all
of
them
at
the
low
level
and
also
support
security
features
like
SC,
Linux,
Hub,
ammo
and
so
on,
and
because
it
is
it's,
the
specification
for
runs
is
governed
by
the
open
container
initiative,
which
is
unique
Foundation.
A
There
is
guarantee
that
okay
to
still
be
maintained,
unlike
other
ones
like
our
kitty
and
so
on,
which
were
being
really
popular
for
some
time
and
most
of
them
have
been
deprecated.
This
has
a
lot
of
backing
with
it
and
it's
going
to
be
around
for
a
long
time
now,
like
I
mentioned,
it
was
released
as
part
of
Docker
container
platform,
but
was
later
spinned
out.
I
think
local
contributed
a
lot
to
The
Container
ecosystem.
A
Now,
when
we
have
other
runtimes
that
are
that
do
things
a
bit
differently
like
we
said,
containers
are
not
necessarily
isolated
completely
from
your
host
operating
system.
They
are
just
a
group
of
processes
that
are
executing
your
program,
but
in
an
isolated
environment,
but
for
security
concerns.
Some
folks
have
shared
the
concern
that
okay
still
yet
processes
within
containers
can
go
beyond
a
isolation
and
probably
read
some
hard
work
or
escape
from
their
isolation.
A
So
that
is
where
sandbox
container
on
times
comes
in,
like
the
G,
visor
or
Kata,
and
the
way
it
does
is
they
use
virtualization
to
completely
isolate
your
containers
from
The
Host.
So
largely
this.
The
main
reason
behind
this
is
to
have
improved
security,
especially
for
critical
workloads.
Where
you
have
concerns
around.
Oh
distribution
should
be
complete,
especially
in
regulated
environments,
where
security
is
a
very,
very
important,
but,
unlike
simply
just
using
virtualization,
these
runtimes
are
lightweights
and
have
minimal
resource
frequency.
A
Okay,
it's
not
like
it
just
goes,
create
a
battery
box
machine
and
run
your
container
and
it's
no.
The
implementation
is
much
more
lightweight
because
you
need
to
maximize
resources
and
also
have
improved
performance.
Now,
with
this,
let's
see,
if
you
use
cases
the
main
use
cases
for
containers,
the
first
one
is
build
systems,
of
course.
A
A
A
Also
partner
can
be
a
drop
in
replacement
for
Docker.
You
can
install
your
podman
and
even
create
an
alias
to
anytime.
You
execute
Docker.
You
should
call
the
podman
executable
in
your
system.
Now.
Batman
is
part
of
this
Suite
of
tools,
including
Builder,
including
Scorpio
and
Kon
Moon.
You
can
use
all
of
them
together,
while
Docker
provides
everything
in
the
demon,
the
demon
checks,
the
docker
demon
checks
your
container
for
the
entire
life
cycle.
A
Okay,
it's
running
reports
back
no
status
and
everything
podman
creates
the
Works
which
onesie
to
create
the
containers,
but
it
uses
common
to
like
monitor
the
containers
and
handle
any
communication
between
the
containers
and
I'll.
Tell
you,
okay,
this
container
is
dead
or
and
so
on.
Now
then
podman
uses
Builder
to
build
and
distribute
images
and
also
scop
you
to
foreign.
A
A
Or
to
use
create,
Creo
or
to
use
a
Qatar
or
to
use
devices,
because
kubernetes
has
the
container
runtime
interface
so
and
any
oci
compliance
runtime
can
be
able
can
be
blocked
to
the
CRI
kubernetes
to
use
in
running
your
containers,
and
it
does
that
with
1C
just
the
way
the
docker
uses
dock
ID
to
work
with
continuity,
to
run
your
oci
compliant
images.
Now,
basically,
the
wrong
time
you
use
depends
on
what
exactly
your
use
case
is.
A
If
you
are
a
developer,
Docker
should
be
fine
for
you,
as
long
as
you
are
within
the
limits
of
usage
that
Docker
specified
they're
using
Docker
as
a
company
is
becoming
more
difficult
because
they
are
restrictions.
I
would
advise
visiting
Dockers
website
to
learn
if
you
are
able
to
use
Docker.
But
if
you
are
unable
to
use
or
you
want
to
stick
to
the
spirit
of
the
community,
you
can
choose
podman,
you
can
even
use
podman
to
run
your
ports,
not
just
containers,
unlike
Docker,
where
you
cannot
run
a
pod
now.
A
Also
podman
can
be
a
drop
in
replacement
for
Docker,
basically
creating
an
alias
for
it.
All
the
department
create
podma,
a
Docker
pool.
Dockerdstocker.Podman
can't
do
that
now.
My
podman
is
part
of
the
streets
it
uses
common.
In
the
background
to
handle
you
handle
the
monitoring
of
your
containers
and
also
communication.
Docker
demon
does
everything,
but
because
podman
is
demon-less,
he
doesn't
use
a
demon.
It
depends
on
a
couple
of
other
tools
to
do
all
the
activities
needs
for
the
entire
life
cycle
of
your
container.
A
Now,
podman
also
uses
builder
in
the
program
to
build
your
images
and
scope
you
for
inspecting
your
images,
so
you
need
to
to
use
the
full
Suites
to
be
able
to
get
the
full
benefit
of
the
entire
life
cycle.
But
if
you
work
in
a
regulated
environment
or
because
of
this
system
regulation
or
just
your
need,
you
need
a
more
secure
runtime
to
run
your
images
in
a
completely
isolated
environment.
A
Then
gviso,
Kata
and
firecracker
option.
You
can
look
at
and
you
can.
You
can
even
make
your
kubernetes
cluster
to
use
any
of
this
sandbox
run
times
to
run
your
application.
Now,
when
you
are
using
also
know
that,
if
you're
using
kubernetes,
you
can
specify
what
because
kubernetes
previously
kubernetes
basically
was
tightly
copied
to
Docker,
but
after
the
community,
the
coupled
Docker,
which
will
give
give
which
led
to
the
Opera
one-time
R
kubernetes,
is
removing
Docker
and
Etc.
A
No
kubernetes
were
not
just
removing
Docker,
but
it
was
making
it
possible
for
different
oci
compliant
runtimes
to
be
able
to
work
with
communities,
including
docker,
so
elect.
If
you
want
to
use
a
container
with
cubelet
find
you
can
set
it
in
communities,
you
can
check
the
kubernetes
documentation
for
how
to
configure
different
runtime
for
your
kubernetes
cluster.