►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-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.
Lightning Talk: Nephio at the Edge - Amar Kapadia, Aarna Networks
In April of this year, Google and the Linux Foundation launched the Nephio project and a jam packed kickoff summit in Sunnyvale in June was an early indicator of early project momentum. Nephio’s goal, in short, is to deliver Kubernetes-based cloud native intent automation templates for cloud infrastructure and xNFs across large scale edge deployments. Nephio enables faster onboarding of network functions to production including provisioning of underlying cloud infrastructure with a true cloud native approach, and reduces costs of adoption of cloud and network infrastructure. But how is Nephio fundamentally different from existing open source approaches? Where are the possible integration points with other open source projects? How can developers think past the workloads to provisioning of underlying cloud infrastructure as well? In this session, Amar will give a Nephio overview and talk about its potential impact to the Kubernetes and edge ecosystems.
A
A
So,
first,
the
problem
statement:
what
are
the
new
problems
that
come
up
when
you
try
to
do
Edge
workload,
for
example
a
network
service,
orchestration
and
management?
And,
in
my
view,
three
things
come
up.
First
is
the
scale
as
we
all
know,
the
edges
can
be
massive
in
comparison
to
to
say
the
cloud
in
terms
of
tens
of
thousands
of
locations,
hundreds
of
thousands
of
devices
and
that's
the
first
challenge.
The
second
is
the
dependence
on
the
infra
that
the
workload
has.
A
For
example,
if
you
take
a
network
service
such
as
radio
area
network,
that
often
requires
gpus
or
dpus,
and
in
so
you
have
to
configure
the
infra
to
suit
the
workload
requirements,
and
the
third
is
just
heterogeneity.
The
edges
heterogeneous
that
are
hyperscalers,
providing
Edge
Solutions
software
companies
providing
cast
solutions
for
private
Edge
implementations,
there's
just
a
lot
of
compute
cache
storage.
Networking.
If
you
look
at
the
diversity,
it's
massive.
A
So
how
this
was
actually
a
a
new
piece
of
information
to
me
that
kubernetes
is
more
than
just
container
orchestration.
I
had
just
assumed
that,
and
what
I
learned
over
time
is
that
kubernetes
is
a
general
purpose,
control
plane
that
just
happens
to
do
container
orchestration
first,
it
can
do
a
lot
more.
So
what
if
we
could
use
kubernetes
for
the
problem
that
I
just
outlined
and
that's
exactly
nephew
by
arrays
of
hands,
how
many
people
are
familiar
with
nephew?
A
Okay,
so
a
few
people.
So
hopefully
this
will
be
new
for
a
lot
of
people.
So
it's
a
new
Linux
Foundation
project
started
this
summer,
so
it's
very
new
and
it's
a
kubernetes
based
intent,
driven
system
I'm
not
going
to
read
the
whole
thing
that
can
be
used
for
Network
functions
and
Edge
Computing
applications
and
the
underlying
infrastructure.
A
A
On
demand
or
private,
your
network
functions
or
workloads
can
be
interconnected
straddling
all
these
sites
they
can
be
Edge
or
Cloud,
doesn't
matter
intent
driven.
This
is
a
huge
piece
of
nephew
where
it's
based
on
configuration
as
data
not
code,
because
I
infrastructure,
as
code,
tends
to
have
imperative
embedded
in
the
descriptor,
and
that
makes
it
very
sort
of
brittle
and
difficult
to
use
and
day.
Zero
configurations
are
automatically
derived.
A
There's
a
I'll
I'll
walk
you
through
it
there's
a
concept
of
mutation
where
your
initial
intent
is
mutated
to
generate
something
that
the
end
cluster
can
consume
and
day.
Zero
configurations
are
part
of
it:
workload,
infra
dependency,
it's
useful
for
both
workloads
and
infra,
and
it's
meant
to
be
heterogeneous.
A
So,
like
I
said,
nephew
uses
kubernetes.
There
are
three
key
pillars
in
nephew:
all
three
pillars:
use
custom
resources
and
us
under
the
custom
resources
they
have
operators.
So
it's
a
standard,
kubernetes
design
pattern.
The
custom
resources
are
in
three
buckets.
First,
are
Cloud
infra
resource
automation,
so
that
deals
with
the
infrastructure
layer.
A
The
next
is
workload,
resource,
automation,
Network
functions
or
Edge,
Computing
applications
and
that
orchestrates
and
manages
applications,
and
the
third
is
workload
configuration.
So
this
third
pillar
can
configure
your
network
functions
or
Edge
Computing
applications
using
whatever
mechanism.
Whatever
protocol
is
required,
it
could,
in
the
network
functions
it
could
be
Yang
netcon
for
Edge
Computing
applications.
That
could
be
rest.
A
A
The
intent
then
gets
mutated
to
something
that
the
end
cluster
can
consume
and
the
mutation
is
based
on
a
series
of
operators,
so
the
operators
can
say.
Oh
you
know
this
cluster
is
small,
so
let
me
adjust
the
scaling
Factor.
Accordingly,
then
you
deploy
the
intent
and
then
the
third
is
very
important
where
you
have
a
control
Loop
that
monitors
the
the
deployment
and
constantly
reconciles
it
with
your
intent.
So
this
is
again
a
key
part
of
intent,
driven
where
you
have
constant
reconciliation
and
below
that
you
have
the
various
clusters.
A
Ci
CD
at
scale
is
also
baked
into
the
project,
so
it's
inherent
there's
projects
called
kpt
kpt
does
packaging
of
kubernetes
resources
and
porch,
which
is
a
wrapper
around
git
and
through
kpt
and
and
porch.
Everything
is
basically
going
to
get
and
you
get
CI
automatically
and
for
CD
there's
a
project
used
called
config
sync
and
where
the
edge
pulls
the
configuration
from
the
central
nephew
cluster
it
it
need
not
be
con
fixing
it
can
be
Argo
CD.
It
can
be
flux,
it's
really
whatever
you
want,
and
because
of
the
two
mechanisms.
A
A
I
have
a
demo
I,
don't
have
much
time
so
I'm
just
going
to
make
some
quick
points
so
on
the
left
is
the
nephew
cluster.
The
nephew
cluster
is
centralized
and
on
the
right
we
are
showing
the
operations
we
are
going
to
do
both
infra
orchestration
and
we're
going
to
do
workload
orchestration
both
and
you'll,
see
how
easy
it
is.
So.
First.
A
So
on
the
right
there
is
a
CRM
file,
kubernetes
resource
file
that
is
describing
what
we
want
to
do
on
the
infra.
So
you
see
it's
very
easy.
It's
simple!
It's
just
saying
what
is
the
repository
from
which
it
should
fetch
the
resource
we
want.
Aws,
eks
and
the
package
type
is
infra
and
there's
a
couple
of
steps
that
are
done
to
apply
the
the
kpt
package
and
then
to
approve
it.
So
now
it's
it's
applied.
Now
we
are
going
to
approve
it
I'm
going
to
speed
through
this.
A
A
Application
or
the
network
service
on
top-
and
that's
also
it's
describing
the
repository-
it's
a
DNS
caching
application
and
the
package
type
is
workload.
So
here
what
you'll
see
is
the
day
Zero
configuration
mutation
is
also
going
to
happen
based
on
the
cluster
type.
It's
actually
going
to
mutate
day,
Zero
configurations,
I'll,
just
show
you
real,
quick
and
I
can
apologize
I'm
flying
through
this.