►
From YouTube: Keynote: The Long Road to IPv4/IPv6 Dual-stack Kubernetes - Tim Hockin & Khaled (Kal) Henidak
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Keynote: The Long Road to IPv4/IPv6 Dual-stack Kubernetes - Tim Hockin, Principal Software Engineer, Google & Khaled (Kal) Henidak, Principal Software Engineer, Microsoft Azure
Prepare yourself - IPv4/IPv6 dual-stack Kubernetes is almost here! In this session, we will share the journey of how this enhancement has progressed over the years and how the community has banded together to land such a massive change that touches almost every part of Kubernetes. We will also cover the new opportunities that dual-stack provides to the Kubernetes ecosystem including larger cluster size, IoT edge and even dual-stack enabled hosted environments.
https://sched.co/UdIA
A
Hello,
cube,
Khan,
hello,
everybody,
my
name
is
Tim,
and
this
is
my
friend
Karl.
We
just
pulled
a
fast
one
on
you.
We
are
not
gonna
talk
about
ipv6
or
dual-stack.
Hardly
at
all,
we
chose
the
most
boring
most
pedestrian
topic
and
title
that
we
could
possibly
come
up
with
just
so
that
we
can
get
up
on
the
stage.
Now
we're
gonna
talk
about
whatever
we
want.
A
Those
of
you
who
know
me
I've
been
around
the
project
for
a
very
long
time.
One
of
the
roles
that
I
have
been
privileged
to
play
through
this
project
is
being
part
of
the
bootstrap
steering
committee.
Our
job
was
to
look
at
what
our
community
had
been
doing
and
to
think
about
what
made
it
successful
and
to
set
up
the
overarching
governance
that
was
going
to
carry
that
forward
and
make
sure
that
the
that
the
project
continued
to
be
successful.
We
met,
and
we
agonized
for
days
over.
How
do
we
capture
those
principles?
A
What
are
the
things
that
are
really
important
about
this
community
because
there's
really
there's
something
special
about
this
community
and
how
do
we
capture
that
and
keep
it
going?
So
we
had
lots
of
ideas
there,
but
there
was
one
principle
that
I
think
really
captured
it
more
than
any
other,
and
that
principle
is
this
project
over
company.
The
project
is
more
important
than
any
one
company.
When
we
wrote
those
original
steering,
Docs
kubernetes
was
already
kind
of
a
big
project.
Now
it
is
significantly
bigger
than
that.
A
A
Sometimes
often
those
companies
are
in
direct
competition
with
each
other.
Kubernetes
is
so
much
bigger
and
so
much
more
than
any
one
of
these
companies
could
have
done
we're
working
together
towards
a
common
goal.
Co-Op
edition,
without
it
kubernetes
would
not
be
but
a
fraction
of
what
it
is
today.
A
So
since
I've
been
around
for
a
while,
I've
had
a
front-row
seat
to
all
of
this,
and
what's
going
on,
this
is
really
the
heart
of
what
we
think
of
as
our
community
today
we'd
like
to
tell
you
a
little
story
about
how
this
principle
has
allowed
us
to
add
a
complicated
new
feature
to
kubernetes
and
how
would
absolutely
not
have
been
possible
without
our
community
so
like
any
software
project,
we've
added
capabilities
and
features
over
time,
we've
accumulated
and
accreted
and
those
things
are
in
direct
response
to
user
demand.
Right.
A
We
get
a
lot
of
pull
requests
on
a
feature
issue
issue
filed
that
are
asking
us
to
do
things,
and
these
things
are
contributed
by
lots
of
people
with
varying
skill
sets
and
varying
sets
of
expertise.
Now
anybody
who's
played
with
kubernetes
can
understand
that
networking
can
be
tricky
right
and
pretty
much.
Everybody
here
is
probably
familiar
with
tcp/ip
right,
those
dotted
quads
that
you
see
ten
dot
whatever,
whatever,
whatever
those
are
actually
ipv4
right
and
when
most
of
us
think
of
tcp/ip.
We
think
of
ipv4
now
a
little
confession
here.
A
I
am
not
actually
a
networking
expert
everything
I
know
about
networking,
I've
learned
through
kubernetes,
but
early
on
somebody
had
to
do
it.
I
drew
the
short
straw,
so
that
was
me.
So
what
we're
familiar
with
is
ipv4,
but
there's
this
whole
other
thing
that
we
ignored
ipv6
and
like
many
projects
in
this
space,
we
have
quietly
accumulated
ipv4
isms
and
that's
not
good.
Our
code
base
now
is
really
locked
into
ipv4.
A
So
a
couple
years
ago
a
handful
of
motivated
people
stepped
up
and
decided
we're
going
to
fix
this,
and
a
working
group
was
formed.
This
is
how
we
do
things
in
our
community
and
these
folks
did
a
ton
of
hard
grungy
work
and
they
exercised
most
of
the
ipv4
isms
from
our
code
base
and
they
made
kubernetes
compatible
with
ipv6
Harrah
ipv6.
We're
done
right
so
spec
for
small
special.
Thank
you
to
all
those
people
who
stepped
up
and
did
that
work.
We're
done.
B
A
bigger
problem
remains
the
reality.
Is
users
wanted
to
use
ipv6
because
they
wanted
to
integrate
with
IOT
I?
Would
you
compute
like
computing
stacks,
but
then
these
applications
are
not
going
to
be
deployed
in
vacuum
right.
They
need
to
integrate
with
existing
ipv4
services,
cloud
cloud
services
and
points
and
apps
og
just
wanted
to
use
ipv6
because
they
ran
out
of
addresses.
Just
recently
the
EU
handed
out
their
lost.
You
ipv4
block.
The
EU
has
no
more
ipv4
addresses
today.
B
So
when
you
think
about
that
users
wanted
to
use
ipv4
and
ipv6,
and
we
call
that
dual
stack
is
the
problem
right.
We
just
run
ipv6
and
we're
done
so.
We
started
this
journey
trying
to
do
the
work
and
we
start
with
the
api's
like
any
kubernetes
journey
begins.
We
picked
up
the
first
API
object
odd.
Then
we
looked
at
it
and
hoops.
It
has
one
IP
what
we
need
to
write
one
forever
family.
We
did
the
same
for
node
and
then
no
it
has
one
cider
oops.
B
B
B
Can
you
switch
so
as
we
looked
at
that
the
assumption
that
we've
made
actually
not
only
to
the
codebase,
but
also
to
the
ecosystem?
Every
same
kubernetes
was
just
speaking
single
IP
from
the
bootstrap
tools
to
the
load
balancers
to
the
C,
no
I,
every
single
single
IP,
it's
everywhere.
That
challenge
does
not
deter
us
as
a
as
a
community.
As
a
matter
of
fact,
people
get
excited
by
challenges
like
that.
With
that
spirit,
a
group
of
us
started
the
work
on
dual
stack:
probably
late,
2017
October,
November
time
frame
by
June
2018.
B
They
had
a
copper,
netis
enhancement
proposal,
I
kept
as
we
call
it
with
everything
that
we
wanted
to
change
in
kubernetes.
The
Cape
was
just
enormous
right.
The
team
that
picked
that
kept
detailed,
every
single
change,
every
impact
everything
we
needed
to
work
on
to
bring
dual
stack.
That
kept
itself
is
an
example
of
how
to
write
cap
for
copper
nets
by
the
way.
But
then
things
happened,
Tim
couldn't
carry
it
forward
and
dual
stack
efforts
stopped
like
everything.
Kubernetes,
our
ethos
is
ownership.
Without
owners,
things
doesn't
exactly
move
forward.
B
As
Tim
said
earlier,
the
requirement
user
requirements
are
is
our
primary
drive.
The
effort
has
falled,
but
the
requirement
didn't
go
away
by
2019.
It
has
became
even
more
pressing
and
our
never-ending
relay
race.
The
petronas
was
handed
over
to
us
myself
as
an
implement
on
the
implementation
side
and
then
on
the
reviewer
side,
basically
to
make
sure
that
I
don't
run
too
fast
with
scissors
with
a
new
team
in
place.
Our
first
order
of
business
was
to
get
that
kept.
B
The
uncompleted
kept
over
the
finish
line,
and
we
did
the
second
order
of
business
was
to
break
this
enormous
effort.
In
two
phases.
We
chose
to
go
with
three
phases:
each
map,
roughly
to
a
copper
nest,
release
first
phase.
We
wanted
to
do
the
egress.
We
want
to
allow
us
to
do
dual
stack.
Second
phase.
We
wanted
to
do
ingress.
We
wanted
to
allow
traffic
and
clusters
to
receive
dual
stack
traffic
on
both
ipv6
and
four,
and
then
the
last
phase
is
to
bring
this
all
together
in
our
ecosystem.
B
Help
load,
balancer
seen
eyes,
bootstrap
tools
into
their
adoption
journey.
These
changes
are
not
exactly
easy,
but
also
we
wanted
to
execute
in
the
copper
nets
way.
Having
the
feature
is
good,
but
not
good
enough.
We
wanted
to
make
it
easy
to
light
up
these
features
on
your
existing
clusters,
not
just
that.
We
wanted
to
make
sure
that
these
changes
are
backward
and
forward
compatible,
meaning
you
don't
have
to
exactly
predict
your
clusters.
Are,
you
are
breathing,
hopefully.
A
So
now
we
have
a
problem.
We
have
a
new
API
problem
that
kubernetes
has
never
had
before.
How
do
we
take
a
singular
field
and
turn
it
into
a
plural
field
and
stay
compatible
with
all
of
the
clients
that
are
out
there,
because
I
think
we
have
a
few
clients
out
in
the
wild?
How
do
we
change
the
assumption
of
a
single
IP
to
multiply
peas
across
multiple
resources,
pods
nodes
services
endpoints?
A
This
was
going
to
be
a
bit
of
a
challenge,
so
we
took
in
part
all
of
the
obvious
solutions
were
unpleasant
for
various
reasons.
We
really
didn't
want
to
rev
the
entire
kubernetes
api
to
version
2.
Just
for
this,
and
even
if
we
did,
we
still
have
to
have
a
compatibility
story
anyway.
Anybody
who
knows
kubernetes
and
our
community
knows
we
love
a
good
debate,
so
we
got
into
it
API,
reviewers
and
a
bunch
of
other
senior
folks
from
the
project
who
had
good
context
came,
and
we
talked
about
this
at
length
for
literally
months.
A
We
came
up
with
a
model
that
mostly
does
what
people
would
expect
most
of
the
time.
I'm
pretty
good,
feel
pretty
good
about
that.
So
I
want
to
bore
you
with
the
details
of
the
API
I'm
happy
to
talk
about
it
later.
If
you
want,
we
won't
go
into
those
details
now,
but
now
that
we
know
how
to
enact
those
changes,
Cal
started
hacking.
Let
me
tell
you
this
man
is
prolific,
the
resulting
pull
request
was
I,
think
github,
x'
official
term
is
kind
of
large.
A
Just
the
phase
woman,
just
egress
was
over
five
and
a
half
thousand
lines
of
code
and
it
changed
to
core
api
types,
pod
and
node.
We
consider
those
to
be
sort
of
high-risk
changes,
so
we
had
to
think
really
hard
about
how
to
do
those
changes
make
sure
that
they
were
correct
and
they
were
complete,
and
you
know
we
don't
like.
We
don't
really
want
to
break
people's
clusters
if
I
can
avoid
it.
These
are
the
sorts
of
PRS
that
reviewers
bring
pitchforks
to.
A
We
also
had
to
change
a
bunch
of
core
controllers
and
I
say
we,
but
I
really
mean
Cal.
I
just
stood
back
and
watched,
so
we
change
the
end
points
controller,
the
node,
IPAM
controller,
the
route
controller,
and
this
is
all
just
phase
one
remember
so
now
we're
approaching
the
115
code.
Freeze
date:
it's
we
can
see
it
in
our
headlights.
A
We're
coming
off
of
cube
Connie
you
we're
just
coming
out
of
a
long
weekend
really
want
to
get
this
thing
into
the
release,
but
truthfully
time
and
review
bandwidth
are
super
limited,
and
anybody
who
sent
me
a
pull
request
towards
the
end
of
a
code
freeze
window
understands
what
that
means.
We
realized
that
this
PR
needed
to
be
sharted
out.
We
needed
help.
This
was
more
than
a
one
person
effort.
So
we
lit
up
the
bat
signal
on
sic
network.
A
B
Happened
after
that
is,
we
were
floored
by
the
reaction
in
a
typical
bad
signal
situation.
You
would
expect
one
two
three
people
to
step
up:
no,
not
in
this
community
18
people
stepped
up.
18
people
stepped
up
to
help.
We
split
the
review
into
multiple
pieces.
I
personally
remember
who
can
cover
this
piece
on
the
cycle?
A
lot
of
people
who
are
saying
I
I
can
do
that.
We
went
through
the
daily
crunch
of
review,
fix
commit
as
a
collective
as
a
community.
B
B
We
just
fell
a
little
short,
but
we
were
not
defeated.
We
were
back
at
it
again.
The
next
release
beyond
16.
This
time
we
wanted
to
go
bigger.
We
wanted
to
do
egress
and
ingress,
not
because
this
is
how
mad
we
are
in
signature
we
do,
but
by
then
it
was
clear.
We
were
supported
by
a
very
strong
community,
all
right.
Let's
do
this
again
going
back
to
the
drawing
board
and
other
API
discussions.
B
B
B
We
have
no
stack
bootstrap,
we
have
dual
stack
external
load,
balancer
see
now,
as
you
get
you
get
the
picture
by
now.
We
are
already
thinking
about.
What's
next
for
kubernetes
networking
we
want
to
go
further.
We
want
to
enable
multi,
IP
pots,
be
dual
stack
or
not.
That
will
enable
applications
to
do
front-end,
back-end,
classing
networking
scenario.
Anybody
was
old
enough,
like
me,
will
remember
that
the
other
thing
we
also
wanted
is
to
make
it
easy
to
run
networking
virtual
appliance
and
cornetist.
B
We
are
super
excited
about
the
possibilities
we
already
unlocked
these
possibilities,
so
we
just
need
to
do
the
work.
More
importantly,
personally
and
all
of
us
I
think
we
are
super
comfortable
thinking,
big
and
bigger,
because
we
know
by
now
the
community
will
come
and
deliver
again
at
this
future.
A
So
wrapping
up
I
feel
like
I,
should
emphasize
a
few
things.
Almost
none
of
us
who
pulled
this
off
knew
each
other
before
this.
This
is
I
think
the
first
time
Cal
and
I
have
actually
met.
If
it
was
again,
it
was
at
a
Q
Khan
in
passing,
and
you
know,
I,
don't
even
like
this
guy
I'm
kind
of
a
I'm
kind
of
a
Star
Wars
fan
and
I
hear
he
likes
the
other
thing.
A
Almost
none
of
us
work
for
the
same
companies.
Many
of
us
don't
work
in
the
same
countries
in
the
same
time
zones,
but
when
we
all
pulled
together,
something
really
exciting
and
awesome
and
I
really
mean
awesome
in
sort
of
a
biblical
sense
happen.
This
is
what
project
over
over
company
means
to
me.
This
is
why
kubernetes
is
what
it
is.
So
this
talk
is
our
little
way
of
saying
thank
thank
you.