►
From YouTube: Webinar: What's New in Kubernetes 1.13
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
This release continues to focus on stability and extensibility of Kubernetes with three major features graduating to general availability this cycle in the areas of Storage and Cluster Lifecycle. Notable features graduating in this release include: simplified cluster management with kubeadm, Container Storage Interface (CSI), and CoreDNS as the default DNS.
These stable graduations are an important milestone for users and operators in terms of setting support expectations. In addition, there’s a continual and steady stream of internal improvements and new alpha features that are made available to the community in this release.
Join members of the 1.13 release team to discuss the newest features in this release.
A
All
right
we're
gonna,
go
ahead
and
get
started.
Welcome
to
today's
C&C
f
webinar!
What's
new
in
kubernetes
1.13
I'd
like
to
thank
everybody
who
is
joining
us
today,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee
there.
However,
there
is
a
QA
box
at
the
bottom
of
your
screen,
so
please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can
towards
the
end.
A
So
today
we
are
gonna,
be
looking
at.
What's
new
in
kubernetes
1.13,
we
got
a
few
people
here
on
the
panel
aside,
myself,
ginger
Coleman
I'm,
the
1.13
enhancements
lead
coming
from
VMware
saw
Dali
gonna,
take
care
of
storage
she's
coming
from
Google
Caitlin's
with
us.
She
was
the
1.13
communications
lead.
Then
we
also
have
Tim
st.
Clair
pep
teo
as
well
as
vmware
now
as
well.
So
one
of
the
few
things
that
we
want
to
get
to
on
our
agenda
today
is
is
looking
at
the
enhancements
overview.
A
As
I
mentioned,
storage
updates
cube
idiom,
and
if
you
have
those
questions,
make
sure
you
use
your
Q&A
button
towards
the
bottom.
So
the
1.13
enhancements
we're
gonna
talk
first
on
some
major
themes
of
really
what
we
saw
in
113.
It
was
a
really
a
big
focus
on
stability.
113
release
cycle
was,
and
it
was
reduced
from
a
typical
12
to
13
weeks
down
to
10,
and
this
is
because
there
was
the
u.s.
A
holidays
as
well
as
2q
cons
that
were
there
in
the
middle
and
with
that
we
had
to
be
able
to
create
something
that
was
able
to
get
something
out
the
door
in
a
reasonable
amount
of
time.
In
addition,
to
make
sure
that
we
were
able
to
achieve
a
lot
of
the
releases
was
to
remove
some
of
these
lofty
goals
in
regards
of
anything
that
was
huge
to
be
able
to
put
in
there.
A
This
also
did
require
extensive
communication,
and
this
was
coming
from
the
release
leads
and
then
going
into
each
of
the
individual
SIG's
themselves
and
having
a
communication
dialogue
saying
this
is
what
was
to
be
expected,
and
this
is
what's
gonna
happen
at
the
same
time
being
able
to
look
at
what
features
or
enhancements
were
being
developed
into
that
particular
cig
and
seeing
sort
of
what
the
status
was
and
making
that
happen.
Now.
A
Another
major
theme
that
you're
going
to
be
seeing
as
as
criminalities
continues
to
advance
is
continuing
to
Devender
the
central
code,
and
this
is
actually
removing
a
lot
of
the
vendor
code.
That's
related
to
individual
vendors
that
are
out
there
and
extend
instead
actually
make
that
more
extensible.
So
you're
gonna
see
a
lot
of
things
that
are
new,
as
well
as
things
that
have
been
graduated,
to
allow
vendors
to
be
able
to
start
plugging
into
particular
interfaces
instead
of
actually
having
being
baked
into
the
core
of
kubernetes
itself.
A
So
just
an
overview
of
what
it
looked
like
in
regards
of
what
features
or
sorry
enhancements
were
added.
You
have
nine
that
came
in
as
alpha
what
were
net
new.
There
were
eight
that
were
graduated
to
a
beta
classification,
meaning
they
had
graduated
from
alpha
to
beta,
and
there
were
six
that
had
graduated
from
a
beta
to
a
stable
classification
as
well
so
23
new
enhancements,
and
since
we
did
have
this
aggressive
timeline
of
getting
this
release
out
the
door,
you
can
see
that
there
are
actually
25
enhancements
that
were
removed.
A
Greater
than
50%
of
the
enhancements
that
were
originally
attract
were
deferred,
and
you
can
start
seeing
expect
to
see
some
of
those
start
hitting
in
the
1.14
release.
So
let's
go
over
some
of
the
highlights.
What
were
the
major
key
themes
or
the
major
updates
that
we
really
look
at,
especially
when
it
comes
to
things
that
are
gonna
touch
a
wide
range
of
users
out
here
and
when
we
talk
about
this,
a
lot
of
these
are
gonna,
be
focused
on
things
that
hit
g8
or
stable.
First
is
cube.
Atm
I'm,
not
gonna.
A
The
other
is
core.
Dns
is
now
the
default
DNS
plugin.
This
was
actually
first
introduced
in
tacuba
days
in
1.11
as
an
option,
but
slipped
from
being
a
default
in
1.12,
because
it
was
failing
some
scalability
testing.
Just
for
some
background.
One
of
the
tests
ran
during
a
sig
relief
process.
Is
that
there's
a
5,000
test,
and
since
that
wasn't
passing,
we
had
to
be
able
to
defer
that,
but
it
came
in
from
113
core
DNS.
If
you
are
unaware,
it
is
a
CNC
F
project.
A
It
currently
has
over
3,000
github
stars
over
114
contributors,
and
it
has
some
unique
features
such
as
being
able
to
listen
to
DNS
requests
over
G
RPC,
the
DNS
role
with
inside
of
kubernetes.
It
is
to
actually
do
internal
name
resolution
between
nodes
and
pods.
Core
DNS
has
a
few
other
benefits
to
it
as
well.
It
has
a
few
removing
pieces
than
its
predecessor,
which
was
cubed
DNS.
A
It's
also
a
single
executable
and
a
single
process,
and
one
thing
that
I
would
imagine
everybody
loves
to
hear
that
it
is
written
and
go
so
with
it
that
it
says
that
it's
also
memory
safe.
It
also
supports
some
more
use
cases.
So,
if
you
want
to
add
custom,
DNS
entries
stub
domain
support
that
you
want
to
serve
DNS
based
on
label,
selectors,
wildcard
queries
and,
more
so
looking
forward
to
seeing
a
lot
more
use
out
of
core
DNS
going
forward
as
I
mentioned.
A
Extensibility
is
one
of
those
key
pieces
that
are
coming
in
here
as
well,
and
this
is
really
looking
at
the
cubelet
and
the
cubelet
needs
a
standard
way
to
discover
local
plugins,
whether
it's
for
CSI,
CNI,
GPU,
etc.
This
is
going
to
change
the
current
process,
which
had
originally
registered
to
the
cubelet
through
G
RPC
and
had
a
new
module,
and
now
what
we
have
is
we
actually
have
a
new
module.
A
B
Kendrick
so
CSI
to
set
the
stage.
This
is
the
culmination
of
a
year's
worth
of
work.
Csi
was
first
introduced
in
kubernetes
in
the
1.9
release
in
the
q4
of
2018,
and
this
last
quarter
in
December
and
it's
part
of
1.13.
It
finally
became
GA
to
set
the
context
for
what
it
is
and
why
it's
important,
you're,
all
probably
familiar
with
the
kubernetes
volume
plug-in
layer,
which
provides
a
very,
very
powerful
abstraction
for
both
file
and
block
it.
B
The
project
evolved
out
of
a
cooperation
with
other
orchestrators
in
the
ecosystem
and
has
broad
industry
support
amongst
storage
vendors,
and
it
actually
ends
up
making
kubernetes
the
kubernetes
volume
layer
truly
extensible.
There
are
over
20
volumes
that
are
currently
available
to
use
and
we're
gonna
see
more
and
more
as
we
continue.
A
Thank
You
Saad
now
another
one
that
I
want
to
be
able
to
bring
up,
because
it's
always
a
hot
topic
is
where
is
windows,
containers
support,
windows,
container
support
was
actually
on
track
and
was
being
watched
pretty
pretty
closely
with
inside
of
113.
It's
it's
good
to
know
exactly
sort
of
where
this
is
with
inside
the
ecosystem
and
where
the
community
really
feels
where
it
is
as
well.
A
So,
during
this
process
there
was
a
meeting
between
cigar,
CH
and
cig
windows
to
really
look
at
the
current
status
and,
however,
it
was
determined
that
it
just
wasn't
ready
to
graduate
to
a
ga
or
a
stable
release
at
this
point.
So
there
is
a
never
request
and
a
formal
cap
has
to
be
filed
if
you're
unfamiliar
with
what
the
camp
process
is.
It's
the
kubernetes
enhancement
proposal.
A
You
can
read
more
about
it
with
inside
of
the
kubernetes
/
enhancements
of
repo
and
from
there
if
I
kept
needs
to
be
a
tied
to
ever
enhancement
going
into
kubernetes
going
forward.
So
this
is
to
make
sure
that
there
is
an
expectation
of
what
will
and
what
won't
be
supported
when
it
comes
to
this
particular
enhancement.
In
addition,
it
also
gives
the
ability
to
have
a
community
consensus
of
everything
going
forward,
so
we're
going
to
look
into
individual
SIG's
and
what
their
enhancements
were
as
we
go
forward
here.
A
So
the
first
one
we
look
at
is
API
machinery,
so
the
API
server
drive
run
graduated
to
beta,
and
this
is
a
feature
that's
been
implemented
with
inside
of
the
API
server
in
itself.
It
sends
requests
by
specifying
a
dry
run
flag,
and
that
is
gonna
put
a
query
and
a
crud
call
to
see
what
would
or
what
could
have
happened.
So
everything's
gonna,
run
normal
except
for
storage,
wouldn't
be
modified.
Everything
else
would
work,
has
expected
admission
controllers
run
a
check
to
see
that
a
requester
is
valid.
A
Cr
DS
are
becoming
a
crucial
part
of
the
kubernetes
ecosystem,
especially
as
individual
vendors
figure
out
how
to
put
their
own
special
sauce
with
inside
of
kubernetes
and
their
own
deployments,
if
you're
unfamiliar,
just
a
resource
and
in
itself
there's
just
an
endpoint
in
the
communities
API
and
it
stores
a
collection
of
API
objects
that
could
be
of
a
certain
time.
So,
for
example,
the
pods
resource
is
just
a
collection
of
pot
objects.
A
A
custom
resource,
however,
is
an
extension
of
that
kubernetes
api
that
allows
that
doesn't
necessarily
mean
it's
available
on
every
communities
cluster,
but
represents
sort
of
customization.
Now
the
existing
problem
is
when
a
web
hook
needed
to
make
a
request
to
another
service,
but
now
the
api's
have
potentially
progressed
or
they've
changed
this
web
hook.
Conversion
allows
developers
to
evolve
their
API,
while
still
maintaining
backwards
can
pad
compatibility
of
those
versioned
API
resources.
A
So
this
allows
objects
or
services
to
hold
multiple
versions
and
at
the
same
time,
can
vert
a
web
hook
from
one
version
to
another.
Based
on
that
particular
need
at
CD
is
at
CD.
Two
has
now
dropped
from
humanities.
1.13
unfamiliar
at
CD.
Has
it's
actually
used
by
a
lot
of
different
components
with
inside
of
kubernetes?
This
could
be
from
the
API
server
all
the
way
down
to
individual
test
jobs
at
CD.
Two
was
the
loan
supported
back
in,
but
it
didn't
fit
all
the
required
use
cases
as
well
as
scale.
A
So
looking
forward
to
a
lot
of
things
that
people
can
come
up
with
at
CD
3
coming
for
the
future
here,
moving
on
the
cig
off
so
dynamic
audit
configuration
is
new
for
alpha.
You
know,
kubernetes
write
itself
already
has
auditing
built
into
it,
and
this
is
really
a
security
focused
mechanism
that
provides
a
set
of
records
that
document
activities
that
are
happen
or
from
being
performed
in
the
system.
This
could
be
from
individual
users,
administrators
or
even
components
themselves,
and
it
allows
an
administrator
to
be
able
to
answer
the
questions
like
what
happened.
A
When
did
it
happen
or
who
did
it?
The
cube
API
saw
sorry.
The
cube
API
server
performs
that
auditing
and
before
each
request
executes
it
generates
an
event
and
has
written
to
the
backend.
Now
the
dynamic
portion
of
this
is
to
allow
advanced
auditing
features
to
be
dynamic.
Configured
after
the
cluster
has
been
provisioned
now.
A
The
reason
this
is
needed
is
because
it's
difficult
to
accomplish,
since
the
configuration
typically
requires
some
sort
of
insight
into
the
deployment
mechanism
of
choice,
and
you
also
need
to
install
more
tools
that
are
needed
for
future
knowledge
of
actually
how
to
reach
them
when
the
cluster
is
live.
So
this
can
be
used
for
particular
use
cases
where
a
cluster
admin
might
want
to
enable
an
internal
audit
trail
or
configure
multiple
audit
policies
to
provide
independent
auditing
during
the
provisioning
aspect
in
itself.
A
Now,
six
CLI
has
a
few
different,
interesting
components
than
themselves.
The
cube
cuttle
diff
is
now
graduated
to
beta.
So
as
a
you
as
a
user
in
itself,
this
will
be
great
use
because
different
object
configurations
may
exist
for
the
same
object
and
a
cubed
at
ease
cluster.
So
here's
a
particular
kind
of
workflow
about
how
this
would
work
so
say,
you're
running
and
apply
on
a
local
object
configuration
it's
going
to
result
in
a
live
object
on
the
cluster,
that's
being
created
or
updated.
A
Now
the
local
object
configuration
is
saved
as
what's
considered
the
last
applied
object.
Next
you're
going
to
update
the
live,
object,
configuration
from
a
local
object,
configuration
in
a
new
merged
configuration
and
now
that
becomes
the
new
live
object
configuration
now.
If
you
didn't
catch
all
that,
it
essentially
allows
you
to
run
a
diff
on
a
running
object
versus
one
that
you
would
say
in
baseball.
Terminologies
have
one
in
the
bulb
in
the
plugin
mechanism.
A
Queue
cuttle
is
really
getting
to
more
extensibility,
allowing
even
greater
use
of
kubernetes,
but
now
unifying
it
on
the
CLI
in
itself.
So
you
could
say
you
could
build
a
plugin
that
would
interface
with
individual
API
calls
of
an
object
outside
of
kubernetes,
basically
you're
building
a
shim
that
hits
a
golang
interface
and
performs
varying
functions.
So
we
can
put
functionality
for
individual
opponents
to
the
cube
cuttle
command-line.
Just
at
an
example.
Think
of
something
like
extensions
for
storage
integrations
that
you
want
to
manage
it
remotely.
A
You
could
create
a
query
that
examines
remaining
storage
available
on
a
device
before
attempting
to
create
a
new
persistent
volume.
So
there's
lots
of
options
here
that
you
can
build
a
lot
of
nice
integrations
and
even
extend
kubernetes
even
further,
so
moving
into
sig
node.
Now
this
is
again
falling
into
more
extensibility
there's
a
whole
ecosystem.
That's
built
around
performance
management
and
monitoring
and
even
device
monitoring
itself
typically
used
to
require
external
agents
because
they
had
to
determine
what
devices
are
in
use
by
those
containers.
A
So
some
types
of
these
could
include
container
logging
exporters
like
Flo,
Indy,
akan,
to
container
monitoring
agents
like
see
adviser
and
even
device
monitoring,
plugins
like
from
Nvidia
with
their
GPU
monitoring
plug-in.
Now
each
of
these
agents
faces
a
similar
problem.
If
you
get
a
metric
or
a
log
associate
with
container,
how
can
this
information
with
metadata
be
filtered
by
name
space,
pod
container
or
whatever?
So
the
goal
is
to
remove
device
specific
knowledge
from
the
cubelet
and
requiring
that
to
become
out
of
tree.
A
So
as
a
cluster
admin,
I
know
that
every
device
is
pulling
data
from
a
particular
agent,
but
in
doing
so,
I
can
do
it
in
a
compatible
fashion.
That
doesn't
require,
like
a
myriad
of
implementations
so
now
device
vendors
can
provide
tools
that
live
out
a
tree
and
again
living
with
the
theme
of
extensibility
they're,
not
gated
by
the
kubernetes
release
cycle.
A
Now.
Moving
frequent
heartbeats
from
the
cubelet
to
the
lease
API
is
a
new
alpha
feature.
This
is
necessary
for
Milly
er.
No,
two
heartbeats
are
necessary
for
a
functioning
kubernetes.
Cluster
scalability
testing
had
discovered
that
clusters
with
more
than
2,000
nodes
that
have
a
small
number
of
images
that
are
used
by
pods
on
varying
nodes
or
hitting
some
SED
limits
for
database
size,
and
when
that
happens,
that
means
at
CD
stops
accepting
those
right
requests
to
give
you
some
sort
of
idea.
A
Note
heartbeats
can
be
potentially
large
objects
somewhere
around
15
kilobytes
in
size
and
they're
done
every
10
seconds
and
that
doesn't
even
include
the
node
status
updates
and
that
can
result
and
nodes
being
marked
is
not
ready.
This
new
implementation
reduces
the
size
of
heartbeats
by
using,
what's
called
a
lease
object
and
the
leader
election
object
uses
the
micro
time
go
package
as
the
initial
record
to
become
the
node
heartbeat
and
now
each
node
will
actually
have
to
correspond
to
the
least
object
in
a
dedicated
namespace.
A
The
lease
object
in
itself
is
gonna,
be
updated
every
10
seconds
and
it's
gonna
reduce
the
frequency
of
notes,
thatis
updates
to
40
seconds.
Moving
on
to
cig
scheduling
tape.
Base
eviction
has
been
around
for
a
while
I'm
sorry,
tape-based
sartet
ting
notes
has
been
around
for
a
while
paint
based
evictions
actually
graduating
to
beta
and,
if
you're
unfamiliar
with
what
painting
nodes
is
in
kubernetes.
It's
something
that
in
maybe
in
other
terminology
in
other
realms.
A
Maybe
it's
considered
like
anti
affinity.
It
ultimately
means
that
we
want
to
restrict,
or
we
want
to
prefer,
to
restrict
some
certain
workloads
from
being
scheduled
to
specific
nodes.
Now
paint
based
eviction
really
builds
upon
this,
because
it's
enacting
rules
automatically
and
it
will
immediately
evict
those
workloads,
especially
if
there's
a
node
state
change.
That's
gonna
be
happening
so,
for
instance,
if
a
node
is
sensing,
a
network
or
memory
pressure,
and
then
a
taint
is
added
to
that
particular
node.
A
A
Races
excited
conditions
that
you
can
actually
put
on
them
as
well,
so
the
scheduler
checking
for
feasibility
scores
and
a
subset
of
all
cluster
nodes.
Now
that
sounds
like
a
lot.
This
is
actually
moving
to
beta,
but
it's
an
enhancement
to
the
schedule.
Algorithm
and
maybe
it'll
go
unnoticed
unless
you're
running
lots
of
pods
with
inside
of
your
clusters,
or
maybe
you're,
hitting
some
performance
issues
that
require
something
down
to
maybe
that
millisecond.
But
what
used
to
happen
is
the
cube.
A
Scheduler
looks
at
all
the
available
nodes
in
a
cluster
for
every
pod
and
every
scheduling
attempt.
Then
it's
going
to
score
them
to
determine
the
placement
now,
even
though
it
may
have
the
highest
score.
It
may
not
be
the
best
note
to
use
so
this
new
feature
is
gonna,
find
feasible
nodes
in
a
cluster
first
and
then
it's
gonna
pass
those
in
for
scoring
it's
gonna
bypass
ones
that
are
beyond
the
threshold
of
needing
to
be
scored.
B
So
when
the
when
a
pod
ends
up
using
that
PBC,
the
scheduler
tries
to
find
a
home
for
that
pod,
the
it
tries
to
find
a
node
that
is
in
the
same
topological
segment
as
the
volume,
and
it
may
be
that
there
are
no
available
resources
in
that
segment
and
therefore
the
pod
remains
unscheduled.
With
this
feature,
there
is
a
new
volume,
binding
mode
called
wait
for
consumer
which
delays
the
binding
are
the
provisioning
of
the
volume.
B
So
when
you
create
the
pvc
object
with
this
new
volume
mode
instead
of
provisioning
right
away,
it
will
wait
for
a
pod
to
reference
the
PVC,
and
when
that
happens,
the
scheduler
will
make
basically
influence
where
the
volume
is
going
to
be
provisioned
by
taking
into
account
what
other
resources
are
available
on
the
cluster
and
that
information
is
passed
along
the
volume
again
to
intelligently
schedule,
a
provision,
a
volume
next
slide.
The
second
feature
we
have
is
Rob
lock
device.
B
This
is
moving
to
beta,
so
previously,
volume
plugins
only
supported
a
file,
which
means
that
you
could
have
a
directory
mounted
with
a
file
system
exposed
inside
of
your
container.
There
wasn't
really
an
ability
to
expose
a
raw
block
device
volume
device
into
your
container.
This
feature
was
added
in
as
alpha
a
few
releases
ago
and
has
finally
graduated
to
beta
and
is
supported
by
a
handful
of
entry
volume
plugins.
It's
also
supported
in
CSI
as
alpha,
but
basically
it
allows
a
raw
block
device
to
be
exposed
directly
inside
your
container.
B
So
if
you
have
you
know,
some
databases
are
optimized
to
use
raw
block
devices,
and
you
may
have
some
application
that,
for
some
reason,
prefers
to
access
block
directly
next
slide.
Finally,
we
have
a
feature
being
added
to
flex
volume.
Flex
volume
was
an
older
way
of
doing
external
volume,
plugins
it
predated
CSI.
B
That
said,
there
was
one
last
feature
that
folks,
who
have
been
working
on
flex
were
really
really
asking
for
which
was
the
ability
to
resize
a
volume,
the
ability
to
resize
a
volume
exists
for
the
entry
volume
plugins
and
is
being
added
for
CSI,
and
it
just
got
added
as
alpha
for
flex
so
keep
an
eye
out
for
that
and
I
believe
that
is
the
last
storage
feature
back
to
you.
Kendrick
awesome.
A
C
It
depends
upon
who
you
talk
to
a
lot
of
people,
say,
cube
ATM,
my
son
likes
to
say
kuba
Tim,
so
it
depends
upon
the
context
of
who
you're
talking
to
you
just
for
a
brief
synopsis
for
those
who
are
unfamiliar
with
cube
ATM
ku
medium
is
a
tool.
A
composable
tool
meant
to
stand
up
best
practices,
kubernetes
cluster,
we're
an
MVP
for
the
control
plane.
It's
meant
to
be
used,
the
user
experience
is
meant
to
be
simple.
C
It's
also
meant
to
be
limited
in
scope
and
composable,
so
we're
Canadian
stops
is
explicitly
at
the
control
plane.
It
does
not
do
sort
of
provisioning
at
the
cloud
provider
level
right
for
those
higher-level
tools.
There
are
other
technologies
that
allow
folks
to
use
that.
So
what
does
this
mean
for
Koob
ADM
to
graduate
to
stable?
C
The
first
and
foremost
aspect
is
having
a
stable
command
line
that
people
can
depend
upon
so
for
folks
who
are
building
higher-level
orchestration
tools,
whether
that
be
built
upon
a
number
of
sort
of
configuration
management-
tooling,
such
as
salts
or
you
know,
if
you
have
ansible
scripts
for
setting
up
your
environment
or
a
number
of
other
CM
tools
to
terraform,
you
can
depend
upon
the
CLI
and
the
semantics
with
inside
of
the
CLI.
So
we
will
follow
the
standard,
deprecation
policy
and
procedures
for
how
we
sort
of
modify
and
support
that
CLI.
C
Also,
we
we
will
support,
as
we
have
in
the
past,
but
we've
graduated
the
support
to
be
fully
functional,
and
so
folks
can
depend
upon
it
for
upgrades
between
minor
versions.
We've
always
done
this
for
a
period
of
time,
but
a
lot
of
folks
to
feel
at
ease
that
we
will
absolutely
guide
folks
through
the
the
life
cycle
of
upgrading
their
clusters.
Next
slide,
please
what's
really
interesting
about
kopitiam.
Is
that
we've
built
it
is
a
very
composable
layered
bottle.
So
there
are
pieces
of
Covidien
called
committee
m
phases.
C
The
phases
exist
underneath
the
init
sub-command.
Those
phases
can
be
executed
independently.
So
if
folks
had
a
higher
level
orchestration
or
they
wanted
to
custom
tailor
their
deployment
model,
they
I
could
absolutely
do
a
piecemeal
implementation
of
certain
aspects
of
Koob
ADM
using
the
phases-
sub-command
bridges
underneath
in
it.
So
what
we're
planning
on
doing
also
in
2019
is
modifying
premium
join
phases
so
that
we
have
a
similar
look
and
feel
for
how
I
know
adjoins
the
cluster
next
up.
We
also
have
completed
a
lot
of
the
work
around
our
sed
configuration
and
management.
C
So
you
can
use
cube
Adium
to
do
sed
management.
You
can
do
it
independently
of
kobane,
ium
and
somewhere.
You
can
do
it
as
in
a
stacked
master
configurations.
We
like
to
call
it
both
of
the
instructions
are
documented
on
the
main
website.
So
folks,
who
want
to
have
a
different
type
of
deployment
technologies,
can
our
support
it
for
both
last
and
not
least,
we've
kind
of
done
a
lot
of
work
to
get
Kubb
ATM
aspects
of
the
comedian,
CLI
ready
for
h8
capabilities.
C
C
Another
aspect
of
comedian
that
we
have
graduated
within
the
1:13
time
frame
was
the
configuration
file
format
inside
of
ku
medium
there's
a
well
versioned
and
typed
configuration
file.
It's
very
analogous
to
what
internal
components
inside
of
renée's
called
the
component
config.
So
we
use
API
machinery
to
basically
have
a
configuration
file
format
that
folks
can
depend
upon
a
conversion
over
time.
So
this
is
important
because
it's
is
its.
A
Thank
you
Tim.
Now
we
do
have
some
time
for
questions.
So,
if
you
like
to,
please
drop
it
in
the
Q&A
tab
at
the
bottom,
your
screen
and
we'll
get
to
as
many
as
we
have
time
for
him.
We've
got
plenty
of
time.
So
that's
the
good
part,
but
I
see
two
questions
that
aren't
here
and
first
is
from
the
Cal
Jane.
A
That
said,
could
you
please
highlight
the
key
benefits
of
kubernetes
on
gke
versus
on
AWS
eks
and
when
to
use
which,
unfortunately,
no
and
just
to
kind
of
give
you
some
more
kind
of
mindset,
of
sort
of
where
the
the
release
team
is
going
in?
Regards
of
how
we're
even
track
features
related
to
the
individual,
SIG's
themselves
or
individual
vendors?
Is
that
you've
seen
that
there
is
much
more
extensibility,
that's
being
built
into
kubernetes?
A
It's
coming
from
everywhere
from
the
storage
side,
it's
coming
to
the
cloud
provider
it's
coming
from
everywhere,
and
so
the
idea
going
forward
is
that
we
are
going
to
no
longer
track
a
lot
of
individual
vendor
enhancements
that
are
coming
with
inside
of
kubernetes
/
enhancements.
The
only
time
that
actually
is
gonna
be
tracked
now
is
the
the
deprecation
status.
So,
as
Saud
had
mentioned
earlier,
with
CSI
you're
gonna
start
seeing
a
lot
of
the
the
components
that
are
already
baked
into
kubernetes
start
being
shifted
out
into
their
own
cloud
controllers.
A
Now
those
are
being
tracked
because
we
have
to
track
them
for
what's
being
deprecated
inside
the
core
of
kubernetes
and
when
it
should
be
going
to
an
external
third-party.
However,
if
the
external
third-party
is
creating
their
vendor
specific
driver,
that's
going
to
be
taken
care
of
either
with
inside
their
own
cig
or
with
inside
of
some
other
tracking
mechanism.
So
the
cig
release
team
is
not
going
to
be
looking
at
every
single
vendor,
that's
creating
every
single
say:
CSI
driver,
that's
nothing!
That's
gonna
happen
there
as
well.
A
Stephan
asks
are
labels
like
alpha
beta,
postponed
included
when
describing
features
in
the
release?
Notes,
no,
not
in
the
release
notes
specifically.
So
the
best
way
to
look
at
this
is
there
are
alpha
beta
and
stable
tags.
If
you
go
to
the
kubernetes
slash
enhancements
repo
now
with
inside
of
there.
That
is
the
tracked.
A
Those
are
all
the
track,
features
or
enhancements
that
are
coming
in
and
how
you
can
see
which
stages
are
being
graduated
with
inside
of
the
release
notes,
it's
everything
from
bug
fixes
to
those
individual
components
themselves.
So,
if
you're
curious
about
a
specific
enhancement,
I'd
encourage
you
to
go
to
that
repo
and
not
be
focused
solely
on
the
the
release
notes
that
are
coming
from
the
rolled
up
version.
The
other
thing
to
also
understand
is
that
the
release
notes
themselves
are
being
given
by
the
individual.
A
C
Kuba
DMH
a
exists,
as
experimental
has
existed
for
as
experimental
sense
for
some
time
now
across
several
releases,
with
each
iteration
that
we've
done
from
like
112
113,
we
have
incremental
II
improved
the
user
experience.
There
is
one
problem
that
we
have
left
to
solve,
that
we
plan
to
promote
it
to
beta
in
114
and
that
problem
is
certificate
management.
So
there
are
a
number
of
proposals
that
we
have
gone
back
and
forth
on
with
regards
to
it.
But
I
fully
expect
like
everything.
C
Instead
of
Covidien,
we
plan
to
support
folks
even
through
experimental
features,
but
we
won't
do
it
officially
until
it's
getting
to
the
gotten
to
the
beta
state.
So
it
we've
been
very
conservative
on
the
Canadian
side
up
front
when
we
call
something
thing
beta,
because
you
want
to
make
sure
that
it's
rock-solid
and
that
folks
can
depend
upon
it,
I
something.
A
The
question
James
asks
when
you
say
windows
container
support
didn't
happen,
does
it
mean
one
cannot,
try
it
out
in
a
pre
alpha
beta
stage
within
one
thirteen?
Yes,
you
can
go,
try
it
out.
It
is
still
available
with
inside.
You
know
it's
it's
data
existence
right
now.
It
was
just
not
graduated
into
a
GA
status
to
be
graduated
into
that
particular
status.
The
terminology
is
still
always
being
defined
and
worked,
but
what
it
means
is
that
it
is.
A
A
C
Need
to
go
into
such
quenching
order,
and
this
is
well
defined,
actually
in
documentation
all
across
the
website.
There's
we
have
a
formalized
section
area
policy
and
there's
other
documentation
that
explicitly
outlines
how
to
upgrade
committee
and
proper,
and
the
reason
for
doing
this
actually
has
nothing
to
do
with
QB
name
at
all.
It
has
to
do
with
in
the
internals
of
API
machinery
and
what
it
means
to
upgrade
or
update
resource
objects,
raus
a
given
version
internally,
as
mentioned
earlier
on
the
call
with
regards
to
CRD
migration.
A
Thank
you
Tim.
You
might
be
able
to
know
this
because
you're
you're
the
smartest
guy
here
in
the
room,
sometimes
for
when
it
comes
to
these
particular
pieces.
When
is
the
issue
of
multi-tenancy
and
kubernetes
going
to
be
solved,
and
can
you
provide
fully
application
isolation
with
inside
the
same
cluster?
That's.
C
C
The
cluster
API
is
agnostic
to
comitia,
but
most
of
the
providers
do
leverage
Covidien
the
primary
function
of
Q
medium
was
to
become
the
reusable
nugget
for
four
different
install
and
most
of
the
Canadian
for
most
of
the
cluster.
Api
providers
do
use
comedian
at
its
core,
as
well
as
other
installation
tools,
including
coop
spray,
which
the
latest
version
of
coop
spray
that
supported
for
113
also
uses
premium
escort.
A
B
Take
this
one,
so
in
fact
yes,
so
the
way
that
Tim
Hawkins
describes.
This
is
that
if
you,
if
we
had
CRD
machinery,
when
we
first
started
the
project,
there
would
be
no
core
objects.
Crd
is
just
a
mechanism
for
describing
an
API
resource
in
the
future.
We
want
to
build
up
the
the
CRD
machinery
to
the
point
where
it
can
provide
you
essentially
the
same
level
of
functionality
as
the
core
built-in
types
and
moving
forward.
All
new
functionality
will
be
added
via
CR
DS
and
in
the
past.
B
If
we
had
this,
even
core
objects
like
node
would
be
CR
DS
and
the
reason
for
doing
this
is
we
want
to
simplify
the
API
server
into
just
a
pluggable
component
that
multiple
projects
can
reuse
and
then
the
resources
that
they
care
about
will
be
installed
as
CR
DS.
So
on
the
six
storage
side,
for
example,
we're
already
running
into
this,
where,
where
our
snapshot
feature,
for
example,
is
making
use
of
CR
DS
2
to
define
the
API
objects
that
it
will
be
using,
but
it
doesn't
make
it
any
less
kubernetes.
A
B
C
A
C
A
Thank
you.
Another
question.
That's
a
follow-up
to
the
multi-tenancy
is:
can
we
achieve
full
isolation
between
applications
installed
across
different
namespaces?
In
the
same
cluster?
There
use
cases
we
need
a
group
of
admins
managing
one
app
that
cannot
access
other
apps
in
a
different
namespace
yeah.
C
You
can
get
full
oscillation
with
regards
to
network
policy,
if
that's
what
you,
if
that's
your
boundary
line
for
isolation,
so
this
is
where
this
is.
Where
I
said,
hard
multi-tenancy
gets
a
little
strange
because
it
depends
upon
what
level
you
consider
things
to
be
completely
sandboxed
right.
So
if
you
want
to
be
completely
sandbox,
you
have
to
get
to
some
level
of
virtualization
at
the
lowest
level
or
some
hard
boundary
box
by
which
folks
could
feel
comfortable
with
at
the
container
at
the
pod
slash
container
level.
C
A
Great,
thank
you.
Tim
with
that
I,
don't
see
any
more
questions
that
are
available
and
that's
what
we're
gonna
wrap
up
with.
Thank
you,
everybody
for
joining
us
today.
The
webinar,
recording
and
slides
will
be
online
later
today
as
well.
We
look
forward
to
seeing
you
at
a
future.
Cn
CF
webinar
have
a
great
day.
Everyone
take.