►
From YouTube: Webinar: What's New in Kubernetes 1.9
Description
In the fourth and final release of 2017, Kubernetes 1.9 continues the evolution of an increasingly rich feature set, more robust stability, and even greater community contributions. This all points to increased extensibility and standards-based Kubernetes ecosystem.
In this webinar, members of the Kubernetes 1.9 release team will cover some of the major features in this release and demo some of the highlights in the areas of Windows and Docker support, storage, admission control, and the workloads API.
Slides: https://docs.google.com/presentation/d/1U01MqTXbHv9aSiM2s87bxeMiUE8EwW0COSgntgZ16Fo/edit?usp=sharing
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,
so
we're
ready
to
start
welcome
everyone
to
the
first
webinar
by
cloud
native
computing
foundation
in
Radian
team
that
is
focused
on
the
US
release
of
cabinet.
Is
that
was
went,
live
publicly
in
December
around
1
months
ago
is
given
it
is
funded
9,
and
today
we
have
a
group
of
people
who
been
developing
the
new
features
and
developing
the
new
functionality
for
communities
hundred
nine
release.
A
I'm.
My
name
is
iridar
etske
I'm,
a
developer
advocate
at
CN
CF
and
have
been
a
feature
slate
head
cabinet
is
wanted
man
release.
Also
I
am
a
co-lead
of
seek
project
management
at
communities.
Community,
together
with
me,
would
have
asada
Lee
from
Google,
who
is
six
storage,
lead
David
aids
from
redhead,
who
is
a
sick?
Heavy
machinery
lead
Michael
Michael
from
aprender
leader
in
sick
windows,
and
can
it
Owens
from
Google
or
his
primary
responsible
for
driving
sick
apps.
So
today
we'll
speak
with
you
about
the
highlights
of
cabin
I.
A
Just
wanted
man
release
why
this
release
is
so
exciting
for
communities
people
and
for
cabin
in
this
community,
and
today
will
also
highlight
a
group
of
new
features
and
major
features
that
have
appeared
in
this
release.
First
of
all,
it's
the
container
storage
interface
called
CSI,
and
so
it
will
describe
it
with
more
details.
We
have
the
new
web
hook
admission
admission,
feature
that
will
be
described
by
a
deputy
it's
today.
A
Winter
server
support
is
amazing,
new
feature
in
this
release,
and
so
many
people
were
waiting
for
it
for
a
long
period
of
time
and
Michael
Michael
will
describe
this
feature
and
for
clothes,
API
became
as
a
purchased,
a
general
availability
feature
and
Kenneth
Owens
would
be
a
person
well
described
feature
today
and
we'll
also
have
the
Q&A
session
at
the
end
of
the
webinar.
If
you'll
have
some
extra
questions,
so,
first
of
all
a
few
highlights
about
this
release.
A
As
I
mentioned
before
it's
the
final
release
in
2017,
we
had
four
releasing
four
losses
in
a
row
in
the
previous
year,
starting
from
1.6
and
keeping
I
just
wondered.
Fine
was
the
final
one,
and
probably
the
most,
the
most
important
won't
close
there
for
roles
for
releases.
It
ended
here
and
combined
in
209
was
really
important
for
this
community
because
we
have
almost
switched
from
the
model
when
other
features
are
dictated
from
from
some
central
point.
A
At
the
same
time,
with
kinetise
1.9
release,
we
have
the
amazing
practice
when
every
single
special
interest
group,
every
single
community
sub
community
was
in
the
cabinet,
as
community
is
responsible
for
some
technical
area,
they
are
responsible
for
delivering
the
new
features
and
they
defined
the
roadmap
and
division.
What
exactly
did
it
like
to
see
this
race?
We
had
almost
40
new
features.
A
Most
of
them
didn't
deliver,
as
the
Alpha
features
of
official
means
that
it's
extremely
new
and,
if
pressed
on
what
it's,
but
it
appears
to
the
world,
and
everybody
can
try
it
in
in
the
new
release.
At
the
same
time,
our
feature
is
not
enabled
by
default,
so
be
careful
about
enable
all
four
features
in
here
cabinet
is
cluster.
The
same
time,
if
you'd
like
to
try
some
extremely
new
functionality
offer
features
offer
you.
Some
features
were
deliver.
This
beta
features
beta
feature
provides
some
extra
stability
compared
to
alpha
feature.
A
You
may
also
hear
this
definition,
so
speaking
about
the
major
errors
where
communities
wandered
nine
features
were
delivered
and
developed
communities
community
was
primarily
focused
on
enabling
extra
workload,
support
him
and
Henson.
The
existing
workload
support
enabling
and
extending
their
capabilities
in
terms
of
security,
convenience,
209,
is,
was
really
focused
on
the
extensibility
features,
together
with
the
search
features
and
all
this
oldest
measure.
B
B
Or
I
think
support
making
the
scheduler
aware
of
storage,
which
is
very
important
for
local
storage
and
then
finally,
container
storage
interface.
While
all
these
features
are
big
today,
I
wanted
to
focus
in
on
CSI
in
particular,
and
with
that,
let's
go
to
the
next
slide.
So,
let's,
let's
set
the
stage.
What
is
the
problem
that
we
are
trying
to
solve
with
CSI
kubernetes
already
has
a
very
robust
volume,
plug-in
system,
it's
unique
and
very
powerful.
B
Closed
repository,
firfer
vendors,
they
don't
like
to
do
this
because
it
means
being
tied
to
the
kubernetes
release
cycle.
It
means
that
they
have
to
open-source
their
code,
whereas
some
vendors
don't
want
to
do
that,
and
it's
bad
for
kubernetes
in
general,
because
it
makes
us
responsible
for
testing
and
maintaining
external
code
and
for
a
number
of
reasons.
B
B
Let's
just
go
ahead
and
call
out
to
external
scripts
that
will
fulfill
that,
and
so
basically
the
way
that
you
deploy
a
new
volume
plug-in
would
be
you
write
a
script
or
some
executable
and
you
deploy
that
on
your
node
machines
and
then
kubernetes
discovers
them
and
allows
you
to
use
them.
This
approach
works,
but
it
has
some
problems.
One
of
the
primary
problems
is
that
deployment
is
pretty
painful.
B
You
actually
have
to
have
access
to
the
root
filesystem
to
be
able
to
deploy
new
volume
drivers,
and
it
doesn't
really
answer
the
question
about
dependencies
right.
If
you're
deploying
a
executable
directly
to
a
node
machine,
the
dependency
the
binary
may
have
dependencies
that
are
not
already
on
the
host
machine
that
you
also
have
to
install
things
like
mount
tools,
file
system
tools.
B
Okay,
Very's
deploy
new
volume,
plugins
and
all
their
dependencies,
so
this
is
a
problem
that
we're
not
alone
in
facing.
We
talked
to
other
container
orchestration
systems
who
experienced
the
same
issue,
and
many
of
the
storage
providers
also
were
experiencing
this
to
the
point
of
trying
to
invent
a
solution
for
it,
and
so
what
we
did
was
get
together
and
create
this
new
initiative
called
the
container
storage
interface.
B
B
So
what
is
si
si?
It's
essentially
three
main
method
calls
one
is
to
create
a
volume
or
delete
a
volume
and
other
is
to
attach
or
detach
a
volume
from
a
node
and
finally,
to
mount
or
unmount
to
volume.
What
si
si
is
not
is
is
a
specification
that
specifies
packaging
or
deployment.
The
si
si
specification
only
defines
the
interface
with
which
arbitrary
Co
can
can
speak
to
an
arbitrary
volume,
plug-in
it
doesn't
care
how
the
volume
plug-in
is
packaged,
how
it's
deployed,
how
it's
monitored,
etc,
etc.
B
Basically,
all
at
once,
you
are
seeing
that
top
next
slide.
I
can
go
to
that.
There
we
go
so
the
current
status
of
the
CSI
spec
is
that
in
December
2017
we
published
the
point.
One
version
of
the
spec
and
the
various
SEOs
have
started
implementing
their
their
versions
of
this
fact,
and
we
introduced
alpha
support
for
this
spec
in
1.9
kubernetes
next
slide.
B
So
the
way
that
we
introduced
it
in
kubernetes
is
actually
a
new
entry
volume,
plugin
very
similar
to
flex.
So
if
you're
familiar
with
Flex
think
the
same
thing
for
CSI,
the
nice
thing
about
adding
an
entry
volume
plug-in
is
that
we
can
reuse
all
the
existing
volume
code
without
having
to
modify
any
of
the
core
or
potentially
destabilizing
the
existing
code.
And
another
nice
thing
about
it.
Is
that.
B
As
far
as
the
users
are
concerned,
they're
going
to
be
interacting
with
CSI
in
exactly
the
same
way,
they've
become
used
to
interacting
with
many
of
the
entry
volume
plugins.
That
means
using
storage.
Api
primitives,
like
persistent
volume,
claims,
persistent
volumes
and
storage
classes
next
slide,
so
I'm
gonna
walk
through
really
quickly
what
that
would
look
like
to
an
end
user
to
an
application
developer.
Who
is
trying
to
deploy
their
application
on
kubernetes?
B
So
first
thing:
is
they
want
to
dynamically
provision
a
volume,
so
their
cluster
administrator
would
come
along
and
they
would
create
a
storage
class.
Normally,
this
provisioner
would
point
to
one
of
the
entry
volume
plugins,
but
now
we
support
outer
street
volume
plugins,
so
the
provisioner
can
be,
for
example,
in
this
case
CSI
driver
by
comma
example,
team
and
parameters
is
just
an
opaque
set
of
parameters
that
should
be
passed
to
that
driver
when.
B
B
So
there's
a
whole
aspect
of
how
to
deploy
si
si
volume
drivers
on
an
arbitrary
kubernetes
system,
I'm
not
going
to
go
into
that.
There's
a
blog
post
coming
out
tomorrow,
which
links
to
documentation
feel
free
to
take
a
look
at
that.
Otherwise,
this
will
run
on
a
lot
longer,
but
very
quickly.
I
wanted
to
highlight
where
we're
going.
Next,
we
just
launched
alpha
for
si
si
last
quarter.
This
quarter
we're
trying
to
decide
whether
to
go
to
beta
or
if
we
have
too
much
work.
B
We're
gonna
remain
in
alpha
and
go
to
beta
next
quarter.
We're
trying
to
make
that
decision
within
the
next
few
weeks.
On
the
CSI
spec
side
of
things,
we
are
going
to
take
the
learnings
from
actually
implementing
this
on
the
CEO
side
and
actually
implementing
drivers
to
improve
and
revise
the
spec
and
push
it
to
1.0.
We
want
to
also
focus
on
improving
how
we
handle
topology.
This
includes
things
like
zones
and
regions,
and
we
also
want
to
be
able
to
improve
how
credentials
are
passed
in
through
the
CSI
interface
and
then.
B
Finally,
we
want
to
figure
out
what
the
certification
story
would
be
for
a
CSI
driver.
How
does
a
arbitrary
CSI
driver
get
the
stamp
of
approval
to
say
that
this
is
compatible
with
the
CSI
interface?
So
we
have
a
lot
of
work
coming
up
in
the
next
few
quarters
if
you're
interested
in
joining
us,
please
join
us
in
the
storage
sake,
we're
looking
for
volunteers
who
are
interested
in
this
space
to
help
us
out
and
that's
it.
Thank
you.
A
C
Great
next
slide,
please
so
in
q1
9
we
moved
webhook
admission
to
beta
I'm
gonna
briefly
describe
what
admission
is
so
admission
is
a
phase
of
rest
handling
when
you
submit
an
API
object
that
comes
after
authorization,
but
before
you
persist,
the
data
SED
admission
plugins
have
access
to
the
actual
content
of
the
body
itself.
So
if
a
user
submits
a
pod,
an
admission
plugin
can
actually
look
and
see
the
content
of
that
pot,
and
this
means
that
an
admission
plugin
can
have
semantic
knowledge
of
particular
resource
types.
C
It
can
know
what
a
pod
image
field
means
or
what
a
cluster
role
rule
means
admission
is
split
into
two
phases
in
this
diagram.
You
can
see
we
come
in.
We
have
authentication
and
authorization,
then
there's
a
phase
where
admission
is
allowed
to
mutate
data
that
the
user
sent
then
there's
a
schema,
validation
and
there's
a
phase
where
admission
gets
to
validate
the
final
object
before
it
is
persisted
to
SCD.
You
can
go
to
the
next
slide.
I'll
explain
those
in
more
detail.
C
So
mutation
is
where
an
admission
plugin
gets
a
chance
to
actually
change
the
resource
content
itself.
So
a
user
can
submit
an
object
and
say
I
want
to
run
image
foo,
but
at
a
mission
plugin
come
in
and
say
no,
you
don't
really
mean
foo,
you
mean
something
else.
It
can
add
labels
annotations.
It
can
change
the
resource
in
any
way
it
wants
during
mutation,
even
after
mutation
is
done,
there's
still
a
chance
for
oak.
Sorry,
yes,
there's
still
a
chance
for
validation.
C
Validation
is
a
spot
that
runs
after
all,
mutation
is
completed
and
it
gives
you
a
chance
to
enforce
the
invariance
for
an
API
resource.
So,
regardless
of
what
a
user
entered
or
the
schema
validation
says
or
what
has
been
mutated
by
an
admission
plug
in
a
validating
admission,
plugin
can
look
and
say
the
final
result
of
the
service
account
field
must
have
a
value
or
does
a
user
have
the
power
to
set
a
particular
field
to
a
particular
value
before
it
gets
persistent
into
sed?
These
invariants
can
be
really
useful.
Next
slide,
please.
C
So
why
webhooks
we
had
admission
for
quite
a
while.
It
was
all
done
in
tree
and
being
in
tree
really
restricted.
Its
utility
admit
that
installers
of
employment
mechanisms
were
unable
to
add
admission
plugins
into
an
api
server
without
recompiling.
It,
and
very
few
people
wanted
to
do
that
and
now
that
it's
a
web
hook
there's
a
lot
of
example,
uses
right.
You
could
do
things
like
inject
a
sidecar
container,
it's
something
that
sto
was
looking
at.
C
You
can
do
things
like
forcefully
resolve
image,
tags
shah's,
which
is
very
helpful
for
repeatability,
and
this
would
let
you
do
it
on
all
sorts
of
resources
that
contain
pod
specs,
and
it's
also
useful
for
things
like
complex
custom,
resource
validation.
Right,
if
you
want
to
be
able
to
say
this
field
can
only
be
said
if
this
other
field
is
set
to
something
between
6
&
7,
so
I
have
a
brief
down
next.
That
shows
actually
wiring
this
together.
So
let's
go
ahead
and
do
that.
C
I've
thanks
I've
started
with
a
cluster
that
has
aggregation,
enabled
and
I'm
going
to
self
host.
My
admission
webhook
on
the
cluster
to
start
I'll
show
you
the
basic
resource,
manifest
it's
simple:
it's
got
a
daemon
set
that
runs
the
server
and
further
down
I
have
an
API
service
that
exposes
that
via
aggregation.
It
allows
me
to
use
the
in
cluster
authentication
and
authorization
to
secure
it,
and
it
allows
me
to
use
queue
control
to
test
whether
my
web
hook
is
behaving
the
way
I
expect
or
not
down.
C
Just
a
little
bit
further
I
have
the
validating
web
hook
configuration.
This
is
the
object,
that's
new
to
data
in
1:9.
It
has
a
stanza
that
describes
how
to
connect
to
your
web
hook
and
right
there,
and
then
it
has
a
bit
that
choosing
what
to
do.
If
the
connection
fails
and
the
server
can't
make
contact
in
this
case,
it
says
to
fail.
C
It
also
has
a
list
of
rules
for
when
to
make
a
call
out
to
the
web
hook,
and
this
one
says
call
the
web
hook
if
you're
going
to
create
a
namespace,
so
I
have
a
little
script.
That
has
some
glue
to
create
some
certificates
and
runs
apply
so
I'm
going
to
install
that
right
here
and
after
doing
this,
I
can
actually
test
my
web
hook
admission
using
Q
control,
so
I
have
an
API
object
that
exactly
matches
what
an
API
server
would
send.
C
I
can
use
Q
control
to
submit
this,
and
then
we
can
look
at
the
response
and
the
response
says
that
the
request
is
allowed
with
this
admission
server.
If
you
reserve
a
namespace
by
creating
a
particular
custom
resource,
it
will
prevent
the
request
from
succeeding.
So
I
am
going
to
create
the
custom
resource
that
reserves
it
and
now,
if
I
run
the
same
check,
we
ran
above
again
using
Q
control
to
test
my
webhook.
C
We
will
be
able
to
see
that
deads
is
reserved
and
the
request
overall
is
forbidden,
and
what
this
will
mean
is
that
when
the
API
server
runs
that
it'll
fail
now
I
said
this
was
all
secured
by
our
back.
If
we
actually
try
to
run
that
same
command
with
cute
controllers,
another
user
like
deads-
and
you
can
see
me
doing
it
right
here-
you'll
get
it
forbidden
error.
The
API
server
said
nope
you're
forbidden,
you
aren't
allowed
to
hit
the
web
hook
admission
server
in
order
to
grant
access
you
do
it
like
anything
else.
C
With
our
back
you're
gonna
create
a
cluster
rule
binding
granting
access
to
the
web
hook.
The
role
to
grant
access
was
created
when
I
ran
that
apply
a
while
back
and
so
I'm
going
to
add
deads.
And
now,
if
we
run
the
check
again,
we're
gonna
be
see
that
we're
loud
and
we
will
get
the
same
result
as
when
we
ran
it
with
cluster
admin.
So
we
gave
permission
using
our
back.
C
C
So
that's
how
you
can
wire
everything
up
using
a
self-hosted,
webhook
admission
server
you
get
in
cluster
security
for
free
and
it
works
with
no
config
from
the
cube
api
server
and
from
any
extension
API
server
that
you
want
to
connect
from.
So
we
can
jump
back
to
the
slides
and
I
have
a
picture
describing
what
we
actually
built
here.
So
you
can
see
that
we
have
a
client,
any
client
cube
controller.
Some
other
client
comes
in
as
the
user.
It
goes
to
the
kubernetes
api
server
and
the
api
server.
C
If
you
have
aggregation,
might
proxy
to
an
extinction
api
server
and
that
can
loop
back
using
a
service
account
credential
to
the
cube
api
server,
which
will
then
securely
proxy
to
the
web
book
admission
server.
And
what
this
allows
you
to
do
is
it
allows
you
to
identify
in
the
web
hook
admission
server.
C
What
api
server
is
contacting
you
and
decide
whether
it
has
access
or
not,
and
all
this
wiring,
all
the
credentials
that
are
used
can
be
done
automatically
and
safely
without
any
config
on
your
part
and
doesn't
require
any
credential
distribution
mechanism
and
it
will
work
on
any
api
server
that
supports
aggregation.
So
if
we
go
to
the
next
slide,
I
have
a
just
a
brief
summary
that
gives
you
the
benefits
right.
You
can
test
it
with
you
control
you
automatically
secure
it
with
our
Beck
rules
and
it
works
for
all
kinds
of
servers.
C
Other
topologies
are
possible
to
build,
but
when
you
build
them
need
to
be
be
careful
about
inventing
credential
distribution
mechanisms
they're
very
hard
to
maintain
the
biggest
fear
with
create
with
aggregating
API
server.
Is
it's
scary?
There's
a
of
options
and
people
get
very
concerned
about
it.
So,
on
the
next
slide,
I
have
I
hate
when
people
put
code
in
slides,
but
I
had
to
do
it
here,
because
this
is
the
code
that
you
need
to
create
your
own
admission.
Webhook,
it's
three
functions.
C
C
Is
it
going
to
be
it's
your
chance
for
a
thumbs-up,
thumbs-down
and
a
function
to
initialize
it,
and
so
this
is
all
built
in
a
couple
libraries
that
I
linked
in
its
there
such
an
Eric
admission,
server
library
which
is
built
on
the
cube,
API
server
library
and
then
a
full
working
example
that
you
saw
here
today
and
there's
some
stuff
lighting
up
at
the
bottom
here.
So
I
suspect
there
are
questions.
C
A
D
You
Igor
hi
everybody
next
slide,
please.
So
the
sick
windows
community
has
been
working
very
hard
for
close
to
two
years
now
in
basically
bringing
Windows
Server
to
the
entire
kubernetes
ecosystem.
But
essentially
our
goal
here
is
to
significantly
expand
deployment.
Ation
scenarios
and
enterprise
reach
of
kubernetes
Gartner
estimates
that
about
80%
of
enterprise
applications
today
still
run
on
Windows.
So
by
bringing
dotnet
and
Windows
based
applications
in
the
kubernetes.
D
It
allows
many
enterprises
that
have
adopted
a
hybrid
model
where
they
have
both
dotnet
Java
and
other
programming
languages
to
manage
all
of
them
in
a
cloud
native
way
using
kubernetes
that
enables
asp.net
dotnet,
core
iis
windows
services
and
many
more
applications
to
be
hosted
in
kubernetes
and
allowing
kubernetes
to
become
the
best
cross-platform
heterogeneous
cluster
manager.
All
of
that
work
obviously
would
not
be
possible
without
the
hard
effort
from
Microsoft
in
investments
into
Windows,
Server
containers,
continual
networking
and
other
features
that
enable
us
to
get
here
so
far.
Next
slide,
please.
D
From
a
timeline
perspective,
we
released
alpha
support
with
kubernetes
version
1.5
last
December,
and
then
one
year
later,
with
1.9,
we
released
better
support.
Alpha
support
was
mainly
great
for
proof-of-concept
projects
and
visualizing
the
roadmap
and
allowing
everybody
to
understand
where
we're
going
with
Windows
containers
and
kubernetes.
Now
with
beta
and
our
continuous
feature
and
functional
advancements,
both
in
kubernetes
as
well
as
in
Windows
Server
itself.
Now
you
can
take
advantage
of
that
work
and
you
can
have
production
level
workloads
running
a
Windows
server
with
kubernetes.
D
Our
goal
is
to
go
to
general
availability
sometime
later
this
year,
probably
towards
the
end
of
the
first
half
of
2018
next
slide.
Please
now,
from
a
feature
perspective,
we're
very
excited
about
the
set
of
features
were
bringing
into
the
community.
With
this
release,
we
have
improved
support
for
pods
in
the
past.
You
could
only
run
one
single
container
per
pod
and
now
done
a
lot
of
work
both
in
Windows
Server
and
in
the
containers
perspective,
so
that
you
can
have
a
part
that
can
share
the
network
namespace
using
networking
compartments
with
multiple
containers.
D
This
kind
of
brings
the
feature
of
a
pod
in
parity
between
Windows,
Server
and
Linux.
Based
containers
will
also
reduce
the
networking
complexity
by
using
a
single,
Network
and
point
per
pod.
Who've
moved
the
load
balancing
from
user
mode
to
kernel,
based
using
their
virtual
filtering
platform,
called
vfp.
That's
using
the
hyper-v
switch
expansion.
I've
done
work
to
incorporate
CRI,
pardon
note
level
statistics.
So
that
means
now.
You
can
get
profile
data
out
of
your
windows,
server
containers
and
you
can
use
the
horizontal
pod,
auto
scaling
to
auto
scale.
D
Your
containers
using
these
performance
metrics,
whether
its
support
for
cube
ATM.
So
if
you're
using
humidity
m
to
simplify
the
provisioning
of
your
entire
kubernetes
cluster,
now
it
has
a
port
for
Windows
Server
and
you
can
use
a
single
tool
to
deploy
your
kubernetes
infrastructure
and,
last
but
not
least,
to
add
a
support
for
config
back
config
Maps
secrets
as
well
as
volumes.
These
are
key
features
that
allow
you
to
separate,
in
some
cases,
secure
the
configuration
of
your
containers
across
different
kubernetes
clusters.
D
Next
slide,
please,
but
one
of
the
biggest
features
that
we've
had
in
this
release
and
the
reason
why
we're
in
bed
is
the
networking
enhancements
and
the
cni
plugins
that
you've
brought
into
the
community
who
have
an
upstream
l3
routing
plugin.
You
have
the
host
gateway
with
IP
route
configured
on
each
host,
and
then
we
have
the
open,
V
switch
and
open
virtual
network
also
called
ovn
OVS
with
overlay.
D
There's
a
process
city
and
the
genève
tunneling
types
and
there's
a
lot
more
network,
plugins
and
enhancements
are
under
development
and
we'll
be
able
to
bring
them
to
the
community
within
the
next
few
months.
Some
of
those
includes
include
the
win
overlay
that
will
enable
the
exelon
and
IP
IP
encapsulation
with
flannel.
We
will
have
a
Windows
L
to
bridge
or
host
gateway,
C
and
either
will
come
out
and
will
also
have
ovn
using
cloud
networking
without
overlays.
That
will
also
be
released
fairly
soon.
Next
slide,
please.
D
So
in
the
last
few
months
probably
lived
over
a
year,
we've
been
very
busy.
As
you
can
see
here.
This
is
a
fairly
busy
slide,
so
you
can
see
a
different
point
of
intervals.
Different
features
are
brought
in
from
the
CRI
to
config
maps
and
secrets
to
the
cni
plugins,
and
the
community
is
working
very
hard
in
continuing
down
this
path.
Continuing
to
improve
our
support
for
Windows
are
the
more
CNI
plugins
to
deliver
customers
choice
and
allow
them
to
have
a
unified
networking
configuration
and
infrastructure
between
Linux
based
containers
and
Windows.
D
Server
containers
will
also
add
support
in
the
future
for
hyper-v
isolation,
stateful
same
functionality
as
well
as
support
for
kubernetes
network
policies
in
ovm.
Kubernetes
next
slide.
Please
now
what
I
want
to
do
is
I
want
to
show
you
guys
a
little
bit
them
on.
Show
you
a
little
bit
of
a
V&O
vs
on
Windows
config,
my
secrets
and
routing
a
load
balancing.
D
D
This
particular
architecture
has
a
lot
of
advantages.
You
know
you
get
distributed
firewall
in
you
get
the
cross
Cloud
communication
using
genève.
You
can
get
low
balance
in
north-south
and
east-west
for
on-prem
environments
as
well
as
distribute
DNS.
So
let's
go
ahead
and
look
at
that
I'll
go
ahead
and
share
my
screen
here.
D
So
I
do
have
an
environment
here
with
multiple
types
of
operating
systems.
So
let's
go
ahead
and
get
our
pots
here.
So
I
have
a
few
pots
already
deployed.
I
have
guests
book,
I
have
an
Apache,
is
and
nginx
pod
and
have
some
readies
notes
as
well,
and
these
are
split
into
two
services.
One
of
them
is
called
the
Apache
service
and
the
other
one
is
called
gas
book.
So,
let's
look
at
gas
book
here
for
a
second,
so
notice
here
that
my
class
stripeys
dot
nine
dot
202.
D
So
if
we
come
over
here,
the
guest
book
is
up
and
running
and
I
can
click
on
environment
and
a
couple
of
things
that
are
noticeable
is
I.
Have
my
two
config
maps
here,
hello,
I
think
is
glad
to
be
here
and
then
we
also
have
a
secret
here
as
well,
so
not
not
very
valuable
secret.
This
is
just
a
secret,
but
we
can
show
you
guys
here
that
we
have
both
config
maps
and
secrets
running,
so
you
can
take
advantage
of
them
in
Windows
Server
containers.
D
So
we
have
secret
and
config
map
de
that
that
it
find
earlier,
and
then
our
part
specification
is
very
similar
to
what
you
see
in
Linux,
with
the
only
difference
is
that
it's
targeting
the
operating
system
to
be
Windows
Server
in
the
labels.
So
if
you
look
at
the
node
selected,
then
it's
targeting
Windows
and
that's
what's
telling
kubernetes
to
go
ahead
and
apply
this
to
a
Windows
environment.
D
I
also
have
one
more
service
here
and
that's
my
Apache
service
and
that
service
has
deployed
three
pods
and
nginx
pod,
an
IAS
pod
and
an
Apache
pod,
and
if
I
open
it
up
here,
I
can
see
that
if
I
hit
the
IP
address
for
my
service
I
get
I
is,
if
I
refresh
it
again:
I
get
Apache
and
and
so
on
and
so
forth.
So
I
went
ahead
and
created
a
simple
partial
script
here
that
will
make
20
calls
against
that
exact
IP
address.
Let
me
know
what
kind
of
results
it
gets.
D
So
you
can
see
here
our
load,
balancing
across
the
different
endpoints
and
the
different
pods
that
are
part
of
the
service
and
who
have
nginx,
iis
and
Apache.
All
routing
against
the
same
service,
so
this
was
a
short
demo.
I
wanted
to
give
you
guys
a
little
bit
of
a
brief
sneak
peek
into
what's
possible,
with
Windows
Server
containers,
I'm,
hoping
that
you
guys
can
come
and
join
us
in
the
cygwin
DOS
slack
channel
post
questions.
D
A
Thank
you
Michael,
so
the
next.
The
next
feature
is
not
a
single
feature.
It's
the
group
of
features
under
the
single
umbrella
and,
if
you
remember
the
beginning
for
the
webinar
mentioned
that
some
of
the
features
are
finally
being
presented
to
the
GA
stage
stable
stage
and
the
next
group
of
features
is
actually
a
group
of
features
status.
Finally,
stable
in
cabinet
is
1.9.
This
window
can
go,
will
describe
the
workload
yeah
give.
It
is
startin
forgiving.
It
is
wonderful,
hi.
E
I'm
Ken
Owens,
a
software
engineer
at
Google
and
co-lead
of
the
cig,
apps
slight,
listen
so
in
the
beginning
of
kubernetes
pods
were
pretty
much
all
we
had
it's.
Basically
a
small
group
of
containers
and
volumes.
I'm,
pretty
sure
most
of
you
in
the
audience
are
familiar
with.
What
is
the
picture
of
her
on?
The
right
is
basically
the
most
basic
pod
you
can
have.
That
has
two
containers.
E
Well,
pods
weren't,
really
enough
for
most
users,
I
mean
honestly
manually,
creating
a
ton
of
pods
individually,
probably
isn't
what
you'd
want
to
do?
We
really
wanted
to
be
able
to
seamlessly
and
reproducibly
create
many
pods
that
are
identical.
So
then
we
developed
the
replication
controller.
Replication
controller
does
precisely
that
it
creates
and
I've
done
a
identical
pod.
So
these
pods
are
fungible,
meaning
creation
for
these
pods
doesn't
have
any
implied
order
and
the
pods
don't
have
any
actual
identity.
In
fact,
the
identity
is
a
random,
well
hash.
E
E
So,
as
we
were
talking
about
previously,
what
users
really
wanted
to
do
is
to
be
able
to
orchestrate
those
pods,
so
they
wanted
to
be
able
to
do
things
like
have
sequential
rollouts
have
blue/green
rollouts
roll
back
to
a
previously
known,
a
good
version
or
potentially
roll
forward,
which
would
be
like
a
rollover.
So
we
develop
deployment.
E
Config
from
OpenShift
and
got
up
streamed
into
main
kubernetes
now
by
the
time
deployment
came
out
and
extensions
of
e
1
beta
1,
the
only
two
v1
API
objects
you
had
for
work,
replication,
controller
and
pod,
and
at
this
point
we
didn't
actually
recommend
using
replication
controller.
We
recommended
using
deployments
and
replica
sets
and
replica
sets
only
as
an
implementation
detail
of
deployment.
E
E
So
about
this
time,
people
want
the
same
type
of
features
for
deployments
and
they're
stateless,
like
twelve
factor
apps
for
cluster
add-ons
and
local
shared
side
cards
data
nodes
for
distributed
file
systems,
and
they
wanted
the
same
type
of
seamless
role
in
updates,
roll
backs
and
rollovers
as
you
get
with
the
Plymouth.
So
he
came
up
with
daemon
said
a
demon
said
is
basically
what
you
use
when,
instead
of
money
in
exactly
n
replicas
of
a
pod
or
about
an
M
replicas
of
a
pod,
you
want
to
attach
a
pod
to
a
particular
node
anytime.
E
The
node
enters
a
cluster.
By
the
time
demon
said
it
came
out.
We
had
also
added
that
two
extensions
people
and
bata
wanted
an
elevated
to
beta
fairly
rapidly.
But
again
it
still
wasn't
GA
slide,
please
so.
Lastly,
we
wanted
to
be
able
to
orchestrate
stateful
applications,
in
particular
things
like
relational
database
management
systems,
distributed
key-value
stores,
message
queues
like
rabbit
distributed,
log,
structured
storage
like
Kafka,
key
value,
storage
like
Etsy,
D
and
zookeeper.
E
These
types
applications
requiring
a
different
set
of
semantics
than
were
generally
available
with
replicas
sensor
deployments.
We
needed
a
stable
network
address
in
a
lot
of
cases.
The
pods
had
identities
that
needed
to
survive
restart
and
they
needed
stable
storage
like
they
needed
a
durable,
PvE
or
PVC
that
got
attached
to
the
pot
and
would
get
reattach
anytime.
You
restarted
the
mod,
so
we
came
up
with
staple
sense
slide,
so
we
were
done
right
like
we
could,
orchestrate
all
the
things
we
were
ready
to.
E
There
are
many
inconsistencies
in
terms
of
like
what
rolling
update
looked
like
what
the
statuses
looked
like
and
primarily
the
issue
is
everything
is
beta
and,
like
honestly
speaking
in
kubernetes,
things
can
maintain
beta
level
of
stability
for
a
long
period
of
time,
and
it
doesn't
mean
you
shouldn't
use
them.
It
doesn't
mean
that
they're
not
stable
enough
to
use
in
a
production
environment.
In
all
cases,
but
many
people
aren't
going
to
be
comfortable
using
something
that's
beta
in
a
prime
environment
and
honestly
people
want
to
be
able
to
build
against
a
stable
API.
E
E
The
reason
we
primarily
did
this
was
to
allow
us
to
break
things
in
a
backward
incompatible
way,
so
that
we
could
fix
things
that
we
knew
were
deficient
with
the
API
prior
to
taking
it
that
yet
some
of
the
bigger
things
is
select
or
defaulting
I,
don't
know
if
people
remember
this
or
aware
of
it.
But
previously,
if
you
created
it
a
deploy,
man,
you
didn't
give
it
a
selector.
It
would
generate
a
selector
based
upon
the
labels
that
are
associated
with
the
pod.
E
This
caused
no
end
of
havoc,
which
could
be
kind
of
apply
in
general.
We
found
that
defaulting.
The
value
of
any
field
in
the
object
off
of
another
feel
is
pretty
much
an
anti-pattern,
but
Ruby
Caudill
apply,
so
we
got
rid
of
that
immutable.
Selectors
is
another
big
one.
If
you're
coming
from
an
existing
well
like
an
extension
to
be
1,
beta,
1
or
apps
B
1
beta
2,
beta
1,
you
can
change
the
selector
on
one
of
these
worklet
api
objects,
which
will
modify
the
pods
that
are
selected
and
controlled
by
that
controller.
E
Well,
we
cleaned
up
the
status
as
the
objects
a
little
bit
and
we
added
status
conditions
to
staple
said
and
demon
said,
even
though
we're
not
populating
them
right
now.
We
think
that
in
the
future,
conditions
might
be
a
way
to
communicate.
Other
interesting
events
about
demon
sets
and
staple
sets
to
well
users
and
various
api's.
We
got
rid
of
the
created
by
annotation
in
favor
of
controller
ref,
created
by
kind
of
existed
prior
to
garbage
collection
in
kubernetes.
E
So
after
we
added
a
full
garbage
collector,
we
had
controller
ref
and
owner
references
across
the
API.
There
really
wasn't
a
need
to
created
by
anymore,
and
it
didn't
have
any
really
valid
semantics.
We
added
scale
sub
resources
across
the
board,
so
there's
a
uniform
scaling
with
the
exception
of
daemon
set,
which
again
generally
daemon,
says,
create
pods
when
you
get
a
new
node
and
they
don't
create
pods
based
on
some
scale
that
you
provided
them.
E
We
did
not
enable
HPA
for
staple
set
yet,
which
is
a
feature
that
we're
where
people
are
interested
in,
but
databases
don't
tend
to
scale
in
the
same
way
that
serving
workloads
do
so
until
we
get
custom
metrics
solid,
we
don't.
We
didn't
see
a
lot
of
value
in
enabling
for
a
zonal,
pod,
auto
scaling
for
staple
sets.
Garbage
collection
is
now
defaulted
delete
and
the
primary
difference
there
is
currently
the
default
is
orphan.
You
would,
if
you
use,
could
be
coddled
to
delete
things.
E
You
wouldn't
actually
notice
as
it's
only
if
you
call
against
the
API
directly,
you
would
see
this
behavior
well,
what
happened
is
when
you
delete
a
staple
set
upon
in
the
staple
set
wouldn't
be
deleted
by
default.
We
implemented
a
Reaper
inside
of,
could
be
coddled
to
implement
the
delete
semantics
by
default
and
could
be
cuddle,
but
we
were
able
to
move
this
server
side,
so
we
can
get
rid
of
all
that
functionality
and
additional
complexity
and
critical
in
1.9.
E
E
E
E
There's
a
v2
at
some
point
and
then
sometime
in
the
very
far
future
after
that
v2
is
released.
Maybe
we
would
consider
deprecating
it,
but
as
it
is,
this
is
the
final
API
and
you
can
start
building
against
it.
In
fact,
all
new
codes
should
go
against
this
API
for
existing
code.
Now
we're
sensitive
to
the
fact
that
we
told
people
to
go
out
and
use
deployment
use
diamond
set.
In
fact
we
used
it
for
our
own
cluster
add-ons.
E
Do
the
migration,
as
you
see,
fit
they're
bi-directional
conversions
implemented
for
all
API
versions
to
be
one.
So
if
you
go
to
use
the
v1
API,
it
should
not
break
any
of
your
existing
API
objects.
It's
just
a
in
effect,
put
your
code
from
one
endpoint
to
another
way
and
believe
that
everything
are
there.
Any
questions.
A
A
A
A
A
D
Was
one
more
question
that
was
already
answered?
You
know.
That's
you
know
around.
You
know.
One
of
the
things
I
showed
in
my
AMA
file
is
designating
the
node
selector
that
it's
windows.
So
if
you
have
a
hybrid
environment,
Linux
and
Windows,
some
some
folks
are
going
to
obviously
have
a
concerns
about.
Do.
I
have
to
go
change
all
my
previous
Yama
files
for
my
previous
deployment,
so
some
of
that
can
be
changed
through
with
environment
configuration
in
the
scheduler
and
some
of
the
other
problems
we're
gonna
have
to
solve
in
sick
windows.
A
A
We
also
have
yet
another
question:
it's
not
really
related
to
our
today's
topic,
but
it's
did
you
know
when
integration
again
Yin?
What
is
the
best
GUI
to
deploy
manage
thoughts?
I
cannot
command
to
try
a
Cuban
at
his
dashboard.
Officially
than
it
is
project
management
is
coasters
alright.
So
if
we
don't
have
any
other
questions,
thank
you.
Everyone
for
joining
us
two
days
until
our
presenters
for
sharing
your
knowledge
cloud
in
the
features
for
1.9
and
hope
to
see
you
all
of
you
at
our
next
webinars.