►
From YouTube: Interoperability of Open Source Tools: The Emergence of Interfaces - Katie Gamanji, American Express
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Interoperability of Open Source Tools: The Emergence of Interfaces - Katie Gamanji, American Express
In the past years, Kubernetes has been the nucleus of container orchestration frameworks. Numerous tools have been developed to extend Kubernetes capabilities and enhance its features. Over time, tools with similar functionalities would have fundamentally different implementations and practices to converge with the Kubernetes components. The emergence of shared standards and a set of best practices became imperative. This talk will focus on the evolution of interfaces within the Kubernetes landscape, including networking, storage, service mesh, and cluster provisioning. Attendees will acquire an understanding of why the interoperability of open-source tools is pivotal in the modern infrastructure.
https://sched.co/cp8T
A
B
Hello,
my
name
is
katie
gomanje
and
I'm
one
of
the
cloud
platform
engineer
for
american
express
around
two
months
ago.
I
joined
american
express,
and
I
am
part
of
the
team
that
aims
to
transform
the
current
platform
by
embracing
the
cloud
native
principles
and
making
the
best
use
of
the
open
source
tools
as
well.
Quite
recently,
I've
been
nominated
one
of
the
toc
or
technical
oversight
committee
member
for
the
cmcf,
alongside
11
other
champions
within
the
open
source
community
I'll,
be
responsible
to
steer
and
maintain
the
technical
vision
for
the
cncf
landscape.
B
B
B
However,
the
community
around
kubernetes
was
not
always
as
developed
and
flourishing,
but,
more
importantly,
it
was
not
always
as
engaging
the
picture
at
the
beginning
was
rather
different.
Nowadays
kubernetes,
it's
known
for
its
adaptability
and
flexibility
to
run
containerized
workloads
of
predefined
technical
requirements.
B
It
is
capable
to
provision
the
ecosystem
for
application
execution
while
shrinking
considerably
its
footprint
in
the
cluster.
It's
all
about
resourceful
management
of
capacity,
however,
to
reach
the
state
of
the
art,
complex
challenges
required
solutionizing,
such
as
the
support
for
different
networking
and
hardware
systems,
and
this
prompted
for
the
cni
and
cri
to
be
developed.
So
pretty
much
the
container
network
interface
and
the
container
runtime
interface,
the
cni
was
introduced
under
the
cfc
ncf
umbrella
in
early
2017.
B
While
the
cri
was
introduced
in
its
alpha
release
in
kubernetes
1.5,
I
would
like
to
dive
a
bit
more
into
the
networking
and
runtime
components,
as
these
were
pivotal
in
making
the
transition
between
the
vms
and
continuous
seamless
so
pretty
much.
How
do
we
make
sure
that
we
have
the
reachability
of
our
workloads
and
how
can
we
make
sure
that
we
can
create
our
workloads
as
containers?
B
B
Supposedly,
we
have
two
different
applications
running
on
two
different
nodes
and
we
would
like
to
send
a
packet
for
application,
one
to
application
two,
when
the
request
is
issued,
we're
actually
going
to
look
inside
the
pod
to
see
if
there
are
any
available
containers
to
solve.
Our
request,
for
the
sake
of
this
example,
will
not
be
able
to
do
so,
which
means
the
request
is
going
to
go
outside
of
the
pod
and
it's
going
to
reach
the
root
network
namespace
on
the
physical
machine.
B
Generally
speaking,
the
routing
table
is
going
to
have
the
mapping
between
every
single
node
and
the
cider
of
the
pods
ip
to
be
allocated
on
that
node.
This
means
that
with
minimal
hubs,
we're
going
to
be
able
to
reach
our
destination
host
and
in
a
reversive
manner,
we'll
be
going
through
the
root
network
namespace
to
the
right
pod
slash
container
now
the
cni
component
is
heavily
embedded
within
the
routing
table
stage.
B
B
Now
the
cni
concerns
itself
with
the
connectivity
of
containers
and
with
the
removal
of
resources
when
the
container
is
not
there
anymore.
So
it's
going
to
have
two
operations,
addition
and
deletion.
It
will
make
sure
to
give
the
pod
an
ip,
but
at
the
same
time
it
will
make
sure
to
clean
up
any
resources
when
the
pod
is
removed.
B
Lately
celium
has
gained
a
lot
of
momentum,
and
this
is
because
it's
aware
of
the
application
and
networking
layers
configuration
for
the
networking,
packets
and
we've
worked
came
with
their
own
networking
component
called
weavenet,
which
is
known
for
its
simplicity
to
be
installed
in
the
cluster,
with
no
extra
configuration
now
at
this
stage,
we
see
that
we
have
the
possibility
to
connect
our
workloads
across
any
distributed
amount
of
machines,
and
this
is
just
step
one.
I
would
like
to
focus
on
the
runtime
component
at
the
moment.
B
Now
the
runtime
story
is
slightly
different,
and
this
is
because,
from
the
beginning,
docker
and
rocket
would
be
the
mainly
supported
runtimes.
Now
the
runtime,
just
to
be
clear,
is
the
particle
which
intercepts
the
request
from
the
cubelet
and
will
create
the
pods
with
the
right
specifications
on
the
machine.
B
Now
at
the
beginning,
the
logic
for
the
runtime
was
very
deeply
ingrained
within
the
kubernetes
source
code,
and
this
exposes
quite
a
few
challenges.
If
you'd
like
to
develop
new
features
for
the
runtime,
that's
going
to
be
very
tightly
coupled
with
the
cubelet
release
process,
which
is
quite
lengthy
in
its
own.
B
B
When
you're
looking
into
the
cncf
landscape,
we
have
plenty
of
tools,
provisioning,
the
runtime
capabilities,
from
which
container
d
and
cryo
are
probably
most
widely
known
for
their
open
source.
Nature
container
d
is
currently
a
graduated
cncf
project
which
showcases
its
maturity
and
high
adoption
rate.
B
B
Now
the
runtime
and
networking
component
were
essential
to
make
the
transition
between
the
vms
and
container
assemblies.
We
will
be
able
to
reach
our
containers
anywhere,
but
at
the
same
time
we
have
the
capability
to
create
our
containers
with
any
any
tooling
already
available,
or
we
want
to
like
to
develop
from
this
stage.
B
Now
the
service
mesh
is
a
dedicated
infrastructure
layer
that
concerns
itself
of
how
the
services
communicate
between
themselves
in
a
distributed
environment.
What
it
actually
does.
It
focuses
on
the
traceability
and
transparency
of
how
the
request
is
sent
across
microservices,
and
this
is
quite
important
because
we
would
like
to
have
this
holistic
vision
of
the
request
journey.
B
Traffic
policy
is
all
about
fine-grained
access
control
of
how
the
services
should
communicate
between
themselves
traffic
management,
it's
all
about
the
proportional
traffic
to
be
sent
across
services.
Now
this
is
quite
important
if
you're
thinking
about
canary
rollouts
and
traffic
telemetry
is
going
to
concern
itself
how
to
capture
and
expose
metrics
to
make
sure
that
the
communication
between
the
services
is
as
transparent
as
possible.
B
B
B
Now,
when
I
was
mentioning
that
it's
one
of
the
most
widely
contributed
areas,
this
is
because
that
more
than
60
providers
are
actively
collaborating
and
integrating
with
csi
from
which
we
have
storage,
os,
rook,
ceph,
open
ebs
and
many
more.
All
of
these
tools
are
going
to
focus
on
dynamic
allocation
for
the
storage
storage
capabilities,
but
at
the
same
time,
on
the
simplicity
to
be
configured
within
a
cluster,
it
is
worth
to
mention
as
well
that
recurrently
is
an
incubating
cncf
project.
B
Now,
transitioning
towards
the
cluster
api,
the
perspective
has
changed
completely.
When
we
talked
about
the
networking
runtime
service
mission
storage,
all
of
these
components
reside
within
the
kubernetes
world.
Cluster
api
takes
the
idea
of
interfaces
a
further
step.
It
completely
refines
the
way
we
actually
think
about
clusters
and
provision
our
clusters.
B
Currently,
we
have
plenty
of
tools,
provisioning,
the
bootstrap
capabilities
for
kubernetes
cluster,
from
which
we
have
cube
atm
cube
spray,
cops
tectonic
and
many
more.
However,
if
you
look
into
every
single
tool,
it's
going
to
be
difficult
for
us
to
find
a
common
denominator
when
it
comes
to
the
cloud
provider.
B
B
Another
challenge
is
exposed
by
regions
such
as
china,
russia.
Now
these
regions
are
known
for
their
infrastructure
well,
which
are
developed
within
those
areas
only
and
they
have
their
own
development
cycle
while
creating
the
platform
or
migrating
the
platform
to
these
areas.
Most
of
the
time,
the
lift
and
shift
capability
is
dispersed.
B
Now
I
was
mentioning
the
cluster
api
provisions
and
infrastructure
and
interface
to
connect
to
different
cloud
providers,
and
currently
there
are
12
cloud
providers
actively
contributing
and
collaborating
with
cluster
api,
from
which
we
have
google
cloud.
Aws
digital
ocean
bare
metal,
but,
more
importantly,
by
the
cloud
and
by
the
cloud,
is
a
chinese
provider,
and
this
is
this
means
that
we'll
be
able
to
provision
our
infrastructure
in
china
with
the
same
ease
as
we
provision
our
platform
in
europe.
B
B
B
Once
we
have
our
management
cluster
up
and
running,
we'll
require
our
dependencies
or
the
controller
managers
to
have
a
fully
working
version
of
cluster
api.
We
require
free
controllers
and
there's
going
to
be
the
cluster
api,
crd
controller,
the
bootstrap
provider
controller
and
the
infrastructure
provider
controller
cluster
api
introduces
four
new
crds
and
will
require
a
controller
to
make
sure
that
we
can
create
and
reconcile
any
changes
we
have
to
those
resources.
B
B
The
cluster
resource
is
going
to
have
the
higher
level
configuration
for
a
cluster,
we'll
be
able
to
specify
our
reciter
for
the
pods
and
services
and
any
dns
suffix
machine
resource
is
very
similar
to
node
configuration
we'll
be
able
to
specify
the
version
of
kubernetes
we'd
like
to
run
as
well.
The
instance
type
for
our
machine
or
the
region.
We'd,
like
our
machine
to
run
into
machine
set,
is
very
similar
to
replica
set.
B
B
It
is
worth
to
mention
here
that
the
machine
resource
is
immutable
within
the
cluster
api
setup.
This
means
that
if
you
deploy
new
configuration
or
changes
to
the
current
configuration,
the
machine
with
the
alt
setup
is
going
to
be
taken
down
and
the
machine
with
the
new
configuration
is
going
to
be
brought
up.
There
is
no
patching.
There
is
only
immutability
to
showcase
the
simplicity
of
creating
a
clustering
with
cluster
api,
I'm
going
to
showcase
the
way
cubespray
does
it
at
the
moment
now.
B
Cubespray
is
a
tool
that
provisions
the
infrastructure's
code
for
a
platform
by
using
ansible,
and
in
the
current
view,
we
have
a
trimmed
vision
of
all
the
roles.
An
engineer
would
need
to
be
aware,
while
troubleshooting
creating
and
maintaining
a
cluster.
This
is
just
a
shorting
output
as
well
cluster
api
transitions
from
this
amount
of
configuration
to
a
couple
of
manifests
and
if
you'd
like
to
create
our
cluster
in
aws,
this
is
going
to
be
the
end
result.
B
B
This
is
going
to
be
the
configuration
which
will
actually
invoke
the
parameters
and
values
specific
to
a
cloud
provider,
and
it
only
makes
sense
because
different
cloud
providers
are
going
to
have
different
parameters
to
be
configured
in
this
particular
snippet.
We
have
an
infrastructure
reference
which
is
specific
to
aws
cluster,
so
the
kind
is
going
to
be
infidelist
cluster.
We
created
a
v1
alpha
to
endpoint
and
give
it
a
name
test
cluster.
B
B
What
we
actually
do
here
is
change
the
infrastructure,
reference
kind
to
gcp
cluster,
and
this
is
going
to
invoke
parameters
which
are
very
specific
to
google
cloud.
As
such,
the
region
is
going
to
be
europe
west
free
and
we
have
the
concept
of
a
project
which
is
very,
very
specific
to
the
gcp
and
we
assign
our
cluster
to
capi
project
as
well.
We
attach
a
network
with
the
name
default
cpi
to
our
cluster
from
here.
We
see
that
we
have
very
usable
manifest
and
we
can
simply
configure
clusters
across
different
cloud
providers.
B
The
hassle
is
minimal
now,
once
we
have
our
cluster.
The
second
step
is
to
actually
add
our
control
plane,
which
is
going
to
be
a
manifest
for
our
masters
and
obviously
we'll
need
to
add
our
work
notes
and
there's
going
to
be
an
extra
manifest
for
that.
So
this
is
just
step
one,
but
again
the
simplicity
is
already
evidenced.
B
B
B
B
B
Within
its
six
years
of
existence,
kubernetes
transmogrified
its
identity,
multiple
times
in
a
recursive
manner.
More
and
more,
we
extrapolate
components
from
the
core
binaries
of
kubernetes
and
make
them
develop
independently,
such
as
the
networking
storage
components,
and
this
has
been
possible
because
kubernetes
is
not
opinated.
B
Of
course,
it's
going
to
be
assertive
when
it
comes
to
the
networking
model
and
the
primitives
it
distributes.
However,
it's
not
going
to
be
opinated
when
it
comes
to
the
underlying
technology
you
run
kubernetes.
On
top
of,
there
is
not
one
kubernetes
platform
that
is
the
same,
because
the
users
have
the
flexibility,
to
plug
different
components
and
to
personalize
their
infrastructure
to
their
needs
as
well.
B
When
you're,
looking
at
the
vendors,
the
immersions
of
interfaces,
it's
all
about
innovation
as
a
vendor,
you
don't
have
to
concern
itself
of
how
to
converge
your
product
with
kubernetes.
The
interface
is
going
to
be
already
there
as
a
vendor.
You
can
concentrate
on
future
development
and
how
can
you
provision
value
to
your
customers
with
minimal
latency?
B
When
you're
looking
into
the
end
user
community
the
emergence
of
interfaces,
it's
all
about
extensibility,
it
was
never
as
easy
as
it
is
today
to
benchmark
different
tools
with
the
same
functionality
as
an
end
user.
You
have
the
privilege
to
choose
the
right
tool
for
your
infrastructure
with
minimal
compromises.
B
B
However,
the
concept
of
interfaces
transcends
the
world
of
kubernetes.
It
can
be
applied
to
different
domains
and
areas,
and
this
is
because
the
interfaces
can
be
the
central
engine
for
development
and
innovation
that
anchors
extensibility,
but
at
the
same
time
embraces
different
solutions
for
the
same
problem.
B
A
A
B
B
A
B
B
B
Absolutely
so
I'm
gonna
start
to
explain
what
a
toc
is
so
as
mentioned,
toc
is
a
technical
oversight
committee,
and
I
am
a
member
of
that.
It's
only
11
of
us
and
we
are
responsible
to
make
sure
that
the
right
projects
are
joining
the
cncf
landscape.
So
pretty
much.
I
was
elected
by
the
end
user
community.
B
So,
as
you
know,
in
the
end
user
we
have
already
almost
140
companies
which
are
part
of
that
and
they're
using
the
tooling
within
the
landscape,
and
I
have
been
elected
to
represent
the
voice
and
their
perspective
moving
forward,
because
in
the
toc
we
have
actually
different
roles.
We
have
tocs
that
are
coming
from
the
contributor
base.
B
So,
as
you
know,
in
in
graduation,
we
have
big
projects
such
as
kubernetes
prometheus.
We
have
helm
quite
recently,
graduated
and
somewhere,
like
all
of
this
project,
would
have
a
lot
of
usability
in
production
environments.
They
graduated
on
the
good
marriage,
so
the
tlc
pretty
much.
We
will
make
sure
that
the
projects
can
transition
from
sandbox
to
incubation
to
graduation
but,
more
importantly,
we'll
make
sure
that
we
have
these
open
governance.
We
have
this
open
collaboration.
B
We
don't
have
any
vendor-specific
tooling
over
there,
so
we
want
it
to
be
interoperable
and
that's
why
they
talk
today
was
heavily
focusing
on
that
as
well.
So
this
is
the
role
of
the
toc,
it's
it's
kind
of
largely
encapsulating
in
in
our
duties,
but
it's
pretty
much
to
make
sure
that
the
right,
tooling
are
joining
the
landscape
and
the
community
can
benefit
from
it
properly.
A
A
B
B
Okay,
so
the
question
is,
I'm
gonna
read
it
aloud:
can
these
api
interface
alignment
reduce
the
multi-cloud
development
and
deployment
and
how
much
so
with
cluster
api?
The
idea
of
it
is
to
consolidate
the
way
we
create
clusters
or
kubernetes
clusters
in
different
cloud
providers,
as
mentioned,
we
can
do
so,
but
the
deployment
phase
is
going
to
be
very
different
from
one
cloud
provider
to
the
other
and
cluster
api
wants
to
consolidate.
All
of
that,
so
definitely
the
answer
is
yes,
it
actually
aims
to
reduce
the
amount
we
spend
on
developing
different
capacitors.
B
We
have
reusable
manifest
of
cluster
api,
as
shown
in
the
presentation
example.
Switching
between
cloud
providers
is
just
a
matter
of
sometimes
changing
the
infrastructure
reference
within
our
manifest
and
they're
just
going
to
invoke
the
different
parameters
for
different
cloud
provider.
So
from
that
perspective
we
never
had
this
concept
before
of
reusing
our
manifest
for
cluster.
This
is
a
new
concept
which
we
can
further
build
on
and
again,
cluster
api
is
just
at
the
beginning,
so
it
has
a
lot
of
potential.
B
That's
why
I'm
actually
calling
for
feedback
for
if
you
have
a
use
case
or
cluster
api,
please
try
it
and
feedback,
because
you
have
very
high
chances
for
your
feedback
to
be
incorporated
in
the
next
three
releases.
So
the
answer
that
I
guess
they
intend
to
reduce
the
open
work
we're
going
to
have
in
a
multi-cloud
environment.
B
The
second
question
of
how
much
the
only
measurable
at
the
moment,
data
point
at
least-
is
the
amount
of
inputs
like
the
actual
infrastructures
code,
which
is
translated
in
yaml
manifest.
So
from
that
perspective
we
definitely
have
a
better
usage.
We
have
an
easier
definition
of
our
cluster.
We
generally
have
the
concept
of
a
cluster
as
a
resource,
so
from
that
perspective
it's
definitely
a
more
native
way
for
kubernetes
to
work
with
clusters
and
deploy
clusters.