►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
CNI Intro – Bryan Boreham, Weaveworks, & Casey Callendrello, CoreOS (Any Skill Level)
A chance to get introduced to the maintainers and other people working on the CNI project
About Bryan
Bryan is Director of Engineering at Weaveworks, delivering deployment, observability and monitoring for containers and microservices. Previously, Bryan has worked on many kinds of systems including financial trading, factory control and bakery. Outside of work he is a father, a keen cook and a helicopter pilot. Bryan is a maintainer on the CNI project, and also works on Weave Cortex, a scaleable multi-tenant back-end for Prometheus. Previous speaking includes: at FOSDEM 2017, GoLang UK 2016, Cloud Native London meetup, Silicon Valley DevOps meetup.
About Casey
Casey Callendrello is an open-source developer at CoreOS. He is a maintainer for the Container Networking Interface (CNI) project. He also contributes to the the Kubernetes project and the Rkt container runtime.
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
Hey
everybody
thanks
for
coming
to
this
talk,
but
it
appears
that
my
co
maintainer
with
CNI
is
also
late,
so
I
think
the
slides
of
this
will
be
available.
I
must
I'm,
sorry,
I
haven't
uploaded
them
yet
so
you
go
for
those
of
you
are
taking
pictures
you'll
be
able
to
download
the
slides.
So
don't
worry
about
it.
A
If
you
don't
want
to
the
goal
today
was
to
talk
about
half
of
the
time
and
then
have
open
discussion,
the
other
half
of
the
time
this
may
upset
or
gentleman
with
the
recording
but
we'll
try
and
make
it
work.
But
today,
in
this
particular
talk,
we're
just
gonna
do
an
intro
to
the
cni
project,
how
it
is
and
how
it
is
a
part
of,
and
how
is
not
a
part
of
kubernetes
the
project,
since
they
are
in
fact
distinct
and
just
sort
of
an
introduction
to
the
open
source
model
that
we
are
talking
about.
A
So
what
is
the
cni
project
in
this
particular
community?
Cni
means
a
lot
of
things
to
a
lot
of
different
people.
The
CNI
project,
that
is
to
say
the
github
organization
and
the
organization
that
is
part
of
the
CN
CF,
has
two
major
outputs.
The
first
is
a
document
and
some
NGO
libraries
implementing
the
specification
right.
The
document
is
meta
is
a
markdown
file.
It
is
in
github,
we
accept
pull
requests
to
it.
A
It
is
released
and
a
relatively
calm
basis,
implementing
this
specification,
our
goal
library
for
the
run
time,
which
is
to
say
the
collar
and
a
goal,
library
that
is
a
skeleton
for
a
plugin,
so
you
don't
have
to
use
these.
This
is
not
necessary
to
be
a
CNI
plugin.
All
you
need
to
do
is
implement
the
specification
as
with
most
things,
sometimes
the
code
is
the
specification,
but,
technically
speaking,
the
document
is
authoritative.
A
Cni
also
means,
or
more
precisely,
the
CNI
project
also
maintains
a
set
of
base
plugins.
These
were
originally,
incidentally,
part
of
the
same
repository
as
a
specification,
but
it
became
clear
that
that
was
not
necessarily
the
right
choice
because
they
go
with
different
Cadence's
and
while
the
CNI
plugins
are
official,
they're,
certainly
not
necessary
for
use
right.
So
this
set
of
bass
plugins
are
some
pretty
common
interfaces
and
again
these
plugins
don't
actually
have
any
kubernetes
specific
logic
in
it,
because
C&I
is
not
curried
any
specific
plugin.
This
form
into
two
general
categories.
A
A
The
specification
I,
don't
know
how
many
of
you
have
read
any
part
of
the
cni
specification,
raise
your
hand
Oh
excellent,
that's
more
than
I
expected
great.
So
the
specification
it's
a
vendor-neutral
specification,
not
just
for
kubernetes
used
by
mezzos,
Cloud,
Foundry
rocket
and
all
it
defines,
is
an
execution
flow
execution
protocol
for
those
of
you
who
have
discovered
those
of
you.
Some
of
you
may
have
discovered
that
go
on
up
until
go
1.10.
It
wasn't
safe
to
talk
to
namespaces,
wasn't
safe
to
switch
namespaces
in
a
long
run
and
go
process.
A
So
CNI
is
and
always
has
been
a
execution
protocol
around
what
environment
variables
you
set
and
what
you
send
on
standard
in
and
standard
out
right.
So
that
is
the
protocol.
It's
really
really
really
simple:
you
can
implement
a
CNI
compliant
runtime,
using
just
like
bash
and
curl
our
bash
and
a
couple
environment
variables
and
typing
a
file
through
it
right
that
is
the
spec.
It's
not
G
RPC
and
we'll
talk
about
why
it
isn't,
and
we
can
talk
about
people's
feelings
about
this
later
in
the
open
discussion.
A
The
base
plugins,
on
their
hand,
are
a
set
of
common
plugins,
originally
split
off
of
rocket
that
just
essentially
need
a
home
right.
They're
widely
used
a
lot
of
other
cni
plugins
and
medicine.
Hi
plugins
wrap
these
there's
nothing
official
about
these
other
than
in
sort
of
true
open
source
style.
Right,
like
somebody
wrote
them,
somebody
else
started
using
them
and
they
said
hey.
Can
we
put
them
in
your
repository,
like
yeah,
sure
I
don't
care
whatever?
Now
we're
stuck
maintaining
them.
Brian
come
on
on
stage.
A
Brian
Barham
is
from
weworks
another
one
of
the
CNI
maintainer
x'
I'm
late,
hello,
yeah
I
got
lost,
so
who
is
this?
He
a
knife,
reject
us,
no,
it's
five
maintainer
x'
who
are
actively
maintaining
the
project.
This
is
also
in
the
maintainer
his
file
and
there's
probably
90
or
100
contributors,
especially
on
the
plugins
side.
A
So
how
does
the
project
work
I
wish?
I
could
say
that
it
was
more
interesting.
It's
we
meet
once
a
week.
We
consider
pull
requests,
we
discuss
stuff,
the
spec
is
actively
maintained,
but
intentionally
has
a
slow
cadence
because,
as
we
all
know,
bringing
everything
up
to
date
is
difficult,
but
it
does
actually
have
version
reconciliation.
So
the
specification
says
that
plugins
should
be
able
to
handle
multiple
versions
of
the
specification
and
the
go
types
and
the
goal
library
actively
have
inter
version
conversion
utilities.
A
B
I
wanted
to
stress
that
the
there's
no
kind
of
billionaire
backer
to
this
project.
You
know
we,
we
maintain
it
essentially
in
our
spare
time
and
we
rely
on
contributions.
So
we're
really
hopeful
there's
people
in
the
room
who
can
contribute
or
would
like
to
contribute,
but
the
one
thing
that
that
is
kind
of
disappointing
is
when
people
show
up
and
say
you
should
do
this.
Okay
I
was
like
well,
okay,
maybe
I
should.
But
the
list
of
things
I
should
do
is
very
very
long,
and
so
I
just
want
to
stress
that.
Yes,.
A
Right,
we're
pretty
chill
a
pretty
small,
open
source
project.
I.
Think
some
of
the
time
when
there's
friction
between
the
community
is
that
people
want
spec
changes
really
quickly
and
select.
Changes
are
not
easy
to
do
quickly
right
and
we
can't
just
do
it
in
kubernetes.
We
can't
just
we
can't
just
bump
thing
and
move,
but
we
can't
like
move
fast
and
break
things
with
this
back
right
as
much
as
I
would
love
to
I
tried
that
once
already.
A
A
So
what
the
heck
are
we
doing
right,
I
mean
we,
don't
we
like
to
hang
out,
we
sort
of
we
meet
once
a
week
we
get
on
Google
Hangouts.
We
talk
about
feelings
and
weather
and
train
strikes
and
these
sorts
of
things,
and
we
do
try
and
make
progress
of
the
specification,
although
it
may
be
slow
going.
So
the
big
thing
we're
working
on
right
now,
inspect
0.4
is
get
C&I.
Right
now
has
three
RPC
calls,
one
of
which
doesn't
really
count.
A
The
first
one
is
the
one
that
doesn't
count
as
version
which
is
used
internally
to
do
version,
manipulation
and
version
negotiation.
So
it's
only
got
two
function,
calls
which
is
add
and
delete,
and
it
turns
out
that
most
people
kubernetes
being
a
strong
motivating
factor
for
this,
of
course,
is
that
we
need
to
get.
A
A
Know
it
throws
it
away,
it
throws
it
away
and
immediately
enters
the
namespace
and
does
an
IP
net
and
s
like
I.
Do
it
as
an
IP
IP
adder
right,
that's
not
good.
So
we
probably
realize
that
this
is
a
missing
thing,
because
kubernetes
wants
to
be
able
to
restart
independent
of
the
pod
could
really
wants
be
able
to
restart
independent
of
Peter
kubernetes.
A
The
cubelet
wants
to
last
shorter
than
a
pod,
and
so
the
cubelet
needs
to
be
able
to
get
the
IP
address
of
a
running
pod,
which
means
that
we
need
to
add
yeah.
So
that's
the
big
thing
we're
working
on
right
now
and
it
has
way
more
corner
cases
than
we
really
expected.
The
biggest
challenge
forget
was
plug-in
chaining,
because
any
plug-in
in
a
chain
can
delete
change,
remove
anything
any
sort
of
IP
address.
A
So
we
wanted
to
add
the
ability
we
still
wanted
to
maintain
the
ability
for
plugins
to
manipulate
the
state
and
so
get
needed
to
be
sensitive
to
that.
So
the
solution
we
came
up
with
forget
was
something
called
result.
Caching,
where,
when
you
execute
get
the
plug-in
actually
gets
as
its
input.
What
it
produced
for
output
when
it
did
the
add
now
this
may
seem
totally
insane
right,
like
what's
the
point
of
get
well.
A
First
of
all,
it
is
useful
for
the
plug-in
to
be
able
to
say,
hey
I
know
you
asked
me
to
get
this
network,
but
it
doesn't
exist
anymore
or
so
like
null
is
it
null
is
a
really
great
answer
to
have
also,
it
might
be
useful
to
just
say
that
the
network
is
somehow
misconfigured
in
some
way,
so
get
is
called
get,
but
what
it
really
is
is
check
capturing
the
Samantha
cleverness
specification
is
difficult.
This
PR
is
not
yet
merged.
A
So,
if
you
have
opinions
about
how
this
should
be
written
down,
I
would
love
for
you
to
take
a
look
at
the
PR.
We
intend
to
merge
it
in
the
next
couple
of
weeks,
but
like
so
there's
still
time
for
people
in
this
community
people
who
this
spec
is
going
to
impact
to
contribute
to
this
specification,
and
this
means
that
C&I
runtimes
are
now
responsible
for
caching
their
results,
but
we
do
it
in
Lipsy
and
I
for
you,
so
it
should
be.
Ok,
we
don't
expect
this
to
have
a
really
high
impact
on
runtimes
I.
B
Well,
it's
just
that
it
doesn't
have
to
cash.
That's
like
the
default
behavior.
If
you
have
a
plug-in
that
can
fetch
the
data
from
an
authoritative
store
store,
then
you
don't
need
to
cash
it
you
don't
need
to
rely
on
the.
We
wrote
the
caching
to
cover
the
simple
cases.
If,
if
you
have
a
network
that
knows
the
the
one
true
result,
then
just
send
it
back.
A
Right
so
result,
caching,
also
winds
up
being
used
super
useful
to
solve
a
use
case
that
several
members
in
the
community
identified.
Raise
your
hand
if
you
know
what
a
chained
plugin
is
excellent
cool.
So,
although
Cooper
did
all
those
CNI
does
not
support
multi
network
C
and
I
does
support
plug-in
chaining,
which
is
an
opportunity
to
have
a
single
configuration
file
that
execute
multiple
plugins,
where
plugins
one
through
n,
starting
with
zero.
A
So
zero
creates
the
interface
and
one
through
n
can
manipulate
the
networking
state
in
some
way
and
a
canonical
example
of
these
sorts
of
things
might
be
a
TL
or
firewalling
or
port
forwarding
anything
that
doesn't
really
care
about
how
the
network
is
actually
created,
but
just
wants
to
manipulate
existing
State
and
the
spec
says
that
for
add
you
execute
plug-in
a
then
B,
then
C
and
B
and
C
are
passed.
The
result
of
a
well
B
is
passed.
The
result
of
a
C
is
passed
the
result
of
B
generally.
A
It
means
that
C
is
whatever
C
outputs
is
what
the
runtime
knows
exists,
and
because
these
specifications,
because
because
you're
gonna
manipulate
an
interface
when
you're
tearing
it
down,
you
should
do
it
backwards
right.
So,
when
you're
doing
it
delete,
you
should
do
C
than
B
than
a.
But
the
problem
is
that
C
and
B.
If
there's
stateless,
they
don't
know
the
IP
address
that
they
created
so
the
spec
right
now.
It
makes
it
really
really
really
hard
to
make
actually
useful
firewalling
plugins.
A
So
this
cash
thing
well
originally
created
for
get
actually
winds
up
being
super
super
useful
for
real
time
for
real-world
plugins
for
delete
as
well
right
right.
So
the
one
of
the
things
that
I
mentioned.
My
previous
talk,
I,
don't
want
to
like
repeat
myself
too
too
much
but
writing
a
chain.
Plugin
is
really
easy.
You
take
our
scale
library,
maybe
100
lines
of
go
and
so
for
people
who
are
in
network
administrator's
and
if
you
can't
find
a
CNI
plugin
that
does
what
you
want.
That
might
be.
Okay
right!
A
You
don't
need
to
completely
reinvent
the
wheel.
If
you
want
to
do
traffic
tagging-
or
you
want
to
do
something
totally
crazy,
that
is
entirely
Network
specific
to
you
like.
Don't
shy
away
from
some
go
because
it's
really
easy
and
you
only
need
to
write
the
small
amount
of
code
that
adds
the
IP
address
to
the
firewall
and
then
submit
it
upstream,
because,
if
you
have
this
need,
like
chances
are
other
people
have.
This
need
as
well.
A
The
goal
after
0.4
is
to
release
a
zero
point,
is
to
release
1.0.
There
shouldn't
be
any
new
features
in
1.0.
It
should
be
mostly
a
cleanup
of
the
spec
and
sort
of
a
point
of
no
return.
We're
saying
this
is
the
accepted
specification.
The
kubernetes
community
is
very,
very
bad
at
declaring
anything
1.0
and
so
we're
trying
to
break
the
trend.
A
Let's
see
if
we
get
there,
but
so
now,
if
you
want
new
features
in
the
spec,
now
is
the
time
to
start
thinking
about
them,
because
really,
we
hope,
by
the
end
of
the
year,
to
be
done
with
the
sort
of
development
cycle
to
be
able
to
declare
like
know
the
specification
as
implemented
is
more
or
less
what
we
need
it's
fixed.
So
now
is
the
time
to
get
involved
with
the
project
yeah.
B
Let's
be
clear
that
we're
trying
to
freeze
the
spec
at
1.0,
the
the
plugins,
will
continue
to
iterate
as
rapidly
as
as
people
contribute
to
them.
The
no
new
features
doesn't
mean
in
terms
of
things
working
in
your
network.
It
means,
in
terms
of
the
the
cni
spec
that
they're
orchestrators
can
call
into
plugins
through.
A
One
of
the
things
introduced
in
I
didn't
put
this
in
the
side,
but
one
of
the
things
introduced
in
0.3
is
dynamic
configuration.
So
a
protocol
for
runtime
is
to
inject
dynamic
configuration
into
the
into
the
configuration
file
which
is
previously
static,
which
means
that
hopefully,
we're
trying
to
lessen
and
plugins
dependency
on
the
API
server.
So
you
should
be
able
to
get
into
the
container
up,
not
necessarily
in
fire.
A
B
B
C
A
Great
so
see
and
I
will
never
support.
Multi
interfaces
in
its
current
implementation.
Also
1.0
will
not
support
multiple
interfaces
well,
see
and
I
was
always
basically
meant
to
define
sort
of
logically
one
network
or
one
interface
right.
It
supports
multiple
interfaces.
Technically,
it
supports
multiple
IP
ranges.
This
works
more
of
sports
arrays
of
everything
you
want,
but
from
a
logical
perspective,
yeah.
A
So
from
a
logical
perspective,
CNI
is
really
about
like
a
CNI
configuration
file,
tried
to
find
some
logical
network
and
from
the
original
days
of
rocket.
If
you
wanted
to
say,
connect
rocket
to
your
like
a
storage
network
and
to
your
front-end
network,
you
would
say
rocket,
run
net
equals
storage,
comma
front
end
and
you've
got
two
interfaces
in
the
order
that
you
applied.
So
eight
zero
East
one
and
it
was
multi
like
rocket-
has
had
multi
networking
since
they
zero.
A
A
It
is
beyond
a
hack
and
there's
a
molten
salt
in
the
in
the
in
the
there's,
a
melt.
This
author,
somewhere
at
Q
Khan,
we
had
lunch
together,
he's
awesome,
he's
very
smart
and
obviously
it's
extremely
successful
and
it's
it
has
a
need,
but
the
CNI
doesn't
need
to
solve
that.
Kubernetes
needs
to
solve
this
and
we're
actively
working
on
it,
but
not
as
part
of
the
CNI
project.
A
Can
you
tell
the
city
to
be
a
PD
60
votes
so
see
and
I
supports
ipv6
sense
about
a
year
ago
in
terms
of
all
the
CNI
plugins,
the
specification
doesn't
care
right.
It's
the
90
I
pee
adjusts
in
the
specification
as
a
string,
so
it's
specification
is
effectively
always
supported,
ipv6,
but
that
what
good
is
that
do
you
if
no
plugins
support
it
all
of
the
base?
Cni
plugin
plugins
have
supported
it
for
about
a
year
or
a
year,
and
a
half
kubernetes
has
beta
support
for
ipv6.
There's
a
talk
about
this.
A
A
A
Dual
stack
is
effectively
the
same
problem
as
multi
network,
because
it
means
add
arrays
to
things
that
previously
were
single
values,
and
it
also
means
that
services
need
to
in
some
manner
be
topology
aware.
So
it's
a
lot
of
work
to
do
right,
because
a
lot
of
these
are
very
unanswered
questions.
Yes,.
E
A
Actually,
this
back,
if
you
don't
mind
for
CNI
cassettes,
unites
us
and
support
multiple,
like
you're
talking
about
for
dual
stack,
yeah
so
see
and
I.
You
can
return
an
array
of
addresses
and
actually
compliancy
and
I
plugins
generally
tend
to
return
all
the
addresses
not
just
for
the
plug-in
but
all
intermedia
dresses.
So
if
you
have
a
gateway
address
or
a
bridge
address
that
you've
created,
you
return
those
as
well.
You
know
what
I
want
me
to
run.
See
and
I
want
to
do
it.
I'll
create
a
v6
I'll,
create
a
dual
stack.
A
B
And
unrehearsed,
so
the
the
the
spec
was
in
the
very
early
days
single
address
in
the
cni
yeah
spec.
Oh
you
want
to
make
the
font
bigger
yeah.
It
doesn't
but
I'd
like
two
years
ago
or
thereabout.
The
cni
spec
was
modified
to
let
you
return
an
array
of
addresses
and,
and
you
know,
we're
not
we're,
not
just
beating
down
on
kubernetes
here.
B
A
So
traditionally,
in
CNI
versions,
0.1
0.2,
which
didn't
exist.
The
specification
is
that
you
take
the
CNI
configuration
on
disk,
which
has
two
meanings.
The
C&I
configuration
on
disk
has
this
name
here
type,
which
is
the
worst
named
field,
because
it
really
means
plug
in
binary,
name
and
CNI
is
expected
to
decode.
This
JSON
only
look
at
the
version
and
the
type
but
find
a
pioneer
on
disk
in
a
path
with
the
name
p2p
in
this
case
and
then
execute
that
binary
and
pass
this
entire
file
on
standard
in.
A
Right
Cooper,
neti
I
already
said,
is
you
can
put
a
range
there?
You
could
put
anything
you
want
there,
you
can
put
lots
of
configuration
files.
The
spec
merely
says
that
you
need
to
have
version
name
and
type,
and
everything
else
is
free
form
that
will
be
passed
through
right
through
standard
into
the
plugin
for
sure,
and
the
return
type
also
does
well.
B
Well,
one
of
those
invitations
regards
one
interface
right.
If
you
want
two
interfaces,
you
do
that
twice:
yeah
yeah
it!
Well,
it's
yeah!
That's
what
I
was
trying
to
say.
It
has
no
need
to
even
talk
about
multiple
interfaces
because
it
talks
about
one
interface.
If
you
need
to
do
it
twice,
yeah,
if
you
need
three,
do
it
three
times.
A
Well,
no,
you
can
create
multiple
addresses
if
your
plugin
supports
it,
but,
logically
and
in
the
kit
indicate
a
single
see,
my
invocation
will
probably
give
multiple
interfaces,
but
it
the
cni
specification,
includes,
as
a
parameter
the
name
of
the
one
interface
that
should
be
created
in
the
container.
So
logically,
one
interface
in
the
container
should
be
created,
regardless
of
how
many
incidental
interfaces
are
created.
B
F
B
A
So
to
answer
your
your
previous
question:
I
just
executed
this
CNI
configuration,
which
defines
two
ranges
for
IP
allocation
and
but
is
going
to
create
one
interface.
It's
still
going
to
just
create
each
zero,
and
this
is
the
response
that
I
got
I
got
the
name.
I
got
two
interfaces
returned,
one
of
which
is
in
the
container
because
the
sandbox
property
is
set,
and
one
of
which
is
not
in
the
container.
It's
the
host
side
of
the
Vieth.
A
But
we
still
return
this
because
it's
useful,
if
you're
doing
something
like
say,
firewall
chaining,
where
you
want
to
know
you
don't
care
about
what
the
container
is.
All
you
want
to
know
is
as
IP
address
and
the
interface
that
it's
going
to
come
through
in
the
host.
So
that's
why
we
see
two
interfaces
returned,
but
only
one
is
going
to
be
in
the
container
and
we
see
two
ip's
returned
a
v4
and
a
v6
don't
see
and
I
supports
dual
stack
and
I
can
even
do.
A
And
we
can
see
that
my
oh
by
the
way
IP
as
an
IP
right,
is
a
container
runtime
engine
I,
don't
know
if
you
guys
noticed,
but
I
just
did
all
of
this
IP
I
just
of
all
this
namespace
management
with
IP
like
anyways.
So
if
I
do
IP
end
testing
means
to
execute
it
in
the
testing.
Namespace
and
I
have
well
3
because
of
ipv6,
but
I
have
to
inter
I,
have
two
addresses
apply
to
this
interface.
F
A
Not
yet,
but
that's
a
pretty
good
idea,
the
cni
specification
has
a
what
is
essentially
a
limited
templating
language,
not
really,
but
it's
essentially
a
limited
templating
language
where
the
runtime
will
replace
one
variable
with
another.
But
the
runtime
needs
to
know
about
these,
because
these
variables
are
defined
as
part
of
the
specification.
A
B
B
So
somebody
wants
the
annotations
on
the
pod
and
the
next
person
wants
the
annotations
on
the
namespace
and
the
next
person
wants
the
annotations
on
the
node
and
then
we
need
the
name
of
their
a
Z
and
then
we
need
you
know
the
the
there's
essentially
no
limit
to
what
you
might
conceivably
want,
kubernetes
to
pass
to
the
CNI
plugin
and-
and
we
don't
pass
any
of
that.
Well
right
now
we
passed
the
name
of
the
namespace,
the
name
of
the
pod.
B
When
I
say
we
here,
I'm
talking
about
kubernetes,
which
I
didn't
write
so
I,
don't
know
why
I'm
saying
that
so
anyway,
kubernetes
passes
a
few
kubernetes
specific
variables
like
the
namespace
on
the
pod
ID.
And
so,
if
you
really
want
extra
formation,
you
can
hit
the
kubernetes
api
server
with
those
pieces
of
information
and
fetch.
Whatever
else
you
wanted,
and
in
fact
almost
everybody
writing
a
major
CNI
plugin-
does
that
so.
A
Said
we'd
really
like
to
be
able
to
get
a
network
up
without
needing
to
talk
to
the
API
server,
because
those
of
us
who
are
naughty
enough
like
us
to
do
self
hosting
if
your
API
server
is
down
and
your
API
server
is
hosted
on
your
and
your
controlling
is
hosted
in
kubernetes
like
unless
you're
very
careful
you
can
have
a
chicken-and-egg
problem.
Also
lowering
load
is
good
in
general,
so
it's
a
tough
balance.
Yeah.
B
C
A
A
A
Five
minutes
left
anybody
want
to
bring
up
a
really
controversial
topic.
People
are
asking
why
it's
not
a
gr
PC
API.
First
of
all,
because
rocket
is
daemon
list
and,
second
of
all,
because
of
go
in
the
namespaces,
we'll
definitely
consider
making
it
a
JRPG,
RPC
api,
post,
1.0
I,
think
that
is
a
really
good
direction
for
this
back
to
take.
But
right
now
we
have
enough
on
our
plate
and
it
works
we'll
get
to
it
all.
C
A
A
So
if
you
deploy
it
as
a
host
Network
pod
as
a
daemon
set,
then
you
have
all
the
visibility
that
you
have
into
any
other
demon
set
right.
You
can
do
docker
logs.
If
you
can't
use
you
could,
hopefully
you
can
do
cubic
level
logs
if
the
node
is
really
screwed
up,
you
can
do
docker
log
right.
So
one
of
the
things
that
we
do
for
our
core
can
put
there's
nothing
to
do
with
networking,
but
at
core
OS
for
our
core
containers.
A
We
will
bind
mount
the
system
journal
in
to
our
core
pods
so
that
they
actually
log
directly
through
the
journal
to
disk.
So
we
can
do
journal
cuddle
that
doesn't
scale
for
all
pods,
but
it
is
a
reasonable
solution
for
system
pods
like
like
networking
daemon
sets
I.
Think
honestly,
like
kubernetes
logging,
of
course,
is
unsolved
and
we
could
talk
about
this
all
day
and
I
don't
want
to
get
myself
in
trouble.
It's.
B
Like
just
one
point
of
detail,
they
the
plug-in
itself,
which
is
a
little
binary,
gets
exact
by
cubelet
and
inherits
cubelets,
stood
it
out
and
stood
at
error.
Yes,
so
for
most
of
the
simple
cases
the
first
place
to
look
is
in
the
couplet
log,
where
anything,
the
you
know,
a
stack
trace
or
core
dumped
or
whatever
any
anything
like
that.
Any
message
like
that
will
will
appear
in
the
couplet
log,
by
dint
of
the
fact
that
Kubla
exact
it
and
it
inherited
the
studded
error
and
couplet
doesn't
run
in
a
pod,
because
turtles.
A
A
B
G
A
A
A
This
is
the
world
were
yeah
right,
so
see
and
I.
The
specification
has
no
OS
dependencies.
Cni
the
library
for
the
runtime
has
no
Linux
isms
and
doesn't
care.
There
are
some
CNI
plugins
that
have
experimental
windows
support
that
has
not
yet
been
merged.
There's
a
PR,
it's
open,
it
is
welcome
to
be
adopted
and
we
will
absolutely
merge
it.
We
need
help,
especially
with
doing
CNI
integration
tests
for
Windows,
because
none
of
us
particularly
window
savvy
so
I,
is
there
a
Travis
for
Windows
I.
Think
it's
up
there.