►
From YouTube: Introduction to CNI, the Container Network Interface Project - Bryan Boreham & Dan Williams
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
Introduction to CNI, the Container Network Interface Project - Bryan Boreham, Weaveworks & Dan Williams, Red Hat
CNI, the Container Network Interface, is a small but critical piece of infrastructure linking runtimes such as Kubernetes and CloudFoundry to dozens of different container network implementations. This session is aimed at users and developers who have little previous knowledge of container networking. Attendees will hear: - A broad overview of what CNI is - What the CNCF-hosted CNI project has delivered - How CNI relates to Kubernetes - How they can get more involved in the project
https://sched.co/Uaif
A
A
A
A
Okay,
okay,
show
of
hands
who
has
used
CNI
get
everyone
bit
of
exercise
after
the
after
lunch.
There
you
go
pretty
much.
Everyone
here
is
used
CNI,
who
who's
written
a
plug-in,
Oh
a
couple
of
people.
Okay,
so
we
do
have
a
deep
dive
session,
which
is
meant
to
be.
You
know
more
deeper
into
the
the
technical
details.
We're
gonna
we're
gonna,
do
an
intro
in
this
session
that.
B
A
A
Okay,
so
yeah
that's
kind
of
our
outline,
but
let's
let
me
see
if
this
thing's
working
now.
Yes,
okay,
let
me
get
into
it.
Ladies,
so
this
is
a
kind
of
overview
picture
of
where,
where
CNI
fits
into
the
the
cloud
native
world
so
top
left,
we
have
a
container,
which
is
what
we
we
attach
networks
to
in
the
kubernetes
world.
That's
going
to
be
a
pod,
a
group
of
containers,
but
one
thing
will
probably
repeat
a
few
times
is
CNI
is
not
tied
to
kubernetes.
A
Cni
was
created
as
a
common
interface
that
could
be
used
by
any
container
runtime
and
any
network,
so
so
we'll
probably
refer
to
kubernetes
a
lot,
but
but
there's
no
there's
no
strong
tie
between
the
two
could
see.
Nis
is
agnostic,
so
the
runtime
over
on
the
left
is
something
like
kubernetes.
Cni
is
also
used
with
me.
Sauce
Cloud
Foundry.
B
A
A
The
runtime
makes
a
call
to
CNI
there's
a
very
small
set
of
verbs
ad
and
L
or
two
of
them.
So
ad
will
add
a
network
interface
to
the
container
and
the
details
of
what
you
would
like
done
are
placed
in
a
JSON
text
which
is
given
to
the
CNI
plugin.
So
the
the
plug-in
comes
from
whoever
whoever's
implemented
a
plug-in
for
your
network.
You
know
that
could
be
a
network.
Vendor
could
be
a
third
party
vendor,
or
some
of
the
plugins
are
owned
by
the
CNI
project
and
we'll
we'll
talk
about
those
later.
A
B
So
the
CNM
project
at
its
core
is
two
distinct
things.
The
first
one
is
a
specification
that
documents
what
the
configuration
format
is
for,
how
you
give
the
details
for
what
that
CNI
plug-in
should
do
which
CNI
plug-
and
you
actually
want
to
run,
and
also
the
result
that
that
CNI
plug-in
returns
to
the
runtime,
whether
that's
kubernetes,
maysa
or
anything
else,
and
then
the
second
thing
is
a
set
of
reference
plugins,
and
these
are
intended
to
be
like
the
best
example
of
what
the
CNI
project
thinks.
An
implementation
of
a
C&I
plugin
could
be.
B
They
are
fairly
simple
because
they
have
to
work
with
all
the
different
CNI
or
all
the
different
runtimes
that
work
with
CNI,
and
so
that
means
that
they're
not
tied
to
any
particular
cloud
system
like
kubernetes
or
me,
sauce
or
anything.
They
can
literally
be
run
from
a
command
line
using
the
cni
tool,
which
is
also
a
binary
that
is
produced
by
the
CNI
project,
and
we
have
a
pretty
extensive
set
of
reference
plugins.
You
can
basically
build.
B
You
know
most
of
a
cluster
of
most
of
a
cluster
from
the
plugins
and
those
plugins
are
also
used
by
another
number
of
other
projects,
but
again
they're
only
a
set
of
reference
plugins.
They
have
very
limited
set
of
capabilities,
they're
supposed
to
be
fairly
simple,
and
you
know
we
know
that
a
lot
of
other.
B
There
are
a
lot
of
other
use
cases
that
these
plugins
don't
meet
and
we're
fine
with
that,
because
you
know
networking
is
complicated
and
everybody
has
their
own
needs
from
it.
So
we
provide
these,
but
then
we
also
try
to
make
sure
that
CNI
as
a
project
and
the
specification
part
of
CNI
works
for
many
many
different
CNI
plugins
that
adhere
to
the
standard
and
we
also
link
a
lot
of
those
plugins
from
the
CNI
project
website.
B
It
tries
to
implement
what
is
common
between
all
of
the
different
runtimes,
and
you
know,
as
we
said,
it's
also
used
by
mezzos
Cloud,
Foundry,
pod
man,
cryo,
kubernetes,
container
D
and
a
couple
other
projects
as
well,
and
it
just
the
spec
defines
both
the
configuration,
the
flow
of
execution
of
plugins.
So
the
verbs
that
Brian
mentioned
earlier.
It
also
defines
the
expectations
between
the
runtime
and
the
CNI
plugin
around
things
like
versioning
and
what
the
parameters
are
they
get
passed
between
the
two.
B
What
the
results
are
that
come
back
and
what
version
that
should
be,
and
it
also
we
make
a
big
attempt
to
be
backwards
compatible
or
when
we
are
not
specifically
backwards,
compatible,
show
exactly
what
you
would
need
to
do
to
implement
the
new
version.
But
that
said,
I
think
we
have
four
or
five
versions
right
now
of
the
specification
and
it
is
possible
for
plugins
to
actually
implement
all
of
those
versions,
and
the
project
has
some
helper
code
that
you
can
use
in
your
plugin
to
convert
between
those
versions
and
correctly
implement
the
specification.
B
So
just
a
quick
overview
of
the
configuration
format
like
Brian
said
it's
JSON
based
and
it's
basically
just
key
values
that
get
passed
through.
There
are
a
number
of
well-known
key
values
that
the
spec
itself
defines,
and
those
are
things
like
the
name
of
this
configuration.
What
the
plug-in
is
that
should
be
called,
but
then
there
are
also
plugin
specific
keys
as
well
and
at
least
in
this
example
the
is
default
gateway,
key
force
address,
IP
mask
hairpin
mode.
B
B
It
could
be
DHCP,
it
could
be
I
think
in
this
case,
host
local
and
all
these
are
different
ways
to
figure
out
what
IP
address
your
container
would
get
as
a
result
of
the
cni
operation
and
that's
just
because
everybody
has
different
needs,
and
so
you
know,
CNI
doesn't
try
to
prescribe
one
specific
way
that
things
happen.
It's
a
framework
for
allowing
different
plugins
to
do
exactly
what
you
need
in
your
situation.
A
Try
to
do
this
bit
this
one
me
yeah,
so
this
is.
This
is
kind
of
a
text
version
of
the
picture
earlier,
the
the
commands
add,
adds
a
network
interface
to
a
container,
and
let
me
say
at
this
point
you
can
call
add
as
many
times
as
you
like
the
the
number
one
most
popular
CNI
question
that
we
get
asked
is
how
do
I
do
multi
Network
and
the
answer
is
just
do
it.
A
Check
is
a
new
feature,
so
we
we
realized
that
things
could
go
wrong
after
add,
and
you
know
sometimes,
network
setup
is
kind
of
asynchronous,
or
sometimes
things
change
underneath
the
run
time
and-
and
so
the
purpose
of
or
the
idea
of
check,
is
that
the
run
time
can
call
check
periodically
and
just
receive
a
response
as
to
whether
the
network
is
still
set
up
the
way
it
expects
we,
we
went
through
multiple
iterations
of
how
that
works.
I
think
there's
a
slide
later
on,
specifically
about
check
well.
A
A
This
was
just
kind
of
the
simplest
thing
that
could
possibly
work.
We
probably
talked
a
little
bit
about
ideas
for
how
we
do
that
differently
in
the
future,
but
basically
the
runtime
in
the
case
of
kubernetes,
that's
cubelet
actually
execute
a
CNI
plug-in
as
a
separate
program.
It
feeds
it.
The
JSON,
which
we've
looked
up
some
container
specific
data
that
it
might
want,
and
then
it
gives
a
back
a
response
in
Jason
on
standard
out,
which
is
then
picked
up
by
the
by
the
runtime
buh-bye
cubelet.
In
that
specific
example.
A
B
So
the
the
reference
plugins
we
have.
This
is
kind
of
a
list
of
a
bunch
of
them,
there's
bridge
which
a
lot
of
you
may
be
familiar
with,
because
that's
you
know
usually
the
default,
one
that
you
see
in
examples
out
there
on
the
Internet.
It's
just
a
host,
a
local
bridge
on
that
particular
host
or
that
particular
node.
B
And
then
all
the
containers
are
connected
to
it
with
Vieth
interfaces,
there's
also
VLAN
Mac,
VLAN,
IP,
VLAN
host
device
point-to-point
and
then
over
the
last
I
think
year
and
a
half
or
two
years,
we've
gotten
a
couple
of
Windows
related
plugins.
The
windows
bridge,
one
essentially
duplicates
the
functionality
of
the
Linux
bridge,
plug-in
basically
the
same
constructs
but
on
the
windows
side
and
then
there's
a
Windows
overlay
plug-in,
which
actually
I
believe
uses
VX
LAN
between
two
different
Windows
nodes
to
provide
communication.
A
B
You
for
those,
if
you
have
questions,
asked
them
yep,
so
that's
that
was
great
to
see
before
then.
We
didn't
really
have
a
lot
of
cross
platform
capability
for
CNI,
or
at
least
people
who
had
written
those
had
not
contributed
those
back.
So
thanks
to
Microsoft
for
sending
those
in
on
the
ipam
side,
we
have
hosts
local,
which
takes
a
subnet,
that's
assigned
to
the
node
and
just
distributes
IP
addresses
from
that
subnet
to
containers,
but
only
on
that
node
and
then
there's
a
DHCP
plugin.
B
So
if
you
really
want
to
use
DHCP
with
your
containers,
you
can
do
that
and
then
a
static
plugin
for
static
IP
addresses
and
there's
also
a
number
of
what
we
call
meta
plugins
and
those
are
plugins
that
don't
set
up
any
particular
layer-2
connectivity.
They
don't
set
up
any
IP
address
connectivity
either,
but
they
provide
additional
features
on
top
of
the
other
plugins
and
they're
typically
used
as
chained
plugins,
which
is
I,
think
a
concept
we'll
get
to
in
a
little
bit,
they're,
basically
plugins
that
you
add
on
to
the
end
of
some.
B
You
know
a
chain
of
other
plugins,
so
you'd,
for
example,
have
the
bridge
plug-in
to
set
up
your
actual
interfaces
and
IPAM
plug-in
to
do
the
IP
address
management,
and
then
perhaps
the
bandwidth
plug-in
to
set
some
limits
on
the
bandwidth
going
either
into
and
or
out
of
the
container,
and
these
are
all
maintained
by
the
cni
project
and,
like
I,
said
before,
we
try
to
keep
these
plugins.
The
best
example
of
the
cni
specification
that
we
can.
A
Yeah
so
shout
out
to
all
the
maintainer
two
of
whom
myself,
Brian
and
Dan
are
here
on
the
stage
we
have
a
reasonably
heavy
representation
from
Red
Hat,
somewhat
from
the
core
OS
history
and
and
somewhat
from
the
Red
Hat
history.
But
you
know
pretty
pretty
broad
spectrum
of
people,
there's
no
company
behind
C
and
I,
there's
no
VC
funding.
A
None
of
us
are
becoming
gonna,
become
a
billionaire
of
container
network
interface
specification.
But
but
we
do,
you
know,
I,
think
it's
a
it's
a
kind
of
essential
piece
of
glue
technology
that
everybody
in
the
world
in
the
cloud
native
world
needs
to
needs
to
have
there
and
running
effectively
and
also
you
know,
lots
of
contributors,
lots
of
people
who
are
not
maintained,
errs
but
send
in
fixes.
B
What
it
says,
yeah
we've
done
a
bunch
of
releases
over
the
last
year
of
Lib,
CNI,
Lib,
C
and
I-
think
we
talked
about
it
that
much
previously,
but
it's
kind
of
another
component
of
the
CNI
project.
Besides
the
specification
and
the
reference
plugins
Lib
CNI
is
a
go
library
that
is
meant
to
be
used
by
runtimes
like
kubernetes,
docker,
shim
or
cryo,
pod
man
or
any
of
the
other
pieces
that
actually
use
CNI
as
the
glue
layer.
B
So
it's
really
just
a
convenience
library
to
make
life
easier
for
the
people
who
are
trying
to
integrate
with
CNI
and
we've
done
a
bunch
of
plugin
releases
and
a
whole
bunch
of
commits
in
the
last
year,
as
well
as
a
good
number
of
contributors
from
outside
of
the
core
maintainer
team
and
the
check
function
is
new
and
Brian
talked
quite
a
bit
about
that
configure
result.
Caching
I
just
mentioned,
and
those
are
again
convenience
functions
for
the
runtimes.
B
B
A
Okay,
a
little
bit
about
how
the
project
works.
You
know
I
put
up,
I
put
up
the
list
of
of
maintainer
x'
and
we
we
have
a
weekly
meeting.
Video
call
we're
probably
probably
more
than
half
the
maintainer
of
show
up
every
week
and
we
we
go
through
recent
issues,
recent
PRS
and
so
on.
Just
make
sure
everything's
up
to
date
discuss
discuss
the
future.
Maybe
we
so.
B
B
A
We
don't
want
to
just
go
breaking
things
all
the
time
it
is
currently
at
what
is
it
Oh
point
seven
anyway,
whatever
it's
zero
point
something
and
we
really
want
to
label
at
one
point:
zero,
because
that's
gonna
relax
certain
people
who
who
don't
like
the
don't
like
the
idea
of
an
something
actually
I,
think
I
have
a
slot
slide
about.
What's
what
is
one
Oh,
plugins
yeah?
A
We,
you
know,
we
shove
our
plugin
releases,
quite
often
usually
usually
to
you
know,
fix
little
things
that
have
come
up
and
we
do
get
a
lot
of
a
lot
of
third-party
fixes
to
the
plugins
kind
of
further.
Further
to
what
Dan
said,
you
know
you,
one
thing
that
probably
won't
work
is
to
show
up
and
demand
that
we
do
some
work.
You
know,
even
if
it's
really
important
to
you,
we're
all
kind
of
volunteers.
So
so
what
works
better
is
to
show
up
with
the
fix.
Now
we
need
to
hear
about
the
issues
and.
A
B
So,
what's
next,
like
Brian
mentioned
we'd
like
to
get
the
spec
21.0
there
are
we
consider
the
spec
basically
1.0
at
this
point,
but
there
are
a
couple.
Excuse
me
leftover
things
that
we
want
to
do.
We
need
much
better
test
coverage
on
some
of
the
reference
library,
the
Lib,
C
and
I
reference
library,
as
well
as
the
plugins.
We
also
want
to
review
the
spec.
B
But
that
was
not
actually
clear
in
the
v3
specification
from
I
think
about
a
year
ago,
which
is
probably
when
that
plug
was
last
updated
for
CNI
specifications.
So
we
do,
you
know,
find
things
in
the
field
and
then
try
to
update
the
specification
to
make
sure
that
it's
clear
what
the
contract
is
between
plugins
and
runtimes,
so
to
make
it
easier
to
follow
the
CNI
specification
and
then
last
signed
release
binaries,
that's
something
that
a
lot
of
projects
have
requested.
It's
something
that
we
know
we
need
to
do
and
we
are
working
on
that.
A
And
finally,
pretty
much
yeah
if
you
want
to
get
involved,
I
mean
if
you
just
want
to
chat
to
us,
the
the
slack
we're
now
using
the
CNC
f
slack
for
reasons
but
yeah.
They
maintain
it
and
moderate
it.
So
that's
great
topic,
CNI,
all
the
cost
software's
on
github.
You
can
open
an
issue.
You
can
open
the
PR.
A
A
You
know
most
like
me,
never
say
never,
but
most
likely.
We.
We
would
like
you
to
host
your
plug-in
and
we'll
have
a
link
to
it.
So
yeah
I
think
that's
that's
the
material
we
came
prepared
with
both
of
our
companies
have
booths
that
you
might
manage
to
catch
us
on.
But
if
you
have
questions
in
the
room,
let's
go
it's.
C
C
B
Openshift
supports
chaining
together
any
basically
a
OpenShift
ships
with
a
default
network
plug
in,
but
you
can
change
that
network
plug
in
at
install
time
in
v4
and
that's
through
the
network
operator.
So
you
can
pick
whichever
C&I
plug-in
you
want.
You
could
pick
the
OpenShift
default
ones.
You
could
pick
we've,
for
example,
and
you
can
chain
if
you
pick
a
different
scene.
I
plug
in
it's
that
C
and
I
plug
in
ends
up
writing
out
its
config
file
and
you
can
chain
different
plugins
through
that.
So
it
is
really
all
driven
through
the
scene.
D
A
Think
Dan
gave
this
example
that
you
might
set
up
a
bridge
and
then
allocate
an
IP
address
and
then
maybe
set
up
a
firewall
rule,
and
then
you
could.
What
else
could
you
set?
The
MAC
address.
There's
another
option
on
the
tuning
plug-in,
which
is
to
set
the
MTU,
so
those
those
could
all
actually
be
separate.
A
Well,
there's
at
least
three
separate
CNI
plugins
that
I
just
mentioned,
and
they
they
basically
just
run
one
after
another
and
each
one
modifies
the
network
setup
of
whatever
the
one
before
did
so
that's
a
chain
for
one
network
interface
for
one
container,
going
through
multiple
plugins.
So
you
know
it
doesn't
make
sense
to
to
do
like
we've
net,
followed
by
open
shift
or
something
like
that.
They'll
just
fight,
you
know
they
they
you
can't
mix
it's
not
like
making.
It
is
like
making
a
cake
right.
A
You
know
you
can't
you
can't
just
put
everything
in
the
cake,
but
don't
don't
make
up
metaphors
on
the
fly,
Brian
so
yeah.
So
so,
as
long
as
the
chain
of
things
mix
makes
some
kind
of
sense,
you
can
chain
together
anyone's
anyone's
plugins,
and
all
of
that
is
is
in
the
adjacent
file
that
is,
is
conceptually
defined
by
the
by
the
cluster
admin.
A
I
say
conceptually,
because
you
know
different
implementations
will
do
that
different
ways
and
most
people
are
just
not
interested
that
is
take
the
default,
but
but
that
that
jacent
file
lists
out
the
all
the
different
plugins
that
are
going
to
get
called
and
any
of
the
specific
parameters
that
they
need.
So
that's
does
that
help
on
that
piece
on
the
multiple
plugins
and
then
your
other
question
was
check.
Do
you
want
to
take
that
sure.
B
Maybe
it's
control
plane
is
unhealthy
because
I
can't
talk
to
its,
you
know
master
service
somewhere,
and
if
any
of
these
things
are
not
as
the
plugin
expects,
then
it
should
return
an
error
back
to
the
runtime
and
then
the
runtime
is
supposed
to
do
something
intelligent
with
that
error
like
kill
the
container
so
that
it
can
be
restarted
and
become
healthy.
So
the
run
times
responsibility
is
to
periodically
call
check
on
some.
You
know
defined
interval
just
to
kind
of
health
check.
B
A
So
the
question
is:
does
the
chain
have
to
follow
a
hierarchy,
and
so
it's
linear,
but
it
has
to
make
some
sense
in
that
you
know,
for
instance,
if
you're
going
to
set
the
MAC
address
up,
then
then
first
you
set
the
interface
up.
Then
you
set
the
MAC
address.
So
it's
it's
purely
linear,
but
there
has
to
make
some
sense
in
in
the
sort
of
logic
of
what
you're
actually
doing.
A
Yeah,
so
if
you
created
an
interface
set,
the
IP
address
set
the
MAC
address
and
set
the
far
wall
rule.
Then,
basically,
the
last
three
of
those
could
come
in
any
order.
Well,
actually,
yeah,
probably
the
firewall
rule
will
come
after
the
IP
address.
That's
something
that's
a
very
good
example
of
you
know
what
makes
sense.
The
the
far
wall
rule
is
probably
gonna
need
the
IP
address.
What
appends,
how
you
do
it,
but
that's
a
good
example.
E
A
Is
that
what
you're
asking
yeah
yeah,
so
the
the
add
function
will
go
through
every
plug-in.
In
turn,
the
check
function
will
go
through
every
plug-in
in
turn
and
the
the
dowel
function,
which
takes
an
interface
away,
calls
them
in
the
reverse
order,
which
is
the
smartest
thing
we
could
think
of
doing
inversion.
B
Will
also
call
them
all
in
the
order
and
then
make
sure
that
the
intersection
of
all
the
reported
versions
of
all
the
plugins
in
the
chain
you
know
is
some
other
than
an
empty
set.
And
at
that
point
it's
a
valid
configuration,
because
each
plug-in
in
the
chain
has
to
support.
At
least
you
know
a
version
so
that
they
can
all
make
sure
that
they're
agreeing
on
what
they
the
input
that
they
get.
B
I
mean
I
think
the
answer.
There
is
kind
of
a
mix.
You
know
for
things
that
you
think
that
your
plugin
can
handle
fairly
quickly.
I
mean
you,
don't
necessarily
want
to
block
you
know
for
like
two
minutes
or
something
and
plug-in
set
up,
but
you
know
if
it's
you
know
something
that
you
think
you
can
recover
from
fairly
quickly
or
you
think
there's
a
possibility
of
recovering
from
it's
probably
safe
to
do
that
in
the
plug-in.
But
you
know
if
it's
something
like
your
control
plane
is
not
ready.
B
A
G
We've
not
exactly
CNI,
so
we
do
use
weave
in
our
kubernetes
clusters
and
we
generate
the
config
file
using
V
works
like
cloud
free
books.
So
my
question
is
like
it's
well
documented
that
we
won't
work
with
kubernetes,
1.4
or
below,
but
it's
still
anyway
like
going
forward
that
we
will
stop
working
with
prior
versions
of
kubernetes
or
what
really
defines
that
matrix.
A
Yeah
I
mean
you
know.
If
you
have
very
specific
requirements,
come
come
by
the
booth
and
we
can.
We
can
try
and
help
you
out,
but
yeah
generally
things
stop
working
because
of
new
features
and
and
they're
just
not
compatible
with
with
old
stuff,
but
we
certainly
certainly
would
aim
to
do
two
versions
back
and
usually
much
more
anyway.
Thank
you
we're
at
time.
Thank
you.