►
From YouTube: Keynote: Kubernetes - 1.4 and Beyond by David Aronchick, Senior Product Manager, Google
Description
Keynote: Kubernetes - 1.4 and Beyond - David Aronchick, Senior Product Manager, Google
Kubernetes continues on its torrid pace of releases, each one with features making it easier and more powerful for running distributed applications. During this session attendees will hear the details of the major new features released in Kubernetes 1.4, and what will be coming in Kubernetes 1.5 in December.
About David Aronchick
David Aronchick is a Senior Product Manager for the Google Container Engine, and leads product management on behalf of Google for Kubernetes. David has been helping to ship software for nearly 20 years, founding and being part of the management team for three different startups, as well as squeezing in time at Microsoft, Amazon, Chef, and now Google.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 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.
A
I,
it's
very
important
that
I
mentioned.
I
am
just
one
of
the
PM's
at
Google
working
on
communities
and
in
specific
you
know
it's
not
a
Google
driven
project,
so
we
have
a
brand-new,
not
brand
new
anymore
about
three
months
old,
Cooper,
Nettie's
p.m.
group
and
we
use
that
to
help
drive
the
product.
So
it's
very
much
not
a
Google
driven
thing:
I
contribute
along
with
the
other
Google
PM's,
but
really
we
want
this
to
be
a
Cooper
Nettie's
are
an
open
source
project
and
and
to
have
the
vision
and
the
roadmap
delivered
from
there.
A
So
without
further
ado
I'm
here
to
talk
to
you
about
Cooper,
Nettie's
1.4,
which
came
out
just
about
six
weeks
ago,
Cooper
Nettie's
1.5
coming
out
in
just
about
a
month.
So
you
know
this
is
one
of
my
favorite
grass
I.
I
showed
it
almost
every
conference
because
it
shows
the
pace
of
the
innovation
here
and
and
the
regularity
with
which
new
things
come
out,
and
that
really
is
a
credit
to
the
people
who
are
here
in
this
room
and
watching
over
the
live
stream
and
couldn't
care
less
about
watching
cube
con
at
all.
A
The
ones
who
actually
are
out
there
doing
the
work,
as
you
saw
in
hen,
Goldberg's
presentation
during
the
keynote
more
than
fifty
percent
of
people.
Making
this
line
go
up
into
the
right
are
not
Googlers
and-
and
that
is
something
we
are
extremely
excited
about.
As
I
mentioned
to
me,
coo
Nettie's
1.4
came
out
just
there
at
the
end
of
October,
and
you
can
see
just
a
few
of
the
highlights
that
we
have
here
around
kerber
Nettie's.
A
This
slide
I've
been
presenting
this
particular
statement
for
over
a
year
and
a
half
at
this
point,
and
it
still
remains
our
vision.
There's
a
great
anecdote
when
you
come
to
Google
before
things
like
uber
Nettie's,
and
things
like
that.
You
were.
You
were
unproductive
for
six
months,
because
you
were
learning
entirely
new
ways
of
building
distributed
systems
and
and
that's
something
that
we
want
to
really
transform
about
building
distributed
systems
in
the
world
and
that's
why
this
vision
is
so
important
to
us.
A
We
want
to
bring
it
to
everyone
and
use
the
15
years
of
experience.
We
have
building
it
and
the
years
of
experience,
redhead
and
IBM,
and
all
these
other
folks
who
contribute
at
the
project
to
make
it
easier
to
build
distributed
systems
in
the
while.
Ok.
So
that's
a
little
bit
of
the
background.
Let's
get
into
Cooper
Nettie's
14.
There
are
many
features
in
Cooper,
Nettie's,
14
I'm,
going
to
highlight
just
a
few
of
them.
A
That
I
think
are
particularly
compelling,
but
you
can
go
and
see
an
entire
list
of
them
in
the
coup
benetti's
p.m.
group
in
our
documentation
or
just
mail
me
and
I'm.
Happy
to
talk
to
him
about
them
them.
There
are
three
big
ones
that
I
want
to
call
out,
as
I
mentioned.
The
first
is
improvements
around
set
up
in
management,
particularly
not
just
the
setup
of
the
individual
master
and
the
nodes,
but
even
the
network
itself.
A
A
So
let
me
walk
you
through
this
who
has
heard
that
setting
up
a
Cooper,
Nettie's
cluster
is
hard
all
right.
The
rest
of
you
are
liars.
This
is
a
known
thing.
It
was
very
much
our
him.
It
was
our
intent
to
build
the
building
blocks
to
get
it
out
there
make
it
easy
to
excuse
me,
make
it
very
powerful,
but
we
knew
that
we
were
going
to
come
back
to
focus
on
some
of
the
user
experience
to
getting
things
up
and
running
shortly
there.
A
There
are
some
solutions
today,
if
you're,
if
you're
going
down
kind
of
the
straight
and
narrow
path
you
can
use
Cuba,
which
is
a
script
that
handles
things
very
easily.
If
you
want
to
get
more
complicated,
you
can
compile
your
own
from
head,
but
that's
a
lot
of
things
to
take
on
yourself
or
you
can
use
a
lot
of
the
third
party
applications
and
there
are
many
great
ones
out
there.
You
know
cube
a
cube
AWS
from
Korres
cops,
which
is
a
community-driven
project
and
many
other
ones
do
make
it
easy
to
do.
A
But
we
think
that's
a
failure
mode
that
much
of
the
system
being
set
up
by
a
third
party
application
you
know,
should
require
a
third
party
application
to
get
up
and
running.
We
really
want
to
make
this
part
of
the
core,
so
we
have
a
brand
new
project
at
launch
to
alpha
in
Coober
Nettie's
1.4,
it's
called
cube
ATM.
A
This
is
going
to
be
one
of
those
things
that
people
debate
how
it's
pronounced,
of
course
cube
adam
QD,
I
don't
know
I
should
take
a
show
of
hands
to
see
how
people
pronounce
cube
cuddle,
but
I
guess
we'll
see
so
cube
ATM
first,
every
component
to
Coober
Nettie's
is
packaged,
so
you
can
from
your
favorite
repo
get
a
package.
This
is
what
that
looks
like
literally
to
get
it
up
and
running.
You
type
that
package
it
installs.
It
then
on
your
master,
node,
you
type
too
bad
a
minute
and
you
have
a
cluster.
A
That's
it
seriously.
The
nice
part
is
the
last
line
of
that
cluster
cube,
join
and
a
token
you
go
to
a
node
that
already
has
the
packages
of
salt
installed,
assume
or
I.
Show
you
doing
it
there
you
type
cube,
join
it
even
gives
you
the
IP
address
presto.
You
now
have
a
two
node
cluster,
that's
it
and
then
finally,
I
mentioned
about
overlay
networks
and
networking.
Many
folks,
if
you're
running
in
a
cloud,
google
cloud
AWS
things
like
that,
a
lot
of
this
stuff
is
taking
care
for
you.
A
However,
many
who
deploy
on
premises
or
across
multiple
clouds
might
run
into
challenges
because
their
networking
topologies
are
more
complex
than
just
flat
networks
and
overlay
network
is
a
great
solution
for
that
benetti's
1.4.
We
have
the
brand-new
CNI
interface
and
anyone
who
subscribes
to
that
interface
can
use
that
for
deploying
nodes.
This
is
an
example
from
we've
works,
but
anyone
any
network
provider
who
uses
this
can
do
it
and
you
literally
type
that
command
and
presto.
A
Let's
do
a
demo,
so
unfortunately,
I
had
to
record
the
demo
a
very
short
amount
of
time,
and
some
of
these
steps
require
fast
forwarding,
not
because
they're
hard,
but
because
it
does
take
some
time
for
things
to
get
going
so
in
the
upper
left
here
this
will
be
my
master
on
the
left-hand
side.
These
two
will
be
nodes
will
get
them
going.
As
I
said
there,
you
type
cube
at
a
minute,
that's
a
little
bit
high.
Can
you
see
that
off
you
go
it
does
some
commands?
A
Does
some
output
that
I
didn't
print
out
earlier
and
that's
it,
but
that
really
was
it
I
didn't
have
any
steps
in
between
there.
It
takes
a
little
bit
longer,
as
I
mentioned.
If
I
had
time
there,
you
could
see
it,
but
that's
it.
Your
master
is
done.
You
then
grab
that
last
token,
there
as
I
said
and
I'm
going
to
copy
it
over
to
these
two
other
things
and
off
they
go.
A
Those
nodes
are
being
set
up
as
we
speak
right
now
and
then
I'm
just
going
to
show
you
those
nodes
they,
like
I,
said
they
usually
take
just
a
few
seconds
to
get
going.
If
I
do
the
watch
API,
you
can
see
them
come
up
and
then
there
are
so
about
15,
10
to
15
seconds
and
your
nodes
are
live
and
joined.
The
cluster
I
mentioned
about
the
daemon
set
networking
across
all
of
this.
A
What
it
does
is
it
deploys
pods
that
subscribed
your
that
use
your
daemon
set
area,
your
net
overlay
network
provider,
a
daemon
set,
deploys
one
and
only
one
pod
to
every
node,
and
so
that
can
provide
your
overlay
Network.
This
is
using
we've.
As
I
mentioned,
I
enter
it,
it's
been
created
and
then
I'll
show
you
in
the
watch
here
you
can
see
at
the
bottom.
A
Those
three
pods
one
for
each
of
the
nodes
in
the
system
have
been
created
and
deployed
to
their
appropriate
spots
so
that
that
really
is
it.
That
is
our
goal
with
Cooper
Nettie's,
our
cube
ADM,
to
make
setting
up
and
using
a
cluster
very,
very
easy.
Okay,
normally
I'd
have
stopped
for
questions
here,
but
I
have
zero
times,
so
I
will
continue
on
second
cross
cluster
Federation.
So
this
is
one
of
the
most
requested
features.
People
don't
want
to
deploy
to
single
zones.
They
don't
want
to
deploy
to
even
single
clouds
anymore.
A
They
would
really
like
to
deploy
in
ways
that
make
sense
for
their
business
needs.
You
may
have
Geographic
requirements
related
to
data
locality.
You
may
have
Geographic
requirements
related
to
latency.
Maybe
you
have
many
users
in
Europe
many
users
in
Asia,
and
you
want
to
have
applications
to
out
to
those
various
places.
Those
are
easy
to
get
started
right.
You
could
just
spin
up
a
cluster
in
each
one,
but
then
you've
developed
a
whole.
A
You
have
to
develop
a
whole
new
management
layer
on
top
of
that
to
coordinate
your
applications
between
these
and
that's
not
ideal
right
right
for
opportunity
for
a
problem,
so
this
is
might
be
how
you
do
it
as
I
said
here.
These
are
three
examples:
USA
and
Asia,
with
various
applications
in
each,
and
so
you
might
individually
deploy
to
each
one
of
those.
A
Then
you
would
deploy
a
service
to
each
one
separately
and
then,
on
top
of
that
you
might
have
a
global
load
balancer,
but
the
global
load
balancer
would
be
decoupled
from
the
services
that
you
created,
giving
you
yet
another
management
headache
that
you
have
to
keep
up
to
speed.
So
the
solution
is
to
use
across
clustered
replication
and
arcs.
A
Is
me
federated
replication
controllers
and
ingress,
and
by
doing
this,
what
you
do
is
first,
you
deploy
in
one
of
the
clusters:
multi
federated
federated
API
masters
will
become
shortly,
be
coming
shortly
right
now,
it's
just
in
one
you
deploy
in
one
a
federation
master
and
you
join
all
those
clusters
to
that.
Federated
master
and
then
that's
what
you
interact
with
in
order
to
deploy
these
things.
A
So,
for
example,
you
might
have
an
application
like
that
up
there,
that
you've
described
you
hand
that
to
the
API
master
and
it
takes
care
of
rolling
out
to
all
the
items
in
that
federated
cluster.
Similarly,
with
a
service,
you
would
roll
that
out
to
the
service
and
it
would
deployed
all
those
individual
clusters
and
then
that
global
load
balancer
through
a
federated
ingress
would
be
kept
in
sync
with
those
clusters
as
they
are
outstanding,
then
let's
say
you
wanted
to
do
a
rolling
deployment
across
those
clusters.
A
A
So
here,
I
just
have
a
very,
very
simple
demo:
it's
the
guestbook
demo,
basically
a
text
box
and
a
blue
banner
at
the
top
I've
already
set
up
three
clusters,
one
in
Europe
in
Frankfurt,
one
in
another,
one
in
Europe
in
the
UK
and
one
in
the
u.s..
You
can
see
the
three
clusters
there
and
I'll
just
show
you
really
quickly
this
third
one,
this
service
Oh
skip
that
the
service
is
just
very,
very
straightforward.
A
It
doesn't
even
understand
what
clusters
it's
being
deployed
to
right
now,
but
I'm
going
to
roll
it
out,
I'm
going
to
apply
that
service
and
roll
it
out
to
the
public,
and
once
it's
rolled
out,
I
then
bring
I'm
going
to
bring
up
a
public,
endpoint
and
I.
Don't
know
you
can
read
it
up
there,
that's
a
public
endpoint
that
doesn't
specify
exactly
where
it
is.
So
if
I
access
this
I'm
going
to
use
incognito
mode,
so
it's
not
cached!
You
can
see
up
there
randomly.
A
A
And
then,
when
I
access
it
again,
I
open
a
new
one,
incognito
window
hit
the
same
load,
balancer,
I'm,
redirected
and
automatically
goes
forward
again.
That
was
not
in
my
coup
benetti's
manifest
it
was
not
in
the
service
manifest
it
just
rolled
out
by
itself.
So
then,
following
up
with
that
now
so
I
have
my
application
out
there.
It's
running
eight
pods
spread
across
these
clusters.
Now,
let's
say
I
want
to
do
an
update.
Well,
I
can
do
a
rolling
update
where
I
destroy
one
and
create
another
one.
A
But
another
very
common
deployment
pattern
is
blue,
green
mm-hmm,
blue
green,
where
you
might
have
one
set
of
nodes
that
are
deployed
or
one
set
of
pods
that
are
deployed
and
a
second
set
that
that
basically
come
up
simultaneously
to
make
sure
that
the
new
one
is
operating
properly
and
coordinate
as
it
comes
up.
So
I'll
do
that
here,
I'm
going
to
roll
out
the
green
one
simultaneously.
A
Yes,
there
you
go
and
that
green
one
is
deploying
and
as
it
deploys
it
comes
out
and
it
came
up
very
very
quickly
and
then,
when
I
go
out
and
access
that
in
in
the
wild
I'm
getting
50,
I
went
for
a
little
quickly
there,
it
access
tit
and
it
showed
up
with
a
green
one,
50
50
and
then
once
I
make
sure
it's
up
and
running
and
operating
properly
I
can
scale
the
previous
one
down
to
zero.
So
again,
you
didn't
see
me
at
any
point.
A
There
specify
a
specific
cluster
even
understand
the
fact
that
this
was
rolling
out
in
this
way,
I
simply
dictated
according
to
my
application,
its
requirements,
and
it
was
able
to
scale
out
very,
very
powerful
and
in
fact,
probably
even
a
little
bit
better
than
we
do
things
today
at
Google,
where
it
requires
quite
a
bit
of
manual
interaction
in
order
to
get
that
right.
So
20
minutes
is
very
short
amount
of
time
all
right
final
one.
A
Let
me
talk
about
helm
or
excuse
me
rolling
out
new
applications
today,
when
you
roll
out
an
application
to
Cooper
Nettie's
at
best,
maybe
you
grab
a
docker
container.
You
have
to
think
about
the
services
and
all
those
various
things
you
might
scratch
your
head
and
say.
Well,
there's
got
to
be
a
better
way.
Someone
must
have
done
this
before
and
in
fact,
that's
exactly
what
we've
decided
to
do
so
with
the
community
help
particularly
led
by
deus.
We
have
a
brand
new
package
manager,
specifically
for
Cooper,
Nettie's,
called
helm.
A
Helm
is
made
up
of
helm
the
package
manager
and
then
a
series
of
charts
whenever
your
packages
and
Linux
think
the
analog
is
charts.
So
with
that
you
say
helm
in
it
and
then
you
deploy,
for
example,
variety,
be.
It
looks
like
this.
You
did
jenkins.
It
looks
like
this.
You
deploy
my
sequel,
it
looks
like
this,
and
these
are
the
basics
right.
Obviously,
there
are
plenty
of
ways
to
configure
this,
but
you
can
be
sure
that
this
is
going
to
be
useful
straight
out
of
the
box
tested
by
the
community.
A
Contributed
by
the
community
will
try
and
get
through
this.
This
is
a
complicated
demo,
but
I'm
going
to
show
you
nonetheless
of
this
one
I
am
going
to
actually
deploy
in
a
way
that
that
makes
me
understand
what
my
underlying
cluster
federation
looks
like
and
that's
for
a
very
specific
reason
in
this
case
I'm
going
to
do
postgresql,
and
so
this,
where
I'm
going
to
deploy
it
in
a
high-availability
configuration
where
one's
own
has
a
master
and
then
a
second
zone
has
two
replicas
associated
with
it.
A
In
this
case,
I
want
to
deploy
one
to
my
post
grass
master
to
London
and
I
type
helm,
install
I,
give
it
a
instruction
like
London
to
deploy
it
to
and
that's
it
that's
it
postgres.
Now
up
and
running,
then,
let's
say
I
want
to
deploy
those
replicas
of
the
Cooper.
Nettie's
master.
Excuse
me
of
the
postgres
master.
A
Now,
in
this,
in
this
particular
case,
there's
a
little
bit
of
magic
going
on
here,
because
normally
you're
Cooper
Nettie's
clusters
wouldn't
have
a
common
IP
pool
to
derive
from
because
we
were
using
we've
from
that
first
example:
you
have
a
global
address
space
that
you
can
pull
from
and
that's
how
these
replicas
saw
it,
but
you
can
easily
handle
that
in
myriad
other
ways,
just
to
show
you
that
is
in
fact
what
happens.
This
is
a
product
by
we've
called
we've
scope
and
you
can
see
there.
A
The
three
clusters
are
now
up
and
running
and
then,
when
I
go
here,
to
show
you
that
this
is
actually
useful.
This
is
the
guest
book
example
that
has
been
augmented
to
use
the
local
postgres
for
that
particular
cluster.
In
this
case,
I'm,
going
to
start
typing
things
in
this
box,
hello
cube
con.
Isn't
this
amazing?
These
are
stored
locally,
but
because
this
is
a
master
replicas
replicated
service
when
I
reload
this,
in
fact,
when
I
actually
type
it
I'm
going
to
force
going
to
the
Germany
cluster.
A
Here
you
can
see
there
at
the
top
I've
swapped
out
and
gone
to
a
different
cluster,
and
yet
those
those
replicated
services
or
to
me
that
replicated
data
has
flowed
through
so
cluster
up
and
running
working
properly,
all
using
home
all
right
and
then
what
would?
What
would
demo
be
without
a
UI
I
will
not
show
you
a
UI
I
will
show
a
screenshot
of
the
new
UI.
This,
in
fact,
is
the
new
UI.
It's
great.
A
It
has
really
cool
things
like
being
able
to
see
aggregated
memory
and
CPU
usage
across
a
given
application,
as
well
as
over.
Ninety
percent
of
all
the
objects
in
the
system
are
available
via
the
you,
the
UI,
so
that's
koo,
pernetti's
one
for
just
a
small
subset
of
the
features.
I
have
very
little
about
a
time
so
I'm
going
to
go
quickly
here,
but
what's
next
we're
going
to
continue
to
advance
along
deployment
and
management,
we
want
to
make
a
bunch
of
investments
around
non-disruptive
system,
invit
maintenance.
A
We
want
to
move
cube
Adam
to
beta,
which
is
currently
on
track,
as
well
as
making
setting
up
of
those
clusters.
Those
federated
clusters
very
very
easy:
we're
also
going
to
continue
to
advance
along
the
stateful
applications
and
far
more
charts,
we're
already
up
to
17
charts
and
our
goal
is
you
know
to
get
to
all
of
your
most
common
applications
to
be
deployable
via
that
package
manager
and
then
finally,
more
federated
clusters?