►
From YouTube: Movienight 101: How to Power a Video Streaming with Kubernetes and WebRTC - Rachel Sheikh, Twitter
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Movienight 101: How to Power a Video Streaming with Kubernetes and WebRTC - Rachel Sheikh, Twitter
Movienight 101: How to Power Video Streaming with Kubernetes and WebRTC - Over the past several years, the streaming industry has boomed, with industry leaders like Netflix and Amazon setting the pace for newcomers like Discovery Plus. One of the most difficult challenges to watching movies with others around the world, however, is syncing playback together. Kubernetes is a great solution to solving this challenge. Through its built in ability to load balance traffic to containers, as well as self-healing capabilities, video streaming is able to function seamlessly without a large amount of computational overhead. This talk will provide a quick background on WebRTC, walk through a simplified process of setting up WebRTC to work with Kubernetes, and share some learnings/takeaways gathered from spinning up this project!
A
A
You
can
find
me
on
twitter,
at
rachel,
chic
and
without
further
ado,
let's
jump
into
how
today's
talk
is
going
to
work,
I'm
going
to
keep
things
fairly
high
level
and
accessible
to
all
all
audiences,
so
we're
going
to
cover
what
movie
night
is
what
webrtc
is
how
I
used
webrtc,
how
I
use
kubernetes
and
some
core
learnings
and
takeaways-
that
I
learned
throughout
this
project
that
you
guys
can
take
forward
if
you
ever
want
to
follow
my
footsteps.
So
let's
kick
it
off.
A
So
I
really
like
movies
and
tv
shows,
as
do
most
people
and
I
really
enjoy
watching
them
with
friends
and
family.
However,
when
we
were
quarantining
at
the
beginning
of
the
pandemic,
it
became
really
difficult
to
sync
things
up
and
get
a
watch
party
together
and
it's
always
a
hassle
trying
to
sync
things
up
over
the
phone
where
you're
trying
to
like
start
in
the
middle
of
a
show,
and
everyone
is
trying
to
get
to
the
right
time
stamp
and
then
it's
just
off
by
a
millisecond,
so
you're
hearing
an
echo
the
entire
time.
A
So
I
wanted
to
create
something
to
solve
this
problem.
If
you've
ever
used
disney
plus
they
have
their
new
group
watch
feature
or
if
you
use
the
chrome
extension
netflix
party,
it's
very
similar
to
this,
where
it's
a
distributed
approach
to
concurrently
streaming
video
across
multiple
peers,
so
yeah.
So
it's
just
something
you
can
start
up
as
a
host
start
a
stream
and
then
kick
back
and
watch
with
your
friends
and
they
can
join
in
whenever
they
want.
A
So,
let's
go
over
the
core
technology.
I
used
to
build
this
webrtc
web
being
that
it
can
go
across
web
clients
for
the
most
part
you
have
your
chrome,
firefox,
opera,
pretty
seamless,
rtc
stands
for
real-time
communication,
and
this
is
an
open
source
framework
developed
by
google
to
enable
peer-to-peer
connections
across
different
browsers.
A
You're
looking
at
about
at
most
a
second
of
latency,
which
isn't
great
if
you
want
to
have
a
real-time
watch
party
webrtc,
however,
cuts
out
that
server
in
the
middle
and
just
does
a
direct
peer-to-peer
connection
which
has
its
limitations
and
we'll
be
going
over
them.
So
we
want
to
have
client
and
client
b
talk
to
each
other.
So
what
do
we
want
to
do
to
get
started?
A
First,
we're
having
these
session
description
protocols,
which
are
just
packets
of
metadata,
like
your
audio
codec,
your
video
codec
and
any
other
browser
specific
metadata
points
that
client
a
needs
to
send
to
the
server,
so
that
client
b
can
also
read
it
and
sync
into
it.
So
client
a
will,
send
an
sdp
offer
and
that'll
go
live
in
a
signaling
server
somewhere
and
client
b
will
see
that
offer
and
send
back
its
own
sdp
answer.
A
So
both
of
these
clients
have
sent
through
forward
their
metadata
they're
syncing
up
together,
everything's
seamless,
if
you're
on
the
same
server
or
you're
on
the
same
device
group
done.
This
is
all
you
need
to
establish
that
connection
from
client
a
decline
b.
However,
if
you
want
to
move
past
that
into
the
real
world,
we
have
firewalls
and
all
these
networking
things
to
get
through.
So
this
is
where
interactive
connectively
established
when
candidates
come
into
play
or
ice
candidates.
A
What
ice
candidates
are
are
a
list
of
public-facing
ip
addresses
reports
that
each
client
generates,
so
that
other
clients
can
connect
to
those
public
facing
ports
and
make
the
connection
happen.
What
we
do
to
programmatically
figure
out?
What's
the
best
connection
between
point
a
and
point
b?
Is
we
use
a
stun
server?
Stun
servers
there's
a
bunch
of
free
resources.
A
Google
has
a
bunch
of
stunt
servers
that
you
can
utilize
in
your
projects
where
basically
it'll,
take
a
look
at
candidates,
figure
out
the
best
path
in
between
and
then
as
soon
as
that
pass
is
established.
You
have
a
great
way
to
just
send
data
packets
through,
for
the
most
part,
this
works
for
movie
night.
This
was
it,
but
about
14
of
the
time
which
is
like
your
very
like
large
scale,
things
like
spaces,
it
doesn't
always
work,
and
so
you'll
have
to
go
dive
back
a
little
bit
into
the
websocket
world.
A
Where
you'll
have
these
things
called
turn
servers.
Turn
servers
are
just
publicly
hosted
servers
that
allow
for
the
facilitation
of
passing
data
through
it
so
say,
you'll
have
a
few
clients
in
a
restricted
network
that
can't
connect
publicly
to
a
stunt
server
with
their
eyes
candidates.
So
they'll
connect
with
web
sockets
directly
to
the
turn
server
and
send
their
data
through,
and
then
everyone
else
can
publicly
connect
to
that
cern
server
using
its
own
public
ports
and
ip
addresses
to
get
the
data
via
tcp
or
udp.
Whichever
is
better
so
it
streamlines
things
a
lot.
A
A
I
took
that
I
created
a
signing
server
on
firebase,
let
both
the
clients
sort
of
send
their
sdps
over
to
that
and
sort
of
start
things
off
by
connecting
and
then
starting
an
rdc,
pure
connection
to
send
the
video
data
through
this
sort
of
removed.
Any
need
for
me
setting
up
my
own
videos
server
and
just
let
me
use
the
host
as
the
server.
A
Then
I
separated
in
two
different
laptops.
So
now
I
had
to
deal
with
the
network.
So
now
I
just
use
one
of
those
free
google
stun
resources
to
go
through
the
ice
candidates
from
each
laptop
and
connect
them
over
the
network
and
then
so
now
we
have
essentially
zoom
and
so
to
turn
zoom
into
a
movie
night
session.
A
I
sort
of
cut
off
all
of
the
peers,
video
streams
and
I
only
had
it
running
from
the
host
and
so
I've
used
obs
in
the
past
to
stream
twitch
a
lot
of
people
just
use
it
to
feel
like
to
capture
video
on
their
device,
whether
it's
from
a
screen
a
window
or
just
like
the
whole
display.
So
you
hook
up
the
obs
stream.
You
use
videos
that
you
legally
have
access
to
and
you
sort
of
stream
that
from
the
host
to
all
the
peers
in
a
peer-to-peer
network,
it's
fairly
simple.
A
Now,
here's
where
the
kubernetes
part
of
it
comes
in,
because
if
you
have
one
instance
of
the
movie
night
session
and
you
want
to
scale
up,
kubernetes
is
a
great
way
to
do
that.
You're,
all
a
kubernetes
conference
and
you've
heard
a
lot
of
kubernetes
talk
so
I'll
stay
fairly
high
level
and
stick
to
how
I
used
it
and
one
example
of
something
I
would
have
wanted
to
explore
in
the
future.
A
So
I
put
all
the
single
session
logic
into
a
docker
image
back
when
docker
and
kubernetes
played
well
together
and
put
that
into
a
pod
and
thanks
to
the
kubernetes
config,
I
was
able
to
take
advantage
of
horizontal
load
balancing
with
an
auto
scaler
so
that
each
time
a
new
person
wanted
to
join
in
and
start
their
own
movie
night
session,
they
were
starting
in
a
new
pod.
So
one
instance
one
session
something
I
wanted
to
explore.
If
I
had
gone
a
little
further
is
using
instance
recovery.
A
So
you
have
all
these
pods
all
these
people
watching
their
shows
one
person
watching
squid
game
crashes,
but
because
we
have
all
these
stp
metadata.
So
we
have
the
time
stamp
where
they
died
off
and
we
have
all
their
codec
information.
We
should
be
able
to
spin
up
a
recovery
pod,
stick
them
back
in
there
and
start
them
at
the
exact
same
point,
something
I
didn't
fully
flush
out,
but
I
want
to
get
to
exploring
if
I
ever
touch
back
on
this
project.
A
So
let's
recap
real,
quick
and
tie
it
all
together.
So
first
you're
going
to
build
out
a
single
webrtc
instance
to
stream
a
single
movie
night
session
and
add
it
to
a
docker
image
and
add
it
to
your
pod,
then
you're
going
to
build
out
the
kubernetes
info
around
that
pod
to
be
able
to
scale
it
out,
do
whatever
you
need
to
do,
deploy
it
scale
and
then,
after
that,
you're
good
to
kick
back.
Watch
away.
Start
your
session
keep
on
rolling.
A
A
A
Having
that
conversation
and
someone
can
start
a
video
and
everyone
can
tune
into
that
video
at
the
exact
same
point,
this
could
have
led
into
that
with
just
a
little
few,
more
tweaks,
more
so
like
capturing
that
video
webcam
instance
that
I
had
in
my
initial
poc
and
then
bundling
it
with
the
video
so
that
one
really
cool
to
explore.
The
last
point
is
playing
around
with
different
approaches
to
initial
scaling.
The
way
I
architected
it
out,
you
had
one
instance
or
one
session
per
instance.
A
B
B
B
A
A
Yep
yeah,
so
that
was
something
that
I
like
lightly
played
with
back
when
it
was
still
the
webcam
sort
of
zoom
feature
thing
back
and
forth,
and
it's
something
I
wanted
to
explore
for
that
sort
of
my
point
on
the
sort
of
apple
facetime
stuff,
where
you
could
see
the
people
you're
watching
with
and
still
see
the
video,
and
that
would
just
involve
bundling
that
sort
of
webcam
stream
alongside
the
video
stream
and
just
putting
it
in
your
client.
Further
up
the
corner.
A
So
the
question
was:
did
I
use
the
turn
server
to
sort
of
manage
all
that
and
would
all
those
people
sort
of
stream
into
the
turn
server?
Yes,
so
the
way
the
turn
server
works,
it's
not
just
client
a
and
then
everyone
else
pulls
out.
Actually
everyone
has
a
bidirectional
connection
to
that
turned
server,
so
they
can
all
send
in
data
at
the
same
time,
and
you
just
work
straight
in
the
turn
server
and
just
spit
it
back
out
to
everyone.