►
From YouTube: Keynote: Kubernetes as a Foundational Layer of Infrastructure – Vicki Cheung, Engineering Manager
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: Kubernetes as a Foundational Layer of Infrastructure – Vicki Cheung, Engineering Manager, Lyft
At a reasonably sized tech company these days, the infrastructure has to support a variety of use cases: - Production Microservices - Batch Workflows - Machine learning training and deployment with GPUs - Research & Development Not to mention that certain use cases might need custom hardware, thus requiring multi / hybrid cloud. The challenge for our infrastructure team is to keep the overall systems complexity down, while providing an extensible, scalable platform. A year and a half ago, I talked about using Kubernetes for deep learning research at scale. Since then, the platform has matured at an incredible pace. In this talk, I will cover why Kubernetes is the platform of choice for Lyft, as well as challenges and surprises along the way, what use cases were most natural, and how we're migrating production traffic.
To learn more click here: https://sched.co/FzGv
A
Hello
good
morning,
hi
I'm,
Vicky,
hey,
that's
me,
I'm,
an
engineering
manager
at
lifts.
I'm
super
excited
to
be
here
at
the
first
coupe
con
in
China
last
year,
at
Berlin
I
talked
about
how
kubernetes
is
a
great
choice
for
deep
learning
use
cases,
and
this
year,
I'm
super
excited.
We've
come
so
far
as
a
community
and
I'm
gonna
talk
about
why
it
makes
sense
for
a
company
like
lyft,
which
has
a
lot
more
use.
Cases
lyft
currently
only
operates
in
North
America.
So
for
those
who
are
not
familiar,
we're
a
transportation
company.
A
Our
rights
sharing
services
is
available
to
ninety
five
percent
of
the
u.s.
population.
The
scale
of
our
operations
has
has
doubled
every
year
in
the
last
few
years.
A
couple
months
ago,
we
just
crossed
an
important
milestone
of
serving
1
billion
rights
so
to
support
the
rate
of
our
growth.
Our
infrastructure
team
has
built
a
great
platform
for
running
micro
services
and
I'm
here,
to
tell
you
all
about
the
new
generation
of
infrastructure.
That's
based
on
kubernetes.
A
To
give
you
an
idea
of
our
requirements
when
we
were
designing
the
kubernetes
platform,
lift
is
heavily
micro
service
oriented,
so
we
have
over
300
micro
services
running
and
production
running
on
over
40,000
ec2
instances
of
various
sizes
and
they're
all
on
our
Envoy
MS
met.
Work.
Lift
is
the
first
place
of
envoy
and
I'm
gonna
talk
about
this
a
little
bit
later
as
well,
but
we've
been
on
envoys
since
the
beginning,
before
the
introduction
of
kubernetes
into
our
stack,
so
I'm
going
to
talk
about
what
that
means
for
Migration
as
well.
A
So
in
this
talk,
I'm
going
to
talk
about
why
we
decided
to
go
with
kubernetes
that
lift
and
then
talk
about
the
challenges
we
faced
when
we're
migrating
at
enterprise
scale.
So
when
we're
designing
the
new
generation
of
infrastructure,
we
really
have
to
think
about
the
use
cases
and
the
engineers
that
we're
trying
to
enable
and
empower.
A
So,
let's
first
talk
about
the
use
cases
at
a
modern
tech
company.
You
probably
have
a
similar
set
of
workflows
that
you
want
to
support
somehow
they
don't
have
to
be
supported
with
the
same
solution,
but
they
definitely
have
a
lot
of
things
in
common,
for
example,
observability
disaster
recovery,
developer,
tooling,
health
checking
the
list
goes
on
they're,
also
very
different
in
nature,
though
you're
gonna
have
to
have
a
sad
time.
If
you
try
to
ask
your
machine
learning
engineers
to
train
models
on
a
platform,
that's
specifically
designed
to
run
micro
services
and
vice
versa.
A
Now,
let's
talk
about
empowering
I
like
to
think
about
infrastructure
as
accelerating
an
engineer's
productivity
and
allowing
them
to
do
their
best
work.
To
put
it
another
way,
especially
in
a
large
organization
where
you
have
many
many
teams
working
on
very
different
things,
when
this
infrastructure
is
slow
engineers
down
a
lot
of
times,
I
think
we
slow
engineers
down
when
we
required
non
infrastructure
engineers
to
understand
the
nitty-gritty
implementation
details
of
the
infrastructure
to
perform
some
very
simple
tasks
like
set
up
a
web
server,
for
example.
A
Maybe
they
need
to
understand
what
a
cloud
instance
is
and
how
to
provision
an
auto
scaling
group
of
instances?
Then
they
need
to
think
about
how
to
configure
these
instances,
such
as
what
packages
they
install
and
how
to
update
the
dependencies,
and
then
they
need
to
run
the
service
and
then
think
about
what
happens
next,
like
health
checking
keeping
it
up.
A
It
was
exhausting
just
to
like
talk
about
it,
so
you're
like
well.
That
sounds
super
ridiculous
like.
Why
would
you
make
it
so
hard
you're
right,
you
probably
wouldn't,
and
you
most
likely
build
some
abstractions
over
your
infrastructure
and
provide
tooling
to
cut
away
the
overheads
well
building
abstractions
is
super
hard.
Your
abstractions
service
area
needs
to
be
just
right.
A
When
you
hire
an
onboard
new
engineers,
you
have
to
train
them
to
use
your
own
special
sauce
of
abstraction
platform
and
that's
a
lot
of
work,
and
this
is
why
it
lifts
we
decided
to
go
with
kubernetes.
It
provides
a
reasonable
set
of
abstractions
for
our
infrastructure
that
is
well
supported
by
the
community,
its
API
as
flexible
and
extensible.
So
we
found
that
it's
a
great
foundation
layer
for
all
kinds
of
different
workflows
that
we
wanted
to
enable
before
kubernetes
came
along.
We
actually
started
to
introduce
containers
into
our
stack.
A
Cool
great.
This
is
why
we're
all
here
we
just
need
to
migrate
the
co
company
over
and
then
we're
good.
Well,
anyone
who's
done.
A
stack
migration
at
scale
knows
that
this
is
a
challenging
feat,
especially
with
young
technologies,
and
so
there
we
have
it
challenge
number
one
is
that
it
is
a
young
technology
still
and
the
ecosystem
surrounding
it
is
even
younger.
A
Kubernetes
has
matured
a
lot,
and
these
days
you
can
spin
up
a
cluster
on
a
cloud
in
minutes
and
deploy
your
service
right
away.
So
great
job
done.
Why
am
I
here?
Ok,
so
out
of
the
box,
kubernetes
gets
you
pretty
far,
but
at
enterprise
scale.
There's
a
lot
more.
You
need
to
think
about
when
you're
integrating
a
new
technology
do
I
know
how
to
operate
it.
How
does
commissioning
work?
How
do
I
monitor
it?
How
do
I
integrate
it
into
our
existing
observability
and
logging
tooling?
A
A
So
how
do
we
deal
with
this?
We
have
an
internal
release
process
to
verify
that
all
our
add-ons
are
compatible
with
each
other
and
with
our
additions
on
top.
We
also
have
to
make
sure
that
we
have
the
server
ability
into
each
and
every
component
we
as
Prometheus
heavily
for
that
and
we
integrate
it
into
our
alerts
and
dashboards.
A
It
was
a
lot
of
work
for
the
team
to
get
to
know
each
component
to
know
how
to
operate
it
and
know
how
to
monitor-
and
we
also
work
very
closely
with
the
community
to
address
any
bugs
or
scaling
issues
that
we
run
into
ok
cool.
So
now
we
know
how
to
run
kubernetes
challenge.
Number
two
is
even
if
we
can
run
all
of
lifts
on
kubernetes.
We
need
to
think
about
how
to
best
migrate,
the
company
over.
How
do
we
on
board
engineers?
A
It
wouldn't
be
a
successful
migration
if
one
day
we
just
plucked
the
whole
stack
over
and
then
our
engineer
showed
up
to
work
the
next
day
and
then
they
didn't
know
how
anything
worked
anymore.
So
a
straightforward
way
is
to
transition
our
engineers
to
a
new
stack
with
the
old
tooling
that
they're
already
familiar
with.
We
make
sure
that
the
tooling
is
backwards
compatible,
for
example,
the
deployment
UI,
the
observability
dashboards,
all
the
little
things
that
they're
used
to
can
still
talk
to
kubernetes.
That
way
they
can
be
productive
from
day.
One.
A
A
So
knowledge
of
kubernetes
isn't
required
for
our
engineers
to
be
productive,
but
if
they're
already
familiar
with
it,
maybe
from
a
previous
job
from
a
pet
project
or
maybe
they're
just
curious
about
it,
or
maybe
they
want
to
use
some
Community
Supported
tooling,
they
can
and
if
they
need
to
do
something
there
and
house
tooling,
doesn't
support
well
now
they
have
a
Google
of
all
alternative.
They
can
just
use
Kip
cuddle
or
build
their
own
cool.
Now
our
engineers
are
super
productive.
Everything
runs
great.
The
last
challenge,
the
usual
migration
question.
A
How
do
we
actually
turn
the
switch
on?
How
do
we
monitor
the
migrations
to
make
sure
that
our
metrics
continue
to
look
good?
Our
services
are
healthy.
It's
easy
to
roll
back.
Just
to
give
you
a
more
concrete
picture
on
how
our
micro
services
interact
with
each
other,
a
single
request
at
lift
can
go
through
up
to
30
services.
A
We
need
to
be
able
to
migrate
services
on
every
request
path
independently,
so
we
don't
have
to
worry
about
upstream
and
downstream
dependencies
that
way
we
can
slowly
ramp
our
migration
up,
and
so
the
solution
we've
come
up
with
is
to
provide
seamless
routing
between
our
pots
and
our
ec2
instances.
At
the
networking
layer,
our
team
wrote,
as
CNI
networking
stack
to
do
just
that
and
it's
open
source,
so
you
can
check
it
out
and
give
us
any
feedback.
So
it's
an
overlay
free
networking
stack
for
running
turbine
at
ease
on
AWS.
A
A
So
here
is
a
pretty
picture
with
many
pink
boxes.
As
you
can
see
here,
our
career,
a
spot
has
a
first-class
IP
in
our
virtual
private
cloud
in
AWS
envoy
is
running
as
a
sidecar
container
in
our
pot,
and
the
pot
appears
just
like
any
other
instance
on
our
network
and
traffic
can
flow
freely
between
the
stacks
between
various
clusters.
A
It's
all
transparent
this.
This
is
great
also
because
now
we've
invested
a
lot
into
our
envoy
tooling,
and
our
engineers
are
ready
familiar
with
those.
So,
for
example,
we
use
a
love.
We
get
a
lot
of
observability
for
free
with
envoy
here
we
have
distributed
tracing
with
envoy,
where
the
trace
can
cross
between
our
different
stacks
or
even
between
different
clusters,
and
it
just
works.
There's
zero
additional
effort
from
our
engineers
or
from
our
in
our
infrastructure
team,
or
even
additional
onboarding
awesome.
A
We
are
in
the
process
of
migrating
our
production
services.
Today
our
production
traffic
goes
through
both
legacy
and
kubernetes
and
we're
hopeful
that
we'll
ramp
up
significantly
next
year,
so
maybe
talk
to
me.
Then
we
look
forward
to
working
even
more
closely
with
the
community
through
various
open-source
projects
and
thank
you
for
having
me.