►
Description
Kubernetes is being released and it’s time for an overview/update from Red Hat’s Clayton Coleman on all the many and varied new features and functions that are included in Kubernetes 1.7!
The Kubernetes 1.7 release is focused on on the “theme” which covers Kubernetes extensibility and is easily one of the most important arcs in the entire project (includes admission control extension, initializers, crd, and API extension). This release also includes kubectl extension, the stateful set and daemon set updates. As well this release includes new security features – secrets at rest, node security and continued improvements to other parts as well as pod security policy.
Clayton Coleman, lead architect, engineer, and strategic visionary for application platforms in the cloud at Red Hat will be our guest speaker.
A
Well,
hello
and
welcome
everybody
to
an
open
ship,
Commons
briefing,
we're
repeating
what
we
do.
Every
kubernetes
release
is:
try
and
coerce,
Clayton
Coleman
who's,
our
lead
architect
for
open
ships
and
lots
of
other
things,
kubernetes
related
at
Red,
Hat
and
you've,
just
gotten
with
kubernetes
1.7
out
the
door
I
think
sometime
late
last
night,
the
cig
release
team
posted
it.
A
So
it
is
up
and
out
and
ready
for
the
consumption
so
very
timely
that
we
get
this
update
from
Clayton,
and
so
the
format
we're
going
to
do
is
gonna
let
plate
and
do
his
presentation.
You
can
ask
questions
in
the
talk,
but
lots
of
people
on
the
call,
so
we
may
get
some
of
them
answered
there
in
the
chat,
but
the
good
questions
or
and
then
we'll
open
it
up
for
Q&A
at
the
end
and
we'll
read
those
out
and
get
those
in.
A
B
Thank
you,
so
a
guy
that
didn't
kubernetes
an
open,
shipped
architect
at
Red
Hat
I,
have
been
working
on
kubernetes
since
their
beginning,
and
this
is
a
very
exciting
release
for
us.
There's
a
ton
of
both
great
new
features,
as
well
as
changes
coming
to
kubernetes
that
make
it
even
more
of
a
platform.
I
broke.
The
the
features
I'll
talk
about
today
are
just
a
taste
of
what's
coming
in
kubernetes
1-7.
B
B
But
there's
four
features
that
I
wanted
to
call
out
here
in
kubernetes,
1-7
they're,
all
in
alpha
or
beta
that
deal
with
how
we
extend
kubernetes
as
a
platform.
So
the
first
many
people
who've
worked
with
kubernetes,
may
have
heard
about
third-party
resources.
This
is
a
an
alpha
feature
that
has
existed
for
since
at
least
kubernetes
1,
and
in
this
release
we
took
the
feedback
from
a
larger
where
people
in
the
community
worked
with
people
who
had
built
extensions
using
third-party
resources
and
tried
to
get
all
of
the
requirements
captured.
B
All
of
our
lessons
learned
with
third-party
resources
get
it
boiled
down
into
something
that
we
believe
we
can
support
going
forward,
and
so
in
kubernetes
1:7,
the
third-party
resource
is
being
transitioned
to
beta
under
the
new
name,
custom
resource
definition.
So
if
you
can
see
on
the
right,
the
name
has
changed.
A
few
of
the
fields
have
changed,
there's
a
ton
of
underlying
work
in
kubernetes
that
makes
third-party
resources
more
stable.
B
So
you
can
give
a
name
of
a
resource
and,
as
an
administrator
install
that
when
that
becomes
enabled
an
end-user
who
has
permission
to
create
those,
can
go
and
request
those
there's,
not
a
lot
of
control
or
structure
in
those
they're
they're
designed
to
be
ad
hoc,
they're,
designed
to
be
easy
to
set
up
and
install
and
there's
a
number
of
community
projects
that
have
latched
onto
third-party
resources
to
store
the
the
API
definitions
that
make
up
their
extension.
And
so
we
do.
We
have
left
room
in
third-party
resources
for
future
enhancement.
B
We
do
think
that,
over
time,
third-party
resources,
under
their
new
aegis
of
custom
resource
definition,
will
become
more
powerful,
we'd
like
to
add
more
features.
But
this
is
typically
the
place
where
extensibility
to
kubernetes
starts.
It's
the
easiest
way
to
get
started,
but
it
doesn't
necessarily
capture
all
the
use
cases,
and
so
a
second
feature
that
we've
added
in
kubernetes
1-7
is
part
of
work.
B
That
was
in
a
very
alpha
form
in
kubernetes
1/6,
but
is
the
ability
to
register
and
define
new
api's
that
actually
have
a
back-end
that
is
implemented
in
code,
and
so
the
difference
between
API
extension
and
registration
and
the
custom
resource
is
the
custom
resource
is
entire
provided
by
the
end
users
of
customer
sources,
no
validation,
there's
no
external
logic
preventing
changes
to
these
api's.
But
on
the
flip
side,
as
you
begin
to
develop
an
API,
you
may
find
that
you
want
to
impose
more
policy.
B
You
may
want
to
define
validation,
rules
in
source
code,
and
so
API
registration
allows
you
to
implement
those
api's
and
then
plug
them
into
a
kubernetes
server.
So
the
the
API
is
registered
with
the
kubernetes
api
server
and
the
Karina's
api
server
will
act
as
a
proxy
to
that
new
that
newly
defined
api
in
in
a
sense
if
a
custom
resource
is
about
an
end-user,
perhaps
not
having
to
bring
code
but
able
to
quickly
iterate
on
their
new
policy
object.
B
The
API
registration
path
is
more
when
someone
has
written
in
code
a
fairly
powerful
API
service
and
we
think
of
custom
resources
is
the
place
that
you
start
and
in
many
cases
as
kubernetes
grows
as
more
people
build
api's
that
extend
kubernetes
or
offer
new
features
alongside
kubernetes
that
the
second
mechanism
of
registration
will
be
how
the
vast
majority
of
them
end
up
implementing
in
the
diagram
you
can.
You
know
as
a
concrete
example.
B
Cabernets
will
return
not
just,
for
instance,
the
apps
b1
beta
one
group,
which
is
a
part
of
the
core
Korean
Air's
project
today,
but
it
also
returns
that
custom
API
group,
a
client,
would
then
talk
to
the
cube
API
server,
and
it
would
receive
the
request
proxy
through
the
server
when
we
think
about
how
this
will
evolve.
Much
of
the
work
that
we've
done
in
openshift
to
enable
kubernetes
to
be
a
true
platform.
We've
looked
at
it
through
how
openshift
resources
might
plug
in
to
kubernetes
and
so
OpenShift
offers.
B
A
number
of
api
is
above
and
beyond
kubernetes.
Some
of
those
are
parallels
to
two
features
that
are
starting
to
reach
GA
and
kubernetes,
like
deployments
and
ingress
for
routes
and
deployment
configs,
but
other
of
those
like
builds
image,
streams
templates
and
a
number
of
the
open
shift
policy
objects
have
no
equivalent
in
kubernetes,
and
so
we
think
about
this
custom.
B
Api
extension
as
a
way
for
someone
like
OpenShift,
who
has
built
an
api
that
works
very
well
natively,
with
cube
and
being
able
to
simply
and
easily
run
that,
both
on
top
of
cube
and
plug
into
cube.
It's
over
the
next
few
releases
of
kubernetes
and
open
shipped.
We
expect
to
see
this
used
by
more
production
grade.
B
Extensions
and
custom
resources
will
still
be
available
for
end-users
to
use
when
they're,
prototyping
and
they'll
always
be
a
trade-off
in
terms
of
whether
you
want
something,
that's
simpler
and
easier
to
install
or
whether
you're
looking
to
build
more
complex
policy
and
things
that
aren't
quite
possible
without
writing
code.
Each
of
those
will
complement
each
other
to
kind
of
give
them
both
sides
of
how
do
you
add
new
capabilities
to
a
kubernetes
server
along
those
lines?
It's
not
just
in
kubernetes
api,
czar
kind
of
the
heart
of
the
system.
B
You
know
each
of
the
kubernetes
api
is
is
about
a
simple
declarative
representation
of
some
concept
like
a
service
or
a
pod.
I'm
Cooper
naze
also
has
declarative
resources
for
things
like
policy,
so
the
are
back.
Engine
in
kubernetes
is
a
set
of
declarative
resources.
Quota
is
a
set
of
declarative
resources.
One
of
our
goals
is
if
kubernetes
has
simple
api's
that
are
fairly
declarative.
B
B
And
so
when
we
talk
about
what
it
would
take
to
turn
kubernetes
into
a
true
platform,
a
real
key
goal
and
a
common
request
is
to
allow
policy
decisions
that
are
made
when
an
end
user
submits
an
application
to
kubernetes
to
be
delegated
to
an
integration
or
an
extension
that
a
team
may
run
for
specific
use
cases
in
kubernetes,
1/7,
there's
a
new
Alfa
feature
that
is
being
that's
broadly
characterized
as
extensible
admission
control.
Every
time
you
submit
a
resource
to
a
kubernetes
server.
B
If
you
create
a
pod
or
a
service,
define
an
ingress
or
a
deployment.
There
is
a
an
internal
bit
of
code
that
runs,
which
is
called
the
admission
chain,
and
that
applies
policy
like
quota
and
pod
security
policy,
as
well
as
a
number
of
other
things
that
have
developed
over
time
like
calling
out
to
see
whether
images
are
allowed
to
be
run
on
the
cluster,
and
that
is
all
code
that
is
compiled
into
kubernetes,
starting
in
kubernetes
1/7.
B
There
is
a
new
emission
control
plug-in
that
can
call
out
to
additional
servers
in
the
process
of
accepting
us.
So
in
the
example
in
the
in
the
slide
I'm
showing
an
end
user,
creating
a
pod,
the
API
server
calls
that
internal
chain,
some
of
those
initial
ones,
run
like
pod
security
policy
or
image
policy,
and
then
the
generic
external
emission
plug-in
will
take
a
set
of
registered
extension
web
hooks
that
could
be
running
on
the
server
could
be
running
as
functions.
B
A
function
as
a
service
endpoint
could
be
running
as
a
micro
service,
really
just
a
simple
call-out
that
takes
the
information
about
the
pod,
that's
being
created
and
sends
it
to
each
of
the
external
hooks.
Each
of
those
external
hooks
gets
an
opportunity
to
accept
or
reject
the
request,
and
so
in
the
example
here
you
know
these
three
example
web
hooks
I
might
choose
web
hook.
One
is
recording
that
user
a
requested
creating
this
pod
in
an
external
system
such
as
an
audit
chain
web
hook.
B
Then
what
is
possible
in
communities
because
one
of
the
three
web
hooks
failed,
the
entire
request
is
failed,
and
so
the
admission
chain
would
stop
and
the
user
would
get
an
error
now.
This
is
a
somewhat
contrived
example,
but
if
you
followed,
along
with
the
development
of
this
feature
in
kubernetes
in
kubernetes
today,
we
have
about
10
or
15
built-in
and
mission
controllers
that
can
be
optionally
enabled
those
cover
things
like
pods
security
policy.
They
cover
node
placement
policy,
allowing
you
to
set
annotations
on
a
namespace
that
control
what
node
selectors
are
allowed
on.
B
Pods
openshift
adds
about
40,
more
emission
controllers.
Ok,
our
goal
here
is
on
a
regular
kubernetes
cluster.
It
should
be
possible
to
add
in
new
admission
control
as
easily
as
adding
new
api's,
and
this
feature
is
alpha.
It's
still
in
its
initial
phases
in
cube
1-7,
but
over
time
we
expect
to
build
a
set
of
standard,
webhook
code
and
examples
that
make
it
easy,
for
instance,
for
individual
operations
teams
who
want
to
impose
specific
policies
to
build
their
plugin
hooks
in
a
fairly
simple
manner.
B
There's
some
performance
cost
that
comes
along
with
making
these
call-outs,
but
in
general
we
found
that
for
most
use
cases.
This
flexibility
is
one
of
the
most
important
extension
points
for
kubernetes,
because
it's
not
just
about
running
applications.
It's
about
knowing
what
is
running
and
being
able
to
control
some
of
the
aspects
of
that
in
and
as
a
kind
of
the
fourth
part
of
this
extension,
we
talked
about
adding
new
api's.
We
talked
about
adding
new
policy.
B
B
So
if
there
is
a
specific
new
API
resource
that
gets
added
through
API
extension,
that
needs
some
form
of
command-line
tool
to
make
useful,
for
instance,
a
policy
object
that
is
fairly
complex
for
an
end
user
to
create
a
plug-in
extension
to
cube
control
might
be
created
that
offers
a
help.
Helpful
flow
for
setting
up
that
policy
object
the
first
time
and
there's
a
lot
of
other
work
going
on.
You
know:
I'm,
just
scratching
the
surface
of
the
extensibility
to
both
CLI
and
the
cube
API.
B
So
moving
on
from
extensibility
security
was
another
big
art
in
the
1
7
release.
You
know,
Red
Hat
takes
security
very
seriously
and
we've
been
you
know
not
just
working
to
ensure
that
people
can
run.
You
know
fully
multi-tenant
systems
through
the
work
that
we've
done
with
our
back
authentication
and
the
pods
security
policies
to
control
who
can
use
what
host
level
resources.
B
One
of
the
common
requests
that
we've
gotten
is
to
make
it
easier
to
keep
secret
data
in
the
platform
encrypted.
The
cube,
1,
7,
&,
OpenShift,
3
6
will
both
include
this
feature
and,
in
its
core
form
the
ability
to
encrypt
at
rest
in
the
sed
database
secrets,
as
well
as
other
resources
that
the
user
may
want
to
encrypt.
B
For
instance,
if
you
have
an
extension
resource
that
also
contains
secret
data,
you
may
wish
to
provide
this
configuration
for
that
as
well,
when
a
user
submits
a
secret
to
the
kubernetes
api,
we'll
take
that
we'll
look
at
the
encryption
config
and
then
encrypt
that
using
either
AES
CBC
or
the
secret
box
standards
for
encryption.
There's
a
there's
some
documentation
on
the
trade-offs
our
goal
was,
even
though,
in
general,
we
still
think
that
whole
disk
encryption
is
the
best
possible
way
to
ensure
that
your
backups
don't
go
walkabout.
B
We
did
want
to
offer
an
out-of-the-box
way
for
administrators
to
at
least
in
the
short
term,
isolated,
encrypt
secrets,
an
extra
level.
These
secrets.
Of
course,
you
know
all
of
the
existing
characteristics
of
a
kubernetes
system
are
still
preserved.
Secrets
are
always
encrypted
over
the
wire
and
are
never
stored
on
disk.
This
just
adds
an
extra
layer
to
the
secrets
from
the
sed
servers
and
there's
a
number
of
recommendations
that
we've
made
in
this
release
on
how
secrets
can
be
more
more
adequately
controlled.
B
A
a
second
part
of
the
cube
1:7
feature
arc
was
tighter
controls
on
the
secrets
and
tighter
control
on
what
nodes
can
access
in
kubernetes
systems
today,
there's
a
fairly
flat
security
model
for
nodes
nodes
are
expected
to
be
controlled
to
a
set
of
resources,
but
they
have
access
to.
They
have
access
to
the
resources
in
bulk,
rather
than
the
specific
resources
that
schedule
to
them.
B
In
kubernetes,
1-7
nodes
are
protected
by
a
new
authorization
layer
that
will
restrict
what
a
node
can
access,
not
just
to
the
pods
that
are
scheduled
on
to
it,
but,
for
instance,
only
the
secrets
or
persistent
volumes
that
are
actually
referenced
by
the
pods
that
are
scheduled
on
to
it.
This
is
alpha
in
1:7.
We
expect
to
continue
to
evolve
this.
B
That
that
is
coming
is
being
involved
in
communities
is
if
nodes
are
given
a
unique
set
of
permissions,
we
obviously
want
to
have
a
standardized
path
in
kubernetes
for
nodes
to
be
given
their
identity,
and
so
this
is
called
bootstrapping
kubernetes.
You
may
have
also
heard
it
as
self
join
or
as
dynamic
registration.
B
This
is
defining
a
standardized
flow
whereby,
when
a
cubelet
starts
up
it,
instead
of
having
its
permission
embedded
on
that
system,
so
instead
of
having
to
distribute
a
unique
credential
to
every
machine
when
the
cubelets
starts
up,
it
actually
asks
a
the
cluster
that
it's
going
to
join,
to
receive
it's
identity
and
the
process.
This
is
there
a
new
API
that
has
been
in
beta
since
grenades,
1-5
called
the
certificate.
B
This
is
a
certificate
API.
This
is
very
similar
to
systems
that
have
existed
and
other
config
management
solutions
like
puppet
or
key
generation
systems.
The
cubelet
creates
a
certificate
signing
request
on
startup,
and
it
asks
the
kubernetes
master
for
a
client
certificate
that
will
identify
it.
A
separate
process
shown
in
this
diagram
as
the
signer,
which
could
be
either
automated,
which
is
something
that's
available
in
an
alpha
form
in
kubernetes
or
manual
in
the
terms
of
this,
is
available
through
the
Trinities
command
line
and
api
is
for
administrators
just
script
as
needed.
B
Our
goal
in
kubernetes
is
to
provide
a
simple
out-of-the-box
path
that
works
well
on
the
cloud
providers
and
to
allow
people
to
extend
or
supplement
this
path
with
their
own
logic.
And
so
there
is
no
there's,
no
expectation
that
this
is
a
closed
system,
which
is
why
the
signer
is
split
out.
Like
it
is,
if
the
signer
decides
to
accept
the
request,
it
will
create
and
sign
a
client
certificate
and
give
that
back
to
the
cubelet.
B
B
This
is
being
tied
into
certificate
expiration
and
so
the
cubelet,
as
those
certificates
get
closer
to
expiration,
will
re
request.
New
certificates
and
the
human
or
the
automated
signing
process
can
then
grant
those
again-
and
we
see
this
as
this
is
a
first
step
in
kubernetes,
one-
seven
that
will
begin
to
make
clusters
more
automated
and
autonomous
in
terms
of
how
individual
machines
are
set
up,
but
still
leave
administrators
with
the
control
over
who
joins
their
cluster
and
what
level
of
automation
and
verification
they
need
as
nodes
join.
B
The
audit
feature
is
also
being
improved
in
Coober
neighs
one
seven.
This
was
first
delivered
into
kubernetes,
one
five
after
being
up
streamed
from
OpenShift.
The
the
first
iteration
was
a
simple
file
based
mechanism,
Bowl
log
based
mechanism.
We
then
extended
that
to
log
to
a
separate
file
in
kubernetes
one,
seven,
we've
added
a
large
number
of
new
of
new
filtering
and
logging
capabilities
that
allow
it
to
be
allow
more
API
actions
to
be
reported
to
allow
filtering
and
to
allow
individual
sinks
of
where
that
data
will
go.
B
So
we
envisioned
over
the
next
few
releases
to
see
the
ability
to
ship
specific
on
it.
Events,
two
distinct
systems
as
necessary,
or
to
send
keep
a
full
record
of
all
actions
locally
and
send
the
most
important
events
remotely.
This
will
continue
to
evolve.
This
is
just
really
the
beginning
for
this,
but
we
envision
plugging
in
well
to
both
existing
enterprise
level,
audit
solutions,
as
well
as
integrating
into
the
cloud
providers
out
of
the
box,
so
that
it's
possible
to,
for
instance,
send
your
logs
directly
to
stack
driver
or
cloud
watch
if
you
so
desire.
B
So
there
again,
as
with
extensibility,
this
is
really
just
scraping.
The
surface
of
the
security
improvements
in
kubernetes
1-7
are
overall,
are
for
security
in
one
8
+
1
9
is
going
to
be
to
continue
to
offer
better
subdivision
and
better
integration
with
external
secret
stores.
There's
a
lot
of
work
going
on
in
kubernetes,
cig
off
and
highly
recommend.
B
If
this
is
an
area
that
interest
you
that
you
join
will
be
talking
about
topics
over
the
next
few
months,
like
container
identity
and
giving
pods
and
services
unique
certificates
that
allow
them
to
talk
to
to
talk
to
other
systems
and
to
have
a
chain
of
attestation
all
the
way
back
to
the
node
that
launches
them.
So
we
see
some
of
the
work
that's
going
into
coop
1
7
is
really
foundational
for
the
next
year
of
evolution
of
kubernetes
in
1-7
for
running
apps,
there's
really
just
at
the
heart
of
it.
B
So
this
feature
has
is
very
similar
to
the
existing
kubernetes
deployment
and
the
open
ship
deployment
config.
When
you
perform
a
configuration
change
on
a
stateful
set,
the
stateful
set
controller
will
begin
replacing
members
of
begin
replacing
members
of
the
stateful
set
one
at
a
time.
It
will
follow
the
default
rules
for
stateful
sets,
which
is
a
very
predictable
order.
A
new
capability,
that's
being
added,
is
partition
and
we
see
this
as
a
key
part
of
enabling
a
more
complicated
orchestration
on
top
of
kubernetes
in
the
future.
B
The
partition
ability
lets
the
person
doing
the
initial
update.
So
when
I
update
a
stateful
set
to
pick
a
new,
the
v2
image
I
can
also
set
a
partition
number,
and
that
says
how
far
the
rolling
update
will
go
before
stopping
and
so
in
the
example
you
can
see.
I've
got
seven
instances
and
my
staple
said:
I
perform
the
update.
The
stateful
set
controller
starts
from
the
lowest
ordinal.
It
works
its
way
to
the
right.
So
it's
going
to
update
the
first
pod,
which
would
be
you
know,
stateful
set
zero.
B
It
will
then
once
that's
ready.
It
will
then
update
the
second
one,
and
the
key
point
looks
like
I
didn't
color
that
second
b2
correctly.
The
key
point
is
with
the
partition
limiter
in
place.
The
staple
set
will
stop
its
updated
to
members,
and
so
when
we
think
about
canary
deployments
or
the
ability
to
script
more
complex
deployment
checks
to
ensure
that
an
update
really
is
going
to
be
successful.
B
Starting
with
kubernetes
one,
seven
and
staple
sets
you'll
have
the
ability
to
pause
that
deployment
and
then
continue
it
as
it
goes,
and
so
you
can
update
the
partition
number
from
one
to
two
to
five
to
seven.
If
you
clear
it,
the
rolling
deployment
will
run
to
full
completion
and
continue
for
the
rest
of
the
set.
We
anticipate
higher
level,
primitives,
plugins
and
Jenkins
tools
that
might
orchestrate
kubernetes
deployments
like
an
a
bowl
or
some
other
capabilities
that
are
out
there
to
start
leveraging.
B
The
the
partition
on
staple
sets
as
well
as
we
plan
on
bringing
it
to
deployments,
to
give
this
fine-grained
control
over
the
act
of
deploying
and
make
make
staples,
that's
even
more
predictable
and
reliable
in
their
rollout
in
1:7.
This
does
only
update
pods.
The
pod
definition
will
be
changed,
but
the
volume
definition
will
not
be
some
of
the
work.
That's
been
discussed
in
the
community
storage
sig
about
adding
resizable
volumes
may
actually
show
up
at
some
future
point
in
staple
sets,
but
it
is
not
part
of
cube
one
seven.
B
A
second
highly
requested
feature
for
stateful
sets
is
the
ability
to
perform
parallel
scaling.
Today,
if
you
run,
if
you
run
a
very
large
stateful
set
the
staple
set
controller
in
cube,
one
six
would
progress
one
at
a
time.
So
if
you
have
a
thousand
pods,
it's
gonna
do
each
each
of
those
thousand
pods
individually.
In
one
seven,
we
added
a
new
alpha
capability
to
staple
sets.
It
allows
you
to
do
parallel
scale
up.
B
B
It
does
not
apply
to
update,
so
a
rolling
update
of
a
stateful
set
will
follow
the
rules
of
the
rolling
update,
so
you
can
still
get
predictable,
controlled
rollouts,
but,
for
instance,
if
a
large
chunk
of
your
pods
are
deleted,
a
new
set
of
paws
would
be
created
to
replace
them
very
quickly.
This
feature:
will
we
don't
anticipate
this
feature
changing
much,
but
it
is
alpha
and
1:7.
B
While
we
get
some
feedback
from
people
deploying
very
large
staple
sets
and
then
finally,
for
the
running
apps,
section
daemon
sets
also
received
the
ability
to
be
to
have
rolling
updates
the
because
daemon
sets
tend
to
be
more
administrator,
focused
or
focused
on
actions
that
take
place
across
the
entire
cluster.
The
rollout
options
are
different,
unlike
a
stateful
set
or
a
deployment,
daemon
sets
define
a
max
unavailable
percentage
and
the
the
daemon
set
controller
will
then
guarantee
that
no
more
than
a
certain
percentage
of
those
pods
are
unavailable
at
a
time.
B
So
in
the
example
you
can
see
when
a
daemon
set
is
updated
and
the
max
unavailable
is
set
to
a
third,
the
daemon
set
will
choose
to
keep
all
but
two
pods
stable
at
any
one
time.
So
in
the
first,
in
that
second
line,
you
can
see
it
spins
up
to
new
V
two
pods.
Those
will
get
updated
when
those
become
ready
and
are
fully
running.
The
second
version
it'll
pick
two
more
pods
in
that
fourth
row.
You
can
see
that
one
of
the
pods
one
of
the
V
one
pods
has
died.
B
If
you
would
like
to
do
controlled,
rollouts
of
daemon
sense
across
smaller
subsets
generally,
you
would
just
create
several
daemon
sets
one
for
each
sub
set
of
nodes
and
update
those
at
a
separate
time.
Both
daemon
sets
and
staple
sets
track.
The
previous
revision
they're
a
new
resource
called
controller
history.
B
This
is
a
this
is
an
alpha
resource,
technically,
even
that
we
depend
on
on
beta,
even
though
this
is
the
update
process
of
daemon
sets
and
staple
sets,
is
itself
beta,
and
so
what
you
can
expect
is
as
a
user,
when
another
person
performs
an
update
on
a
stateful
set
or
a
daemon
set
you'll
be
able
to
go
and
view
the
history.
Just
like
you
can
view
the
history
of
the
deployment
or
a
deployment
config
through
replica
sets
and
replication
controllers
on
the
runtime
side.
B
We've
haven't
talked
a
ton
about
this,
but
the
the
container
runtime
interface
in
kubernetes
is
getting
close
to
moving
into
a
beta
state.
The
container
runtime
interface
for
those
who
aren't
aware
is
the
abstraction
in
kubernetes
that
separates
the
container
runtime
from
the
cubelet
and
allows
you
know
as
a
standard
set
of
API.
B
Is
that
it
invokes
to
ensure
that
containers
are
running
for
pods,
that
logs
and
the
exec
behavior
can
be
supported,
that
statistics
flow
and
that
images
are
managed
over
the
last
year
or
so
Red
Hat
has
been
working
kind
of
on
a
standard
container
runtime
that
uses
OC
I
and
system
D.
As
we
get
closer
to
having
CRI
move
into
the
beta
state
in
kubernetes,
Red
Hat
has
been
pushing
forward
on
ensuring
that
the
cryo
cryo
also
reaches
an
alpha
milestone.
B
It
really
is
focused
on
supporting
exactly
the
subset
of
features
that
are
necessary
for
kubernetes.
It
doesn't.
It
adds
significantly
less
overhead
on
a
coordinate
system,
and
we
envision
this
in
the
future,
being
both
a
proving
point
for
CRI,
as
well
as
offering
some
operational
and
production
advantages
when
running
containers
on
kubernetes
and
so
you'll
see
more
of
this
in
the
future.
B
Network
policy
is
one
of
the
more
popular
features
in
kubernetes,
at
least
done
so
I've
heard
in
q1
7.
It
will
not
move
to
GA
and
the
network
policy
buggins,
both
in
kubernetes
and
OpenShift.
A
large
number
of
them
are
moving
to
support
network
policy
as
a
as
a
fundamental
resource.
This
allows
fine-grained
control
over
which
containers
and
applications
can
talk
to
each
other
across
namespaces
on
the
open
shift
side.
B
Trying
to
to
dive
into
I
did
want
to
call
out
for
four
very
important
areas
that
we
won't
go
into.
An
extreme
amount
of
detail
on
local
storage
volumes
was
a
proposal
for
kubernetes
one-seven
and
a
very
early
alpha
version
of
it
is
in
q1
7.
This
is
a
really
exciting
feature.
That's
very
commonly
requested
the
ability
for
a
pod
to
request
local
storage
and
then,
if
the
pod
gets
rescheduled
to
have
it
be
rescheduled
back
on
that
machine
at
that
storage
is
still
available.
B
There
were
a
ton
of
CLI
improvements
in
kubernetes
1/7,
the
overall
usability
of
the
command
extensions
that
make
it
easier
to
manage
deployments
to
get
better
information
from
the
server
as
a
number
of
performance
improvements.
The
cube
proxy,
which
is
kind
of
the
current
heart
of
how
applications
talk
to
each
other
on
kubernetes
today,
got
a
massive
set
of
performance
improvements
that
we
expect
will
continue
into
the
kubernetes
1/8
release
and
then
service
catalog,
which
many
other
folks
on
this
call
are
probably
familiar
with
the
service.
Catalog
work
continues
apace.
B
We
expect
over
the
Queen
A's
won
8
+
1
9
time
frames
to
really
bring
that
to
you
know
at
first-class
behavior,
Bernays
Service
Catalog
is
actually
one
of
the
first
consumers
of
the
extension
points
I
mentioned
before,
and
so
we
expect
a
fairly
rich
experience
and
that
to
be
the
proving
grounds
for
on
kubernetes
being
able
to
add
new
capabilities
in
a
seamless
way
without
having
to
necessarily
compile
those
into
the
kubernetes
project
itself,
and
with
that
I'd
love
to
take
some
questions.
If
there
are
any.
A
There
are
a
couple
Clayton
and
I've
also
posted
in
the
notes
and
the
chat,
the
police
notes
for
the
connect,
1.7
release
so
and
we
have
a
couple
of
deep
dives
coming
one
on
creo,
another
on
service
catalog
in
the
upcoming
open
ship,
hominins
briefing
schedule
the
first
question
or
the
the
most
recent
question
will
go.
That
way.
Do
you
have
the
user
context
in
the
web
book,
and
this
is
going
back
to
the
touch
since
ability
yeah.
B
A
fundamental
part
of
of
policy
extension
is
knowing
who
the
acting
user
is,
and
so
that
is
a
part
of
both
the
extension
mechanism,
as
well
as
for
for
the
the
webhook
extensions
for
emission
policy.
But
it
is
also
available
to
extension,
API
servers,
and
so
you
will
continue
to
see
that
propagated
to
the
rest
of
the
system
and.
B
That
is
a
goal.
There
was
a
number
of
really
important
changes
that
have
continued
to
occur
in
Cooper,
nays,
1,
5,
1,
6
and
1
7
to
clean
up
the
internal
structure
of
those
libraries
to
make
them
really
be
consumable.
So
is
definitely
a
short-term
or
a
near-term
goal
for
us
to
have
a
very,
very
powerful,
go
client
library
and
as
well,
to
be
able
to
reuse
the
extension
mechanisms
or
sorry.
The
the
generation
mechanisms
that
we've
been
working
on
in
kubernetes
for
the
AP
openshift
api
as
well.
B
B
Of
the
features
that
I
described,
there's
no
explicit
plan
to
back
port
those
two
older
kubernetes
versions,
a
large
chunk
of
the
is
speaking
for
openshift,
a
large
chunk
of
the
api
aggregation
and
api
extensibility
and
the
service
catalog
work
is
specifically
something
that
Red
Hat
is
driven
because
you
know
we
believe
really
strongly.
In
extensibility.
Some
of
those
capabilities
will
be
in
kubernetes
in
open
chef,
3
6.
B
A
B
That
is,
cubed
bootstrapping
has
been
one
as
it
evolved
in
kubernetes.
One
seven
there's
been
an
early
version
of
it
in
openshift
and
kubernetes,
since
the
one
five
release
our
goal.
What
we
really
do
want
to
make
bootstrapping,
because
it's
so
fundamental
to
how,
in
the
future
we'll
do
a
certificate
regeneration.
It
allows
a
an
external
CA
to
be
used
to
sign
certificates.
It
allows
us
to
delegate
trusts
from
that
initial
cubelet
bootstrapping
to
the
containers
that
run
on
the
platform
and
because
it
just
reduces
the
amount
of
overhead
necessary
to
stand
up
new
nodes.
B
It's
like
there'd
be
a
very
strong
focus
for
us
in
the
open
ship
side.
To
have
that
both
be
you
know.
Initially,
we
will
do
a
better
job
of
documenting
what's
already
there,
but
we
intend
to
use
it
more
fully
to
to
make
it
easier
to
stand
up
nodes.
So,
while
in
one
seven
and
three
seven
openshift,
you
may
not
see
it
be
fully
supported
over
the
long
term,
bootstrapping
will
become
the
de
facto
way
that
we
stand
up
new
nodes.
B
There
was
a
lot
of
work
on
Federation
in
the
one
seven
time
frame.
The
Federation
is
still
alpha,
there's
a
number
of
things
that
we
still
think
need
to
be
closed
out,
such
as
upgrading
and
a
lot
of
a
lot
of
getting
things
and
final
working
shape.
So
there
was
a
ton
of
work
that
was
done
in
the
one
seven
time
frame
of
functional
changes,
not
a
terribly
large
number.
A
D,
any
other
questions
I'm
gonna
pop
over
and
just
remind
everybody
that
the
Oakland
ship
Commons
Gathering,
is
coming
up
soon
and
we
have
limited
space
again,
but
it
will
be
at
coupon
and
you
would
be
able
to
hear
Clayton
we
give
by.
Then
it
should
be
the
same
update
on
hopefully
ku,
1.8
and
that'll.
Be
there.
You
can
register
that
and
then
all
of
the
other
I
mentioned
that
there
were
other.
A
Calendar
folks
here
I
think
we
have
a
big
week
coming
then
maybe
not
over
the
4th
of
July
week,
but
we're
gonna
have
a
parent
out.
Sinha
from
Google
is
going
to
give
technical
roadmap
road
ahead
for
1.8
talk
on
July
11th
will
be
a
distributed,
tracing
with
Yeager
and
then
some
a
couple
of
other
ones
and
then
coming
up
soon.
There'll
be
one
on
Service
Catalog
and
we
haven't
found
a
date
yet
for
another
one
on
cryo,
but
it
should
probably
be
on
sometime
in
July.
So
is
a
very
busy
calendar.
A
So
please
do
keep
an
eye
out
and
we'll
try
and
keep
you
all
up
to
date
on
everything.
That's
coming
out
the
pike
with
kubernetes
in
the
relationship
there's
a
lot
of
interest
in
this,
and
so
we
hope
that
you'll
stay
tuned
and
if
you
haven't
joined
with
the
Oakland
ship
Commons.
Yet
please
do
so
and
get
you
on
the
slack
channel
and
into
our
mailing
list
so
that
you
miss
any
of
these
events
and
I
still
don't
see
any
other
questions.