►
From YouTube: Kubernetes SIG Storage Introduction and Update - Xing Yang, VMware & Michelle Au, Google
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Kubernetes SIG 存储介绍和更新 | Kubernetes SIG Storage Introduction and Update - Xing Yang, VMware & Michelle Au, Google
Kubernetes SIG 存储负责确保不同类型的文件和块存储在容器调度的任何地方都可用，确保存储容量管理（容器临时存储的使用，卷的体积调整等），根据存储影响容器的调度（数据引力，可用性等），以及存储的通用操作（快照等）。在此次讨论中，我们将对 SIG 存储进行介绍，然后深入探讨 SIG 存储目前正在开展的一些项目，提供最新状态更新，并讨论未来可能出现的情况。
Kubernetes SIG Storage is responsible for ensuring that different types of file and block storage are available wherever a container is scheduled, storage capacity management (container ephemeral storage usage, volume resizing, etc.), influencing scheduling of containers based on storage (data gravity, availability, etc.), and generic operations on storage (snapshotting, etc.). In this session, we will give an introduction to SIG Storage and then deep dive into some projects that SIG Storage is currently working on, provide an update on the current status, and discuss what might be coming in the future.
A
B
A
A
A
A
pvc
and
a
pv
have
a
one.
Two
one
mapping
studio
class
is
in
the
cluster.
Scope
is
the
way
for
admin
to
describe
the
classes
of
storage,
different
classes,
might
map
to
different
quality
of
service
levels
or
other
admin
defined
policies
in
dynamic
provisioning
study
class
is
used
to
find
out
which
provisioner
should
be
used
and
what
parameters
should
be
passed
to
the
provisioner
when
creating
a
volume.
A
A
A
When
now
the
static
pvc,
one
of
the
static
pvs,
the
admin
the
administrator
created,
match
a
user's
pvc,
the
cluster
may
try
to
dynamically
provision
a
volume
specifically
for
that
pvc.
The
provisioning
is
based
on
storage
classes.
The
pvc
must
request
a
sturdy
class
and
the
admin
must
have
created
and
configured
that
class
for
dynamic
provisioning
to
occur.
A
A
The
reclaim
policy
is
retained
here.
That
means
the
pv
will
remain
along
with
physical
volume
on
the
structure
system.
When
the
user
deletes
the
pvc,
if
the
claim
if
the
reclaim
policy
is
delete,
the
pv,
along
with
the
physical
volume,
will
be
deleted
when
the
user
deletes
the
pvc
and
the
alarm.
Expansion
is
true
here,
indicating
that
one
expansion
can
be
requested
by
the
user
and
the
only
binding
mode
can
be
either
immediate
or
wait
for
first
consumer.
A
A
A
All
containers
in
a
pod
can
read
and
write
the
same
files
in
empty
volume,
though,
that
volume
can
be
mounted
at
the
same
or
different
paths
in
each
container
and
when
a
part
is
removed
from
node.
For
any
reason,
the
data
in
the
emptier
is
deleted
permanently
and
empty.
The
volume
can
be
used
as
a
scratch.
Space.
A
A
A
And
then
next
I
will
talk
about
the
downward
apis,
so
here
we
can
see
an
example
of
the
downward
api
volume
it
makes
downward
apart
data
available
to
the
applications
it
mounts
a
directory
and
writes
the
requested
data
in
plain
text
file
and
in
this
yaml
file
you
can
see
that
the
part
has
a
downward
api
volume
and
the
container
mounts
the
volume
at
this.
The
specified
location
and
each
element
on
items
is
a
downward
api
volume
file.
A
So
next
I
want
to
talk
about
the
csi
inline
ethmoid
volume,
so
we
set
volume
types
to
csi
in
the
pod
spec
and
specify
the
driver
name
and
the
warning
attributes
and
for
a
csr
driver
to
support
csi
at
my
volume
it
must
be
modified
or
implemented
specifically
for
this
purpose
a
since
the
driver
is
suitable
for
csi
ethmo
inline
volume
if
it
serves
a
special
purpose
and
needs
custom.
Providing
parameters
like
drivers
that
provide
secrets
to
a
pod,
so
the
secret
store
csi
driver
is
an
example.
A
A
The
suture
allows
any
existing
study
drivers
that
supports
dynamic
provisioning
to
be
used
as
an
ethernet
volume.
With
the
volume's
lifecycle
bound
to
your
pod,
it
can
be
used
to
provide
scratch
storage
that
is
different
from
the
root
disk.
For
example,
a
persistent
memory
or
a
separate
local
disk
on
that
node
all
student
class
parameters
for
volume
provisioning
are
supported.
A
A
A
A
A
So
here
is
an
example
of
a
csi
deployment
that
shows
various
kubernetes
components:
the
csi
driver
and
the
storage
system
that
is
used
to
persist
the
data.
Here
we
have
the
cube
control
manager
on
the
master
node.
A
csr
driver
controller
plugin
is
deployed
together
with
kubernetes
csi,
external
partitioner,
external
attacher,
external
resizer
and
external
snapshotter
said
cars.
A
The
kubernetes
is
a
side
course
watching.
Kubernetes
api
objects
such
as
persistent
volume
claims,
persistent
volumes,
volume,
attachments,
volume
snapshots
to
detect
grid
volume,
attach
volume.
One
extension
volume
snapshots,
requests
the
same
cards
called
the
css
driver
and
the
csi
driver
communicates
with
the
storage
system
to
complete
those
volume
operations
on
kubernetes
worker
nodes.
A
A
A
A
I
included
some
resources
for
your
reference.
Here
are
docs
that
explain
what
are
the
kubernetes
story
concepts
and
what
is
csi.
The
last
reference
is
an
example
to
deploy
the
sample
csi
host
hostpass
driver
for
a
new
contributor
who
wants
to
contribute
code,
it's
good
to
follow
this
example
and
learn
how
csr
works.
A
B
B
So
what
we've
done
instead
is
csi
migration.
The
csi
migration
is
a
feature
that
lets
you
continue
using
the
existing
api
for
your
existing
persistent
volumes
and
storage
classes,
but
underneath
the
covers
it
actually
makes
calls
to
a
corresponding
csi
driver
instead
of
going
through
the
built-in
drivers.
B
B
B
B
So
you
know
once
that
graduates
in
maturity,
then,
potentially
we
can
remove
the
need
for
a
csi
proxy
and
having
a
separate
service
to
do
the
privileged
operations,
however,
to
retain
backwards
compatibility
with
existing
csi
drivers.
What
we're
planning
on
doing
is
to
turn
the
csi
proxy
grpc
client
library
into
a
normal
library,
with
using
the
same
apis.
B
B
B
B
B
So,
if
you're
a
csi
driver
author,
please
take
a
look
at
this
fs
group
policy
feature
the
last
feature
that
we're
targeting
for
ga
is
generic
ephemeral
volumes.
Xing
talked
about
this
earlier,
so
I
won't
go
into
a
lot
of
details,
but
to
summarize,
this
feature
allows
a
pod
to
specify
a
volume
template
which
will
dynamically
provision
and
manage
volumes
with
the
same
lifetime
as
your
pod.
B
B
This
is
in
a
design
and
prototyping
phase.
So
if
you
have
any
ideas-
or
you
have
work
in
this
area-
that
you
think
will
be
useful,
please
join
us
in
these
discussions
and
we
would
appreciate
any
ideas
or
help
that
you
can
provide
another
interesting
initiative
that
we're
starting
is
to
explore.
Is
volume
snapshot,
namespace
transfer?
B
B
In
next
slide,
please
we're
also
collaborating
with
a
couple
other
things
on
a
variety
of
other
projects.
I'll
highlight
the
container
notifier
effort.
This
is
a
feature
that
allows
for
sending
custom
signals
to
a
pod
and
being
able
to
define
custom
actions
for
that
pod
to
take
when
processing
that
signal.
B
B
B
The
main
difference
is
that
finalizers,
their
main
goal
is
to
ensure
that
all
of
the
deletion
handlers
for
an
object
are
able
to
finish
before
the
object
is
finally
deleted
from
the
api
server
with
finalizers.
The
big
difference
is
once
the
deletion
process
starts.
You
can't
reverse
it,
and
you
can't
undo
a
delete
with
the
ends.
B
The
the
biggest
difference
is
that
the
ends
will
prevent
the
deletion
process
from
starting
in
the
first
place.
So
this
will,
you
know,
help
with
the
scenarios
when
you
really
want
to
protect
some
objects
from
being
accidentally
deleted,
and
so
that's
another
exciting
effort
that
we
are
working
with
api
machinery
on
and
we're
hoping
to
be
able
to
use
this
to
add
some
extra
protection
to
secrets,
especially
in
terms
of
in
terms
of
protecting
secrets
that
are
used
for
volumes.
B
B
If
any
of
these
projects
sound
interesting
to
you,
please
reach
out
to
us
through
our
slack
channel
or
join
one
of
our
sig
meetings
that
we
hold
every
two
weeks,
we'll
welcome.
We
welcome
new
ideas
and
you
contribute
new
contributors
and
we'll
you
know
definitely
try
to
help
you
get
involved
into
the
sig.