►
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).
Cloud Native Networking for Containers in AWS using CNI Plugins - Anirudh Aithal, Amazon Web Services (Intermediate Skill Level)
The Container networking interface (CNI) project makes it really simple for container orchestrators to configure networking for containers. In this presentation, Anirudh Aithal will provide a detailed walkthrough of developing a plugin, from prototyping to integrating with orchestration frameworks such as Elastic Container Service (ECS) and Elastic Container Service for Kubernetes (EKS). We'll start with a brief introduction of CNI project and plugins. We will also review how CNI plugins enabled us to iterate fast on enabling cloud-native networking capabilities for containers such as routable IPs, network ACLs, firewall rules by provisioning elastic network interfaces on a per-container basis, without modifications to the orchestration framework itself. We will also review the best practices for developing a plugin including testing, logging, versioning and operationalizing the same.
About Anirudh
Anirudh is a Sr. Software Engineer in the Container Services team at AWS. He has been involved with bringing many of the virtual machine abstractions to containers running on AWS including elastic network interfaces, identity and access management and telemetry. He's also a maintainer of a number of projects/github repositories including the CNI plugins (https://github.com/aws/amazon-ecs-cni-plugins and https://github.com/aws/amazon-vpc-cni-k8s) and the ECS agent (https://github.com/aws/amazon-ecs-agent)
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
Welcome
to
the
cloud
native
container,
networking
in
a
double
is
using
CNI
plugin
session.
Obviously,
I
went
for
the
buzzword
bingo
here,
I
tried
my
best
to
shove
in
service
mesh
and
on
were
in
there
to
make
it
cooler,
but
I
fail
on
a
serious
note.
I
know
it's
late
in
the
day.
There's
the
party
to
go
to,
and
some
of
you
are
jet-lagged,
including
myself
and
I,
really
appreciate
your
patience
and
interest.
In
attending
this
session.
A
A
We
have
an
easiest
agent
that
manages
the
state
of
containers.
We
also
have
a
number
of
networking
plugins,
including
the
cni
plugins,
that
are
the
focus
of
today's
session.
My
team
maintains
most
of
that.
You
can
find
me
on
github
in
twitter,
on
my
alias,
so
the
agenda
for
today
is
mostly
covering
the
cni
plugins
that
we
wrote
for
the
VPC
amazon
VPC,
which
is
the
software-defined
networking
solution.
A
So
in
our
customer
conversations
we
heard
requirements
that
could
be
mostly
put
into
three
different
buckets.
The
first
one
is
usability,
so
whatever
networking
solutions
solution
that
we
were
going
to
provide
hard
to
be
super
easy
to
use
and
super
easy
to
integrate
with.
So
what
this
means
is
ask
developers.
All
you
need
to
say
is
my
application
needs
networking,
and
my
application
needs
to
communicate
with
this
other
set
of
applications,
and
that
should
be
it.
A
You
should
be
able
to
use
the
same
abstractions
in
the
cloud
as
you
use
when
you're
developing
code
and
as
an
infrastructure
provider
or
a
network
administrator,
you
should
be
able
to
say
that
you
should
be
able
to
integrate
with
whatever
solution
we
were,
providing
and
bring
in
your
own
custom
interfaces
or
higher
level
constructs
or
higher
level
abstractions.
On
top
of
these
things,
for
example,
if
you
want
to
bring
in
your
own
software-defined
load
balancer
solution,
you
should
be
able
to
do
that.
A
If
you
wanted
to
bring
in
your
own
service
discovery
solution,
you
should
be
able
to
do
that,
and
service
discovery
is
also
interesting.
Example
for
the
next
set
of
requirements,
which
is,
containers
need
to
communicate
with
each
other
I'm
going
to
use
the
word
container
interchangeably
with
pod
in
kubernetes
and
tasks
in
easiest,
so
containers
need
to
essentially
our
applications
need
to
essentially
discover
each
other
and
communicate
with
each
other
using
that
IP
addresses
which
hopefully
are
natively
routable.
A
This
means
that
the
IP
address
that
you
give
the
container
it
has
to
be
routable
from
whatever
top
of
the
rack
switch
or
the
router
that
you
maintain.
The
next
set
of
requirements
were
around
security.
Security
is
something
that
our
customers
care
about
deeply
and
our
tenet
is
being
secured
by
default.
So
what
does
this
mean?
A
It
means
that
container
a
should
be
able
to
isolate
its
traffic
from
container
B
in
the
sense
that
container
we
shouldn't
be
able
to
snoop
on
or
influence
the
pattern
of
container
a
and
even
from
a
processor
running
on
the
horse.
So
if
you
have
a
rogue
process
on
the
host,
even
that
should
not
be
able
to
mess
up
with
your
containers
traffic.
A
The
next
part
of
this
is
access.
Control
being
able
to
enforce
network
policies
by
a
network
administrator
rather
than
at
a
user
level,
makes
it
a
lot
more
secure
environment
to
work
with,
for
example,
is
a
network
administrator
care
really
about
the
fact
that
none
of
the
containers
will
respond
to
any
traffic
on
port,
22
or
port
80,
or
something
like
that
so
being
able
to
describe
this
at
the
network.
Administrator
level
was
also
something
that
was
very
important
to
our
customers.
A
The
next
one
is
being
able
to
audit
that
whatever
policies
you
have
enforced
are
actually
taking
place
on
these
instances.
So
how
do
you
check
that
you
can
enforce
these
policies
and
being
able
to
get
alerts
when
these
policies
are
not
being
enforced?
The
last
one
is
being
able
to
have
a
scalable
performance
solution
which
doesn't
follow
when
you
go
from
100
containers
to
100,000
containers
or
even
to
a
million
containers.
So
just
because
you
have
more
endpoints
to
deal
with
doesn't
mean
that
your
networking
solution
should
follower.
A
Similarly,
you
shouldn't
suffer
any
performance
regression
in
terms
of
low
higher
latency
lower
bandwidth,
just
because
you
have
more
endpoints
in
your
network
and
the
last
one
is
monitoring
so
being
able
to
identify
hotspots
and
address
them
in
an
automated
manner
or
being
able
to
identify.
Bottlenecks
is
also
something
that
our
customers
brought
up
as
a
pain
point.
This
also
another
aspect
here,
even
if
we,
as
a
network
solutions
provider,
can't
provide
the
solution,
we
should
provide
you,
the
abstraction
so
that
you
can
build
your
own
solution.
A
On
top
of
this,
so
extensible
in
a
way
all
comes
into
this
picture.
So
with
these
requirements
in
mind,
let's
look
at
how
traditionally
applications
have
been
able
to
network
with
each
other.
So
in
this
example,
I
have
a
HTTP
daemon
process.
It's
listening
on
port
80.
Let's
assume
that
it's
bound
to
the
default
networking
interface
or
it's
0.
The
out
outer-box
is
an
ec2
instance.
This
can
be
a
host
or
a
virtual
machine
or
whatever
translates
with
you
the
best.
A
The
default
network
interface
also
has
an
IP
address,
but
before
the
packet
actually
reaches
the
h0
interface,
it
goes
through.
Some
of
the
routing
rules.
Routing
table
applies
some
of
the
rules
and
you
also
have
net
filter
in
Linux,
which
is
applying
firewall
rules
using
the
IP
tables
command
is
typically
how
you
interact
with
it.
So
all
of
these
together,
including
the
local
host
interface,
form
what
you
call
a
networking
stack.
So
if
you
zoom
in
a
little
bit
what's
actually
happening
underneath
is
all
of
these.
Networking
resources
are
present
in
the
default
network.
A
Namespace,
so
namespaces
are
a
construct
in
Linux,
where
you
can
create
logical
copies
of
your
ease
of
a
particular
resource
network
namespaces.
Let
you
create
logical
copies
of
the
networking
resource
and
by
default,
all
processes
inherit
namespace
from
their
parent,
which
is
why
HTTP
daemon,
which
is
a
child
of
the
init
process,
has
access
to
all
the
networking
resources
that
init
process
has
access
to.
So,
if
you
run
more
processes
on
this
host,
all
of
them
can
discover
each
other
using
the
local
host
interface,
because
they're
all
sharing
this
default
network.
A
Namespace
containers
change
this
paradigm,
where
you
can
have
multiple
network.
Namespaces
and
half
processors
belong
to
these
namespaces,
so
by
default,
these
namespaces
are
isolated
from
each
other.
So
if
I
wanted
to
run,
two
HTTP
demons
on
on
one
host
I
would
instead
create
a
container
and
the
second
HTTP
daemon
is
running
within
the
container
and
the
first
one
is
in
the
default
namespace.
A
So
now,
I
essentially
have
two
HTTP
demons
running
on
the
same
host
and
I
didn't
have
to
change
the
port
number
on
which
these
processes
were
listening,
one
because
that's
the
other
alternative
solution
right.
If
I
want
to
run
three-headed
repiy
demons
on
the
default,
namespace
I
essentially
have
to
change
the
port
numbers
and
that's
not
a
scalable
solution
or
a
manageable
solution.
So
now
we
have
this
new
container.
It
has
its
own
network
namespace.
This
creepy
daemon
running
within
it,
but
it
is,
it's
still
not
connected
to
anything.
So
how
do
you
connect
namespaces?
A
Together?
You
use
something
called
virtual
Ethernet
base
or
read
bits
in
Linux.
We
Paes
establish
a
tunnel
or
a
pipe
between
two
network
namespaces.
They
look
act
and
feel
like
Ethernet
devices,
but
they
always
exist
in
pairs.
So
here
we
have
one
end
of
the
vapor,
which
is
VEC
one
connected
to
the
other
end,
which
is
VC
one
peer
and
both
of
them
have
IP
addresses
associated
with
them,
and
the
VEC
one
pair
actually
belongs
to
an
overlay.
A
This
can
also
be
a
bridge
or
an
that
I'm
using
the
term
overlay
in
a
generic
sense
here,
and
you
have
a
connection
from
this
overlay
to
the
at
zero
interface,
and
now
this
httpd
container
can
receive
traffic
from
the
internet
or
wherever
this
endpoint
is
connected
to
using
this
V
pairs.
So
if
we
zoom
out
a
little
bit
more,
this
is
a
scenario
in
which
you
have
multiple
containers
running
in
multiple
instances.
A
So
again
this
you
can
replace
virtual
machine
or
host
for
this
instance,
but
the
underlying
thing
here
is
these
containers
are
connected
with
each
other
using
an
overlay
Network.
So
in
an
overlay
network,
you
have
generally
some
sort
of
a
proxy
running
in
the
default
namespace.
That
knows
how
to
communicate
with
container
one.
The
same
proxy
also
runs
here
knows
how
to
communicate
with
container
two
proxies
maintain
the
state
of
the
world
laughs.
They
do
the
address
translation
packet,
forwarding
and
everything
so
in
the
world
of
overlay
networking.
A
A
And
then
the
packet,
the
proxy
that's
running
here
or
the
overlays
data
plane
component
forwards
the
packet
to
the
virtual
Ethernet
pair,
and
then
it
eventually
ends
up
on
the
destination
container.
So
this
process
took
roughly
five
hops
depending
on
your
overlay
solution.
This
could
be
less
or
more.
A
Some
providers
have
lesser
number
of
hops
because
they
optimize
on
some
routes.
Others
do
not.
So
how
did
we?
How
did
this
overlays
solution
fit
into
our
requirements?
So
we
were
still
working
with
very
simple
abstractions
discovery
was
still
easy
because
all
the
containers
were
getting
native
IP
addresses,
but
we
lost
on
security
and
we
lost
big
time
because
all
of
the
traffic
in
this
was
flowing
through
this
h0
on
this
host
and
being
received
through
h0
on
this
host.
A
So
we
went
back
looked
at
how
ec2
instances
are
networked
and
see
if
we
can
get
any
inspiration
from
this.
So
this
is
a
typical
ec2
instance
setup.
We
have
V
PC,
which
stands
for
virtual
private
cloud,
which
is
a
software-defined
network.
All
customers
get
one
in
AWS
and
V.
Pc
usually
has
a
large
IP
address
range.
It's
almost
like
your
data
center
networking
and
you
have
so
by
default.
A
It
gets
a
slash,
16
range,
which
means
we
can
create
65,000
535
endpoints
within
it,
and
then
a
V
PC
can
be
carved
out
into
multiple
subnets
subnets
are
a
network
partition
construct
in
V
PC,
and
you
can
associate
a
subnet
with
an
availability
zone,
availability
zone
or
a
reliability.
Constructing
a
double
is
where
logically
group
data
centers
are
partitioned
together
into
an
availability
zone.
If
your
application
runs
in
multiple
abilities
availability
zones,
even
if
one
of
these
subnets
go
down,
the
other
subnet
will
be
up
and
you
won't
suffer
downtime.
A
So
in
this
example,
we
have
two
subnets.
They
have
slash
twenty
Cedars,
the
large
V
PC,
you
can
assume,
has
a
slash,
sixteen
cedar
and
you
have
instance,
one
and
instance
two.
This
also
this
thing
called
security
group,
which
is
the
PC
level
construct
where
you
can
enforce
access
control
policies
using
firewall
rules,
so
you
can
save,
which
IP
addresses
allow
are
allowed
to
communicate
with
these
instances
and
which
ports
are
exposed.
A
A
So
in
this
diagram,
if
we
send
a
packet
from
instance,
one
to
instance
to
it's
pretty
straightforward
or
packet
exits
instance
one-
and
it
just
shows
up
an
incident
store,
so
there's
no
additional
hops,
there's
no
performance
penalty
or
anything
because
VPC
essentially
has
this
notion
of
a
flat
network.
So
this
is
very
appealing
to
us
and
we
wanted
to
see
what
made
this
so
magical
and
if
we
can
leverage
the
same
thing
for
our
containers.
A
So
under
the
hood,
each
ec2
instance
essentially
gets
a
virtual
network
interface
card,
which
is
also
called
an
elastic
network
interface
or
an
Eni,
and
all
Ian
ice
in
a
VPC
are
networked
together.
There's
no
additional
performance
penalty
for
communicating
between
tui
and
ice
and
each
ec2
instance
by
default
gets
one
e
ni
and
the
interesting
thing
here
is:
you
can
create
en
ice
on
demand
and
associate
multiple
Ian
ice
to
an
instance.
A
So
that's
what
essentially
led
to
the
solution
that
we
eventually
implemented,
which
was
creating
Ian
ice
for
tasks
or
parts
so
I
don't
know.
Member
last
year
we
released
to
CNI
plugins
the
ECSC
ni
plug-in
and
the
V
PCC
and
I
plug
in
for
kubernetes,
both
of
which
essentially
do
the
same
thing.
You
can
find
the
source
code
and
design
details
on
github,
this
detailed
design
documents
with
workflows
and
everything
for
both
of
these
plugins.
The
central
idea
for
both
of
these
plugins
is
the
same.
A
Each
container
or
each
task
or
each
pod
gets
its
own
en
I.
The
e
ni
gets
provisioned
on-demand
and
because
so
this
brings
this.
This
brings
the
same
level
of
abstraction
to
ec2
instances
to
containers,
so
containers
are
now
glass,
networking
primitive
with
these
features
and
because
they
have
on
ena
per
application.
Discovery
is
very
simple
as
well.
So
if
you
look
at
the
diagram
now,
instead
of
any
overlay,
there
is
no
overlay
here.
A
container
one
has
a
ena.
A
A
It
knows
the
container
scipy
address
this
IP
address
is
natively
addressable
within
the
VPC,
and
the
packet
just
ends
up
on
the
other
container.
So
no
extra
hops,
no
performance
penalty.
You
can
enforce
security
group
rules,
so
you
can
actually
enforce
firewall
rules,
a
top
network
administrator
layer
rather
than
at
an
application
layer.
There's
no
additional
state
for
us
to
maintain,
because
VPC
does
all
of
the
IP
address
management.
So,
overall,
it
turns
out
to
be
a
pretty
simple
solution
for
our
customers
to
use.
A
So
if
we
look
back
at
the
requirements,
we
achieved
on-demand
delivery
because
via
treating
network
as
a
resource
constraint
for
our
scheduler
to
do,
the
placement
on
discovery
is
pretty
simple,
because
we're
using
native
IP
addresses
you
have
isolation
from
network
namespaces.
You
can
enforce
access
control
policies
using
security
groups.
You
have
audit
logs
from
VPC
few
logs.
So
if
you
haven't
used
VPC
flow
locks
before
it's
a
pretty
cool
feature,
it
lets.
A
So
as
long
as
your
ARCA
straighter
knew
how
to
do
see
how
to
integrate
with
CNI,
you
could
use
your
user
plugins
with
any
network
Orchestrator.
In
fact,
our
vp
c
c-
and
I
plug
in
which
we
were,
which
was
optimized
for
e
CS,
is
being
used
by
at
least
two
customers
on
communities
and
vice
versa.
So
let's
look
at
some
of
the
design
constraints
or
design
decisions
that
we
had
to
make
the
very
first
one
was:
should
we
do
c
ni,
or
should
we
do
c,
NM,
so
c
NM?
A
A
Business
and
CNI
plugins
fit
right
into
the
because
CLA
plugins
such
as
short
chip,
executables
they
come
provision
and
then
they
go
away,
and
the
second
aspect
was
simplicity,
so
CNA
has
a
specification
against
which
you
can
actually
write
reliable
and
repeatable
tests.
So
this
means
that
you
have
a
consistent
interface
to
program
against,
which
was
also
a
big
blast.
Furnace
and
CNA
plugins
are
actually
chainable,
so
they're
great
in
terms
of
extensibility.
A
Our
customers
can
extend
networking
solution
on
their
own
or
it
makes
us
easy
to
extend
our
networking
solution
for
them,
because
CNI
has
this
changed
execution.
It's
almost
like
working
with
a
linux
shell
or
you
can
pipe
the
result
of
one
plug-in
to
another
plug-in
and
it
still
works,
and
the
last
one
is
ecosystem
support
lip
CNI,
which
is
the
library
against
which
all
CNI
users
integrate
with
so
cubelet
ECS
asian
integrated
with
lips
ena
is
battle
tested,
multiple
customers
already
use
it
in
production,
and
that
was
a
great
thing
for
us.
A
So
here's
a
brief
just
to
illustrate
how
simple
it
is
to
use
CNI
plugins.
This
is
a
sequence
diagram
of
how
CNI
plugins
are
invoked,
so
CNI
plugins,
essentially
respect
two
verbs,
add
and
delete,
and
you
just
invoke
the
add
command
with
a
networking.
Config
all
invoke
the
delete
command
with
a
networking.
Config
add,
creates
the
network,
delete,
taste
on
the
network,
and
it's
as
simple
as
that
in
this
diagram.
A
I
actually
have
two
plugins,
but
if
you
have
just
one
plug-in,
even
the
last
part
goes
away
and
it's
two
arrows,
which
is
pretty
much
a
dream
for
anybody
who
is
programming
against
it.
The
next
aspect
was
which
programming
language
to
use
gulang
or
something
else
we
chose
golang
because
of
its
support
for
static
binaries,
installing
sia
static,
binary
system.
A
It's
simple
to
installing
third-party
packages
on
which
you'd
like
binary,
depends
on
and
so
on,
and
you
can
also
package
this
into
a
container
so
that
so
it
was
a
default
programming
language
for
us
to
use
again.
The
ecosystem
support
is
something
worth
noting
here
as
well.
Lip
CNI
is
pretty
mature
and
is
written
in
go
so
it's
pretty
much
a
no-brainer
that
we
would
use,
go
I
do
know
some
people
who
have
written
plugins
interest
but
I,
don't
say
hi
to
them.
That
often.
A
Next
is
packaging.
This
distribution,
we
package
the
plugin
as
in
a
docker
container,
which
means
that
we
get
all
of
the
advantage
of
packaging
containers.
Sorry,
packaging
advantages.
The
containers
give
you
here's
an
example
of
a
docker
file.
You
can
find
this
in
a
repo
for
how
we
actually
package
these
plugins.
They
get
copied
along
with
the
ECAC
agent
binary
or
if
you
are
running
the
kubernetes
flavor
of
it
they
get
deployed
as
daemon
sets,
and
all
of
this
is
made
possible
and
much
easier
because
we
are
packaging
them
as
containers.
A
Another
thing
here,
even
if
you're,
not
writing
a
CNI
plugin,
is
just
a
good.
Software
practice
is
to
version
your
executables
and
version
them,
especially
with
the
get
hash
from
which
they
were
built,
because,
when
you're
deploying
these
things
at
scale,
when
you
have
hundreds
of
thousands
of
copies
of
this
running,
if
there's
any
problems,
it's
very
easy
to
determine
which
build
caused
the
issue.
So
we
have
human
readable
version
numbers,
but
we
also
have
get
short
hashes
and
we
actually
automate
this
version
by
using
build
flags
and
go
so
go.
A
B
A
So
versioning
everything
in
an
automated
manner
is
something
that
I
would
HIGHLY
encourage
you
do
in
whatever
software
system
you're
building
next
testing
the
plugins.
We
actually
have
close
to
100%
unit
dis
coverage,
not
that
it
guarantees
absence
of
books,
but
it's
cleared
to
have
that
sort
of
coverage.
We
also
run
integration
tests
and
end-to-end
tests
in
our
CI
CD
pipelines.
So
if
you
remember
Dan
Cohen's
keynote
from
yesterday,
CI
is
something
that
you
should
be
deeply
care
about.
A
So
just
to
conclude
avoid
feature
and
v4
containers
are
bringing
the
same
abstraction
as
you
have
for
virtual
machines,
at
least
in
terms
of
networking,
because
it
makes
a
lot
of
things
very
simple,
and
we
are
really
grateful
to
authors
of
the
cni
plugins,
because
it's
an
awesome
project
for
anyone
to
integrate
with
and
it
made
our
lives
a
lot
simpler
and
version
everything
with
kit
sauce.
It
helps
you
a
lot
when
you're
dealing
with
the
distributed,
complicated
application
to
detect
what
actually
caused
the
issue.
A
So
here's
some
related
links
in
case
you're,
downloading
the
slide
on
the
internet
or
something
this
the
net
link
library,
the
siene
project,
are
all
great
resources
not
just
for
using,
but
also
looking
at
how
to
write
good
maintainable
gulang
code.
So
it
highly
encourage
you
to
read
that
and
with
that
it
set
up
thanks
for
your
time
or
you
can
reach
me
all
our
team
on
github
using
these
links
and
yeah
thanks
again,
I.
B
A
Yeah,
so
the
question
is:
what's
the
provisioning
latency
for
here
nice,
if
you
are
provisioning,
an
e
ni
for
each
part,
so
we
actually
have
a
daemon
set
that
provisions
ionized
ahead
of
time
for
the
part.
So
when
the
instance
starts
up,
we
provision
as
many
en
eyes
as
we
can
so
the
initial
provision
latency
you
only
take
a
hit
when
the
instance
starts,
so
the
containers
themselves
don't
see
this
performance
head.
B
A
The
question
is
this:
a
limit
on
the
number
of
en
is
that
we
can
attach
to
an
instance.
Does
it
limit
the
number
of
parts?
Yes,
it
does,
and
it's
something
that
we
are
working
on
to
increase
behind
the
scenes
with
that
networking
team,
if
you're
using
parts
we
also
optimize
it
by
creating
secondary
IP
addresses
for
en
eyes,
so
that
helps
it
a
bit
but
not
a
whole
lot.
But
yes,
that's
something
that
we
are
aware
of
and
we
are
working
on.
B
A
Right,
so
the
question
is:
how
do
you
apply
cluster
level
access
control
policies
as
a
network
administrator?
So
you
can
create
a
security
group
at
a
cluster
level
and
when
you're
creating
your
instances,
you
can
tell
them
to
inherit
from
that
security
group
and
then
have
it
be
applied
in
that
manner.
A
A
A
So
the
question
is:
how
production-ready
is
this
because
you're
using
other
providers-
and
you
want
to
switch
to
it-
it's
actually
production-ready.
We
released
this
back
in
October
last
year
and
the
ECS
version
of
it
is
actually
being
used
in
production
a
lot
by
our
customers.
The
kubernetes
version
of
it
was
built
with
our
partners,
and
some
of
them
are
already
using
it
in
their
in
the
e
KS
preview,
but
you
can
use
it
of
course
outside
of
the
eks
product
as
well
in
your
own
cluster.
A
B
A
The
question
is:
do
Eni
support
public
IPS,
the
secondary
Ian
eyes,
do
not
support
public
IP
addresses
it's
a
feature
request
that
we've
heard
often
from
our
customers,
but
we
haven't
arrived
it
if
they
should
really
support
public
IP
addresses,
because
public
IP
addresses
have
both
security
concerns
in
this
also
IP
exhaustion
concerns.
So
we
do
want
to
provide
some
sort
of
public
IP
addressing
scheme.
We
don't
know
if
it's
essentially
going
to
be
ipv4
or
ipv6.
A
A
A
Yeah,
the
question
is:
are
the
CNAs
registerable
as
targets
to
lbs
and
lbs?
The
answer
is
yes
and
that's
why
we
went
with
the
Eni
route,
because
we
wanted
integrations
at
as
many
places
in
layers
as
possible.
If
you
wanted
to
use
a
service
discovery
using
route
53,
you
should
be
able
to
register
these
as
targets.
If
you're
using
load
balancers,
you
should
be
able
to
register
these
as
targets
and
they
are
register
well
as
targets.
A
A
B
A
Yes,
the
question
is:
if
we're
using
second,
the
IP
adresses
will
the
load
balance
is
still
be
able
to
use
the
ena
as
a
target.
In
theory,
I
think
it's.
It
should
be
possible
because
if
you
use
the
network
load
balancer,
it
uses
the
IP
address
and
port
as
a
target,
so
it
should
be
doable,
but
I
haven't
tried
it
myself.
So
I
can't
say
for
sure.
Come
talk
to
me
after
the
session.
I
am
at
the
8th
of
this
booth
and
we
can
hash
it
out.
A
So
when
you
say
global
IP,
is
it
the
elastic
IP?
Is
it
the
elastic
IP
that
you
are
referring
to
yeah?
So
the
question
is:
if,
if
my
service
has
an
elastic
IP,
address
or
village
still
work
with
Jia
nice,
the
answer
is
yes.
Elastic
IP
addresses
are
also
of
epc
level
construct,
so
any
VPC
level
abstraction
that
works
with
traditional
ec2
instances
will
work
with
this
solution.
A
The
answer
here
is
to
run
your
provisioning
process
in
as
part
of
your
API
server
or
in
easiest.
It's
up.
It's
happening
at
a
scheduler
layer,
so
only
the
scheduler
is
privileged
to
create
a
anaïs
and
whatever
components
are
on
the
host
can
just
use
the
CNAs,
so
they
get
the
information
that
this
part
of
this
task
should
use
the
CNA
and
then
they
provision
it.
So
as
long
as
you
constrict
the
only
the
provisioning
part
of
the
network
to
the
plugin,
you
should
be
safe.