►
From YouTube: Webinar: What’s New in Kubernetes 1.10
Description
In the first release of 2018, Kubernetes 1.10 continues to advance maturity, extensibility, and pluggability of Kubernetes. This newest version stabilizes features in 3 key areas, including storage, security, and networking.
Join members of the Kubernetes 1.10 release team who will cover some of the major features in this release and demo some of the highlights in the area of storage including the Container Storage Interface (CSI) and Local Persistent Volumes.
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
Right
so
we're
ready
to
start
welcome
everyone.
My
name
is
yaara
wretzky
I'm,
a
developer
advocate
at
cloud
negative
computing
foundation,
and
today
we're
here.
We
skate
and
Bernard
from
our
from
the
Linux
Foundation
from
cloud
native
computing
foundation.
Who
is
helping
us
with
hosting
the
webinar,
and
we
have
to
present
us
today.
A
Bofur
representing
Google
and
storage
special
interest
group
at
cabin
and
his
community
have
suddely,
who
is
the
6
torch,
lead
and
shallow,
who
is
a
sleek
storage
member
at
Benares
community,
and
today
today
we
will
speak
with
you
about
about
communities
1
to
10
the
latest
release
of
Copernicus.
The
media
highlights
about
this
release
and
that,
together
with
michelle,
will
highlight
two
major
and
prominent
features
that
have
landed
in
this
release.
B
A
Heaven
only
25
of
features
is
that
community
has
been
focused
on
enhancing
the
existing
features
from
the
previous
iterations
and
to
developing
some
extremely
brand-new
functionality.
At
the
same
time,
we
had
a
few
major
errors
where
the
community
has
been
working
working
on
in
during
communities
one
to
ten
attrition,
including.
A
B
Thank
you
her.
So,
in
the
storage
state,
we've
been
working
on
a
number
of
features.
This
quarter
mostly
moving
features
that
we
started
on
in
the
last
year.
Moving
them
to
beta.
One
of
those
features
is
the
container
storage
interface,
which
I'm
going
to
talk
about.
Another
feature
is
local,
persistent
storage,
which
Michelle
is
going
to
tell
you
more
about.
We
also
had
a
femoral
storage
resource
go
to
beta
as
well
this
quarter.
So
let
me
jump
in
and
explain
a
little
bit
more
about
CSI,
as
I
mentioned,
CSI
is
beta
in
1.10.
B
It
was
introduced
in
as
alpha
in
the
1.9
release,
which
was
last
quarter.
So
let
me
refresh
your
memory
about
what
the
problem
is,
that
CSI
is
trying
to
solve
the
kubernetes
volume
plug-in
system
that
you're,
probably
familiar
with
already,
is
very
powerful.
It
makes
it
easy
to
consume
block
and
file
storage,
but
it's
been
challenging
to
add
support
for
new
entry
volume
plugins
with
the
existing
volume
subsystem,
because
it
requires
checking
a
plug-in
code
into
the
kubernetes
core
repository,
and
this
is
painful
for
a
number
of
reasons.
B
For
this
reason,
and
a
number
of
other
reasons,
we've
wanted
to
have
a
mechanism
by
which
volume
plugins
can
be
added
to
kubernetes
completely
out
of
tree
along
came
the
container
storage
interface,
and
this
was
a
collaboration
between
not
just
kubernetes
but
other
cluster
orchestration
systems,
including
mezzos
cloud,
foundry
and
docker.
What
we
realized
is
that
there
was
this
need
across
the
industry
for
a
standard
that
would
have
label
enable
us,
the
container
orchestration
systems
to
expose
arbitrary
storage
systems
to
our
containerized
workloads
and
storage
provider.
Storage.
B
Vendors
also
wanted
to
be
able
to
have
one
standard
to
which
they
can
design
a
plugin
for
and
have
it
work
across
all
CEOs
so
that
they
don't
have
to
re-implement
it
for
every
single
orchestration
system.
This
specification
was
started,
work
on
it
started
last
year
in
February,
and
the
point
to
release
has
just
been
cut,
that
should
say:
February
2018,
not
2017,
and
the
specification
for
the
interface
has
been
published.
Github
it's
open
source.
You
can
collaborate
on
it
at
the
specified
URL,
but
the
specification
alone
is
just
an
interface.
B
B
First
of
all,
there
is
a
storage
class
in
your
storage
class.
You
specify
you
point
to
the
CSI
driver
as
your
provisioner
and
you
pass
in
any
parameters
that
you
want
to
be
passed
in
when
a
new
volume
should
be
created.
Think
of
this
as
a
template
for
creating
a
new
volume
and
when
you
want
to
create
a
new
volume
as
an
end
user,
you
will
create
a
persistent
volume
claim.
This
is
the
exact
same.
B
Persistent
volume
claim
that
you're
used
to
you
should
point
to
a
storage
class
that
will
provision
a
CSI
volume
in
this
case
fast
storage
that
we
created
up
above
will
result
in
a
CSI
volume
being
provisioned,
and
then
you
can
use
it
in
your
pod
in
exactly
the
same
way.
In
the
volume
section
of
your
pod
specification,
you
specify
persistant
volume
claim
and
the
claim
name
corresponds
to
the
to
your
PVC
and,
of
course,
you
can
still
pre
provision
a
volume.
B
If
you
want
to,
for
a
CSI
volume,
you
can
create
manually,
create
a
persistent
volume
object.
This
is
normally
done
automatically
if
you're
using
dynamic
provisioning
through
PVC
and
a
storage
class.
But
if
you
don't
want
to
use
storage
classes,
you
want
to
pre
create
your
volumes.
You
can
do
that
by
creating
your
own
persistent
volume
object
and,
in
your
specification,
specify
that
it's
a
CSI
volume
specify
in
the
driver
which
driver
to
you.
It
is
the
name
of
the
volume
is
the
volume
handle
and
additional
attributes
that
are
specific
to
that
volume.
B
So
we're
moving
to
beta
this
quarter
and
you
might
be
wondering
what's
new
in
beta.
The
big
difference
is
that
CSI
is
now
enabled
by
default.
You
don't
have
to
opt
in,
as
was
the
case
with
alpha
and
we're
also
snapping
to
the
zero
point
to
release
of
the
CSI
spec.
The
zero
point
to
release
has
a
number
of
braking
changes
from
zero
point
one.
B
So
if
you
had
a
zero
point,
one
driver
please
make
sure
that
your
driver
has
been
updated
before
you
use
it
with
kubernetes
110,
and
then
we
had
a
bunch
of
features
go
in
on
the
kubernetes
side
of
things,
including
mount
propagation,
which
is
a
dependency
for
deploying
CSI
drivers.
That
feature
has
moved
to
beta
we've,
also
improved
security
around
the
volume
attachment
objects
which
are
required
to
attach
and
detach
CSI
volumes
by
reducing
which
volume
attachment
objects,
a
particular
node
can
access.
B
It
can
only
access
volume,
attachment
objects
for
the
volumes
that
are
scheduled
on
that
node.
We've
also
improved
secret
support
for
CSI,
so
each
of
the
different
CSI
calls.
Now
you
can
specify
the
secret
Association
associated
with
it
in
the
CSI
persistent
volume
source
object.
You
can
also
specify
the
filesystem
type
it
used
to
be
hard-coded
to
ext4.
Now
that's
customizable,
and
we
also
added
in
a
new
call
in
to
CSI
that's
called
known
stage
volume.
B
B
What's
next
we're
going
to
try
and
target
GA
for
CSI,
not
this
coming
quarter,
but
the
quarter
after
that
in
the
v12
release
1.12
before
we
get
to
GA
stable
some
of
the
features
that
we
want
to
tick
off.
Our
block
volume
support
currently
CSI
only
supports
file.
We
also
want
to
add
in
support
for
a
generic
mechanism
to
be
able
to
specify
availability
topology.
So
this
is
things
like
zones.
B
B
We
also
want
to
integrate
with
the
cubelet
device
plug-in
mechanism.
This
is
something
that
the
GPU
team
has
been
working
on
for
a
while.
We
want
to
have
a
standard
way
by
which
plugins
are
added
to
the
cubelet
and
registered
with
the
cubelet
instead
of
having
a
different
mechanism
for
every
different
type
of
volume
or
every
different
type
of
plug-in,
whether
it's
GPU
device,
CSI
and
potentially
even
networking.
B
So
we're
looking
to
achieve
that
consistency.
We're
also
starting
the
work
on
introducing
snapshotting
into
the
CSI
interface
and
then
bubbling
that
up
into
kubernetes
and
a
call
to
action
if
you're,
a
storage
vendor
you're
interested
in
having
your
storage
system
exposed
in
kubernetes
now's
the
time
to
start
developing
CSI
drivers
reach
out
to
us.
If
you
need
help
we're
happy
to
help
you
and
please
provide
feedback.
B
We
want
to
make
sure
that
this
thing
is
actually
useful
for
four
storage
vendors.
We
have
a
handful
of
drivers
that
we've
been
testing
but
we'd
like
more
and
all
of
this
material
that
I
just
went
over
is
going
to
come
out
in
a
blog
post
on
kubernetes
I/o
today.
So
keep
an
eye
out
for
that,
and
with
that
I'm
gonna
hand
it
over
to
Michelle
to
discuss
local
persistent
volumes.
C
Thanks
Todd,
all
right,
so
I'm
gonna
talk
about
the
local
persistent
volumes
feature
which
is
now
in
beta
in
110.
So
to
give
a
brief
overview
of
what
the
feature
is.
This
basically
allows
you
to
specify
a
local
disc
as
a
persistent
volume
using
the
existing
persistent
volume
interfaces
that
we
have
today.
C
C
Alongside
with
this
feature,
we
made
a
number
of
scheduler
enhancements
so
that
the
scheduling
of
local
discs
is
smarter.
There's
two
main
benefits
of
this.
First.
If
you
have
a
pod
that
uses
a
local
disc,
it's
going
to
always
get
scheduled
to
the
node,
where
that
local
disc
resides
that's
what
we
call
data
gravity
that
way.
If
the
pod
has
to
restart
and
be
rescheduled,
it
will
always
land
on
the
node
where
data
is.
The
second
aspect
of
this
is
that
we
make
the
initial
persistent
volume
claim
binding,
smarter.
C
So
previously,
how
persistent
volume
binding
works
is
that
you
would
create
the
persistent
volume
claim
and
then
we
would
randomly
pick
a
suitable,
persistent
volume
for
it.
So
what
could
happen
with
local
volumes?
Is
we
could
end
up
picking
a
local
volume
on
a
node
that
doesn't
have
enough
resources
to
actually
run
the
pod?
C
So,
as
part
of
this
feature,
we
added
enhancements
into
the
scheduler
to
be
able
to
postpone
that
initial
PDC
binding
so
that
the
scheduler
can
look
at
all
of
the
pods
other
scheduling
constraints
such
as
the
resource
requirements,
any
affinity
or
anti
affinity
policies.
Any
you
know
taints
on
nodes
and
then
also
consider
the
PBC
requirements
at
the
same
time,
so
that
we
can
actually
bind
the
volume
the
pods
volumes
to
a
node
that
can
actually
run
the
workload
so
before
I
proceed.
C
I
first
want
to
point
out:
there
are
a
number
of
caveats
with
using
local
storage
or
local
persistent
storage.
First,
is
the
data
gravity
part,
so
your
pod
will
always
get
scheduled
to
the
node
where
that
local
disk
is,
but
that
also
means
if
the
node
has
a
problem
or
the
disk
has
a
problem,
then
your
pod
is
also
stuck.
C
In
addition,
many
local
disk
products
in
many
cloud
providers
have
lower
durability,
guarantees
I
think
for
most
of
the
major
cloud
providers.
The
local
discs
will
basically
you'll
lose
all
the
data
in
the
local
discs
if
the
node
gets
some
sort
of
error.
So
for
all
of
those
reasons,
local
persistent
volumes
is
not
suitable
for
most
workloads.
I
think
most
workloads
should
stick
to
the
distributed
and
high
highly
available
storage
solutions
out
there.
Today,
however,
there
are
a
few
workloads
that
are
still
suitable
to
use.
C
Local
disks,
those
workloads
have
to
be
able
to
tolerate
node
and
data
unavailability
and
potentially
data
loss
as
well.
Some
examples
of
such
workloads
are
workloads
that
want
to
cache
some
states
SSDs
for
improved
performance
and
in
those
kind
of
workloads
there,
potentially
caching,
so
much
data
that
it
can't
the
in-memory
so
they'll
have
to
ssds.
Instead,
they
want
the
dated
gravity
in
order
to
avoid
having
to
refresh
reload
the
entire
cache
from
scratch
whenever
a
pod
has
to
be
start.
C
The
second
major
use
case
is
for
distributed
storage
systems
that
will
shard
and
replicate
data
across
multiple
nodes.
That
way
they
can
all
they
can
tolerate.
Having
a
node
go
down
and
potentially
recover
from
that
examples
of
some
distributed,
storage
systems
would
be
like
my
school
or
Postgres
cluster
cassandra
and
so
on.
There's
a
there's
quite
a
few
that
can
fit
in
this
bucket
all
right.
So
how
do
you
actually
use
this
feature?
There
are
three
easy
steps.
C
The
first
two
steps
are
done
by
the
cluster
administrator.
First,
the
cluster
administrator
has
to
create
a
storage
class
for
the
local
disks.
Then
the
cluster
administrator
has
to
create
the
local
persistent
volumes
that
are
available
in
the
cluster.
Once
all
that
setup
is
done,
then
the
user
can
go
ahead
and
now
create
stateful
sets
with
their
persistent
volume
claim
templates,
and
then
they
will
start
binding
to
the
local
PDS
that
were
created.
C
The
full
and
complete
documentation
is
available
on
the
kubernetes
website,
but
I'll
go
over
a
brief
example
now,
so
the
first
step
create
a
storage
class.
This
is
needed.
This
is
needed
so
that
we
can
enable
the
smarter
scheduler
feature
that
I
was
talking
about
earlier.
Basically,
by
default,
persistent
volume
claim
binding
occurs
immediately
once
you
treat
the
persistent
volume
claim,
but
we
actually
want
to
delay
that
initial
binding
until
a
pod
is
actually
created
that
uses
it
and
can
go
through
the
scheduler
so
to
enable
that
option
to
enable
that
mode.
C
You
have
to
add
this
new
volume,
binding
mode
filled
in
to
the
storage
quests
that
you
are
using
for
your
local
storage
and
one
important
note
to
take
into
account.
Normally,
storage
classes
have
been
associated
with
dynamic
provisioning
in
this
initial
beta
offering
of
the
local
persistent
volumes
feature.
We
don't
support
dynamic
provisioning,
yet
you
still
have
to
manually.
C
You
still
have
to
create
the
persistent
volumes
ahead
of
time,
but
we
still
need
to
define
this
storage
class
in
order
to
in
order
to
trigger
this
new
scheduler
mode,
all
right
so
now,
the
next
step,
which
is
to
create
the
local
volumes,
there's
two
ways
you
can
do
this.
You
can
either
do
this
manually,
one
at
a
time
by
hand,
and
there
is
a
more
automated
way
that
also
described
next,
but
first
I'm
gonna
go
over
the
manual
way
to
create
the
vocal
PBS
so
you'll
see
here.
This
is
my
example.
C
Persistent
volume,
spec
and
I've
highlighted
the
two
new
major
fields
that
need
to
be
sets.
First,
is
the
first
field,
is
the
local
volume
specification
and
it's
pretty
simple
right
now?
The
only
field
is
a
path,
and
this
is
the
path
to
the
global
mount
point
of
this
volume
on
the
local
node,
like
I
mentioned
before
this
disk
has
to
be
pre,
formatted
and
mounted
globally.
On
the
node
beforehand,
and
also
the
for
this
manual
creation
process,
we
only
support
the
retain.
C
We
reclaimed
policy
for
now,
which
means
that
when
your
application
is
done
with
the
volume
someone
needs
to
go
in
and
clean
up
the
local
disk
and
then
recreate
the
persistent
volume
for
it.
The
second
new
field
that
is
available
now
in
the
persistent
volume
object,
is
node
affinity,
so
this
is
very
similar
to
node
affinity
in
pot
objects.
Today,
the
only
difference
is
now
we're
applying
it
to
a
persistent
volume.
So
what
a
node
affinity
on
a
persistent
volume
does
is
it
restricts
the
nodes
that
this
persistent
volume
can
be
accessed
from.
C
So
in
the
case
of
local
volumes,
we
want
to
restrict
this
persistent
volume
to
only
be
accessible
from
a
single
node,
so
we
do
this
by
specifying
the
kubernetes
host
name
label
key,
and
the
value
of
that
key
will
in
this
example,
is
my
node.
So
my
note
in
this
example
is
called
my
node,
but
you
would,
you
know,
put
in
whatever
the
actual
node
name
of
your
in
your
cluster,
so
this
is
also
so
we're
using
this
right.
Now.
C
Initially
for
local
volumes,
but
there's
no
definitive
anded
in
the
future
and
is
flexible
enough
in
the
future
to
support
any
other
volume
types.
So
if
you
have
storage,
if
you
have
a
volume
type
that
is
restricted
to
specific
zones,
you
can
also
use
node
affinity
to
specify
that
if
you
want
to
restrict
your
storage
to
specific
racks,
you
can
also
use
this
as
well.
C
All
right
so,
like
I
mentioned
one
downside
here
of
manually,
creating
the
local
volume
is
that
you
need
to
manually
clean
it
up
and
recreate
it
when
the
application
is
done
with
it.
It's
kind
of
a
pain
so
to
improve
on
that.
We've
implemented
this
local
volume
manager
that
you
can
run
as
a
daemon
set
in
your
cluster.
That
will
manage
a
lot
of
this
PD
lifecycle
for
you.
C
So
that
is
the
so.
That's
covers
the
second
step
of
how
you
can
create
local
persistent
volumes,
either
manually
or
automatically,
and
the
third
last
step
is
to
actually
use
them
in
your
workloads.
So
luckily,
here
for
this
step,
the
process
is
exactly
the
same
as
it
is
today.
You
use
the
existing
volume,
claim
templates
that's
available
in
staple
sets.
You
use
the
same
request,
storage
capacity
and
you
request
specific
access
modes.
The
only
difference
here
is
now.
C
You
need
to
specify
the
storage
class
name
for
the
local
storage
that
you
created
or
that
the
administrator
created
earlier
and
after
this,
the
applet
the
whole
workflow
is
exactly
the
same.
You
could
even
easily
do
things
like
switch
between
using
local
storage
and
switch
between
remote
storage.
Just
by
changing
the
storage
class
field,.
C
So
the
basics
of
how
to
actually
use
the
feature-
and
you
know
we're
still-
there's
still
lots
of
other
work
that
still
needs
to
be
done
before
we
can
go
GA.
Some
of
the
items
that
we're
currently
focusing
on
now
are
to
improve
the
local
raw
block
volume
support
it's
available
right
now
in
alpha
and
110,
but
we'll
have
to
push
push
that
to
beta
as
well.
The
second
major
feature
that
we're
working
on
is
supporting
dynamic
provisioning
using
LVM.
C
This
is
also
still
going
to
require
more
scheduler
changes
and
also
more
provision
or
changes
on
the
local
storage
front.
So
that
is
an
active
development,
and
the
third
step,
like
I
mentioned,
is
to
try
to
automate
more
of
this
node
setup
work.
So
I
previously
mentioned
that
there
you
still
need
to
manually
format
and
mount
these
local
disks
during
the
initial
node
setup.
So
we're
also
looking
at
ways
that
we
can
try
to
automate
that
a
little
bit
more.
So
you
don't
so
we
remove
those
manual
steps.
C
So
if
any
of
this
sounds
interesting
to
you,
please
try
out
the
feature,
give
us
feedback
and,
if
you're
interested
in
developing
helping
to
develop
any
of
these
future
items.
Also,
please
reach
out
to
me
and
reach
out
to
the
sig.
We
can
try
to
work
in.
We
can
try
to
work
in
some
tasks
there,
alright
so
and
in
general,
yeah
and
in
general,
if
you're
interested
in
any
of
the
either
CSI
or
local
persistent
volumes
or
any
other
features
related
to
storage.
Please
reach
out
to
us.
At
six
storage
we
hold
our.
C
We
hold
meetings
every
two
weeks
on
Thursdays
at
9:00
a.m.
all
the
details,
the
meetings
and
zoom
links.
Are
there
we're
also
going
to
have
a
pretty
big
presence
at
UConn
EU,
there's
a
number
of
presentations
that
various
members
of
the
storage
sig
are
going
to
be
giving
including
some
basic
storage
storage,
101
intros,
there's
going
to
be
a
more
detailed
session
on
local
storage
and
how
it's
actually
used
in
a
production
environment.
C
A
C
So
the
way
that
resizing
works
is
that
you
update
your
system
volume
claim
with
the
desired
size
that
you
want
to
increase
to,
and
then
the
kubernetes
system
is
going
to
go
and
increase
the
size
of
the
underlying
block
volume.
But
then,
in
order
to
do
the
file
system
resize,
you
need
to
restart
your
pod
first
and
that
way
we
can
safely
unmount
the
file
system
from
the
container
and
then
trigger
the
file
system.
Resize.
In
that
case,.
A
C
B
A
Perfect,
so
the
next
question
is
probably
to
to
meet
Caitlyn
is
how
can
we
get
the
slides
and
video
streams,
so
this
session
is
being
recorded
and
will
be
available
in
the
next
few
days
at
CN,
CF
2
at
our
website.
So
the
next
question
is
back
to
sudden
Michelle
is
about
when
a
node
is
using
a
local
storage
and
I
changed
it
Ames
finishes
Oh
disprin,
deported
or
scheduled
on
to
denote
their
local
persistent
search
was
yeah.
C
So,
in
that
scenario
you
can
potentially
have
this
is
this
is
one
of
the
downsides
of
using
local
storage.
So
if
say,
you
have
a
workload
using
local
storage
and
it's
scheduled
on
node
a
and
then
you
add
a
taint
to
node
a
that
causes
the
pod
to
be
evicted
from
it.
Your
pod
cannot
be
scheduled
after
that,
because
it's
bound
to
a
volume
that
only
exists
on
that
node.
C
A
A
C
I
guess
it
should
be,
it
should
be
possible
to
if
you
put
in
annotations
or
anything
into
the
PVC
or
PV.
You
can
pass
data
from
past
data
from
that
to
the
plug-in
right.
Now,
though,
the
plug-in
does
not
understand
those
annotations,
so
you
would
have
to
potentially
enhance
the
plug-in
to
support
it.
A
C
So
each
each
PVC
can
only
bind
to
one
PV.
So
if
you
want
to
break
up
one
large
disk
right
now,
you
have
to
manually
partition
the
disk
into
smaller
partitions
and
create
a
persistent
volume
for
each
of
these
smaller
partitions
right
now.
We're
working
on
a
design
to
support
dynamic
provisioning
using
LVM
I
think
that
will
support
they'll
be
able
to
support
this
use
case
better
of
carving
up
large
disks.
A
Perfect,
so
the
next
question
is:
will
this
changes
work
on
cubular
on
timber,
Matic
engine
unknown
to
Daenerys?
I
can
answer
these
questions.
D
is
dysfunctionality.
All
this
functionality
that
has
been
described
in
today's
webinar
is
related
to
today
what
Neela
kubernetes
this
time,
if
they're
abusin
of
communities
decades
and
is
conferment
enough,
fishel
certified.
So
all
different,
you
know
from
the
vanilla
cabinets
from
the
upstream
divinities
can
be
also
used
on
that
specific
commercial
and
non-commercial
distribution.
A
We
have
yet
another
question
about
the
features,
so
that's
the
question
that
I
can
answer.
So
where
can
we
find
information
on
some
other
features?
The
25
other
features
in
this
release,
so
the
brief
information
about
them
even
find
on
blog
kubernetes,
the
dáil
websites,
that
in
terminators
blog
where
we
are
posting
the
latest
news
from
communities
community,
including
the
release
announcement.
So
please
check
the
latest
announcements
from
the
previous
week
where
we
had
kinetics
1
to
10
release
announcement
and
the
detailed
information,
the
raw
data
about
the
features
where
the
kubernetes
community
itself
strengths.