►
From YouTube: Webinar: What's New in Kubernetes 1.8
Description
In the third release of 2017, Kubernetes 1.8 represents a snapshot of many exciting enhancements and refinements underway. In addition to functional improvements, this release focuses on maturing process, formalizing architecture, and strengthening Kubernetes’ governance model.
In this webinar, members of the Kubernetes 1.8 release team will cover some of the major features in this release.
We will give a broad overview of all the features in the release and demo some of the highlights in the areas of storage, workloads and extensibility.
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
All
right,
the
number
of
attendees
seems
to
be
stabilizing
so
get
started.
Welcome
everybody.
My
name
is
Mark
Coleman
and
I'm.
The
marketing
chairperson
for
the
CNC
F
I'm,
also
joined
today
by
Caitlin
Bernard
from
the
CN
CF
who's
helping
out
in
today's
webinar,
we're
very
fortunate
to
have
a
partner
and
Anthony
from
Google
and
Brad
from
Red.
Hat
will
be
telling
us
all
about.
A
What's
new
in
Cuban
eighties
1.8,
today,
I'm
sure
they'll
introduce
themselves
fully
as
we
get
into
the
presentation
before
we
get
started,
I'd
like
to
encourage
you
to
not
leave
questions
until
the
end.
We're
gonna
try
and
make
it
interactive
as
we
go
through,
but
you'll
notice
that
you're
all
muted-
and
you
can't
do
anything
about
that.
So
please
drop
your
questions
into
the
chat
window
and
I
will
find
opportune
moments
to
interrupt
the
speakers
to
ask
for
those
questions
as
we
go
through.
B
There,
Bradley
childs
from
our
Red
Hat,
will
take
over
from
there
and
talk
about
the
storage,
sig
and
the
storage
features
in
1.8,
and
he
will
also
hopefully
run
through
a
demo
of
some
of
the
some
of
the
new
alpha
features
in
storage.
So
that's
essentially
our
agenda.
We
can
go
to
the
next
slide.
I'll
provide
a
features
overview
of
the
1.8
release.
B
The
1.8
release
of
kubernetes
really
represents
a
snapshot
of
many
exciting
enhancements
and
refinements
that
are
underway
in
the
project
across
the
different
special
interest
groups
and
technologies.
The
key
areas
of
progress
that
users
should
look
for
in
this
release
include
maturing
of
security
features,
in
particular
rural
based
access
controls
or
are
back
in
also
network
policy,
and
those
are
two
core
features
and
I'll
talk
a
little
bit
more
about
them.
Also,
there
have
been
changes
to
move
the
apps
and
badge
workload.
Objects
towards
maturity
and
Anthony
will
cover
that
in
more
detail.
B
In
conjunction
with
that,
we've
made
a
huge
progress
if
you're
running
big
data
workloads
on
kubernetes,
particularly
in
the
area
of
spark
support.
And
so
one
of
the
highlights
in
this
release
is
that
the
spark
solution
for
kubernetes
has
been
approved
for
upstream
inclusion
into
the
spark
repository
and
that's
a
major
advancement
that
validates
that
spark
can
run
successfully
on
kubernetes.
So
we
won't
go
into
details
on
that
one
here,
but
we
do
have
links
in
the
blog
post
to
users
who
want
to
run
spark
on
kubernetes
and
then
notable.
B
There
are
a
number
of
notable
experimental
features.
So
while
security
has
matured,
some
of
the
are
back
and
network
policy
features
and
the
apps
and
badge
workloads
are
on
their
way
to
maturing.
There
are
a
number
of
alpha
features
or
what
we
call
experimental
features
which
we
encourage
users
to
start
trying
out.
However,
they're
not
ready
for
production
yet,
but
there
are
some
exciting
ones
in
scheduling
and
in
storage
and
we'll
talk
more
about
them
and
hopefully
Bradley
will
give
us
a
demo
of
one
of
the
storage
ones.
B
And
lastly,
it's
important
to
note
that
there
isn't
deprecation
in
this
release,
which
is
third-party
resources
or
T
PRS.
They
were
deprecated
actually
in
the
1.7
release,
but
as
you
upgrade
to
1.8,
you
will
no
longer
be
able
to
use
the
old
CPR
definitions
and
custom
resource
definitions
or
C
RDS
have
really
matured
and
they
address
a
number
of
the
outstanding
issues
with
TPR,
so
they're,
a
much
better
mechanism
for
extending
kubernetes
and
we'll
give
a
demo
of
that
Anthony
Anthony
section,
that's
a
feature
so
review.
B
Let
me
go
through
some
of
the
features
in
brief
before
handing
it
off
to
Anthony,
so
real
role
based
access
control
has
moved
to
stable
in
this
release.
Our
back
is
essentially
a
mechanism
for
controlling
access
to
the
kubernetes
api
and
it
went
beta
in
1.6
and
since
then
many
kubernetes
clusters
and
provisioning
tools
and
strategies
have
enabled
our
back
by
default.
Some
of
our
advanced
users,
of
course,
we're
already
using
our
back
by
default,
because
it's
such
a
critical
piece
of
ensuring
security
and
authentication
within
a
kubernetes
cluster.
B
B
Network
policy
network
policy
has
moved
to
beta.
Network
policy
is
also
a
security
feature,
and
it
is
essentially
a
feature
for
enabling
multi-tenancy
within
your
cluster.
It's
a
building
block
for
enabling
multi-tenancy
through
network
policy.
You
can
specify
which
groups
of
pods
are
allowed
to
communicate
with
each
other
and
to
other
network
endpoints,
so
essentially
segregating
the
network.
You
can.
You
can
allow
or
block
traffic
to
your
pod
through
a
network
policy
resource,
and
it
also
filters
outbound
traffic
through
the
policies.
B
So
this
is
important
for
enforcing
security
requirements
and
is
found
to
be
critical
in
many
of
the
enterprise
to
enterprise
deployments
of
kubernetes.
It's
implemented
through
a
network
plugin,
and
there
are
many
of
those
that
are
available.
So
Calico
is
a
company
that
provides
our
policy,
and
this
happens
to
be
what
we
use
on
Google
container
engine
in
Google's
cloud,
but
also
we've
and
romana,
and
provide
Network
policy
plugins
and
in
this
particular
release
in
1.8.
A
network
policy
has
added
support
for
cider
and
egress
based
policies.
B
So
that's
a
that's
an
additional
and
we
hope
to
be
able
to
graduate
network
policy
to
stable
in
the
next
couple
of
releases
next
slide.
Please
great
another
feature
that
I'd
like
to
talk
about
a
little
bit
is
cube.
Abm
and
cube.
Atm
is
a
tool
that
was
introduced
last
year
to
simplify
installation
of
kubernetes
clusters.
It
is
certainly
not
the
only
tool
for
installing
kubernetes
clusters.
In
fact,
there
are
many
many
tools
for
doing
so.
B
However,
cube
ATM
does
aim
to
provide
a
set
of
primitives
that
can
be
used
by
other
tools,
and
so
in
that
sense,
it's
it
aims
to
provide
a
unifying
layer
for
cluster
install
the
primitives
that
cube
ATM
provides,
are
in
it
and
joints
of
cube
ATM
in
it,
and
cube
idiom
join
in
in
the
former
release.
1.6
and
1.7
cube
ATM
added
support
for
the
security
features,
namely
our
back
and
node
authorizers
node
authorizers
are
a
feature
that
allow
you
to
restrict
what
the
cubelet
has
access
to
and
in
this
release.
B
B
Both
the
control
plane
and
the
nodes
through
cube,
ATM
using
the
command
ATM
upgrade
apply,
and
then
you
basically
say
what
version
you'd
like
to
upgrade
to
and
some
of
the
nice
features
around
the
upgrade
process
are
you
can
run
cube,
idiom
upgrade
plan
to
see
which
versions
are
available
for
upgrade
and
you
can
do
you
can
use
the
dry
run
flag
for
a
non-intrusive
dry
run
off
the
of
the
upgrade?
That's
the
main
announcement
and
this
release
with
regard
to
cube
ATM.
B
There
are
a
couple
of
alpha
features:
a
self-hosting
as
an
alpha
feature,
I'm
not
going
to
go
into
that
in
too
much
detail.
Again,
it's
experimental
and
then
Cuba
idiom
joint
is
in
beta
as
before
you
thank
you.
I
mentioned
that
there
are
a
number
of
experimental
features
that
are
quite
exciting
and
weed,
while
experimental
futures
are
not
ready
for
production,
you
may
be
interested
in
trying
them
out.
B
So
on
the
scheduling
side,
priority
and
print
preemption
has
moved
to
alpha,
and
this
is
an
important
feature
for
essentially,
if
you
want
to
have
some
sort
of
level
of
assurance
with
regard
to
which
pods
should
always
be
scheduled
and
which
ones
should
take
priority
over
others.
So,
for
example,
priority
and
preemption
can
be
used
to
guarantee
scheduling
of
system
pods.
So,
for
example,
you
don't
want
the
cube
dns
to
run
on
memory
or
not
have
a
place
to
schedule,
and
so
this
is
an
important
feature.
B
So
that's
the
overview
you
with
that
I'm
going
to
hand
it
over
to
Anthony
and
Anthony
is
going
to
talk
more
about
if
you're
running
applications,
whether
there
are
batch
applications
or
other
types
of
applications
deployments
and
other
objects.
What
are
we
doing
to
graduate
those
capabilities
forward
in
kubernetes
and.
A
B
So
alpha
is
really
experimental.
It's
essentially
sort
of
the
first
installment
of
a
set
of
functionality
that
you
know
we
want
users
to
to
try
out
or
be
ourselves
as
a
community
want
to
try
out.
So,
for
example,
we'll
talk
about
snapshots
a
little
bit
later,
and
the
priority
and
preemption
feature
that
I
talked
about
in
scheduling.
That's
an
alpha
future.
It's
not
ready
for
production.
It
will
likely
change.
The
API
will
will
almost
definitely
change.
So
we
don't
recommend
that
folks
put
that
into
production.
B
In
fact,
on
on
container
engine
in
Google
Cloud,
we
don't
actually
offer
alpha
features
for
production
clusters.
Beta
is
a
lot
more
advanced
and
Anthony's
going
to
talk
about
some
of
the
beta
beta,
api's
and
workloads
and
I.
Think
those
examples
will
clarify
when
beta
is
and
then
stable
is
really,
for
example,
our
back
is
where
we
think
that
the
functionalities
complete
it's
not
going
to
change,
and
so
it
really
is
production-ready
excellent.
A
B
C
All
right
so
hello,
I'm
Anthony,
a
and
I
work
on
the
chrome,
Annie's
team
at
Google,
primarily
focused
on
workloads,
which
is
things
that
you
used
to
run
your
applications
and
then
also
on
extensibility.
So
I'll
give
a
little
overview
of
things
that
we
have
introduced
in
1.8
in
as
a
part
of
mentioned,
the
big
focus
this
year
has
been
on
maturing
things
to
get
to
GA
gener
of
their
body
or
that
what
we
call
v1
for
each
API.
The
first
thing
I
went
talk
about.
C
Is
this
app
script,
which
is
what
would
you
use
for
running
things
that
you
basically
want
to
be
running
all
the
time?
It
manages
your
pods
and
if
the
puzzles
go
down,
it
makes
new
ones
and
ensures
that
you
have
enough
to
serve
what
you
need.
I
wanted
to
talk
a
little
bit
about
how
we
do
versioning,
because
they
can
be
confusing.
C
This
right
here
is
a
color-coded
chart
of
all
the
different
ways
that
you
can
access
deployments
and
daemon
sets
and
requisites
in
just
1.8,
and
so
part
of
what
I
want
to
point
out
is
that
these
things
are
in
groups
called
API
group
versions.
So
if
you
look
at
the
first
box
and
that's
one
group,
extensions
of
you,
wanna
beta1,
which
is
the
oldest
group,
that
these
API
is
existed
in
and
what
we've
been
doing,
is
splitting
things
out
of
that
extensions
group
and
putting
them
into
more
specific
groups.
C
So
these
particular
controllers
were
moving
some
of
them
out
of
extensions
into
the
apps
group,
to
better
put
them
together
with
peers
that
have
a
consistent
API
and
be
able
to
move
those
along.
As
we
create
new
versions,
they
look
stay
consistent
with
each
other.
So
in
previous
versions,
we
introduced
apps
beyond
beta1,
now
we're
in
what
way
we've
introduced
apps
with
you,
1
beta
2,
which
is
the
second
beta
of
what
we
hope
will
become
v1.
C
That's
how
to
reread
that
and
then,
if
you
look
all
the
way
to
the
right,
this
is
just
saying
in
1.9.
We
expect
to
release
apps
b1,
which
will
be
basically
all
these
same
ap
ice,
but
in
like
a
practice
that
kind
of
the
final
version
of
the
very
stable
API.
That's
not
going
to
change
after
that
next
slide.
C
So
as
part
of
my
training
API,
one
of
the
big
focuses
for
us
has
been
making
things
stable,
preventing
preventing
errors
that
you
don't
have
to
happen.
If
you
have
a
better
user
experience.
One
of
them,
for
example,
is
on
all
of
these
workload.
Api
is
now.
If
you
use
b1
beta
to
the
selector
is
required.
It
used
to
be.
You
can
forget
about
the
selector.
Totally
I
will
fill
one
in
for
you
in
the
old
versions,
but.
C
Caused
more
problems
than
it
solves.
One
of
the
problems
was
copying
fields
from
one
place
to
another
place
during
this
defaulting
phase
caused
problem
with
keep
until
apply
and
another
problem
was.
This
was
encouraging
users
to
never
learn
about
selectors,
which
had
won.
They
would
be
missing
out
on
some
of
the
flexibility
that
selectors
gave
you
and
two
it
could
cause
confusion
that
would
actually
cause
users
to
get
unexpected
behavior.
C
So
there's
an
example
of
this
on
the
right,
and
previously
we
would,
if
you
don't
specify
the
selector
at
all,
we
would
just
copy
all
the
labels
from
your
plan
template
and
generate
a
selector
that
contains
all
of
those
labels,
but
actually,
in
many
cases
you
don't
want
to
have
all
the
labels
in
your
selector
that
you
have
on
the
part.
You
might
have
some
labels
on
the
pod.
That
will
change
and
you
want
those
parts
to
still
belong
to
this
deployment.
C
C
1.7,
well,
we
did
now
is
in.
If
you
use
the
view
and
beta-2
api,
then
these
rolling
updates
are
on
by
default
and
even
set
staple
set,
which
matches
the
behavior
that
you
already
had
for
deployment
where
you
would,
by
default,
to
a
rolling
update.
In
addition
for
stability,
we
introduced
default
revision.
History
limits
for
all
controllers
that
have
history,
and
what
this
means
is
that,
for
example,
with
deployment
originally,
if
you
keep
changing
the
template,
you
might
end
up
with
an
unbounded
number
of
replicas
sets
that
build
up
representing
your
old
history.
A
C
Seeing
architecture
kind
of
is
an
umbrella
that
ensures
consistency
across
SIG's,
and
so
what
we
would
do
is
we
make
our
proposals
within
CAS.
If
there
are
things
that
we
may
not
be
able
to
agree
on
with
other
SIG's
or
within
our
SIG's,
then
we
would
go
to
sig
architecture
and
say
what
is
the
overarching
philosophy
that
we
should
be
following.
C
All
right,
and
then
the
second
group
within
word,
those
that
I
want
to
talk
about,
is
the
batch
group.
So,
unlike
the
apps
group,
which
is
managing
things
that
you
want
to
run
all
the
time,
the
batch
group
is
the
more
about
things
that
you
want
to
run.
You
have
a
fixed
amount
of
work
and
you
just
want
to
run
a
pod
until
it
finishes
at
work
and
then
you're
done
so
job
will
run
one
instance
of
this
or
an
instances
right
now.
Cron
job
is
built
on
top
of
job.
C
You
will
run
create
jobs
for
you
at
the
schedule
that
you
specify
in
a
crowd
of
tab.
That's
the
text
and
again
we
have
this
concept
of
these
API
group
versions.
So
there's
three
versions
and
I
want
to
point
out
there's
a
little
bit
of
confusion
here,
because
the
batch
v2
alpha
1
is
actually
the
one
that's
deprecated
and
they
recommended
one
now
is
that
V
1
beta
1,
which
is
unexpected.
You
would
think
that
V
2
comes
after.
C
C
And
beta
one
is
how
you
get
to
the
latest
cron
job
and
now
that
it's
beta,
what
that
means
is
that
it's
available
by
default
in
humanities
clusters
that
are
started
startup
with
default
settings
and
then
just
to
go
over
a
couple
of
the
things
that
we've
changed
to
add
stability
to
these
features
in
job,
for
example.
In
what
money
we
added
a
feature
called
back-off
limit,
which
is
another
way
in
addition
to
active
deadline
seconds
I
was
already
there.
C
That
complement
is
a
new
way
to
specify
how
many
times
you
want
the
pod
to
reach
be
retried
before
you
give
up
on
it.
This
was
causing
problems
before
with,
for
example,
a
lot
of
terminated
failed,
pods,
building
up
in
your
system,
because
it
was
just
never
going
to
succeed
and
then
another
thing
playing
cron
job.
C
We
now
have
also
limits
on
the
history,
so
cron
job
goes
and
creates
jobs
similar
to
the
way
that
typically
creates
replica
sets,
and
it
used
to
be
that
by
default,
cron
job
would
just
keep
creating
jobs
and
those
jobs
would
stick
around
forever
and
now.
There's
a
default
limit
on
the
amount
of
old
jobs.
It
will
stick
around,
so
it
kind
of
manages
itself.
C
C
This
slide
is
more
about
the
context,
so
this
stuff
is
not
new
in
one
thing,
but
has
already
been
there
since
1.7,
but
when
I
want
to
talk
about
here
is
the
difference
between
adding
your
own
API
server,
which
you
can
see
on
the
right,
an
example
of
that
versus
using
custom
resource
definition.
So,
on
the
right
side,
what
you
have
is
a
custom
API
server
that
runs
to
all
of
the
same
type
of
code
that
our
cube
API
is
over.
C
The
main
API
server
is
running
so,
but
because
you
have
a
fork
of
that
code,
you
can
change
literally
anything
in
the
behavior
there
as
its
responding
to
requests
and
what
we
do
is
basically
just
a
reverse
proxy.
When
the
client
talks
to
our
API
server,
it
looks
like
the
URL
that
you've
asked
to
handle
will
just
forward
that
to
you.
Essentially
the
difference
with
custom.
Resource
definition
is,
as
you
see
inside
of
you
know,
there's
these
API
as
we
provide
inside
of
the
main
API
server
like
to
automate
cron
job
custom.
C
Resource
definition
is
sort
of
a
meta
API,
where
it's
an
API
that
lets
you
ask
the
API
server
to
host
another
API
for
you.
So
this
example
will
shows
head
city.
Cluster
is
installed
as
a
custom
resource
definition,
and
what
that
does
is
API
server
is
now
serving
in
on
your
behalf.
Now
that
makes
it
a
lot
easier.
You
just
kind
of
post
a
declarative
definition,
but
it
also
makes
it
a
lot
less
flexible
because
you
have
to
kind
of
squeeze
all
of
the
behavior
that
you
run
into
this
Jamo
and
say.
C
A
C
D
C
Crd
customers,
whose
definition
one
of
the
biggest
things
there's
a
novel
feature
called
json
schema
validation.
So,
as
I
mentioned
with
an
API
server,
if
you're
writing
the
whole
thing,
you
can
do
any
code.
You
want
for
validation.
What
we're
giving
you
in
CRD
is
a
way
to
specify,
as
you
see
on
the
top
right,
some
simple
things
like
making
sure
these
fields
are
present.
Make
sure
this
field
is
an
integer
with
a
valid
range
within
1
in
10,
or
something
make
sure
this
one
is
a
string
that
matches
a
regular
expression.
C
Have
to
enable
in
your
API
server
with
the
flag
called
feature
gates.
You
can
look
at
the
CRD
documentation
for
exactly
what
feature
gate
there
or
if
you
use
the
one
that
just
says,
enable
all
alpha
features,
then
this
will
be
included
and
I'll
do
a
demo
of
that
in
a
second.
But
let
me
I
want
to
go
through
the
other
new
things.
One
of
the
other
ones
is
garbage
collection.
C
So
if
you
look
at
the
bottom
right,
what
we
have
is
an
example
of
a
deployment
which
goes
and
creates
two
replicas
sets,
and
each
replica
set
then
goes
and
creates
odds
and
what
we've
done
in
the
past
forward.
These
sort
of
core
controllers,
like
deployment
is
keep
control,
has
to
have
custom
logic
to
say
when
you
delete
the
deployment,
unless
you
asked
for
cascade
equals
false.
If
you
delete
the
deployment
it
will
go
and
clean
up.
C
The
replica
sets
for
you,
which
means
cute
control,
has
to
have
custom
code
that
understands
how
to
find
the
replicas
sets
of
a
deployment
and
then
how
to
tell
the
replicas
said
to
clean
up
its
pods
and
then
go
back
and
delete
the
core
deployment.
Otherwise,
we
would
leave
behind
all
of
those
child
objects,
and
this
approach
wasn't
going
to
work
for
things
like
custom
resources,
because
we
can't
go
and
build
it
in
support
in
queue
control
for
every
different
type
of
resource.
So
it
knows
how
to
reach
in
in
cleaning
up
the
children.
C
So,
instead,
what
we
have
is
we
introduced
in
the
earlier
versions,
server-side
cascading
delete,
which
is
the
ability
to
have
the
server,
take
care
of
this
stuff
for
you,
because
the
server
understands
the
relationships
between
objects,
where
we
declare,
for
example,
that
this
replica
set
is
owned
by
that
deployment,
and
then
the
server
will
realize.
Oh
if
the
deployment
that
owns
it
is
gone,
I'll
go
and
clean
up
the
things
that
are
no
longer
needed
in
the
past,
though
this
didn't
work
for
custom
resources.
C
So,
what's
new
in
1.8
is
that
now
this
works
for
custom
resources,
which
means
instead
of
a
deployment.
If
you
have
a
custom
controller
there,
this
cleanup
will
work
and
I'll
show
you
that,
as
an
example
in
the
demo
and
then
the
last
thing
I
want
to
reiterate
is
third-party
reserves,
which
was
the
kind
of
the
alpha
version
before
customers
source
definition.
Third-Party
resource
is
not
deprecated,
it's
totally
gone,
and
what
will
happen
is
if
you,
if
you
don't
migrate
before
upgrading
to
1.8,
then
those
third-party
resources
will
just
disappear.
So.
C
C
D
C
C
And
then
I'm
going
to
try
to
create
an
instance
of
that
CID,
okay
and
then
other
than
this
big
JSON,
which
is
just
spitting
back
out.
The
object
I
tried
to
put
in
at
the
bottom
here
you
have
a
list
of
errors
and
the
nice
thing
about
this
validation.
Now
is
previously.
Your
controller
would
have
to
detect.
C
Oh
there's,
the
user
specified
something
invalid
and
it
will
have
to
asynchronously
report
that
back
and
the
user
has
to
go
in
and
look
at,
say
the
events
on
the
object,
this
validation
for
simple
things
that
are,
you
know
this
field
is
missing.
That
field
should
be
an
integer.
You
can
immediately
give
a
feedback
to
the
user
and
say,
go
and
fix
that
and
then
resubmit
it.
So
what
we're
seeing
here
is,
let's
see,
matched
labels
in
bonny
is
required.
Service.
C
Host
name,
so,
let's
see
if
we
can
fix
those
match
labels,
so
it
turns
out
what
I
do
here
is
I
put
in
the
old
form
of
selector.
What
I
actually
need
to
do
is
put
in
the
new
form
and
without
this
kind
of
validation
you
might
actually
the
controller
might
mistake
your
selector
for
being
the
wrong
type
and
just
kind
of
start
silently
doing
the
wrong
things
over.
This
validation
is
really
nice
protection.
C
C
C
Delete
this
new
controller,
if
this
was
in
1.7,
what
would
happen
is
my
controller
object
would
disappear,
but
all
those
clouds
would
be
left
behind,
and
so
hopefully,
what
happens
now
is
after
I
delete
that
the
pods
should
start
terminating,
and
that
was
because
of
the
this
server-side
garbage
collection.
I
didn't
have
to
write
anything
in
my
controller.
They
would
do
this
for
me.
C
A
Yes,
there's
another
question:
coming
from
the
like
site:
it's
a
long
one
somewhere.
To
paraphrase
a
little
bit.
He
asks
about
the
recent
dr.
Conte
EU
announcement
of
humanity's
being
included
as
an
orchestration
management
option.
He
said:
will
there
be
different
requirements
for
creating
a
cluster?
Will
it
be
either
a
that
you
will
still
need
to
have
at
least
n
n
CD
nodes,
n
masters
and
modes
etc?
Or
is
there
going
to
be
some
new
way
to
accommodate,
say
two
or
three
node
clusters
running
in
its
engine
style,
so.
B
I'm
not
sure
that
that
is
a
question
that
we
can
cover
in
this
webinar,
since
it's
not
related
to
kubernetes.
1.8,
certainly
I
believe
that
as
you
as
you
look
at
the
dock
or
kubernetes
capability,
custom
resource
definitions
will
be
something
that
they
may
be
using
and
so
you'll
be
able
to
see
what
custom
controllers
they
have
there
in
that
sense.
Maybe
is
related
to
this.
How
big
of
this
webinar
but
I
think
the
specific
question
will
have
to
take
it
to
a
different
audience.
Yeah.
B
Great
Thank,
You,
Anthony
and
I
think
hopefully
that
demo
was
useful.
It
shows
some
of
the
new
capabilities
in
CR
DS
and
then
just
overall
CR
DS
are
an
excellent
mechanism
and
they
do
replace
third-party
resources.
There
are
easier
mechanisms
and
cubic
aggregator,
so
we
hope
that
our
advanced
users
will
will
make
use
of
them,
and
so
at
this
point
we
should
switch
over
to
the
storage
features
overview
and
Brad
childs
from
Red
Hat
will
give
us
will
give
us
that
overview
as
well
as
present
a
short
demo.
Everyone.
D
Is
aparna
said
I'm
brad
child's,
I
co-lead
the
storage
special
interest
group
in
communities
with
side
who
were
happens
to
be
I
believe
in
Italy
on
co2
that
he
I
so
I'm
gonna
talk
real
quick
about
the
kubernetes
when
eight
features
for
stores
that
we
added
this
release.
I'm
gonna
go
over
like
the
same
old
features,
the
some
of
the
helpful
function
that
we
that
we
added
and
then
from
the
designs
that
we
worked
on
as
well.
C
D
A
lot
of
features
introduced
in
one
seven
that
we
wanted
to
make
sure
were
production
hard
and
that
we
had
all
the
bugs
and
kinks
worked
out
of
I.
So
we
spent
a
lot
of
time
focusing
on
making
sure
that
the
features
we
hadn't
won.
Seven
were
correct,
and
then
you
know
moving
this
week
that
function
to
GA
one
of
those
functions.
Mount
options
was
something
pretty
well-received.
It
allows
a
on
premise:
storage,
admin
to
specify
volume,
specific
properties.
So
one
example
of
this
is
NFS.
D
They
typically
have
you
know
when
you
have
on
premise
storage.
That's
really
have
multiple
in
offense
server
instances
that
each
one
has
special
brands
that
are
customized
through
mount
parameters
I.
So
this
was
really
well
received
when
we
did
all
of
us.
We
move
this
to
GA
in
the
one
8
release.
Our
flex
line
was
something
else
that's
been
well
received.
We
had
a
knock
date
and
when
seven,
where
we,
the
drivers
would
be
pushed
out
to
running
notes,
so
prior
you'd
have
to
restart
cubelet
bring
it
down,
then
bring
it
back
up.
D
So
your
flex
logins
to
work.
We
enhance
the
function.
So
you
don't
actually
have
to
restart
Keyblade
model.
We've
also
added
some
volume
metrics
to
assist
in
debugging
and
performance
evaluation.
So
this
is
numbers
around
the
attach
detach
time
and
other
technical
things
related
storage,
and
we
had
this
so
we
could
start.
You
know
providing
better
benchmark
and
better
testing
for
some
the
individual
storage
components.
Then
we
also
added
our
retention
policy
to
our
already
stable
storage
class
feature.
D
Of
this
again
is
on
prim.
We
had
things
like
ice
fuzzy.
That
would
error,
because
error
that
was
attached
to
multiple
notes.
We've
beefed
up
the
the
check
for
this
and
some
of
the
support
for
only
allowing
I
scuzzy
to
be
attached
to
a
single
note
at
a
time.
So
this
was
kind
of
a
bug
that
people
then
stepping
on
fixing
this
release.
Then.
D
Bug
fixes
and
some
feature
enhancements
around
local
storage,
again,
local
sorts,
another
on
friend
data,
intense
workload
each
and
we
had
on
one
seven.
We
really
look
went
back
to
make
sure
that
we're
good
right
and
artists
with
the
features
and
point
eight
next
slide,
please,
okay,
so
our
alpha
features
we
had
snapshots
and
volume
recites.
This
is
something
that
we've
been
incubating
and
the
external
storage
repo
and
it's
outside
of
the
Canadians
to
treat.
A
D
The
db2
that
that
snapshot,
level
or
great
another
key
be
off
in
that
snapshot
and
I
will
show
it
demoing
that
in
a
second
as
well
and
then
finally,
another
feature
that
we're
incubating
is
volume
resize.
This
allows
a
user
to
expand
resizes
a
little
bit
of
a
trickier,
because
you
can't
shrink
the
volume
we've
taken
on
support
for
that.
You
can
only
grow
the
volume,
so
we
allow
users
to
grow
their
persistent
volumes
in
size,
and
this
is
a
big
feature
because
they
didn't.
D
File
system
size
read
resize
support.
We
only
have
cloud
provider
resizes
the
current
time,
but
we're
continuing
to
incubate
that,
and
you
know,
looking
at
any
feedback
we
get
from
the
community
for
an
extra
function.
Okay,
so
a
lot
of
the
work
that
we
did
for
1/8
was
design
level
work.
Probably
one
of
the
bigger
things
is
the
container
storage
interface,
which
is
a
container
orchestration
agnostic
driver
layer
for
storage.
It's
meant
to
cross
who
Nettie's
mezzos.
You
know
multiple
cloud
providers
with
the
same
storage
driver,
and
this
has
been
a
frost
cloud
initiative.
D
We've
had
and
we've
really
developed
the
spec
for
this
as
part
of
the
C
and
C
F
and
then
as
part
of
communities.
We've
started
prototyping
the
actual
proof
of
concept,
work
and
support
for
this
and
1/8.
So
design
and
development
are
designed
for
CSI
in
kubernetes
started
when
8,
we
should
have
an
elephant
feature
for
that.
One
9
blocks
towards
another
thing
that
we
had
a
lot
of
community
feedback
on
a
lot
of
interest
from
storage
vendors.
They
wanted
raw
block
storage.
C
D
Right
now
we
have
file
storage,
Cooper,
Nettie's,
so
we've
we
spent
pretty
much
an
entire
release.
Talking
about
the
ins
and
outs
and
all
the
different
issues
around
that,
then
we
had
a
containerized
mount,
which
is
another
feature
that
allows
us
to
enhance
our
enzyme
testing
and
some
of
our
platform,
support
of
storage
and
kubernetes.
It's
not
something
user
will
see
much,
but
it's
it's
something
there
to
really
help
us
test
and
continuously
test
our
storage
plugins.
To
make
sure
we
don't
have
any
regressions.
D
A
D
D
D
D
D
So
here's
the
double
snapshot
object
and
if
you
look
at
the
message
we've
it's
created
successfully.
This
is
coming
from
the
back
end
and
the
controller
that's
watching
for
these
objects,
and
now
we
can
take
the
snapshot
and
either
provision
another
PB
from
it
or
potentially
go
back
the
other
PB,
but
the
distant
will
provision
another
PB
from
it
and
create
a
second
deployment
to
use
that
PB
n.
D
D
D
D
So
punster
running,
even
when
you
have
video
that
takes
a
while
to
do
stuff
and
knows
that
video
could
fall
right.
I've
had
words
happen,
alright,
so
here's
I.
So
this
is
done
and
we're
going
to
go
into
our
second
staple
site
and
validate
that
the
the
database
table
has
been
replicated
with
the
data.
So
let's
start
our
table
and
then
we'll
select
that
value
that
we
created
on
the
old
table
and
show
that
it's
been
copied
over.
D
D
D
A
A
A
B
A
C
Ceo
any
question
was,
you
know:
what's
a
good
use
case
example
for
CRD
and
specifically,
does
it
make
sense
to
sort
of
replace
some
things
that
you
might
do
otherwise,
with
init
containers
like
setting
up
MongoDB
replica
sets
or
reddit
clusters?
My
answer
to
that
would
be
Enid
containers
if
are
good
for
getting
things
initially
connected
together.
C
The
question
was:
why
would
you
want
to
run
my
cycle
and
kubernetes?
Basically
what
stateful
said
or
whatever,
instead
of
just
running
it
in
individual
or
on
bare
metal?
And
my
sure
that
is
the
benefit
comes
when
you
use
make
use
of
all
the
automation
features
that
occur
in
a
nice
provides
in
order.
C
To
sum,
one
of
the
problems
that
they
mentioned
in
this
question
is,
let's
say,
there's
known
failures,
and
then
you
try
to
bring
things
back
up
and
you
have
problems
with
making
things
rejoin
together,
and
so
this
is
the
place
where
kubernetes
can
provide
a
lot
of
places
for
you
to
insert
your
logic
and
glue
to
make
all
that
stuff
happen
automatically.
So
actually
there
should
be
nothing
for
you
to
do
when
this
occurs.
It
should
kind
of
self
heal
itself.
Now.
C
Probably
what
I'd
like
to
point
out
is
there's
an
example
of
the
end
state
of
like
what
happens
after
you
go
through
this
process
of
automating
everything
possible,
distributed.
Failure
in
my
sequel,
it's
a
project
that
I
worked
on
before
called
the
test,
vit
PSS
and
we
actually
put
some
work
into
making
that
run
on
kubernetes
very
analogously
to
the
way
either
we
run
it
in
Google
at
YouTube.
So
take
a
look
at
that
if
you're
interested
in
my
sequel
and
you're
using
kubernetes,
it's
it
does
a
lot
of
this
automation
stuff
for
you.
B
There's
a
question
on
the
features
in
how
many
are
alpha
beta
and
stable
I
can
take
that
one.
You
know
that
it's
it's
a
little
bit
arbitrary.
What
a
feature
is
so
many
small
changes
tend
to
be
features.
Therefore,
we
don't
always
pay
that
much
heed
to
the
number
of
features,
but
if
you're
interested
there's
about
40
features
in
this
release,
total
four
of
which
are
stable,
so
the
stable
features
we
talked
about
are
back
that
has
moved
to
stable.
B
We
talked
about
support
for
volume
options,
that's
moved
to
stable,
also,
support
for
higher
level
metrics
for
volumes
volume,
metrics,
that's
also
stable
and
then
there's
a
new
security
feature
at
the
container
level,
which
is
to
allow
privilege
escalation
and
that's
been
added
to
security
context.
So
that's
a
stable
feature
again.
Some
of
these
are
our
smaller
changes,
and
so
that's
why
we
don't.
We
don't
necessarily
pay
that
much
attention
to
the
count
of
features
as
far
as
beta
and
alpha
roughly
1/2
or
beta
of
the
remaining
roughly
half
or
beta
in
half
our
alpha.
B
We
went
through
several
of
the
beta
features
again
just
in
terms
of
the
categories.
Custom
research
definitions,
our
beta
workload,
contrary
controllers,
we
went
into
detail
those
our
beta
cron
jobs
is
beta,
there's
a
number
of
other
beta
network
policy
has
to
beta
features
with
site
or
support
and
egress
support,
and
then
there's
a
there's.
A
number
of
features
related
to
the
horizontal
pod
autoscaler
that
have
also
moved
to
beta
with
regard
to
arbitrary
or
custom
metrics
usage
and
then
cube
ATM,
the
upgrade
command
we
covered.
B
That
is
beta,
the
exposing
story
at
usage
metrics
as
beta
cubed
client.
Certain
rotation
is
beta
anyway.
I
would
refer
you
to
our
release,
notes
for
more
details
on
all
of
the
features,
the
full
list
and
which
are
which
are
beta
on
which
are
alpha.
On
alpha.
We
talked
to
several
of
the
Alpha
futures.
We
spoke
to
the
again
there's
a
longer
list,
but
priority
preemption
volume
snapshots.
A
B
B
You
know
key
ops
kind
of
covers
not
only
cluster
installation
but
also
cluster
provisioning.
Cubes
Frey
is
a
newer
tool,
so
it
has
some
of
the
more
modern
methodologies
it
uses
some
of
the
primitives
from
cube
a
DM
cube
idiom
again,
as
I
mentioned,
it
intends
to
be
the
sort
of
reusable
modular
piece
that
can
go
into
chaos
and
can
go
into
cube
spray.
But
at
the
moment
there
are
many
different
ways
of
deploying
a
kubernetes
cluster,
and
that
is
something
that
sequester
lifecycle
is
actively
working
to
consolidate
and
to
standardize.
A
Thanks
for
pilot
right,
we're
almost
at
the
top
of
the
hour,
and
there
are
no
more
questions
coming
in
right
now,
so
I
think
we
should
wrap
it
up
here.
Thank
you
to
everyone
who
attended
and
for
all
the
for
all
the
questions
that
you
put
in
there.
Of
course
huge.
Thank
you
to
Anthony,
Aparna
and
Brad
for
explaining
all
the
exciting
new
features
in
1/8.
This
is
the
first
time
we've
done.
A
One
of
these
webinars,
but
I
I've
enjoyed
it
so
I
hope
we're
gonna
be
doing
one
for
one
night
and
everything
that
comes
after
that
also
big.
Thank
you
to
Caitlin
who's
been
quietly
making
sure
that
everything
runs
smoothly.
In
the
background,
that's
all
for
now.
Thank
you
very
much
and
I
hope
to
see
you
again
sometime
in
the
future.
Bye
bye.