►
From YouTube: Keynote: Reverse Engineering Cloud Native: Interoperability & Community - Katie Gamanji & Kohei Ota
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 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.
Keynote: Reverse Engineering Cloud Native: Interoperability and Community - Katie Gamanji, Senior Field Engineer & Kohei Ota, Senior Field Engineer, Apple
Kubernetes has become the default container orchestrator framework, setting the standards for application deployment in a distributed environment. In the past years, numerous tools have been developed to extend Kubernetes capabilities and enhance its features. Simultaneously, the expansion of the technology landscape prompted the growth of the adopter base and the number of scenarios where cloud native can be applied. The organic adoption and development of new tools, created the ecosystem and community as we know it today.
This keynote will feature the core principles that define the next generation’s identity of cloud native practitioners using a reverse engineering approach. It will present the interoperability of tools, inclusivity at the community and adopters level, and a culture of change and education that drives the ubiquity of the cloud native.
A
B
A
Today,
we'd
like
to
invite
you
to
reverse
engineering,
Cloud
native
and
more
specifically,
look
into
interoperability
and
community,
and
to
do
so
first
we're
going
to
look
into
the
emergence
of
interfaces.
This
is
pretty
much
at
the
basis
of
our
landscape.
We
Embrace
multiple
solutions
for
the
same
problem
and
we're
going
to
look
into
the
networking,
runtime
storage
service,
mesh
and
cluster
provisioning
interfaces.
A
However,
the
community
around
kubernetes
was
not
always
as
flourishing,
but,
more
importantly,
it
was
not
always
as
engaging
the
picture
at
the
beginning
was
quite
different.
Nowadays,
kubernetes
is
known
for
its
ability
to
provide
the
environment
for
application
execution
while
shrinking
its
footprint
in
the
cluster.
It's
all
about
resourceful
management
of
the
resources,
however,
to
reach
the
state
of
the
art.
A
Now,
let's
focus
on
networking.
First,
exploring
the
networking
fabric
within
a
kubernetes
cluster
is
quite
a
challenging
task.
Kubernetes
is
known
for
its
ability
to
schedule
workloads
on
a
distributed
amount
of
machines,
while
preserving
the
connectivity
and
reachability
to
these
workloads.
As
such,
the
networking
topology
is
highly
assertive
and
it
gravitates
towards
the
idea
that
every
single
pod
should
have
an
ionic
IP.
A
A
Now,
the
networking
topology
dictates
that
every
single
part
should
be
should
be
reachable
via
a
typing.
As
such,
we
needed
inclusivity
for
different
networking
systems
and
here's
where
the
cni
will
contain
a
network
interface
was
introduced
pretty
much.
It
introduces
the
network
overlay
for
a
cluster,
and
it
has
two
operations,
addition
and
deletion.
It
will
make
sure
to
allocate
an
IP
to
a
pod
when
it's
created
and
it
will
ensure
to
remove
any
resources
when
the
Pod
is
not
going
to
be
there
anymore.
A
However,
if
you
want
to
have
a
more
fine
Access
Control
to
services
within
your
cluster,
you
might
look
into
tools
such
as
Calico,
which
comes
with
a
network
policy
enforcer,
and
if
you
want
to
tackle
security
as
part
of
the
networking,
you
might
look
into
a
tool
such
as
psyllium
that
allows
you
to
have
visibility
of
the
layer,
free
and
layer
7.
So
pretty
much.
The
networking
and
application
layer.
B
When
kubernetes
was
born,
the
community
decided
to
use
Docker
as
the
primary
container
runtime
and
then
core
OS
also
introduced
the
rocket
as
an
alternative.
However,
because
there
was
no
standardization
back,
then
the
implementation
for
the
API
clients,
libraries
of
Docker
and
Rocket,
were
internally
embedded
directly
in
the
kubernetes
source
code.
B
The
there
are
two
different
major
implementations
for
Sierra
runtimes
in
the
community.
One
is
container
D
container
D
was
born
from
Docker
and
it's
an
open
source
project
from
called
Mobi
project,
and
it
still
empowers
the
the
strong
power
for
the
container
creation
deletion
for
Docker,
as
well
cryo,
originally
created
by
Red
Heart,
provides
the
functionality
with
the
Simplicity
and
security
as
a
CRI
native
container
runtime.
A
Now
for
anyone
new
to
service
mesh,
this
is
pretty
much
a
dedicated
infrastructure
layer
that
concerned
itself
with
traffic
to
be
sent
across
different
services
within
a
cluster.
Now,
when
you're
going
to
have
a
request
issued
by
the
user,
it's
always
actually
going
to
look
or
transcend
different
microservices
and
with
service
mesh
you'll,
be
able
to
fully
recreate
that
path.
Now
the
SMI
currently
integrates
with
tools
such
as
Linker
D
is
still
console
hub
from
hashicorp
and
many
more.
B
Class
API
is
a
project
that
you
can
create
your
kubernetes
cluster
on
the
provision
it
as
a
your
kubernetes
custom
resource,
just
like
managing
your
manifests
in
yaml
files
and
class
API
has
a
interface
called
provide
interface,
which
makes
you
have
an
option
to
choose
on
which
cloud
provider
or
Cloud
infrastructure
layer.
You
want
to
provision
your
classroom.
A
Now,
when
we
look
into
the
perspective,
all
of
these
interfaces
created
the
landscape
that
we
know
today
with
multiple
tools.
Now,
whilst
the
technology
is
the
gravitational
point
of
cloud
native,
nothing
would
be
possible
without
the
community
around
it.
Now,
from
the
beginning,
the
kubernetes
community
operates
on
the
principle
that
inclusive
is
better
than
exclusive.
We
try
to
build
communities
through
open
governance,
transparency
and
a
diligent
kind
of
conduct.
A
However,
one
thing
I
would
like
to
highlight
is
that
you
do
not
need
to
write
code
to
be
an
active
member
of
the
community.
You
can
actually
get
involved
in
different
working
groups,
sigs
and
tags
or
technical
advisory
groups.
Now,
within
the
cncf,
we
have
seven
tags
that
focus
on
very
specific
areas.
Some
of
them
already
talked
about
such
as
networking,
runtime,
storage,
observability
and
many
more
now.
I,
definitely
invite
you
to
again
shaking
these
tags.
All
of
the
information
is
publicly
available
on
GitHub,
such
as
the
meeting
notes
and
the
meeting
invites.
B
A
Now,
as
a
community,
we
should
not
only
focus
on
solving
the
problems
that
we
have
now.
We
should
focus
on
solving
the
problems
of
the
future
and
actually
create
a
safe
space
for
the
next
generation
of
cloud
native
practitioners
to
operate
in
as
such,
I
would
like
to
encourage
everyone
to
continue
building
a
diverse
Community.
We
need
to
further
diversify
our
executive
leadership
governing
and
advisory
boards
and
Technical
committees.
A
And
when
we
look
into
the
end
user,
Community
or
the
doctor,
Community
Cloud
native,
translates
into
extensibility,
it
was
never
as
easy
as
it
is
today
to
Benchmark
different
tools
for
the
same
problem
as
an
end
user.
You
can
choose
the
right
tool
for
your
technical
stack
with
minimal
compromises
and
when
we
look
into
the
community,
Cloud
native
is
all
about
sustainability.