►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-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.
Kubernetes Data Protection WG Deep Dive - Xiangqian Yu, Google
Speakers: Xiangqian Yu
Data Protection WG is dedicated to promoting data protection support in Kubernetes. The Working Group is working on identifying missing functionalities and collaborating across multiple SIGs to design features to enable data protection in Kubernetes. In this session, the co-chairs of this WG will discuss what is the current state of data protection in Kubernetes and where it is heading in the future. They will also talk about how interested parties (including storage and backup vendors, cloud providers, application developers, and end users, etc.) can join this WG and contribute to this effort. Details of the WG can be found here: https://github.com/kubernetes/community/tree/master/wg-data-protection.
A
A
We
have
a
long
agenda
to
go
today,
so
we'll
try
to
go
fast.
They
generalize
many
to
Deep
dive
into
a
couple
of
caps
into
this
whole
data
protection
working
group.
Or
what
are
we
doing?
What
kind
of
progresses
were
made
so
far
and
what
problems
are
we
trying
to
solve
as
Euro
we'll
start
with
motivation,
then
move
on
to
the
organization
that
has
been
involved
and
actually
pretty
actively
contributing
into
this
working
group
and
give
this
group
here
a
little
bit
key
updates.
A
A
A
Another
trend
is
that
some
of
you
I
think
I
recognize
it
went
to
the
data
in
kubernetes
meeting
on
Monday
right.
The
trend
is
pretty
obvious,
so
more
and
more
stateful
workload
is
moving
into
kubernetes
World.
Initially,
the
kubernetes
actually
has
been
built
in
a
state
where
you
can
safely
bring
down
and
bring
up
your
application
at
any
given
point
of
time
and
it
scales
for
you,
but
not
a
not
a
very
fundamental
problem
to
solve
over
here
for
state
will
work.
A
Early
is
actually,
how
do
I
make
sure
my
data,
it's
not
in
it's
it's
protected
properly
so
day,
two
operations
for
now
in
kubernetes
is
actually
still
having
a
couple
of
grabs
over
there.
There
are
tools
there
by
saying
that
right,
like,
for
example,
git
Ops
is
very
popular
as
of
today
to
allow
you
save
your
configuration
into
a
git
repository
while
still
allow
you
to
do
application,
low,
back
and
upgrade
failures,
recovery,
etc,
etc.
A
However,
the
main
gaps
has
been
noticed
and
found
in
the
various
where
we
want
to
do
application,
Level
consistency,
snapshots
or
backup
of
your
system
and
then
the
restoration
pieces,
along
with
your
data
stored
in
your
persistent
volumes.
So
this
is
the
entire
motivation
of
this
working
group
is
to
provide
or
build
or
design
the
basic
components
to
support
stateful
application
Protections
in
the
kubernetes
environment,
with
that
these
are
the
list
of
organizations
and
contributors
from
these
organizations
and
very
active
in
this
working
group.
A
So
if
you're
interested
and
if
you,
if
you're
interested,
feel
free
to
reach
out
to
us
too
key
updates.
So
in
the
past
year
or
so,
this
is
a
very
hard
topic,
first
of
all,
because
it
is
really
challenging
and
they
are
very
matured,
commercial
products
for
VM
workloads
in
terms
of
a
database
running
on
VMS,
etc,
etc,
but
in
kubernetes
not
a
lot
has
been
down
until
now
in
this
area,
so
we
published
the
first
ever
white
paper
in
the
community.
A
This
one
of
the
key
things
I
think
a
lot
of
people
can
benefit
from
this
white
paper
is
how
what
are
the
kind
of
you
know,
modern
applications
that
consider
or
are
moving
to
kubernetes
environment
and
what
are
the
mechanisms?
Those
applications
use
is
to
protect
the
work
to
protect
the
data
that
includes
relational
databases,
message
accused
or
a
key
biosphere
or
key
value
or
key
value
stores.
A
In
this
this
is
a
very
long
white
paper.
So,
if
you're
interested,
please
take
a
look
at
that
and
then
there's
an
annual
report,
Which
documents,
all
the
Caps
that
the
working
group
has
been
tracking
in
the
past
year
or
two,
and
also
we
provide
all
the
previous
talks
and
links
in
this
slide
stack
if
you're
interested
feel
free
to
take
a
look
cool
with
that.
This
is
a
very
busy
slice,
I'm
not
going
to
dive
too
much
into
that,
but
conceptual
wise
it.
A
It
gives
you
a
rough
idea
how
application
backup
can
happen
to
achieve
application,
consistency
in
a
kubernetes
environment,
again
I'm
not
going
to
dive
too
deep
into
this.
But
the
key
point
I
want
to
point
out
is
that
they
are
cream.
Labeled
components
which
are
already
available
and
the
blue
ones
are
workflows
and
orange
and
yellow
ones
are
either
in
progress
or
still
being
designed.
A
So
you
can
see
there's
one
important
one
called
cozy,
which
is
already
Alpha
in
1.25.
This
provides
you
the
ability
to
provision
a
bucket
and
Grant
access
in
a
kubernetes
environment,
supporting
right
now,
I
think
a
couple
of
vendors,
gcp
AWS
as
well
as
Azure,
and
then
the
volume
mellow
conventions
right
now
in
Alpha.
This
is
more
about
the
backup,
workflow
and
the
under
restoration
part.
A
This
is
the
another
kind
of
busy
slide,
not
diving
too
much
by
highlighting
cozy,
which
serves
as
the
source
where
you
store
your
backup,
as
well
as
the
volume
populator
which
allows
you
to
plug
in
any
specific
window,
specific
implementations
to
do
a
volume
restoration
at
one
time,
with
that
I'm
gonna,
wrap
up
and
start
deep
diving
into
each
of
these
caps.
This
is
the
first
one
William
model
convention.
A
Some
of
you
may
be
aware,
as
of
today,
the
William
snapshot
feature
allows
you
to
take
a
snapshot
of
a
persistent
volume
in
a
kubernetes
cluster
right.
This
is
a
point
in
time
snapshot
of
your
of
your
data.
It
allows
you
to
also
restore
a
block
volume
into
a
file
system,
one
and
vice
versa.
However,
this
is
the
interesting
dilemma
over
here
where
the
volume
model
transition
can
actually
introduce
vulnerability
to
the
kernel,
and
this
is
considered
to
be
a
cve.
A
So
what
happens
is
like
if
your
DD,
for
example,
a
block
volume
or
you
just
touch
it
and
maybe
put
some
mailware
on
a
block
of
volume
and
take
a
snapshot
of
it
and
you
accidentally
restore
it
into
a
file
system
volume,
and
that
will
cause
your
kernel
to
crash
right.
We
don't
want
that
because
that
crashed
the
entire
node.
So,
on
the
flip
side,
this
is
actually
in
a
great
neat
feature
of
backup
vendors,
the
backup
Windows.
What
they
want
to
do
is
I
will
take
a
snapshot
of
your
file
system
volume.
A
However,
I
want
you
to
do
a
very
efficient
volume,
backup,
meaning
that
I
only
want
to
backup
the
data
that
changed
in
the
past
in
between
two
snapshots
and
that,
in
order
for
them
to
do
that,
they
want
to
introduce
something
called
like
a
block
differences
calculation
where
you
invest.
Majority
of
implementation
is
really
just
calculate
the
hash
value
of
the
block
devices
and
try
to
see
okay.
If
there's
anything
changed,
I
will
back
it
up,
otherwise,
I'll
just
leave
it
there.
So
this
is
a
great
it's
a
neither
feature.
A
However,
you
introduce
the
vulnerability
so
in
or
volume
snapshot,
so
we
introduced
this
volume
conversion
model
to.
Of
course,
we
want
to
fix
the
cve
right.
So
basically,
the
idea
is,
in
the
volume
snapshot
content
resource
right
now
there
is
a
field
called
Source
volume
model.
It
tells
you
whether
your
snapshot
is
coming
from
a
block
device
or
snap
is
it.
The
snapshot
is
coming
from
a
file
system
volume
and
then,
if
I
add
in
this
model,
the
behavior
becomes.
A
When
you
do
a
restoration,
if
the
source
volume
is
a
block
volume
and
you're
restoring
into
a
file
system,
while
it
will
not
work,
it
will
block
you.
However,
in
order
to
support
the
backup
systems
right,
there's
a
special
way
of
tricking
in
the
system
by
adding
an
annotation.
This
is
a
very
supportive,
well-supported
annotation
that
allows
you
to
actually
do
the
transition.
This
is
basically
a
basically
opened
the
door.
A
Now
you
close
the
door
entirely
for
backup
system,
because
the
assumption
is
that
they
know
exactly
what
they're
doing
so
to
prevent
the
kernel
attacks
from
happening
in
the
beginning
right
now.
This
is
in
the
office
stage
in
1.24
and
we
have
the
cap,
and
the
blockade
is
still
right
there,
great
thanks
to
renak,
who
has
been
working
on
this
for
I
think
a
couple
of
months,
because
this
involves
a
API
change
in
the
world
snapshot
content.
A
A
However,
this
Source
currently
only
supports
volume
snapshot
right,
William
snapshot
in
many
storage
vendors.
It's
just
a
point
in
time:
local
snapshot
of
your
system.
It
does
not
necessarily
back
up
your
data.
It
depends
on
when
there's
the
implementation,
but
if
your
cluster
crashes
or
your
storage
system
crashes,
you
still
don't
have
the
ability
to
recover
it.
A
You
want
to
use
later
on,
after
your
Disaster
Recovery
or
a
disaster,
or
your
application
failure
in
order
to
do
this,
where
we
need
the
in
order
for
the
vendor
to
support
within
a
crd
that
supports
specific
data
source
reference
in
the
PVC.
This
is
a
newly
added
field.
Right
now,
it's
in
beta
stage,
the
crd
will
be
recognized.
Just
like
a
CSI
driver's
storage
class
will
be
recognized
by
the
name
of
the
crd
to
point
to
the
particular
volume
populator
you
don't
want.
A
One
thing
you
don't
want
to
happen
is
that,
okay,
you
have
a
backup
that
is
created
by
storage
window.
One
and
a
storage
window
choose
one
popular
connection
and
try
to
read
the
data
and
it's
never
going
to
work,
and
it
also
introduces
problems.
Then
the
William
populated
controller
will
watch
the
PVC
that
has
that
data
source
field
specified
and
smart
enough
to
say.
Oh,
this
is
actually
this
specific
volume
populator's
job,
so
they
will
pick
up
from
the
oil,
the
PVC
and
start
popular
the
data
off
the
line.
A
A
This
is
the
API,
it
look,
does
look
we're
pretty
straightforward
and
basic
at
this
stage
is
better
in
1.24
and
is
gated
by
this
any
volume
data
source
feature
gate
in
kubernetes.
If
you
want
to
try
it
out
to
another
feature
gate
you
should
be
able
to
plug
in
your
volume
populator
and
do
all
the
volume,
backup
and
restore
process
in
your
case
and
the
foreign
are
the
steps
how
you
can
carry
all
these
operations
with
that
I'm
going
to
shift
you
to
Shin
to
continue
our
journey.
B
I'm
going
to
talk
about
CBT,
this
is
the
next
feature
that
we
are
working
on.
So
CBT
stands
for
change,
block
tracking.
This
identifies
the
blocks
of
data
that
have
changed.
This
enables
incremental
backups.
Without
this
a
backup,
software
will
have
to
do
full
backups
all
the
time,
and
that
is
a
not
space
efficient,
takes
very
long
time
to
complete
and
takes
more
bandwidth.
B
So
what
is
the
alternative?
We
don't
have
a
common
CPT
API.
We
either
have
to
do
full
backups
all
the
time
or
we
have
to
call
each
story-
vendors
API
to
retrieve
CPT.
So
this
is
a
not
ideal
right
now
we
do
have
a
cat.
That's
been
reviewed.
This
is
the
based
on
aggregated
API
server,
because
we
try
not
to
save
other
CPT
records
in
API
server.
B
B
B
B
B
Shown
here
we
have
a
bucket
access
class
that
specifies
the
authentication
type.
It
can
be
a
key
or
aim,
and
we
also
have
a
bucket
access
in
the
bucket
access.
You
specify
the
bucket
access
cost
name,
the
bucket
claim
name
the
credentials
and
the
protocol
and
user
just
creates
a
pod
with
the
project
volume
pointing
to
a
secret
in
the
bucket
access,
and
the
secret
contains
the
bucket
info
that
is
mounted
at
the
specified
location.
B
See
it
has
been
leading
this
project.
There
are
also
many
other
contributors
for
this
project.
This
project
reached
Alpha
stage
in
1.25
release,
so
the
causatine
has
been
having
meetings
every
week.
They
are
busy
working
on
fixing
bugs
working
on
documentation
and
also
trying
to
get
more
sort
of
vendors
to
write
drivers.
B
Next
I'm
going
to
talk
about
choirs
and
unquest
hooks.
We
need
this
to
ensure
application
consistency
to
be
able
to
acquire
supplication
before
taking
a
snapshot
and
unquest.
Afterwards
we
looked
into
the
class
and
the
unquest
mechanism
of
different
applications,
and
they
all
have
different
semantics.
B
B
At
the
same
point
in
time,
there
was
also
a
performance
element
here
that
if
you
can
take
a
snapshot
of
multiple
volumes
at
the
same
time,
that's
more
efficient
than
take
one
snapshot
at
a
time.
So
that's
why
we
need
a
consistent
group
snapshot
and
there
is
a
cap.
That's
been
previewed
targeting
1.26
I'm
working
on
this
cup.
B
B
B
So
moving
on
to
application
snapshot
and
backup,
we
already
have
a
apis
to
take
snapshot
of
individual
volume.
But
what
about
a
application?
How
do
you
do
snapshot
and
backup
for
that?
There
is
a
cap
that
tries
to
define
a
stateful
application
and
the
proposal
way
to
do
a
snapshot
and
the
backup
of
that
staple
application.
This
is
still
in
a
very
early
stage
of
design.
B
B
B
A
B
A
B
B
B
A
You
will
keep
a
lot
of
states
in
your
rent
right,
that's
to
achieve
better
performance,
so
my
SQL
actually
allows
you
to
say:
stop
accepting
rights,
flush
migraine
to
my
disk
and
then
do
whatever
you
want
to
do
and
then
resume
me
right.
This
is
quite
as
Focus
to
guide
the
guided
the
process
to
be.
You
know
Atomic
before
and
after
you're,
taking
a
snapshot
of
the
entire
volume.
A
A
B
B
A
B
Storage
in
the
storage
system
itself
is
that
what
you're
saying,
but
but
what
I
think
the
concern
is
even
just
to
for
that
to
pass
through
the
API
server?
That's
even
a
concern
right,
so
it's
not.
We
are
actually
also
I
want
to
emphasize
that
this
is
only
the
control
path.
We're
not
really
talking
about
the
data
itself.