►
From YouTube: Lightning Talk: Architecting Geo-distributed and Hybrid 5G Edge wit... Sachin Rathee & Robert Belson
Description
Lightning Talk: Architecting Geo-distributed and Hybrid 5G Edge with Kubernetes - Sachin Rathee, Red Hat & Robert Belson, Verizon
There’s been a lot of talk about "the edge" but what does that really mean in the context of your infrastructure and application architecture? With the proliferation of high-speed 5G networks, Verizon developed a mobile edge computing platform to support customer demands for increasingly immersive experiences. In this session, the Verizon and Red Hat will share our experiences with using Kubernetes on Verizon 5G Edge to orchestrate and schedule container deployments across hybrid clouds that may include public footprint with AWS Wavelength Zones and/or on premises AWS Outposts simultaneously. Moreover, learn how the edge discovery service can be used to support advanced deployment techniques and day 2 operations. Leave this session with an understanding of best practices for Kubernetes at the network edge and learn how to run an Kubernetes worker node on public/private edge for your ultra low-latency applications.
A
B
Thanks
sachin
and
hello,
everyone
thanks
so
much
for
joining
this
session.
We're
super
excited
to
tell
you
a
little
bit
more
about
our
experiences
working
together
to
build
the
next
generation
of
hybrid
mobile
edge,
compute
applications
using
kubernetes,
and
I
think
it
all
starts
with
defining
what
the
edge
actually
is
and
that
it's
an
inherently
ambiguous
term.
I'd
argue
that
the
edge
is
both
the
device.
You
often
have
in
your
back
pocket.
B
The
various
5g
radios,
you
might
see
as
you
walk
along
a
city
street
or
on
the
highway
itself,
as
well
as
anything
in
between
any
edge
endpoint
could
be
defined
as
part
of
an
overall
cloud
continuum
and
what
gets
us
so
excited
about
the
edge?
Isn't
just
that?
It's
more
performant!
It's
not
just
the
speed,
the
latency,
the
throughput,
but
it's
that
you
can
start
to
unlock
new
revenue
streams,
because
you
can
often
introduce
new
features
as
a
result
of
the
edge
topologies.
B
B
I
want
to
talk
a
little
bit
about
the
challenges
here,
because,
while
edge
applications
unlock
all
of
these
fascinating
capabilities,
they're
pretty
difficult
to
build,
as
you
think,
about
edge
use
cases
that
necessitate
higher
performance.
Perhaps
a
disaster
response
based
use
case
today,
you
could
find
yourself
in
a
scenario
in
the
absence
of
the
edge
that
the
actual
workload
is
a
thousand
miles
away
from
those
end
devices.
B
That's
not
going
to
work
in
the
future.
More
broadly,
can
you
introduce
the
edge
in
such
a
way
that
doesn't
disrupt
the
existing
ways
you
deploy
applications
and
the
existing
ways
you
orchestrate
your
containerized
workloads
and,
lastly,
as
you
start
to
introduce
new
paradigms,
not
just
for
the
cloud
itself,
but
your
device
fleet?
Are
you
going
to
know
ahead
of
time
whether
that
device
is
connected
to
a
public
network,
a
private
network?
B
Could
we
find
ourselves
in
a
world
where
you
have
a
mix
of
devices
and
then
how
does
your
edge
environment
care?
For
that?
Do
you
need
to
decide
ahead
of
time
to
all
of
those
challenges?
We
worked
with
red
hat
to
address
each
of
those
by
trying
to
create
a
kubernetes
native
implementation
to
solve
these
challenges.
A
Now,
when
looking
at
kubernetes
solutions
suitable
for
edge
we're
not
just
looking
at
edge
deployment
option
but
we're
looking
at
an
end-to-end
solution,
this
is
where
openshift,
which
is
a
kubernetes
distribution,
comes
into
play.
It's
a
solution
that
takes
care
of
development
of
apps,
provide
consistency
in
their
deployment,
as
well
as
maintains
consistent
resource
consumption.
No
matter
where
it's
deployed.
A
Openshift
also
has
capability
to
interface
with
any
infrastructure
components,
whether
it's
networking
storage,
supports
various
cpu,
architectures
and
gpus,
depending
on
the
use
cases
from
security
perspective.
How
data
is
handled
at
edge
is
also
of
paramount
importance,
and
for
that
openshift
provides
highly
secure
solution
built
on
railcore
os
with
openshift.
You
have
a
solution
that
can
be
deployed
seamlessly
or
any
infrastructure
using
its
native
capabilities,
whether
it's
full
deployment
or
installing
an
existing
environment.
B
And
as
you
think
about
the
reference
architecture
here
at
the
highest
of
levels,
there
are
ongoing
discussions
about
how
to
best
deploy
kubernetes
at
the
edge
from
our
experience.
What
we
think
is
going
to
be
most
successful
from
a
mobile
edge
perspective
is
to
take
that
control
plane
for
a
given
region
and
actually
centralize
it
in
the
region
itself
and
then
for
each
incremental
set
of
edges,
each
of
which
could
be
separated
by
over
a
thousand
miles
apart.
B
The
nodes
would
essentially
be
the
spoke
in
the
hub
and
spoke
architecture
that
way
you're
reusing
the
same
control
plane.
It's
cost
efficient,
it's
easier
to
manage,
and
in
a
world,
particularly
in
the
future
of
10
20
50
100
edges,
you
reduce
the
complexity
of
management.
Nonetheless,
now
you'll
have
challenges
around
multi-cloud
multi-region.
A
Now
edge
is
not
limited
to
a
particular
geography,
or
technology
edge
could
be
private
to
an
enterprise
or
public
where
it
can
be
accessed
by
anyone.
It
could
be
on
a
cloud
platform
or
multiple,
disparate
cloud
platforms.
However,
the
need
to
manage
from
a
central
location
still
remains.
This
is
where
open
cluster
management
project
comes
into
play,
which
is
a
cncf
project.
A
Open
cluster
management,
which
is
supported
as
advanced
cluster
management
by
red
hat,
solves
the
problem
by
deploying
and
ingesting
cluster
configuration
from
multiple
kubernetes
platforms
and
use
it
to
manage
edge
application
deployed
anywhere.
Once
clusters
are
under
advanced
cluster
management,
users
can
get
full
observability
and
can
manage
all
kubernetes
cluster
from
a
single
dashboard.
B
A
Look
at
infrastructure
automation,
it
requires
use
of
software
to
create
repeatable
instructions
and
processes
that
reduce
human
interaction
and
makes
management
less
error
prone.
The
right
automation,
platform,
install
and
running
in
the
right
location
can
improve
activities
like
provisioning
configuration
management,
security
and
compliance.
A
A
B
But
now,
let's
talk
about
one
additional
challenge
in
the
world
where
you
fully
automated
and
abstracted
away
the
complexity
of
the
in
for
itself.
You've
still
introduced
a
problem
around
edge
discovery,
even
in
the
case
of
a
single
cluster.
How
does
a
given
mobile
application
understand?
Natively,
which
edge
is
the
closest
edge?
In
fact,
if
we
borrow
from
the
airline
industry,
when
they
often
say
the
closest
exit
may
be
behind
you,
that
very
much
is
true
in
an
edge
discovery
scenario.
B
It
could
very
well
be
that
you're
in
boston,
a
highly
immersive
application
needs
to
be
delivered
and
the
closest
edge
could
be
in
miami.
It
all
has
to
do
with
the
topology
of
the
mobile
network
and
the
nature
of
where
your
device
is
in
fact
anchored
within
the
packet
core
of
our
mobile
network,
with.
A
B
The
complexity
of
the
infrastructure
itself:
that's
why
we
developed
the
edge
discovery
service,
an
api
that
any
developer
can
use
to
solve
these
challenges.
It's
a
simple
api
that
essentially
allows
you
to
take
advantage
of
crud
operations
for
a
service
registry,
populating
edge
endpoints
with
an
fqdn,
the
ip
address
for
those
carrier-facing
workloads.
And
then
you
just
query
it
passing
your
ip
address
as
a
mobile
device
or
iot
device,
and
out
comes
the
closest
edge,
it's
incredibly
powerful.
A
B
That's
exactly
what
you're
seeing
here
on
the
left-hand
side,
these
machine
sets
are
spanning
a
physical
data
center,
or
rather
a
physical
outpost
in
dallas
and
then
equipment
that
you've,
perhaps
never
even
seen
before,
because
it's
a
wavelength
zone
in
boston
in
new
york
city
on
top
of
the
region
itself.
So
you
have
all
this
infrastructure
being
infra
that
you
manage
infra,
that's
managed
for
you,
separated
by
a
thousand
miles
all
abstracted
away
via
machine
sets
and
then
by
inspecting
each
of
these
nodes
or
each
of
these
workloads.
B
You
can
see
all
of
that
relevant
metadata
right
at
your
fingertips,
but
going
back
to
the
edge
discovery
service.
What
we
did
is
we
created
an
admission
controller
that
any
time
requests
are
made
to
the
kubernetes
api
server
to
expose
a
given
workload
that
thus
would
necessitate
for
the
edge
discovery
to
actually
know
about
this
workload.
B
We
would
then
intercept
that
request,
figure
out
the
end
node
being
exposed,
take
that
metadata
populate
it
to
the
edge
discovery
service
and
then
keep
that
valuable
state
information
in
a
config
map.
So
this
is
how
we're
using
kubernetes
native
objects
to
bring
together
network
intelligence
and
a
hybrid
multi-cloud
mobile
edge
computing
world.
We
recognize
that
this
is
just
the
start.
B
We
invite
you
to
join
us
on
this
journey
by
visiting
github.com,
verizon
5ghz
tutorials
to
learn
more,
and
we
hope
that
together,
verizon
and
red
hat
can
be
your
trusted
partner
for
solving
your
next
generation
of
challenges
and
opportunities
on
the
hybrid
mobile
edge
thanks.
So
much
and
hope
you
enjoy
the
rest
of
kucon.